对以前版本的 Exchange Server 的高可用性和站点复原能力的更改

  • 项目

Exchange Server 2013 及更高版本使用 DAG 和邮箱数据库副本 (以及其他功能，例如单项目恢复、保留策略和滞后数据库副本) ，以提供高可用性、站点复原能力和 Exchange 本机数据保护。 自 Exchange 2010 以来，高可用性平台、Exchange 信息存储和可扩展存储引擎 (ESE) 都得到了增强，以提供可用性和较少的管理，并降低成本。 这些增强功能包括：

  • 降低 IOPS：这样可以尽可能高效地使用容量和 IOPS 方面更大的磁盘。

  • 托管可用性：借助托管可用性，内部监视和面向恢复的功能紧密集成，有助于防止故障、主动还原服务，并自动启动服务器故障转移或提醒管理员采取措施。 重点在于监视和管理最终用户体验而不仅仅是服务器和组件运行时间，以帮助保持服务连续可用。

  • 托管存储：托管存储是 Exchange 2013 或更高版本中重写的信息存储进程的名称。 托管存储以 C# 编写，并与 Microsoft Exchange 复制服务 (MSExchangeRepl.exe) 紧密集成，通过改进的复原能力提供更高的可用性。

  • 支持每个磁盘多个数据库：通过增强功能，可以支持多个数据库 (同一磁盘上的主动副本和被动副本的混合) ，从而尽可能高效地在容量和 IOPS 方面使用更大的磁盘。

  • AutoReseed：使用自动重设定项功能，可以在磁盘发生故障后快速还原数据库冗余。 如果某个磁盘出现故障，则该磁盘上存储的数据库副本会自动从主动数据库副本复制到相同服务器上的备用磁盘。 如果故障磁盘上存储了多个数据库副本，则可以在备用磁盘上对所有这些副本自动重新设定种子。 这样可实现更快的种子重新设定，因为活动数据库可能位于多台服务器上并且可并行复制数据。

  • 存储故障自动恢复：此功能延续 Exchange 2010 中的创新功能，让系统能够从影响恢复性和冗余性的故障中恢复。 Exchange 现在包括更多 I/O 时间较长的恢复行为、MSExchangeRepl.exe过多的内存消耗，以及系统处于无法计划线程的严重状态。

  • 滞后的复制增强功能：滞后副本现在可以在一定程度上使用自动日志淡化来照顾自身。 在各种情况下（例如页面修补和磁盘空间不足）时，滞后副本将自动淡化日志文件。 如果系统检测到滞后副本需要页面修补，日志将自动重播到滞后副本中以执行页面修补。 当到达低磁盘空间阈值，以及检测到滞后副本在指定时间段内是唯一可用副本时，滞后的副本还将触发此自动重复功能。 此外，滞后副本可以使用安全网，使恢复或激活更加容易。

  • 单一复制警报增强功能：Exchange 2010 中引入的单一复制警报不再是单独的计划脚本。 它现在已集成到系统内的托管可用性组件，是 Exchange 中的一个本地函数。

  • DAG 网络自动配置：系统可以根据配置设置自动配置 DAG 网络。 除了手动配置选项之外，DAG 还可从 MAPI 和复制网络中区分，并自动配置 DAG 网络。

降低 IOPS

在 Exchange 2010 中，被动数据库副本的检查点深度较低，这是快速故障转移所必需的。 此外，被动复制会主动预读取数据，以跟上 5 兆字节 (MB) 检查点深度。 由于使用低检查点深度并执行这些主动的预读取操作，被动数据库副本的 IOPS 等于 Exchange 2010 中活动副本的 IOPS。

在 Exchange 2013 或更高版本中，系统可以提供快速故障转移，同时对被动副本使用高检查点深度 (100 MB) 。 由于被动副本具有 100 MB 检查点深度，因此它们进行了去谐，从而不再具有那么高的积极性。 由于增加检查点深度和取消优化主动预读取，被动副本的 IOPS 约为主动复制 IOPS 的 50%。

在被动副本上具有较高检查点深度还导致了其他更改。 在 Exchange 2010 中进行故障转移时，数据库缓存会在数据库从被动副本转换为主动副本时刷新。 从 Exchange 2013 开始，已重写 ESE 日志记录，以便缓存在从被动到主动的转换中持久保存。 因为 ESE 无需刷新缓存，所以可以快速进行故障转移。

进行的另一个更改是关于后台数据库维护 (BDM) 过程。 BDM 现在的处理能力大约为每秒 1-2 MB/副本。

由于这些更改，Exchange 现在比 Exchange 2010 大幅降低了 IOPS。

托管可用性

托管可用性是内置主动监视和 Exchange 高可用性平台的集成。 借助托管可用性，系统可以基于服务运行状况确定何时对数据库进行故障转移。 托管可用性是一种内部基础结构，部署在邮箱服务器上的客户端访问 (前端) 服务和后端服务中。 托管可用性包括三个主要异步组件，这些组件不断执行工作：

  1. 第一个组件是探测引擎，它负责对服务器进行度量并收集数据。 这些测量结果将流入第二个组件，即监视程序。

  2. 监视程序包含系统基于在收集的数据上被视为正常的内容而使用的所有业务逻辑。 类似于模式识别引擎，监视程序将在收集的测量上寻找各种不同的模式，然后决定组件是否正常运行。

  3. 最后，还有负责恢复操作的响应程序引擎。

在某个程序运行不正常时，第一个操作是尝试恢复该组件。 这可能包括多阶段恢复操作;例如：

  1. 重新启动应用程序池。

  2. 重启服务。

  3. 重新启动服务器。

  4. 使服务器脱机，使其不再接受流量。

如果恢复操作不成功，系统将通过事件日志通知升级问题给人。

托管可用性以两种服务形式实现：

  • Exchange Health Manager 服务 (MSExchangeHMHost.exe) ：这是用于管理工作进程的控制器进程。 它用于在必要时构建、执行并启动和结束工作进程。 它还可用于在进程崩溃的情况下恢复工作进程，以防止工作进程出现单点故障。

  • Exchange Health Manager 辅助角色进程 (MSExchangeHMWorker.exe) ：这是负责执行运行时任务的工作进程。

托管可用性使用持久性存储来执行其功能：

  • XML 配置文件用于初始化工作进程启动期间的工作项目定义。

  • 注册表用于存储运行时数据，如书签。

  • 暗红色通道事件日志基础结构用于存储工作项目结果。

有关托管可用性的详细信息，请参阅 托管可用性。

托管存储

Exchange 2010 及更早版本支持在邮箱服务器角色上运行信息存储进程 (Store.exe) 的单个实例。 此单个存储示例托管服务器上的所有数据库：主动、被动、延迟和恢复。 在这些 Exchange 体系结构中，邮箱服务器上托管的不同数据库之间几乎没有隔离（如果有）。 单个邮箱数据库存在的问题之一是，可能会对其他所有数据库产生负面影响，其邮箱损坏产生的崩溃可能影响为所有数据库驻留在服务器上的用户提供的服务。

单个存储实例的另一个挑战是，可扩展存储引擎 (ESE) 缺乏处理器可伸缩性。 ESE 可很好地扩展到 8-12 个处理器核心，但除此之外，跨处理器通信和缓存同步问题会导致性能下降。 鉴于当今的服务器具有 16 个以上的核心系统可用，这将带来管理挑战：管理 ESE 的 8-12 个核心的相关性，并将其他核心用于非存储进程， (例如助手、搜索基础、托管可用性等) 。 此外，之前的体系结构限制了存储进程的规模。

随着 Exchange 服务器自身的发展，Store.exe 进程经过这些年也已经取得了长足的进步，但作为一个单独的进程，最终的可扩展性是有限的，它代表了一个单一故障点。 由于这些限制，Store.exe在 Exchange 2013 中删除，并替换为托管存储。

有关详细信息，请参阅托管存储。

每个卷多个数据库

尽管 Exchange 中的存储改进主要针对 JBOD) 配置的一组磁盘 (，但它们可供所有支持的存储配置使用。 此功能是能够在相同卷上托管多个数据库。 此功能与针对大型磁盘的 Exchange 优化有关。 这些优化可显著提高大型磁盘在容量、IOPS 和种子重新设定时间方面的使用效率，旨在应对与 JBOD 存储配置中运行关联的挑战：

  • 数据库大小必须可进行管理。

  • 种子重新设定操作必须快速且可靠。

  • 虽然存储容量不断增加，但 IOPS 却没有。

  • 承载被动数据库副本的磁盘在 IOPS 方面未充分利用。

  • 滞后副本具有非对称的存储要求。

  • 具有有限的灵活性以便从磁盘空间不足的情况中恢复。

存储容量增加的趋势仍在继续。 例如，8 TB 驱动器上最大数据库大小 (2 TB 的 Exchange 最佳做法指南) 意味着将浪费超过 5 TB 的磁盘空间。

解决方案是增大数据库规模，但这会抑制可管理性，因为它可能会引入较长的重播时间 (包括操作上无法管理的重播时间) ，以及通过网络复制该数量数据的可靠性受到损害。

此外，在 Exchange 2010 模型中，存储被动副本的磁盘在 IOPS 方面未充分利用。 对于滞后被动副本，磁盘不仅在 IOPS 方面未充分利用，而且在大小方面也是非对称的（相对于用于存储主动和非滞后被动副本的磁盘）。

Exchange 2013 及更高版本已经过优化，可以更高效地使用 JBOD 配置中 (8 TB) 的大型磁盘。 对于每个磁盘多个数据库，现在可以拥有存储多个数据库副本（包括滞后副本）的相同大小的磁盘。 目标是驱动现有卷数间的用户分布，从而为您提供一种对称设计，在这种设计中，在正常运行期间，每个 DAG 成员都在相同卷上托管主动、被动和可选滞后副本的组合。

下面说明了对每个卷使用多个数据库的配置示例。

每个卷使用多个数据库的配置

每个卷有多个数据库。

关系图中的配置提供对称设计。 所有四个服务器将相同的四个数据库全都托管于每个服务器上的单个磁盘上。 关键在于，拥有的每个数据库的副本数应等于每个磁盘的数据库副本数。

在关系图的配置中，每个数据库有四个副本：一个主动副本、两个被动副本和一个滞后副本。 因为每个数据库有四个副本，所以正确配置是每个卷有四个副本。

此外，还会配置激活首选项，以便在 DAG 中及每个服务器间进行平衡处理。 例如：

  • 活动副本的激活首选项值为 1。

  • 第一个被动副本的激活首选项值为 2。

  • 第二个被动副本的激活首选项值为 3。

  • 滞后副本的激活首选项值为 4。

除了在现有卷之间更好地分布用户外，每个磁盘使用多个数据库的另一个好处是减少了对需要重新设置 (（例如磁盘故障) ）的故障还原数据保护的时间。

随着数据库越来越大，对数据库进行种子重新设定的时间也会越来越长。 例如，2TB 数据库可能需要 23 个小时来重新设定种子，而 8TB 数据库可能需要的时间长达 93 个小时（将近 4 天）。 这两个种子就会按每秒约 20 MB 的速度进行设定。 这通常意味着，在可操作的合理时间段内，无法设定非常大的数据库的种子。

对于每个磁盘单个数据库副本方案，种子设定操作可有效地与源绑定，因为它始终从单个源对磁盘进行种子设定。

通过将卷划分为多个数据库副本，以及通过让指定卷上的被动数据库的主动副本存储在单独 DAG 成员上，系统在对磁盘进行种子重新设定的上下文中将不再与源绑定。 当替换故障磁盘时，可以从多个源对其进行种子重新设定。 这使得系统可以在大大缩短的时间内对这些数据库进行种子重新设定并还原数据保护。

每个卷使用多个数据库时，建议遵循以下最佳做法和要求：

  • 必须使用每个物理磁盘中的一个逻辑磁盘分区。 请勿在磁盘上创建多个分区。 每个数据库副本及其附随文件（如，事务日志、内容索引等）都应托管于单个分区上的唯一目录中。

  • 对每个卷配置的数据库副本数应等于每个数据库的副本数。 例如，如果数据库有四个副本，则应对每个卷使用四个数据库副本。

  • 数据库副本应具有相同的邻居。 (例如，它们应在每个服务器上共享同一磁盘。)

  • 在 DAG 中平衡激活首选项，以便指定磁盘上的每个数据库副本都具有唯一的激活首选项值。

自动种子重新设定

自动重设定 (也称为 AutoReseed) 是通常由管理员驱动的操作的替代，以响应磁盘故障、数据库损坏事件或其他需要重新设定数据库副本的子期的问题。 AutoReseed 旨在当磁盘故障发生后通过使用系统提供的备用磁盘自动还原数据库冗余。

有关详细信息，请参阅AutoReseed。 有关配置 AutoReseed 的详细步骤，请参阅为数据库可用性组配置 AutoReseed。

从存储故障自动恢复

从存储故障中自动恢复允许系统从影响复原能力或冗余的故障中恢复。 除了 Exchange 2010 中引入的 bug 检查行为外，Exchange 现在还包含针对长时间 I/O 的其他恢复行为、Microsoft Exchange 复制服务 (MSExchangeRepl.exe) 的过度内存消耗，以及无法计划线程的严重情况。

即使在 JBOD 环境中，存储阵列控制器也可能会出现问题，如崩溃或挂起。 下表列出了提供挂起 I/O 检测的功能，以及提供增强复原能力的恢复功能。

名称 支票 操作 阈值
ESE 数据库挂起 IO 检测 ESE 检查未完成的 I/O 在暗红色通道中生成失败项目以重启服务器 240 秒
失败项目通道检测信号 确保可以对暗红色通道写入和读取失败项目 复制服务检测暗红色通道并在失败时重启服务器 30 秒
系统磁盘检测信号 验证服务器的系统磁盘状态 定期将无缓冲的 I/O 发送到系统磁盘；在检测信号超时时重启服务器 120 秒

Exchange 2013 及更高版本通过包括针对其他严重条件的行为来增强服务器和存储复原能力。 下表介绍了这些情况和行为。

名称 支票 操作 阈值
系统错误状态 无法安排线程，包括非托管线程 重启服务器 302 秒
较长的 I/O 时间 I/O 操作滞后测量 重启服务器 41 秒
复制服务内存使用情况 测量 MSExchangeRepl.exe 的工作集 1：使用服务终止请求记录深红色通道中的事件 4395
2：启动终止MSExchangeRepl.exe
3：如果服务终止失败，请重启服务器		 4 GB
系统事件 129（总线复位） 在系统事件日志中检查事件 129 重启服务器 事件发生的时间
群集数据库挂起 全局更新管理器更新已被阻止 重启服务器 事件发生的时间

滞后副本增强功能

滞后副本增强功能包括与安全网络的集成以及特定情况下的日志文件自动减少。 Exchange 2013 中引入了安全网，以取代称为传输垃圾箱的 Exchange 2010 功能。 安全网类似于传输转储器，因为它是与邮箱服务器上的传输服务关联的传递队列。 此队列存储成功传递到邮箱服务器上活动邮箱数据库的邮件副本。 邮箱服务器上的每个活动邮箱数据库都具有自己的队列，该队列存储已传递邮件的副本。 可以指定在成功传递的邮件的副本过期并自动删除之前，安全网络存储这些副本的时间长度。

安全网络会负责 DAG 环境中一些卷影冗余工作。 在 DAG 环境中，卷影冗余无需在等待将已传递邮件复制到 DAG 中其他邮箱服务器上的邮箱数据库被动副本期间，将已传递邮件的另一个副本保留在卷影队列中。 已传递邮件的副本已存储在安全网络中，因此卷影冗余可以在需要时从安全网络重新传递邮件。

使用安全网，激活滞后的数据库副本变得更加容易。 例如，分析一个具有 2 天重播滞后的滞后副本。 在该例中，您针对 2 天时间段配置了安全网络。 如果遇到需要使用滞后副本的情况，可以：

  1. 暂停复制到该副本。

  2. (复制它两次，以保留数据库的滞后性质，并创建额外的副本，以防需要它) 。

  3. 获取副本并放弃所有日志文件，但所需范围内的日志文件除外。

  4. 装入该副本，这会触发对安全网络的自动请求以重新传递最近两天的邮件。

使用安全网络，您不需要寻找哪里出现破坏点。 您将获得最近两天的邮件，减去进行故障恢复时遭受损失的常见数据。

在特定情况下，滞后副本现在可以通过调用自动日志重播以减少日志文件来进行自我管理：

  • 当达到磁盘空间不足阈值时

  • 当滞后副本发生物理损坏并且需要进行页面修补时

  • 当在超过 24 小时的时间内可用正常副本（仅主动或被动；不计入滞后数据库副本）少于三个时

在 Exchange 2010 中，不可对滞后副本进行页面修补。 在 Exchange 2013 或更高版本中，可通过此自动淡化功能对滞后副本进行页面修补。 如果系统检测到滞后的副本需要页面修补，日志将自动重放到滞后副本以执行页面修补。 当达到低磁盘空间阈值，以及检测到滞后副本在指定时间段内是唯一可用副本时，滞后的副本还将触发此自动重复功能。

滞后副本减少行为在默认情况下会被禁用，可以通过运行以下命令来启用。

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

启用后，在少于三个副本时，会出现减少行为。 可以通过修改以下 DWORD 注册表值来更改默认值 3。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

若要针对磁盘空间不足阈值启用减少功能，必须对下列注册表项进行配置。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

在配置这些注册表设置的任何一个之后，重新启动 Microsoft Exchange DAG 管理服务以使更改生效。

例如，假设给定数据库有四个副本 (三个高可用性副本和一个滞后副本) ，并且默认设置用于 ReplayLagManagerNumAvailableCopies。 如果非滞后副本由于某种原因（例如被挂起，等等）而停用，那么滞后副本会在 24 小时内自动减少其日志文件。

单一副本警报增强功能

确保服务器运行可靠且邮箱数据库副本正常运行是每日 Exchange 消息传递操作的主要目标。 必须主动监视硬件、Windows 操作系统和 Exchange 服务。

但在 Exchange 邮箱复原环境中，请务必监视 DAG 和邮箱数据库副本的运行状况和状态。 当在复制的数据库只剩下单个副本的时间段内执行数据冗余风险管理和监视时，这尤其至关重要。 在不使用独立磁盘冗余阵列 (RAID) 而是部署 JBOD 配置的环境中，这一点至关重要。 在 RAID 环境中，单个磁盘故障不会影响主动邮箱数据库副本。 但是在 JBOD 环境中，单个磁盘故障会触发数据库故障转移。

CheckDatabaseRedundancy.ps1脚本已在 Exchange 2010 中引入。 顾名思义，该脚本的用途是，通过验证至少存在两个已配置的当前正常副本来监视复制邮箱数据库的冗余，并且当仅存在复制数据库的单个正常副本时通过生成事件日志来提醒管理员。 在这种情况下，当确定冗余时，会将主动副本和被动副本都计算在内。

单一副本情况包括（但不限于）：

  • 主动副本未能复制到任何被动副本。

  • 所有被动副本失败；这包括 FailedAndSuspended 和 Failed 状态以及正常状态，在这些状态下，副本会在日志复制或重播方面滞后。 如果滞后副本在 10 分钟内将日志重播到延迟期，则不会将其视为滞后。

  • 系统未能准确了解主动副本的当前日志生成。

由于管理员的当务之急是了解它们减少为数据库的单个正常副本的时间，因此已将 CheckDatabaseRedundancy.ps1 脚本替换为属于托管可用性的 DataProtection 运行状况设置的集成本机功能。

本机功能仍通过事件日志通知向管理员发出警报，为了区分 Exchange 2013 或更高版本的警报和 Exchange 2010，Exchange 现在使用以下事件 ID：

  • 事件 4138（红色警报）

  • 事件 4139（绿色警报）

本机功能已得到增强，以减少同一服务器上的多个数据库进入单个复制条件时出现的警报干扰。 在 Exchange 2010 中，会在每数据库级别上生成单一副本警报。 因此，影响多个数据库和多个数据库副本的服务器范围问题可能会导致警报风暴。 由于多个故障是服务器范围的 (例如，控制器或内存问题) ，因此很有可能每个服务器事件都会出现警报风暴。

警报现在基于每个服务器生成。 当中断影响整个服务器并且数据冗余面临多个数据库副本的风险时，将生成单个每个服务器警报。

DAG 网络自动配置

DAG 网络是用于复制通信或 MAPI 通信的一组（一个或多个）子网。 每个 DAG 都包含最多一个 MAPI 网络，以及零个或更多复制网络。

在 Exchange 2010 中，初始 DAG 网络 (例如 DAGNetwork01 和 DAGNetwork02) 是由系统基于群集服务枚举的子网创建的。 例如，如果具有多个网络和指定网络 (的接口，则 MAPI 网络) 位于同一子网上，则几乎不需要其他配置。 但是，如果指定网络的接口位于多个子网上，则需要执行称为折叠 DAG 网络的任务。

在 Exchange 2013 或更高版本中，不再需要折叠 DAG 网络。 Exchange 仍使用相同的检测机制来区分 MAPI 网络和复制网络，但现在它会根据需要自动折叠 DAG 网络。

此外，默认情况下，DAG 网络现在由系统自动管理。 若要使用 Exchange 管理中心 (EAC) 查看 DAG 网络属性，必须使用 EAC 修改 DAG 的属性，或使用 Set-DatabaseAvailabilityGroup cmdlet 将 ManualDagNetworkConfiguration 参数设置为 来 $true配置用于手动网络控制的 DAG。

对最佳副本选择的更改

最佳副本选择 (BCS) 是一个内部算法过程，在提供了用于激活的潜在副本及其运行状况和状态的列表时，用于查找要激活的单个数据库的最佳副本。 当现有主动数据库副本失败时或是当管理员执行无目标切换时，Active Manager 会选择"最佳"的可用（并且未阻止的）副本来作为最新主动数据库副本。 在 Exchange 2010 中，BCS 进程将评估每个数据库副本的几个方面，以确定要激活的最佳副本。 包括：

  • 复制队列长度

  • 重播队列长度

  • 数据库状态

  • 内容索引状态

在 Exchange 2013 或更高版本中，Active Manager 执行相同的 BCS 检查和阶段来确定复制运行状况，但它现在还包括使用运行状况状态递减顺序的约束。 这些更改的结果是，BCS 现已称为最佳副本和服务器选择 (BCSS)。

BCSS 包括多个新的运行状况检查，这些检查现在是 Exchange 中内置托管的可用性监视组件的一部分。 Active Manager 执行的其他四项检查 (按) 执行的顺序列出：

  1. 所有正常：检查托管受影响数据库副本的服务器，该副本的所有监视组件都处于正常状态。

  2. 最高为正常：检查托管受影响数据库副本的服务器，该副本的所有监视组件均处于正常状态。

  3. 全部优于源：检查托管受影响数据库副本的服务器，该数据库具有监视组件的状态比托管受影响副本的当前服务器要好。

  4. 与源相同：检查托管受影响数据库副本的服务器，该数据库具有与托管受影响副本的当前服务器相同的状态的监视组件。

如果由于托管可用性监视组件（例如，通过故障转移响应程序）触发的故障转移而调用 BCSS，则会实施一个附加强制约束，其中，目标服务器的组件运行状况必须好于进行故障转移的服务器。 例如，如果Outlook 网页版 (故障（以前称为“Outlook Web App) ”）触发通过故障转移响应方进行托管可用性故障转移，则 BCSS 必须选择托管受影响数据库副本的服务器，Outlook 网页版正常。

DAG 管理服务

Exchange 2013 CU2 或更高版本包括 Microsoft Exchange DAG 管理服务 (MSExchangeDAGMgmt) 。 此服务包含以前在 MICROSOFT Exchange 复制服务内部的内部 DAG 监视功能 (MSExchangeRepl) 。

不包含群集管理访问点的 DAG

运行 Windows Server 2008 R2 或 Windows Server 2012 的 Exchange 服务器上的所有 DAG 都需要在 MAPI 网络中包含的每个子网上至少有一个 IP 地址。 分配给 DAG 的 IP 地址由包含群集管理访问点（也称为群集网络名称）的 DAG 群集用于对使用群集名称的群集启用名称解析和连接（或者更准确的说法，是到当前拥有群集核心资源组的群集成员的连接）。

Windows Server 2012 R2 或更高版本，无需管理访问点即可创建故障转移群集。 不包含管理访问点的 Windows 故障转移群集具有以下特征：

  • 不会向群集分配任何 IP 地址，因此群集核心资源组中没有 IP 地址资源。

  • 不会向群集分配网络名称，因此群集核心资源组中没有网络名称资源。

  • 群集名称未在 DNS 中注册，群集名称在网络上不可解析。

  • 不会在 Active Directory 中创建群集名称对象 (CNO) 。

  • 无法使用故障转移群集管理工具管理 Windows 故障转移群集。 相反，需要使用 Windows PowerShell并且需要针对各个群集成员运行 PowerShell cmdlet。

Windows Server 2012 R2 或更高版本在 Exchange 上运行的 Exchange 2013 SP1 或更高版本使你无需群集管理访问点即可创建 DAG。 有关详细信息，请参阅创建 DAG 和 创建数据库可用性组。