Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet

• US 6,728,748 B1
• Filed: 11/30/1999
• Issued: 04/27/2004
• Est. Priority Date: 12/01/1998
• Status: Expired due to Term

• Current Assignee: Network Appliance Incorporated (NetApp, Inc.)
• Original Assignee: Network Appliance Incorporated (NetApp, Inc.)
• Inventors: Mangipudi, Krishna, Basani, Vijay
• Primary Examiner(s): Maung, Zarni
• Application Number:
  US09/450,571
• Time in Patent Office: 1,610 Days
• Field of Search: 709/105, 709/221, 709/223, 709/226, 709/224, 709/225, 714/15
• US Class Current: 718/105
• CPC Class Codes: H04L 41/0213 Standardised network management protocols, e.g. simple network management protocol [SNMP]
• CPC Class Codes: H04L 41/0604 using filtering, e.g. reduction of information by using priority, element types, position or time
• CPC Class Codes: H04L 41/0893 Assignment of logical groups to network elements
• CPC Class Codes: H04L 41/0894 Policy-based network configuration management
• CPC Class Codes: H04L 41/22 comprising specially adapted graphical user interfaces [GUI]
• CPC Class Codes: H04L 41/5009 Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
• CPC Class Codes: H04L 41/5025 by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
• CPC Class Codes: H04L 43/045 for graphical visualisation of monitoring data
• CPC Class Codes: H04L 43/06 Generation of reports
• CPC Class Codes: H04L 43/08 Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
• CPC Class Codes: H04L 43/0811 by checking connectivity
• CPC Class Codes: H04L 43/0817 by checking functioning
• CPC Class Codes: H04L 43/0823 Errors, e.g. transmission errors
• CPC Class Codes: H04L 43/16 Threshold monitoring
• CPC Class Codes: H04L 67/02 based on web technology, e.g. hypertext transfer protocol [HTTP]
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1006 with static server selection, e.g. the same server being selected for a specific client
• CPC Class Codes: H04L 67/1008 based on parameters of servers, e.g. available memory or workload monitoring of computer activity G06F11/30
• CPC Class Codes: H04L 67/1012 based on compliance of requirements or conditions with available server resources
• CPC Class Codes: H04L 67/1014 based on the content of a request
• CPC Class Codes: H04L 67/1017 : based on a round robin mechanism
• CPC Class Codes: H04L 67/1023 : based on a hash applied to IP addresses or costs
• CPC Class Codes: H04L 69/329 : in the application layer [OSI layer 7]

Abstract

A method and apparatus for robustly enhanced Class of Service (COS) at the application layer permits highly flexible privilege based access and enables implementation of complex policies and rules for classification and differentiation of services. Differentiation facilitates categorization of traffic to permit flexible design and implementation of multiple Class of Service levels.

Claims

1. An apparatus implementing class of service among a plurality of clients sending requests seeking access to sites on a plurality of back-end servers, comprising:

a front-end processor configured to receive client requests from said plurality of clients for access to sites hosted by said plurality of back-end servers;

a monitoring processor in communication with said front-end processor, monitoring availability of said plurality of back-end servers to enable said requests to be sent to a selected one of said plurality of back-end servers, wherein said monitoring processor further includes an adaptive policy engine (APE) adaptively balancing one of said plurality of back-end servers defining at least a first cluster and a second cluster, by defining a threshold setting an acceptable range for each of a plurality of service level metrics, and reconfiguring said at least said first cluster and said second cluster in response to a determination that at least one of said plurality of selected service level metrics for one of said at least said first cluster and said second cluster is not within said acceptable range; and

at least one intelligent agent deployed on at least one of said plurality of back-end servers in communication with said monitoring processor and said front-end processor, said at least one intelligent agent monitoring selected server attributes and reporting status of said selected server attributes back to said monitoring processor enabling said front-end processor to direct said client requests to selected ones of said plurality of back-end servers as a function of said selected server attributes.

2. The apparatus of claim 1 wherein said front-end processor is a TCP router.

3. The apparatus of claim 1 wherein said at least one of said plurality of selected service level metrics is selected from a group consisting of:

response time by user;

URL;

request;

transaction type;

content type;

application type;

service/protocol type;

domain of origin;

file size;

online/offline status;

total hits per second;

CPU utilization (i.e. number of processors and percent utilization);

number of processes;

total open connections;

disk space (i.e. disk size in bytes, bytes used, percent used, percent free);

response times of back-end servers;

URL/content availability;

server and virtual site availability;

application availability; and

memory utilization (i.e. total memory, memory used, free memory).

6. The apparatus of claim 1 or 4 wherein said at least one intelligent agent monitors at least one server attribute/parameter, said at least one server attribute/parameter selected from the group consisting of:

response time by user;

URL;

request;

transaction type;

content type;

application type;

service/protocol type;

domain of origin;

file size;

online/offline status;

total hits per second;

CPU utilization (i.e. number of processors and percent utilization);

number of processes;

total open connections;

disk space (i.e. disk size in bytes, bytes used, percent used, percent free);

response times of back-end servers;

URL/content availability;

server and virtual site availability;

application availability; and

memory utilization (i.e. total memory, memory used, free memory).

7. The apparatus of claim 6 wherein said at least one server attribute/parameter is reported to said front end processor via a Management Information Base (MIB).

8. The apparatus of claim 6 wherein said at least one server attribute/parameter is made available to application layer programs.

9. The apparatus of claim 1 or 4 wherein said front end processor classifies incoming requests into classes based on the Source IP address, Destination IP address, Port Number, URL, service or protocol, virtual site, transaction or request, authenticated user or cookie based.

10. The apparatus of claim 1 or 4 wherein selected ones of said plurality of back-end servers are clustered into user definable cluster groups designated with a particular class of service, and wherein a request or user is directed to one of said user definable cluster groups based on said particular class of service.

11. The apparatus of claim 10 wherein a specific machine selected from selected ones of said plurality of back-end servers is selected based upon a load balancing algorithm specified for a cluster group, and said load balancing algorithm is selected from a group consisting of weighted percentage load balancing;

round robin load balancing;

CPU availability load balancing;

probabilistic load balancing and least connections load balancing.

12. The apparatus of claim 11 wherein said probabilistic load balancing algorithm comprises the steps of determining which of said plurality of back-end servers has a maximum load, determining an offset of each said back-end server from said maximum load, summing all of said offsets for all said back-end servers to obtain a sum, and proportionally distributing a number of said requests as a function of said offsets, where said number is equal to said sum.

13. The apparatus of claim 1 wherein said monitoring processor further includes an adaptive balancing module that balances said plurality of back-end servers in a cluster dynamically based on information/parameters received via a UDP packet and based on service level commitments.

14. The apparatus of claim 1 or 4 further including a failover capability wherein said redundant front-end processor assumes functions of said front-end processor when said front-end processor fails and vice versa.

4. An apparatus implementing management service level metrics for a plurality of clients sending requests seeking access to sites on a plurality of back-end servers and enabling said requests to be sent to a selected one of said plurality of back-end servers, comprising:

a front-end processing system including a front-end processor and a redundant front-end processor, wherein at least one of said front-end processor and said redundant front-end processor is configured to receive client requests from said plurality of clients for access to sites hosted by said plurality of back-end servers;

an adaptive policy engine, in communication with said front-end processor, adaptively balancing ones of said plurality of back-end servers defining a first cluster and a second cluster and reconfiguring said first cluster and said second cluster in response to a determination that at least one selected server attribute for one of said first cluster and said second cluster is not within an acceptable range; and

at least one intelligent agent deployed with at least one of said plurality of back-end servers, in communication with said adaptive policy engine, said at least one intelligent agent monitoring selected server attributes and reporting status of said selected server attributes to said adaptive policy engine, enabling said adaptive policy engine to reconfigure said first cluster and said second cluster as a function of said selected server attributes.

5. The apparatus of claim 4 wherein said at least one selected service level metric is selected from a group consisting of:

online/offline status;

total hits per second;

CPU utilization (i.e. number of processors and utilization);

number of processes;

total open connections;

disk space (i.e. disk size in bytes, bytes used, percent used, percent free);

response times of back-end servers;

URL/content availability;

server and virtual site availability;

application availability; and

memory utilization (i.e. total memory, memory used, free memory).

15. A method for implementing class of service among a plurality of clients sending requests seeking access to sites hosted on a plurality of back-end servers, comprising the steps of:

by a front-end processing system including a front-end processor and a redundant front-end processor, receiving client requests from said plurality of clients for access to sites hosted by said plurality of back-end servers;

monitoring availability of said plurality of back-end servers with a monitoring processor to enable said requests to be sent to a selected one of said plurality of back-end servers;

deploying at least one intelligent agent on at least one of said plurality of back-end servers;

reporting a monitored status of selected server attributes from said at least one intelligent agent back to said monitoring processor; and

directing said client requests to selected ones of said plurality of back-end servers as a function of said selected server attributes.

16. The method of claim 15 in which said step of directing said client requests further comprises the steps of:

defining at least a first cluster and a second cluster of back-end servers from said plurality of back-end servers;

determining that at least one selected service level metric for said first cluster is not within an acceptable range for said metric; and

reconfiguring said at least said first cluster and said second cluster as a result of said determining step.

17. The method of claim 16 in which said at least one selected service level metric is selected from a group consisting of:

online/offline status;

total hits per second;

CPU utilization (i.e. number of processors and utilization);

number of processes;

total open connections;

disk space (i.e. disk size in bytes, bytes used, percent used, percent free);

response times of back-end servers;

URL/content availability;

server and virtual site availability;

application availability; and

memory utilization (i.e. total memory, memory used, free memory).

18. A method for balancing client request load among a plurality of web servers comprising the steps of:

classifying said plurality of web servers into clusters corresponding to at least a first class and a second class, wherein said classifying is based on user-defined policies;

determining a set of service threshold levels of selected service level metrics for each of said at least said first class and said second class;

monitoring said selected service level metrics for each web server;

determining when a service level threshold of said selected service level metrics has been exceeded for at least one of said at least said first class and said second class; and

invoking an adaptive control process to rebalance said at least said first class and said second class of said web servers by moving a web server from one to another of said at least said first class and said second class according to the monitored selected service level metrics.

19. The method of claim 18 in which said adaptive control process includes a mechanism for implementing one of a plurality of load balancing algorithms as a function of class.

20. The method of claim 19 wherein said plurality of load balancing algorithms includes weighted percentage;

round robin;

CPU availability;

least connections; and

probabilistic.

21. The method of claim 20 wherein said probabilistic load balancing is a process which involves determining which of said plurality of back-end servers has a maximum load, determining an offset of each said back-end server from said maximum load, summing all of said offsets for all said back-end servers to obtain a sum, and proportionally distributing a number of said client requests as a function of said offsets, where said number is equal to said sum.