why？
- DNS based load balancing cluster ：动态负载不均衡（端侧请求有差异），不能很好处理峰值；故障切换时延大（TTL），IP列表限制
- Dispatcher based load balancing cluster： 开销大。F5等硬件贵 ，可扩展性插，调试维护相对麻烦
为什么选LVS
I prefer the IP-level load balancing, because the overhead of IP load balancing is small and the maxim number of server nodes can reach 25 or up to 100.
- 基于IP 负载均衡开销小 （相对于7层）
- 服务器可扩展的主机数多
HOW：
lvs三种模式各自利弊
|
VS/NAT
|
VS/TUN
|
VS/DR
|
|
|
server
|
any
|
tunneling
|
non-arp device
|
|
server network
|
private
|
LAN/WAN
|
LAN
|
|
server number
|
low (10~20)
|
high
|
high
|
|
server gateway
|
load balancer
|
own router
|
own router
|
VS/NAT：both the request packets and response packets are need to be rewritten by the load balancer；限制：瓶颈在LB服务器的吞吐量；
VS/TUN： the load balancer just schedules requests to the different real servers, and the real servers return replies directly to the users；限制：必须开 "IP Tunneling"(IP Encapsulation) 协议
VS/DR：LinuxDirector processes only the client-to-server half of a connection in the virtual server via direct routing, and the response packets can follow separate network routes to the clients. //限制：LAN环境，节点服务器也需要vip地址,并调整内核的ARP响应参数以阻止更新vip的MAC地址，避免发生冲突
实现原理：
NAT： 请求：LB收到请求，目的IP由VIP改为RS的IP； 响应：由RS配置默认网关为LB IP （ 进：client--LB---RS 出：RS----LB-----client）；往返经过 LB
TUN： 请求：LB收到请求，TUN封装 目的IP为RS的lo IP（同VIP） ，源LB IP （内部报文源还是CIP，目的VIP）； 响应： RS （lo VIP） ---自己的路由--目的CIP ，回程不经过LB
DR: 请求： LB收到请求，修改DMAC为RS的MAC（内部源为 CIP,目的VIP不变）； 响应 RS(lo VIP)---自己的路由---目的CIP，回程不经过LB
LVS的高可用性：
1）LB服务器，有心跳进程守护，实现failover
2）IPVS实现了会话状态的同步，主LB向备LB同步连接信息通过UDP的组播； 这样LB failover时候，客户端无感知
Now the load balancer might become a single failure point of the whole system. In order to prevent the whole system from being out of service because of the load balancer failure, we need setup a backup (or several backups) of the load balancer. Two heartbeat daemons run on the primary and the backup respectively, they heartbeat the message like "I'm alive" each other through serial lines and/or network interfaces periodically. When the heartbeat daemon of the backup cannot hear the heartbeat message from the primary in the specified time, it will take over the virtual IP address to provide the load-balancing service. When the failed load balancer comes back to work, there are two solutions, one is that it becomes the backup load balancer automatically, the other is the active load balancer releases the VIP address, and the recover one takes over the VIP address and becomes the primary load balancer again.
The primary load balancer has state of connections, i.e. which server the connection is forwarded to. If the backup load balancer takes over without those connections information, the clients have to send their requests again to access service. In order to make load balancer failover transparent to client applications, we implement connection synchronization in IPVS, the primary IPVS load balancer synchronizes connection information to the backup load balancers through UDP multicast. When the backup load balancer takes over after the primary one fails, the backup load balancer will have the state of most connections, so that almost all connections can continue to access the service through the backup load balancer.
The availability of database, network file system or distributed file system is not addressed here.
lvs基础架构
The three-tie architecture consists of
- Load Balancer, which is the front-end machine of the whole cluster systems, and balances requests from clients among a set of servers, so that the clients consider that all the services is from a single IP address. //对端侧（前端）提供一个IP
- Server Cluster, which is a set of servers running actual network services, such as Web, Mail, FTP, DNS and Media service.
- Shared Storage, which provides a shared storage space for the servers, so that it is easy for the servers to have the same contents and provide the same services. //保障数据一致性
参考 ：