可通过多种方法配置高可用性。本节包括三种高可用性选择的概述以及有助于您选择最合适的高可用性的信息。
本节包含以下主题:
简单的非对称高可用性系统拥有两个物理节点。主节点通常为活动状态,另一个节点则充当备份节点,随时准备在主节点失败时接管主节点。要完成故障转移,切换共享磁盘阵列以使其由备份节点控制。Calendar Server 进程于失败的主节点上停止,然后在备份节点上启动。
此类型的高可用性系统具有多种优点。一个优点是备份节点是专门为主节点所保留的。这就意味着在发生故障转移时,备用节点上不会出现资源争用问题。另一个优点是可执行滚动升级;即可在升级一个节点的同时在另一节点上继续运行 Calendar Server 软件。在升级第一个节点时对 ics.conf 文件所做的更改不会影响在辅助节点上运行的其他 Calendar Server 软件实例,因为只会在启动时读取一次配置文件。要使新配置生效,必须先停止并重新启动日历进程。要升级另一个节点,可对升级后的主节点执行故障转移,然后在辅助节点上继续进行升级。
当然,也可以先升级辅助节点,再升级主节点。
非对称高可用性模型也具有一些缺点。一个缺点是备份节点大部分时间都处于闲置状态,因此资源未得到充分利用。另一个可能的缺点是单存储阵列。如果简单非对称高可用性系统的磁盘阵列发生故障,将无法进行备份。
简单对称高可用性系统拥有两个活动的物理节点,每个节点都拥有各自的磁盘阵列。磁盘阵列包含两个存储卷,一个卷用作本地日历存储库,另一个卷则为另一节点的日历存储库的镜像映像。每个节点都可作为另一节点的备份节点。当某个节点故障转移至其备份节点时,两个 Calendar Server 实例会在备份节点上并发运行,且每个实例都会从其自身的安装目录运行并访问其自身的日历存储库。它们唯一共享的是备份节点的计算能力。
此类型的高可用性系统的优点是两个节点同时处于活动状态,因此充分利用了计算机资源。但是,发生故障时,备用节点会出现多个资源争用情况,因为它运行了两个节点的 Calendar Server 服务。
对称高可用性也提供备份存储阵列。如果磁盘阵列失败,可通过其备份节点上的服务来获取其冗余映像。
要配置对称高可用性系统,需在共享磁盘上安装 Calendar Server 二进制文件。这样做可能无法执行滚动升级,它是一种面向未来 Calendar Server 版本的功能,通过该功能可使用 Calendar Server 修补程序在最少停机时间或无停机时间的情况下更新系统。
除本章中描述的两类高可用性系统外,还存在第三种类型,它由前两类混合而成。它是一种多节点非对称高可用性系统。在此类系统中,“N”个磁盘阵列和“N”个节点都使用相同的备份节点,而此备份节点处于保留状态且通常不处于活动状态。此备份节点可为任意“N”节点运行 Calendar Server。它共享每个“N”节点的磁盘阵列,如上图中所示。如果多个节点同时失败,则备份节点必须能同时运行“N”个 Calendar Server 实例。每个“N”节点都拥有自身的磁盘阵列。
N+1 模型的优点是可将 Calendar Server 负载分发到多个节点,并且只需一个备份节点即可应对所有可能出现的节点故障。
此类高可用性的缺点与所有非对称系统相同;即备份节点在大部分时间都处于闲置状态。此外,当 N+1 高可用性系统备份节点必须托管多个 Calendar Server 实例时,它必须具有其他功能。这就意味着将闲置一个更加昂贵的计算机。但是,计算机的闲置率将为 1:N 而不是 1:1(它是单个非对称系统的闲置率)。
要配置此类系统,可参考每个“N”节点及备份的非对称高可用性系统的说明。每次使用相同的备份节点,但使用不同的主节点。
下表汇总了每种高可用性模型的优缺点。此信息有助于确定最适合自身部署的模型。
表 6–1 高可用性模型的优缺点
下表列出了在任意指定的一天由于系统故障而无法使用日历服务的概率。这些计算假定每个服务器平均每三个月会有一天由于系统崩溃或服务器挂起而停机,每个存储设备平均每 12 个月会停机一天。不过,这些计算忽略了两个节点同时停机的状况,因为其可能性很小。
表 6–2 系统停机时间计算
模型 |
服务器停机时间概率 |
单个服务器(无高可用性) |
Pr(down) =(4 天系统停机 + 1 天存储设备停机)/365 = 1.37% |
非对称 |
Pr(down) =(0 天系统停机 + 1 天存储设备停机)/365 = 0.27% |
对称 |
Pr(down) =(0 天系统停机 + 0 天存储设备停机)/365 =(接近 0) |
N + 1 非对称 |
Pr(down) =(5 小时系统停机 + 1 天存储设备停机)/(365xN) = 0.27%/N |