User manual REDHAT LINUX VIRTUAL SERVER 4.7 ADMINISTRATION

[. . . ] Linux Virtual Server Administration Linux Virtual Server (LVS) for Red Hat Enterprise Linux 4. 7 Virtual_Server_Administration ISBN: N/A Publication date: July 2008 Linux Virtual Server Administration Building a Linux Virtual Server (LVS) system offers highly-available and scalable solution for production services using specialized routing and load-balancing techniques configured through the PIRANHA. This book discusses the configuration of high-performance systems and services with Red Hat Enterprise Linux 4. 7 and LVS. Linux Virtual Server Administration: Linux Virtual Server (LVS) for Red Hat Enterprise Linux Copyright © 2008 Red Hat, Inc. Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1. 0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www. opencontent. org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. [. . . ] After altering the file you do not have to restart the piranha-gui service because the server checks the . htaccess file each time it accesses the directory. By default, the access controls for this directory allow anyone to view the contents of the directory. Here is what the default access looks like: Order deny, allow Allow from all To limit access of the Piranha Configuration Tool to only the localhost change the . htaccess file to allow access from only the loopback device (127. 0. 0. 1). For more information on the loopback device, see the chapter titled Network Scripts in the Red Hat Enterprise Linux Reference Guide. Order deny, allow Deny from all Allow from 127. 0. 0. 1 You can also allow specific hosts or subnets as seen in this example: Order deny, allow Deny from all Allow from 192. 168. 1. 100 Allow from 172. 16. 57 In this example, only Web browsers from the machine with the IP address of 192. 168. 1. 100 and machines on the 172. 16. 57/24 network can access the Piranha Configuration Tool. Caution Editing the Piranha Configuration Tool. htaccess file limits access to the 20 Web Server Port configuration pages in the /etc/sysconfig/ha/web/secure/ directory but not to the login and the help pages in /etc/sysconfig/ha/web/. To limit access to this directory, create a . htaccess file in the /etc/sysconfig/ha/web/ directory with order, allow, and deny lines identical to /etc/sysconfig/ha/web/secure/. htaccess. 5. Turning on Packet Forwarding In order for the LVS router to forward network packets properly to the real servers, each LVS router node must have IP forwarding turned on in the kernel. Log in as root and change the line which reads net. ipv4. ip_forward = 0 in /etc/sysctl. conf to the following: net. ipv4. ip_forward = 1 The changes take effect when you reboot the system. To check if IP forwarding is turned on, issue the following command as root: /sbin/sysctl net. ipv4. ip_forward If the above command returns a 1, then IP forwarding is enabled. If it returns a 0, then you can turn it on manually using the following command: /sbin/sysctl -w net. ipv4. ip_forward=1 6. Configuring Services on the Real Servers If the real servers are Red Hat Enterprise Linux systems, set the appropriate server daemons to activate at boot time. These daemons can include httpd for Web services or xinetd for FTP or Telnet services. It may also be useful to access the real servers remotely, so the sshd daemon should also be installed and running. 21 22 Chapter 3. Setting Up LVS LVS 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. 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, determine which of the three LVS topologies to use. 1. The NAT LVS Network The NAT topology allows for great latitude in utilizing existing hardware, but it is limited in its ability to handle large loads because all packets going into and coming out of the pool pass through the LVS router. Network Layout The topology for LVS using NAT routing is the easiest to configure from a network layout perspective because only one access point to the public network is needed. The real servers pass all requests back through the LVS router so they are on their own private network. Hardware The NAT topology is the most flexible in regards to hardware because the real servers do not need to be Linux machines to function correctly. In a NAT topology, 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. [. . . ] In one terminal, watch the kernel log messages with the command: tail -f /var/log/messages Then start LVS by typing the following command into the other terminal: /sbin/service pulse start Follow the progress of the pulse service's startup in the terminal with the kernel log messages. When you see the following output, the pulse daemon has started properly: gratuitous lvs arps finished To stop watching /var/log/messages, type Ctrl-c. From this point on, the primary LVS router is also the active LVS router. Configuring the LVS Routers with Piranha Configuration Tool requests to LVS at this point, you should start the backup LVS router before putting LVS into service. [. . . ]