User manual REDHAT ENTERPRISE LINUX AS 2.1 INSTALLATION GUIDE

[. . . ] Red Hat Enterprise Linux AS 2. 1 The Official Red Hat Enterprise Linux AS Installation Guide ISBN: N/A Red Hat, Inc. 1801 Varsity Drive Raleigh, NC 27606-2072 USA +1 919 754 3700 (Voice) +1 919 754 3701 (FAX) 888 733 4281 (Voice) P. O. Box 13588 Research Triangle Park, NC 27709 USA © 2002 Red Hat, Inc. 1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA rhl-ig-as-x86(EN)-2. 1-Print-RHI (2002-03-22T11:09-0400) Copyright © 2002 by Red Hat, Inc. [. . . ] Only one LVS router is active at a time. The role of the active router is to redirect service requests from virtual IP addresses to the real servers. The redirection is based on one of eight supported loadbalancing algorithms described further in Section 6. 3, LVS Scheduling Overview. 4 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 hot-standby system. Periodically, the LVS routers exchange "I'm alive" 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 message 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 6­1, A Basic LVS Configuration is best for clusters serving data which does not change very frequently -- such as static Web pages -- because the individual real servers do not automatically sync data between each node. The next section discusses approaches to replicating data across the server pool. 6. 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 better for servers which 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, the latter option is preferable. 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 104 Chapter 6:Linux Virtual Server Overview to all of the servers simultaneously. Also, the cluster administrator can use programs such as rsync to replicate changed data across all nodes at a set interval. However, this type of data synchronization does not work well if the cluster is extremely busy with users uploading files or issuing database transactions. For a cluster with a high load, a three-tiered topology is the best solution. 6. 2 A Three Tiered LVS Configuration Figure 6­2, A Three Tiered LVS Configuration shows a typical three tiered LVS cluster topology. In this example, the active LVS router routes the requests from the Internet to the pool of real servers. Each of the real servers then accesses a shared data source over the network. Figure 6­2 A Three Tiered LVS Configuration Section 6. 3:LVS Scheduling Overview 105 This configuration is ideal for busy FTP servers, where accessible data is stored on a central, highly available server and accessed by each real server via an NFS exported directory or Samba share. This topography is also great for websites that access a central, highly available database for transactions. [. . . ] 32, 35, 86 steps choosing an installation class . . . . . . . 18 hardware compatibility . . . . . . . . . . . . . . 19 Red Hat Enterprise Linux AS components . . . . 17 support, technical ( See technical support ) swap. . . [. . . ]