数据中心切换
适用于: Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题: 2012-02-14
通过将 Microsoft Exchange Server 2010 Service Pack 1 (SP1) 中的本机站点恢复功能和正确的规划结合使用,可以迅速激活第二个数据中心,从而服务于发生故障的数据中心的客户端。 数据中心或站点故障的管理方式不同于可能引起服务器或数据库故障转移的故障类型的管理方式。 在高可用性配置中,自动恢复将由系统启动,故障通常会使邮件系统处于全功能状态。 相比之下,数据中心故障被认为是灾难恢复事件,因此,必须手动执行和完成恢复才可还原客户端服务并结束中断。 您执行的过程称为“数据中心切换”。 与很多灾难恢复方案一样,数据中心切换的前期规划和准备工作可简化恢复过程并缩短中断的持续时间。
在决定激活第二个数据中心之后,需要完成以下四个基本步骤才能执行数据中心切换:
**终止部分运行的数据中心:**如果有任何服务仍在运行,此步骤将终止主数据中心中的邮箱和统一消息服务。 这对邮箱服务器角色尤其重要,因为此服务器角色使用主动/被动高可用性模型。 如果部分故障的数据中心中的服务未停止,则部分故障的数据中心中的问题可能会在切换回主数据中心期间对服务产生负面影响。
重要说明: 如果由于主数据中心故障而导致网络或 Active Directory 基础结构可靠性存在风险,则我们建议关闭所有邮件服务,直到将这些依存关系还原到运行正常的服务。 **验证并确认第二个数据中心的先决条件:**此步骤可以与步骤 1 同时执行,因为验证第二个数据中心的基础结构依存关系的运行状况与第一个数据中心服务基本无关。 每个组织通常需要其自己的方法来执行此步骤。 例如,您可以决定是通过查看由基础结构监视应用程序收集和筛选的运行状况信息,还是通过使用组织基础结构独有的工具来完成此步骤。 这是关键步骤,因为在第二个数据中心的基础结构不正常和不稳定时进行激活操作可能会产生不良结果。
**激活邮箱服务器:**此步骤启动激活第二个数据中心的过程。 此步骤可以与步骤 4 同时执行,因为 Microsoft Exchange 服务可以处理数据库中断和恢复。 激活邮箱服务器涉及一个过程,即将主数据中心的故障服务器标记为不可用,然后对第二个数据中心中的服务器进行激活。 邮箱服务器的激活过程取决于 DAG 是否处于数据库激活协调 (DAC) 模式。 有关数据库激活协调模式的详细信息,请参阅了解数据中心激活协调模式。
如果 DAG 处于 DAC 模式,您可以使用 Exchange 站点恢复 cmdlet 来终止部分出现故障的数据中心(如果需要)并激活邮箱服务器。 例如,在 DAC 模式中,可以使用 Stop-DatabaseAvailabilityGroup cmdlet 执行此步骤。 在某些情况下,必须两次(在每个数据中心中各标记一次)将服务器标记为不可用。 然后,通过将 DAG 成员减少到仍可进行正常运行的状态,在第二个数据中心中运行 Restore-DatabaseAvailabilityGroup cmdlet 以还原数据库可用性组 (DAG) 的剩余成员,从而重建仲裁。 如果 DAG 没有处于 DAC 模式,必须使用 Windows 故障转移群集工具来激活邮箱服务器。 完成上述两过程中的任一过程后,以前在第二个数据中心中处于被动状态的数据库副本可以变为活动状态并被装入。 此时,邮箱服务器的恢复完成。
**激活其他服务器角色:**这涉及使用 URL 映射信息和域名系统 (DNS) 更改方法来执行所有所需的 DNS 更新。 映射信息描述要执行的 DNS 更改。 完成更新所需的时间量取决于所用的方法和 DNS 记录上的生存期 (TTL) 设置(以及部署的基础结构是否接受此 TTL)。
在步骤 3 和 4 完成后的某个时间,用户应开始有权访问邮箱服务。 本主题后面将对步骤 3 和 4 进行详细描述。
若要了解与高可用性和站点弹性相关的管理任务, 请参阅管理高可用性和站点恢复。
目录
终止部分故障的数据中心
激活邮箱服务器
激活其他服务器角色
将服务还原到主数据中心
重新建立站点弹性
终止部分故障的数据中心
如果发生故障的数据中心中仍有 DAG 成员在运行,则应将其终止。
当 DAG 处于 DAC 模式时,可以终止主数据中心中任何仍存在的 DAG 成员的特定操作如下:
主数据中心中的 DAG 成员在主数据中心中必须标记为已停止。 “已停止”是活动管理器的一种状态,可阻止数据库装入。通过使用 Stop-DatabaseAvailabilityGroup cmdlet,可将故障数据中心中的每个服务器上的活动管理器置于此状态。 只需单个命令,即可通过此 cmdlet 的 ActiveDirectorySite 参数将主数据中心中的所有服务器全标记为已停止。 可能无法执行此步骤,具体取决于故障。 如果数据中心的状态允许,则应执行此步骤。 应当对主数据中心中的所有服务器运行 Stop-DatabaseAvailabilityGroup cmdlet。 如果邮箱服务器不可用,但 Active Directory 在主数据中心中正常运行,则必须对主数据中心中处于此状态的所有服务器运行具有 ConfigurationOnly 参数的 Stop-DatabaseAvailabilityGroup 命令,不然就必须关闭邮箱服务器。 无法关闭发生故障的数据中心中的邮箱服务器,或无法成功对服务器执行 Stop-DatabaseAvailabilityGroup 命令,均可能会发生跨两个数据中心的网络分区症状。 可能需要通过电源管理设备分别关闭计算机以满足此要求。
此时,必须对第二个数据中心进行更新,以表示哪些主数据中心服务器已停止。 通过使用相同 ActiveDirectorySite 参数来运行具有 ConfigurationOnly 参数的相同 Stop-DatabaseAvailabilityGroup 命令,并在发生故障的主数据中心中指定 Active Directory 站点的名称,可完成此操作。 此步骤的目的在于通知第二个数据中心中的服务器还原服务时,哪些邮箱服务器可用。
如果 DAG 没有处于 DAC 模式,可以终止主数据中心中任何仍存在的 DAG 成员的特定操作如下:
主数据中心中的 DAG 成员必须通过对每个成员运行下列命令来强制从 DAG 基础群集退出:
net stop clussvc cluster <DAGName> node <DAGMemberName> /forcecleanup
第二个数据中心中的 DAG 成员必须立即重新启动,然后用于完成从第二个数据中心的退出过程。 通过对每个成员运行以下命令停止第二个数据中心中每个 DAG 成员上的群集服务:
net stop clussvc
对于第二个数据中心中的 DAG 成员,通过运行以下命令强制仲裁启动群集服务:
net start clussvc /forcequorum
打开故障转移群集管理工具,并连接到 DAG 基础群集。 展开群集,然后展开“节点”。 右键单击主数据中心中的每个节点,选择“更多操作”,然后选择“退出”。 在退出主数据中心中的 DAG 成员后,请关闭故障转移群集管理工具。
如果正在使用发生故障的数据中心中的任何统一消息服务器,则必须禁用这些服务器,以阻止呼叫路由到发生故障的数据中心。 通过使用 Disable-UMServer cmdlet(例如 Disable-UMServer UM01
),可以禁用统一消息服务器。 另外,如果使用 IP 电话 (VoIP) 网关,则还可以从 VoIP 网关删除统一消息服务器条目;或者,如果您的 VoIP 网关配置为使用 DNS 路由呼叫,则可以将发生故障的服务器的 DNS 记录更改为指向第二个数据中心中统一消息服务器的 IP 地址。
终止部分故障的数据中心
激活邮箱服务器
在数据中心切换过程中激活邮箱服务器所需的步骤还取决于 DAG 是否处于 DAC 模式。 在激活第二个数据中心中的 DAG 成员之前,建议您验证第二个数据中心中的基础结构服务是否可以进行消息服务激活。
当 DAG 处于 DAC 模式时,完成第二个数据中心中的邮箱服务器的激活过程所需步骤如下:
必须停止第二个数据中心中的每个 DAG 成员上的群集服务。 可以使用 Stop-Service cmdlet 来停止此服务(例如
Stop-Service ClusSvc
),或者在提升的命令提示符下使用net stop clussvc
。然后,通过使用 Restore-DatabaseAvailabilityGroup cmdlet 激活备用数据中心中的邮箱服务器。 备用数据中心的 Active Directory 站点会传递给 Restore-DatabaseAvailabilityGroup cmdlet 以标识用于还原服务的服务器和将 DAG 配置为使用备用见证服务器。 如果以前没有配置备用见证服务器,则可以使用 Restore-DatabaseAvailabilityGroup cmdlet 的 AlternateWitnessServer 和 AlternateWitnessDirectory 参数配置该服务器。 如果此命令成功,则仲裁条件将缩小为备用数据中心中的服务器。 如果此数据中心中的服务器数为偶数,则 DAG 将切换为使用 DAG 对象上的设置标识的备用见证服务器。
此时,可激活数据库。 根据组织使用的特定配置,此操作可能不是自动的。 如果备用数据中心中的服务器拥有激活阻止设置,则系统将不会从主数据中心自动故障转移到任何数据库的备用数据中心。 如果备用数据中心中所有数据库副本都没有故障转移限制,则系统将激活第二个数据中心中的副本(假定这些副本处于正常状态)。 如果数据库配置了需要显式手动操作的激活阻止设置,则有以下两种选择可用于操作:
清除阻止激活的设置。 此操作将使系统恢复其默认行为,即激活所有可用副本。
保持此设置不变,使用 Move-ActiveMailboxDatabase cmdlet 完成第二个数据中心中的数据库的激活。 若要在设置了阻止激活时,使用 Move-ActiveMailboxDatabase cmdlet 完成此步骤,您必须显式标识移动的目标。
最后一步是查看来自任务的所有错误和警告消息。 应对所有明示的警告遵照执行并进行更正。 仅当这些命令无法达到基本设计目标时,其任务设计模型才会失败。 例如,如果 Restore-DatabaseAvailabilityGroup cmdlet 无法在不导致仲裁中断的情况下,缩小 DAG 的仲裁以允许第二个数据中心中的服务器重新启动来提供服务,则此 cmdlet 将失败。 但是,每个任务的输出还将用于标识需要管理员跟进的问题。 强烈建议您保存所有任务输出,并查看这些输出以备后续操作。
如果 DAG 没有处于 DAC 模式,完成第二个数据中心中的邮箱服务器的激活过程所需步骤如下:
必须根据第二个数据中心中的 DAG 成员数对仲载进行修改。
如果 DAG 成员为奇数,请通过运行以下命令将 DAG 仲裁模型由“多数节点和文件共享仲裁”更改为“多数节点仲裁”:
cluster <DAGName> /quorum /nodemajority
如果 DAG 成员为偶数,通过在 Exchange 命令行管理程序中运行以下命令来重新配置见证服务器和目录:
Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>
通过运行以下命令对第二个数据中心中任何剩余的 DAG 成员启用群集服务:
net start clussvc
通过对每个 DAG 成员运行以下命令来执行服务器切换以激活 DAG 中的邮箱数据库:
Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
通过运行以下命令在第二个站点中的每个 DAG 成员上装入邮箱数据库:
Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database
因为公用文件夹数据库不使用连续复制,而是依赖公用文件夹复制来实现高可用性,因此在数据中心切换后重新连接到公用文件夹数据库的 Outlook 客户端的行为取决于站点弹性公用文件夹体系结构以及公用文件夹数据库的运行状况和货币。 要为 Outlook 客户端重新建立公用文件夹连接,只需更改邮箱数据库的默认公用文件夹,使其指向第二个站点中的某个公用文件夹数据库。有关如何更改邮箱数据库的默认公用文件夹数据库的详细步骤,请参阅为邮箱数据库更改默认公用文件夹数据库。
终止部分故障的数据中心
激活其他服务器角色
激活非邮箱服务器角色所需的步骤取决于特定服务器及其配置。 以下部分描述了每个服务器角色的激活过程。
激活客户端访问服务器
客户端连接到服务终结点(例如,Outlook Web App、自动发现、Exchange ActiveSync、Outlook Anywhere、POP3、IMAP4 以及 RPC 客户端访问阵列)以访问 Exchange 服务和数据。 因此,激活客户端访问服务器涉及到将这些服务终结点的 DNS 记录的映射从主数据中心中的 IP 地址更改为配置为新服务终结点的第二个数据中心中的 IP 地址。 需要修改的 DNS 记录不一定位于同一 DNS 区域中,具体取决于 DNS 配置。
然后,客户端将通过以下两种方式之一自动连接到新服务终结点:
客户端将继续尝试连接,并且会在原始 DNS 条目的 TTL 过期以及客户端的 DNS 缓存条目过期之后进行自动连接。 用户还可以在命令提示符下运行
ipconfig /flushdns
命令来手动清除其 DNS 缓存。启动或重新启动的客户端将在启动时执行 DNS 查找,并会为服务终结点获取新 IP 地址,此 IP 地址将是第二个数据中心中的客户端访问服务器或数组。
假定已完成所有相应的配置更改以定义并配置第二个数据中心中的服务,使它们充当主数据中心中的服务,且已建立的 DNS 配置正确,则不需要进一步的更改来激活客户端访问服务器。
激活集线器传输服务器
将邮件提交到集线器传输服务器的客户端以及其他服务器通常使用 DNS 来标识这些服务器。 激活集线器传输服务器需要将 DNS 记录更改为指向第二个数据中心中集线器传输服务器的 IP 地址。 然后,客户端和发送服务器将通过以下两种方式之一自动连接到第二个数据中心中的集线器传输服务器:
客户端将继续尝试连接,并且会在原始 DNS 条目的 TTL 过期以及客户端的 DNS 缓存条目过期之后进行自动连接。 用户还可以在命令提示符下运行
ipconfig /flushdns
命令来手动清除其 DNS 缓存。启动或重新启动的客户端将在启动时执行 DNS 查找,并会为 SMTP 终结点获取新 IP 地址,此 IP 地址将是第二个数据中心中的集线器传输服务器。
假定已完成所有相应的配置更改以定义并配置第二个数据中心中的服务,使它们充当主数据中心中的服务,且已建立的 DNS 配置正确,则不需要进一步的更改来激活集线器访问服务器。
激活统一消息服务器
统一消息 (UM) 服务器连接到组织的 PBX 系统和电话线。 PBX 系统和统一消息服务器之间的逻辑连接是由 IP 网关提供的。 IP 网关具有高可用性功能,可在检测到故障时,在多个统一消息服务器之间进行切换。
如果第二个数据中心中存在因为专用于站点恢复解决方案而处于禁用状态的统一消息服务器,则可通过使用 Enable-UMServer cmdlet(例如 Enable-UMServer UM04
)来启用它们。
假定通过使用 DNS 服务器已将 IP 网关与统一消息服务器关联,则激活统一消息服务器需要将 DNS 记录更改为指向将为第二个数据中心中统一消息服务器配置的新 IP 地址。 在 TTL 和 DNS 缓存条目到期后,客户端和 IP 网关将无法连接到 Microsoft Exchange 统一消息服务。 假定已完成所有相应的配置更改以定义并配置第二个数据中心中的服务,使它们充当主数据中心中的服务,且已建立的 DNS 配置正确,则不需要进一步的更改来激活统一消息服务器。
如果正在使用的 IP 网关不支持使用 DNS 名称来解析统一消息服务器,则需要执行其他配置步骤来手动将 IP 网关指向第二个数据中心中统一消息服务器的 IP 地址。
激活边缘传输服务器
激活边缘传输服务器角色的步骤有所不同,具体取决于特定配置。 两个数据中心中的边缘传输服务器可配置为主动/被动或主动/主动配置。 在主动/被动配置下,第二个数据中心中的边缘传输服务器在第二个数据中心被激活之前将一直处于空闲状态。 在主动/主动配置下,两个数据中心中的边缘传输服务器始终在传递邮件。
在主动/主动配置下,无需执行任何步骤激活第二个数据中心的边缘传输服务器,因为这些服务器已在运行。 在主动/被动配置下,从主数据中心切换到备用数据中心时,需要更新每个 SMTP 域的 DNS MX 资源记录。 尽管主动/主动配置提供了一种简单的数据中心切换解决方案,但是它的缺点也是显而易见的,即需要小心监视负载以确保在数据中心切换之后,第二个数据中心中的边缘传输服务器不至于由于主数据中心中的边缘传输服务器不可用,而不能提供足够容量来支持通过它们的增加了的负载流量。
即使是主动/主动配置,可能也需要在数据中心切换期间更新边缘传输服务器的 MX 资源记录。 允许发生故障的数据中心的 MX 资源记录继续指向该数据中心,意味着可在数据中心开始恢复时启动到其边缘传输服务器的连接尝试。 当边缘传输服务处于不稳定状态(例如,正在还原数据中心中的依赖性服务)时,可能会出现这种情况。
假定 DNS 记录受组织控制,则激活边缘传输服务器需要为每个由服务器托管的 SMTP 域更新 MX 资源记录。
注意: |
---|
如果组织使用的 MX 资源记录不由受组织控制的 DNS 服务器托管,则可以考虑参考 MX 资源记录中的 CNAME 记录,并使用受组织控制的且之后可进行更新的 CNAME 记录。 |
DNS 更新启用传入流量,而传出流量则通过激活边缘传输服务器正常运行的站点中的邮箱数据库来进行处理:
使用更新的名称解析信息来启动传入 SMTP 连接时,SMTP 客户端将连接到第二个数据中心中的边缘传输服务器。 边缘传输服务器会正确路由流量,无需进一步的更改。
传出 SMTP 连接启动时,它们会尝试本地可用的边缘传输服务器,这些邮件会根据接收服务器的状态来确定是排队还是立即发送。
终止部分故障的数据中心
将服务还原到主数据中心
通常,数据中心故障不是临时性的,就是永久性的。 对于永久性故障,如导致主数据中心永久损坏的事件,主数据中心是无法激活的。 但是,对于临时故障(例如,超时断电或大范围但可修复的损坏),主数据中心最终可还原为完整服务。
将服务还原到先前发生故障的数据中心的过程称为“故障回复”(switchback)。 用于执行数据中心故障回复的步骤与用于执行数据中心切换的步骤类似。 一个重要区别是数据中心故障回复按计划执行,中断时间通常较短。
有一点非常重要,即在 Exchange 的基础结构依存关系被重新激活,正常运行并已处于稳定状态,且进行验证之后,才会执行故障回复。 如果这些依存关系不可用或没有正常运行,则故障回复过程将很可能导致比所需时间更长的中断,而且可能整个过程都将失败。
邮箱服务器角色故障回复
邮箱服务器角色应当是故障回复到主数据中心的第一个角色。 下列步骤将详细说明邮箱服务器角色故障回复过程:
在数据中心切换过程中,主数据中心中的邮箱服务器会进入停止状态。 当环境(如主数据中心、Exchange 依存关系和广域网 (WAN) 连接)恢复之后,第一步是将已还原的主数据中心中的邮箱服务器置于已启动状态,并将其并入到 DAG 中。 完成此操作的方式取决于 DAG 是否处于 DAC 模式。
如果 DAG 处于 DAC 模式,您可以使用 Start-DatabaseAvailabilityGroup cmdlet 重新合并主站点中的 DAG 成员。 随后,为确保 DAG 使用正确的仲裁模型,需要在不指定任何参数的情况下对 DAG 运行 Set-DatabaseAvailabilityGroup cmdlet。
如果 DAG 没有处于 DAC 模式,您可以使用 Add-DatabaseAvailabilityGroupServer cmdlet 重新合并 DAG 成员。
将主数据中心中的邮箱服务器合并到 DAG 中之后,这些服务器需要一些时间来同步其数据库副本。 此操作可能需要对数据库副本进行重新设定种子操作,具体取决于故障的性质、中断的时间长短以及管理员在中断期间所采取的操作。 例如,如果在中断期间从发生故障的主数据中心删除数据库副本以允许第二个数据中心中幸存的主动副本产生日志文件截断,则需要进行重新设定种子操作。 从此刻起,每个数据库均可单独进行处理。 主数据中心中复制的数据库副本处于正常状态之后,可继续执行下一步骤。
注意: 此过程不需要同时移动所有数据库。 建议同时移动组织的大部分数据库,如果出现与主数据中心中的数据库副本关联的问题,则某些数据库可能会继续停留在第二个数据中心中。 当主数据中心中的大多数数据库均处于正常状态后,便可计划故障回复中断。 当计划的时间来临时,必须采取以下操作:
在数据中心切换过程中,DAG 配置为使用备用见证服务器。 必须将 DAG 重新配置为使用主数据中心中的见证服务器。 如果使用主数据中心中断之前使用的相同见证服务器和见证目录,则可以运行
Set-DatabaseAvailabilityGroup -Identity DAGName
命令。 如果计划使用与原始见证服务器和目录不同的见证服务器或见证目录,请使用 Set-DatabaseAvailabilityGroup 命令来配置具有适当值的见证服务器和见证目录参数。应在第二个数据中心中卸除主数据中心中要重新激活的数据库。 您可以使用 Dismount-Database cmdlet 来卸除这些数据库。
卸除数据库之后,应将客户端访问服务器 URL 从第二个数据中心移动到主数据中心中。 通过将 URL 的 DNS 记录更改为指向主数据中心中的客户端访问服务器或数组,可完成此操作。 这样将使得系统的每个要移动的数据库看起来好像已发生数据库故障转移。
重要说明: 在客户端访问服务器的 URL 移动且 DNS TTL 和缓存条目过期之后,再继续执行下一步骤。 将客户端访问服务器的 URL 移动到主数据中心之前激活主数据中心中的数据库,会导致配置无效,例如,已装入的数据库的 Active Directory 站点中无客户端访问服务器。 因为主数据中心中的每个数据库都处于正常状态,所以可通过执行数据库切换在主数据中心中激活数据库。 通过对将要激活的每个数据库使用 Move-ActiveMailboxDatabase cmdlet,可完成此操作。
将每个数据库移动到主数据中心之后,可通过使用 Mount-Database cmdlet 装入这些数据库。
一个或多个数据库处于活动状态并装入主数据中心后,便可对其他服务器角色执行故障回复步骤。
其他服务器角色故障回复
在切换过程中,客户端、其他服务器和 IP 网关用于解析客户端访问、集线器传输、边缘传输和统一消息服务器的服务端点的内部和外部 DNS 记录会修改为指向第二个数据中心中的相应终结点。 其他服务器角色的故障回复过程需要将这些记录修改为指向主数据中心中的已还原服务终结点。
由于在切换到第二个数据中心期间进行了 DNS 更改,客户端、服务器和 IP 网关会继续尝试连接,且应在原始 DNS 条目的 TTL 过期以及其 DNS 缓存的条目过期之后自动连接。
重新建立站点弹性
成功完成到主数据中心的故障回复之后,可通过验证第二个数据中心中每个邮箱数据库副本的运行状况和状态,重新建立主数据中心的站点弹性。 此外,如果第二个数据中心中的任何数据库副本初始时被阻止激活,则可在此时重新配置这些设置。
终止部分故障的数据中心
© 2010 Microsoft Corporation。保留所有权利。