对于Seth Copeland来说，担任位于Kansas Citv，Missourl的Tanner＆Ha Jey Resorts的IT主管意味着投身于研发灾难恢复计划，支持公司的160个用户。Seth说“当我在2005年10月刚刚担任这个职位时，实际上根本没有计划，我们只是简单地使用磁带备份。”由于实施这一计划的复杂性，Tanner＆Haley在2006年7月申请Chapter 11破产(并且正处于被ultimate Resort接受的过程)——正当新研发的灾难恢复计划产生效果时。利用节省下来的成本和空间，Seth决定实施虚拟化灾难恢复方案。以下是我和Seth关于如何使用虚拟化技术提供预算合理的两层方案实现高可用性和恢复的交谈。


是什么触发了公司灾难恢复计划的研发?


对于我来说，触发事件是当龙卷风在离办公室不远的地方登陆o Kansas clty的大多数灾难都是本地的，像龙卷风那样的。我认为也许什么地方有问题，但是我不知道。Missouri River可能发洪水，但是我们离河很远。假如有人对Kansas City发动核打击，我们可能会全军覆没，但是我并不太担心。

解释一下您现在的灾难恢复方案。该计划是按照灾难的严重性规定步骤的吗?


我们的计划是使用vMware产品和NSI Software的Double—Take for Virtual systems软件。在数据中央这里有一台服务器运行VMware ESX Server，我把任何单个服务器复制到他本地。ESx Server机器作为本地的高可用性服务器，以防丢失单个服务器。假如邮件服务器死机或数据库服务器发生故障，这台本地高可用性服务器就能够代替他们。此外，这台本地高可用性服务器中的任何那些虚拟服务器随后都经由DoubIe—Take软件复制到我们位于Kansas的OverIana Park的4个服务器，在那里我们安置4到5台服务器，每台都使用VMwa re ESX Server。我们主数据中央的虚拟化服务器负责解决单个服务器故障。OverIand Park负责站点故障。我主要考虑两点 进行系统备份能有多快，连同虚拟站点是否能够应付任何进入的连接。他能够应付负载吗，答案是能够。我们通常占有恢复时间目标(recovery time。objective。RTO)大约两个小时，失去至多最后10分钟的数据。那就是我根据业务需要所做的配置。
坏掉一块磁盘、邮件系统、保留系统——这还只是小灾难。计划只是通过将故障转移到本地服务器即可化解这些小灾难。
计划还考虑了这样的情况办公楼被摧毁，员工甚至不能来上班，不得不在家工作。在这种情况下，我们会需要尽快恢复呼叫中央，于是我们会让员工把办公电话带回家，把我们的电话线转接到Connecticut的公司总部，连接到Mitei Networks VolP电话系统，在家庭之外运行呼叫中央。


为什么您的解决方案以虚拟化为基础?


主要原因是节省成本。我们申请了Chapter 11后，每花一分钱都要算计。虚拟化软件已发展成熟，硬件也足够强大．我们根本不用担心在虚拟机上运行恢复服务器。我的意思是假如必须从头建立数据中央，我一定会更多地采用虚拟化的解决方案。这也就是我们选择虚拟化的真正原因——节省硬件成本和灾难恢复站点所占用的空间。

除了恢复呼叫中央服务，下一步您要恢复哪些部分呢?


我已给了每个管理者电话计划——那就是，在我们的系统发生故障时如何和他们沟通，因为BlackBerrjes和邮件在线需要一点时间。
我还让管理者确定以下几项的优先顺序：谁是他们最重要的人——谁的服务应该恢复，按什么顺序——他们最重要的系统是什么?假如在灾难的第一天，我能恢复10个用户，那么最重要的10个人是谁？

迄今为止解决方案运行得如何?您有机会将他真正用于一次灾难恢复吗?


解决方案还没派上用场。我们每几个月测试他一次。在测试中，主要考虑两点：进行系统备份能有多快?连同Over land Park的虚拟站点能否应付我们的任何用户都转到那儿所带来的负载。这两点都能很好地满足。我们还没有机会实际应用这个方案。我希望永远无需用到他。