实施灾难恢复 (DR) 解决方案需要做出明智的选择。NetApp Global Services (NGS) 提出了一种量化的解决方案设计方法。
作者简介
John Fullbright是NetApp的专业服务顾问，是 Exchange 领域的常驻专家。2006 年 4 月，John荣获微软最有价值专家 (MVP)奖。加盟 NetApp 之前，John 是微软全球解决方案支持中心的一名快速响应工程师。作为微软快速现场服务团队的成员，John 经常被委派去解决微软重要客户遇到的难题。
实施灾难恢复(DR)解决方案需要做出明智的选择。NetApp Global Services (NGS) 提出了一种量化的解决方案设计方法。借助这种方法，全球客户可以了解与不同方法有关的权衡点，从而做出明智的决策。
例如，美国一家大型保险公司最近发现，在24小时的时间间隔内完成磁带备份越来越难。于是，该公司聘请 NetApp Global Services帮助为Microsoft Exchange环境设计和实施灾难恢复解决方案，该公司的Exchange的环境如下所述：
一家主要子公司距离总部大约1000英里；
Exchange 装机量多达30000个(每个站点15000个)；
Exchange 数据传输速率高达14TB(每个站点的数据传输速率是 7TB)；
光纤通道SAN基础设施；
站点之间采用OC3连接。
本文着重介绍了影响项目的三个权衡点，以及该客户选择了哪种方式。
第一个权衡点
如果发生站点灾难，目标是高可用性，还是不间断的备份和恢复，抑或是远程恢复？
基本上可以通过两种方法实现在线数据保护：复制(镜像)和磁盘到磁盘备份。
通过复制，可以将数据集完全复制到另外一个存储系统上，该存储系统既可以在本地站点，也可以在其他站点。如果发生站点灾难时的目标是确保立即恢复高可用性或远程重新启动操作，这种方法是最佳解决方案。这种方法不能取代备份，这是因为如果某些内容从镜像的一方消失，那么在下一轮复制时，这些内容也会从镜像的另一方消失。距离是一项关键因素，虽然可以在远距离内实现异步复制，但是如果站点之间的距离超过80公里，那么在站点间同步镜像数据便会受到技术上的限制。
通过功能强大的辅助磁盘，磁盘到磁盘备份和存档方法既可作为容易出现故障的磁带系统的补充，也可以取而代之。数据通过网络备份到远程位置。一旦发生灾难，可以从此处恢复数据。与复制不同的是，主机不能直接连接到辅助存储设备。相反，有了对数据集进行反复更改的历史记录，您可以及时地从任意点恢复数据。
在这种情况下，公司IT团队决定使用综合方法。实施远程灾难恢复是重中之重。该公司拥有两个大型站点，相距 1000英里左右，具备相当出色的网络带宽连接能力。因此，可以毫不犹豫地决定使用NetApp镜像软件，以指定的时间间隔异步复制站点之间的Exchange日志文件和数据库。此外，IT团队选择使用NetApp SnapVault软件迁移到磁盘- 磁盘-磁带的环境，从而解决了现有的磁带备份问题。
第二个权衡点
如果无法实现数学方法计算的结果，能否增加网络带宽或者可以接受损失多少数据量？
为了调整DR基础设施的规模，必须确定发生更改的数据量。因此，每天必须对其进行复制或备份。确定更改量之后，下一步就是计算出发生灾难时可以负担得起的最大丢失数据量。如果将更改量除以复制时间间隔，可以估算每个时间间隔内必须传输的数据量。此时需要进行权衡。如果使用数学方法得出的结果对您不利，则必须增加网络带宽或考虑更长的恢复点目标(RPO)，这可能导致更多数据丢失。
考察完各个组织的要求之后，该团队建立了一个间隔为五分钟的RPO。鉴于周期很短，我们必须在计算日志更改量时考虑峰值。具体方法是，使用在五分钟的时间间隔内进程store.exe的每秒平均写入次数的perfmon采样来创建数据集。据该团队估计，每24小时更改量大约是 200GB。如果复制时间间隔为五分钟，则表示每隔五分钟就要复制 700MB 左右的数据(200GB/天÷288复制周期/天)。根据其他网络流量，峰值流量可能已经超过可用的OC3网络(155 Mbps 或大约19MB/秒)。
IT团队只接受五分钟的RPO目标也不想升级网络基础设施。NGS 发现，对于首先写入日志然后从日志写入数据库的任何事务处理应用程序，更改量由分散的两部分组成。新数据首先写入日志文件，然后写入数据库。因此，一半的更改量 (100GB) 将来自日志文件。
1.通过每五分钟只复制日志，该公司在将宽带需求减半的同时仍实现五分钟的 RPO 目标。
Exchange 数据库每隔 4 小时便复制一次。峰值流量不会超过13MB。这样，不仅为日志文件提供了高级数据保护，而且将负载更加均匀地平摊到全天，从而有助于降低对网络和主存储设备的影响。
这种方法可能存在着一个缺点，即恢复时间与重放这些日志有关。测试完该过程之后，NGS 确定重放日志只使恢复时间增加五分钟左右。随着时间不断扩大，带宽使用范围和削减整体带宽需求所具有的优点远远胜过这种方法带来的影响。
2.随时控制I/O速率，确保决不会超过网络容量。
通过两种 NetApp 产品，NGS帮助客户进一步减小复制和备份流量的影响，可以对SnapVault和SnapMirror(r) 进行调节，使它们不超过指定的I/O速率。并非所有的DR 应用程序都支持这种功能。但是，如有可能最好设置阈值，以便活动中出现的异常峰值不会导致意外的结果。
第三个权衡点
可以承受多长的停机时间？
下一步是确定发生灾难时恢复运行所需的时间。这是恢复时间目标(RTO)。RPO比较简单，但RTO可能比较复杂，这是因为必须要考虑恢复运行所要采取的所有步骤。
为了建立实际的RTO，NGS与该公司的IT团队通力协作，记录与Exchange恢复联机有关的所有内容，包括断开复制链接，使复制LUN可读/写；将所有LUN连接到同级站点上的主机；启动Exchange服务；重放日志；评估完所有必要步骤(包括进行必要的基础设施更改、启动 Exchange和重放数小时的日志文件)之后，客户建立了为期4小时的RTO，规定Exchange数据库的复制时间间隔不超过4个小时。
最终结果是构建多层存储体系结构。通过与NGS的通力合作，该IT团队在满足原来预算要求的同时，得以构建一个提供能够多级保护并从路由故障和站点灾难恢复的基础结构：
为了实现快速恢复，主存储设备上最多保存每卷的30个Snapshot副本(相当于五天时间)和48个日志副本(相当于4个小时)。使用SnapVault的磁盘到磁盘备份承担了主服务器和存储设备上中断的磁带备份工作。此后，数据可以备份到磁带，而不会影响主存储设备或Exchange的运行。使用SnapMirror的远程复制可以针对站点灾难提供保护。在NetApp存储设备上保存250多个Snapshot副本，不会影响性能。对于基Copy-on-Write(根据写入的数据进行备份)的解决方案，情况并不完全是这样。
