LB Cluster and LVS

背景：

Load Balancing Cluster：

tcp: lvs

应用层: nginx, haproxy, apache, lighttpd, varnish, squid

扩容：

scale up

scale out

需要：

lvs: 内核空间

应用层：用户空间，因为能理解应用层协议，能实现基于该协议的精细化管理。例如：动静分离、后端主机健康状况检查

选择：根据需求选择 BL Cluster

LVS: Linux Virtual Server

概念：

是一段内核代码，类似于 netfilter ，工作在内核中，只是一个框架，本身并不提供功能，这个框架提供了能够根据用户提供的转发规则，将用户对于服务应用的请求转发到后端主机

根据用户请求的服务器，在内核中判定（根据rules），如何进行转发，转发到那个后端主机

名称由来：

LVS 一般不运行任何 Web 服务，但却告诉用户我这有某个服务，而是将用户请求转发至后端主机，因此被叫做VS

关键字：

内核代码: 框架，TCP/IP， tcp/udp

IP:Port, 集群服务

DNAT：目标地址，在LVS出去之前可以 DNAT 多台主机，但是LVS 出现之后，DNAT 就只能 DNAT 1台主机了

类似于netfilter

服务器术语：

调度器：Director, Dispatcher, Load Balancer

RealServer:

报文传输过程IP:

CIP :Client IP

VIP:Virtual Server IP

DIP:Director IP

RIP:Real Server IP

CIP<-->VIP<-->DIP<-->RIP

LVS调度算法抛砖：

rr: Round-Robin，轮叫,轮调

wrr: Weighted Round-Robin, 加权轮叫

图形描述：

LVS 工作机制：

LVS：章文嵩

iptables/netfilter

ipvsadm/ipvs

因为 netfilter 和ipvs 都要使用 LOCAL IN，FORWARD 这2个 HOOK, 在这2个点上不能同时存在规则

LVS 工作点特性

IP:Port （L4 Switch, L4 Router）四层交换，四层路由

交换机：以 MAC地址进行报文转发工作在 2层：数据链路层

路由器：以 IP地址进行报文转发工作在 3层：网络层

LVS：以 IP:Port 进行报文转发工作在 4层：传输层 , 类似于路由器/交互机,所以叫做：L4 Switch, L4 Route

LVS类型：

lvs-type：

NAT:

TUN

FullNAT

NAT:

1、RealServer应该使用私有IP地址；

2、RealServer的网关应该指向DIP；

3、RIP和DIP应该在同一个网段内；

4、进出的报文都得经过Directory，在高负载下，Directory会成为系统性能瓶颈；

5、支持端口映射；

6、RealServer可以使用任意OS；

用途：由于上面第4条，使得其扩展受限，所以这种type 很少使用

DR: Direct Routing

1、RealServer可以使用私有地址；

2、RealServer的网关一定不能指向DIP；

3、RealServer和Director要在同一物理网络内；DIP和RIP应该在同一网段；

4、入站报文经过Directory，出站则由RealServer直接响应Client；

5、不能做端口映射；

6、RealServer可以为大多数常见OS；

用途：改进了 NAT的扩展问题，但是引入了设置的物理限制（同一机房）

TUN：Tunneling

1、RIP、DIP不能是私有地址；

2、RealServer的网关不能指向DIP；

3、入站报文经过Directory，出站则由RealServer直接响应Client；

4、不支持端口映射；

5、支持IP tunneling的OS才能用于RealServer；

6、Real Server 和 Director 不用在同一个物理网络内

NAT(DNAT):

请求进来时：DNAT 人为设定 destination IP ，在LOCAL IN上进行NAT
请求出去时：SNAT LVS设定 source IP , 在FORWARD 上进行NAT

DR: Direct Routing

响应过程不经过Director

客户端访问的是VIP ，响应不经过Director，就能回到客户端，那么 Real Server 必须能够构建 VIP为源IP 地址的响应报文，怎么实现？

Director 提供2个网卡： VIP DIP

Real Server 提供2个网卡： RIP VIP

通过上面设置我们可以让 Real Server 构建以VIP 的响应报文

路由器发现要访问的VIP 在自己网段内，把报文接过来，然后动态ARP ,寻找VIP 的MAC地址找到后用该MAC封装报文，交给交换机，但是Director 、RealServer 都有VIP ，怎么才能让 Director 顺利接到报文，然后Load Balancing？

A. 路由器设置使用静态ARP 绑定 VIP为Director MAC地址,这样路由器就不用ARP广播了，直接将报文指定给 Director

B. 利用红帽提供的 arptables ，使Real Server 拒绝响应 Router的动态APR 广播。这样Router 仅能得到 Director MAC

C. 在 linux 2.6.4 之后，直接引进了2个参数，这2个参数可以设定主机路由响应方式：
1.只有APR广播经过的网卡才响应ARP请求

2.直接接入的网络的网卡才通告（ARP)该网络 IP:MAC ,那么不在该网络的网卡就不用做ARP通过

借用这种机制，我们可以这样屏蔽掉 Real Server 回应 Router对于VIP的动态ARP广播：

Real Server ： RIP eth0

VIP lo:0

并且让VIP 不在RIP 的网段上，那么 RIP 接入网络，只会通报 RIP 的MAC地址，而VIP 的MAC 地址就不会通报了，而且Router 的ARP 广播报文是通过 eth0 进入本机的，因此lo:0也不会回应此次 ARP的

以上3种办法都能达到：仅让Director 会响应 Router的关于VIP 的动态ARP 广播请求

报文交给了 Director ，但是 Director 要怎么把报文转给 Real Server ，才能是 Real Server 构建响应报文时使用VIP喃？

显然不能以目标地址为：RIP 的方式给 Real Server 因为访问的目标，才是构建响应的源（意思就是，我要访问 VIP ,你就得以 VIP 的身份回应我）

所以，Diretor 转交报文给 Real Server 时，必须以VIP 为目标 IP ，并且 Diretor 对报文的做如下动作：修改报文的目标MAC 为 Real Server MAC，确保报文送到的是 Real Server

Real Server 收到报文，发现目标MAC为自己，拆掉MAC , 发现目标IP 为 VIP ，也是自己，于是再拆 TCP 首部交给应用层服务，最后响应报文需要以报文出去的网卡为源IP 地址构建响应报文（linux内在机制：报文从哪个网卡离开，就把哪个网卡作为源地址），但是 lo:0 是出不去的，只能从 eth0:出去，难道又只能以 eth0:上的 RIP 构建响应报文吗？

强行定义路由规则，明确告诉linux：只要访问目标为 VIP 那么响应的源IP 就必须是VIP

响应报文从eth0出来后交给的下一个主机，那么下个主机一定是 eth0（RIP)的网关。
由于RIP 与 VIP 不能同网段，那么VIP的网关一定不能与 RIP 的网关为同一网关

注意：

因为Director 把报文给 Real Server时，使用的MAC 地址通信（因为使用IP通信，那么又要ARP广播，那样得到的又是Director的VIP MAC地址），所以 DIP 与 VIP 必须在同一个物理网络内（同机房）

TUN：Tunneling

IP首部：源IP:CIP 目标IP:VIP

伪IP首部: 源IP: DIP 目标IP: RIP

通过在 DIP 和 RIP 直接搭建一个 IP 隧道来传输正在的报文，虽然RIP是中转站，但是 RIP与VIP 在同在 Real Server上，这样也是目的地了

FullNAT：

转载于:https://blog.51cto.com/deamonsky/1381712

相关推荐