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.
