test

Sun Java Enterprise System 2005Q4 部署规划指南

第 5 章 部署设计

在解决方案生命周期的部署设计阶段，需要设计一个高层部署体系结构和一个低层实现规范，并准备一系列实现该解决方案所必需的计划和规范。项目核准出现在部署设计阶段。

本章包括以下部分：

关于部署设计

部署设计始于解决方案生命周期的逻辑设计和技术要求阶段创建的部署方案。部署方案包括逻辑体系结构和解决方案的服务质量 (Quality of Service, QoS) 要求。通过在物理服务器和其他网络设备之间映射在逻辑体系结构中确定的组件，从而创建部署体系结构。要求对硬件配置提供了指导，以满足性能、可用性、可伸缩性和其他相关规范。

部署体系结构的设计是一个反复进行的过程。通常要复查要求和初步设计。要考虑不同要求之间的相互关系，对折衷和拥有成本问题进行平衡以获得最佳解决方案，最终满足该项目的业务目标。

项目核准

项目核准出现在部署设计阶段，通常在创建部署体系结构之后。使用部署体系结构（还可能用到下述的实现规范）对部署的实际成本进行估计，并提交给风险承担者进行核准。项目一经核准，即签署部署完成合同，并获取和分配项目实现所需的资源。

部署设计输出

在部署设计阶段，可能需要准备下列规范和计划：

影响部署设计的因素

有几个影响部署设计过程中所作决策的因素。请考虑下列关键因素：

部署设计方法

与部署规划的其他方面一样，部署设计不仅是一门科学，也是一门艺术，不能用特定的步骤和过程来详细规定。以往的设计经验、系统体系结构知识和特定领域知识的掌握以及发挥创造性思维，这些都是成功完成部署设计的因素。

部署设计通常围绕满足其他 QoS 要求的同时达到性能要求而展开。采用的策略必须对设计决策中的各种折衷进行平衡，以期优化解决方案。使用的方法通常涉及下列任务：

估计处理器要求

本节讨论了估计支持部署设计中的服务所必需的 CPU 处理器数量和相应内存的过程。本节包括一个示例通信部署方案估计过程的演练。

估计 CPU 计算能力是一个不断反复的过程，要考虑下列方面：

估计过程包括下列步骤。这些步骤的执行顺序并非关键所在，这一顺序只是提供了考虑可对最终结果产生影响的因素的一种方式。

  1. 给确定为用户的系统入口点的组件确定 CPU 数量估计底线。

    一个设计决策是完全加载还是部分加载 CPU。完全加载 CPU 可使系统容量最大化。要增加容量，需要添加额外的 CPU，从而增加了维护成本及停机的可能性。某些情况下，可以选择添加其他计算机来满足不断增长的性能要求。

    部分加载 CPU 为处理超额性能要求预留了余地，无需立即增加维护成本。不过，这种未充分利用的系统却附加了提前的费用开销。

  2. 对 CPU 数量估计进行调整，将组件间的交互考虑在内。

    研究逻辑体系结构中组件之间的交互，确定相关组件要求的额外负载。

  3. 研究特定使用案例的用量分析，确定系统的峰值负载，然后对处理峰值负载的组件进行调整。

    从最大加权的使用案例（要求最多负载）开始，然后考察每个使用案例，确保考虑了所有的预测使用方案。

  4. 对 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 

将出外邮件消息发送给收件人。 

Messaging Server MMP

1 

访问电子邮件客户机的 Messaging Server 消息存储。 

Messaging Server STR (Message Store)

1 

检索和存储电子邮件消息。 

Access Manager

2 

提供授权和验证服务。 

Calendar Server（后端）

2 

检索和存储 Calendar Server 前端 Communications Express 的日历数据。 

Directory Server

2 

提供 LDAP 目录服务。 

Web Server

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 预留 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 数量要求，请进行以下计算：

  1. 以 CPU 数量估计底线数（如上一节示例的估计处理器要求中计算的数字）作为起始数量。

  2. 计算需要安全传输的事务的百分比，然后计算安全事务的 CPU 数量估计。

  3. 计算非安全事务减少的 CPU 数量估计。

  4. 将安全和非安全数量估计相加，计算出总 CPU 数量估计。

  5. 将 CPU 数量估计向上舍入到最近的偶数。

安全事务的 CPU 数量估计显示了一个基于 Portal Server 的使用案例和用量分析的示例计算，其中假设：

表 5–5 修改安全事务的 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 运算时，计算能力专用于 SSL 计算的特定部分，通常是建立安全会话的“握手”运算。

这种硬件可能会对最终部署体系结构有益。不过，由于此类硬件的专用化性质，最好先以 CPU 能力估计出安全事务的性能要求，然后再考虑使用专用硬件处理额外负载的益处。

使用专用硬件时应考虑的一些因素有：使用案例（例如，要求大量 SSL 握手运算的使用案例）是否支持使用该硬件及使用此类硬件给设计增添的复杂性。这种复杂性包括这些设备的安装、配置、测试和管理。

确定可用性策略

开发可用性要求策略时，应研究组件交互和用量分析，以确定要考虑的可用性解决方案。对组件进行逐个分析，以确定最适合可用性和故障转移要求的解决方案。

下列项目是为帮助确定可用性策略而需收集的信息类型的示例：

所选的可用性策略还必须考虑设计最佳资源使用方案中阐述的可维护性要求。避免需要太多管理和维护的复杂解决方案。

可用性策略

Java Enterprise System 部署的可用性策略包括以下各项：

后续各节给出一些提供不同级别的负载平衡、故障转移和复制服务的可用性解决方案示例。

单服务器系统

将服务的所有计算资源置于单个服务器上。如果服务器发生故障，整个服务便终止运行。

图 5–2 单服务器系统

显示可满足性能要求的安装了 10 个 CPU 的单个服务器。

Sun 提供具有下列优点的高端服务器：

一台高端服务器的价格通常高于具有可比性的多服务器系统。不过，单个服务器可节省对数据中心多台服务器的管理、监视和驻扎成本。多服务器系统在负载平衡、故障转移和解除单个故障点方面的灵活性更强。

水平冗余系统

利用可提供负载平衡和故障转移两种功能的平行冗余服务器提高可用性的方法有若干种。下图显示的是组成一个 N+1 故障转移系统的两台复制服务器。其中一台服务器发生故障时，N+1 系统通过一个额外服务器继续提供 100% 容量。

图 5–3 具有两台服务器的 N+1 故障转移系统

显示用于满足 10 CPU 性能要求的两台复制服务器，每台服务器上安装有 10 个 CPU。

上面水平冗余系统中每台服务器的计算能力都完全相同。一台服务器即可满足性能要求，另一台服务器作为备份服务器调入服务时，也可提供 100% 的性能。

N+1 故障转移设计的优点是，故障转移情况下仍可达到 100% 的性能。缺点是增加了硬件成本，而总体性能却未得到相应提升（因为一个服务器只在发生故障转移的情况下使用，平时备用）。

下图所显示的是这样一种系统：通过在两台服务器间分配性能负载来实现负载平衡和故障转移。

图 5–4 两台服务器间的负载平衡和故障转移

显示用于满足 10 CPU 性能要求的两台服务器，每台服务器上安装有 6 个 CPU。

在上面水平冗余系统中所示的系统内，如果一台服务器发生故障，所有服务仍然可用，只不过性能只能达到完全性能的某一百分比。另一台服务器提供 6 CPU 计算能力，为要求的 10 CPU 的 60%。

这种设计的一个优点是，两台服务器均可用时有 2 个 CPU 的额外潜潜在容量。

下图显示的是，在多台服务器间分配负载来满足性能和负载平衡要求。

图 5–5 在 n 台服务器间分配负载

显示的是用于满足 10 CPU 性能要求的五台服务器，每台服务器上安装有 2 个 CPU。

由于水平冗余系统所示的设计中有五台服务器，如果一台服务器发生故障，其余服务器可继续提供总计 8 个 CPU 的计算能力，达到 10 个 CPU 性能要求的 80%。如果在设计中增加一个具有 2 CPU 计算能力的服务器，实际得到的便是 N+1 设计。如果一台服务器发生故障，其余服务器可满足 100% 的性能要求。

这种设计具有下列优点：

不过，增加服务器数量会使管理和维护成本大幅增加，还应考虑在数据中心驻扎服务器的成本。达到某一数量后，再增加服务器所得到的性能提升会越来越少。

Sun Cluster 软件

对于要求高可用性（如四或五个九）的情况，可以考虑将 Sun Cluster 软件纳入可用性设计。群集系统是冗余服务器、存储器及其他网络资源相结合的产物。群集中的服务器彼此间不间断地通信，如果其中一台服务器脱机，群集中的其余设备会将该服务器隔离，并将故障节点上的任何应用程序或数据故障转移到另一节点。这一故障转移过程所需时间较短，几乎不用中断为系统用户提供的服务。

配置、管理和维护 Sun Cluster 软件需要额外的专用硬件和专门技能。

可用性设计示例

本节包含两个可用性策略示例，基于员工数为 1,000 至 5,000 人的中型企业基于身份的通信解决方案，如先前在基于身份的通信示例一节中所述。第一个可用性策略说明了用于 Messaging Server 的负载平衡。第二个说明了使用 Sun Cluster 软件实现故障转移的解决方案。

Messaging Server 的负载平衡示例

下表中列出了逻辑体系结构中每个逻辑 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 

对于本例，假设在技术要求阶段指定了下列服务质量要求：

为满足可用性要求，应为每个 Messaging Server 组件提供两个实例，每一个都位于不同的硬件服务器上。如果一个组件的服务器发生故障，另一个组件可提供服务。下图显示了此可用性策略的网络示意图。

显示 Messaging Server MMP 和 MTA 组件的可用性的体系结构示意图。

上图中，CPU 数量为原估计数量的两倍。CPU 数量加倍的原因如下：

使用 Sun Cluster 软件的故障转移示例

下图显示了一个对 Calendar Server 后端和 Messaging Server 消息存储实施故障转移策略的示例。Calendar Server 后端和消息存储都在单独的硬件服务器上复制，并且使用 Sun Cluster 软件配置了故障转移。Sun Cluster 中每台服务器上的 CPU 数量和相应内存都被复制。

图 5–6 使用 Sun Cluster 软件的故障转移设计

体系结构示意图，显示了为实现故障转移而使用 Sun Cluster 软件部署的 Calendar Server 和 Message Server 存储。

目录服务复制示例

可对目录服务进行复制，以便在不同服务器间分配事务，从而提供高可用性。Directory Server 提供各种复制服务策略，其中包括：

Directory Server 的可用性策略是个复杂的问题，不在本指南的讨论范围之内。以下两节，单主复制和多主复制提供了对基本复制策略的概括说明。有关详细信息，参见《Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide》的第 12 章 "Designing a Highly Available Deployment"。

单主复制

下图显示了一个说明基本复制概念的单主复制策略。

图 5–7 单主复制示例

显示单主复制策略的数据流的示意图。

在单主复制中，一个 Directory Server 实例管理主目录数据库，并记录所有变化。主数据库被复制为任意数量的使用者数据库。Directory Server 的使用者实例按读取和搜索操作进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。

单主复制的优点包括：

多主复制

下图显示了一个可用于全局分配目录访问的多主复制策略。

在多主复制中，一个或多个 Directory Server 实例管理主目录数据库。每个主数据库都有一个指定同步主数据库的过程的复制协议。每个主数据库都被复制为任意数量的使用者数据库。与单主复制相同，Directory Server 的使用者实例都按读取和搜索访问进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。

图 5–8 多主复制示例

显示多主复制策略的数据流的示意图。

多主复制策略除具有单主复制的所有优点之外，还提供了一个在更新主数据库时提供负载平衡的可用性策略。还可以实现一个对目录操作提供本地控制的可用性策略，这对于在全球分布数据中心的企业是一个很重要的考虑事项。

确定可伸缩性策略

可伸缩性是指增加系统容量的能力，通常是以增加系统资源但不改变部署体系结构的方式进行。在要求分析阶段，通常是根据业务需求和后续用量分析对预期增长作出预测。这些对系统用户数量和满足他们需要的系统容量的预测往往只是估计值，可能与部署系统的实际数字大相径庭。设计应具备足够的灵活性，考虑到预测中存在的偏差。

可伸缩的设计具有足够的处理增加负载的潜在容量，直到系统使用附加资源进行升级为止。可伸缩设计可以随时进行扩展，以处理持续增加的负载，同时无需重新设计系统。

潜在容量

潜在容量是可伸缩性的一个方面，即在系统中增加额外的性能和可用性资源，以便在出现异常峰值负载时能够从容应对。还可以对部署系统中潜在容量的使用案例进行监视，以协助确定何时要通过增加资源来扩展系统。潜在容量是给设计注入安全机制的一种方法。

分析使用案例有助于确定可能产生异常峰值负载的方案。利用对异常峰值负载的分析，并对可应对意外增长的因素加以考虑，便能够设计出可给系统注入安全机制的潜在容量。

系统设计应能处理一定的合理时间（通常为系统运行的前 6 到 12 个月）内的预测容量。可利用维护周期，根据需要增加资源或扩大容量。理想情况下应能安排定期对系统进行升级，但预测需要增加的容量往往很难。根据仔细的资源监视和业务预测来确定升级系统的时间。

如果计划在渐增式阶段中实现您的解决方案，则可以安排系统容量增长计划，使其与为每个渐增式阶段安排的其他改善相一致。

可伸缩性示例

本节中的示例说明对一个实现 Messaging Server 的解决方案进行水平和垂直扩展。对于垂直扩展，可向服务器添加额外的 CPU 以处理增长的负载。对于水平扩展，通过添加额外的服务器分摊负载来处理增长的负载。

本例的底线假设通过两个为负载平衡而分布的消息存储实例支持 50,000 名用户群体。每个服务器有两个 CPU，共有四个 CPU。下图显示如何扩展系统，为 250,000 名用户或 2,000,000 名用户处理增长的负载。

注 –

可伸缩性示例显示垂直扩展和水平扩展的区别。本图未显示扩展时应考虑的其他因素，如负载平衡、故障转移和使用模式变化。

图 5–9 水平和垂直扩展示例

体系结构示意图显示了垂直和水平扩展与一个底线体系结构相比较的情况。

确定性能瓶颈

成功的部署设计的关键之一是确定潜在的性能瓶颈并开发出可以避免它们的策略。访问数据的速率不能满足指定的系统要求时，则出现性能瓶颈。

可以根据不同硬件的类别（例如，下表列出某一系统内的数据访问点）对瓶颈进行分类。此表还为每种硬件类别中存在的瓶颈提出了可能的补救措施。

表 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" 讨论了规划磁盘访问时的各种因素。本章包括以下主题：

设计最佳资源使用方案

部署设计不只是对满足 QoS 要求所需的资源进行估计，部署设计期间，还对所有可用选项进行分析，选择出最大限度降低成本而又能满足 QoS 要求的最佳解决方案。必须分析每个设计决策中的平衡点，确保在某一方面获得的益处不会被在另一方面产生的成本抵消。

例如，针对可用性进行水平扩展可能会提升总体可用性，但代价是需要增加维护和维修成本。针对性能进行垂直扩展可能会以经济的方式提高计算能力，但某些服务对这些附加能力的使用效率不高。

完成设计策略前，请对决策进行检查，确保平衡利用资源，使提议解决方案总体受益。此分析通常是检查某一方面的系统性质如何对其他系统性质产生影响。下表列出某些系统性质及相应的资源管理考虑事项。

表 5–8 资源管理考虑事项

系统质量 

说明 

性能

对于将 CPU 集中分布在个别几台服务器上的性能解决方案，服务能否对计算能力加以高效利用？（例如，某些服务对可高效利用的 CPU 数量有上限。） 

潜在容量 

您的策略是否处理超出性能估计的负载？ 

对于过载，是以在服务器上进行垂直扩展的方式，以负载平衡到其他服务器的方式，还是以这两种方式兼用的方式进行处理？ 

在达到下一部署扩展重大事件点前，潜在容量是否足以处理出现的异常峰值负载？ 

安全

是否对处理安全事务所需的性能开销给予了充分考虑？ 

可用性

对于水平冗余解决方案，是否对长期维护开支给予了充分估计？ 

是否已将系统维护所需的计划停机考虑在内？ 

是否在高端服务器和低端服务器间求得了成本平衡？ 

可伸缩性

是否对部署扩展的重大事件点进行了估计？ 

是否制定了可在达到部署扩展重大事件点前提供足够的潜在容量来处理预测的负载增长的策略？ 

可维护性

是否在可用性设计中考虑了管理、监视和维护成本？ 

是否考虑了采用委派管理解决方案（允许终端用户执行某些管理任务）来降低管理成本？ 

管理风险

部署设计所依据的许多信息，如服务质量要求和用量分析，并不是基于经验的数据，而是基于从业务分析最终得来的估计和预测数据。由于许多原因（包括无法预料的商业气候环境、不完善的数据收集方式或者简单的人为错误），这些预测可能不准确。完成部署设计前，请复查设计所依据的分析，确保设计已将任何估计或预测值的合理偏差考虑在内。

例如，如果用量分析低估了系统的实际用量，便要面临这样的风险：所构建的系统无法应付其遇到的流量。未达到性能要求的设计当然是失败的设计。

反之，如果所构建系统的能力远超所需能力，便白白浪费了本可用在他处的资源。关键在于，在满足要求的基础上留出一定的保险余量，但要避免资源浪费。

资源浪费可导致设计失败，因为这种设计未能充分利用本可用于其他一些领域的资源。此外，浪费资源的解决方案还可能给风险承担者以未诚信履行合同的印象。

示例的部署体系结构

下图显示的是本白皮书前文中介绍的示例部署的完整部署体系结构。通过此图可大概了解部署体系结构的表示方法。

注意 – 注意 –

下图中的部署体系结构只作说明之用，它不代表实际设计、构建或测试的部署，不应将其视为部署规划建议。

图 5–10 示例的部署体系结构

此图显示一个部署体系结构的布局示例。