构建云故障转移策略

创建一个包含特定于云的附文(详细说明组件和任务)的故障转移策略

在最近几年内,大部分组织和机构已将一部分数据转移到云中,这些组织和机构正在转移数据,或者正在深入规划一定程度的云使用,他们关注的两个主要问题仍然是可靠性和安全性。在可靠性方面,组织仍然需要至少 99.5% 的正常运行时间。不幸的是,在发生故障时,许多组织采用的仍然是 “反应性” 的应对措施,而不是采取更加审慎的前瞻性步骤:创建包含特定于云的包括附文(每个附文详细说明组件和任务)的云故障转移策略。作者提供了这样一个策略的路线图,演示了策略附文以及发生故障时应该采取前瞻性措施的场景。

Judith M. Myerson, 系统工程师兼架构师

Judith M. Myerson 是一位系统工程师兼架构师。她感兴趣的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性、 RFID 及时和项目管理。她是 RFID in the Supply Chain 的作者,也是 Enterprise Systems Integration, Second Edition Handbook 的编辑。



2012 年 4 月 23 日

云故障转移策略的目标是确保云服务在至少 99.5% 的时间内可用。它应该关注在云服务中运行的软件即服务 (SaaS) 应用程序、平台即服务 (PaaS) 平台或基础架构即服务 (IaaS) 虚拟机如何从故障数据中心转移到健康的数据中心,向云客户提供几乎无中断的服务。

云用户希望避免云服务的毁灭性故障,比如至少两次导致亚马逊的美国(北弗吉尼亚)区瘫痪的网络中断:

  • 2007 年,亚马逊的弹性计算云 (EC2) 服务受到了影响。
  • 2011 年,亚马逊的云计算 PaaS 解决方案、EC2 和关系数据库服务受到了影响。

亚马逊其他两个在美国的数据中心区域仍在健康运行。

在北弗吉尼亚区域,亚马逊的 EC2 服务使用的存储卷会自动自行创建备份来填充存储容量。当自动备份尝试使用超出存储容量上限的容量来存储自身时,就会导致中断。网络没有地方存储更多的备份。

这种类型的中断可能导致客户丢失数千小时的数据。本文将介绍如何避免这些类型的损失。本文将介绍云故障转移策略、特定于云的附文,以及阻止损害、修复问题、还原系统和通知客户的场景。

特定于 SaaS 的附文

以下是一个前瞻性云故障转移策略的特定于 SaaS 的附文中应包含的组件和任务示例。

组件

由于 SaaS 用户的控制能力有限,特定于 SaaS 的附文包含至少 3 个组件:

  • 用户控制
  • 用户许可
  • 故障转移计划

SaaS 用户拥有的惟一的控制权是访问 SaaS 应用程序以执行业务功能。用户许可组件(与提供方协商)应该指定以下实体的最大数量:

  • 要访问的 SaaS 应用程序。
  • 要访问某个应用程序的并发用户。
  • 分配给每个用户的请求。

用户许可组件应该指定允许用户访问的 SaaS 应用程序的类型,比如财务、项目管理、客户关系、零售管理,甚至是包含 IBM Rational AppScan 的漏洞扫描器。

故障转移计划组件应该表明 SaaS 应用程序实例已部署好,允许从一个托管的中心故障转移到另一个中心。它应该表明提供方提供了备份服务和服务水平协议 (SLA),并且遵守联邦隐私法和电子文档法等数据隐私法律。

任务

最低限度,应允许 SaaS 用户:

  • 访问每个用户能访问的最大数量的 SaaS 应用程序。
  • 基于为用户分配的角色来更新记录。
  • 接收安全警告。

只有提供方能够:

  • 购买软件升级许可。
  • 管理 SaaS 应用程序的补丁。
  • 访问系统应用程序和虚拟机。
  • 访问支持虚拟机的传统计算基础架构。

当一个 SaaS 应用程序失败时,提供方应该指定它如何在最短的时间内(不长于 5 分钟)将 SaaS 应用程序从故障数据中心故障转移到健康的数据中心,以及如何在修复问题后还原应用程序。

让我们看看一个 SaaS 故障场景,以演示这方面的知识。


SaaS 故障转移场景

一家公司内部部署的 CRM 应用程序以 SaaS 应用程序的形式成功迁移到了一个外部提供方,该提供方在美国数据中心区域托管着一个多租户环境。当某个数据中心的网络上的一个网络故障导致系统崩溃了两天时(因为存储数据的自动备份填满了所有存储容量,使得网络没有空间存储来自全球的 2 亿个事务),遇到的投诉量直线上升(您可能已想到):

  • 销售人员抱怨。
  • 服务中心的电话几天来从未停歇。
  • 提供方抱怨(它发现自己无法像像 SaaS 用户协商的 SLA 中保证的那样,在发生故障后 2 分钟内让 SaaS CRM 应用程序恢复正常)。

提供方急于获得快速的解决方案,并在其网站上发布了通知,“请耐心等待……我们很快就会让系统恢复正常。”其实并不够快。

提供方花了两天时间才让 SaaS 应用程序恢复正常。提供方无法提供高效的故障转移。以下是提供方可采取来阻止损害、修复问题、还原系统和通知客户的前瞻性操作。

阻止损害

要阻止损害,可以提前计划,准备好 SaaS 应用程序,将它作为用于自动故障转移的实例。应该已经在 SaaS 用户与提供方之间就 SLA 进行了协商。当性能远低于保证的服务可用性水平(99.9%)时,应该向提供方发出一个警告。根据网络上的流量,低于该水平的性能几乎可以实时地恢复到保证的水平。

同时通知 SaaS 客户,在提供方修复问题期间,会在另一个数据中心继续提供服务。提供方将让它们知道,何时在最初的数据中心还原服务。

(请注意,在这些策略中描述的所有前瞻性操作中有一个重要的元素,那就是通知:让关注的各方知道您的操作进度,常常会赢得更多纠正问题的时间;不让客户知道合理的状况通常不会有好结果。)

修复问题

提供方可提前规划故障转移,制定一条云故障转移策略:

  • 安装 SaaS 应用程序的实例,以便允许从一个数据中心故障转移到另一个数据中心。
  • 定期检查,以确定备份磁带在正常工作且没有缺陷。
  • 通过测试查看网络软件能否按预期修复问题。

还原系统

下一步是开始在系统出现故障的数据中心还原系统。提供方设置一个测试环境来测试还原的系统的恢复能力,确保相对顺利地完成到另一个数据中心的故障转移。例如,提供方随机关闭资源和服务,并留意结果。

当测试完成时,提供方将备份还原的系统,然后将它转移到一个生产系统。

通知客户

只要将 SaaS 应用程序还原到出问题的数据中心,提供方便可立即通知其客户还原已经完成,并告知将执行的 SLA 的条款(免费积分、赔偿、某个终止的机会)。


特定于 PaaS 的附文

一个云故障转移策略的特定于 PaaS 的附文中应该包含哪些组件和任务?

组件

PaaS 开发人员拥有更多控制权,所以特定于 PaaS 的附文包含的组件至少比 SaaS 附文多一项:开发人员应用程序的能力,PaaS 开发人员的组件包括用户控制、开发人员许可、应用程序开发(不可用于 SaaS 用户)和一个故障转移计划。

PaaS 开发人员控制 SaaS 应用程序和一个完整业务生命周期中的所有应用程序的开发,例如电子表格、文字处理器和备份。

根据与提供方的协商,开发人员许可组件应该指定以下实体的最大数量:

  • 要开发的应用程序。
  • 开发人员允许的并发应用程序。
  • PaaS 允许的访问应用程序的 SaaS 用户。

应用程序开发组件应该指定要开发的应用程序类型,比如:

  • SaaS 应用程序
  • 网站
  • CRM 应用程序
  • 移动应用程序
  • 收费和薪资应用程序
  • 服务交付平台应用程序(比如移动电视)
  • 内容交付管理应用程序

故障转移计划组件应该指定已部署好的 PaaS 应用程序实例,从而允许从一个托管的中心故障转移到另一个中心。该组件应该指定一个 PaaS 开发人员将使用她自己的还是提供方的故障转移应用程序,她是否能够采用第三方工具来执行负载平衡等任务。该计划还应该表明,提供方是否提供了备份服务和 SLA,以及它是否遵守数据隐私法律。

任务

PaaS 开发人员可以:

  • 构建、部署和运行应用程序。
  • 管理补丁和升级。
  • 确定 SaaS 用户是否可访问 PaaS 上共存的 SaaS 应用程序。
  • 灵活地自定义他们自己的平台,以满足当地市场条件。

他们还可以:

  • 扫描应用程序中的漏洞。
  • 配置应用程序防火墙。
  • 构建和监视安全警告。
  • 执行备份操作。

在最低限度上,只有提供方能够:

  • 运行系统应用程序。
  • 运行虚拟机。
  • 访问支持虚拟机的传统计算基础架构。

让我们看看一个 PaaS 故障场景,以演示这方面的知识。


PaaS 故障场景

一个 PaaS 开发人员的 “资源优化” 应用程序出现故障。该故障导致此平台和同一个提供方托管的其他 PaaS 平台完全关闭。这可能是由未能创建可在主机发生故障后继续生效的重复服务实例所导致的。不幸的是,“资源优化” 应用程序没有识别出故障,也没有实现较短的超时和快速重试。

以下是提供方可采取的前瞻性操作,可执行这些操作来满足与提供方协商的特定于 PaaS 的附文中有关阻止损害、修复问题、还原系统和通知客户的条款。

阻止损害

要阻止损害,PaaS 开发人员需要构建仅包含单个主机的简单服务,而不是构建包含多个独立的主机。这允许开发人员创建可在主机发生故障后继续生效的重复的服务实例。

修复问题

当发生故障时,开发人员的软件应该快速识别这些问题并启动故障转移过程。

让我们假设,如果开发人员有一个包含业务逻辑组件 A、B 和 C 的收费应用程序,那么他可以按照以下方式建立一个服务组:

(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)

Where n is the number of component type representing the number of a 
service group category

        for service category 1, 
                A1 is the logic to find service code
                B1 is the logic to insert service category into the bill
                C1 is the logic to check the accuracy of zip codes
				
        for service category 2, 
                A2 is the logic to find service code
                B2 is the logic to insert service category into the bill
                C2 is the logic to check the accuracy of zip codes
				
        for service category n, 
                An is the logic to find service code
                Bn is the logic to insert service category into the bill
                Cn is the logic to check the accuracy of zip codes

如果一个运行 PaaS 的虚拟机发生故障,该故障会导致整个系统组丢失。这意味着,如果一个系统组中的组件 A1 发生故障,那么其他两个组件 B1C1 也会发生故障。如果不止一个服务组,那么整个系统可能都会发生故障。

要修复该问题,开发人员应该组件分解为独立的池,如下所示:

(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn)

这样,开发人员就可以在健康的数据中心创建多个冗余的服务副本。这意味着,如果组件 A1 发生故障或运行缓慢,同一个独立池中的所有其他组件 A2... An 不会发生故障。第二个独立的组件池 B1, B2...Bn 和第三个组件池 C1, C2, ...Cn 也不会发生故障。

在执行收费应用程序的所有独立服务池的故障转移期间,开发人员为缓慢的服务使用快速超时和重试。开发人员需要确定何时停止超时和重试,以避免使用所有等待缓慢或故障服务的组件所导致的系统锁定。

还原系统

下一步是开始在关闭的系统所在的数据中心还原 PaaS 平台。在测试环境中,提供方随机停止支持 PaaS 的资源和服务。开发人员在各种条件下测试应用程序,以测试 PaaS 的恢复能力。当测试完成时,提供方备份还原的系统,然后将它转移到生产环境。

通知客户

只要 PaaS 应用程序开始在还原的数据中心中正常运行,提供方即向 PaaS 开发人员告知还原的系统和执行的 SLA 条款。


特定于 IaaS 的附文

最后,云故障转移策略中的特定于 IaaS 的附文中应该包含哪些组件和任务?

组件

因为 IaaS 是 PaaS 级别的基础,所以特定于 IaaS 的附文应该包含一组不同的组件。除了用户控制、企业许可和故障转移计划之外,您还可以找到一个虚拟机组件。

一位 IaaS 专家负责控制虚拟机;PaaS 开发人员和 SaaS 用户不会控制虚拟机。

企业许可应该指定以下实体的最大数量:

  • 要开发、运行和维护的虚拟机。
  • 并发访问虚拟机的 IaaS 专家。
  • 在 IaaS 虚拟机上工作的 PaaS 开发人员。

故障转移计划应该允许 IaaS 虚拟机从一个托管的中心故障转移到另一个中心。它应该允许 IaaS 基础架构和网络专家与 PaaS 开发人员合作设置故障转移虚拟机。

任务

IaaS 专家可以:

  • 开发、管理和访问虚拟机。
  • 授权 PaaS 开发人员在虚拟机上开发应用程序。
  • 使用第三方工具提高性能(例如负载平衡器)和保护系统数据。
  • 扫描虚拟机中的漏洞。

这些专家还可以:

  • 配置虚拟机防火墙。
  • 构建和监视安全警告。
  • 备份虚拟机。

只有提供方可访问支持虚拟机的传统计算资源的基础架构。IaaS 专家无法访问它。

让我们看看一个 IaaS 故障场景,以演示这方面的知识。


IaaS 故障场景

如果在高 I/O 时缺乏需要使用的更多资源,虚拟机会发生故障。换句话说,不存在允许故障转移到健康的数据中心的虚拟实例。

提供方可采取以下前瞻性操作。

阻止损害

要阻止损害,可以计划在高 I/O 时运行虚拟机需要多少资源。举例而言,这可通过容量规划和性能阈值策略来完成。(参考资料 一节中提供了更多介绍阈值策略和容量规划的更详细的文章。)

修复问题

要修复问题,可建立性能阈值策略,确定何时配备在高 I/O 期间所需的虚拟机,以及如何确保所有服务激活点都得到满足。确保主机控制的数据中心中已部署了您的虚拟机实例。

另外,当发生故障时,计划快速识别它们,让提供方将基于 IaaS 的虚拟机实例转移到另一个数据中心。

还原系统

下一步是开始在关闭的系统所在的数据中心还原 IaaS 平台。在测试环境中,提供方可随机停止支持 IaaS 的资源和服务。测试完成后,提供方备份还原的系统,然后将它转移到生产环境。

通知客户

只要虚拟机开始在还原的数据中心中正常运行,提供方便会告知 IaaS 专家,数据中心中的虚拟机还原已完成。


结束语

要透彻理解高效的云故障转移策略,需要进行前瞻性的策略规划,以:

  • 确定为什么会发生云故障。
  • 识别这些故障。
  • 在策略中准备特定于云的附文,以便前瞻性地应对引起这些故障的变化因素。

您的开发人员、用户和提供方团队需要紧密合作来建立策略和附文。该团队会发现,如果解决了应该包含哪些元素、组件和任务的问题,那么他们建立策略的工作会大大简化。

在本文中,我介绍了应该视为每个云计算模型(SaaS、PaaS 和 IaaS)中的故障转移策略的一部分的基本组件和任务。我还提供了有关这些提供方如何阻止损害、修复问题、还原系统以及通知每个模型的客户的建议。

(参考资料中的)其他文章更深入剖析了用途、范围、后台、操作和约束等策略元素的定义,这些元素会帮助您建立云计算策略,用该策略来处理阈值触发器、工作负载平衡、一般安全性、移动访问、应用程序迁移、服务风险管理、性能指标等问题。在我提供的所有策略指令中,可靠性和安全性始终是关键的基础组件。

参考资料

学习

获得产品和技术

  • 查找可用于 IBM SmartCloud Enterprise 的 产品映像

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing, SOA and web services
ArticleID=811666
ArticleTitle=构建云故障转移策略
publish-date=04232012