Load balancing of Linux cluster services

Load Balancing cluster (LB)

How load Balancing clusters work

When a user sends a request, the request is not immediately sent to the backend's real server (realservers), but is sent first to the Scheduler or Distributor (Director), and then the director, based on some scheduling algorithm, The request is sent to the backend real server (realservers). After the server processes the request, it responds directly to the client.

Load Balancing Devices

The scheduler or distributor just mentioned is a load balancing device that has hardware and software points:

Common hardware load balancing devices:

1. F5 Big-IP

2. Citrix Netscale

3, A10

Common software load-balancing devices:

Four-tiered load balancing devices:

LVS: Full name Linux Virtual Server,lvs is a Linux kernel-based load balancing technology created by Dr. Zhangwensong of the research and engineering. LVS is compatible with most current network services, features high availability and scalability, and is easy to manage. LVS is widely used.

Seven-layer load balancing device:

Nginx, Haproxy. Typically used in reverse proxy functions

Since LVS is widely used in the open source world, this paper mainly uses the LVS load balancer device to achieve load balancing function.

There are three ways of implementing LVS clusters:

One, network address translation (NAT), its working model is as follows:

650) this.width=650; "title=" Nat.png "alt=" wkiol1sdbtzqexg7aah0rvnthxy886.jpg "src=" http://s3.51cto.com/wyfs02/M00 /54/74/wkiol1sdbtzqexg7aah0rvnthxy886.jpg "/>

This approach works very similar to how Dnat works. First, when a client sends a message request to the Scheduler Director, the Scheduler director selects a real server from a group of real servers according to the connection scheduling algorithm, and changes the target IP of the message from VIP to rip, the target port of the message, Change to the destination port of the server. When the back end of the real server response message, the source IP of its message from RIP to VIP, the source port of its message is also changed to the corresponding port. Finally, the dispatcher director returns the response message to the client. The whole process for the user, only know the dispatcher external VIP, the back end of the real server address is not known, therefore, for the user, the entire cluster system is transparent.

The flow of data messages in this mode is:

Cip→vip→dip→rip→dip→vip→cip

The ability to implement clustering based on NAT has the following features:

1. The cluster node must be in the same IP network as the director

2, RIP is usually a private IP, for the communication between the cluster nodes

3. Director is located between the client and the real server, responsible for all communications processed in and out

4. Real server must point the gateway to the dip

5. Support Port Mapping

6. Real server can use any OS

7, in a large-scale scene, because the director handles all communications, the load pressure is large, therefore, director easily become a system bottleneck.

Second, direct Route Dr

This approach is the most extensive way to implement the LVS load Balancing cluster, and its working model is as follows:

650) this.width=650; "title=" Dr.png "src=" http://s3.51cto.com/wyfs02/M00/54/75/wKioL1SDLF7yKwtsAAEz2g4-FFE321.jpg "alt=" Wkiol1sdlf7ykwtsaaez2g4-ffe321.jpg "/>

It works as follows: First the client sends the request will reach the Scheduler Director, the director according to the load capacity of each server, dynamically select a real server to respond to the backend, the scheduler neither modify the message IP, nor encapsulate IP, but modify the destination MAC address of the message, and the MAC address of the server you just selected as the destination MAC address, and then transfer it in the LAN. Therefore, each server node and director must be in the same physical network segment. When the real server in the backend responds to a message request, it responds directly to the client by using the server's hidden VIP as the source Ip,cip as the destination IP. Therefore, each server on the backend has a VIP, this VIP does not accept any requests, only in response to the message, as the source IP response to the client.

The flow of data messages in this mode is:

Cip→vip→rip→cip

Clusters implemented in this way have the following characteristics:

1. Each server node and director must be in the same physical network segment

2, RIP can be a public address, can be convenient remote management and monitoring

3, Director is only responsible for processing inbound request messages, response messages are returned directly to the client by real server

4. Real server cannot point the network segment to dip

5. Port mappings are not supported

Third, Tun,ip tunnel mode

Cluster that implements this way, each server must be in a different network segment

The working model is as follows:

650) this.width=650; "title=" Tun.png "src=" http://s3.51cto.com/wyfs02/M00/54/77/ Wkiom1sdk-hb4aheaae9eve2mrk009.jpg "alt=" Wkiom1sdk-hb4aheaae9eve2mrk009.jpg "/>

It works: First, the client sends a request to the Scheduler Director, and the scheduler dynamically chooses a backend server to respond. The scheduler then dynamically establishes the tunnel with the server (not static), and at this point the scheduler will reseal the message request (that is, there are 2 IP headers). When the server receives the request, the outer package is removed and the message responds, and the response message is returned directly to the client by the real server. The source IP is the VIP when responding, and the target IP is CIP. Therefore, there must be a hidden VIP on each server at this time.

The flow of data messages in this mode is:

Cip→vip→rip→cip

Clusters implemented in this way have the following characteristics:

1. Cluster nodes can cross the Internet

2, RIP must be a public network IP

3, the Director is only responsible for processing inbound request messages, response messages from real server directly back to the client

4. Real server cannot point the gateway to the dip

5, only the tunnel-enabled OS can be used as real server

6. Port mappings are not supported

Scheduling algorithm

Each of the above implementation of the cluster function, request messages are sent to the Scheduler director, then the scheduler is based on what conditions to select the corresponding backend real server to respond to the request message? This is based on the scheduling algorithm chosen by the dispatcher director.

A total of 10 scheduling algorithms. There are 4 kinds of static scheduling algorithms, and there are 6 kinds of dynamic scheduling algorithms.

4 types of static scheduling algorithms:

1. Cyclic dispatch: Round-robin scheduling, abbreviation RR

This scheduling algorithm is to send the request message in sequence to the backend real server for processing. This scheduling model is similar to cyclic DNS, but it is more coarse because it is network-attached rather than host-based.

2, weighted cyclic scheduling: Weight round-robin scheduling, abbreviated WRR

This scheduling algorithm also sends requests in sequence to the backend's real server for response processing. However, the response ability of each server is determined by the proportion of the weight, the greater the weight, the stronger the processing message capacity. Scenarios that apply to the processing power of individual cluster nodes.

3, Source hash Dispatch: Sources hash scheduling, referred to as SH

4, the Target hash dispatch: Destination hash scheduling, referred to as DH

6 Kinds of dynamic scheduling algorithms:

1. Minimum connection: least-connection, abbreviation LC

This scheduling algorithm is based on the number of active connections in the server, the smaller the number of active connections (active) server, the server responds. The rule of calculation is active*256+inactive. The scheduling algorithm is suitable for the processing ability of each cluster node.

2. Weighted least connection method: Weight Least-connections, referred to as WLC

This scheduling algorithm is based on the number of connections to the server and their weights to decide to send the request to that server to respond. The calculation rule is (active*256+inactive)/256, which server has the lowest value, then the server responds.

3, based on the region's least connection scheduling: Locally-base leaset-connection scheduling, referred to as LBLC

4. The least region-based connection scheduling with replication schedule: locally-base leaset-connection scheduling with Replication scheduling, abbreviation LBLCR

5, the shortest expected delay: Shortest expected delay scheduling, referred to as SED

6. Minimum queue scheduling: Never queue scheduling, abbreviated NQ

This article is from the "Linux Learning path" blog, so be sure to keep this source http://xslwahaha.blog.51cto.com/4738972/1587182

Load balancing of Linux cluster services