A Three Tiered Lvs Configuration - Red Hat CLUSTER SUITE - CONFIGURING AND MANAGING A CLUSTER 2006 Manual

Chapter 7. Linux Virtual Server Overview
The active router also 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, the administrator can also call external
executables. If a service on a real server malfunctions, the active router stops sending jobs
to that server until it returns to normal operation.
The backup router performs the role of a standby system. Periodically, the LVS routers ex-
change heartbeat messages through the primary external public interface and, in a failover
situation, the private interface. Should the backup node fail to receive a heartbeat mes-
sage 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 addresses serviced by the
failed router using a technique known as ARP spoofing — where the backup LVS router
announces itself as the destination for IP packets addressed to the failed node. When the
failed node returns to active service, the backup node assumes its hot-backup role again.
The simple, two-layered configuration used in Figure 7-1 is best for clusters serving data
which does not change very frequently — such as static webpages — because the individ-
ual real servers do not automatically sync data between each node.
7.1.1. Data Replication and Data Sharing Between Real Servers
Since there is no built-in component in LVS clustering to share the same data between the
real servers, the administrator has two basic options:
Synchronize the data across the real server pool
•
Add a third layer to the topology for shared data access
•
The first option is preferred for servers that do not allow large numbers of users to upload
or change data on the real servers. If the cluster allows large numbers of users to modify
data, such as an e-commerce website, adding a third layer is preferable.
7.1.1.1. Configuring Real Servers to Synchronize Data
There are many ways an administrator can choose to synchronize data across the pool of
real servers. For instance, shell scripts can be employed so that if a Web engineer updates a
page, the page is posted to all of the servers simultaneously. Also, the cluster administrator
can use programs such as
However, this type of data synchronization does not optimally function if the cluster is
overloaded with users constantly uploading files or issuing database transactions. For a
cluster with a high load, a three-tiered topology is the ideal solution.
to replicate changed data across all nodes at a set interval.
rsync
87