Shulou(Shulou.com)06/03 Report--

The following brings you an introduction to the analysis of the flow direction of LVS-DR data packets, hoping to give you some help in practical application. Load balancing involves many things, and there are not many theories. There are many books on the Internet. Today, we will use the accumulated experience in the industry to do an answer.

Analysis of LVS-DR packet flow

To facilitate principle analysis, Client and cluster machines are placed in the same network, and packets flow through 1-2-3-4 routes.

Client sends a request to the target VIP, and Director (load balancer) receives Director to select RealServer 1 according to the load balancing algorithm, does not modify or encapsulate the IP message, but changes the MAC address of the data frame to the MAC address of RealServer 1, and then sends it on the local area network. RealServer_ _ 1 received the frame, unencapsulated it and found the target IP and Ben. Machine matching (RealServer binds VIP beforehand), so the message is processed. The message is then re-encapsulated and sent to the local area network. Client will receive a reply message. Client thinks that you can get a normal service without knowing which CVM handles it: if you cross a network segment, then the message is returned to the user through the router via Internet. The ARP problem in LVS-DR in the LVS-DR load balancer cluster, the load balancer and the node server should be configured with the same VIP address and have the same IP address in the LAN. It is bound to cause confusion in ARP communication among servers. When an ARP broadcast is sent to a LVS-DR cluster, because the load balancer and the node server are connected to the same network, they both receive the ARP broadcast. At this time, only the front-end load balancer responds, and other node servers should not respond to the ARP broadcast. Do not respond to ARP requests for VIP and use virtual interface lo:0 bearer VIP address to set kernel parameter arp_ ignore=1: the system only responds to the destination IP for local IP ARP request RealServer return message (the source IP is VIP) is forwarded by the router. When re-encapsulating the message, when you first need to obtain the router's MAC address to send the ARP request, Linux defaults to use the source IP address (i.e. VIP) of the IP packet as the source IP address in the ARP request packet On the other hand, when the IP address router that does not use the sending interface (such as ens33) receives the ARP request, it will update the ARP entry. The original VIP corresponding Director MAC address will be updated to the VIP corresponding RealServer MAC address at this time the new request message. According to the ARP entry, the router will The message will be forwarded to RealServer, resulting in the VIP failure of Director. The setting method for solving two problems of ARP is modified. / etc/sysctl.conf file net.ipv4.conf.lo.arp_ignore = 1net.ipv4.conf.lo.arp_announce = 2net.ipv4.conf.all.arp_ignore = 1net.ipv4.conf.all.arp_announce = 2Keepalived in enterprise applications, a single server bears the risk of a single point of failure, in enterprise application clusters. There are at least two single point failure risks. Once a single point failure occurs, the enterprise service will be interrupted, causing great harm.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.