Windows或Linux集群的心跳机制，失效备援和仲裁机制

Windows和Linux集群的心跳机制与失效备援是怎样的

同步两台服务器和发现服务器失效的基础机制就是心跳，它是在被一对服务器共享的网络上的监控数据流。

SafeKit软件支持同两台服务器的共享网络数量一致的心跳数量。心跳机制是用来实施Windows和Linux集群的。它整合在镜像集群架构中的。

在通常的操作中，两台服务器通过心跳渠道交换它们的状态（主的，次的，资源状态）并同步它们的启动和停止应用程序。尤其当因为软件失效或手工操作时导致的一个失效备援时，用来停止应用的脚本，在次服务器上执行前，首先在主服务器上执行。这样，对应于一个应用程序完全停止，次服务器上的复制数据总处于一个安全状态。

如果本地服务器无法接受到任何心跳数据，就会认为另一台服务器已经停机，这样，本地服务器会切换到ALONE状态。如果次要服务器进入ALONE状态，这个应用失效备援会由次要服务器上的应用重新启动来完成。尽管不是必要的，但最好有两个心跳渠道在两个不同的网络间同步两个服务器，用以区分网络故障和服务器故障。

服务器在两个远程机房时的集群仲裁问题

大多情况下，一个保障数据中心的关键应用的HA集群会被安装在两个不同地区的两个机房的两台服务器上，用以支持整个机房发生灾难。

如果两个机房同时发生短暂网络掉线，裂脑（split brain）问题就会出现。两个服务器都可能会重新启动关键应用。

在使用一个硬件恢复集群时，这个现象必须避免发生，因为双执行意味着并发访问共享磁盘和关键应用数据的潜在的损坏。 这就是为什么仲裁集群要用第三个仲裁服务器实现，甚至远程硬件重置去避免对关键应用的并发执行。

不幸的是这个新的仲裁设备会给整体集群架构增加费用和复杂性。而且系统对冻结操作系统不免疫：当操作系统从冻结恢复时，会有双重的应用执行，即使使用了上述机制。

如果发生操作系统冻结或网络离线，而没有在仲裁上的网络检查器，主服务器将在独立状态下继续运行应用。次要服务器将重新启动应用并将进入一个独立状态。复制的路径将被隔离，每个运行的应用将在他们自己的路径的自己的数据中工作。

当网络重新连接后，两台服务器中一个应用必须被牺牲地关掉。在关掉一台服务器的应用后，该操作会使数据从另一台服务器上重新导入。重新导入后，数据又立刻重新处于在首要和次要服务器之间的镜像模式。

所有这些操作都是自动的。心跳，恢复和仲裁管理都融入于SafeKit产品的集群中，且对SafeKit的用户是透明的。因此，无特殊技能的用户可以在两台标准服务器的当地或远程服务器上进行SafeKit部署。而且，其配置同于Windows或Linux集群。