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原理