灾难恢复方案:虚拟化可帮忙

日期: 2015-12-28 作者:Chris Evans翻译:余彥 来源:TechTarget中国 英文

虚拟化彻底改变了我们在数据中心部署应用的方式,并延伸到了灾难恢复。

以前,配置过程要花几周甚至几个月的时间,如今却转变为几分钟内搞定的自动化任务。虚拟化具备一些能提供敏捷性、灵活性和更好弹性的特点,包括snapshots(快照)、vMotion和HA/FT(高可用性/容错性)。

与此同时,灾难恢复也转变了。在物理服务器环境下,意外中断的恢复过程需要失效备援到主要环境或完全相同的硬件和操作系统的复制,以还原备份。

据称,虚拟化能废除上述恢复过程的很多步骤,使灾难恢复的部署变的更容易更简单。但是能简化到什么程度呢?

本文中,我们会调查灾难恢复计划和配置过程的每一步,以及虚拟化可以帮助简化到什么程度?

物理 PK. 虚拟

服务器虚拟化是一个很棒的工具,能够加强和简化应用部署的工作量。硬件使用不足——典型是单一应用对应一个操作系统实例,把物理资产集中成更高效的封装时,虚拟化为服务器提供隔离性和管理效益。

虚拟服务器综合了代表物理磁盘的虚拟磁盘文件,处理器、存储器和其他附件的配置信息。这使得虚拟服务器——或者虚拟机器(VM)——非常轻便,也允许虚拟化提供一些能力,诸如高可用性(在出现硬件故障时将VM移到另一台服务器上)和容错性(如果硬件出问题,运行能掌管服务的VM重映像),而无需大量附加硬件或者复杂的配置。

将VM看成一套文件的能力意味着备份和恢复也一样简化了。运行VM的硬件各种各样(无限制),管理程序因此承担了翻译物理地址到虚拟设备上的任务。这表示VM和封装在它内部的工作量比以往更加轻便。

灾难恢复计划和执行

我们来看看典型灾难复原方案的关键元素,以及看清虚拟化技术可以在哪里帮上忙。

灾难恢复计划的第一步,是查看商业需求,以及将应用与服务水平目标匹配。在灾难恢复领域,测量标准是复原时间目标(RTO)和修复点目标(RPO)。

RTO指定应用在服务必须恢复前可以忍受的总故障时间。任务严苛的应用有很低的,甚至为零的RTO(表示服务必须一直连续)。

RPO描述了应用可以忍受的数据损失总量。该指标有可能为零(比如,没有数据损失)或者以分钟或小时来衡量。一些无核app(比如那些用来报告的)可能可以忍受的RPO为24小时,尤其是数据可以从别的来源产生时。

此时,与技术的选择没有关系。开展商业影响/风险分析是基于人们对商业需求的评估。然而,随着我们在灾难复原计划过程中更进一步,我们会发现技术选择出现了。接下来的问题,变成了虚拟化到底能在哪里帮助灾难复原。

灾难恢复风险评估

下一步,灾难恢复计划过程要获取从影响分析中得到的服务要求,并且提出风险评估。

对于每个应用或者系统,我们可以将RTO/RPO要求对应到可能的风险,评估那些风险的可能性,并开始为每项风险制定出减轻和修复策略。下面的表格展示了一些例子:

此时此刻,我们可以看到,要在物理和虚拟基础设施中做出选择。

第一个例子显示,基于物理硬件的集群解决方案如何用来履行服务要求的。尽管不能接受数据损失,应用可以忍受高达30分钟的中断。

可用以下两种方式实现。一种是失效备援的镜像物理设施,价格不菲。另一种是拥有高可用性的虚拟设施,比如VMware HA。该功能可使在备用硬件上的应用自动重启,运用共享存储基础框架以确保RPO为零。

第二个例子展示了一个企业的网站需要24*7小时不停机。这种情况下,应用以静态数据为基础,在一个或者更多的访问同一数据池的网络服务器实例上实现。如果任一服务器停止,负载均衡软件会重定向通信路线到一个新服务器上。

虚拟化通过单独的VM提供网络服务器实例,就可以应用在上述场景中。如果一种硬件故障总是发生,新的网络服务器就可以从模板中部署并加入到负载均衡列表中,而无需更多复杂的HA或者集群软件。该方案在跨地域的场景中也可以实现。

第三个例子凸显了传统应用如何被传统的或者基于VM的备份所保护。相比使用物理基础架构,虚拟方案提供更快的备份和还原能力。

建立灾难恢复方案

现在,我们已经识别了应用和量化了相应的风险。我们开始完整制定出减轻和修复场景,作为应用和基础设施设计的一部分。与纯粹的物理服务器运行相比,虚拟化提供了一些独特的性质,可以帮助达到业务连续性。包括:

基于模板化的应用工作负荷,有能力在几分钟内加速|VM实例。

通过容错性和高可用性的应用恢复,可以消除对复杂修复措施的需要,包括在大城市。

VM失效备援的一体化和自动化可适用于偏远地区,使用工具有VMware’s Site Recovery Manager。

硬件抽象化允许VM在不同的硬件平台上修复。与生产现场相比较,硬件平台可能是高低不一的规格或者混合的。

VM/服务器备份基于来自下面存储器的文件映象复制。

失效备援与应用的集成,通过使用基于主机的工具,避免崩溃一致性副本和应用恢复的更高可能性。

通过工具,比如vMotion,避免灾难。

所有这些特征允许应用以比典型物理服务器更高效的方式在基础设施上部署。

测试和验证

设计之后,需要测试和验证灾难复原计划。是否使用虚拟基础架构,方案必须包括验证应用有能力在灾难复原模式运行,并且以每个系统服务水平目标(RPO/RTO)的形式恢复正常运行。

虚拟化不能避免测试(和确认基础设施每一部分配置正确),但它可以使测试过程实现起来更简单。比如,提出在灾难复原现场的VM,测试功能和数据完整性,而保持VM的隔离性,以避免与正运转的生产现场一起崩溃。无需影响灾难恢复过程就可实现。反之,对物理服务器的测试会让生产服务处于危险中,直到测试结束。

总结

虚拟化以更高效和简单的方式,提供了大量执行灾难复原的机会。然而,正如我们所看到的,基于商业需求,它不能代替深思熟虑、详细说明的综合灾难复原方案。随着技术持续进化,灾难复原方案需要回顾和更新,以反映当前的虚拟化能力,从而变成一份“活的”文档,以确保不间断的业务持续性。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者

Chris Evans
Chris Evans

Chris Evans已经在IT行业工作了25年以上。早期的职业生涯始于大型机领域,然后进入存储和系统编程领域,专注于开放系统存储和目前流行的虚拟化和云技术。

相关推荐

  • 用脆弱性评估流程击败黑客

    无论IT的风险是什么,查找、修复并保护组织的数据、应用、网络、系统等组件中常见或不常见的漏洞都有一套基本的最佳实践。本提示将就如何创建一个脆弱性评估流程提供建议。

  • 灾难恢复/数据外泄的业务连续性计划

    Harvey Koeppel说,随着我们变的“天生数字化”,一份好的企业灾难恢复/业务连续性计划应该把数据放在第一位。他罗列出了10条技巧。

  • 如何测试你的DR/BC计划

    多年来,我在一定程度上自大的发表很多意见,以接近建立灾难恢复/业务持续性计划。我的建议包括,认清技术的修复和持续性仅仅是DR/BC计划应该包含的一部分

  • VMware食言:背弃EMC的Virtustream混合云

    在风险讨论的几月之后的现在,VMware不再参与EMC的Virtustream混合云品牌构建业务。通过8-K监管文件,VMware声明确认退出该业务。