与旧版本相比的高可用性和网站恢复更改

  • 项目

适用于：Exchange Server 2013 SP1

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

  • IOPS 比 Exchange 2010 降低：这使你可以尽可能高效地利用更大的磁盘的容量和 IOPS。

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

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

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

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

  • 从存储故障中自动恢复：此功能延续了 Exchange 2010 中引入的创新，使系统能够从影响复原能力或冗余的故障中恢复。 除了 Exchange 2010 bug 检查行为之外，Exchange 2013 还包括长时间 I/O 的其他恢复行为、MSExchangeRepl.exe 过度占用的内存，以及系统处于无法计划线程的严重状态。

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

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

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

与 Exchange 2010 相比降低了 IOPS

在 Exchange 2010 中，被动数据库副本的检查点深度较低，这是快速故障转移所必需的。 此外，被动副本会积极地预读取数据以便保持 5 MB 检查点深度。 由于使用低检查点深度并执行这些主动的预读取操作，被动数据库副本的 IOPS 等于 Exchange 2010 中活动副本的 IOPS。

在 Exchange 2013 中，系统能够提供快速故障转移，同时可对被动副本使用较高检查点深度 (100 MB)。 由于被动副本的检查点深度为 100 MB，因此它们已取消调整，不再具有攻击性。 由于增加了检查点深度并对积极预读取进行了去谐，因此在 Exchange 2013 中，被动副本的 IOPS 大约为主动副本 IOPS 的 50%。

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

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

由于这些更改的结果，Exchange 2013 与 Exchange 2010 相比显著降低了 IOPS。

托管可用性

托管可用性是内置主动监视与 Exchange 2013 高可用性平台的集成。 借助托管可用性，系统可以基于服务运行状况确定何时对数据库进行故障转移。 托管可用性是部署在 Exchange 2013 中的客户端访问服务器角色和邮箱服务器角色上的内部基础结构。 托管可用性包括持续工作的三个主要异步组件。 第一个组件是探测器引擎，负责在服务器上进行测量并收集数据。 这些测量结果将流入第二个组件，即监视程序。 监视程序包含系统基于在收集的数据上被视为正常的内容而使用的所有业务逻辑。 类似于模式识别引擎，监视程序将在收集的测量上寻找各种不同的模式，然后决定组件是否正常运行。 最后，还有响应程序引擎，它负责恢复操作。 在某个程序运行不正常时，第一个操作是尝试恢复该组件。 这可能包括多阶段恢复操作；例如，第一次尝试可能是重启应用程序池，第二次尝试可能是重启服务，第三次尝试可能是重启服务器，并且后续尝试可能会使服务器脱机，以使其不再接受流量。 如果恢复操作不成功，系统将通过事件日志通知升级问题给人。

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

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

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

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

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

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

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

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

托管存储

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

Exchange 早期版本中单个存储示例的另一挑战是，虽然可扩展存储引擎 (ESE) 可很好地扩展到 8-12 个处理器核心，但除此之外，跨处理器通信和缓存同步问题均阻碍扩展。 鉴于当今更大的服务器，有 16 个以上的核心系统可用，这将带来管理挑战，即管理 ESE 的 8-12 个核心的相关性，并将其他核心用于非存储进程， (例如助手、搜索基础、托管可用性等 ) 。 此外，之前的体系结构限制了存储进程的规模。

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

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

每个卷多个数据库

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

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

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

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

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

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

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

存储容量增加的趋势会延续下去（预计 8 TB 驱动器很快便会上市）。 在将 8 TB 驱动器与 Exchange 的最大数据库大小最佳做法指导 (2 TB) 结合使用时，会浪费 5 TB 以上的磁盘空间。 一种解决方案是增大数据库，但这会阻碍可管理性，因为它会引入较长的重播时间，包括在某些情况下，操作上无法管理的重播时间，并且通过网络复制该量数据的可靠性会受到损害。

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

为了延续长期做法，我们优化了 Exchange 2013，以便它可以在 JBOD 配置中更高效地使用大型磁盘 (8 TB)。 在 Exchange 2013 中，借助每个磁盘多个数据库这一功能，可以让相同大小的磁盘存储多个数据库副本，包括滞后副本。 目标是驱动现有卷数间的用户分布，从而为您提供一种对称设计，在这种设计中，在正常运行期间，每个 DAG 成员都在相同卷上托管主动、被动和可选滞后副本的组合。

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

每个卷有多个数据库。

上面的配置提供了一个对称设计。 所有四个服务器将相同的四个数据库全都托管于每个服务器上的单个磁盘上。 关键在于，拥有的每个数据库的副本数应等于每个磁盘的数据库副本数。 在上面的示例中，每个数据库有 4 个副本：一个主动副本、两个被动副本和一个滞后副本。 因为每个数据库有四个副本，所以正确配置是每个卷有四个副本。 此外，还会配置激活首选项，以便在 DAG 中及每个服务器间进行平衡处理。 例如，活动副本的激活首选项值为 1，第一个被动副本的激活首选项值为 2，第二个被动副本的激活首选项值为 3，滞后副本的激活首选项值为 4。

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

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

对于每个磁盘单个数据库副本方案，种子设定操作可有效地与源绑定，因为它始终从单个源对磁盘进行种子设定。 通过将卷划分为多个数据库副本，并将指定卷上的被动数据库的活动副本存储在单独的 DAG 成员上。 系统不再在重设置磁盘的上下文中绑定源。 当替换故障磁盘时，可以从多个源对其进行种子重新设定。 这样，系统就可以在更短的时间内为这些数据库重新设置和还原数据保护。

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

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

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

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

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

自动种子重新设定

自动重新设定种子（即 AutoReseed）是通常是由管理员驱动的响应磁盘故障、数据库崩溃或其他必需重新为数据库副本设定种子的问题的而进行的操作的替代功能。 AutoReseed 旨在当磁盘故障发生后通过使用系统提供的备用磁盘自动还原数据库冗余。

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

从存储故障自动恢复

从存储故障自动恢复继续发展了 Exchange 2010 中引入的创新，以允许系统从影响恢复能力或冗余的故障中恢复。 除了 Exchange 2010 bug 检查行为之外，Exchange 2013 还包括长时间 I/O 的其他恢复行为、Microsoft Exchange 复制服务 (MSExchangeRepl.exe) 过度占用的内存，以及无法计划线程的严重情况。

即使在 JBOD 环境中，存储阵列控制器也可能会出现问题，如崩溃或挂起。 Exchange 2010 包含可提供增强恢复能力的挂起 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 2010 功能。 安全网络类似于传输转储程序，因为它是与邮箱服务器上的传输服务关联的传递队列。 此队列存储成功传递到邮箱服务器上活动邮箱数据库的邮件副本。 邮箱服务器上的每个活动邮箱数据库都具有自己的队列，该队列存储已传递邮件的副本。 可以指定在成功传递的邮件的副本过期并自动删除之前，安全网络存储这些副本的时间长度。

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

随着安全网的引入，激活滞后的数据库副本变得更加容易。 例如，分析一个具有 2 天重播滞后的滞后副本。 在该例中，您针对 2 天时间段配置了安全网络。 如果遇到需要使用滞后副本的情况，则可以挂起对它的复制并复制它两次（用于保留数据库的滞后性质并在需要时创建额外副本）。 随后，获取一个副本并丢弃所有日志文件（除了所需范围内的日志文件）。 装入该副本，这会触发对安全网络的自动请求以重新传递最近两天的邮件。 使用安全网络，您不需要寻找哪里出现破坏点。 您将获得最近两天的邮件，减去进行故障恢复时遭受损失的常见数据。

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

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

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

  • 如果只有不到 3 个可用正常副本， (主动或被动副本;超过 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 管理服务以使更改生效。

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

单一副本警报增强功能

确保服务器可靠运行并且邮箱数据库副本状态正常是日常 Exchange 2013 邮件运行的主要目标。 必须主动监视硬件、Windows 操作系统和 Exchange 服务。 但是，在 Exchange 2013 邮箱恢复环境中运行时，监视 DAG 和邮箱数据库副本的运行状况和状态十分重要。 当在复制的数据库只剩下单个副本的时间段内执行数据冗余风险管理和监视时，这尤其至关重要。 在不使用独立磁盘冗余阵列 (RAID) 而是部署 JBOD 配置的环境中，这一点至关重要。 在 RAID 环境中，单个磁盘故障不会影响主动邮箱数据库副本。 但是，在 JBOD 环境中，单个磁盘故障会触发数据库故障转移。

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

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

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

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

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

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

本机功能仍通过事件日志通知提醒管理员，并且为了区分 Exchange 2013 警报与 Exchange 2010，Exchange 2013 使用以下事件 ID：

  • 事件 4138（红色警报）

  • 事件 4139（绿色警报）

在 Exchange 2013 中，该本机功能得到了增强，降低了在相同服务器上的多个数据库进入单一副本状况时可能出现的警报"噪声"级别。 在 Exchange 2010 中，会在每数据库级别上生成单一副本警报。 因此，当存在影响多个数据库和多个数据库副本的服务器端问题时，可能会出现警报风暴。 由于服务器中存在几个故障，如控制器或内存问题，因此对于每个服务器事件，很可能出现此类警报风暴。 在 Exchange 2013 中，现在会基于每个服务器生成警报。 当中断影响整个服务器并且数据冗余对于多个数据库副本存在风险时，将为每个服务器立即生成一个警报。

DAG 网络自动配置

DAG 网络是用于复制通信或 MAPI 通信的一组（一个或多个）子网。 每个 DAG 都包含最多一个 MAPI 网络，以及零个或更多复制网络。 在 Exchange 2010 中，系统会根据群集服务枚举的子网创建初始 DAG 网络（例如 DAGNetwork01 和 DAGNetwork02）。 在使用多个网络并且指定网络（例如 MAPI 网络）的接口处于相同子网上的环境中，管理员几乎不需要执行其他配置。 但是，在指定网络的接口处于多个子网上的环境中，管理员必须执行一个称为折叠 DAG 网络的任务。

在 Exchange 2013 中，不再需要折叠 DAG 网络。 Exchange 2013 仍使用相同的检测机制区分 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 2013 中内置托管的可用性监视组件的一部分。 Active Manager 执行了四个额外的新检查（按执行顺序列出）：

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

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

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

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

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

DAG 管理服务

Exchange 2013 的正式发布 (RTM) 版本的累计更新 2 (CU2) 在作为 DAG 成员的邮箱服务器上包含新服务。 该服务称为 Microsoft Exchange DAG 管理服务 (MSExchangeDAGMgmt)。 该新服务包含内部 DAG 监视功能，该功能之前在 Microsoft Exchange 复制服务 (MSExchangeRepl) 内执行。

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

运行 Windows Server 2008 R2 或 Windows Server 2012 的所有 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 2013 Service Pack 1 (SP1) 及更高版本创建不包含群集管理访问点的 DAG。 可以使用 Exchange 管理中心或使用 Shell 创建没有管理访问点的 DAG。 有关详细信息，请参阅创建 DAG 和 创建数据库可用性组。