test

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

第 3 章 技术要求

在解决方案生命周期的技术要求阶段，执行用量分析、确定使用案例并为提议的部署解决方案确定服务质量要求。

本章包括以下部分：

关于技术要求

技术要求分析以解决方案生命周期的业务分析阶段所创建的业务需求文档为起点。需要以这些业务分析为基础，执行下列步骤：

用量分析

用量分析的任务是确定要设计的解决方案的各个用户及确定这些用户的使用模式。收集的信息可用于估计系统的负载情况。在给使用案例指定加权时，用量分析信息同样有用，如使用案例中所述。

用量分析阶段的任务是：尽可能与用户面谈，对与使用模式有关的现有数据进行研究及与先前系统的制造者和管理员会谈。下表列出了进行用量分析时应考虑的因素。

表 3–1 用量分析因素

主题 

说明 

用户数量及类型 

确定解决方案必须支持的用户数量，并在必要时对用户进行分类。 

例如： 

  • “企业对客户”(Business to Customer, B2C) 解决方案可能会有大量访问者，但可能只有少数用户会进行注册并参与商业交易。

  • “企业对员工”(Business to Employee, B2E) 解决方案通常为每位员工提供服务，尽管有些员工可能需要从公司网络外部进行访问。在 B2E 解决方案中，经理可能需要获得普通员工不能访问的某些区域的访问权限。

活动和非活动用户 

确定活动和非活动用户的使用模式和使用比率。 

活动用户是指登录系统并与系统的服务进行交互的用户。非活动用户是指未登录的用户、虽然登录但不与系统组件进行交互的用户、或虽然数据库中存在该用户但从不登录的用户。 

管理用户 

确定对部署系统进行访问，以对部署进行监控、更新和支持的用户。 

确定可能影响技术要求的任何特定管理使用模式（例如，从防火墙外部管理部署）。 

使用模式 

确定各类用户如何访问系统，并提供预期用量目标。 

例如： 

  • 是否存在因用量高涨而产生的高峰期？

  • 正常营业时间是什么？

  • 用户是否遍布全球？

  • 预计的用户连接持续时间是多少？

用户增长 

确定用户群体规模是否固定，或部署是否预期有用户数量增长。 

如果预期用户群体会有增长，请尽量作出合理的增长预测。 

用户事务 

确定必须支持的用户事务类型。可将这些用户事务转化为使用案例。 

例如： 

  • 用户会执行哪些任务？

  • 用户登录后是否保持登录状态？他们通常会执行一些任务，然后注销？

  • 用户间的重要协作是否需要利用共用日历、召开 Web 会议及部署内部 Web 页？

用户研究和统计数据 

利用现有用户研究和其他资源来确定用户行为模式。 

企业或行业组织往往都会进行一些用户研究，可以从中汲取有用的用户信息。现有应用程序的日志文件中可能会包含一些统计数据，这些数据在做系统估量时会用到。 

使用案例

使用案例模拟典型的用户与要设计的解决方案间的交互，以最终用户的视角说明操作的完整流程。在设计中对整个一组使用案例给予优先考虑可确保设计不偏离提供预期功能这一中心。使用案例是逻辑设计的主要输入。

为使用案例指定相对加权，加权最高的使用案例代表最常见的用户任务，这是一种常见的做法。为使用案例指定加权可让您将设计决策集中到使用最多的系统服务上。

可分两级对使用案例进行说明。

服务质量要求

服务质量 (quality of service, QoS) 要求是指定某些功能（如性能、可用性、可伸缩性和可维护性）的系统特性的技术规范。QoS 要求由业务需求阶段指定的业务需要驱动。例如，如果服务必须全年每天 24 小时可用，则可用性要求必须解决此业务需求。

下表列出了通常构成 QoS 要求基础的系统特性。

表 3–2 影响 QoS 要求的系统特性

系统质量 

说明 

性能 

按用户负载条件对响应时间和吞吐量所做的度量。 

可用性 

对最终用户可访问系统资源和服务的频度的度量，通常以系统的正常运行时间来表示。

可伸缩性 

随时间推移为部署系统增加容量（和用户）的能力。可伸缩性通常涉及向系统添加资源，但不应要求对部署体系结构进行更改。 

安全 

对系统及其用户的完整性进行说明的复杂因素组合。安全性包括用户的验证和授权、数据的安全以及对已部署系统的安全访问。 

潜在容量 

在不增加资源的情况下，系统处理异常峰值负载的能力。潜在容量是可用性、性能和可伸缩性特性中的一个因素。 

可维护性 

对已部署系统进行维护的容易度，其中包括监视系统、修复出现的故障以及升级硬件和软件组件。 

各系统特性密切相关。对一个系统特性的要求可能会影响到对其他系统特性的要求和设计。例如，提高安全性级别可能会影响到性能，而性能又会影响到可用性。靠另外增加服务器来应对可用性问题会影响可维护性（维护成本）。

能否设计出既可满足业务需求，又能兼顾业务约束的系统的关键在于，了解各系统特性间的关联方式及必须作出的权衡。

以下各部分将对影响部署设计的各种系统特性做更深入的探讨，并就确定 QoS 要求时应考虑的因素提供相关指导。还包括一节介绍服务级别要求的内容，该要求是服务级别协议的基础。

性能

业务需求通常用指定响应时间的非技术术语表示性能。例如，基于 Web 访问的业务需求可能会做以下说明：

正常情况下，用户登录后会有一段合理的响应时间，这段时间通常不超过四秒。

从该业务需求入手，对所有使用案例进行研究，以确定在系统级体现该要求的方式。某些情况下，您可能希望将用量分析期间确定的用户负载情况也包括在内。以指定负载情况下的响应时间或响应时间加吞吐量来表示每个使用案例的性能要求。可能还要指定容错数。

下面是有关如何指定系统性能要求的两个示例。

性能要求与可用性要求（故障转移对性能的影响）及潜在容量（可用于处理异常峰值负载的容量）关系密切。

可用性

可用性是指定系统正常运行时间的一种方法，通常以系统可供用户访问的时间占总时间的百分比来表示。系统不可访问时间（停机时间）可能是因硬件、软件、网络故障或任何其他因素（如断电）所致，这些因素会使系统停机。不将计划的服务（维护和升级）停机时间视为停机时间。按正常运行时间百分比计算系统可用性的基本公式是：

可用性 = 正常运行时间/(正常运行时间 + 停机时间) * 100%

通常以“九”的个数来衡量可达到的可用性。例如，99% 的可用性为两个九。指定更多的九会对部署设计产生很大影响。下表显示的是为某系统增加代表可用性的九后的非计划停机时间数值，该系统以 24x7 方式全年不间断运行（共计 8,760 小时）。

表 3–3 全年运行（8,760 小时）系统的非计划停机时间

九的个数 

可用性百分比 

非计划停机时间 

2 

99% 

88 小时 

3 

99.9% 

9 小时 

4 

99.99% 

45 分钟 

5 

99.999% 

5 分钟 

容错系统

对可用性的要求达四个或五个九通常要求系统必须是一个容错系统。容错系统必须能够在硬件或软件出现故障时继续运行。通常，容错的实现手段是为提供关键服务的硬件（如 CPU、内存和网络设备）及软件配置冗余组件。

单一故障点是指没有备用的冗余组件的硬件或软件组件，而这些组件是重要路径的组成部分。该组件出现故障会使系统无法继续提供服务。设计容错系统时，必须确定并消除潜在的单一故障点。

容错系统的实现和维护成本高昂。请确保先了解业务可用性要求的本质，然后再考虑能够满足这些要求的可用性解决方案的策略和成本。

排定服务可用性优先级

在用户看来，可用性更多牵涉到的往往是逐个服务的可用性，而非整个系统的可用性。例如，如果即时消息传送服务不可用，通常情况下对其他服务的可用性几乎没有影响或无任何影响。但是，如果许多其他服务所依赖的服务不可用（如 Directory Server），则会有较大影响。较高的可用性规范应该明确引用要求更高可用性的特定使用案例和用量分析。

根据一组有序的优先级列出可用性需求会有帮助。下表按优先级顺序列出了不同服务类型的可用性。

表 3–4 不同优先级服务的可用性

优先级 

服务类型 

说明 

1 

关键任务 

任何时候必须可用的服务。例如，应用程序的数据库服务（如 LDAP 目录）。 

2 

必须可用 

必须可用，但可以较低性能获得的服务。例如，在某些业务环境中，消息传送服务的可用性可能并不关键。 

3 

可延迟 

在特定时间段内必须可用的服务。例如，在某些业务环境中，日历服务的可用性可能并非不可或缺。 

4 

可选 

可无限期延迟的服务。例如，在某些环境中，即时消息传送服务可能有用，但非必需。 

服务丢失

可用性设计将考虑到可用性降低或组件丢失时所发生的情况。其中，要考虑连接的用户是否必须重新启动会话和一个区域内的故障对系统的其他区域的影响程度。QoS 要求应考虑这些方案并指定部署如何对这些情况作出反应。

可伸缩性

可伸缩性是增加系统容量的能力，从而使系统可以支持来自现有用户或扩大的用户群体的额外负载。可伸缩性通常要求增加资源，但不应要求对部署体系结构的设计进行更改，或因增加额外资源需要时间而中断服务。

与可用性一样，可伸缩性更多牵涉到的是系统所提供的各项服务，而非整个系统。不过，对于其他服务所依赖的服务（如 Directory Server），可伸缩性的影响可能会波及整个系统。

不必在 QoS 要求中指定可伸缩性要求，除非业务需求中对预测的部署增长做了明确说明。不过，在解决方案生命周期部署设计阶段，即使未指定可用性 QoS 要求，部署体系结构也应添加一定余量，用于扩展系统规模。

估计增长

估计系统的增长，确定可用性要求，做一些可能无法达成的预测、估计和推测。以下是开发可伸缩系统的三个关键点。

下表列出确定可伸缩性要求应考虑的一些因素。

表 3–5 可伸缩性因素

主题 

说明 

分析使用模式 

通过研究现有数据了解当前（或预测）用户群体的使用模式。如果缺少现时数据，可对行业数据或市场估计进行分析。 

以最大的合理标度为目标进行设计 

设计时以能够满足已知和潜在需求的最大必需标度为目标。 

这往往是根据现有用户负载的性能评估和对未来负载的合理预期而作出的 24 个月估计。估计周期的长短在很大程度上取决于预测的可靠性。 

设置合适的重大事件点 

以渐增方式实现部署设计来满足短期要求，同时设立缓冲区来应对意外增长。设置增加系统资源的重大事件点。 

例如： 

  • 资本收购（如每季度或每年）

  • 购买硬件和软件的提前时间（如，一到六个星期）

  • 缓冲区（10% 到 100%，具体取决于增长预期）

融入新兴技术 

了解新兴技术（如速度更快的处理器和服务器），及此技术会对基础体系结构的性能产生怎样的影响。 

安全性要求

安全性是一个复杂的主题，涉及到部署系统的各个级别。开发安全要求围绕确定安全威胁和开发解决它们的策略进行。此安全分析包括以下步骤：

  1. 确定关键资产

  2. 确定对这些资产的威胁

  3. 确定使组织暴露于可能带来风险的威胁的薄弱环节

  4. 开发减轻组织风险的安全规划

分析安全要求应由您的组织的各方面风险承担者参与，包括管理员、业务分析师和信息技术人员。通常，组织会指定一个安全结构设计师来领导安全措施的设计和实现。

以下各节介绍安全规划包括的一些领域。

安全规划元素

规划系统安全是部署设计的一部分，对于设计的成功实现至关重要。规划安全时请考虑以下几点：

潜在容量

潜在容量是指在不增加资源的情况下，部署处理异常峰值负载用量的能力。通常不直接围绕潜在容量定义 QoS 要求，但该系统特性是确定可用性、性能和可伸缩性要求的一个因素。

可维护性要求

可维护性是指对部署系统进行维护的容易度，其中包括监视系统、修复出现的故障、向系统添加用户、从系统删除用户及升级硬件和软件组件等任务。

计划可维护性要求时应对下表所列的主题予以考虑。

表 3–6 可维护性要求主题

主题 

说明 

停机时间计划 

确定必须使特定服务完全或部分不可用的维护任务。 

某些维护和升级任务可在用户不知不觉中完成，而要执行其他类似任务则必须中断服务。尽可能与用户一起为要求停机的维护活动制订计划，使用户能够为停机时间作出准备。 

使用模式 

确定使用模式，以确定适于安排维护的最佳时间。 

例如，在通常于正常营业时间内出现用量高峰的系统中，适合在傍晚或周末执行维护任务。对于在地域上分散的系统而言，确定这些时段的难度可能更大。 

可用性 

可维护性往往是可用性设计思想的反映，因为最大限度缩短维护和升级停机时间策略是围绕可用性策略来制订的。要求具有高可用性的系统的维护、升级和检修停机时间较短。 

处理可用性要求的策略会影响到对维护和升级的处理方式。例如，在地域上分散的系统中，维护方式可能取决于维护期内将工作负载发送到远程服务器的能力。 

要求具有高可用性的系统可能还需要采用更为复杂的解决方案，使系统重新启动可以自动进行，而几乎不需要人为介入。 

诊断和监视 

定期运行诊断和监视工具来确定故障区域，可以提高系统的稳定性。 

定期监视系统可以防患于未然，有助于根据可用性策略来平衡工作负载及改进维护和停机计划。 

服务级别要求

服务级别协议 (service level agreement, SLA) 指定了最低性能要求以及未能满足此要求时必须提供的客户支持级别和程度。服务级别要求是指定 SLA 所基于的条件的系统要求。

与 QoS 要求一样，服务级别要求源自业务需求，并代表着对部署系统必须达到的整体系统特性的担保。服务级别协议被视为合同，所以必须明确规定服务级别要求。服务级别要求对要求的测试条件及不合要求的构成条件均有明确规定。