内容


IBM WebSphere 开发者技术期刊

企业中的可用性规划

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

可用性是一个可达到的服务水平特性,每个企业都牢牢地抓住它。最坏的情况出现在因为没有进行仔细的可用性规划而导致负载被低估或带宽被阻塞时。将本文中的信息和附带的电子表格应用到您的规划实践中可以帮助您避免这种情况。

引言


构建或使用“企业”类计算环境的组织必须接受一个事实,那就是Internet 的繁荣对企业强加了比过去 IT部门需要处理的更高的可用性要求。今天的应用程序不仅仅是做更多的工作,而且有更多的用户,他们经常是遍布全球的,并需要24/7 的可用性。对 IT企业来说一个共同的困难是,当实现其他的服务级需求(比如吞吐量和响应时间)并高效利用服务器资源时如何经受住企业中已计划的和未计划的中断。

虽然一直以来很多组织在集中式的系统(例如大型机)上提供高可用性,但是现在越来越多的关键性的应用程序被部署在分布式(例如Unix,Windows)平台上。虽然在理论上分布式系统可以达到大型机提供的可用性水平,但在实际上,除了基本的操作平台之外,它需要仔细的设计、配置以及运用复杂的技术以及冗余能力。

要适当地计划可用性有大量的因素需要考虑。本文分析硬件可用性、软件可用性,以及各种各样的能力规划考虑与用户负载因素之间的关系。本文还尝试描述与设计达到要求的可用性和容量的计算环境有关的流程和活动。

最后,为决定通过特定的环境拓扑可能达到的可用性的等级而要求的数学相对来说比较直接,但不是所有人都知道或理解。本文附带的电子表格可用于简化可用性计算,后面的部分将介绍它在执行计算中的使用方法。

本文其他部分组织如下:

最后,结束语和参考文献部分概述了本文的内容并提供了指向更多材料的一些链接。

1. 容量、冗余和可用性基础


为了彻底地理解本文的其余部分,有必要准确地理解容量、冗余和可用性表示什么,以及这些因素在企业中如何相互关联。

1.1 服务器容量


服务器容量是运行一个应用程序必须的自然条件。不同的应用程序有不同的服务器容量要求:一些应用程序是 CPU 敏感的而其他的可能是内存敏感的。运行一个应用程序必须的服务器容量是衡量服务器本身的基础。同时运行的服务器应用程序典型的需要大的服务器和渐增的 CPU 和/或内存要求。购买太多的容量则一些硬件的投资会变得闲置。而购买太少的容量,则应用程序之间会彼此竞争资源并负面影响总体性能。

在理想状况下,一个服务器运行在 90% 的 CPU 和内存使用率将能最好地利用资源投资;然而,这将为需求高峰剩下很少的扩展空间,而我们并不是生活在一个静止的只有单一的需求分配的世界。另外,很难在同一时间为季节性区别预测传入的负载特征,因此通常通过计划使服务器运行在低于正常情况的 90% 来允许附加的容量。以这种方式计划出可用性和服务器容量将作为一个持续的任务直到企业环境开始实现“on demand”技术,自动调节资源可用性以处理改变的工作量情况。

图 1. 服务器容量是一个随着用户负载增加和显示它如何影响应用程序的响应时间的 CPU 和内存使用的函数
服务器容量是一个随着用户负载增加和显示它如何影响应用程序的响应时间的 CPU 和内存使用的函数
服务器容量是一个随着用户负载增加和显示它如何影响应用程序的响应时间的 CPU 和内存使用的函数

图 1 显示了在不同用户负载水平下的应用程序特征,我们看到服务器容量和性能的交互。用户数量以一定的基数随 X 轴增加时负载水平成两倍或三倍等一直到随初始用户数量的 6 倍增长。该应用程序的服务器容量要求在内存和 CPU 限制到达处定义。这在内存或 CPU达到高峰时发生,在本例中,是在当 4 倍的用户数量使用本应用程序时导致响应时间增加。在本例中,当期望的用户负载为 4.5 倍或更高时,多个物理服务器被要求提供足够的容量以合理的响应时间处理传入的请求。

1.2冗余服务器容量


冗余服务器容量的预置在企业中是规划可用性的一个关键方面。一个冗余服务器要么是工作量单元中的一个积极的参与者,要么保持闲置作为一个当主服务器失败时的“hot standby”。冗余服务器在投资上几乎没有回报,除了在失败的场景下通过选择没有被发生故障的服务器处理的工作量来证明其价值。冗余是为那些要么提供及时的信息要么操作“其他人的钱”或个人信息的组织提供的。冗余服务器必须在生产环境中通过必需的应用程序服务器容量。拥有的冗余服务器比他们的竞争对手小只会导致与递减的服务器容量相关的性能降低。这是不理想的,不过在某些情况下它可能是可接受的,毕竟低吞吐量比完全没有吞吐量要好。

图 2. 一个服务器集群,它们中的两个虽然是活动的工作量参与者,但是是冗余的
一个服务器集群,它们中的两个虽然是活动的工作量参与者,但是是冗余的
一个服务器集群,它们中的两个虽然是活动的工作量参与者,但是是冗余的

图 2 显示了一个服务器集群,它们中的两个冗余服务器是传入的工作量处理中的活动参与者。在该场景下,环境被限制为当该单元中的任意两个被从服务中移除时传入的工作量不会受影响。这是因为在该单元中服务器的容量被度量以使其中任意四台服务器都能处理传入的所有工作量,而剩余两台服务器提供的容量只在当其他服务器被从服务中移除时起作用。这样的中断可以是计划的也可以是未计划的事件,例如当一个应用程序被升级时重启单元中的服务器,或者是当一台服务器的电力供应失败时。

服务器冗余在分布式 UNIX 或 Windows 平台中并不普遍。这是因为真正的高可用性在分布式环境中不是必需的,除非该企业中的应用程序从很小的内部的工作量转变成相当高的工作量,通常是在 Internet 上向世界开放。从历史的观点说,冗余被用于消除单独的服务器硬件上的故障,从而提高它们的可用性。例如,RAID 和热交换 CPU 卡在单一服务器层次上通常都具备冗余特征的。

为了支持真正的高可用性,冗余必须应用到其余架构的每一个单独的层次上。在典型的错误中,一个企业选择群集它们的 Web 服务器和应用程序服务器而不是数据库服务器。数据库服务器的故障被证明是所有应用程序故障的关键点。High Availability(HA)解决方案存在于企业中的每一层上,并且应该在计划可用性时加以研究。WebShpere Application Server中的大部分通用组件的高可用性技巧可以在 参考资料部分中找到。

1.2.1 位置、位置、位置
冗余服务器不一定是在同一地理位置上。在图 2中,服务器可以被划分成组,每组服务器都驻留在一个独立的物理数据中心。冗余容量的这种部署有附加的网络开销和成本。然而,任何一个数据中心发生灾难将影响其他的独立的物理数据中心的操作。实际上,独立位置的管理可以进一步地分解成当需要时手动投线的子单元。然而请注意,全面的灾难恢复解决方案超出了本文档讨论的范围,它涉及电源、Internet连接性和其他因素的附加冗余。

1.2.2冗余环境中的处理隔离
处理隔离是由一个工作量单元提供的另一个优点。一个服务器上的应用程序被停止或处理失败不会对运行在其他服务器上的应用程序产生影响。理想地,它在测试中发现应用程序问题,而不是在部署中影响生产环境中的应用程序,实际上,故障仍然会发生,或它可能需要停止应用程序或服务器以升级它们或执行备份,因此处理隔离对一个企业基础架构仍然是一个有用的能力。处理隔离也可以在相同的基础架构中以多种方式提供;例如,应用程序可以在应用程序服务器中被群集,它们可以依次以水平的方式在企业的冗余服务器中被群集。

图 3. 处理隔离为多问题的应用程序提供可靠性
处理隔离为多问题的应用程序提供可靠性

在图 3 中,处理隔离发生在单一服务器的上下文中和服务器的水平层次中。在 Server 1 上的处理 A1、A2 和 A3 是同一应用程序 A 的彼此独立的实例。通过相同服务器上的应用程序的克隆,该应用程序应该在任意情况下都能通过剩余的克隆继续处理传入的请求。这种处理隔离是运行多问题应用程序的一个方便的技术,虽然在某些情况下运行一个“ill-mannered”的应用程序的多个副本可能导致整个服务器的中断,而不仅仅是一个应用程序服务器处理时中断。

附加的隔离可以通过在一个水平配置的集群中物理上独立的 Server 2 上(A4、A5、A6)运行应用程序 A 的多个实例获得。在这种情况中的隔离不仅包括应用程序 A 的三个附加的、隔离的实例,而且还包括在水平层次上独立的服务器中应用程序处理的显式硬件隔离。这种应用程序的水平隔离提供应用程序继续处理请求而不管任何一个特殊的服务器的运行状态的能力。一个服务器上的 Network Interface Card(NIC)故障将不会影响其他服务器上的应用程序。

最后,注意相同的概念显然可以被扩展,以便在不同的应用程序之间提供隔离,例如,保护一个可靠的应用程序的可用性不受一个多问题的应用程序的影响。

1.3可用性


在设计一个服务器拓扑以支持高可用性时,规划者必须考虑要求的各种服务器类型、它们必须支持的要求的应用程序工作量容量和可用性的等级或“up time”。容量要求来自于应用程序的性能测试并理解在生产中引入的负载特征。然后冗余服务器的数量由 Service Level Agreement(SLA)要求来决定。这发生在当容量、冗余、处理隔离和可用性开始交织在一起时。

图 4. 用于提供可用性的处理隔离和冗余
用于提供可用性的处理隔离和冗余
用于提供可用性的处理隔离和冗余

在这个示例中,可用性通过以下几方面的组合来提供:

  1. 为应用程序决定合适的服务器容量。
  2. 决定计划的和未计划的中断的实际成本,并因而确定合理的附加冗余容量成本来防止它们。
  3. 适当地为冗余应用程序处理的附加处理隔离规划服务器大小。
  4. 提供正确的服务器的数量以处理预期传入的工作量。
  5. 增加两个额外的服务器作为冗余参与者处理传入的工作量。

在图 4中,应用程序垂直地在每个应用程序服务器上克隆,以在一个应用程序的实例自然结束时提供必需的处理隔离。处理隔离水平地在应用程序服务器上被保护,任意服务器本身应该必须从服务中去除。冗余服务器、#5 和 #6提供继续处理传入的请求的能力,其中两个服务器应该需要为计划的和未计划的维护作准备。

虽然冗余服务器是一项额外的成本,通过冗余服务器可以获得高可用性。如何计划必需的冗余服务器数量必须以一种方式来管理,以便使其保持在一个合理的预算内,从而拥有一定的可用性保证。本文剩余部分讨论附带的电子表格和可用性的数学要求。

2.对每一个独立的组件的可用性要求

所述,在一个高可用性基础架构中确保 所有组件都被构造为可用的,而不仅仅是WebSphere Application Servers 和 Web Servers,这一点是很重要的。对每一个组件,以下几个方面的可用性需要考虑:

  • 处理容量:如果一个组件失效,对整个处理工作量会发生什么样的影响?
  • 配置/静态数据:存在什么样的机制以确保一个失效组件的任何相关配置或静态数据被正确的传递到备份?
  • 动态数据:对于被一个失效的组件管理的任何动态数据会发生什么;例如,数据丢失、冻结直到该组件被恢复,或通过共享或复制存储到备份的方式被传递?

在一个WebSphere 体系结构中通用组件的高可用性请参阅在 参考资料部分;不过,下表列出了一些组件和故障转移需要考虑的组件特性:

表 1.故障转移需要考虑的特性

组件故障转移处理故障转移的静态或配置数据故障转移的动态数据
WebSphere Application Servers应用程序服务器、Administration Server(V4)Node Agent(V5)或 Deployment Manager应用程序部署、连接性和调整配置使用 2-阶段提交时的事务日志、HTTPSession
WebSphere Message Queue ServersWMQ Processes队列配置队列
HTTP ServersHTTP DaemonWeb Content、配置 --
网络元素,例如 HTTP Switch、 Router、Reverse Proxie、Firewall处理配置--
数据库数据库处理配置数据
目录目录处理配置目录数据
后端应用程序(CICS、ERP 等)应用程序处理配置假定数据在相关数据库中
Authentication Server授权处理配置--
Systems Management处理配置事件数

一个应用程序的可用性不仅仅是应用程序本身的可用性。在很多情况下,高可用性应用程序显著地为它试图访问的后端系统所影响。在有些情况下,应用程序连接到HA配置中无效的遗留应用程序或到第三方供应商,它们可能在各种情况下无效,这些情况可能对应用程序的可用性造成负面影响。这些“软”需求只能增加更多的误区到产生误区的因素中。

注意,除了以上讨论的相对明显的基础架构组件外,Internet连接性、电力供应等因素也必须加以考虑。

3. 计算可用性

图 5.整体环境拓扑示例

图5 展示了一个示意性的“环境”整体拓扑图,从 ISP到后端。本节讨论如何分析或计算部署在这样一个环境中的系统的整体可用性。下表描述了各个单独的组件,但是请注意整体:

  • 整体拓扑当且仅当 所有单独的组件可用时才“可用”。
  • 该示意图中大部分“组件”可能都是以一定的冗余实现的。

表 2.通用拓扑组件

组件描述
ISPInternet Service Provider,例如环境和外部网络之间的连接。
RouterISP 和环境宿主网络之间的路由。
Firewall防火墙。
交换在一个服务器集群中分发请求的技术--在本例中 HTTP 和应用程序服务器之间有交换,不过,在某些情况下交换可能集成在另一个组件中(例如在 WebSphere Application Server 中,“交换”在 HTTP Server 插件中实现,上图中在防火墙的另一端)。
HTTPHTTP 服务器。
App应用程序服务器。
后端存在为应用程序服务器提供连接的现有应用程序(如 CICS、数据库、ERP等)。在很多情况下多个后端系统被包括进来,在这种情况下,这些后端系统在整个基础架构中被模块化为分离的组件。
Auth 服务器验证服务器。
LDAP用于指示一个目录组件,通常是一个 LDAP 目录。
Tx用于指示管理事务的任何独立的组件。例如,在 WebSphere Application Server v5 中,它指 WebSphere Network Deployment Node Agents 和存储事务日志的目录--这些都应该和基本的应用程序服务器分开来考虑。
Network部署环境的网络。网络的每一个元素可能被单独对待(例如路由器、桥等),但是通常将网络作为一个单一的有独立可用性特征的组件。
电力供应整个基础架构依赖的电力供应--也就是说这不包括每个单独为每一个服务器配置的电力供应,而仅指所有服务器都依赖的电源。
物理建筑物环境所处的建筑物。

在这样的一个环境中,计算可用性的基本方法为:

  1. 决定每个组件的可用性,以从 0 到 1 的数字表示。
  2. 将所有组件的可用性相乘得到一个整体的表达式计算其百分比。

在数学上这被表达成:

在此有必要考虑将“物理建筑物”作为一个单独的失效点:从单一环境来看这是成立的;然而很多实际的应用程序被部署在两个或更多的物理位置上以转移风险。本文所述的技巧可能被扩展为涵盖这种情况,如下面 对多个物理位置的计算一节所述。

下一个问题是考虑如何决定单独的组件的可用性。有几种方法可以达到这个目的,包括:

  1. 大部分组件实际上是集群或主动/被动对。请参见下面 计算集群的可用性部分给出的信息计算集群的可用性。
  2. 一些组件(例如“网络”)包含大量独立的组件,相对于其他的拓扑结构,它的结构可能处于不同的控制之下。如果您的目的是计算某个特定的网络拓扑的可用性,这一部分中的方法将发挥作用。然而,如果您的目的是计算一个服务器拓扑的可用性,最好用整个网络可用性的经验方法--也就是失效和恢复之间的平均时间,或者如果这些是不可用的,则进行估计。要了解更多细节,请参见下面的“计算单个组件的可用性”。
  3. 一些组件(例如“应用程序服务器”)由一组单独的组件构成,但是足够简单以至于可以分析其组成的层。参见 计算单独组件的可用性部分。
  4. 一些组件(如“ISP”)可能完全在其宿主环境和拓扑结构的控制之外,并且可能服从约定的可用性特征,在这种情况下这些组件可以被使用。

本文剩余部分将描述决定单个节点、集群等的可用性的计算,在这之后您将对整个拓扑结构中每个组件的可用性有一个轮廓。然后您将准备计算它的整体可用性,如上所述。电子表格1,“Overall Chain”,将帮助您完成这个任务。

然而,首先有必要扩展以上提到的一些东西:“可用性”和“可能性”之间的关系。除了可用性经常表示成百分比而可能性表示成一个从0 到 1的数字之外,本质上它们是同一个东西。因此,可能性 =可用性%/100。

下一步是将“可用性“关联到失效发生的频率和持续时间上来。下面的部分解释其计算方法。然而,将关于失效发生多频繁和它们持续多长时间的信息转换成一个“可用性”特征是没有价值的。因此,如果您以每五年有两周失效的优质硬盘的服务器,而每三星期失效一天电力供应来开始计算,那么,所有的问题就集中到一个方面--因此您丢失了特定于更严重的两星期失效的信息。这种计算超出了当前讨论的范围。

3.1从独立组件可用性开始计算整个解决方案可用性的电子表格


电子表格 1,“Overall Chain”,从独立组件可用性开始计算整个解决方案的可用性,同时在以下图6 中示出。该表提供了一张 10 行的表格,每行包含整个解决方案的 10 个组件的空间。对每一个组件,您可以输入一个名字或描述和一个以百分比表示的单独的可用性数据。然后“OverallAvailability”单元给出整个解决方案的可用性。

仅需在表中的每个单元格输入组件的名称和可用性就行了。可能有些有些单元空出来了,保持为空就行了。在单元中输入组件信息的顺序没有关系。

图 6.在表格 1 中计算整体解决方案的可用性:“Overall Solution”
在表格 1 中计算整体解决方案的可用性:“Overall Solution”
在表格 1 中计算整体解决方案的可用性:“Overall Solution”

3.2 计算单个组件的可用性


“可用性”告诉您一个组件“运行(up)”相比较“停止(down)”的时间的百分比。在一个简单的层次上,它由两部分组成:首先,一个组件多少时间失效一次?其次,当它失效时,多长时间它能恢复?

请看一个实例,一个合理的假定是 UNIX硬件往往在几年的时间失效一次(例如,电力供应中断),让我们假定 3 年。很多 UNIX 操作者和他们的供应商有一个支持协议以保证在 24 小时内更换或进行维修。因此,一个典型的 UNIX 服务器的可用性为:

Availability of a typical UNIX server
Availability of a typical UNIX server

这是我们将用于计算单独组件的可用性的基本等式--您可以在电子表格 5 中发现它,“容量和可用性”。

值得指出的是,以上的计算方式使用特定短语“平均失效 到达时间”而不是“失效 之间的平均时间”。在这些短语之间公认的含义有一些微妙的但是重要的不同:

平均失效 到达 时间是连续运行期间的平均值--也就是说,在 结束 一个失效和 开始 另外一个之间的平均周期。

失效 之间 的平均时间是 开始 一个失效到 开始 另一个失效之间的平均经过的时间。

理解这些短语的准确定义是很重要的,在这里我们考虑那些采用平均失效 到达时间的计算方法。从数学上来说,两者之间存在以下联系:

Mean time relationship
Mean time relationship

3.2.1 从平均失效到达时间和平均恢复时间的可用性计算表格
表格 5,“容量和可用性”,包含几种计算方法,第一个被标记为“平均失效时间计算”,如下图 7 所示。它提供了一个基于数天内的平均失效时间信息和数小时内的失效恢复信息的可用性特性。

图 7. 使用表格 5 中的平均失效到达时间和平均恢复时间的可用性计算:“容量和可用性”
使用表格 5 中的平均失效到达时间和平均恢复时间的可用性计算:“容量和可用性”
使用表格 5 中的平均失效到达时间和平均恢复时间的可用性计算:“容量和可用性”

3.2.2 计算有一个“堆栈”的组件的可用性
在支持应用程序的拓扑结构中,每个节点的可用性由几个方面组成:

  1. 硬件的可用性。
  2. 操作系统的可用性。
  3. 应用程序服务器的可用性。
  4. 应用程序的可用性。

计算出节点的实际可用性的过程与用于整体拓扑结构的方式相同:所有这些方面都必须对作为一个整体可用的节点可用,因此您需要找出“堆栈”的每个元素的可用性,然后将它们相乘得到该节点的可用性。该方法和以上讨论的对整体解决方案使用的方法一样,并且也可以应用到一些包含多余一个节点的组件,如以下 带有共享的高可用性磁盘的服务器集群所描述。电子表格 4,“堆栈”,计算一个堆栈的可用性必须使它的每个元素都可用以便使整个堆栈可用。

有时,计算堆栈的一些元素的独立的可用性可能比较困难或不适当,例如:

  1. 如果知道失效之间的平均时间和平均恢复时间(例如对于硬件),则使用这一部分中的计算方法。
  2. 如果不知道该堆栈的一些元素的信息(例如因为“应用程序代码”还没有测试,或刚刚测试好),您需要另一种方法。假定这些元素 100%的可用性会给您一个“最佳用例(best case)”场景。此外,您还可以更广泛地测试、猜测或等到实际生产时得到实际的失效数据。
  3. 其中一些组件可能不是您负责的。例如,如果要求您设计一个支持 99.9x%的可用性的基础架构,但是应用程序代码却是另一些人负责的,您可以考虑假定 100%的可用性,并将这个说明写到拓扑结构的规范中去。否则,您可能会要求应用程序提供一些预计频率和失效的严重程度的方法。

3.2.2.1 计算堆栈可靠性的计算表格

电子表格 4,“堆栈”,计算堆栈的可用性,如下图 8 所示。该表格提供了 10 个表,每一个都用于计算一个单独的堆栈。每一个表都有一个该堆栈的标签(例如“Application Server Node”)和 10 个单元以描述该堆栈的每一个单独的元素特征,例如“硬件”、“操作系统”、“应用程序服务器中间件”等。

对每一个元素,您可以用两种方式描述其可用性。如果有平均失效到达时间和平均恢复时间信息,输入到表格中将计算出“计算出的可用性贡献”行。如果没有那些信息,您可以在“在此覆盖可用性贡献”处输入您自己的可用性特性行。如果都指定则使用被覆盖的可用性贡献。

每个堆栈的计算的可用性显示在每个表底部的“堆栈 1 的可用性(Stack 1 availability)”、“堆栈 2 的可用性(Stack 2 availability)”等单元中。

图 8. 表格 4 中的堆栈计算:“堆栈”
表格 4 中的堆栈计算:“堆栈”
表格 4 中的堆栈计算:“堆栈”

此时需要注意的是关于克隆的情况,例如,应用程序服务器在单个节点上的处理,与 WebSphere 应用程序通用的实践。在这种情况下,您有一个迷您处理“集群”在单个节点上。因此,为了计算“Application Server Node”上的“应用程序服务器和应用程序”元素的组合可用性,您可以使用以下方法:

  1. 假定应用程序里面有一个偶然性的错误(例如一个发布数据库连接的失败)要求应用程序服务器每个月重启一次。
  2. 重启应用程序服务器花 5 分钟。
  3. 在单个节点或物理服务器上有该应用程序服务器的四个克隆。
  4. 综合考虑,通过应用本节介绍的计算方法可以计算出单个应用程序服务器的可用性为 0.999999968。
  5. 假定该节点将继续保持运行,并且假设应用程序服务器中的两个可用(一个合理的假定,假设任何中断只有几分钟),使用这些特性去执行一个集群的计算,如下 计算集群的可用性所述。
  6. 该集群可用性特性可以用作“Application Server Node”堆栈计算中该“应用程序服务器和应用程序”元素的可用性贡献。

最后,注意如上所述的计算方法往往给出很高的可用性特性--在上面给出的示例中,“应用程序服务器 + 应用程序”可用性为 100.000000%(也就是说 100% 到小数点后 6位)。这指示它对整体可用性的贡献很小,除非您有一个特别多错误的应用程序。

3.3 计算集群的可用性


计算集群的可用性依赖于知道集群中每个节点的基本可用性。一旦这了解了,计算该集群的可用性的公式相对来说就容易知道了,但是可能计算起来很枯燥。

例如,考虑一个有两台机器的集群,如果两台中至少有一台可用,则整个集群被认为是“可用的”,然后整体可用性可以使用下表计算出来,假定一个节点的可用性是 99.90%(因此它可用的可能性是 0.9990,意味着 可用的可能性是 1.0000-0.9990 =0.0010):

表 3. 集群可用性

服务器 1 可用?服务器 2 可用?在这个配置中集群“可用”?这个配置的概率
0.9990 x 0.9990
0.0010 x 0.9990
0.9990 x 0.0010
0.0010 x 0.0010

概率的数学形式告诉我们,集群作为一个整体可用的概率是所有单个“可用”配置的和。既然这样,计算出来为 0.99999917 或 99.999917%。

使用这种方法的问题是,它不是可伸缩的--随着服务器的数量(我们称之为 n)的增加,表中需要的行数是 2 的 n 次方--因此对于 10台服务器,您需要 1024 行。幸好,有公式能减少它-- 组合理论提供了一个简短的方式来计算它。基本上,在一个比如有 10台服务器的集群中,您可能有一个有限数量的感兴趣的组合:亦即没有服务器出故障、一台服务器出故障、两台服务器出故障? ? ?直到所有十台服务器都出故障。计算这些情况的可能性非常容易;问题在于存在很多不同的方式,比如 10 台服务器中的 5 台可能出故障。组合计算它们有多少种方式很容易,让我们看一看 参考资料中我的旧物理教科书。另外,电子表格将为您做到这些。您可以在表格 3 “集群”中找到计算方法。

3.3.1 集群可用性的电子表格计算
电子表格 3,“集群”,显示在下图 9 和 10 中。该表格要求您输入集群中的节点数量、每个独立节点的平均失效到达时间和平均恢复时间以及多少个节点失效时集群整体上仍然“可用”(参见下面的“冗余”和“可用性”了解关于这个问题的更多讨论)。

正如上面的“堆栈可用性的电子表格计算”,可能有时想要指定为单独的节点指定一个可用性特性而不是平均失效到达时间和平均恢复时间信息。如果是这样,您可以在“覆盖单一节点可用性%”单元格中输入这种信息,如下图 10 所示。

然后电子表格为您计算两个特性:首先,整个集群的可用性显示在“集群可用性(Cluster Availability)”单元中。其次,“Capacity redundant in normal operations(正常操作下的容量冗余)”单元指示当集群中的所有服务器可操作时集群容量的冗余百分比。这仅仅是集群仍然可用时允许失效的服务器容量数量,表示成总数的百分比。关于这点在下面 冗余容量和可用性有更多的讨论。

图 9. 表格 3 中的集群可用性计算:“集群”
表格 3 中的集群可用性计算:“集群”
表格 3 中的集群可用性计算:“集群”
图 10. 表格 3 中的集群可用性计算:“集群”,通过覆盖计算出来的单一节点可用性
表格 3 中的集群可用性计算:“集群”,通过覆盖计算出来的单一节点可用性
表格 3 中的集群可用性计算:“集群”,通过覆盖计算出来的单一节点可用性

3.3.2冗余容量和可用性
当考虑如何定义一个集群可用和不“可用”时冗余容量变得与可用性计算有关。例如,在一个有 10台服务器的集群中,当有一台服务器出故障时它是否“可用”?或当 2 台服务器出故障时?或 9 台出故障时?

这个问题紧密地与在正常操作时您准备接受的冗余容量的数量相关。例如,如果您定义“可用”为 10 台服务器中的 8台,那么您将接受在正常情况下有 2 台服务器是冗余的--也就是说 20% 的总容量。电子表格 5,“容量和可用性”,将帮助您进行这些计算,但是基本点是,在您为一个特定的可用性等级设计基础架构之前,您需要决定您决定为冗余付出多少,然后您可以指定您能忍受多少台服务器出故障时该集群仍然被称作是“可用”的。

表格 4,“容量和可用性”,包含和冗余容量和可用性相关的两种计算方法。第一种,“变种 1”显示在下图 11 中。

“变种 1”计算要求您输入为了支持您的操作能力(也就是说没有任何冗余)需要的服务器数量。然后您可以指定一个百分比来表示您将为支持可用性投资什么样的附加容量等级。例如,您可能需要 10 台服务器以支持您的工作量,至少花费 $100,000。然后您可能希望再花额外的 $25,000,或 25% 的冗余服务器以支持额外的可用性。在这种情况下,计算看起来似乎很简单,但是它指出您需要购买两台半额外的服务器。该电子表格将归拢您需要购买的服务器数量并指示实际的冗余容量--在此,3 台额外的服务器提供 30% 的冗余容量。(注意更多的关于提供可用性解决方案和为了防止失效而付出的代价比较的讨论可以在下面的“收集需求”中找到。)

最后,该电子表格还以总的集群大小的百分比来计算冗余容量--亦即包括额外部署的以支持可用性的服务器。所以当本例中以 30% 的冗余容量来计算时,即 10 台服务器支持工作量,这个数字为 23.08%的总的集群大小,即 10 + 3 = 13。这两个百分比的数字在表格中分别表示为“实际冗余和正常容量要求的服务器数量的百分比”和“冗余容量和为支持可用性要求的总服务器数量的百分比”。

末了,有时关心当服务器大小改变时这些计算如何进行。与执行任何您指定的服务器大小和冗余容量一样,该电子表格有一个表显示当 1、2、3...10 台服务器被要求以支持正常操作容量时您指定的冗余容量如何计算。

图 11. 表格 5“容量和可用性”中的可用性和容量计算的第一个变种
表格 5“容量和可用性”中的可用性和容量计算的第一个变种
表格 5“容量和可用性”中的可用性和容量计算的第一个变种

第二个计算,“变种 2”,显示在下图 12 中。这是一个简单的计算,假定您知道集群的大小和您允许集群作为一个整体仍然“可用”的情况下失效的服务器的数量。在这种情况下,该计算告诉您正常运行情况下您的整个集群的有效冗余的百分比。此外,还提供了一个表来说明当集群的大小改变时计算方法的改变。也就是说该表显示了当您指定允许失效的服务器数量时集群大小从 1 到 10 的冗余容量。

图 12. 表格 5 “容量和可用性”中的可用性和容量计算的第二个变种
表格 5 “容量和可用性”中的可用性和容量计算的第二个变种
表格 5 “容量和可用性”中的可用性和容量计算的第二个变种

3.3.3 具有共享的高可用性磁盘的服务器集群
在某些情况下,对于服务器集群,共享相同的高可用性磁盘相对来说比较普遍,特别是那些不仅服务器 处理要求高可用性,而且该处理所需的 动态数据必须可用。一些附加的示例如下:

  • 数据库。
  • 异步消息。
  • 事务管理(例如 WebSphere Application Server Deployment Manager)。

在某些情况下(比如 High Availability UNIX 硬件),两个或更多的服务器组合共享的磁盘被作为一个单一组件看待。在另外一些情况下,一个单独服务器的集群可能在其文件系统中有特定的目录映射到高可用性磁盘数组,以提供对集群中所有服务器高可用性的访问,例如,执行事务日志和消息队列。

在这种情况下,用以支持集群的数据和处理的可用性是服务器集群可用性(如上面基于大量可能可用或不可用的服务器的计算)和整个集群依赖的高可用性磁盘数组的一个组合--也就是说现在这是一个“堆栈”计算。该堆栈如下图 13 所示,其可用性计算为:

计算具有堆栈的组件的可用性
计算具有堆栈的组件的可用性
图 13. 由高可用性磁盘数组支持的服务器集群
由高可用性磁盘数组支持的服务器集群
由高可用性磁盘数组支持的服务器集群

3.4 将计算方法扩展到多个物理位置


如上所示,这里讨论的技术可以用作当包含两个或多个物理位置时的计算。当然有些情况超出了当前讨论的范围,下面的部分讨论了一些示例。

3.4.1 为不同的目的在多个位置之间进行单一环境分割
考虑这样一个情况,一个新的 Web 应用程序被部署到一个环境,但是需要连接到部署在一个分开的物理位置上的遗留应用程序。在这种情况下,为了让整个解决方案可用,两个物理位置必须同时可用。同样遵循和计算整个解决方案的情况相同的计算技巧,惟一的不同点在于第二个物理位置的可用性必须和第一个一样同时被包含进来。

3.4.2 跨多个等同位置的可用性进行单一环境分割
在一些要求异常高的可用性的情况下,对单个物理位置的依赖性可能是不可接受的,也就是说在整个物理位置变得不可用的情况下支持连续操作的需求,例如电力供应失败或一个自然灾难。

在这种情况下,两个或更多物理位置变成一个集群;也就是说,一旦单个位置上的可用性被计算出来,两个组合起来的可用性可以如上 计算集群的可用性所述进行计算。需要额外考虑的因素是 Internet服务提供商提供两个位置的网络访问、任何失效恢复技术用于在它们之间进行转换以及任何磁盘共享或复制技术,以支持两个位置之间的数据可用性。

该主题超出了当前讨论的范围。然而,如果您考虑一个有如此严格的可用性需求的解决方案时,显著的开销和随之而来的复杂性要求设计和实现需要专家的技能。

3.4.3 为灾难恢复在一个备份位置进行单一环境复制
这在很多方面和前面的情况相同,但是此处的意图大异:提供一个可以在线访问的备份位置可以在指定的恢复时间内重新恢复处理能力,这比修复和重构主站点要更快。一个隐含的问题是恢复时间可能更长,所以有一系列不同的技术以提供故障恢复(在这种情况下可能是手动的)和数据复制(可能是定期的将信息转移到磁带上)被使用。

虽然这里讨论的技术可能用于分析灾难恢复(Disaster Recovery)情景,它们更典型地特征化为恢复时间而不是可用性。另外,灾难恢复是一个复杂的主题,超出了这里讨论的范围,应该由专家来讨论。

4. 在端对端项目生命周期中设计可用性解决方案

4.1 规划可用性设计


规划可用性贯穿收集将作为输入到分析中的数据的多个阶段。一旦输入可用,就将执行分析以确定规划的可用性级别能否达到。当分析完成时,便评估企业以确定当前容量和负载需求是否和规划的可用性级别相符合。规划阶段贯穿四阶段处理以确定可用性:

  1. 收集输入。
  2. 分析数据。
  3. 验证分析对提供的输入有意义。
  4. 评估企业环境。

4.2 收集需求

容量、冗余性和可用性 一节所述,可用性需求依赖于几个因素:

  1. 必须支持的正常工作量(包括高峰期)。
  2. 规划的可用性的可接受级别(例如预定的升级中断)。
  3. 规划的可用性的可接受级别(例如应用程序可以允许的中断频率以及中断多长时间)。
  4. 应用程序之间的隔离需求(例如,如果应用程序A从服务中撤出(或者出乎意料地,或者是由于已计划的改变),应用程序B 也从服务中撤出是可接受的吗?)。
  5. 服务中断的代价是什么,与实现一个高可用性基础架构所需的费用相比孰轻孰重?

不幸的是,在系统实现中有一些老生常谈的主题,那就是常称为“非功能性需求”的一部分,它们是基本的业务需求,并且它们中很少为业务实现 IT 系统所良好指定。同样的,它们实际上是技术但是并不总是被大部分 IT 系统的拥有者所理解。很普遍的做法是系统构建在假定的可用性上面,这不可避免地导致不合适的花费或应用程序工作得比预期的要差。

这种需求的全面分析讨论超出了这篇文章的范围;然而,很明显的是,这些需求只能被处于将要部署的应用程序的所有者位置上的某个人来确定--只有这些人才能决定什么是可接受的什么是不可接受的,什么样的中断的代价和多大的花费能降低它们发生的次数。由于这些人关注的问题很少在这些主题上,因此为他们提取这些信息的职责就落到了某个资深的技术人员身上。

上面列出的需求 2 到 5 通过询问应用程序的拥有者一系列的问题来定义。由于这些回答是设计一个提出设施的基本输入(并且它们可能影响应用程序的多个方面,例如什么状态应该保存在 HTTPSession 中和什么东西应该保存在数据库中),因此它们应该在项目生命周期的早期被回答。如果具体的回答不能在基础架构设计开始时(或更糟糕,在实现时)给出,这各问题应该被作为项目成功的基本风险。

需求 1 有一点点复杂;而回答它需要质问企业,而企业可能并不容易知道这个答案的更多细节。下面列出的一些技术可能是需要的:

  • 分析现有系统的日志。
  • 使用业务智能或管理报告系统。
  • 访问职员,例如打电话给操作员。
  • 基于整体业务特性的估计(例如每年销售的抵押产品,每年的工作天数等)。

如果以上几条没一条可用(尽管总是有些某种形式的估计),那么可能需要应用某项技术来衡量现有系统作为任何新系统的需求分析--例如有什么测量方法或日志系统能被用于记录现有系统的事务处理率吗?

一旦工作量需求被估定,使用它们去计算要求的服务器容量也不是直观的。存在各种各样的基准,什么样的工作量可以被支持,什么样的服务器可以运行在什么样的平台上,这里面有很强的应用程序依赖性。在这里没有测试的替代品。因此,刻画工作量需求将遵循一个叠代的周期:

  • 从业务需求中构建基本的工作量需求。
  • 使用可用的基准提供容量的初始估计。
  • 实现一个早期的端对端的技术原型,测试它的性能和吞吐量并细化容量估计。
  • 设计和实现一个初始基础架构以及一个为渐增的容量提供的备份计划(如果需要的话)。
  • 重复地测试应用程序地每个可用版本并且修订规划的基础架构容量(如果需要的话)。

最后,对这个问题的讨论并未隐式地假定应用程序是单独的,也就是说,对整个应用程序存在一个单一的工作量和可用性的集合。实际上,并不总是这样的,可能是那些提供高可用性的措施仅仅对应用程序的一部分有必要--如果是这样的话,这将提供一个以极低成本实现所需的可用性的方式。例如:

  • 尝试通过用例来分析需求;一些用例(例如通过一个在线银行帐号支付)可能比其他的需要更低的可用性(例如预定旅游保险小册子)。
  • 尝试通过系统架构来分析端对端需求(例如,如果支付通过一个Web应用程序来完成,然后被置于一个异步处理队列中,那么可能只有Web 应用程序和队列需要高可用性)。

4.2.1 失效的成本和冗余性的成本
如前所述,为渐增的可用性提供冗余容量带来的成本必须小于失效所带来的成本。应该注意的是,这种成本通常远高于简单的获取额外的服务器,例如:

  • 为数据库服务器提供高可用性包括使硬件本身具有更高的可用性,而不是提供额外的冗余硬件。这可能包括复杂的服务器平台和实时磁盘复制技术。获取、实现和管理这些技术的成本远高于购买这些额外的基本服务器。
  • 整个基础架构的可用性受限于其中可用性最低的组件。因此提供服务器冗余性并不能带来帮助,除非电力供应、网络、防火墙等都以冗余容量被提供。
  • 定义一个全面的高可用性解决方案包括在整个拓扑结构中增加大量的“移动部件”--例如,不管采用什么样的服务器集群提供冗余性,都要求采用一些机制以转移失效。这种机制必须是已得到的,并且必须以一定的方式高可用性地部署并管理。

一般来说,以上所有的方面都比我们要求的可用性越来越快地增长--这是应该预期到的,因为无论花多少钱都不能保证 100% 的可用性。因此投资合理数量的钱到合理的可用性解决方案上很重要。

既然不可能不设计就推出一个解决方案,那么一个好的开始是去计算每小时故障时间的代价(也就是说如果我的应用程序失一个小时不可用,那么我要损失多少业务或产量?这总是正确的吗,或一个常见的、预期的问题会比一个突发情况花费要少?在不同的工作日或星期里成本会不同吗?)。实际上,您可能需要派生出几个特性,例如:

  • 一个长达两个小时的未计划中断的花费是 1千美元每小时。
  • 一个超过 2 小时但是少于 1天的未计划中断的花费是 b千美元每小时等。
  • 一个长达6 小时的计划中断在过了一个晚上之后的花费是 c千美元。
  • 一个在工作时间内发生并且用户注意了至少24 小时的计划中断的花费是 d千美元每小时等。

另外,存在一些细微的特征您可能需要确定。例如,如果在您的应用程序服务器中有“购物车”信息保存在内存中,那么任何服务器的失效都将破坏一定数量的购物车,除非您一步步的提供永久存储。因此,对于任何这种“有状态”的事务数据,您需要了解当数据丢失时的业务价值。

一旦您理解了这些问题的基本成本,下一步您需要确定的是每年可接受的故障成本--即每年您可能损失多少业务或生产量?如上所述的每种故障时间的代价都不同,您可能需要分别地了解每一类的可接受总成本。一旦您有了这些信息,您就有了设计一个可用性解决方案的基本参数。

4.2.2 改变工作量
如前一部分所述,设计一个合适的可用性解决方案的起点是了解正常操作情况下的工作量。然而,通常工作量需求很少能被表示成一个简单的数字,例如:

  • 很多应用程序在一天中表现出峰值(例如工作日的开始、午餐时间、晚上早些时候当大家都下班回家的时间等)。
  • 很多应用程序在一星期中表现出峰值(例如周一早上当一周的工作开始时、周六早上当周末开始时等)或在某些特殊的日子特别活跃(例如和电视节目或体育事件相关的Web 站点、在工作周内使用的应用程序)。
  • 一些应用程序可能在一年中表现出变动或和特殊事件相关(例如和体育季节或旅游相关的Web 站点等)。
  • 虽然存在一种方法那就是简单地提供足够的容量以适应任何最大的高峰负载,但这种方法将导致服务器容量的不充分利用,特别是如果多个应用程序以这种方式部署在它们自己的基础架构中时。下面图14 和 15展示了三种不同的假想应用程序每小时的工作量,以及当它们分开或部署在一起时导致的冗余容量。

图 14. 三个应用程序每小时改变的工作量
三个应用程序每小时改变的工作量

三个应用程序每小时改变的工作量

图 15. 单独与共享的基础架构中的冗余容量

评估改变工作量到这种层次的细节不是很容易,但是使用的技术和 参考资料部分中讲述的完全一样。

4.2.3 分析需求
使用以上信息,您应该能够定义一组或一部分应用程序,其中每一个可以被特征化为:

  1. 工作量
  2. 可接受的计划不可用性
  3. 可接受的为计划不可用性
  4. 隔离需求。

首先,隔离和可用性需求使您能够确定哪些应用程序可以共同托管在同一个物理服务器(或同一个服务器处理/应用程序服务器)上,如上 可用性、容量和冗余性一节中所述。因此,您可以将应用程序分成组以便共同部署,这基于:

  • 相似的可用性需求。
  • 兼容的隔离需求。

这些需求还允许您指定可用性解决方案的种类以用于每一组应用程序:

  • 一些应用程序可能能够容忍在正常操作期间相对长(例如1 个小时)未计划的问题,因而可能适合“cold standby”可用性解决方案,在这种方案中整个基础架构被重启(或被另外的基础架构替代)。其他的应用程序可能不能容忍这种问题,因而需要提供“hotstandby”基础架构,这种情况下失效的组件被已经运行的备份自动替代。
  • 一些应用程序可能能够容忍相对频繁的几个小时发生一次的问题以便允许应用程序升级。既然架构可以撤下来执行,升级处理因此可以相对直接。其他的应用程序可能不能容忍这种问题,因而要求更复杂的处理以每次撤下一台并进行升级然后恢复在线,在整个过程中保持整个基础架构可用。

下一步是确定和每个组相关的总工作量需求。结合测试或基准的结果,这将告诉您用以支持正常操作所必需的服务器容量。最后,您需要决定为支持可用性为每个组提供的总的冗余容量。我们提供了与本文档相关的电子表格和相关部分 计算可用性,以帮助您完成这些工作。要了解与用于支持故障转移和冗余容量工作量管理有关的信息,请参考 参考资料部分。

4.3测试可用性解决方案


分布式的高可用性环境拓扑结构很复杂,并且包含大量的“移动部件”或组件(开关、复制的磁盘、监控技术),需要主动的功能以支持可用性。虽然可能看起来很明显,但是全面测试这些组件,以验证当一个组件失效发生时它们会作相应的工作并维护可用性是很重要的。

所以,除了操作和工作量测试外,高可用性环境和部署它们的应用程序也应该进行某些形式的可用性测试。然而,将环境开启并等待失效的发生不是一种有效的测试方式。取而代之的是,需要应用一些触发和模拟失效的手段。

因此,对每一个组件的全面可用性测试计划将包括:

  • 什么样的失效可能影响组件(例如处理失败、硬件失效、网络失效)?
  • 每种失效如何触发/模拟(例如部署一段有错误的代码、使用调试器中止应用程序)?
  • 当一个失效发生时哪个人或处理应该做鉴别的工作?(例如是否使用一个克隆的组件自动检测?或由系统管理软件来做这个工作?或是应该进行一个操作员参与的手动处理?)
  • 什么样的处理或行为(如果有的话)应该处理每一个失效(例如识别工作量管理组件应该将处理切换到备份组件,识别手动失效恢复处理,或确定应该用于重启失效组件的脚本等)?
  • 什么样的测试可以被应用于验证该失效被正确地处理了?注意这里包括成功地处理未来的处理、以及成功地处理任何失效时正在进行的处理--例如正在进行的事务成功地重新选出并由后备服务器处理?

该信息将提供一组测试用例,可用于测试基础架构的高可用性特征。

结束语


可用性是一个可实现的服务水平特征,每个公司都牢牢抓住它。最坏的情况出现在因为没有进行仔细的可用性规划而导致负载被低估或硬件/网络带宽被阻塞时。要避免出现这种坏的情况,可以遵循本文中概述的步骤并使用作为企业中的可用性规划练习的一部分附带的电子表格。

正如本文所详细描述的,理解可用性规划所要求的核心概念和范围广泛的工作的的水平并不是简简单单的;然而,它完全在大部分 IT 构架师的能力范围之内。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=55410
ArticleTitle=IBM WebSphere 开发者技术期刊: 企业中的可用性规划
publish-date=02012004