Chapter 8. Setting Up a Red Hat Enterprise Linux AS LVS Cluster
A Red Hat Enterprise Linux AS LVS cluster consists of two basic groups: the LVS routers and the real servers. To prevent a single point of failure, each groups should contain at least two member systems.
The LVS router group should consist of two identical or very similar systems running Red Hat Enterprise Linux AS. One will act as the active LVS router while the other stays in hot standby mode, so they need to have as close to the same capabilities as possible.
Before choosing and configuring the hardware for the real server group, you most decide what which of the three types of LVS topographies to use.
The NAT LVS Cluster
The NAT topography allows for great latitude in utilizing existing hardware, but it is limited in its ability to handle large loads due to the fact that all packets going into and coming out of the cluster pass through the LVS router.
- Network Layout
The topography for an LVS cluster utilizing NAT routing is the easiest to configure from a network layout perspective because the cluster needs only one access point to the public network. The real servers pass all requests back through the LVS router so they are on their own private network.
- Hardware
The NAT topography is the most flexible in regards to cluster hardware because the real servers do not need to be Linux machines to function correctly in the cluster. In a NAT cluster, each real server only needs one NIC since it will only be responding to the LVS router. The LVS routers, on the other hand, need two NICs each to route traffic between the two networks. Because this topography creates a network bottleneck at the LVS router, gigabit Ethernet NICs can be employed on each LVS router to increase the bandwidth the LVS routers can handle. If gigabit Ethernet is employed on the LVS routers, any switch connecting the real servers to the LVS routers must have at least two gigabit Ethernet ports to handle the load efficiently.
- Software
Because the NAT topography requires the use of iptables or ipchains for some configurations, there can be a fair amount of software configuration outside of Piranha Configuration Tool. In particular, FTP services and the use of firewall marks requires extra manual configuration of the LVS routers to route requests properly.
Putting the Cluster Together
After determining which of the above routing methods to use, the hardware for the LVS cluster should be linked together on the network.
 | Important |
|---|---|
The adapter devices on the LVS routers must be configured to access the same networks. For instance if eth0 connects to public network and eth1 connects to the private network, then these same devices on the backup LVS router must connect to the same networks. Also the gateway listed in the first interface to come up at boot time is added to the routing table and subsequent gateways listed in other interfaces are ignored. This is especially important to consider when configuring the real servers. |
After physically connecting together the cluster hardware, configure the network interfaces on the primary and backup LVS routers. This can be done using a graphical application such as redhat-config-network or by editing the network scripts manually. For more information about adding devices using redhat-config-network, see the chapter titled Network Configuration in the Official Red Hat Linux Customization Guide. For more information on editing network scripts by hand, see the chapter titled Network Scripts in the Official Red Hat Linux Reference Guide. For the remainder of the chapter, example alterations to network interfaces are made either manually or through the Piranha Configuration Tool.
General LVS Networking Tips
Configure the real IP addresses for both the public and private networks on the LVS routers before attempting to configure the cluster using the Piranha Configuration Tool. The sections on each topography give example network addresses, but the actual network addresses are needed. Below are some useful commands for bringing up network interfaces or checking their status.
- Bringing Up Real Network Interfaces
The best way to bring up any real network interface is to use the following commands as root replacing N with the number corresponding to the interface (eth0 and eth1):
/sbin/ifup ethN
Warning Do not use the ifup scripts to bring up any floating IP addresses you may configure using Piranha Configuration Tool (eth0:1 or eth1:1). Use the service command to start pulse instead (see the Section called Starting the Cluster in Chapter 9 for details).
To bring a network interface down, simply type:
/sbin/ifdown ethN
Again, replace N in the above command with the number corresponding to the interface you wish to bring down.
- Checking the Status of Network Interfaces
If you need to check which network interfaces are up at any given time, type:
/sbin/ifconfig
To view the routing table for a machine, issue the following command:
/sbin/route