一项好的邮件服务器灾难恢复计划

  一项好的邮件服务器灾难恢复计划要从多方面进行周密考虑，除了进行科学的系统设计和验证工作，还要定期进行故障切换测试。

　　每年，微软Exchange服务器的各类停机故障给企业带来了

　　高达数百万美元的损失。因此，一些精通技术的IT专业机构正在努力减少甚至消除计划中和无计划停机造成的影响，而它们的方法就是实施高可用性系统和灾难恢复系统。

　　然而，要想建设一个分散在多个地理地点的Exchange集群，其建设过程绝对不是一件简单的工作。它要求对服务器群进行适当的规划、测试、部署和验证。如果用户能够理解以下讨论中提出的问题并且在规划阶段认真考虑这些建议，那么用户就朝着系统的成功部署迈出了第一步，也是最为关键的一步。也只有通过这种方式，用户所部署的系统才能以最佳的方式实现用户的商业目标。

　　这一过程的起点是用户在实施Exchange灾难恢复系统的最初决策，而且它将是一个持续的过程，只要系统处于生产环境中，该过程就会继续下去。

　　规划与设计

　　在规划阶段，用户必须回答以下这些关键问题。

　　● 系统的恢复时间目标是什么？

　　● 根据变化的速率和预计的增长率，主站点与灾难恢复站点之间需要有多大的带宽？

　　● 除了Exchange服务器和进程本身外，系统的哪些部分是必须受到监视和恢复的？在恢复后的一定时间内是否可以提供一个可接受的最小功能集？如果有，那么它的子集是什么？

　　● 是否允许自动故障切换，或者管理员接到的提示是否是恢复行动的第一步？

　　● 在故障切换过程中，哪些电子邮件是必须得到保护的？它们使用的访问方法是什么？在恢复期间它们将如何被移植到灾难恢复站点？

　　如果用户针对这些要求准备好了相应的文档，那么用户就可以开始设计工作了。用户的第一个决策就是选择适合的灾难恢复站点。虽然有些机构决定使用远程企业办公室作为备份地点，但也有很多企业选择同一地点的主机服务中心，因为这些地点可提供完全的电源冗余和网络连接能力。如果使用远程办公室，用户必须明白一点: 远程站点与主站点之间需要进行大量的邮件传输，以及将日志文件使用现有网络进行远程镜像。远程办公地点可能无力承担由此而产生的双倍流量负荷。因此，用户还必须对带宽要求和可用性进行分析。为了实现成功的部署，用户必须为站点之间设计足够强大的连接，而且这种连接既要能够提供足够的带宽，而且要将延迟的问题考虑在内。这些都是成功部署的关键条件。

　　在这一阶段，用户还应当了解服务器、存储容量和配置、主站点和灾难恢复站点间的网络路由，以及可能用到的客户重定向方法，并且以文档的形式将其完整地记录下来。

　　无论是最初的设计阶段，还是最后的验证阶段，整个过程中都必须有具备以下各领域专业能力的人员参与进来：Windows服务器管理员、Exchange服务器管理员、集群软件管理员以及网络路由和故障查找人员。

　　在构建端到端系统的过程中，具备这些技能的人员是至关重要的。他们应当参与最初的设计开发和测试环境的搭建工作，而且应当亲自参与部署和验证阶段。

　　测试很关键

　　要想正确地模拟实际运行的Exchange环境，就必须在测试实验室中模拟跨站点网络连接、用户负载以及备份工作等邻近程序和其他特定环境因素，因此测试阶段通常是非常困难的。用户在测试实验室中模拟环境与实际运行环境越接近，那么在部署过程中遇到的问题就越少。

　　通过使用Exchange Server Load Simulator（负载模拟），企业便可以测试运行Exchange的服务器会对电子邮件负载做出何种的响应。如果在执行故障切换时正在运行活动的负载模拟会话，那么就可以有效地测试复制数据的连贯性，以及故障切换软件在面对类似生产环境负载时的表现情况。我们还发现，有些基于硬件的广域网模拟器可以针对不同的速度和延迟进行编程。无论是作为测试工具还是调试工具，这类模拟器的价值都是不可估量的。

　　在测试过程中，用户需要回答如下这些问题。

　　● 故障切换软件的探测和恢复性能是否如预期的一样？

　　● 数据复制软件在速度和数据连贯性方面的表现是否如预期一样？

　　● 监视或数据复制软件的存在是否对最终用户产生了明显的性能影响？

　　● 各种客户端是否都能以无缝的方式移植到灾难恢复服务器上运行的Exchange上？

　　水到渠成来部署

　　如果用户组建的是一个专家小组，并且成功地在测试阶段中模拟了实际运行环境，那么部署工作就会变得毫无悬念。当然，用户应当预先安排足够的时间，用以实现最初的跨站点同步镜像，以及后续的转至灾难恢复站点的故障切换和切换返回生产性服务器的完整测试过程。这些测试都应当验证客户重定向情况是否与计划相符，并且确认全功能Exchange环境所需要的所有服务都已经全部恢复。

　　在最初的部署完成后，我们建议用户在每次更改Exchange环境（如安装服务包、引入新的服务等）后都进行故障切换测试。如果因为没有考虑到管理方面的变化而导致主站点发生灾难时，恢复系统无法取而代之并提供相同的Exchange服务，那将是最可怕的情况。很多管理员在更改了Exchange环境之后都没有意识到这种作法对灾难恢复系统产生的影响，而我们了解到的多数错误情况都属于此类。即使是在静态环境中，企业也应当每季度至少运行一次测试，确保自己拥有适当的监视和恢复能力。

　　虽然部署Exchange灾难恢复系统是一项复杂的任务，但是，本文中提出的概念能够帮助用户实现成功的部署，满足用户在保护关键业务及协作环境的各项要求。

　　编看编想

　　离不开的邮件

　　随着E-mail在我们生活中扮演着越来越重要的角色，用户邮件服务器的保障工作也显得越发关键。有些业务繁忙的IT专业人士一天收到的邮件有数百封之多，因此在许多用户的IT环境中，邮件服务器需要确保极高的可用性。

　　笔者认识一位大型分销商的系统管理员，由于出现了一次非常严重的系统故障而导致邮件服务宕机，期间公司邮箱无法使用，之后花了两天时间才将整个系统恢复。故障发生的前一天，所有的公司邮件全部丢失，而且比较棘手的问题是，每个用户都不清楚究竟丢失了哪些邮件。由于所有的业务情况都需要邮件确认，因此，那次邮件服务器的故障给公司带来了巨大的损失。

　　上文提到的这些建议对于用户提高Exchange服务器的可用性有很大帮助。当然许多用户使用的可能不是Exchange，但是这些方法对他们的邮件服务器同样具有借鉴意义，其中一些策略性方面的建议值得用户在实践中付诸实施。