3.2. Load Balancer Using Direct Routing
3.2. Load Balancer Using Direct Routing Direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well. Network Layout In a direct routing Load Balancer setup, the LVS router needs to receive incoming requests and route them to the proper real server for processing. The real servers then need to directly route the response to the client. So, for example, if the client is on the Internet, and sends the packet through the LVS router to a real server, the real server must be able to connect directly to the client through the Internet. This can be done by configuring a gateway for the real server to pass packets to the Internet. Each real server in the server pool can have its own separate gateway (and each gateway with its own connection to the Internet), allowing for maximum throughput and scalability. For typical Load Balancer setups, however, the real servers can communicate through one gateway (and therefore one network connection). Hardware The hardware requirements of a Load Balancer system using direct routing is similar to other Load Balancer topologies. While the LVS router needs to be running Red Hat Enterprise Linux to process the incoming requests and perform load-balancing for the real servers, the real servers do not need to be Linux machines to function correctly. The LVS routers need one or two NICs each (depending on if there is a backup router). You can use two NICs for ease of configuration and to distinctly separate traffic; incoming requests are handled by one NIC and routed packets to real servers on the other. Since the real servers bypass the LVS router and send outgoing packets directly to a client, a gateway to the Internet is required. For maximum performance and availability, each real server can be connected to its own separate gateway which has its own dedicated connection to the network to which the client is connected (such as the Internet or an intranet). Software There is some configuration outside of keepalived that needs to be done, especially for administrators facing ARP issues when using Load Balancer by means of direct routing. Refer to Section 3.2.1, "Direct Routing Using arptables" or Section 3.2.3, "Direct Routing Using iptables" for more information. 3.2.1. Direct Routing Using arptables In order to configure direct routing using arptables , each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs. Using the arptables method, applications may bind to each individual VIP or port that the real server is servicing. For example, the arptables method allows multiple instances of Apache HTTP Server to be running and bound explicitly to different VIPs on the system. However, using the arptables method, VIPs cannot be configured to start on boot using standard Red Hat Enterprise Linux system configuration tools. To configure each real server to ignore ARP requests for each virtual IP addresses, perform the following steps: Create the ARP table entries for each virtual IP address on each real server (the real_ip is the IP the director uses to communicate with the real server; often this is the IP bound to eth0 ): This will cause the real servers to ignore all ARP requests for the virtual IP addresses, and change any outgoing ARP responses which might otherwise contain the virtual IP so that they contain the real IP of the server instead. The only node that should respond to ARP requests for any of the VIPs is the current active LVS node. Once this has been completed on each real server, save the ARP table entries by typing the following commands on each real server: arptables-save > /etc/sysconfig/arptables systemctl enable arptables.service The systemctl enable command will cause the system to reload the arptables configuration on bootup before the network is started. Configure the virtual IP address on all real servers using ip addr to create an IP alias. For example: Configure Keepalived for Direct Routing. This can be done by adding lb_kind DR to the keepalived.conf file. Refer to Chapter 4, Initial Load Balancer Configuration with Keepalived for more information. 3.2.2. Direct Routing Using firewalld You may also work around the ARP issue using the direct routing method by creating firewall rules using firewalld . To configure direct routing using firewalld , you must add rules that create a transparent proxy so that a real server will service packets sent to the VIP address, even though the VIP address does not exist on the system. The firewalld method is simpler to configure than the arptables method. This method also circumvents the LVS ARP issue entirely, because the virtual IP address or addresses exist only on the active LVS director. However, there are performance issues using the firewalld method compared to arptables , as there is overhead in forwarding every return packet. You also cannot reuse ports using the firewalld method. For example, it is not possible to run two separate Apache HTTP Server services bound to port 80, because both must bind to INADDR_ANY instead of the virtual IP addresses. To configure direct routing using the firewalld method, perform the following steps on every real server: Ensure that firewalld is running. Ensure that firewalld is enabled to start at system start. Enter the following command for every VIP, port, and protocol (TCP or UDP) combination intended to be serviced for the real server. This command will cause the real servers to process packets destined for the VIP and port that they are given. Reload the firewall rules and keep the state information. The current permanent configuration will become the new firewalld runtime configuration as well as the configuration at the system start. 3.2.3. Direct Routing Using iptables You may also work around the ARP issue using the direct routing method by creating iptables firewall rules. To configure direct routing using iptables , you must add rules that create a transparent proxy so that a real server will service packets sent to the VIP address, even though the VIP address does not exist on the system. The iptables method is simpler to configure than the arptables method. This method also circumvents the LVS ARP issue entirely, because the virtual IP address(es) only exist on the active LVS director. However, there are performance issues using the iptables method compared to arptables , as there is overhead in forwarding/masquerading every packet. You also cannot reuse ports using the iptables method. For example, it is not possible to run two separate Apache HTTP Server services bound to port 80, because both must bind to INADDR_ANY instead of the virtual IP addresses. To configure direct routing using the iptables method, perform the following steps: On each real server, enter the following command for every VIP, port, and protocol (TCP or UDP) combination intended to be serviced for the real server: iptables -t nat -A PREROUTING -p <tcp|udp> -d <vip> --dport <port> -j REDIRECT This command will cause the real servers to process packets destined for the VIP and port that they are given. Save the configuration on each real server: The systemctl enable command will cause the system to reload the iptables configuration on bootup before the network is started. 3.2.4. Direct Routing Using sysctl Another way to deal with the ARP limitation when employing Direct Routing is using the sysctl interface. Administrators can configure two systcl settings such that the real server will not announce the VIP in ARP requests and will not reply to ARP requests for the VIP address. To enable this, enter the following commands: Alternatively, you may add the following lines to the /etc/sysctl.d/arp.conf file:
arptables -A IN -d <virtual_ip> -j DROP arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip> ip addr add 192.168.76.24 dev eth0 systemctl start firewalld systemctl enable firewalld firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 0 -d vip -p tcp|udp -m tcp|udp --dport port -j REDIRECT firewall-cmd --reload iptables-save > /etc/sysconfig/iptables systemctl enable iptables.service echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth0.arp_announce = 2