Exchange Server 2010 中的高可用性功能 

 

• 深入探讨数据库可用性分组

邮箱数据库和它们包含的数据对于任何 Exchange 组织都十分重要。为了确保邮箱数据库的高可用性，Exchange 2007 提供了各种复制和群集选项，包括本地连续复制、单一副本群集和群集邮箱服务器。虽然这些功能相对早期功能有所改进，但它们仍面临许多实现难题。对于初学者，实现高可用性的每种方法都是以不同方式管理的。通过单一复制群集，群集中的所有邮箱服务器都使用共享存储。实现群集意味着 Exchange 管理员必须配置 Windows 故障转移群集，而这种群集相当复杂，管理员可能需要用大量时间才能取得较长的正常运行时间。在连续复制中，Exchange 2007 使用内置异步复制来创建数据的副本，然后使用事务日志传送和重播来维护这些副本。虽然您在非群集环境中使用本地连续复制来创建本地副本，但在群集环境中要使用群集连续复制或备用连续复制，并且管理每种连续复制的方式有所不同。

Exchange Server 2010 拥有全然不同的实现高可用性的方法，它将高可用性集成到其核心体系结构中，从而产生一种提供服务可用性、数据可用性和自动恢复的端到端解决方案。其结果是，单一的关键高可用性解决方案取代了以前所使用的很多不同解决方案。此解决方案就是数据库可用性分组 (DAG)。

DAG 在数据库级（而不是在服务器级）提供自动故障转移和恢复，在您部署包含多个邮箱数据库副本的多个邮箱服务器时无需使用群集。由于这些变化，构建高可用性邮箱服务器解决方案不再需要群集硬件或高级群集配置。DAG 自身提供了用于实现高可用性的基础组件，属于同一 DAG 的邮箱数据库的故障转移自动实现。可以将 DAG 扩展到多个 Active Directory 站点，并通过对邮箱服务器进行相关体系结构更改而使单一邮箱数据库能够在 Active Directory 站点之间移动。如此一来，一个 Active Directory 站点中的单一邮箱数据库便可以故障转移到其他 Active Directory 站点。

您需要记住的是，数据库副本仅适用于邮箱数据库。为了获得公用文件夹数据库的冗余性和高可用性，您将使用公用文件夹复制。与群集连续复制（同一群集中不能存在一个公用文件夹数据库的多个副本）不同的是，您可以在一个 DAG 中的服务器之间复制公用文件夹数据库。

在深入探讨 DAG 的细节之前，我们来看一下 Exchange 2010 中的高可用性选项在其他方面的变化。

Exchange Server 2010 中高可用性功能的简要介绍

在以前的版本中，Exchange 作为一个使用群集资源管理模型的群集应用程序运行。在此方法中，您通过先创建一个 Windows 故障转移群集、然后在群集模式中运行 Exchange 安装程序来实现邮箱服务器的高可用性。作为安装过程的一部分，将会注册 Exchange 群集资源 DLL (exres.dll)，从而允许创建群集邮箱服务器。相比之下，Exchange 2010 不作为群集应用程序运行，群集资源管理模型也不再用于获得高可用性。Exchange 群集资源 DLL 和它提供的所有群集资源都不再存在。Exchange 2010 使用其内部自有的高可用性模型。虽然 Windows 故障转移群集的某些组件仍在此模型中使用，但它们现在只由 Exchange 2010 进行管理。

非常有趣的是，很多基础复制技术都保留下来，只是经过改进现在以明显不同的方式工作。由于已从 Exchange 2010 移除存储组，因此将在数据库级别运行连续复制。Exchange 2010 将管理员定义的单一 TCP 端口用于数据传输，而不是将服务器消息块 (SMB) 用于日志传送和种子设定。它不是让被动副本从主动副本拉出一个已关闭的日志文件，而是让主动副本将日志文件推入被动副本，并使用加密来保证数据流的安全性，或将数据流压缩以减小复制数据的大小。虽然早期版本 Exchange 中数据库的主动副本仅可用于设定种子和重新设定种子，但在 Exchange Server 2010 中，邮箱数据库的主动和被动副本都可指定为用于设定种子和重新设定种子的源，从而允许您更轻松地将数据库副本添加到其他邮箱服务器。

另一个重大变化与复制数据的方式有关。在 Exchange 2007 中，Microsoft Exchange 复制服务会将日志重播到被动数据库副本中，并构建一个用于减少 I/O 读取操作的读/写操作缓存。但是，在数据库的被动副本激活之后，该数据库缓存会丢失，因为用于装载数据库的 Microsoft Exchange 信息存储服务并没有提供该缓存。这意味着该被动副本已激活并在没有就绪缓存的一个冷状态下提供。冷状态与数据库缓存在服务器重新启动或执行缓存的服务重新启动之后的状态相同。处于冷状态意味着服务器不具有缓存的读/写操作，这种情况通常会增加所需 I/O 读取操作的数量，直到缓存大小增加到足以减少服务器上的磁盘 I/O。在 Exchange 2010 中，Microsoft Exchange 信息存储服务将重播日志并处理装载操作，以确保在激活并提供被动副本时有可用的缓存。因此，在发生切换或故障转移之后，服务器更有可能使用缓存来减少 I/O 读取操作。

对于高可用性邮箱服务器，电子邮件一旦到达邮箱中就将变得安全；但是，对传输中的电子邮件加以保护又是另外一回事。如果在处理邮件时集线器传输服务器出现故障且无法恢复，邮件就可能丢失。作为防范数据丢失的安全措施，Exchange 2007 引入了传输转储程序功能，该功能可确保集线器传输服务器保持最近传送到收件人的一个邮件队列，这些收件人的邮箱通过本地连续复制或群集连续复制加以保护。邮件保留在传输转储程序中，直到达到管理员定义的时间限制或大小限制。发生故障转移时，群集邮箱服务器自动请求 Active Directory 站点中的每台集线器传输服务器从传输转储程序队列重新提交邮件。这种方法可防止邮件在群集进行故障转移所需的时间内丢失。虽然这种方法很有效，但它仅可用于连续复制环境中的邮件传送，无法解决邮件在集线器传输服务器和边缘传输服务器之间传输时可能发生的邮件丢失问题。

Exchange 2010 通过几种方式弥补了这些不足。传输转储程序现在可接收反馈，以确定已经传送和复制了哪些邮件。集线器传输服务器将保留发送到 DAG 中已复制邮箱数据库的邮件的副本。该副本保留在传输队列 (mail.que) 中，直到集线器传输服务器得到通知，获知表示邮件的事务日志已成功复制到邮箱数据库的所有副本并已由这些副本进行检查。然后，将从传输转储程序将这些日志截断，以确保传输转储程序队列仅用于保持尚未复制相应事务日志的那些邮件副本。另外，当一个 Active Directory 站点中的邮箱数据库故障转移到另一个 Active Directory 站点时，就会将传输转储程序重新传送请求发送到原始站点和新站点。

为了在传输邮件的整个过程中提供邮件冗余性，Exchange 2010 新增了卷影冗余功能。卷影冗余采用了与传输转储程序相似的方法，不同之处是它将推迟从传输数据库删除邮件的操作，直到传输服务器验证该邮件所有后续跃点均已完成传送时才执行。如果传输服务器无法验证下一跃点传送，则重新提交该邮件以传送到下一跃点。与在多台服务器上创建邮件的同一副本相比，这种方法占用的网络带宽更少。此时，所生成的唯一附加网络流量是在传输服务器之间交换丢弃状态消息所生成的流量。丢弃状态消息是由 Shadow Redundancy Manager 生成的，用于指示准备好从传输数据库丢弃电子邮件的时机。

卷影冗余是简单邮件传输协议 (SMTP) 服务的扩展，只要 SMTP 连接中的两台服务器都支持该功能，就可以使用该功能。当您的路由拓扑中有冗余消息路径时，卷影冗余可以消除对任何特定集线器状态或边缘传输服务器状态的依赖，从而使任何传输服务器都可处置。在这种情况下，如果传输服务器出现故障，或者您想将其脱机以进行维护，则您可随时这样做，方法是将其移除、替换或升级，而不必清空其队列或担心丢失邮件。

Shadow Redundancy Manager 使用一种检测信号方法来确定拥有卷影邮件队列的服务器的可用性。启动服务器时会发出一个 XQUERYDISCARD 消息，目标服务器返回丢弃通知作为响应。此通知交换就是检测信号。

如果一台服务器在检测信号超时间隔（默认为 300 秒）内无法与主服务器建立连接，则该服务器将计时器重置并重试最多三次（检测信号重试次数的默认值）。如果在达到最多重试次数之前，主服务器未响应，则该服务器确定主服务器已出现故障，承担起卷影邮件的所有权，并重新将它们提交。随后，邮件将传送到它们的相应目标位置。在某些情况下，例如在原始服务器重新与其原始数据库联机时，可能会发生重复的邮件传送。由于 Exchange 中具有重复邮件检测功能，因此 Exchange 邮箱用户不会看到重复的邮件。但是，非 Exchange 邮箱服务器上的收件人可能会收到重复的副本。

深入探讨 DAG

虽然到目前为止我所介绍的许多高可用性增强功能十分重要，但没有一个功能对 Exchange 2010 管理方式的影响超过数据库可用性分组。DAG 是 Exchange 2010 中的基础高可用性组件，它的规则十分简单。每个 DAG 都可具有最多 16 个邮箱服务器作为其成员。每个邮箱服务器只能作为一个 DAG 的成员，并且只能承载一个数据库副本。所承载的副本可以是主动副本或被动副本。主动副本与被动副本的不同之处在于：主动副本是用户一直使用和访问的副本而不是脱机副本。不能在同一台服务器上创建同一个数据库的两个副本。这样，DAG 中的任何服务器都可以承载 DAG 中任何其他服务器上的任何邮箱数据库的一个副本。虽然多个数据库可同时处于主动状态，但在任意时刻，任何特定数据库的仅一个副本可处于主动状态，该数据库的最多 15 个被动副本可位于 DAG 中的其他服务器上。

在 Exchange 组织中创建第一个 DAG 时，Exchange 将创建一个 Windows 故障转移群集，但是没有 Exchange 群集组，群集中也没有存储资源。DAG 仅使用 Windows 故障转移群集的群集检测信号、群集网络和群集数据库功能。群集检测信号用于检测故障。每个 DAG 需要至少一个网络用于复制通信，需要至少一个网络用于 MAPI 和其他通信。群集数据库将存储数据库状态更改和其他重要信息。当您将其他服务器添加到 DAG 中时，这些服务器将加入到基础群集中，该群集的仲裁模型将基于成员服务器的数目根据需要自动得到修改。

Active Manager 是 Exchange 2010 的一个组件，它提供了资源模型和故障转移管理功能。Active Manager 可在作为 DAG 成员的所有邮箱服务器上运行，充当特定数据库的主角色拥有者 (Primary Active Manager) 或备用辅助角色拥有者 (Standby Active Manager)。主角色拥有者将确定哪些数据库副本是主动副本以及要激活哪些副本。主角色拥有者接收拓扑更改通知并对服务器故障做出反应。主角色拥有者还拥有群集仲裁资源。如果充当主角色拥有者的服务器发生故障，则主角色会自动移动到 DAG 中的另一台服务器，该服务器将取得对群集仲裁资源的所有权。

辅助角色拥有者将检测复制的本地数据库以及本地信息存储库的故障，并将故障通知发送给主角色拥有者，要求主角色拥有者启动故障转移。辅助角色拥有者不会确定哪台服务器进行接管，也不会更新数据库的位置状态。主角色拥有者执行这些任务。当一个主动数据库出现故障时，Active Manager 使用一种最佳副本选择算法来选择要激活的数据库副本。此算法将根据数据库副本的数据库状态、内容索引状态、副本队列长度以及重播队列长度来确定要激活的最佳数据库副本。如果一个以上数据库副本满足选择条件，则将使用激活首选值，并激活和装载具有最低首选值的数据库。

在将服务器添加到 DAG 之后，可以将每台服务器上的主动数据库复制到 DAG 中的其他服务器，并且您可以配置其他 DAG 属性，如用于数据库复制的网络加密或网络压缩。在 DAG 内，事务日志将复制到拥有邮箱数据库副本的每台成员服务器上，并重播到该邮箱数据库的副本中。创建了多个数据库副本以后，您可以使用 Exchange 管理控制台和 Exchange 命令行管理程序来监视 DAG 的复制和运行状态。数据库故障转移可在发生中断故障时自动执行，或者您也可以手动启动切换。在切换过程中将卸除主动副本，然后装载 DAG 中另一台服务器上的被动副本并使该副本成为主动副本。

真正的简化

如前文所述，Exchange 2010 有很多可提高可用性的重要增强功能，包括将高可用性功能集成到核心中以及用于提高可用性的体系结构更改等。在所有新增功能和更改功能当中，我最喜欢的功能是 DAG。DAG 真正简化了群集的实现，可使您专注于最重要的事情（即数据）。希望本文对您有所帮助，同时推荐您查阅我的新书：《Exchange Server 2010 Administrator’s Pocket Consultant》、《Windows 7 Administrator’s Pocket Consultant》和《Windows Server 2008 Administrator’s Pocket Consultant, 2nd Edition》。

转载于:https://www.cnblogs.com/nniixl/archive/2010/09/18/1830214.html