Keepalived 高可用的三种路由方案

话说之前大学放暑假的时候，我到一个餐厅打工两个月，Title 是初级传菜员。正是这次打工经验，为我带来了一波潜藏已久的素材，请听听我的故事吧~,本文主要内容如下：,,在餐厅主要有这几种角色：,为什么需要传菜员这个角色？有了传菜员这个角色后，发生了什么呢？,流程图如下：,,① 客户点菜下单。,② 服务员记录菜名、上菜时间。这里的上菜时间是指客户要求的上菜时间，因为有些客户可能想等朋友一起来了再吃。,③ 服务员将一份订单交给传菜员，另外一份订单留在包间。,④ 传菜员大声通知多位厨师有哪些菜要做，什么时候开始上菜。,⑤ 厨师准备食材和烹饪。如果缺少食材，厨师还会告诉传菜员，由传菜员转告服务员说这道菜不能做。,⑥ 厨师做好后将菜装在盘子里，然后递给传菜员。,⑦ 传菜员将订单上对应的菜划掉，表示已经做了。,⑧ 传菜员将菜端给服务员。,⑨ 服务员将菜从订单上划掉。,⑩ 服务员将菜端上餐桌。,这个流程简单来说就是客户下单->服务员传单->传菜员通知->厨师烹饪->传菜员传菜->服务员上菜。,上面的流程不正是服务员请求数据，将请求都发给了传菜员，传菜员将请求转发给了厨师，厨师处理完后返回结果。妙啊！！,上篇我们讲到 Keepalived 的负载均衡调度算法，通过这个算法选出某台真实服务来处理本次客户端请求。,服务员与厨师对话的方式,对于 Keepalived 来说，选择了一个真实服务器后，后续还有两个流程需要梳理下：,上面两个流程就是 Keepalived 的路由方案要做的事。,Keepalived 有三种路由方案：NAT、TUN、DR。,具体的配置哪种路由方案在 keepalived.conf 配置文件中，其中有一个 lb_kind 配置，可以配置成 NAT、DR、TUN 三种。目前配置的是 DR 模式。,还有一个配置 lb_algo，这个是配置调度算法的，比如这里配置的 wrr 加权轮询调度算法。,,上篇我们说到 Keepalived 是利用了 LVS 模块的功能来实现负载均衡的。那么 LVS 的结构是怎么样的呢？,分为两个模块：前端的负载均衡器（Load Balance，简称 LB），后端的多台真实服务器（Real Server, 简称 RS）组成。LB 负责流量转发，RS 负责处理请求，然后将请求返回。,NAT 的全称是 Network Address Translation，网络地址转换。它有两个功能：,如下图所示，LVS 负载调度器有两块网卡，配置了不同的 IP 地址，网卡 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 伪装。,对于服务员来说，她只和传菜员打交道，并不知道厨师‍ 。,如果餐厅的生意非常火爆，一个传菜员会非常忙，有可能厨师已经把菜做好了，但是传菜员没有时间传给服务员，那么餐厅的瓶颈就是传菜员了。,如下所示，一个传菜员对应三个厨师，而且做的菜很多，都需要传菜员将菜端给包间外的服务员。,,NAT 的路由方案存在瓶颈，由于所有的数据请求及响应的数据包都需要经过 LVS 调度器转发，如果后端服务数量很多，客户端访问流量也很大的话，那么调度器会忙于调度转发和地址替换等操作。,为了解决 NAT 的性能问题，TUN 路由方案是个比较好的选择。TUN 方案中，真实服务器处理完结果后，直接返回给客户端。但是这就要求真实服务器能够与外部网络连接。,,TUN 其实是 tunneling（隧道）的缩写，而 TUN 路由方案就是基于 IP 隧道的一种技术。,我们熟知的 VPN 技术就是 IP 隧道技术。,IP 隧道其实是一种封装技术，将一个 IP 报文封装在另一个 IP 报文中。分为如下两步：,它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器VIP地址的数据包封装，通过隧道转发给后端的真实服务器（Real Server），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。,原理图如下所示：,,TUN 模式的缺点：,隧道模式的RS节点需要合法 IP，这种方式需要所有的服务器支持 IP Tunneling 协议。,那么 LVS 的 TUN 路由模式有没有什么问题呢？,因为 TUN 的方式必须在 LVS 调度器和真实的服务器之间有一个隧道连接，这个创建隧道的过程会对服务器增加负担。,DR 模式和 TUN 模式的相同之处：,DR 模式和 TUN 模式不同之处：,,负载均衡器和RS都使用同一个IP对外服务但只有 DR（Director Server，可以理解为 LVS 的核心） 对 ARP 请求进行响应，所以 RS （Real Server，真实服务器）对本身这个 IP 的 ARP 请求保持静默。,也就是说，网关会把对这个服务IP的请求全部定向给 DR。而 DR 收到数据包后根据调度算法,找出对应的 RS，把目的 MAC 地址改为 RS 的 MAC（因为 IP 一致）并将请求分发给这台 RS 这时 RS 收到这个数据包，处理后直接返回给客户端。由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域，也可以简单的理解为在同一台交换机上。,,推荐 DR 模式。