本节包含两个可用性策略示例,基于员工数为 1,000 至 5,000 人的中型企业基于身份的通信解决方案,如先前在基于身份的通信示例一节中所述。第一个可用性策略说明了用于 Messaging Server 的负载平衡。第二个说明了使用 Sun Cluster 软件实现故障转移的解决方案。
下表中列出了逻辑体系结构中每个逻辑 Messaging Server 组件的 CPU 能力估计。此表重复了在更新 CPU 数量估计一节中计算出的最终估计数量。
表 5–6 支持组件的 CPU 数量估计调整
组件 |
CPU |
内存 |
---|---|---|
Messaging Server(MTA,入站) |
2 |
4 GB |
Messaging Server(MTA,出站) |
2 |
4 GB |
Messaging Server (MMP) |
2 |
4 GB |
Messaging Server (Message Store) |
2 |
4 GB |
对于本例,假设在技术要求阶段指定了下列服务质量要求:
可用性。总体系统可用性应为 99.99%(不包括计划停机)。单个计算机系统故障不会导致服务故障。
可伸缩性。日常峰值负载情况下,任何服务器的使用量都不应超过 80%,而且系统必须能够适应每年 10% 的长期增长速度。
为满足可用性要求,应为每个 Messaging Server 组件提供两个实例,每一个都位于不同的硬件服务器上。如果一个组件的服务器发生故障,另一个组件可提供服务。下图显示了此可用性策略的网络示意图。
上图中,CPU 数量为原估计数量的两倍。CPU 数量加倍的原因如下:
在一台服务器发生故障的情况下,另一台服务器提供处理负载的 CPU 能力。
对于任何服务器在峰值负载下利用程度不超过 80% 的可伸缩性要求,添加的 CPU 能力可提供此保险余量。
对于适应年增长 10% 负载的可伸缩性要求,添加的 CPU 能力增加了潜在容量,在需要另外扩大规模之前可用于处理增长的负载。
下图显示了一个对 Calendar Server 后端和 Messaging Server 消息存储实施故障转移策略的示例。Calendar Server 后端和消息存储都在单独的硬件服务器上复制,并且使用 Sun Cluster 软件配置了故障转移。Sun Cluster 中每台服务器上的 CPU 数量和相应内存都被复制。
可对目录服务进行复制,以便在不同服务器间分配事务,从而提供高可用性。Directory Server 提供各种复制服务策略,其中包括:
多数据库。在不同数据库中存储目录树的不同部分。
链锁和引用。将分布数据链接到单个目录树。
单主复制。为主数据库提供一个中心源,然后将该中心源分配到使用者副本中。
多主复制。在多个服务器间分配主数据库。然后,这些主中的每一个都在使用者副本中分配其各自的数据库。
Directory Server 的可用性策略是个复杂的问题,不在本指南的讨论范围之内。以下两节,单主复制和多主复制提供了对基本复制策略的概括说明。有关详细信息,参见《Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide》的第 12 章 "Designing a Highly Available Deployment"。
下图显示了一个说明基本复制概念的单主复制策略。
在单主复制中,一个 Directory Server 实例管理主目录数据库,并记录所有变化。主数据库被复制为任意数量的使用者数据库。Directory Server 的使用者实例按读取和搜索操作进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。
单主复制的优点包括:
为数据库读取和写入操作优化了单个 Directory Server
为读取和搜索操作优化了任意数量的 Directory Server 使用者实例
Directory Server 使用者实例的水平可伸缩性
下图显示了一个可用于全局分配目录访问的多主复制策略。
在多主复制中,一个或多个 Directory Server 实例管理主目录数据库。每个主数据库都有一个指定同步主数据库的过程的复制协议。每个主数据库都被复制为任意数量的使用者数据库。与单主复制相同,Directory Server 的使用者实例都按读取和搜索访问进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。
多主复制策略除具有单主复制的所有优点之外,还提供了一个在更新主数据库时提供负载平衡的可用性策略。还可以实现一个对目录操作提供本地控制的可用性策略,这对于在全球分布数据中心的企业是一个很重要的考虑事项。