Windows或Linux集群的心跳机制,失效备援和仲裁机制
Evidian SafeKit
Windows和Linux集群的心跳机制与失效备援是怎样的
同步两台服务器和发现服务器失效的基础机制就是心跳,它是在被一对服务器共享的网络上的监控数据流。
SafeKit软件支持同两台服务器的共享网络数量一致的心跳数量。心跳机制是用来实施Windows和Linux集群的。它整合在镜像集群架构中的。
在通常的操作中,两台服务器通过心跳渠道交换它们的状态(主的,次的,资源状态)并同步它们的启动和停止应用程序。尤其当因为软件失效或手工操作时导致的一个失效备援时,用来停止应用的脚本,在次服务器上执行前,首先在主服务器上执行。这样,对应于一个应用程序完全停止,次服务器上的复制数据总处于一个安全状态。
如果本地服务器无法接受到任何心跳数据,就会认为另一台服务器已经停机,这样,本地服务器会切换到ALONE状态。如果次要服务器进入ALONE状态,这个应用失效备援会由次要服务器上的应用重新启动来完成。尽管不是必要的,但最好有两个心跳渠道在两个不同的网络间同步两个服务器,用以区分网络故障和服务器故障。
服务器在两个远程机房时的集群仲裁问题
大多情况下,一个保障数据中心的关键应用的HA集群会被安装在两个不同地区的两个机房的两台服务器上,用以支持整个机房发生灾难。
如果两个机房同时发生短暂网络掉线,裂脑(split brain)问题就会出现。两个服务器都可能会重新启动关键应用。
在使用一个硬件恢复集群时,这个现象必须避免发生,因为双执行意味着并发访问共享磁盘和关键应用数据的潜在的损坏。 这就是为什么仲裁集群要用第三个仲裁服务器实现,甚至远程硬件重置去避免对关键应用的并发执行。
不幸的是这个新的仲裁设备会给整体集群架构增加费用和复杂性。而且系统对冻结操作系统不免疫:当操作系统从冻结恢复时,会有双重的应用执行,即使使用了上述机制。
使用SafeKit的简单的集群仲裁
使用SafeKit HA软件,Windows和Linux集群内的仲裁不要求第三台仲裁服务器,仲裁硬盘或远程硬件重置。一个简单的网络检查器对于SafeKit仲裁就足够了。
无论如何SafeKit HA集群支持对关键应用的双重执行而不破坏数据。
如果发生操作系统冻结或网络离线,而没有在仲裁上的网络检查器,主服务器将在独立状态下继续运行应用。次要服务器将重新启动应用并将进入一个独立状态。复制的路径将被隔离,每个运行的应用将在他们自己的路径的自己的数据中工作。
当网络重新连接后,两台服务器中一个应用必须被牺牲地关掉。在关掉一台服务器的应用后,该操作会使数据从另一台服务器上重新导入。重新导入后,数据又立刻重新处于在首要和次要服务器之间的镜像模式。
所有这些操作都是自动的。心跳,恢复和仲裁管理都融入于SafeKit产品的集群中,且对SafeKit的用户是透明的。因此,无特殊技能的用户可以在两台标准服务器的当地或远程服务器上进行SafeKit部署。而且,其配置同于Windows或Linux集群。
在N服务器上部署一个farm模块,并实施一个网络负载均衡集群 |
|
Windows farm |
Linux farm |
Generic Windows farm > | Generic Linux farm > |
Microsoft IIS > | - |
NGINX > | |
Apache > | |
Amazon AWS farm > | |
Microsoft Azure farm > | |
Google GCP farm > | |
Other cloud > |
不同的软件集群
SafeKit提供两个基础软件集群:镜像集群和farm 集群。几种应用模块可以配置在同一个软件集群上。因此,高级集群架构可以被实施:混合farm/mirror,active/active 或N-1。
Hyper-V Cluster (英语)
This video shows a Hyper-V cluster with full replication of virtual machines.
This is a typical architecture with high availability at the virtual machine level, with no need to write restart scripts per application. Hyper-V and KVM are supported, but VMware is not included in this configuration.
Virtual machines can run on both Hyper-V servers and they are restarted in case of failure.
Microsoft SQL Server Cluster (英语)
This video shows a mirror module configuration with synchronous real-time replication and failover.
This is a typical architecture with high availability at the application level, utilizing restart scripts per application (here SQL service). It is independent of the underlying infrastructure, whether it be physical machines or virtual machines under any hypervisor, including VMware.
做正确的选择
在市场上有很多种类的高可用方案,这些方案中,SafeKit的特点就是下面所介绍的简便性。您可以下载这个高可用性手册来选择适合您的关键应用的解决方案。
软件集群vs硬件集群
当您建立一个集群服务器时,有两个选择:一个像SafeKit的软件集群,或是一个硬件集群。相比之下SafeKit的实施会简单得多。
无共享vs硬盘共享集群
SafeKit是一个不共享集群而非硬盘共享集群。由于不需配置共享硬盘,服务器可以很容易地安装在远程计算机房,同时不需要SAN和可复制的硬盘阵列。
虚拟高可用 vs应用高可用
虚拟高可用在虚拟机级别上实现高可用,而应用高可用在应用级别实现高可用。在虚拟高可用和应用高可用之间做选择,请阅读这篇文章。
文件复制vs硬盘复制
不同于硬盘复制,在使用文件复制时,您仅仅需要确定您想实时复制的文件的路径就可以了。SafeKit是一个基于文件复制的方案。因此不需要配置特殊的硬盘就能够实现全部复制。
同步复制vs异步配置
如果您选择了SafeKit的同步复制而非异步复制,那么失效备援发生时您就不会再有任何的数据丢失。
没有网络先决条件的网络负载平衡
在VMware里,SafeKit是微软NLB的多播或单播的替代品,它不需要特殊的网络配置。并且,它可以在Windows,和Linux上运行。
SafeKit的高可用性架构
- 在两台服务器上部署一个镜像模块,并实施一个块级别和文件级的软件数据复制。
- 在N服务器上部署一个farm模块,并实施一个网络负载均衡集群。
- 部署一个镜像模块+一个farm模块,并实施一个负载均衡与镜像集群方案。
- 部署两个镜像模块,并实施一个active-active交叉数据复制集群。