江苏龙网

  1. 主页 > 生活百科 > >

高可用集群系统如何防止脑裂

脑裂

脑裂（split-brain） ， 指在一个高可用（HA）系统中 ， 当联系着的两个节点断开联系时 ， 本来为一个整体的系统 ， 分裂为两个独立节点 ， 这时两个节点开始争抢共享资源 ， 结果会导致系统混乱 ， 数据损坏 。
对于无状态服务的HA ， 无所谓脑裂不脑裂；但对有状态服务(比如MySQL)的HA ， 必须要严格防止脑裂 。（但有些生产环境下的系统按照无状态服务HA的那一套去配置有状态服务 ， 结果可想而知...）

高可用集群系统如何防止脑裂

文章插图
 
如何防止HA集群脑裂一般采用2个方法
1. 仲裁
当两个节点出现分歧时 ， 由第3方的仲裁者决定听谁的 。这个仲裁者 ， 可能是一个锁服务 ， 一个共享盘或者其它什么东西 。
2. fencing
当不能确定某个节点的状态时 ， 通过fencing把对方干掉 ， 确保共享资源被完全释放 ， 前提是必须要有可靠的fence设备 。
理想的情况下 ， 以上两者一个都不能少 。
但是 ， 如果节点没有使用共享资源 ， 比如基于主从复制的数据库HA ， 我们也可以安全的省掉fence设备 ， 只保留仲裁 。而且很多时候我们的环境里也没有可用的fence设备 ， 比如在云主机里 。
那么可不可以省掉仲裁 ， 只留fence设备呢？
不可以 。因为 ， 当两个节点互相失去联络时会同时fencing对方 。如果fencing的方式是reboot ， 那么两台机器就会不停的重启 。如果fencing的方式是power off ， 那么结局有可能是2个节点同归于尽 ， 也有可能活下来一个 。但是如果两个节点互相失去联络的原因是其中一个节点的网卡故障 ， 而活下来的正好又是那个有故障的节点 ， 那么结局一样是悲剧 。
所以 ， 单纯的双节点 ， 无论如何也防止不了脑裂 。
没有fence设备是否安全以PostgreSQL或MySQL的数据复制为例来说明这个问题 。
在基于复制的场景下 ， 主从节点没有共享资源 ， 所以2个节点都活着本身没有问题 。问题是客户端会不会访问到本该死掉的那个节点 。这又牵扯到客户端路由的问题 。
客户端路由有几种方式 ， 基于VIP ， 基于Proxy ， 基于DNS或者干脆客户端维护一个服务端地址列表自己判断主从 。不管采用哪种方式 ， 主从切换的时候都要更新路由 。
基于DNS的路由是不太靠谱的 ， 因为DNS可能会被客户端缓存 ， 很难清干净 。
基于VIP的路由有一些变数 ， 如果本该死掉的节点没有摘掉自己身上的VIP ， 那么它随时可能出来捣乱（即使新主已经通过arping更新了所有主机上的arp缓存 ， 如果某个主机的arp过期 ， 发一个arp查询 ， 那么就会发生ip冲突） 。所以可以认为VIP也是一种特殊的共享资源 ， 必需把它从故障节点上摘掉 。至于怎么摘 ， 最简单的办法就是故障节点发现自己失联后自己摘 ， 如果它还活着的话（如果它死了 ， 也就不用摘了） 。如果负责摘vip的进程无法工作怎么办？这时候就可以用上本来不太靠谱的软fence设备了(比如ssh) 。
基于Proxy的路由是比较靠谱的 ， 因为Proxy是唯一的服务入口 ， 只要把Proxy一个地方更新了 ， 就不会发生客户端误访问的问题了 ， 但是也要考虑Proxy的高可用 。
至于基于服务端地址列表的方法 ， 客户端需要通过后台服务判断主从（比如PostgreSQL/MySQL会话是否处于只读模式） 。这时 ， 如果出现2个主 ， 客户端就会错乱 。为防止这个问题 ， 原主节点发现自己失联后要自己把服务停掉 ， 这和前面摘vip的道理是一样的 。
因此 ， 为了不让故障节点捣乱 ， 故障节点应该在失联后自己释放资源 ， 为了应对释放资源的进程本身出现故障 ， 可以加上软fence 。在这个前提下 ， 可以认为没有可靠的物理fence设备也是安全的 。
主从切换后数据能否保证不丢主从切换后数据会不会丢和脑裂可以认为是2个不同的问题 。还以PostgreSQL或MySQL的数据复制为例来说明 。
对PostgreSQL ， 如果配置成同步流复制 ， 可以做到不管路由是否正确 ， 都不会丢数据 。因为路由到错误节点的客户端根本写不进任何数据 ， 它会一直等待从节点的反馈 ， 而它以为的从节点 ， 现在已经是主子了 ， 当然不会理它 。当然如果老是这样也不好 ， 但它给集群监视软件纠正路由错误提供了充足的时间 。


推荐阅读


上一篇：工作3年和工作7年的程序员到底差在哪里？

下一篇：密封盒漏水是不是密封性不好 密封罐密封不好是什么原因