在解决方案生命周期的部署设计阶段,需要设计一个高层部署体系结构和一个低层实现规范,并准备一系列实现该解决方案所必需的计划和规范。项目核准出现在部署设计阶段。
本章包括以下部分:
部署设计始于解决方案生命周期的逻辑设计和技术要求阶段创建的部署方案。部署方案包括逻辑体系结构和解决方案的服务质量 (Quality of Service, QoS) 要求。通过在物理服务器和其他网络设备之间映射在逻辑体系结构中确定的组件,从而创建部署体系结构。要求对硬件配置提供了指导,以满足性能、可用性、可伸缩性和其他相关规范。
部署体系结构的设计是一个反复进行的过程。通常要复查要求和初步设计。要考虑不同要求之间的相互关系,对折衷和拥有成本问题进行平衡以获得最佳解决方案,最终满足该项目的业务目标。
项目核准出现在部署设计阶段,通常在创建部署体系结构之后。使用部署体系结构(还可能用到下述的实现规范)对部署的实际成本进行估计,并提交给风险承担者进行核准。项目一经核准,即签署部署完成合同,并获取和分配项目实现所需的资源。
在部署设计阶段,可能需要准备下列规范和计划:
部署体系结构。描述逻辑体系结构域物理环境的映射关系的高层体系结构。物理环境包括内联网或 Internet 环境中的计算节点、处理器、内存、存储器设备及其他硬件和网络设备。
实现规范。用作构建部署蓝图的详细规范。这些规范提供了计算机和网络硬件的细节,用于获取和描述部署的网络布局。实现规范还包括目录服务的规范,其中包括目录信息树的更多信息及为目录访问定义的组和角色。
实现计划。包含实现企业软件解决方案各个方面的一组计划。实现计划包括以下各项:
迁移计划。描述迁移企业数据和升级企业软件的策略和进程。迁移的数据必须符合新安装的企业应用程序的格式和标准。所有企业软件必须为正确的发行版本级别,才能进行交互操作。
安装计划。源自部署体系结构,用于指定硬件服务器名称、安装目录、安装顺序、每个节点的安装类型以及安装和配置分布式部署所必需的配置信息。
用户管理计划。包括现有目录和数据库中的数据的迁移策略、考虑到部署体系结构中指定的复制设计的目录设计规范以及使用新内容置备目录的过程。
测试计划。描述测试已部署软件的过程,包括用于开发原型和试验性实现的具体计划、确定处理预测负载的能力的负载测试以及确定计划的功能是否按预期运行的功能性测试。
展开计划。描述实现从计划和测试环境转向生产环境的过程和时间表。将实现转向生产的过程通常出现在不同阶段。例如,第一个阶段可能是为有限的用户组部署软件,在随后的每一阶段逐渐增加用户群体,直到整个部署完成。分阶段实现还可包括按计划实现特定软件包,直到整个部署完成。
有几个影响部署设计过程中所作决策的因素。请考虑下列关键因素:
逻辑体系结构。逻辑体系结构详细说明了提议解决方案中的功能性服务以及提供这些服务的组件之间的相互关系。将逻辑体系结构用作确定分配服务最佳方式的关键。部署方案包括逻辑体系结构及与之相对应的服务质量要求(如下所述)。
服务质量要求。服务质量 (Quality of Service, QoS) 要求指定解决方案操作的各个方面。使用 QoS 要求有助于开发策略,以期达到性能、可用性、可伸缩性、可维护性及其他服务质量目标。部署方案包括逻辑体系结构(如前所述)及与之对应的服务质量要求。
用量分析。在解决方案生命周期的技术要求阶段开发用量分析,从而提供有助于估计已部署系统负载的使用模式的信息。用量分析的使用有助于隔离性能瓶颈,开发出满足 QoS 要求的策略。
使用案例。在解决方案生命周期的技术要求阶段开发使用案例,列出为某一部署确定的独特用户交互,通常确定最常见的使用案例。尽管使用案例已包含在用量分析中,但评估部署设计时,应参考使用案例,确保它们已妥善解决。
服务级别协议。服务级别协议 (Service Level Agreement, SLA) 指定了最低性能要求以及未能满足此要求时必须提供的客户支持级别和程度。部署设计应能轻松满足服务级别协议中指定的性能要求。
总拥有成本。在部署设计期间,分析能够解决可用性、性能、可伸缩性等 QoS 要求的潜在解决方案。但是,对于所考虑的每个解决方案,必须同时考虑该解决方案的成本及该成本影响总拥有成本的程度。请确保考虑决策中涉及到的折衷,并且已对资源进行了优化,能够在业务约束范围内达到业务需求。
业务目标。业务目标始于解决方案生命周期的业务分析阶段,包括实现这些目标的业务需求和业务约束。最终将根据部署设计满足业务目标的能力对其进行评判。
与部署规划的其他方面一样,部署设计不仅是一门科学,也是一门艺术,不能用特定的步骤和过程来详细规定。以往的设计经验、系统体系结构知识和特定领域知识的掌握以及发挥创造性思维,这些都是成功完成部署设计的因素。
部署设计通常围绕满足其他 QoS 要求的同时达到性能要求而展开。采用的策略必须对设计决策中的各种折衷进行平衡,以期优化解决方案。使用的方法通常涉及下列任务:
估计处理器要求。部署设计通常从估计逻辑体系结构中每个组件所需的 CPU 数量开始。始于代表最大负载的使用案例,然后继续考虑每个使用案例。考虑对使用案例提供支持的所有组件上的负载,并相应地修改您的估计。还应考虑您在设计企业系统方面的任何以往经验。
复制服务以实现可用性和可伸缩性。对处理器估计感到满意后,请针对可用性和可伸缩性方面的 QoS 要求来修改设计。考虑能够解决可用性和故障转移事项的负载平衡解决方案。
分析时应考虑设计决策的折衷问题。例如,可用性与可伸缩性策略对系统的可维护性(维护)有什么影响?这些策略的其他成本是什么?
本节讨论了估计支持部署设计中的服务所必需的 CPU 处理器数量和相应内存的过程。本节包括一个示例通信部署方案估计过程的演练。
估计 CPU 计算能力是一个不断反复的过程,要考虑下列方面:
逻辑组件及它们之间的交互(由逻辑体系结构中的组件依赖性表示)
已确定使用案例的用量分析
服务质量要求
以往部署设计和使用 Java Enterprise System 的经验
咨询具有设计和实现各类部署方案经验的 Sun 专业服务机构
估计过程包括下列步骤。这些步骤的执行顺序并非关键所在,这一顺序只是提供了考虑可对最终结果产生影响的因素的一种方式。
给确定为用户的系统入口点的组件确定 CPU 数量估计底线。
一个设计决策是完全加载还是部分加载 CPU。完全加载 CPU 可使系统容量最大化。要增加容量,需要添加额外的 CPU,从而增加了维护成本及停机的可能性。某些情况下,可以选择添加其他计算机来满足不断增长的性能要求。
部分加载 CPU 为处理超额性能要求预留了余地,无需立即增加维护成本。不过,这种未充分利用的系统却附加了提前的费用开销。
对 CPU 数量估计进行调整,将组件间的交互考虑在内。
研究逻辑体系结构中组件之间的交互,确定相关组件要求的额外负载。
研究特定使用案例的用量分析,确定系统的峰值负载,然后对处理峰值负载的组件进行调整。
从最大加权的使用案例(要求最多负载)开始,然后考察每个使用案例,确保考虑了所有的预测使用方案。
对 CPU 数量估计进行调整,将安全性、可用性和可伸缩性要求考虑在内。
此估计过程是确定所需实际处理能力的起点。通常,根据这些估计创建原型部署,然后对预期使用案例执行严格的测试。只有经过反复的测试,才能确定部署设计的实际处理要求。
本节说明了一种对示例部署所需处理能力进行估计的方法。该示例部署基于员工数为 1,000 到 5,000 人的中型企业基于身份的通信解决方案的逻辑体系结构,如基于身份的通信示例一节所述。
本例中使用的 CPU 和内存数字都只是说明性的随意估计。这些数字基于本理论性示例所依据的任意数据。要估计处理器要求,有必要对各种因素进行彻底分析。此分析将包括(但不限于)下列信息:
基于彻底的业务分析的详细使用案例和用量分析
通过对业务需求分析而确定的服务质量要求
处理和网络硬件的特定成本和规范
实现类似部署的以往经验
这些示例中提供的信息用于说明设计系统时可能使用的一种过程,并不代表任何具体的实现建议。
先估计处理每个作为用户入口点的组件的预期负载所需的 CPU 数量。下图显示了一种基于身份的通信方案的逻辑体系结构,先前在基于身份的通信示例一节中有所介绍。
下表列出该逻辑体系结构中与此部署的终端用户直接接口的表示层中的组件。该表包括 CPU 数量估计底线,这些估计源自技术要求分析、使用案例、特定用量分析以及此类型部署的以往经验。
表 5–1 包含用户入口点组件的 CPU 数量估计
组件 |
CPU 数量 |
说明 |
---|---|---|
Portal Server |
4 |
作为用户入口点的组件。 |
Communications Express |
2 |
将数据发送到 Portal Server 消息传送和日历频道。 |
提供用户入口点的组件需要其他 Java Enterprise System 组件的支持。为继续指定性能要求,进行性能估计时请将其他 Java Enterprise System 组件要求的支持考虑在内。设计逻辑体系结构时,应详细说明组件之间的交互类型,如逻辑体系结构示例一节中的逻辑体系结构示例所述。
表 5–2 支持组件的 CPU 数量估计
组件 |
CPU |
说明 |
---|---|---|
Messaging Server MTA(入站) |
1 |
路由来自 Communications Express 和电子邮件客户机的入内邮件消息。 |
Messaging Server MTA(出站) |
1 |
将出外邮件消息发送给收件人。 |
1 |
访问电子邮件客户机的 Messaging Server 消息存储。 |
|
1 |
检索和存储电子邮件消息。 |
|
2 |
提供授权和验证服务。 |
|
2 |
检索和存储 Calendar Server 前端 Communications Express 的日历数据。 |
|
2 |
提供 LDAP 目录服务。 |
|
0 |
提供对 Portal Server 和 Access Manager 的 Web 容器支持。 (无需附加 CPU 周期。) |
返回使用案例和用量分析,确定峰值负载用量的区域,并对 CPU 数量估计进行调整。
例如,假设本例中确定如下峰值负载情况:
同时登录时用户数的初始激增
在指定期限内交换电子邮件
要考虑此峰值负载用量,应调整提供这些服务的组件。下表概述了考虑此峰值负载用量时可能要做的调整。
表 5–3 针对峰值负载进行的 CPU 数量估计调整
组件 |
CPU(调整后) |
说明 |
---|---|---|
Messaging Server 入站 MTA |
2 |
为峰值外来电子邮件添加 1 个 CPU |
Messaging Server 出站 MTA |
2 |
为峰值出外电子邮件添加 1 个 CPU |
Messaging Server MMP |
2 |
为附加负载添加 1 个 CPU |
Messaging Server STR(消息存储) |
2 |
为附加负载添加 1 个 CPU |
Directory Server |
3 |
为附加 LDAP 查找添加 1 个 CPU |
继续进行 CPU 数量估计,将影响负载的其他服务质量要求考虑在内:
安全。从技术要求阶段开始,确定安全数据传输可能对负载要求的影响程度,并对估计进行相应修改。下一节估计安全事务的处理器要求中,介绍了进行调整的过程。
复制服务。调整 CPU 数量估计,将用于可用性、负载平衡和可伸缩性的复制服务的情况考虑在内。下一节确定可用性策略中,讨论了对可用性解决方案的估量。确定可伸缩性策略一节中讨论了涉及目录服务可用性访问的解决方案。
潜在容量和可伸缩性。根据需要修改 CPU 数量估计,为部署中的意外大型负载预留潜在容量。查看预计的扩展重大事件点及相应时段的预计负载增量,确保满足任何水平或垂直扩展系统的重大事件点的要求。
通常将 CPU 数量向上舍入到最近的偶数。向上舍入到偶数可在两个物理服务器间均匀分布分摊 CPU 数量估计,而且也为潜在容量增加了一个小因素。但是,应根据对复制服务的特定需要进行舍入。
一般规则是为每个 CPU 预留 2 GB 内存。实际所需的内存取决于您的特定用量,可以通过测试确定。
下表列出了该基于身份的通信示例的最终估计。这些估计值不包括任何额外计算能力(已在安全性和可用性中添加)。安全性和可用性的总数将在后续各节添加。
表 5–4 支持组件的 CPU 数量估计调整
组件 |
CPU |
内存 |
---|---|---|
Portal Server |
4 |
8 GB |
Communications Express |
2 |
4 GB |
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 |
Access Manager |
2 |
4 GB |
Calendar Server |
2 |
4 GB |
Directory Server |
4 |
8 GB(从 3 CPU/6 GB 内存向上舍入) |
Web Server |
0 |
0 |
安全数据传输涉及通过安全传输协议(如安全套接字层 (Secure Sockets Layer, SSL) 或传输层安全 (Transport Layer Security, TLS))处理事务。通过安全传输处理的事务通常需要额外的计算能力先建立安全会话(称为握手),然后对传输的数据进行加密和解密。额外的计算能力要求可能相当大,这取决于所使用的加密算法(例如,40 位还是 128 位加密算法)。
为使安全事务具有与非安全事务相同水平的性能,必须对额外计算能力进行规划。安全事务可能需要高于非安全事务四倍(甚至更多倍)的计算能力,具体取决于事务的性质和处理事务的 Sun JavaTM Enterprise System 服务。
估计处理安全事务的处理能力时,首先要分析使用案例来确定需要安全传输的事务所占的百分比。如果安全事务的性能要求与非安全事务相同,则需修改 CPU 数量估计,将安全事务所需的额外计算能力考虑在内。
在某些使用方案中,可能只有在验证时才需要进行安全传输。用户通过系统验证后,便不需要对数据传输采取额外安全措施。但在其他方案中,可能所有事务都需要安全传输。
例如,浏览在线电子商务站点的产品目录时,客户完成商品挑选并准备“付帐”前,所有事务都可以是非安全的。不过,某些使用方案(如银行或证券经纪行部署)要求大多数或全部事务必须为安全事务,并对安全与非安全事务有着相同的性能标准。
本节将继续使用示例部署,说明如何计算得出既包括安全事务又包括非安全事务的理论性使用案例所需的 CPU 数量。
要估计安全事务的 CPU 数量要求,请进行以下计算:
以 CPU 数量估计底线数(如上一节示例的估计处理器要求中计算的数字)作为起始数量。
计算需要安全传输的事务的百分比,然后计算安全事务的 CPU 数量估计。
计算非安全事务减少的 CPU 数量估计。
将安全和非安全数量估计相加,计算出总 CPU 数量估计。
将 CPU 数量估计向上舍入到最近的偶数。
安全事务的 CPU 数量估计显示了一个基于 Portal Server 的使用案例和用量分析的示例计算,其中假设:
所有登录均要求安全验证。
所有登录占 Portal Server 总负载的 10%。
安全事务的性能要求与非安全事务相同。
要将处理安全事务的额外计算能力考虑在内,处理这些事务的 CPU 数量将增加为四倍。与本例中其他 CPU 数字一样,该倍数也只是说明性的随意倍数。
步骤 |
说明 |
计算 |
结果 |
---|---|---|---|
1 |
以所有 Portal Server 事务的估计底线作为起始数量。 |
研究峰值负载用量的使用案例中的估计底线为 4 个 CPU。 |
- - - - - |
2 |
计算安全事务的附加 CPU 数量估计。假设安全事务需要的 CPU 能力为非安全事务的四倍。 |
估计底线的百分之十需要安全传输:
0.10 x 4 CPU = 0.4 CPU
将安全事务的 CPU 能力增加为四倍:
4 x 0.4 = 1.6 CPU |
1.6 个 CPU |
3 |
计算非安全事务减少的 CPU 数量估计。 |
估计底线的百分之九十为非安全传输:
0.9 x 4 CPU = 3.6 CPU |
3.6 CPU |
4 |
计算调整后的安全与非安全事务的 CPU 数量估计总数。 |
安全数量估计非安全数量估计总数:
1.6 CPU + 3.6 CPU = 5.2 CPU |
5.2 CPU |
5 |
向上舍入到最近的偶数。 |
5.2 CPU ==> 6 CPU |
6 CPU |
根据本例中的安全事务计算,通过添加额外的两个 CPU 和 4 GB 内存,修改安全事务的 CPU 数量估计中的总 CPU 数量估计,得到以下用于 Portal Server 的总数。
组件 |
CPU |
内存 |
---|---|---|
Portal Server |
6 |
12 GB |
可以利用专用硬件设备(如 SSL 加速卡和其他装置)提供建立安全会话和加密与解密数据所需的计算能力。使用专用硬件进行 SSL 运算时,计算能力专用于 SSL 计算的特定部分,通常是建立安全会话的“握手”运算。
这种硬件可能会对最终部署体系结构有益。不过,由于此类硬件的专用化性质,最好先以 CPU 能力估计出安全事务的性能要求,然后再考虑使用专用硬件处理额外负载的益处。
使用专用硬件时应考虑的一些因素有:使用案例(例如,要求大量 SSL 握手运算的使用案例)是否支持使用该硬件及使用此类硬件给设计增添的复杂性。这种复杂性包括这些设备的安装、配置、测试和管理。
开发可用性要求策略时,应研究组件交互和用量分析,以确定要考虑的可用性解决方案。对组件进行逐个分析,以确定最适合可用性和故障转移要求的解决方案。
下列项目是为帮助确定可用性策略而需收集的信息类型的示例:
指定的可用性中有多少个九?
故障转移情况下的性能要求(例如,故障转移期间至少保持 50% 的性能)是什么?
用量分析是否区分高峰和非高峰使用时间?
地域考虑因素有哪些?
所选的可用性策略还必须考虑设计最佳资源使用方案中阐述的可维护性要求。避免需要太多管理和维护的复杂解决方案。
Java Enterprise System 部署的可用性策略包括以下各项:
负载平衡。使用冗余硬件和软件组件来分流处理负载。负载平衡器把对某个服务的任意请求引导至该服务的多个对称服务实例之一。如果任一实例发生故障,其他实例可以承担更大的负载。
故障转移。涉及对冗余硬件和软件的管理,在任何组件发生故障时提供对服务的不间断访问并保证关键数据的安全。
Sun Cluster 软件为后端组件管理的关键数据提供了故障转移解决方案,比如 Messaging Server 的消息存储和 Calendar Server 日历数据。
复制服务。复制服务为对同一数据的访问提供多个源。Directory Server 为 LDAP 目录访问提供多个复制和同步策略。
后续各节给出一些提供不同级别的负载平衡、故障转移和复制服务的可用性解决方案示例。
将服务的所有计算资源置于单个服务器上。如果服务器发生故障,整个服务便终止运行。
Sun 提供具有下列优点的高端服务器:
系统运行中更换和重新配置硬件组件
可在服务器的故障隔离域中运行多个应用程序
不必重新引导系统即可升级容量、执行速度及 I/O 配置
一台高端服务器的价格通常高于具有可比性的多服务器系统。不过,单个服务器可节省对数据中心多台服务器的管理、监视和驻扎成本。多服务器系统在负载平衡、故障转移和解除单个故障点方面的灵活性更强。
利用可提供负载平衡和故障转移两种功能的平行冗余服务器提高可用性的方法有若干种。下图显示的是组成一个 N+1 故障转移系统的两台复制服务器。其中一台服务器发生故障时,N+1 系统通过一个额外服务器继续提供 100% 容量。
上面水平冗余系统中每台服务器的计算能力都完全相同。一台服务器即可满足性能要求,另一台服务器作为备份服务器调入服务时,也可提供 100% 的性能。
N+1 故障转移设计的优点是,故障转移情况下仍可达到 100% 的性能。缺点是增加了硬件成本,而总体性能却未得到相应提升(因为一个服务器只在发生故障转移的情况下使用,平时备用)。
下图所显示的是这样一种系统:通过在两台服务器间分配性能负载来实现负载平衡和故障转移。
在上面水平冗余系统中所示的系统内,如果一台服务器发生故障,所有服务仍然可用,只不过性能只能达到完全性能的某一百分比。另一台服务器提供 6 CPU 计算能力,为要求的 10 CPU 的 60%。
这种设计的一个优点是,两台服务器均可用时有 2 个 CPU 的额外潜潜在容量。
下图显示的是,在多台服务器间分配负载来满足性能和负载平衡要求。
由于水平冗余系统所示的设计中有五台服务器,如果一台服务器发生故障,其余服务器可继续提供总计 8 个 CPU 的计算能力,达到 10 个 CPU 性能要求的 80%。如果在设计中增加一个具有 2 CPU 计算能力的服务器,实际得到的便是 N+1 设计。如果一台服务器发生故障,其余服务器可满足 100% 的性能要求。
这种设计具有下列优点:
单台服务器发生故障时的性能得到提升
即使不止一台服务器停机,仍然具有可用性
可轮换将服务器停机,以进行维护和升级
多台低端服务器的价格通常低于单台高端服务器
不过,增加服务器数量会使管理和维护成本大幅增加,还应考虑在数据中心驻扎服务器的成本。达到某一数量后,再增加服务器所得到的性能提升会越来越少。
对于要求高可用性(如四或五个九)的情况,可以考虑将 Sun Cluster 软件纳入可用性设计。群集系统是冗余服务器、存储器及其他网络资源相结合的产物。群集中的服务器彼此间不间断地通信,如果其中一台服务器脱机,群集中的其余设备会将该服务器隔离,并将故障节点上的任何应用程序或数据故障转移到另一节点。这一故障转移过程所需时间较短,几乎不用中断为系统用户提供的服务。
配置、管理和维护 Sun Cluster 软件需要额外的专用硬件和专门技能。
本节包含两个可用性策略示例,基于员工数为 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 的使用者实例都按读取和搜索访问进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。
多主复制策略除具有单主复制的所有优点之外,还提供了一个在更新主数据库时提供负载平衡的可用性策略。还可以实现一个对目录操作提供本地控制的可用性策略,这对于在全球分布数据中心的企业是一个很重要的考虑事项。
可伸缩性是指增加系统容量的能力,通常是以增加系统资源但不改变部署体系结构的方式进行。在要求分析阶段,通常是根据业务需求和后续用量分析对预期增长作出预测。这些对系统用户数量和满足他们需要的系统容量的预测往往只是估计值,可能与部署系统的实际数字大相径庭。设计应具备足够的灵活性,考虑到预测中存在的偏差。
可伸缩的设计具有足够的处理增加负载的潜在容量,直到系统使用附加资源进行升级为止。可伸缩设计可以随时进行扩展,以处理持续增加的负载,同时无需重新设计系统。
潜在容量是可伸缩性的一个方面,即在系统中增加额外的性能和可用性资源,以便在出现异常峰值负载时能够从容应对。还可以对部署系统中潜在容量的使用案例进行监视,以协助确定何时要通过增加资源来扩展系统。潜在容量是给设计注入安全机制的一种方法。
分析使用案例有助于确定可能产生异常峰值负载的方案。利用对异常峰值负载的分析,并对可应对意外增长的因素加以考虑,便能够设计出可给系统注入安全机制的潜在容量。
系统设计应能处理一定的合理时间(通常为系统运行的前 6 到 12 个月)内的预测容量。可利用维护周期,根据需要增加资源或扩大容量。理想情况下应能安排定期对系统进行升级,但预测需要增加的容量往往很难。根据仔细的资源监视和业务预测来确定升级系统的时间。
如果计划在渐增式阶段中实现您的解决方案,则可以安排系统容量增长计划,使其与为每个渐增式阶段安排的其他改善相一致。
本节中的示例说明对一个实现 Messaging Server 的解决方案进行水平和垂直扩展。对于垂直扩展,可向服务器添加额外的 CPU 以处理增长的负载。对于水平扩展,通过添加额外的服务器分摊负载来处理增长的负载。
本例的底线假设通过两个为负载平衡而分布的消息存储实例支持 50,000 名用户群体。每个服务器有两个 CPU,共有四个 CPU。下图显示如何扩展系统,为 250,000 名用户或 2,000,000 名用户处理增长的负载。
可伸缩性示例显示垂直扩展和水平扩展的区别。本图未显示扩展时应考虑的其他因素,如负载平衡、故障转移和使用模式变化。
成功的部署设计的关键之一是确定潜在的性能瓶颈并开发出可以避免它们的策略。访问数据的速率不能满足指定的系统要求时,则出现性能瓶颈。
可以根据不同硬件的类别(例如,下表列出某一系统内的数据访问点)对瓶颈进行分类。此表还为每种硬件类别中存在的瓶颈提出了可能的补救措施。
表 5–7 数据访问点
硬件类别 |
相对访问速度 |
改善性能的补救措施 |
---|---|---|
处理器 |
纳秒 |
垂直扩展:提高更多的处理能力,增强处理器高速缓存 水平扩展:添加负载平衡的并行处理能力 |
系统内存 (RAM) |
微秒 |
使系统内存专用于特定任务 垂直扩展:添加额外内存 水平扩展:创建附加实例,用于并行处理和负载平衡 |
磁盘读写 |
毫秒 |
使用磁盘阵列 (RAID) 优化磁盘访问 使磁盘访问专用于特定功能,如只读或只写 在系统内存中缓存频繁访问的数据 |
网络接口 |
随网络节点的带宽和访问速度的不同而不同 |
增加带宽 传输安全数据时添加加速器硬件 增强网络内节点的性能,以便数据更加可用 |
确定性能瓶颈按照相对访问速度列出硬件类别,表明低速访问点,如磁盘,更可能是瓶颈源头。但是,能力不足的处理器处理大量负载时也可能形成瓶颈。
部署设计通常从为部署中的每个组件以及它们的依赖性进行底线处理能力估计开始。然后确定如何避免与系统内存和磁盘访问相关的瓶颈。最后检查网络接口,确定潜在的瓶颈并集中精力于解决它们的策略。
部署设计的一个关键组件是磁盘对经常访问的数据集(如 LDAP 目录)的访问速度。磁盘访问对数据的访问速度最低,很可能是性能瓶颈的源头。
优化磁盘访问的方法之一是将写入操作与读取操作分开进行。不仅写入操作比读取操作更加费时,读取操作(查找 LDAP 目录的操作)的出现频率也远远高出写入操作(更新 LDAP 目录中的数据)。
优化磁盘访问的另一种方法是将各个磁盘专用于不同类型的 I/O 操作。例如,为 Directory Server 日志记录操作(如事务日志和事件日志)与 LDAP 读写操作分别提供磁盘访问。
另外,还可考虑实现一个或多个专用于读写操作的 Directory Server 实例以及使用分布于各本地服务器的复制实例进行读取和搜索访问。链锁和链接选项也可用于优化对目录服务的访问。
《Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide》第 6 章 "Defining System Characteristics" 讨论了规划磁盘访问时的各种因素。本章包括以下主题:
最低内存和磁盘空间要求。提供各种大小的目录所需的磁盘和内存的估计值。
估量缓存访问的物理内存。为根据 Directory Server 的计划用量和总规划内存用量估计高速缓存大小提供指导。
估量磁盘子系统大小。提供根据目录后缀和影响磁盘使用的 Directory Server 因素规划磁盘空间要求的信息。以及提供在磁盘(包括各种磁盘阵列变通方案)间分布文件的信息。
部署设计不只是对满足 QoS 要求所需的资源进行估计,部署设计期间,还对所有可用选项进行分析,选择出最大限度降低成本而又能满足 QoS 要求的最佳解决方案。必须分析每个设计决策中的平衡点,确保在某一方面获得的益处不会被在另一方面产生的成本抵消。
例如,针对可用性进行水平扩展可能会提升总体可用性,但代价是需要增加维护和维修成本。针对性能进行垂直扩展可能会以经济的方式提高计算能力,但某些服务对这些附加能力的使用效率不高。
完成设计策略前,请对决策进行检查,确保平衡利用资源,使提议解决方案总体受益。此分析通常是检查某一方面的系统性质如何对其他系统性质产生影响。下表列出某些系统性质及相应的资源管理考虑事项。
表 5–8 资源管理考虑事项
系统质量 |
说明 |
---|---|
对于将 CPU 集中分布在个别几台服务器上的性能解决方案,服务能否对计算能力加以高效利用?(例如,某些服务对可高效利用的 CPU 数量有上限。) |
|
潜在容量 |
您的策略是否处理超出性能估计的负载? 对于过载,是以在服务器上进行垂直扩展的方式,以负载平衡到其他服务器的方式,还是以这两种方式兼用的方式进行处理? 在达到下一部署扩展重大事件点前,潜在容量是否足以处理出现的异常峰值负载? |
是否对处理安全事务所需的性能开销给予了充分考虑? |
|
对于水平冗余解决方案,是否对长期维护开支给予了充分估计? 是否已将系统维护所需的计划停机考虑在内? 是否在高端服务器和低端服务器间求得了成本平衡? |
|
是否对部署扩展的重大事件点进行了估计? 是否制定了可在达到部署扩展重大事件点前提供足够的潜在容量来处理预测的负载增长的策略? |
|
是否在可用性设计中考虑了管理、监视和维护成本? 是否考虑了采用委派管理解决方案(允许终端用户执行某些管理任务)来降低管理成本? |
部署设计所依据的许多信息,如服务质量要求和用量分析,并不是基于经验的数据,而是基于从业务分析最终得来的估计和预测数据。由于许多原因(包括无法预料的商业气候环境、不完善的数据收集方式或者简单的人为错误),这些预测可能不准确。完成部署设计前,请复查设计所依据的分析,确保设计已将任何估计或预测值的合理偏差考虑在内。
例如,如果用量分析低估了系统的实际用量,便要面临这样的风险:所构建的系统无法应付其遇到的流量。未达到性能要求的设计当然是失败的设计。
反之,如果所构建系统的能力远超所需能力,便白白浪费了本可用在他处的资源。关键在于,在满足要求的基础上留出一定的保险余量,但要避免资源浪费。
资源浪费可导致设计失败,因为这种设计未能充分利用本可用于其他一些领域的资源。此外,浪费资源的解决方案还可能给风险承担者以未诚信履行合同的印象。
下图显示的是本白皮书前文中介绍的示例部署的完整部署体系结构。通过此图可大概了解部署体系结构的表示方法。
下图中的部署体系结构只作说明之用,它不代表实际设计、构建或测试的部署,不应将其视为部署规划建议。