NetApp Tech OnTap
     

怎样使您的灾难恢复计划坚固可靠?

根据美国国土安全部的研究,只有 1/4 的美国公司有灾难恢复计划。在这些公司中,实际上仅有 30% 测试了自己的计划。令人恐惧的事实是,也许大多数公司都处于保护不够的状态,而且相信自己的计划非常充分的人也许应该重新考虑一下。

20 多年来, Datalink 公司一直在帮助各公司应对复杂的信息存储、管理和保护挑战。我们拥有广泛的数据保护技术专长并形成了很多最佳实践,这些最佳实践已经概括在我们的数据连续性和增强数据恢复实践中。

大约 75% 的 Datalink 新客户与我们初次接触时,手上都没有一个切实可行的灾难恢复计划。灾难恢复计划是备份和恢复的自然延伸,应该是包括备份 / 恢复、业务连续性和灾难恢复在内的全面数据保护计划的组成部分。本文将概述一些我们用来帮助客户进行这类规划的经验法则。尤其是,我将描述:

  • 怎样正确判断您的灾难恢复计划是否足够可靠;
  • 能使灾难恢复规划更简单的技术;
  • 集成的数据保护的价值。

您的计划足够可靠吗?

考虑到很多公司业务实践变化和数据存储量增加的速度,一个制定时很充分的灾难恢复计划现在也许不够充分了。 Datalink 常常看到,业务需求和 IT 基础设施之间存在差距。这些差距可能与技术有关,与流程有关,而且最近还发现,与人员可能也有关。在目前的经济状况下,各公司都在尽可能地使员工竭尽全力,从而在人员方面引起了可能影响灾难恢复就绪性的差距。

例如,我们最近与一家中等规模的制造公司合作,以加强其灾难恢复能力。这家公司多年前做过一次业务影响分析,当时得出的结论是,有 40 个应用是运行业务所必需的。不过,我们的分析显示,实际上有大约 70 个应用是必需的。说句公道话,有些差异可能是自初次评估以来所发生的变化引起的,而另一些差异也许是以前的分析遗漏了一些事情所致。

用面向流程的方法确定关键应用
我们用一种面向流程的方法来帮助确定哪些应用对业务而言是关键的。就一家制造公司而言,要想正常运转就必须做到的、最基本的事情有4件:

  • 订购和接收原料;
  • 支付原料费用;
  • 生产和交付产品;
  • 收取所交付产品的账款。

就上述例子而言,通过从流程的角度了解每个应用,以及询问该应用是否对完成上面所列一项或多项职能是必需的,我们确定了 70 个应用。您也可以对您自己所在的公司进行类似的分析。

牢记基础设施应用
不要忽略关键的基础设施应用。有很多必须运行的“ 0 级”应用,如 Active Directory 、 DNS 、电话系统、网络,等等。如果 DNS 不运行,那么关键业务应用可能也不运行。

为每个应用建立恢复目标
一旦确定了应用清单,就需要为每一个应用建立恢复目标。一般情况下,有4个关键的衡量标准需要考虑:

  • 可用性―― 可用性是应用或数据集可供使用的时间。它常常以百分数表示。例如。 99% 的运行时间对应于每年差一点儿不到 88 个小时的宕机时间,而 99.999% 的运行时间对应于每年比 5 分钟多一点儿的宕机时间。
  • 恢复时间目标 ( RTO ) ――恢复时间目标定义的是,如果发生故障,应该花多长时间恢复。一个 20 分钟的恢复时间目标意味着,在发生故障之后,一个应用或数据集将在 20 分钟之内重新恢复在线。请注意,长的恢复时间目标与积极的可用性目标是相互矛盾的。
  • 恢复点目标 ( RPO )―― 在大多数情况下,当故障发生时,要消除所有可能的数据损失,费用会高得不能承受。恢复点目标定义的是,您愿意丢失的最大数据量。例如,一个小时的恢复点目标意味着,一个应用或数据集将能够恢复到先于停机发生时刻不超过一个小时的点。(请注意,就大多数应用而言,这类目标意味着每小时一次的备份。)恢复点目标不直接影响可用性或恢复时间目标,除了积极的(短的)恢复点目标延长了完成恢复过程所需时间这种情况。
  • 数据保留―― 数据保留衡量标准定义的是,一个给定的数据集必须保留多长时间,以满足备份或法规要求。您可能同时有分别针对在线和离线(磁带)数据副本的数据保留衡量标准。例如,对一个特定的备份,您可能在线保留一个月,然后再在磁带上保留一年。

也许,您不是针对每一个应用有不同的目标,而是要建立几个不同的服务“层”,将应用归类到这些层中。您还需要了解应用之间的依赖关系,并排定应用重新启动的顺序。在正常运行情况下看似显然的依赖关系,如在数据库应用之前启动数据库,在危机中非常容易被忽略,甚至一些小的错误也可能耗费大量宝贵的时间。

协调各项活动
为了真正取得灾难恢复规划的成功,必须努力协调各种活动,做好部门间的工作,所开展的工作会涉及所有业务领域。不幸的是,还没有人设计一个软件工具,可以包揽这些需要仔仔细细和考虑周到地先期开展的跑腿活儿。如果 IT 部门没有与业务部门交流,那么结果会变得很糟。

利用技术优化基础设施

在为灾难恢复分析环境并设计一个可行的基础设施时,很多工具和技术可以提供帮助。

用工具进行数据恢复
各种软件工具可以帮助您了解应用、存储和网络使用以及演变趋势。明智地使用这些工具,不仅能帮助您进行先期环境分析,还有助于微调设计,以提供充足的容量和带宽。

Datalink 常常用 NetApp SANscreen®进行存储恢复。 SANscreen 有很多功能,其中一项是,就服务器上运行的应用之间的服务路径以及存储在存储系统上的数据提供信息。 SANscreen 不需要安装任何代理,因此您可以让它运转起来,并迅速获得结果。我们还用 Riverbed Cascade 和类似工具仔细检查网络使用、性能和状态。

量化地了解运行情况,有助于确定需要什么类型的灾难恢复解决方案,或可以支持哪些灾难恢复解决方案。

复制和/或压缩
提供一个足够大的网络管道来处理数据复制流量,其费用可能高得难以承受。用有或没有 LAN 压缩的主存储去复制,可以极大地减少带宽需求,从而有可能减小所需网络管道的宽度。例如,将 NetApp 去复制技术应用到虚拟服务器环境中,可以减少高达 90% 的带宽需求。在 SnapMirror 复制时,这显然可转化成巨大的带宽节省。通常,将去复制技术应用到存储卷上,视数据类型的不同而不同,可减少 25% 到 90% 的带宽需求.

合并和虚拟化
如果您还没有这么做,那么合并和虚拟化服务器、网络及存储系统可能对您实现灾难恢复的能力有很大影响。消除复杂性不仅降低数据中心的运营成本,还使您能够更容易地知道您有什么、东西在哪里,这对数据保护和灾难恢复战略是必不可少的。

最新的服务器虚拟化技术可能还提供一些集成式功能,以简化虚拟机和应用在第二个站点的重新启动。(最近的一篇有关 Tech OnTap 的文章讨论了VMware®站点恢复管理器和NetApp存储系统使用的问题.)

另一个新出现的趋势是,将网络合并到单个以太网架构上。这也可以降低成本,使网络管理更简单,并能够更容易地满足灾难恢复对网络带宽的需求。以太网上的光纤通道( FCoE )的出现,使得有可能 在一个统一的网络架构中纳入已有光纤通道存储系统.

以下部分讨论虚拟化存储的一些优势。

集成的数据保护可以简化日常工作

有些人是以设计灾难恢复解决方案谋生的,从他们的立场来看,能够将所有数据保护和灾难恢复功能集成到基本存储系统中,可能是至关重要的设计要素。集成式数据保护不是为每一个数据集采用不同的解决方案,而是将同样的、一致的方法应用到所有数据上。

NetApp 存储系统集成了全套数据保护功能,包括存储空间利用效率很高的 Snapshot 技术、用于磁盘备份的 SnapVault 、用于灾难恢复的 SnapMirror 和用于数据连续可用性的 MetroCluster 。(这些技术在另外两篇阐述集成式数据保护的文章中有更详细的描述,一篇专门探讨集成式数据保护,另一篇是一个有关 MetroCluster 的案例分析。)

正如我之前提到的那样,定义几个服务层、每一层有不同的数据保护和灾难恢复功能,这样做几乎总是有意义的。由于 NetApp 提供全面丰富的功能,因此无论何时,只要可能,我们都用 NetApp 解决方案进行设计,以满足这些需求。

如果您已经在其他存储系统上做了大量投资,而这些系统缺乏 NetApp 集成式数据保护功能,那么 NetApp V 系列使您能够继续使用原来的存储系统,同时获得NetApp功能的各种益处. 。 Datalink 在最近几个项目中使用了 V 系列,已经取得了极大的成功。(有关集成式数据保护的 MetroCluster 案例分析中也包括对V系列的介绍。)

最后,惟一能确保灾难恢复计划合适的方法是定期对其进行测试, NetApp FlexClone 技术使测试过程容易多了。您绝不需要其他解决方案那么多的额外存储容量,而且这个过程对生产活动的干扰少得多。

在一个典型的灾难恢复测试方案中,在测试开始之前,所有用于测试的数据都必须复制到另一套磁盘上。这意味着,马上需要两倍的存储空间,而且在开始测试之前,需要做耗费时间的复制工作。

使用 FlexClone ,您能以存储空间利用效率很高的方式对任何或所有灾难恢复卷进行复制,产生可写副本,只有在更改这些已复制卷时,才需要占用额外的存储空间。这些 FlexClone 卷使您能够在固定的时间点抓取灾难恢复数据的静态图,而不会干扰正在进行的更新,也不需要大量额外的存储容量。

利用 FlexClone ,您可以将灾难恢复测试所需的时间从 24 小时或更长缩短到几个小时,因为这个过程快速、可靠、高效,而且资源占用的密集度低得多。

最后,灾难恢复站点意味着在资源上的大量投资。利用 FlexClone ,您可以将这些资源用于完成其他任务,如开发、数据挖掘、质量保证(QA)等等,而不会对灾难恢复的就绪性有负面影响。

定期测试和更新灾难恢复计划

正如之前部分所建议的那样,对于为灾难发生做好准备来说,定期测试是至关重要的。我建议,至少每年测试一次灾难恢复计划,如果业务变化和 / 或存储量增长速度异常快,那么测试还要更经常一些。如果可能,要使用自动化工具跟踪存储容量、网络带宽等的变化趋势。

最后,应该每年对业务需求做一次回顾,并相应更新灾难恢复计划和功能。这不仅能使计划切实可行,而且在面对增长和变化时,能继续满足公司的总体需求。

图1:数据价值与所需保护级别

怎样开始?

如果您需要帮助,以开始灾难恢复规划或更新已有计划,那么很多现有资源可以提供帮助,而不必做无谓的重复工作。美国政府在其 ready.gov网站上提供核对清单和其他资源,是一个不错的起点。

如果您仍然感到胆怯,那么可以考虑从外部获得一些帮助。您的服务器、网络、存储和应用厂商也许有额外的资源(免费和收费)提供,诸如 Datalink 这样的服务型公司也可提供帮助。额外多花几美元,在保护业务和让自己心里踏实方面,能有很大的回报。

想了解有关灾难恢复规划的各种观点?

请到 NetApp 社区在线提问、交换和分享您的看法。

Joshua Konkle

James Mason
国内实践主管兼存储架构师
数据连续性主管
Datalink 公司

James Mason 在 IT 行业工作了 25 年,最近 5 年在 Datalink 工作,近 10 年来几乎全力关注灾难恢复问题。他最近的业绩包括:设计了 Datalink 历史上最大型的 SAN 解决方案。James Mason 曾在 IBM 和 Convex 公司工作过。

Explore