云环境中的灾难恢复

应对云提供商完全丢失服务的计划

为了保持业务连续性,即使是最小的组织也需要为应对灾难做好准备 — 云提供商完全丢失服务的情况不太可能出现,但是不为此制订计划是不负责任的。灾难恢复可能很复杂,但是在云计算环境中这简单得多。了解作者在他的组织最近的灾难恢复工作中采取的步骤,学习如何参照这个流程完成自己的灾难恢复工作。

Bill Robbins, 系统工程师, Educopia Institute

/developerworks/i/p-brobbins.jpgBill Robbins 是 Educopia Institute 的系统管理员,这是一个在 Amazon EC2 云上运行基于 Linux® 的基础设施的非盈利性组织。他拥有 Georgia Institute of Technology 的电子工程学士和硕士学位。在 2008 年加入 Educopia 之前,他在 BellSouth and Emory University 从事 IT 和网络管理,还在佛罗里达和乔治亚州的电信公司担任过设计工程师。早在出现图形化终端之前,他已经使用过许多种 UNIX 系统。



2011 年 5 月 03 日

许多小公司正在把它们的基础设施转移到云计算环境中,以此简化管理。但是,许多公司没有认识到仍然应该为基础设施准备灾难恢复计划。云改变了执行灾难恢复所需的条件;它们不同于服务器-客户机和网络基础设施所需的条件。本文讨论这些差异和需要采取的步骤。

我所在的小型组织 Educopia Institute 为学术交流计划和实现共享的计算机基础设施项目。我们最近完成了灾难恢复准备工作,并由此发现在云计算环境中这个流程非常简单。在本文中,讨论我们采取的步骤。

常用缩略词

  • DNS: 域名系统
  • SSL: 安全套接字层

注意:如果您在云中运行物理生产环境而不是开发环境,本文中的信息也是适用的。

虚拟化

根据定义,在云中运行就意味着使用虚拟服务器。与使用物理服务器相比,使用随时可以运行的虚拟服务器拷贝要容易得多,而且更便宜:不需要为服务器的灾难恢复实例准备额外的硬件,但是需要把映像存储在灾难恢复云中。与从头重新构建物理服务器相比,装载并运行虚拟服务器要快得多。这个随时可以运行的虚拟服务器拷贝是灾难恢复计划的核心。

要想开始制订灾难恢复计划,需要有能够运行服务器映像的第二个物理位置。这个位置应该距离您的主服务器的位置至少几百英里。因为您的团队已经能够通过 Internet 连接这个服务器,所以他们不需要到灾难恢复站点去。

在 Amazon EC2 内迁移

下载 中提供一个 ec2-migrate-manifest 命令示例 [description | syntax | options],我的组织使用它在 Amazon EC2 内迁移基础设施。

我的组织使用 Amazon Elastic Compute Cloud (Amazon EC2),把数据从一个 Amazon 数据中心转移到另一个是非常简便的。在 Amazon 云中需要的命令是 ec2-migrate-manifest。但是,与在同一提供商的数据中心之间转移相比,从一个提供商的数据中心转移到另一个提供商的数据中心要复杂一点儿。有许多云计算环境提供商;您必须判断哪一家最适合实现灾难恢复。无论是使用 Amazon EC2 还是其他提供商的服务,您必须先进行小规模的概念验证,然后再执行全面的灾难恢复工作。


概念验证

在概念验证中,需要把虚拟服务器的一个完整映像从主数据中心复制或迁移到灾难恢复数据中心。在最初,这个映像不必是生产服务器的最新的完整映像:这时只是要证明能够在另一个云中重新创建原来云中的服务器。概念验证不需要运行当前的数据,也不需要有真实的 web 地址。

这个阶段也不需要花费很多费用。在所有云计算环境中,设置一定的存储空间并运行一个小服务器是很便宜的。如果可以的话,使用当前的云计算环境实现灾难恢复,这样做的费用更低。成功完成概念验证之后,就可以继续实现计划了。

请记住,您可能不会很快用到这个提供商或站点:只需经常关注它,检查它是否正常运营。定期向灾难恢复提供商提交映像,这样就能知道它是否正常。


在灾难恢复站点上必须运行什么

显然,您必须了解并记录在云中运行和设置了什么,这意味着需要收集数据。

完成这项工作之后,要仔细地评估哪些东西必须转移到灾难恢复站点上。并不是简单地 “转移所有东西”:有些特性或功能可能是用于测试的,或者不太重要,可以以后再恢复。

如何查明云中实际运行的所有东西呢?应该记录这些信息,确保文档中的信息是最新的。登录正在运行的生产服务器上的 shell,确认它运行正常。执行以下步骤创建文件,这些文件可以帮助记录服务器上的东西(这里给出的命令在 Red Hat Linux® 的任何变体上都应该是有效的):

  1. 记录正在运行的进程:
    ps –ef  > /tmp/procs.txt
  2. 查明服务器上活跃的连接:
    netstat -an > /tmp/connects.txt
  3. 查明服务器上的文件系统:
    df -ah > /tmp/mounts.txt
  4. 记录正在运行的 cron 作业:
    cd /var/spool/cron
    
    more * > /tmp/crons.txt

因为是要转移虚拟服务器,而不是重新构建服务器,所以不需要识别系统上的每个软件包和每个模块(比如 Apache 或 Perl 模块)或 Ruby GEM。因为要复制虚拟映像,所有这些元素都会存在。

连接列表帮助判断在灾难恢复站点上需要的安全性和防火墙设置。要点:能够从这个列表看出允许访问的其他服务器,以及允许从哪些其他服务器访问您的服务器。

进程列表应该与灾难恢复站点上运行的服务器一致。(与运行的硬件相关的一些进程可能不一样。)可以看出是否配置了所有系统启动脚本。

进程没有正常启动的问题可能需要在主环境的启动脚本中解决。尤其是,必须检查各个 cron 作业:

  • 运行作业的时间是否确实有意义?
  • 由于服务器将在另一个时区中运行,是否需要修改某些设置?
  • 是否有任何脚本调用了主云计算环境中的设施?如果是这样,在灾难恢复环境中也需要可以使用这个设施。

对于文件系统,主要关注它们的大小:不希望在灾难恢复站点上文件系统突然满了。

现在,研究这些列表,决定在灾难恢复站点上必须复制什么东西。如果可以缩减列表,应该尽量缩减。准备好列表之后,就可以执行下一步了。


及时更新灾难恢复站点

现在,可以创建映像并把它发送到灾难恢复站点。具体流程因云提供商而异。

还必须考虑每隔多长时间执行这个流程,以及如何及时更新灾难恢复站点。应该权衡考虑您能够承受的时间和数据损失与确保避免损失所需的代价。显然,您不希望丢失任何工作或数据,但是确保这一点是有代价的。

对于我的组织,我们认为丢失一周的数据是可以承受的,所以我们每个月创建一个完整的虚拟映像。这个映像也被发送到灾难恢复站点。我们每周执行一次完整备份,每天执行一次增量备份。我们决定把每周的完整备份发送到灾难恢复站点。在主站点上不需要同时保留这些备份,只需多花一点儿钱通过 Internet 发送它们。


全部工作的步骤

现在,您已经有了一个检查表,还知道备用云服务器将在哪里运行。现在需要执行 beta 测试。

可以把生产服务器的完整映像复制或迁移到备用云。可以在您方便的时候运行备用服务器,确保流程的这个部分符合期望。确认流程正常之后,还需要执行几个步骤才能完成灾难恢复工作。

新的网络标识

最大的变化是灾难恢复服务器的网络标识。简单地说,这个服务器必须使用不同的 IP 地址。所有域名可以保持不变,但是它们的 IP 地址必须改变。这个变化会导致几个问题,其中最重要的是修改域名的 IP 地址。(这称为 DNS A 记录。)在执行灾难恢复测试和发生实际灾难时要修改 A 记录。

尽管更新 A 记录所用的方法各不相同,但是一般都需要知道您在 DNS 提供商的账户 ID 和密码,以及如何修改记录。在灾难恢复站点上永久保留一个 IP 地址,输入这个 IP 地址作为 DNS 条目。给它指定一个名称,确认在查找这个 IP 地址时会返回有效的记录。

例如,如果您的网站是 www.agreatsite.com,那么给灾难恢复服务器设置 alt-www.agreatesite.comdrwww.agreatesite.com 这样的永久 DNS 记录。在执行灾难恢复测试(和发生实际灾难)时,只需访问 DNS 提供商站点并把 www.agreatsite.com 的 IP 地址改为灾难恢复站点的 IP 地址:不需要修改或删除 alt-www.agreatsite.com 的条目。如果其他站点或服务器也必须把您的灾难恢复服务器输入它们的安全设置,有 DNS 记录会有帮助。

新标识的安全设置

接下来,把灾难恢复 IP 地址通知其他职员、分部、厂商和合作伙伴:当前在其安全设置中包含您的主 IP 地址的所有实体。对于通知的范围,必须仔细地考虑和研究。当您的服务器试图连接另一个系统时,需要安全设置。

在您的防火墙中可能有针对这些连接的规则,也可能没有(很可能没有)。通常,对于您自己的服务器发起连接没有限制。同样,在运行 netstat 命令时,可能会看到活跃的连接,也可能看不到。有些连接只在需要时才会建立,而不是通过 cron 在指定的时间建立的。例如,可能只在需要时手工地通过安全的传输通道发送某些东西的更新。

灾难恢复站点上的修改

最后,您需要了解在灾难恢复站点上不一样的所有其他东西。一定要考虑以下方面,列出必须做的修改。

  • 时区
  • 用于备份和存档的存储
  • 在云计算环境中需要模拟的设施
  • 引用这些设施的所有脚本或代码
  • 使用 IP 地址而不是主机名的所有脚本或代码

尽可能在执行灾难恢复测试之前完成修改,如果只能在测试期间修改它们,那么要做好准备。


运行灾难恢复测试

现在应该实际运行一次完整的灾难恢复测试:仅仅记录数据并 “认真考虑” 这个步骤是不够的。安排好步骤的执行次序,然后确定测试的时间。团队成员必须确定合适的日期和时间,在这个时间短时关闭站点不会有很大损害。应该通知相关方面,确保安排的测试时间不会发生冲突。

我要强调一下:灾难的发生是不可预测的,但是灾难恢复测试时间是确定的。

开始测试

测试的第一步是修改 DNS 设置,因为修改结果的传播要花一段时间。然后,可以关闭主服务器。但是,在启动灾难恢复站点之前,应该考虑是否可以快速完成所有工作,从而减轻关闭主站点的损失。

您可能配置了监视或警报,比如 Nagios。如果是这样,可以关闭警报。另外,其他系统可能依赖于您的主服务器。应该怎么办?快速完成目前的工作或者转交给其他服务器,同时启动灾难恢复站点。

转到灾难恢复云

现在,可以在灾难恢复站点上启动服务器。按照前面完成的检查表执行操作。根据在灾难恢复站点上保存映像的方式不同,可能还需要恢复备份。

引导服务器之后,可能需要在服务器上进行最后的修改。例如,可能必须修改服务器上运行的脚本以使用灾难恢复存储设施。还必须删除或修改定期创建灾难恢复映像的任务。可能还必须修改运行 cron 作业的时间。

运行功能性测试

等一段时间,让 DNS 修改能够传播开(我们感觉需要 2 到 4 小时),然后开始测试。应该按一定的次序执行测试,还要做一点儿反向工程。首先检查最明显的方面,比如网站是否正在运行。您可能有一个 RSS feed,它列出云中运行的任何站点。如果没有,现在创建这个 feed。它应该包含公共的站点以及用来管理服务器的站点,比如 phpMyAdmin 和 Drupal 用户登录。还应该检查进程监视。是否有原来临时运行的进程?现在可以关闭它们。一些进程在另一个站点上可能必须关闭,现在可以打开。

查看前面获取的记录。仔细检查所有进程和网络连接是否都存在。在此之后,每个组织需要运行不同的测试集以检验恢复是否成功。如果所有测试成功地完成,最后需要确保所有 cron 任务已经就位,观察它们在后几天的表现。

记录详细信息

测试阶段的工作已经完成了,但是结果可能并不完美。现在需要总结并记录所有步骤,包括在测试期间缺失的东西。以后可能有机会再次测试。


转回主服务器并再来一次

把 “转回主服务器” 安排在下一个周末。对于运行真正的完整的灾难恢复测试,这个步骤非常重要:实际上要运行两次,通过错误学习经验,确保在发生真正的灾难时灾难恢复能够完美地执行。

在复原活动期间,再次执行前面的过程。安排另一次计划内停机,让所有东西回到正常状态。现在,您能够确信所有东西都就位了。

一定要全面审查灾难恢复计划。需要定期运行测试,可能应该不少于两年一次,但是不多于每六个月一次。对于任何系统变动,都应该进行评估,考虑它们是否要求修改灾难恢复计划。


结束语

每个组织和站点的灾难恢复计划各不相同。在本文中,我提供了一个起点,讨论了要考虑的问题。肯定有其他一些东西需要研究。例如,如果有与 IP 地址相关联的 SSL 证书,可能需要多做些工作。还可以避免编辑在主站点和灾难恢复站点上运行的脚本,只需在脚本中添加代码,让脚本能够探测运行它们的位置。我计划下一次完成这个任务,而且我发现 www.whatismyip.com 站点很有帮助。可以使用命令:

wget http://www.whatismyip.com/automation/n09230945.asp -O public_ip.txt

返回公共 IP 地址,然后在需要修改的脚本中的 case 语句中使用这个 IP 地址。

灾难恢复计划还提供另一个好处:您现在有一个随时可以运行的完整的最新的测试环境。在某些情况下(比如要对软件包进行重大升级),希望先试验修改环境所需的所有步骤,然后再修改生产环境。可以启动灾难恢复环境,查明完成步骤需要什么 — 甚至可以编写执行步骤的脚本,然后再修改主环境。

如果您还没有灾难恢复计划,现在应该开始制订它了。云和虚拟计算让这个工作比以前简单多了。祝您好运!


下载

描述名字大小
使用 ec2-migrate-manifest 命令的示例ec2-ami.zip1KB

参考资料

学习

获得产品和技术

  • 以最适合您的方式 评估 IBM 产品:下载产品试用版,在线试用产品,在云环境下试用产品,或者在 SOA Sandbox 中花费几个小时来学习如何高效地实现 SOA。

讨论

条评论

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
ArticleID=656251
ArticleTitle=云环境中的灾难恢复
publish-date=05032011