Linux Cluster Director (Scheduler)

Linux Cluster (Linux cluster)

Cluster: A collection of computers, combined in order to solve a particular problem;

How the System expands:

Scale up: scaling up; Such as: add memory to the original machine, CPU.

Scale out: outward expansion; such as: to the original web system, the mail system to add a new machine.

If you are interested in understanding the world rankings of servers, can query: www.top500.org in the periodic evaluation of the server, the evaluation of the vector machine.

Linux Cluster Types:

Lb:load balancing, load balancing;

Features: Can solve Spof (single point of Failure), but director will become a performance bottleneck;

Ha:high availability, high availability cluster;

MTBF: Average trouble-free time;

MTTR: Mean time of failure repair;

availability=mtbf/(mtbf+mttr)

There are two main ways to improve availability:

1. Increase MTBF;

2. Reduce MTTR----Redundancy, automatic fault switching, monitoring detection heartbeat;

Hp:high perormance, high performance cluster;

ds:distributed system, distributed systems; Hadoop, HDFS, Gluster FS, MogileFS, ...

Linux Cluster Director (Scheduler)

Hardware:

F5 big-IP (good performance, high price)

Citrix Netscaler (moderate performance, affordable)

A10 A10 (slightly worse performance)

Software:

Lvs:linux Virtual Server (Chinese Zhangwensong Development)

Nginx:

Haproxy

Ats:apache Traffic Server

Perlbal:

Pound

Work-based protocol layer partitioning:

Transport layer: four-layer switching (load balancing implemented at the Transport layer)

Lvs

Nginx

Haproxy

Application layer: seven-layer switching (load balancing implemented at the application level)

httpd

Nginx

Haproxy

Special Load Balancing:

FASTCGI:HTTPD, Nginx

Mysql:mysql-proxy, MHA, Amoeba

Lvs:linux Virtual Server

Real Server

Author: Zhangwensong

LAYER4: four-layer switching, four-tier routing;

Ip:port: The data packet is dispatched to a real server on the backend based on the destination IP address of the requested message and the target port number of the Protocol; In the selection of real server, there are a series of scheduling algorithms to choose from;

Iptables/netfilter: Acting on the dnat:prerouting chain

Ipvsadm/ipvs: The main role is in the input chain, so the rules on the input chain must be emptied;

Ipvsadm: Command line tool in user space, rule Management tool for Cluster service and real server management;

Ipvs: The framework that works on the NetFilter input hooks in the kernel space can receive administrative commands from Ipvsadm;

Ipvs can support such protocols as TCP, UDP, SCTP, AH, ESP, AH_ESP, etc., and can dispatch data of such protocols;

There are several common terms in the LVS cluster:

Vs:virtual Server (Dispatch server), Director, Dispatche, Balancer

Rs:real server (real server), backend server, upstream server

Cip:client IP, client IP address, that is: the IP address of the requesting sender;

Vip:virtual server IP, Virtual server virtual IP address, client access destination address;

Dip:director IP, the scheduler IP address, the IP address that is used when forwarding client requests to the rear real server;

Rip:real server IP, the IP address of the rear real server;

General communication process using LVS:

CIP--VIP--DIP---RIP

LVS Cluster Type: Lvs-nat lvs-dr lvs-tunnel Lvs-fullnat

Lvs-nat:

The Dnat of multi-target IP address is forwarded by modifying the target address and target port in the request packet to a process of the rip and port of the back-end RS selected by the scheduling algorithm;

Note the following questions:

1.RIP and dip must be in the same network segment and should be a private IP address; The gateway to the RS should point to the dip;

2. The request message and the response message must be forwarded by the Director, the director is easy to become a system performance bottleneck and trigger a single point of failure;

3. Port redirection can be implemented; The port number that the CIP sends to the VIP can be different from the service port of the service provided by the back-end rip;

4.VS must be a Linux system, RS can be any operating system;

LVS-DR: Default Type

Dr:direct Routing, direct routing;

Packet forwarding is carried out by re-encapsulating a data Link layer header (MAC address) for the request message; The source MAC address of the message after re-encapsulation is the MAC address of the network interface where the dip is located; The destination address is the MAC address of the interface where the rip of the backend RS is selected by a scheduling algorithm; The source IP address and source port, as well as the destination IP address and destination port, remain unchanged throughout the message forwarding process;

Take a look at a few questions:

1. Ensure that the front-end router can send a message with the target IP address VIP to VS (Director);

1) The mapping relationship between IP address and MAC address is statically bound on the router;

2) Use the Arptables on the RS;

3) Modify the kernel parameters on the RS to limit the notification of ARP and the response to ARP requests;

Arp_announce

Arp_ignore

2.RS RIP can be a private address or a common address, and rip and dip should be in the same logical network;

3. The request message must pass through the director, but all response messages do not need to be routed directly to the client via the Director;

4. Port redirection is not supported;

5.RS must be a Linux operating system;

RIP and VIP must be configured on the 6.RS, and the VIP should be configured on the lable of the Lo interface;

Lvs-tun:tunnel, tunnel;

Do not modify the IP header of the request message (the source IP is CIP, the destination IP is VIP), but in the original package format of IP packets to encapsulate an IP header (the source IP is dip, the destination IP is RIP), the re-encapsulated message to the use of scheduling algorithm selected from the back-end RS;

Note the following questions:

1.CIP, VIP, DIP, RIP should be the public IP address;

The 2.RS gateway cannot point to the dip, so the response message is not forwarded by the Director, but directly to CIP;

3. Port redirection is not supported;

4.RS must support tunnel protocol;

RIP and VIP must be configured on 5.RS;

Lvs-fullnat:

Non-standard type;

By simultaneously modifying the source IP address and destination IP address of the request message, the message forwarding is realized.

CIP--DIP

VIP--RIP

Note the following questions:

1.VIP is a public address, dip and rip are private addresses, and dip and rip can no longer be the same network segment;

2.RS the destination of the response message to the received request message is the dip, so the request message and the response message must go through the Director;

3. Support port redirection;

4. This type is not supported by default;

Ipvs Scheduler:

The scheduling algorithm can be divided into two categories according to whether the LVS considers the current load state of each RS at the time of Dispatch:

Static algorithm: According to the characteristics of the algorithm itself to dispatch, pay attention to the starting point fairness;

Rr:roundrobin, polling;

Wrr:weighted RR, weighted polling;

Sh:source Hashing, source address hash, will be from the same IP address of the request always sent back end of the first pick in the RS, generally used for the forward proxy server cluster;

Dynamic algorithm: Mainly based on the current load status of each RS schedule scheduling, pay attention to the results of fairness;

The load of the back-end RS, expressed in overhead;

Lc:least connections, minimum number of connections;

There are two kinds of connections: one is active connection; One is inavtive connection;

Overhead=activeconnections*256+inactiveconnections

Note: The first time the dispatch, according to the order configured in Ipvsadm the top-down distribution;

wlc:weighted LC, weighted minimum connection; (Default algorithm)

Overhead= (activeconnections*256+inactiveconnections)/weight

Note: The first time the dispatch, according to the order configured in Ipvsadm the top-down distribution; The weights do not play a role in the first time dispatch;

Sed:shortest expection delay, shortest expected delay;

Overhead= (activeconnections+1) *256/weight

Note: SED can solve the problem of beginning injustice, but the weight gap is relatively large, it may lead to unfairness;

Nq:never Queue, improved version of the SED algorithm, the first time scheduling, according to the weight of the back-end RS to assign a connection to each RS; And then according to the SED algorithm scheduling; Must ensure that at least one ActiveConnection at the rear end of each RS;

Lblc:locality-based Least Connections, based on local minimum connection, dynamic DH algorithm;

LBLCR:LBLC with Replication, the LBLC with copy function;

Linux Cluster Director (Scheduler)