One of the advantages of using an LVS cluster is its ability to perform
flexible, IP-level load balancing on the real server pool. This
flexibility is due to the variety of scheduling algorithms an
administrator can choose from when configuring a cluster. LVS load
balancing is superior to less flexible methods, such as
Round-Robin DNS where the hierarchical nature of
DNS and the caching by client machines can lead to load
imbalances. Additionally, the low-level filtering employed by the LVS
router has advantages over application-level request forwarding because
balancing loads at the network packet level causes minimal computational
overhead and allows for greater scalability.
Using scheduling, the active router can take into account the real
servers' activity and, optionally, an administrator-assigned
weight factor when routing service
requests. Using assigned weights gives arbitrary priorities to
individual machines. Using this form of scheduling, it is possible to
create a group of real servers using a variety of hardware and software
combinations and the active router can evenly load each real server.
The scheduling mechanism for an LVS cluster is provided by a collection
of kernel patches called IP Virtual Server or
IPVS modules. These modules enable
layer 4 (L4) transport
layer switching, which is designed to work well with multiple servers on
a single IP address.
To track and route packets to the real servers efficiently, IPVS builds
an IPVS table in the kernel. This table is used
by the active LVS router to redirect requests from a virtual server
address to and returning from real servers in the pool. The IPVS table
is constantly updated by a utility called ipvsadm
— adding and removing cluster members depending on their
availability.
The structure that the IPVS table takes depends on the scheduling
algorithm that the administrator chooses for any given virtual
server. To allow for maximum flexibility in the types of services you
can cluster and how these services are scheduled, Red Hat Enterprise Linux provides the
following scheduling algorithms listed below. For instructions on how
to assign scheduling algorithms refer to Section 10.6.1 The VIRTUAL SERVER Subsection.
- Round-Robin Scheduling
Distributes each request sequentially around the pool of
real servers. Using this algorithm, all the real servers are
treated as equals without regard to capacity or load. This
scheduling model resembles round-robin DNS but is more granular
due to the fact that it is network-connection based and not
host-based. LVS round-robin scheduling also does not suffer the
imbalances caused by cached DNS queries.
- Weighted Round-Robin Scheduling
Distributes each request sequentially around the pool of
real servers but gives more jobs to servers with greater
capacity. Capacity is indicated by a user-assigned weight
factor, which is then adjusted upward or downward by dynamic
load information. Refer to Section 7.3.2 Server Weight and Scheduling
for more on weighting real servers.
Weighted round-robin scheduling is a preferred choice if
there are significant differences in the capacity of real
servers in the pool. However, if the request load varies
dramatically, the more heavily weighted server may answer more
than its share of requests.
- Least-Connection
Distributes more requests to real servers with fewer active
connections. Because it keeps track of live connections to the
real servers through the IPVS table, least-connection is a type
of dynamic scheduling algorithm, making it a better choice if
there is a high degree of variation in the request load. It is
best suited for a real server pool where each member node has
roughly the same capacity. If a group of servers have different
capabilities, weighted least-connection scheduling is a better
choice.
- Weighted Least-Connections
(default)
Distributes more requests to servers with fewer active
connections relative to their capacities. Capacity is indicated
by a user-assigned weight, which is then adjusted upward or
downward by dynamic load information. The addition of weighting
makes this algorithm ideal when the real server pool contains
hardware of varying capacity. Refer to Section 7.3.2 Server Weight and Scheduling for more on weighting real
servers.
- Locality-Based Least-Connection Scheduling
Distributes more requests to servers with fewer active
connections relative to their destination IPs. This algorithm is
designed for use in a proxy-cache server cluster. It routes the
packets for an IP address to the server for that address unless
that server is above its capacity and has a server in its half
load, in which case it assigns the IP address to the least
loaded real server.
- Locality-Based Least-Connection Scheduling with
Replication Scheduling
Distributes more requests to servers with fewer active
connections relative to their destination IPs. This algorithm is
also designed for use in a proxy-cache server cluster. It
differs from Locality-Based Least-Connection Scheduling by
mapping the target IP address to a subset of real server
nodes. Requests are then routed to the server in this subset
with the lowest number of connections. If all the nodes for the
destination IP are above capacity, it replicates a new server
for that destination IP address by adding the real server with
the least connections from the overall pool of real servers to
the subset of real servers for that destination IP. The most
loaded node is then dropped from the real server subset to
prevent over-replication.
- Destination Hash Scheduling
Distributes requests to the pool of real servers by looking
up the destination IP in a static hash table. This algorithm is
designed for use in a proxy-cache server cluster.
- Source Hash Scheduling
Distributes requests to the pool of real servers by
looking up the source IP in a static hash table. This algorithm is
designed for LVS routers with multiple firewalls.
The administrator of an LVS cluster can assign a
weight to each node in the real server
pool. This weight is an integer value which is factored into any
weight-aware scheduling algorithms (such as
weighted least-connections) and helps the LVS router more evenly load
hardware with different capabilities.
Weights work as a ratio relative to one another. For instance, if one
real server has a weight of 1 and the other server has a weight of 5,
then the server with a weight of 5 gets 5 connections for every 1
connection the other server gets. The default value for a real server
weight is 1.
Although adding weight to varying hardware configurations in a real
server pool can help load-balance the cluster more efficiently, it can
cause temporary imbalances when a real server is introduced to the
real server pool and the virtual server is scheduled using weighted
least-connections. For example, suppose there are three servers in the
real server pool. Servers A and B are weighted at 1 and the third,
server C, is weighted at 2. If server C goes down for any reason,
servers A and B evenly distributes the abandoned load. However, once
server C comes back online, the LVS router sees it has zero
connections and floods the server with all incoming requests until it
is on par with servers A and B.
To prevent this phenomenon, administrators can make the virtual server
a quiesce server — anytime a new real
server node comes online, the least-connections table is reset to zero
and the LVS router routes requests as if all the real servers were
newly added to the cluster.
