LVS Cluster Management

LVS Cluster Management We have several points to explain:

2. LVS basic theory and System expansion Foundation.

4. Ipvsadm the implementation of cluster management commands and Lvs-nat types.

6. Lvs FWM and persistent connection, health status monitoring.

8. The implementation of the LVS-DR model.

This article is about the first part: The basic theory of LVS and the basis of system expansion.

LVS Full Name: Linux virtual Server, which is what we call the VS service.

Component: Ipvs, Ipvsadm

Types of Linux clusters: LB, HA, HP

Ipvs works on the netfilter input link;

Ipvsadm is used to define the Cluster service on Ipvs: It is also necessary to define which backend host is available for this cluster service;

Scheduling decisions are made according to the specified scheduling method (algorithm);

Supported protocols: TCP, UDP, SCTP, AH, ESP, Ah_esp

Common terminology conventions in LVS:

Host:

Director: Scheduler

Real Server:rs, backend service Host

Ip:

Client:cip

Director Virtual IP:VIP

Directory Ip:dip

Real Ip:rip

type of LVS :

Lvs-nat:

Masquerade

LVS-DR:

Direct routing

Lvs-tun:

Tunneling

Lvs-fullnat:

Fullnat

Lvs-nat: Similar to Dnat, but supports multi-target forwarding;

It is forwarded by modifying the target address of the request packet to a certain RS rip selected by the scheduling algorithm;

Architectural Features:

(1) RS should use a private address, that is, RIP should be a private address; Each RS gateway must point to the dip;

(2) The request and response messages are forwarded through the Director; in high-load scenarios, the director is easy to become a system bottleneck;

(3) Support port mapping;

(4) RS can use any type of OS;

(5) The Rip of Rs must be in the same network as the director's dip;

lvs-dr: Direct Routing

The director does not modify the IP header of the request when it implements forwarding, but instead completes the forwarding by directly encapsulating the MAC header; the target Mac is the director chooses the MAC address of an RS based on the scheduling method; The topological structure is different from the NAT type;

Architectural Features:

(1) To ensure that the front-end router will be the target address VIP request message through the ARP address resolution sent to Director

Solution:

Static binding: The target Mac corresponding to the VIP is statically configured as the MAC address of the director directly in the front-end route;

Arptables: On each RS, it rejects the ARP broadcast request to the VIP through the arptables rule;

Kernel parameters: Modify the kernel parameters on the RS, and implement the ARP broadcast request that refuses to respond to the VIP in combination with the configuration of the address;

(2) RS RIP can use a private address, but can also use the public address, at this time through the Internet host directly to the RS to initiate management operations;

(3) The request message must be dispatched through the director, but the response message must not pass through the Director;

(4) Each RIP must be in the same physical network as the dip;

(5) port mapping is not supported;

(6) RS can use most of the OS;

(7) RS Gateway must not point to the Director;

Lvs-tun: Do not modify the request packet IP header, but through the IP tunneling mechanism in the original IP packet and then encapsulate the IP header, through the Internet to send the request message to the selected RS;

CIP; VIP DIP; Rip

Client IP; Virtual IP Director IP; Real IP

Architectural Features:

(1) RIP, DIP, VIP are public network address;

(2) RS gateway can not, nor can point to dip;

(3) The request message is distributed by the Director, but the response message is directly from RS to the client;

(4) port mapping is not supported;

(5) The OS of Rs must support IP tunneling;

Lvs-fullnat: The source address of the request message is dip, the target is RIP to achieve the forwarding, for the response message, the change source address is VIP, the target address is CIP to achieve forwarding;

Architectural Features:

(1) Rip,dip can use private address;

(2) Rip and dip can not be in the same network, and RIP Gateway may not need to point to dip;

(3) Support port mapping;

(4) RS OS (operating system) can use any type;

(5) Request message through Director, Response message via director;

The dispatching mode of LVS Scheduler:lvs cluster;

static method: Only according to the algorithm itself implementation scheduling;

Rr:round-robin, polling, round call, rotation, rotation, that is, 1:1-way scheduling;

Wrr:weighted Round-robin, weighted polling; that is, the RS configuration weights in the cluster to achieve scheduling;

Sh:source IP Hashing, source address hash; that is, the request from the same address, all directed to the previously selected RS;

Dh:destination IP Hashing, destination address hash; that is, the request to access the same destination address is directed to one of the previously selected RS;

Dynamic method: According to the algorithm and the back-end RS Current load situation implementation scheduling;

Lc:least Connection

Overhead=active*256+inactive

wlc:weighted Least connection

Overhead= (active*256+inactive)/weight

sed:shorted expection Delay

Overhead= (active+1) *256/weight

Nq:never Queue

lblc:local-based Least Connection, dynamic mode of DH algorithm;

Lblcr:replicated LBLC

The above is the basic concept of LVS and system expansion basis. Next we will introduce the use of IPVSADM Cluster management commands:http://10267776.blog.51cto.com/10257776/1734582

LVS Cluster Management