Nginx: 高可用和与虚拟路由冗余协议VRRP原理以及KeepAlived软件架构

Nginx 服务的高可用

1 ）服务可用

• 假定是这样一个最传统的一个CS模式的一个客户服务器模式
  • 这里有用户和一台服务器
  • 服务器可能是mysql, 也可能是webserver, 或其他服务器
• 想实现服务可用的一个三要素
  • 1.1 ) server 需要公网的ip地址以及申请一个域名
  • 1.2 ) 需要服务软件和相关端口
  • 1.3 ) 存在对应的数据，如：
    • webserver需要css, html, js 等
    • sqlserver需要库和表

2 ) Nginx 高可用

• 我的客户端通过互联网去访问远端的Nginx服务器
• Nginx 服务器肯定是需要具备上面服务可用的三要素
  • Nginx有一个合法的公网ip地址和域名
  • Nginx软件可用，并且80,443等端口正常
  • Nginx资源文件访问正常
• 如果这台Nginx在运行的过程中，并发量很大，存在服务器掉电等等一些不可控的故障，要实现我的业务连续性的这种高可用，应如何?
• 保证Nginx宕机后，转移到另外一台Nginx服务器上，并且把IP地址配置到备用的Nginx上，同时启动相关端口，以及相同的数据文件，这样高可用就实现了
• 这个难点在如何去保证现在Nginx上所配置的面向公网的这个IP地址能够实现在Nginx宕掉之后去自动的转移到另外一台Nginx上
• 这个需要VRRP的虚拟路由冗余协议，本身能够解决这个问题
  • 能够实现宕机时将IP地址，从一台服务器自动的去转移到另外一台服务器上
  • 同时在这两台服务器之间，是有心跳信息监控的
  • 保证IP地址，总是能够配置到一台存活的Nginx服务器上
  • 从而去实现Nginx服务的高可用

3 ）VRRP 原理

• IP地址是如何实现在多台服务器之间进行转移的是比较难实现的
• 在这里有一个叫VRRP协议本身它就是为解决这样一个问题而生

3.1 原理

• 公司内网内，有很多员工都有自己对应的PC电脑
• PC电脑想要通过一定的网关设备，gateway设备去访问对应的互联网
• 不可能给每一台个人电脑都去申请一个公网的IP地址，公网IP地址是有是有成本的
• 每一台PC电脑都去申请一个公网的IP地址，这个是不可能，也是不现实的
• 因此，有这样一个解决方案，在我们的 gateway 上配置了两个IP地址
  • 里面有一个网卡会配置一个对应的内网内的一个IP地址
  • 这个内网IP地址，和我们所有PC上所配置的内网IP地址是在同一个网段的
  • 同时，gateway 还有另外一个网卡上配置一个公网的IP地址
  • 那 gateway 就能够实现和内网和公网相通
• 这个时候PC电脑想要去访问公网或internet上的一些东西的时候
  • 比如说去浏览一些网页，查到一些文件的时候
  • 它可以将这个请求转发给这台 gateway
  • 之后，gateway可以将请求再通过另外一块网卡转发给 internet
  • 当报文回来的时候还是一样，也会首先到达gateway的一个公网的网卡上
  • 由 gateway再作为代理，去把这个数据报文传送给对应的PC电脑
  • 它整个过程是这样的
• 对于我们这样一些网关设备，可能是路由器或者是其他一些设备，它都是一个单点的
• 假如说，gateway网关设备宕掉后，其实内网内所有的PC都不能够再去访问对应的internet了
• 这个时候，想要去解决网关设备(重要设备)的一个单点故障的时候，如何去解决呢？

• 其实我们有这样一种思路, 可以给他找另外一台 gateway
• 现在给了两台一模一样的设备，给这台设备也配置上一个对应的IP地址
  • 一个内网的IP地址，一个公网的IP地址
• 但是有一个问题，因为我们这个 gateway 在这配置对应的内网的IP地址的时候
• 内网的IP地址是不可以相同的，那对这种，如何去解决呢？
• 不管在PC电脑上，需要去设置代理服务器的地址，还是通过广播的形式去请求对应gateway的IP地址
• 不管哪一种方式来说，这个IP地址它只能有一个
• 如何去实现两台gateway，对所有的PC电脑都有一个IP地址
• 其实VRRP本身就能去实现这样一个功能, 两台gateway都有各自的IP地址但不提供给PC
• 这两台 gateway 正常情况下只有一台是提供服务的，一个是master(提供服务)，另一个是backup
• 还有一个另外的IP地址，称之为 虚IP, 即：VIP, 比如：
  • VIP: 192.168.1.1
  • master gateway: 192.168.1.2
  • backup gateway: 192.168.1.3
• 因为这个VIP它是可以在我们两个网关设备之间进行漂移的
• 某一时刻，我的master的gateway在提供服务的时候，其实这个VIP地址是配置到对应的 master gateway上的
• 其实这个VIP是真正对外提供服务的，也就是说，所有的PC电脑想要访问的时候，都需要将代理设置为对应的VIP
• 但是这一切，他们之间，这个VIP在master和backup之间进行自动转移, 对我们的PC来说是透明的
• 因此, 有这样一个场景，比如说在某一时刻，有两台网关设备，这个backup的网关设备，对外是不提供服务的
• 某一个时刻，master的gateway 挂掉之后，这个VIP才会自动去漂移到我们这个对应的backup的gateway上
• 这里，还有一个 vmark，为什么会有vmark这样一个地址呢？
• 其实， 这个VIP地址是配置在我们的 master gateway上的。
• MAC地址(物理地址)是跟网卡绑定的, 不同的网卡的MAC 地址肯定是不一样
• 假如说VIP在这一时刻是配置在 master gateway上的
• 这个时候，我对应的PC电脑去和 VIP 通信的时候，它会发ARP请求
• 同时它得到的会是这个master gateway上的对应网卡的一个 MAC 地址信息
• 这个时候, 我的master有故障, VIP转移到backup上，备用的网关上对应的网卡MAC地址
• 肯定跟master的MAC地址，是不一样的，所以，在这需要有一个 VMAC
• 也就是说, 这个VIP和VMAC，它对于所有的客户端来说都是一样的
• 它是能够实现对应的 master和gateway上进行正确转移的
• 整个过程是这样的
  • 在某一个时刻，我们的VIP和我们的VMAC都会配置到我们的master gateway上
  • 假如说，master gateway 在某一个时刻故障当掉了
  • 这个时候, VIP和VMAC 会一同的转移到 backup gateway 这个设备上
• 对整个过程来说，master getway 和 backup gateway 两个配合的是天衣无缝的, 对外，他们就是一个整体
• VRRP本身就是实现了这样一个能力，总结一下
  • 虚拟网关：有一个master和多个backup组成
  • Master 网关：实际承载报文转发的节点，主节点
  • Backup 网关：主节点故障号转移节点，备用节点
  • 虚拟IP地址：虚拟网关对外提供服务的IP地址
  • IP地址拥有者：真实提供服务的节点，通常为主节点
  • 虚拟MAC地址：回应 ARP 请求时使用虚拟MAC地址
  • master故障后，需要转移到哪一台backup，优先级如何定
  • 非抢占式：master挂掉又恢复，backup一直提供服务，不会回到master上
  • 抢占式：master修复上线后，从backup再次回到master
• VRRP 原理是为了 KeepAlived 软件提供理论支持的
• KeepAlived 软件实现了VRRP原理

KeepAlived软件架构

• VRRP协议最初设计是用来解决局域网环境中网关的高可用问题
• KeepAlived的软件实现了VRRP协议提供对虚拟IP的一个转移能力
• 同时, 它最初设计是用来高可用我们的LVS服务, 是Linux虚拟服务器角色
• LVS是非常重要的负载均衡服务, 它在四层对应用服务进行负载均衡
• 因此它的负载均衡能力比LBS还要强, 由于它是在内核中
• Nginx 作为负载均衡是在七层进行负载均衡需要考虑应用层的很多特征信息
• 肯定不如在四层这种传输层直接去进行负载均衡，能力更强
• 它本身最初设计就是为了高可用LVS的，只是在后来它又被开发者开发出来更多的用途
• 也能够去兼容高可用于其他一些应用服务

1 ）架构图

• 在这个架构图中，右边最核心的有一个 VRRP Stack
• 也就是实现了 VRRP 的一个协议栈，对软件本身它就是实现了VRRP协议的一个软件
• 它最重要的一个功能就是 VRRP Stack, 能够实现VRRP协议，能够对IP进行转移
• 下面还有一个IPVS wrapper, KeepAlived 本身的设计就是用来高可用 IPVS 和 LVS 的
• LVS其实它有很多的这个规则，它的规则也是需要在不同的服务器上进行转移的
• 比如说你有两台LVS的服务器，正常情况下是由其中一台提供服务
• 如果一台断掉之后，除了利用 VRRP Stack 这样一个协议栈的能力
• 将虚拟IP转移到另外一台备用节点服务器上
• 除此之外，还需要在备用服务器节点去生效新的IPVS规则，也就是LVS的一个规则
• 因此，在这内置有一个叫 IPVS wrapper 的模块
• 这个模块就是用来实现IPVS规则，在不同的服务器上进行转移的
• 当主节点当掉之后，它会自动的将主节点上的这个IPVS规则给擦除掉
• 同时，虚拟IP会转移到备用服务器节点上
• 同时在备用服务器节点上也会利用IPVS wrapper 模块去启用对应的IPVS规则
• 从而实现了对LVS的一个高可用
• 在这所谓的IPVS规则，其实就是Nginx程序，其实都一样，只是LVS本身它是不需要数据的
• 为什么叫LVS虚拟服务器呢？就是因为它本身不会真正去处理这样一些数据
• 真正的处理这些请求的服务器都会在后面的服务器
• 既然自己本身不处理这个请求，只是把请求转发到后端的很多真实的服务器上
• 这个时候，就需要有一个 Checkers 这样的一个模块
• 这个 Checkers 模块，其实说白了，也就是这台高可用的LBS或者是Nginx服务器
• 能够实现对我们后端提供这种请求处理的真实服务器进行一个健康状态监测
• 比如说，他提供了多种监测方式，如TCP的监测方式，或者是HTTP/SSL检测方式等
• 如果想启用HTTP的监测方式的时候，比如说我这台LBS的服务器，或者是在Nginx的服务器
• 也就是说这台服务器它会定期的通过HTTP的形式发送一个数据包给我后端的每一个应用服务器
• 应用服务器，收到之后会返回一个HTTP的包，如果定期收到回应包是200的
• 就认为后端这台应用服务器是存活着的， 否则认为是 Down掉了
• 这个时候当新的请求过来的时候，这个请求不会再转发到后端这台已经Down掉的服务器上
• KeepAlived 本身针对 LVS能够提供一个健康状态监测的能力
• KeepAlived 本身是为 LBS 高可用设计的，但是它也能够去实现对Nginx的高可用
• 只是说它内置没有这样的模块，需要去写一些辅助脚本来去实现辅助 KeepAlived 进行监测
• 当然它还有其他模块，像内存管理模块，像IO复用模块等等

2 ）核心服务能力

• 第一个就是能够实现对服务器服务的一个故障转移
• 第二个就是通常用于对负载均衡器的高可用
  • 比如说LVS或者是Nginx，HAproxy等等负载均衡器都能够去实现高可用

3 ) 适用的场景

• 高可用 LVS
  • 虚拟IP的转移
  • 生成ipvs规则
  • RS健康状态检测
• 高可用其他服务
  • 虚拟IP的转移
  • 编写脚本实现服务启动/停止

4 ）核心组件

• vrrp stack：vrrp协议的实现
• ipvs wrapper：为集群内的节点生成ipvs规则
• checkers：对集群内所有的RS做健康状态检测
• 控制组件：对配置文件解析和加载

5 ）总结

• KeepAlived 本身就是一个VRRP协议栈的一个实现
• 能够实现对虚拟IP的实时在不同的服务器节点之间转移
• KeepAlived本身是为LVS高可用设计的，但是它也可以去高可用其他的一些服务
• 只是如果说想要去高可用LVS的其他服务的话，必须通过写一些辅助脚本来实现
• 但是要用高层LVS的话，你根本不需要写任何脚本，在配置文件中做就OK了