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