| Red Hat Docs > Manuals > Red Hat High Availability Server Manuals > |
|
A Linux Virtual Server (LVS) cluster is a collection of servers that have been specially configured to provide highly-available services. The diagram below illustrates how an LVS cluster works.
An LVS cluster consists of one or two router nodes (top of figure) and a variable number of application servers (bottom). We will refer to the LVS router nodes as LVS routers, and to the pool of application servers as real servers. Note that these terms designate roles rather than machines. For example, the LVS routers shown in Figure 8-1 might be configured to perform both LVS router and real server roles.
Service requests arriving at an LVS cluster are addressed to a virtual server IP address (sometimes refered to as a VIP address). This is a publicly-advertised address that an administrator at the site associates with a fully-qualified domain name (for example, lvs.ajax.com). The illustration shows only one virtual server address, but there may be more than one. The important thing to remember is that a VIP address will migrate from one LVS router to the other during a failover, thus maintaining a presence at that IP address. As such, they can be considered floating addresses. VIP addresses may be aliased to the device (for example, eth0:1) that connects the LVS routers to the public network, or each could be associated with a separate device.
Only one LVS router is active at a time. The role of the active router is to redirect service requests from a virtual server address to the real servers. The redirection is based on one of four supported load-balancing algorithms (described in Table 8-1). The active router dynamically monitors the health of the real servers, and the workload on each, via one of three supported methods (described in Table 8-2). If a real server becomes disabled, the active router stops sending jobs to that server until it returns to normal operation.
The backup router performs the role of a standy system . Periodically, the LVS routers exchange "I'm alive" heartbeat messages. Should the backup node fail to receive a heartbeat message within an expected interval, it initiates a failover and assumes the role of the active router. During failover, the backup router takes over the VIP address(es) serviced by the failed router and uses a technique known as ARP spoofing — It starts announcing itself as the destination for IP packets addressed to the failed node. When the failed node returns to service, it assumes the hot backup role.
Three routing methods are supported:
Network Address Translation (NAT)
IP encapsulation (tunneling)
Direct routing
Each LVS router is configured to use a single routing method. If you set up multiple LVS clusters, you can use different routing methods for each cluster.
The diagram below illustrates NAT routing works.
The NAT router IP address is the default route used by each real server on the private network to communicate with the active router. Like the virtual server address, it is also a floating IP address. The NAT router address may be aliased to the device (for example, eth1:1) connecting the LVS routers to the network of real servers, or associated with a separate device on each router.
Also like virtual server addresses, NAT addresses are enabled only on the active router. Therefore, should the active router fail, the backup router enables the virtual server and NAT addresses during take-over of the floating IP addresses. In the topology shown in Figure 8-2, virtual server addresses are enabled on device eth0 and the NAT router address on eth1.
As a real server processes a request, it returns packets to the active router, where the address of the real server in the packets is replaced by the virtual server address. In this manner, the private network of real servers is masqueraded from the requesting clients.
NAT routing is easy to set up and flexible. The real servers may be any kind of machine running any operating system or Web server, or any combination. The chief disadvantage is that, after about twenty real servers, the LVS router may become a bottleneck because it must process outgoing as well as incoming requests.
Figure 8-3 illustrates how a tunneling virtual server works. With this method, IP encapsulation is enabled on the real servers. Prior to assigning a job to a real server, the active router encapsulates the IP address of the requesting client inside the real server's address.
When a real server has processed a job, it returns the response directly to the requesting client rather than to the active router. Thus, the active router processes incoming requests only. An additional advantage of tunneling is that the real servers may be geographically distributed. (While IP encapsulation using non-Linux real servers may be possible, only Linux real servers have been tested in this configuration.)
Figure 8-4 illustrates direct routing. With this method, the LVS routers and real servers exist on the same LAN segment. After selecting the real server for a job, the active router changes the address of the request to that of the real server.
When a real server has processed a job, it returns the response directly to the requesting client rather than to the active router. This method avoids the (admittedly slight) overhead of tunneling.
Figure 8-5 suggests how multiple clusters could be deployed in combination with DNS round robin to satisfy the needs of the busiest sites. In this scenario, a DNS server resolves service requests to multiple virtual server addresses, which a router distributes equally among multiple LVS routers. These routers, in turn, distribute requests to a shared bank of real servers.
Regardless of the routing method, the IPVS table in the active router's kernel redirects requests from a virtual server address to a real server. For example, a TCP request addressed to port 80 on virtual server 1.2.3.1 might be routed to port 80 on real server 192.168.1.2. The actual mapping of jobs to real servers in the IPVS table is based on the load-balancing algorithm in use. Table 8-1 describes the supported load-balancing methods.
Table 8-1. Load-balancing Methods
| Name | Description |
|---|---|
| Round robin | Distribute jobs equally among the real servers. |
| Least-connections | Distribute more jobs to real servers with fewer active connections. (The IPVS table stores active connections.) |
| Weighted round robin | Distribute more jobs to servers with greater capacity. Capacity is indicated by a user-assigned weight, which is then adjusted upward or downward by dynamic load information. |
| Weighted least-connections | Distribute more jobs to servers with fewer active connections relative to their capacity. Capacity is indicated by a user-assigned weight, which is then adjusted upward or downward by dynamic load information. |
