服务质量 (quality of service, QoS) 要求是指定某些功能(如性能、可用性、可伸缩性和可维护性)的系统特性的技术规范。QoS 要求由业务需求阶段指定的业务需要驱动。例如,如果服务必须全年每天 24 小时可用,则可用性要求必须解决此业务需求。
下表列出了通常构成 QoS 要求基础的系统特性。
表 3–2 影响 QoS 要求的系统特性
系统质量 |
说明 |
---|---|
性能 |
按用户负载条件对响应时间和吞吐量所做的度量。 |
可用性 |
对最终用户可访问系统资源和服务的频度的度量,通常以系统的正常运行时间来表示。 |
可伸缩性 |
随时间推移为部署系统增加容量(和用户)的能力。可伸缩性通常涉及向系统添加资源,但不应要求对部署体系结构进行更改。 |
安全 |
对系统及其用户的完整性进行说明的复杂因素组合。安全性包括用户的验证和授权、数据的安全以及对已部署系统的安全访问。 |
潜在容量 |
在不增加资源的情况下,系统处理异常峰值负载的能力。潜在容量是可用性、性能和可伸缩性特性中的一个因素。 |
可维护性 |
对已部署系统进行维护的容易度,其中包括监视系统、修复出现的故障以及升级硬件和软件组件。 |
各系统特性密切相关。对一个系统特性的要求可能会影响到对其他系统特性的要求和设计。例如,提高安全性级别可能会影响到性能,而性能又会影响到可用性。靠另外增加服务器来应对可用性问题会影响可维护性(维护成本)。
能否设计出既可满足业务需求,又能兼顾业务约束的系统的关键在于,了解各系统特性间的关联方式及必须作出的权衡。
以下各部分将对影响部署设计的各种系统特性做更深入的探讨,并就确定 QoS 要求时应考虑的因素提供相关指导。还包括一节介绍服务级别要求的内容,该要求是服务级别协议的基础。
业务需求通常用指定响应时间的非技术术语表示性能。例如,基于 Web 访问的业务需求可能会做以下说明:
正常情况下,用户登录后会有一段合理的响应时间,这段时间通常不超过四秒。
从该业务需求入手,对所有使用案例进行研究,以确定在系统级体现该要求的方式。某些情况下,您可能希望将用量分析期间确定的用户负载情况也包括在内。以指定负载情况下的响应时间或响应时间加吞吐量来表示每个使用案例的性能要求。可能还要指定容错数。
下面是有关如何指定系统性能要求的两个示例。
以 15 分钟为间隔采样的 Web 页刷新响应时间在全天各时段均不得超过四秒,每百万事务错误数须少于 3.4 个。
在定义的高峰期间,系统必须能够每秒接受 25 个安全登录,而且任何用户的响应时间均不得超过 12 秒,每百万事务错误数须少于 3.4 个。
性能要求与可用性要求(故障转移对性能的影响)及潜在容量(可用于处理异常峰值负载的容量)关系密切。
可用性是指定系统正常运行时间的一种方法,通常以系统可供用户访问的时间占总时间的百分比来表示。系统不可访问时间(停机时间)可能是因硬件、软件、网络故障或任何其他因素(如断电)所致,这些因素会使系统停机。不将计划的服务(维护和升级)停机时间视为停机时间。按正常运行时间百分比计算系统可用性的基本公式是:
可用性 = 正常运行时间/(正常运行时间 + 停机时间) * 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 可伸缩性因素
安全性是一个复杂的主题,涉及到部署系统的各个级别。开发安全要求围绕确定安全威胁和开发解决它们的策略进行。此安全分析包括以下步骤:
确定关键资产
确定对这些资产的威胁
确定使组织暴露于可能带来风险的威胁的薄弱环节
开发减轻组织风险的安全规划
分析安全要求应由您的组织的各方面风险承担者参与,包括管理员、业务分析师和信息技术人员。通常,组织会指定一个安全结构设计师来领导安全措施的设计和实现。
以下各节介绍安全规划包括的一些领域。
规划系统安全是部署设计的一部分,对于设计的成功实现至关重要。规划安全时请考虑以下几点:
物理安全。物理安全是对路由器、服务器、服务器机房、数据中心及基础结构中其他部分的物理访问。如果未经授权的人可以进入服务器机房然后拔掉路由器电源,则其他安全措施将毫无意义。
网络安全。网络安全是通过防火墙、安全访问区、访问控制列表和端口访问对网络进行访问。对于网络安全,应开发针对未授权访问、篡改和拒绝服务 (denial of service, DoS) 攻击的策略。
应用程序和应用程序数据安全。应用程序和应用程序数据安全包括通过验证和授权过程及策略访问用户帐户、公司数据和企业应用程序。此领域包括定义下列策略:
密码策略
访问权限,如对用户的委派管理(区别于管理员访问)
帐户灭活
访问控制
加密策略,包括数据安全传输和使用证书签署数据
个人安全惯例。组织范围的安全策略,定义工作环境和所有用户必须遵守的惯例,以确保其他安全措施按设计实行。通常的做法是编印安全手册并对用户进行安全惯例培训。要实现有效的总体安全策略,可靠的安全惯例必须成为企业文化的组成部分。
潜在容量是指在不增加资源的情况下,部署处理异常峰值负载用量的能力。通常不直接围绕潜在容量定义 QoS 要求,但该系统特性是确定可用性、性能和可伸缩性要求的一个因素。
可维护性是指对部署系统进行维护的容易度,其中包括监视系统、修复出现的故障、向系统添加用户、从系统删除用户及升级硬件和软件组件等任务。
计划可维护性要求时应对下表所列的主题予以考虑。
表 3–6 可维护性要求主题
主题 |
说明 |
---|---|
停机时间计划 |
确定必须使特定服务完全或部分不可用的维护任务。 某些维护和升级任务可在用户不知不觉中完成,而要执行其他类似任务则必须中断服务。尽可能与用户一起为要求停机的维护活动制订计划,使用户能够为停机时间作出准备。 |
使用模式 |
确定使用模式,以确定适于安排维护的最佳时间。 例如,在通常于正常营业时间内出现用量高峰的系统中,适合在傍晚或周末执行维护任务。对于在地域上分散的系统而言,确定这些时段的难度可能更大。 |
可用性 |
可维护性往往是可用性设计思想的反映,因为最大限度缩短维护和升级停机时间策略是围绕可用性策略来制订的。要求具有高可用性的系统的维护、升级和检修停机时间较短。 处理可用性要求的策略会影响到对维护和升级的处理方式。例如,在地域上分散的系统中,维护方式可能取决于维护期内将工作负载发送到远程服务器的能力。 要求具有高可用性的系统可能还需要采用更为复杂的解决方案,使系统重新启动可以自动进行,而几乎不需要人为介入。 |
诊断和监视 |
定期运行诊断和监视工具来确定故障区域,可以提高系统的稳定性。 定期监视系统可以防患于未然,有助于根据可用性策略来平衡工作负载及改进维护和停机计划。 |