User manual REDHAT LINUX VIRTUAL SERVER 5.0 ADMINISTRATION

[. . . ] Linux Virtual Server Administration 5. 0 Linux Virtual Server (LVS) for Red Hat Enterprise Linux 5. 0 ISBN: N/A Publication date: 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 and LVS. Linux Virtual Server Administration: Linux Virtual Server (LVS) for Red Hat Enterprise Linux 5. 0 Copyright © You need to override this in your local ent file Red Hat, Inc. Copyright © You need to override this in your local ent file 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. [. . . ] However, because all of the data passed to the Piranha Configuration Tool is in plain text, it is recommended that you restrict access only to trusted networks or to the local machine. The easiest way to restrict access is to use the Apache HTTP Server's built in access control mechanisms by editing /etc/sysconfig/ha/web/secure/. htaccess. 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. [. . . ] To do this, simply repeat the process described above on the backup LVS router node. After completing this final step, LVS will be up and running. 56 Appendix A. Using LVS with Red Hat Cluster You can use LVS routers with a Red Hat Cluster to deploy a high-availability e-commerce site that provides load balancing, data integrity, and application availability. The configuration in Figure A. 1, "LVS with a Red Hat Cluster" represents an e-commerce site used for online merchandise ordering through a URL. [. . . ]