Red Hat CLUSTER SUITE - FOR RHEL 4 Overview page 36

26
Weighted Round-Robin Scheduling — Distributes each request sequentially around a
•
pool of real servers but gives more jobs to servers with greater capacity. Capacity is in-
dicated by a user-assigned weight factor, which is then adjusted up or down by dynamic
load information. This is a preferred choice if there are significant differences in the ca-
pacity of real servers in a server pool. However, if the request load varies dramatically,
a more heavily weighted server may answer more than its share of requests.
Least-Connection — Distributes more requests to real servers with fewer active connec-
•
tions. This 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 server node has roughly the same capacity. If the real servers have varying
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 up or down by dynamic load information. The addition
of weighting makes this algorithm ideal when the real server pool contains hardware of
varying capacity.
Locality-Based Least-Connection Scheduling — Distributes more requests to servers
•
with fewer active connections relative to their destination IPs. This algorithm is 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 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.
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 for LVS routers with multiple
firewalls.
Also, the active LVS router dynamically monitors the overall health of the specific services
on the real servers through simple send/expect scripts. To aid in detecting the health of
services that require dynamic data, such as HTTPS or SSL, you can also call external
executables. If a service on a real server malfunctions, the active LVS router stops sending
jobs to that server until it returns to normal operation.
The backup LVS router performs the role of a standby system. Periodically, the LVS
routers exchange heartbeat messages through the primary external public interface and,
in a failover situation, the private interface. Should the backup LVS router fail to receive a
heartbeat message within an expected interval, it initiates a failover and assumes the role
Chapter 1. Red Hat Cluster Suite Overview