估计处理器要求
本节讨论了估计支持部署设计中的服务所必需的 CPU 处理器数量和相应内存的过程。本节包括一个示例通信部署方案估计过程的演练。
估计 CPU 计算能力是一个不断反复的过程，要考虑下列方面：
-
逻辑组件及它们之间的交互（由逻辑体系结构中的组件依赖性表示）
-
已确定使用案例的用量分析
-
服务质量要求
-
以往部署设计和使用 Java Enterprise System 的经验
-
咨询具有设计和实现各类部署方案经验的 Sun 专业服务机构
估计过程包括下列步骤。这些步骤的执行顺序并非关键所在，这一顺序只是提供了考虑可对最终结果产生影响的因素的一种方式。
-
给确定为用户的系统入口点的组件确定 CPU 数量估计底线。
一个设计决策是完全加载还是部分加载 CPU。完全加载 CPU 可使系统容量最大化。要增加容量，需要添加额外的 CPU，从而增加了维护成本及停机的可能性。某些情况下，可以选择添加其他计算机来满足不断增长的性能要求。
部分加载 CPU 为处理超额性能要求预留了余地，无需立即增加维护成本。不过，这种未充分利用的系统却附加了提前的费用开销。
-
对 CPU 数量估计进行调整，将组件间的交互考虑在内。
研究逻辑体系结构中组件之间的交互，确定相关组件要求的额外负载。
-
研究特定使用案例的用量分析，确定系统的峰值负载，然后对处理峰值负载的组件进行调整。
从最大加权的使用案例（要求最多负载）开始，然后考察每个使用案例，确保考虑了所有的预测使用方案。
-
对 CPU 数量估计进行调整，将安全性、可用性和可伸缩性要求考虑在内。
此估计过程是确定所需实际处理能力的起点。通常，根据这些估计创建原型部署，然后对预期使用案例执行严格的测试。只有经过反复的测试，才能确定部署设计的实际处理要求。
示例的估计处理器要求
本节说明了一种对示例部署所需处理能力进行估计的方法。该示例部署基于员工数为 1,000 到 5,000 人的中型企业基于身份的通信解决方案的逻辑体系结构，如基于身份的通信示例一节所述。
本例中使用的 CPU 和内存数字都只是说明性的随意估计。这些数字基于本理论性示例所依据的任意数据。要估计处理器要求，有必要对各种因素进行彻底分析。此分析将包括（但不限于）下列信息：
-
基于彻底的业务分析的详细使用案例和用量分析
-
通过对业务需求分析而确定的服务质量要求
-
处理和网络硬件的特定成本和规范
-
实现类似部署的以往经验
注意 – 这些示例中提供的信息用于说明设计系统时可能使用的一种过程，并不代表任何具体的实现建议。
为用户入口点确定 CPU 数量估计底线
先估计处理每个作为用户入口点的组件的预期负载所需的 CPU 数量。下图显示了一种基于身份的通信方案的逻辑体系结构，先前在基于身份的通信示例一节中有所介绍。
图 5–1 基于身份的通信方案的逻辑体系结构
下表列出该逻辑体系结构中与此部署的终端用户直接接口的表示层中的组件。该表包括 CPU 数量估计底线，这些估计源自技术要求分析、使用案例、特定用量分析以及此类型部署的以往经验。
表 5–1 包含用户入口点组件的 CPU 数量估计|
组件 |
CPU 数量 |
说明 |
|---|---|---|
|
Portal Server |
4 |
作为用户入口点的组件。 |
|
Communications Express |
2 |
将数据发送到 Portal Server 消息传送和日历频道。 |
包括针对服务依赖性的 CPU 数量估计
提供用户入口点的组件需要其他 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 数量估计，而且也为潜在容量增加了一个小因素。但是，应根据对复制服务的特定需要进行舍入。
一般规则是为每个 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 |
- © 2010, Oracle Corporation and/or its affiliates