Table of Contents
Advertisement
Chapter 1. Red Hat Cluster Suite Overview
In typical situations, a client on the Internet sends a request to an IP address. Network routers
typically send requests to their destination by relating IP addresses to a machine's MAC
address with ARP. ARP requests are broadcast to all connected machines on a network, and
the machine with the correct IP/MAC address combination receives the packet. The IP/MAC
associations are stored in an ARP cache, which is cleared periodically (usually every 15
minutes) and refilled with IP/MAC associations.
The issue with ARP requests in a direct-routing LVS configuration is that because a client
request to an IP address must be associated with a MAC address for the request to be handled,
the virtual IP address of the LVS router must also be associated to a MAC. However, because
both the LVS router and the real servers have the same VIP, the ARP request is broadcast to all
the nodes associated with the VIP. This can cause several problems, such as the VIP being
associated directly to one of the real servers and processing requests directly, bypassing the
LVS router completely and defeating the purpose of the LVS configuration. Using an LVS router
with a powerful CPU that can respond quickly to client requests does not necessarily remedy
this issue. If the LVS router is under heavy load, it may respond to the ARP request more slowly
than an underutilized real server, which responds more quickly and is assigned the VIP in the
ARP cache of the requesting client.
To solve this issue, the incoming requests should only associate the VIP to the LVS router,
which will properly process the requests and send them to the real server pool. This can be
done by using the
packet-filtering tool.
arptables
8.4. Persistence and Firewall Marks
In certain situations, it may be desirable for a client to reconnect repeatedly to the same real
server, rather than have an LVS load-balancing algorithm send that request to the best
available server. Examples of such situations include multi-screen web forms, cookies, SSL,
and FTP connections. In those cases, a client may not work properly unless the transactions are
being handled by the same server to retain context. LVS provides two different features to
handle this: persistence and firewall marks.
8.4.1. Persistence
When enabled, persistence acts like a timer. When a client connects to a service, LVS
remembers the last connection for a specified period of time. If that same client IP address
connects again within that period, it is sent to the same server it connected to previously —
bypassing the load-balancing mechanisms. When a connection occurs outside the time window,
it is handled according to the scheduling rules in place.
Persistence also allows you to specify a subnet mask to apply to the client IP address test as a
tool for controlling what addresses have a higher level of persistence, thereby grouping
connections to that subnet.
Grouping connections destined for different ports can be important for protocols that use more
than one port to communicate, such as FTP. However, persistence is not the most efficient way
to deal with the problem of grouping together connections destined for different ports. For these
situations, it is best to use firewall marks.
36
Advertisement
Table of Contents
