本文主要内容如下:
一、餐厅角色
在餐厅主要有这几种角色:
- 服务员:负责记录客户已点哪些菜、上菜时间、上菜、划掉菜。可以将多个服务员都当做客户端,相对于传菜员来说。
- 传菜员:负责通知厨房走菜、划菜、传菜。可以将传菜员当作 Keepalived 组件。
- 厨师:烹饪、装盘。可以将厨师当作后台真实服务器。
为什么需要传菜员这个角色?有了传菜员这个角色后,发生了什么呢?
- 服务员需要服务顾客,不需要离开包间去厨房拿菜。(单一职责)
- 服务员不需要定期到厨房询问菜是否好了。(解耦)
流程图如下:
① 客户点菜下单。
② 服务员记录菜名、上菜时间。这里的上菜时间是指客户要求的上菜时间,因为有些客户可能想等朋友一起来了再吃。
③ 服务员将一份订单交给传菜员,另外一份订单留在包间。
④ 传菜员大声通知多位厨师有哪些菜要做,什么时候开始上菜。
⑤ 厨师准备食材和烹饪。如果缺少食材,厨师还会告诉传菜员,由传菜员转告服务员说这道菜不能做。
⑥ 厨师做好后将菜装在盘子里,然后递给传菜员。
⑦ 传菜员将订单上对应的菜划掉,表示已经做了。
⑧ 传菜员将菜端给服务员。
⑨ 服务员将菜从订单上划掉。
⑩ 服务员将菜端上餐桌。
这个流程简单来说就是客户下单->服务员传单->传菜员通知->厨师烹饪->传菜员传菜->服务员上菜。
上面的流程不正是服务员请求数据,将请求都发给了传菜员,传菜员将请求转发给了厨师,厨师处理完后返回结果。妙啊!!
二、初探 Keepalived 的路由方案
2.1 为什么需要路由方案
上篇我们讲到 Keepalived 的负载均衡调度算法,通过这个算法选出某台真实服务来处理本次客户端请求。
就好比传菜员要将要做的菜,告诉其中一个厨师(一般是告诉大厨)。
而如何告诉厨师呢?是用
喇叭
喊,还是传呼机
,还是走到他旁边告诉他?
服务员与厨师对话的方式
对于 Keepalived 来说,选择了一个真实服务器后,后续还有两个流程需要梳理下:
- Keepalived 如何将请求转发给这个服务呢?
- 服务处理完这个请求后,如何将处理结果返回给客户端?
上面两个流程就是 Keepalived 的路由方案要做的事。
Keepalived 有三种路由方案:NAT、TUN、DR。
2.2 配置在哪
具体的配置哪种路由方案在 keepalived.conf 配置文件中,其中有一个 lb_kind 配置,可以配置成 NAT、DR、TUN 三种。目前配置的是 DR 模式。
还有一个配置 lb_algo,这个是配置调度算法的,比如这里配置的 wrr 加权轮询调度算法。
2.3 LVS 的结构
上篇我们说到 Keepalived 是利用了 LVS 模块的功能来实现负载均衡的。那么 LVS 的结构是怎么样的呢?
分为两个模块:前端的负载均衡器(Load Balance,简称 LB),后端的多台真实服务器(Real Server, 简称 RS)组成。LB 负责流量转发,RS 负责处理请求,然后将请求返回。
三、深入理解 Keepalived 的路由方案
3.1 NAT 路由方案
NAT 的全称是 Network Address Translation,网络地址转换。它有两个功能:
- 使企业内部的私有 IP 可以访问外网,
- 使外部用户可以访问位于公司内部的私有 IP 主机。
对于 Keepalived 来说,这种模式就好比餐厅的标准下单上菜模式:多个服务员将订单数据转给传菜员,传菜员通知厨师进行烹饪,厨师把菜做好后转给传菜员,传菜员负责把菜传递给服务员。
如下图所示,LVS 负载调度器有两块网卡,配置了不同的 IP 地址,网卡 eth0 设置为公网 VIP 与外部网络连通,网卡 eth1 设置为私有 VIP 与内部网络通过交换设备相互连接,
示例如下:
eth0 网卡 -> 公网 VIP -> 外部网络
eth1 网卡 -> 私有 VIP -> 交换设备 > 内网网络
原理图如下所示:
① 比如现在 eth0 网卡配置了一个公有 VIP 如 10.1.2.88,客户端发送的请求都是到这个 Public VIP(目标地址)。
② 主 LVS Router 负责接收请求,将请求的目的地址(Public VIP)替换成 NAT VIP(192.168.56.88)。
③ 这个 NAT VIP 和后端服务器同属一个局域网,可以相互访问,请求经过负载均衡调度选择一个真实服务器。
④ LVS 修改数据包中的目标地址和目标端口为真实服务器的。
⑤ 真实服务器处理完请求后,将应答数据返回给 LVS Router。
⑥ LVS Router 将应答数据的源 IP 地址 NAT VIP 和端口转换成 Public VIP 和 LVS 的端口,然后转发给外部网络的客户端。
对于客户端而言,它只和 Public VIP 打交道,并不知道 NAT VIP,更不知道真实服务器的 IP 地址,这个过程也称为 IP 伪装。
对于服务员💁🏻来说,她只和传菜员打交道,并不知道厨师👩🏻🍳 。
1.2 LVS-TUN 路由方案
1.2.1 NAT 方案的瓶颈
如果餐厅的生意非常火爆,一个传菜员会非常忙,有可能厨师已经把菜做好了,但是传菜员没有时间传给服务员,那么餐厅的瓶颈就是传菜员了。
如下所示,一个传菜员对应三个厨师,而且做的菜很多,都需要传菜员将菜端给包间外的服务员。
NAT 的路由方案存在瓶颈,由于所有的数据请求及响应的数据包都需要经过 LVS 调度器转发,如果后端服务数量很多,客户端访问流量也很大的话,那么调度器会忙于调度转发和地址替换等操作。
为了解决 NAT 的性能问题,TUN 路由方案是个比较好的选择。TUN 方案中,真实服务器处理完结果后,直接返回给客户端。但是这就要求真实服务器能够与外部网络连接。
也就是说厨师做好菜后,厨师直接把菜递给服务员,不需要经过传菜员。厨师是对外可见的。
1.2.2 TUN 详解
TUN 其实是 tunneling(隧道)的缩写,而 TUN 路由方案就是基于 IP 隧道的一种技术。
我们熟知的 VPN 技术就是 IP 隧道技术。
IP 隧道其实是一种封装技术,将一个 IP 报文封装在另一个 IP 报文中。分为如下两步:
- ① 先将原始数据包进行封装。
- ② 然后添加新的源地址+端口、新的目标地址+端口。
它可以将原始数据包封装并添加新的包头(内容包括新的源地址及端口、目标地址及端口),从而实现将一个目标为调度器VIP地址的数据包封装,通过隧道转发给后端的真实服务器(Real Server),通过将客户端发往调度器的原始数据包封装,并在其基础上添加新的数据包头(修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口),LVS(TUN)模式要求真实服务器可以直接与外部网络连接,真实服务器在收到请求数据包后直接给客户端主机响应数据。
原理图如下所示:
TUN 模式的缺点:
隧道模式的RS节点需要合法 IP,这种方式需要所有的服务器支持 IP Tunneling 协议。
1.3 LVS-DR 模式
那么 LVS 的 TUN 路由模式有没有什么问题呢?
因为 TUN 的方式必须在 LVS 调度器和真实的服务器之间有一个隧道连接,这个创建隧道的过程会对服务器增加负担。
在餐厅这种场景中,TUN 模式中,厨师是对外可见的,菜好了后直接和服务员对接;而 DR 模式中,厨师不可见,统一被看成是传菜员。
DR 模式和 TUN 模式的相同之处:
- 模式中,用户的请求被调度器负载均衡到真实服务器上,然后真实服务器把响应结果返回给客户端。
- 客户端的请求数据包中目标 IP 为 LVS 的 VIP,源 IP 为客户端 IP。
DR 模式和 TUN 模式不同之处:
- DR 模式要求调度器与后端服务器必须在一个局域网内。
- DR 模式不需要创建 IP 隧道。
- DR 模式中,VIP 需要在 LVS 调度器与后端所有的服务器间共享。
- DR 模式中,真实服务器处理完结果后,返回数据包时,设置源 IP 为 VIP 地址,目标 IP 为客户端 IP。
- DR 模式中,LVS 调度器和真实服务器在同一物理网段上。同一网段机器数量有限,限制了其应用范围。
更细节的内容
负载均衡器和RS都使用同一个IP对外服务但只有 DR(Director Server,可以理解为 LVS 的核心) 对 ARP 请求进行响应,所以 RS (Real Server,真实服务器)对本身这个 IP 的 ARP 请求保持静默。
也就是说,网关会把对这个服务IP的请求全部定向给 DR。而 DR 收到数据包后根据调度算法,找出对应的 RS,把目的 MAC 地址改为 RS 的 MAC(因为 IP 一致)并将请求分发给这台 RS 这时 RS 收到这个数据包,处理后直接返回给客户端。由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上。
四、三种模式对比
推荐 DR 模式。