介绍一下Exchange 2010 SP1 虚拟化功能部分

自从我们宣布对 Exchange 2010 的虚拟化支持声明的一些重大更改以来，已有几个月的时间（请参阅宣布 Exchange 2010 的增强的硬件虚拟化支持（该链接可能指向英文页面））。在这段时间内，我收到了相当多有关特定部署方案和我们的支持声明更改可能如何影响这些部署的很棒的问题。考虑到问题数量巨大，似乎是发布一些其他信息和说明的绝佳时机了。

首先我想介绍一下背景。在我们对支持声明进行更改时，我们希望确保的主要事情是客户不会担心 Exchange 服务可用性可能因使用虚拟化部署而降低。换句话说，我们希望确保使用 Exchange 2010 产品的物理部署可实现的高水平可用性无论如何都不会因部署在虚拟化平台上而降低。当然，我们还希望确保产品保持运行，并且我们确认虚拟化堆栈提供的其他功能不会在正常操作期间产生任何 Exchange 数据丢失。

考虑到这些要点，下面是我们更改的内容及其实际意味着什么的简要介绍。

部署了 Exchange 2010 SP1（或更高版本）： 虚拟机中支持所有 Exchange 2010 服务器角色，包括统一消息。 统一消息虚拟机具有以下特殊要求：

虚拟机需要四个虚拟处理器。应使用标准最佳实践指南确定内存大小。 有四个物理处理器核心可供每个统一消息角色虚拟机一直使用。此要求意味着不能使用任何处理器过度订阅。此要求会影响统一消息角色虚拟机利用物理处理器资源的能力。 Exchange 服务器虚拟机（包括属于 DAG 的一部分的 Exchange 邮箱虚拟机）可以与基于主机的故障转移群集和迁移技术结合使用，只要将虚拟机配置为不会在移动或脱机时在磁盘上保存状态和还原该状态。在目标节点上激活虚拟机时，所有故障转移活动必须引发冷启动。所有计划的迁移必须引发关机和冷启动，或使用 Hyper-V 实时迁移之类的技术的联机迁移。虚拟机的虚拟机监控程序迁移由虚拟机监控程序供应商支持；因此，您必须确保您的虚拟机监控程序供应商已测试并支持 Exchange 虚拟机迁移。Microsoft 支持这些虚拟机的 Hyper-V 实时迁移。

让我们研究一些定义以确保我们全部以相同的方式理解这些支持声明中的术语。

冷启动：这是指使系统从断电状态进入操作系统的干净启动的操作。在这种情况下，不保留任何操作系统状态。 已保存状态：在虚拟机断电时，虚拟机监控程序通常能够保存该时间点的虚拟机状态，以便在虚拟机重新通电时，它会返回到该状态而非经历“冷启动”。“已保存状态”将是 Hyper-V 中的“保存”操作的结果。 计划的迁移：在系统管理员开始将虚拟机从一个虚拟机监控程序主机移动到另一个虚拟机监控程序主机时，我们将此称为计划的迁移。这可以是单个迁移，系统管理员也可以配置某种自动化，该自动化负责定时或作为系统中发生的非硬件或软件失败的某个其他事件的结果移动虚拟机。此处的要点是 Exchange 虚拟机正常运行并由于某个原因需要重定位 – 这可以通过实时迁移或 vMotion 之类的技术实现。如果虚拟机所在的 Exchange 虚拟机或虚拟机监控程序主机遇到某种失败情况，则该情况的结果不是“计划的”。

虚拟化统一消息服务器

进行的更改之一是添加了对 Hyper-V 及其他受支持的虚拟机监控程序上的统一消息角色的支持。正如我在本文开头提到的，我们确实希望确保对支持声明进行的任何更改都会使产品完全发挥作用并为用户提供尽可能好的服务。因此，我们需要部署 Exchange Server 2010 SP1 以提供 UM 支持。这么做的原因相当简单。UM 角色依赖 Microsoft Lync 团队提供的媒体组件。我们的 Lync 合作伙伴在 Exchange 2010 SP1 发布之前做了一些工作以在虚拟部署中实现高质量的实时音频处理，而在 Exchange 2010 SP1 发行版中，我们将这些更改集���到了 UM 角色中。实现了该集成后，我们执行了一些其他测试来确保尽可能最佳的用户体验并修改了支持声明。

正如您将注意到的，我们对运行 UM 的虚拟机（和虚拟机监控程序主机）的 CPU 配置确实具有特定要求。这是防止用户体验不佳（这将显示为语音质量不佳）的额外保障。

基于主机的故障转移群集和迁移

许多有关更改的支持声明的混淆源于有关将基于主机的故障转移群集和迁移技术与 Exchange 2010 DAG 结合使用的详细信息。此处的指南实际上相当简单。

首先，让我们讨论我们是否支持第三方迁移技术（例如 Vmware 的 vMotion）。Microsoft 无法对使用这些技术的第三方虚拟机监控程序产品与 Exchange 2010 的集成发表“支持”声明，因为这些技术不属于服务器虚拟化验证计划（该链接可能指向英文页面） (SVVP) 的一部分，该计划涵盖我们对第三方虚拟机监控程序的支持的其他方面。我们在这里发表有关支持的一般声明，但另外您需要确保虚拟机监控程序供应商支持其迁移/群集技术与 Exchange 2010 结合使用。尽可能简单地说：如果您的虚拟机监控程序供应商支持其迁移技术与 Exchange 2010 结合使用，则我们支持 Exchange 2010 与其迁移技术结合使用。

其次，让我们讨论我们如何定义基于主机的故障转移群集。这是指提供自动回应主机级别的故障并在备用服务器上启动受影响的虚拟机的功能的任何种类的技术。如果在故障方案中，虚拟机将在备用主机上通过冷启动来启动，则提供的支持声明中绝对支持使用此技术。我们希望确保虚拟机从不会通过磁盘上保留的已保存状态启动，因为它相对于其余 DAG 成员来说将是“陈旧的”。

最后，当提到支持声明中的迁移技术时，我们将讨论允许虚拟机从一个主机到另一个主机的计划移动的任何种类的技术。另外，这可以是作为资源负载平衡的一部分发生的自动移动（但与系统中的故障无关）。绝对支持迁移，只要虚拟机从不通过磁盘上保留的已保存状态启动。这意味着支持通过使用网络传输状态和虚拟机内存来移动虚拟机且觉察不到停机的技术与 Exchange 2010 结合使用。请注意，第三方虚拟机监控程序供应商必须为迁移技术提供支持，同时 Microsoft 将为 Exchange 在此配置中使用提供支持。对于 Microsoft Hyper-V，这将意味着支持实时迁移，但不支持快速迁移。

使用 Hyper-V，一定要知道在虚拟机上选择“移动”操作时的默认行为实际上是执行快速迁移。要在使用 Exchange 2010 SP1 DAG 成员时保持受支持状态，按照下面的虚拟机设置中所示调整此行为很重要（此处显示的设置表示您应该如何使用 Hyper-V 进行部署）：


图 1：数据库可用性组成员的正确 Hyper-V 虚拟机行为

让我们回顾一下。在 Hyper-V 中，DAG 成员支持实时迁移，但不支持快速迁移。直观地说，这意味着支持以下操作：


图 2：支持 Hyper-V 中的数据库可用性组成员的实时迁移（请查看大屏幕截图）

不支持以下操作：


图 3：不支持数据库可用性组成员的快速迁移

希望这有助于阐明我们的有关 SP1 更改的支持声明和指南。我们期待着您提供任何反馈！

Jeff Mealiffe



这是一篇本地化的博客文章。请访问 Demystifying Exchange 2010 SP1 Virtualization 以查看原文

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。