Implement LVS Load Balancing (NAT) and vmwarelvs on VMware

Implement LVS Load Balancing (NAT) and vmwarelvs on VMware

The implementation of LVS in this article adopts the NAT mode. For the NAT topology, refer to my previous article. This article is purely an experiment. NAT is not recommended in the production environment, the reason is that Load Balancer is prone to bottlenecks!

1. Install CentOS-6.5-x86_64-minimal on VMware9

2. After the installation is complete, set its hostname to LVS-master.

hostname LVS-mastersudo -i

3. copy the two VM files to RS1 and RS2.

All three virtual machines adopt a bridging network. The biggest advantage is that they can directly access each other using real routes in the same LAN. You do not need to configure two NICs on The LVS-master. You only need to configure one more virtual IP address.

4. Configure on LVS-master:

modprobe -l |grep ipvs

If you see the result, you can continue.

Install ipvsadm

yum -y install ipvsadm

Enable nginx

service nignx startchkconfig nginx on

Configure VIP 192.168.83.198 to provide http services externally

ifconfig eth0:0 192.168.83.198 netmask 255.255.255.255 broadcast 192.168.83.230

Enable IP Forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

Configure virtual services

ipvsadm -A -t 192.168.20.87:80 -s wlc

Add a real server1 instance

ipvsadm -a -t 192.168.83.198:80 -r 192.168.83.87 -g

Add a real server2 instance

ipvsadm -a -t 192.168.83198:80 -r 192.168.83.88 -g

Finally, write the above five scripts on/etc/rc. local to enable the machine to run automatically.

5. Configure on RS1

Add the following four sentences to the end of the/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 = 2

The above indicates disabling ARP

ifconfig lo:0 192.168.83.198 netmask 255.255.255.255 broadcast 192.168.83.198 up

Add route

route add -host 192.168.83.198 dev lo:0

Enable nginx Service

Service nginx start

Index.html

echo ' the response is from Real server1' > /var/www/html/index.html

6. The configuration on RS2 is the same as that on RS1.

7. Final Test

The response is from Real server1 or the response is from Real server2 ~

That's it!

In LVS Server Load balancer, if the host goes down, the backup server cannot take over the virtual IP address. Why?

LVS Server Load balancer publishes virtual IP addresses through the host and performs NAT translation on the backend server. Therefore, when the master server is down, the backup server cannot provide services!
This is different from dual-host Hot Standby. After the active device is down, the virtual IP address can be moved to the standby device, but the load balancing is different. All traffic is sent to the active device, the target traffic address of the master device is then NAT to the actual address of other servers, so that the traffic is delivered to other servers for processing. Therefore, after the master server is down, all Server Load balancer instances will become invalid.
If you have money, we recommend that you purchase professional Server Load balancer devices, such as radware or F5.

LVS Load Balancing

The advantages of the three mechanisms, as well as the four configuration methods and architecture methods of these mechanisms.

Advantages and disadvantages of the three forwarding mechanisms

◆ Virtual Server via NAT
The advantage of VS/NAT is that the server can run any operating system that supports TCP/IP. It only needs an IP address configured on The LVS host, and the server group can use a private IP address. The disadvantage is that it has limited scalability. When the number of server nodes increases to 20, The LVS host itself may become a new bottleneck of the system, in VS/NAT, request and response packets must be balanced by the load balancing LVS host. The average latency of rewrite packets measured on the Pentium 166 host is 60us. Assuming that the average length of TCP packets is 536 Bytes, the maximum throughput of the LVS host is 8.93 MBytes/s. Assuming that the throughput of each server is 600 KBytes/s, such an LVS host can drive 16 servers.
◆ Virtual Server via IP Tunneling
In the VS/TUN cluster system, the Server Load balancer LVS host only distributes requests to different actual servers. The actual server directly returns the response information to the user. In this way, the Server Load balancer LVS host can process massive requests without becoming a system bottleneck. Even if the server Load balancer LVS host only has Mbps full-duplex NICs, the maximum throughput of the virtual server can reach several Gbps. Therefore, VS/TUN can greatly increase the number of servers allocated by the Server Load balancer LVS host, which can be used to build high-performance super servers. VS/TUN technology requires that all servers support the "IP Tunneling" or "IP Encapsulation" protocol. Currently, VS/TUN backend servers mainly run Linux operating systems. Because "IP Tunneling" is becoming a standard protocol for various operating systems, VS/TUN is also applicable to backend servers running other operating systems.
◆ Virtual Server via Direct Routing
Like VS/TUN, The VS/DRLVS host only processes the connection from the customer to the server, and the response data can be directly returned to the customer from an independent network route. This greatly improves the scalability of the LVS cluster system. Compared with VS/TUN, this method has no overhead of IP tunnel, but requires that the Server Load balancer LVS host and the actual server have a network card connected to the same physical network segment, the server network device or device alias does not respond to ARP.

Load-balancing Methods)

Different allocation methods build LVS hosts into four different Scheduling Methods
The load balancing schedule is in the unit of connection. In HTTP (nowait), a TCP connection is required for each object obtained from the WEB server. Different requests of the same user are allocated to different servers, therefore, the distribution of such connections completely avoids load imbalance caused by sudden user connections. There are currently four scheduling algorithms:
Round-Robin Scheduling (RRS)
The scheduling algorithm in turn assumes that all servers have the same processing performance and distribute requests to different servers in sequence. The algorithm is simple, but it is not applicable to scenarios where the processing performance in server groups is inconsistent.
Weighted Round Robin route Weighted Round-Robin Scheduling (WRRS)
Therefore, the weighted round-robin scheduling algorithm is used to indicate the server's processing performance with the corresponding weighted value, and the number of requests is allocated to each server in proportion to the weighted value. Servers with high weights receive connections first. servers with high weights process more connections than servers with lower weights. servers with the same weights process the same number of connections.
Minimum number of connections (LCS)
The minimum number of connections is to record the number of TCP connections that have been established on each server.