The working model and scheduling algorithm of LVS

Lvs:linux Virtual Server Port-based high concurrency load balancer

Working with TCP layer, software implementation method

How it works: When a packet is prerouting into the input chain, if the request is a service defined as a Cluster service, LVS is forwarded back to the postrouting chain by forcing a change in the packet's direction to the prerouting-> Forward->postrouting back to the client

For load-balanced clusters, an important point of concern:

1. How the implementation of scheduling works

2. Scheduling algorithm

3. Back-end health status monitoring

LVS Pros and Cons:

Pros: Because work in kernel space, based on the NetFilter framework, it is not limited by the number of socket file handles, can support up to millions of concurrent

Disadvantage: The Cluster service can only be defined based on the port, and is powerless for scheduling based on the seven layer protocol

Working model of LVS:

By forcing the packet from the input chain to the postrouting chain to complete the back-end forwarding, several working models of LVS are derived from the way in which the operation is done:

Lvs-nat:

Multi-Objective Dnat

How it works: Modify the destination IP address of the packet to dispatch the IP address of a realserver on the back end

Characteristics:

Packet inflow and outflow are routed through the director

Support Port Mappings

Back-end realserver need to point to Director for its gateway

Back-end Realserver with the director's dip required on the same IP network

LVS-DR:

Direct routing (default type)

How it works: forwards packets to the backend by modifying the MAC address

Characteristics:

Data packets are directed to the director and returned directly from the Realserver

Port mappings are not supported

Dip needs to be on the same physical network as the rip on the backend realserver, as it communicates directly through the Mac

The VIP address is also configured on Realserver because it is going to be returned directly to the client, but this VIP should meet the following criteria:

Only as a return package source IP

The ARP resolution request for this IP is not responding

Lvs-tun:

Tunnel type

How it works: Encapsulates an IP header again beyond the three tiers of the original packet

Characteristics:

Data packet into the director,

Port mappings are not supported

The OS needs to support tunneling mechanisms

Realserver must have VIP, but only for the use of back bag

Main application scenario: remote machine Room

Lvs-fullnat

Full NAT

How it works: Modify the source IP address of the packet

Characteristics:

Data packet in and out are routed through the director

Support Port Mappings

Main application scenario: RIP and dip are not on the same IP network, as long as they can be routed back to the director

Scheduling algorithm:

Static Dispatch: Based on the algorithm only, regardless of the backend realserver overload

Dynamic scheduling: Based on the algorithm combined with the overload of the backend Realserver

Static Dispatch:

Rr:roundrobin Polling

Wrr:weight Roundrobin Weighted Polling

Sh:source Hash source hash, by the source address hash divided by the weight of the remainder scheduling, can achieve session binding

Dh:destination Hash

Dynamic scheduling:

Lc:least Connection: Minimum connection

Wlc:weight least Connection Weighted minimum connection (default scheduling algorithm) (active*256+inactive)/weight

Sed:shorest expextion Delay Shortest expected delay (active+1) *256/weight

Lblc

Lblcr

This article is from the "Zxcvbnm Xuan ye" blog, please be sure to keep this source http://10764546.blog.51cto.com/10754546/1763816

Working model and scheduling algorithm for LVS