Linux Cluster
A Linux cluster (cluster) is a set of Linux computers that, as a whole, provide users with a set of network resources, which are the nodes of a cluster. An ideal cluster, users will not be aware of the underlying nodes of the cluster system, in their view, the cluster is a system, not multiple computer systems, and the administrators of the cluster system can arbitrarily add and revise the nodes of the cluster system.
There are 4 main advantages of Linux cluster system:
1, easy to expand, the administrator can easily add or remove nodes in the cluster system.
2, high availability, when a node in the cluster fails, its responsible task can be passed to other nodes, effectively avoid a single point of failure.
3, high-performance, load-balanced cluster system can undertake a great deal of concurrent customer requests.
4, cost-effective, can use relatively inexpensive hardware to construct a high-performance system.
Common types of Linux clusters include:
1, lb:load balancing, load Balancing cluster
A scheduler (Director) in a load-balanced cluster, which is located on top of multiple internal servers, chooses one from the lower-level server group to respond to requests sent by the client, based on a defined schedule.
2, Ha:high availability, high availability cluster
As the name implies, the availability of the service is relatively high, when a server failure does not cause the service interruption, the cluster automatically transfers the customer's access request to a working server.
3, Hp:hight performance, high performance
A high-performance cluster is when a task is computationally large, and a cluster of computers is working together to accomplish this task, which we call the parallel processing mechanism. The general high performance cluster is used in scientific research work.
Common types of Linux cluster extensions (build) are:
1, scale up (vertical expansion): By increasing the hardware resources, that is, to increase the better equipment to meet the demand for performance consumption. But this approach is very low cost.
2, scale out (scaling out): By hardware or software, a single server-owned business requirements into a set of node servers for processing, this way is easy to expand and cost-effective.
Lvs,linux Virtual Server
After a preliminary understanding of Linux cluster, we further introduce the Load Balancer Clustering technology LVS (Linux Virtual Server).
LVS is a free software project initiated by Dr. Zhangwensong, and its official site is http://www.linuxvirtualserver.org. LVS works in kernel space, implementing four-tier routing of TCP/IP protocol groups, Before the Linux2.4 kernel, the LVS must be recompiled to support the LVS function module, but since the Linux2.4 kernel has fully built in the LVS function modules, no need to patch the kernel, you can directly use the various features of LVS.
LVS uses three-tier structure: Scheduler, server pool, shared storage, structure such as:
Load Balancer/director: Consists of one or more load schedulers, primarily acting like a router, distributing user requests to a real server on a server pool;
Server Pool/realserver: A set of servers that actually perform customer requests, typically web, MAIL, FTP, DNS, and so on.
Shared storage: Provides a shared store for a server pool, allowing the server pool to have the same content and provide the same service.
LVS needs to filter the data stream in the kernel's TCP/IP protocol stack, which needs to be supported by the kernel module, which is defined by the user, we can think of LVS as a two-stage architecture that works in the kernel space as "Ipvs", and in the user space, The "Ipvsadm" is used to define the Cluster service rules.
LVS cluster type related terms:
Scheduler: Director; vs:virtual server; rs:real server; cip:client IP;
Vip:virtual Serve ip; dip:director ip; rip:real Server IP
Types of LVS clusters:
Lvs-nat: Modify the target Ip;masquerade type of the request message
LVS-DR (Direct routing): Re-encapsulates the new MAC address, the default type of use, and the gateway type
Lvs-tun (IP tunneling): Add a new IP header outside the original request IP message; IPIP type
Lvs-fullnat: Modify the source and destination IP of the request message
lvs- Nat: Dnat of multi-target IP, by modifying the target address and target port in the request message to the RIP and port of a selected RS for forwardingKey points: (1) Rip and dip must be in the same IP network, and should use the private network address, RS gateway to the Dip, (2) The request and response messages must be forwarded through the Director, in very high load scenario, director may become a system bottleneck, (3) Support port mapping, The target port of the request message can be modified; (4) vs must be a Linux system, RS can be any systemdefault mode for Lvs-dr:lvsBy re-encapsulating a Mac header for the request message, the source Mac is the Mac of the interface where the dip is located, the target Mac is the MAC address of the selected Rs RIP interface, the source Ip/port, and the target ip/ Port remains the same point: (1) Director and each RS must be configured to use VIP; (2) Ensure that the front-end router sends a request message with the target IP VIP to Director: limit the ARP notification and response level by modifying the kernel parameters on the RS (arp_ Announce and Arp_ignore); (3) The rip of Rs can use the private network address or the public network address, RIP and dip in the same IP network; RIP's gateway cannot point to the dip to ensure that the response message is not configured on the DR by Director;vip Should be on the eth0:0, in the configuration of the VIP on the RS, it must be lo:0, or not to let RS do not respond to the VIP ARP notification effect. (4) RS and director to the same physical network is the same broadcast domain, (5) The request message through the Director, but the response is not through the director, but by the RS through the gateway directly to the client; (6) port mappings are not supportedLvs-tun:Forwarding mode: Do not modify the Request packet IP header (the source IP is CIP, the target IP is VIP), and in the original IP packet to encapsulate an IP header (the source IP is DIP, the target IP is RIP), the message sent to the selected target RS points: (1) DIP,VIP, RIP should be the public address, (2) RS gateway can not, and can not point to dip, on the LO alias card of RS Configuration VIP address, (3) Request message through director, but the response is not through director; (4) port mapping is not supported ; (5) RS OS has to support tunnel functionLvs-fullnat:By simultaneously modifying the source IP address of the request message and the destination IP address for forwarding points: (1) VIP is the public address, RIP and dip is the private network address, and usually not the same IP network; therefore, the Gateway of RIP does not generally point to dip, (2) RS receives the request message source address is dip, therefore, Just respond to the dip, but the director also sends it to the client, (3) The request and response messages are passed through the director; (4) Support port mapping; (5) Lvs-fullnat LVS default does not support the need to replace the supported kernel
The scheduling algorithm for LVS:
static scheduling algorithm: Scheduling based on the algorithm itselfRr:roundrobin, polling, the scheduler allocates external requests to nodes in the cluster in turn, wrr:weighted RR, weighted polling, the scheduler allocates external requests to nodes in the cluster based on pre-set weights, Sh:source Hashing, Implementation session sticky, the source IP address hash, the request from the same IP is always sent to the first pick of the real server IP, thus realizing the conversation binding; Dh:destination Hashing, the target address hash, The request to the same destination address is always forwarded to the real server IP in the first pick, and the typical usage scenario is load balancing in the forward proxy cache scenarioDynamic scheduling algorithm: Scheduling based on current load status and scheduling algorithm of real serverLc:least connections, the scheduler dynamically dispatches network requests to the server with the fewest connections established through the LC scheduling algorithm wlc:weighted least connections, The scheduler optimizes load-balancing scheduling by the WLC scheduling algorithm based on pre-set weights, and servers with higher weights will withstand a large proportion of connection requests; Sed:shortest expection Delay, improved on the WLC, overhead= ( activeconns+1) *256/weight; nq:never Queue Scheduling, if there is a realserver number of connections = 0 directly assigned to the past, do not need to perform the SED operation, to ensure that there is no host is idle ; lblc:locality-based Least-connection, the minimum number of connections based on the address is dispatched, the request from the same destination address is assigned to the same RS, at this time the server is not full load. Otherwise, the request is assigned to the RS with the smallest number of connections and is considered as the first consideration for the next assignment; lblcr:locality-based Least Connections with Replication, local least-link with replication Scheduling algorithm is also for the target IP address load balancing, is mainly used in the cache cluster system, which differs from the LBLC algorithm is that it maintains a mapping from a target IP address to a set of servers, while the LBLC algorithm maintains a mapping from a destination IP address to a server.
First knowledge of Linux clusters