in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 7 8 9 10 11 12 < 13 > 14 15 16 17 18 19 .. 70 >> Next

Health Checks
Performing various checks to determine the health of servers and applications is one of the most important benefits of load balancers. Without a load balancer, a client sends requests to a dead server if one fails. The
Basic Health Checks
administration must manually intervene to replace the server with a new one, or troubleshoot the dead server. Further, a server may be up, but the application can be down or misbehaving for various reasons, including software bugs. A Web application may be up, but it can be serving corrupt content. Load balancers can detect these conditions and react immediately to direct the client to an alternate server without any manual intervention from the administrator.
At a high level, health checks fall into two categories: in-band checks and out-of-band checks. With in-band checks, the load balancer uses the natural traffic flow between clients and servers to see if a server is healthy. For example, if the load balancer forwards a client’s SYN packet to a real server, but does not see a SYN ACK response from the server, the load balancer can suspect that something is wrong with that real server.
The load balancer may then trigger an explicit health check on the real server and examine the results. Out-of-band health checks are explicit health checks made by the load balancer.
Basic Health Checks
Load balancers can perform a variety of health checks. At a minimum, load balancers can perform certain network-level checks at different OSI layers.
A Layer 2 health check involves an Address Resolution Protocol (ARP) request used to find the MAC address for a given IP address. Since the load balancer is configured with real-server IP-address information, it sends an ARP for each real-server IP address to find the MAC address. The server will respond to the ARP request unless it’s down.
A Layer 3 health check involves a ping to the real-server IP address. A ping is the most commonly used program to see if an IP address exists in the network, and whether that host is up and running.
At Layer 4, the load balancer attempts to connect to a specific TCP or UDP port where an application is running. For example, if the VIP is bound to real servers on port 80 for Web application, the load balancer attempts to establish a connection or attempts to bind to that port. The load balancer sends a TCP SYN request to port 80 on each real server, and checks for a TCP SYN ACK in return; failing which, it marks the port 80 to be down on that server. It’s important to note that the load balancer treats each port on the server as independent. Thus, port 80 on RS1 can be down, but port 21 may be fine. In that case, the load balancer continues to utilize the server for FTP application, but marks the server down for Web application. This provides for a very efficient load balancing, granular health checks, and efficient utilization of server capacity.
Application-Specific Health Checks
Load balancers can perform Layer 7 or application-level health checks for well-known applications. There is no rule as to how extensive an application health check should be, and it does vary among the different load-balancing products. Let me just cover a few examples of what an application health check may involve.
For Web servers, the load balancer can send an HTTP GET or HTTP HEAD request for a URL of your choice to the server. You can configure the load balancer to check for the HTTP return codes so HTTP error codes such as “404 Object not found” can be detected. For DNS, the load balancer can send a DNS lookup query to resolve a user-selected domain name to an IP address, and match the results against expected results. For FTP, the load balancer can log in to an FTP server with a specific userID and password.
Application Dependency
Application Dependency
Sometimes we may want to use multiple applications that are related to each other on a real server. For example, Web servers that provide shopping-cart applications have a Web application on port 80 serving Web content and another application using Secure Socket Layer (SSL) on port 443. SSL allows the client and Web server to exchange such sensitive data as credit card information securely by encrypting the traffic for transit. A client first browses the Web site, adds some items to a virtual shopping cart, and then presses the checkout button. The browser will then transition to the SSL application, which takes credit card information to purchase the items in the shopping cart. The SSL application takes the shopping-cart information from the Web application. If the SSL application is down, the Web server must also be considered down. Otherwise, a user may add the items to the shopping cart but will be unable to access the SSL application for checkout. Many load balancers support a feature called port grouping, which allows multiple TCP or UDP ports to be grouped together. If an application running on any one port in a group fails, the load balancer will mark the entire group of applications down on a given real server. This ensures that users are directed only to those servers that have all the necessary applications running in order to complete a transaction.
Previous << 1 .. 7 8 9 10 11 12 < 13 > 14 15 16 17 18 19 .. 70 >> Next