VMware vSphere 5.1 群集深入解析(第四部分 群集架构的扩展)

第四部分群集架构的扩展

第一章群集架构的扩展

第二章 vSphere配置

第三章故障排错

第四章总结汇总

第五章附录

第一章群集架构的扩展

在这部分我们将继续讨论特定的基础架构、怎样利用HA，DRS和存储DRS以及怎样部署增加可用性。无论是你的工作量还是资源提供给你的工作量，我们将通过一些设计建议和决策方法来进行指导。当然，为了在实施的细节上做出合适的决定，完全了解你的环境是必要的。无论如何，我们希望这个部分能提供一个恰当的方式理解如何将某些功能放到一起，如何在你的环境接收到需求的时候，建立理想的架构。

场景

我们选择是场景是扩展群集，也会提到Vmware vSphere Metro Storage Cluster 解决方案。我们选择指导的场景来允许我们解释多个设计和架构考虑。尽管场景已经测试过，在我们的实验环境中也有效，每个环境是独一无二的，我们的建议基于我们的经验和你的情况可能不同。

一个VMware vSphere Metro Storage Cluster (vMSC)配置是Vmware vSphere 5认证的解决方案，基于群集结合存储阵列同步复制。这个解决方案通常部署在数据中心距离上有限制的环境，往往大都市或者校园环境。

扩展群集模式主要的优势是使数据中心充分活跃和工作负载平衡，因为站点之间虚拟机的迁移和存储vMotion的能力，许多客户发现了其吸引力，开启 on- demand和non-intrusive来跨站点移动工作负载，群集的扩展能力提供主动负载平衡自由，这应该是主要的设计和实施目标。

扩展群集解决方案提供的好处：

?工作负载移动性

?跨站点自动负载平衡

?增强避免停机时间

?避免灾难

技术需求和约束

因为虚拟机在线迁移的技术约束，有一些指定的需求必须在扩展群集实施时需要考虑，这些需求在Vmware 硬件兼容向导中存储部分的清单中，包括如下：

?存储连接使用光纤通道，ISCSI，SVD（存储虚拟化设备）和支持FCOE ?存储连接使用NAS（NFS协议）在写入的时候不支持vMSC配置（2012年8月）

?在站点和ESXi管理网络之间支持的最大网络延迟为10ms往返时间（Round Trip Time (RTT)）

?注意vMotion仅仅在企业加强版的license下才支持的10ms延迟（Metro vMotion）

?为了同步存储重复链接支持最大的延迟是5ms（Round Trip Time (RTT)），通常你的存储厂商会提供它们允许的最大的RTT

?ESXi的vMotion网络至少需要622Mbps的冗余网络链路

存储的需求比存储同步复制解决方案要复杂一些，一个

vSphere Metro Storage Cluster请求会由单个存储子系统扩展到站点，在这个设计中，提供的数据存储必须可以访问（能读能写），并同时来自于两个站点。更进一步，当问题出现，ESXi主机必须能继续从任一站点访问数据存储，不影响正在进行的存储操作。

这排除了传统的同步复制解决方案，当他们在活动的（主）LUN之间创建主/备关系，数据被访问，备LUN正在收到复制操作，在这些解决方案中，为了访问备LUN，重复必须停止（或者撤销），LUN可见主机，现在升级了的备LUN有了完全不同的LUN ID，本质上是一个新的可用副本，这种类型的解决方案适用于适用于传统的灾难恢复。预计虚拟机需要在第二站点上启动，vMSC需要同时配置第二站点，vMSC需要同时配置不影响访问，所以站点之间还是允许运行着的虚拟机进行迁移；正常的vMotion不会迁移虚拟机的磁盘文件。

vMSC的存储子系统必须在两个站点上同时读写，所有磁盘写入站点同步来确保数据一致性。写无论本地从哪个位置读取，存储架构在群集站点间调用需要大量的带宽和非常低的延迟，增加距离和延迟将引起磁盘写入延迟，使得性能大打折扣，将不允许在群集站点的不同地点之间成功执行vMotion。

统一和非统一

vMSC解决方案在不同区域目录中分类，这些分类基于不同基础的主机访问存储。理解不同类型的扩展存储解决方法非常重要，它会影响到你的设计，有个主要的目录在VMware 硬件兼容性列表中有描述：

?统一主机访问配置–两个站点的ESXi主机要连接全部站点存储群集上的存储节点来访问，提交ESXi主机的路径是扩展访问距离

?不统一的主机访问配置–每个站点的ESXi主机只连接同一站点的存储节点，提交ESXi主机的路径的存储节点限制在本地站点。

让我们从架构和实施角度描述更深一些来确保它们足够清晰。

统一，数据中心-A和数据中心-B的主机既能访问数据中心A存储系统又能访问数据中心B存储系统。实际上，存储区域网络在站点和所有主机之间被扩展从

而能访问所有的LUN，在这些配置中，读写访问LUN发生在两个阵列之一上，同步镜像被维护隐藏，在第二阵列处于只读状态。例如，如果LUN包含的数据存储在数据中心-A的阵列上可读写，所有的ESXi主机将通过数据中心A的阵

列进入数据存储，为了数据中心A的ESXi主机，会有一个本地访问，数据中心B ESXi主机上的运行着虚拟机的位于数据存储上，为了防止停机或者LUN的

操作控制转换到数据中心-B上，所有的ESXi主机将继续查看在场的相同的LUN，除了已经访问了数据中心-B的ESXi主机。

图160：统一存储架构

正如你所看到的，理想的情况是一个虚拟机同一个数据中心通过阵列控制（读写）访问的数据存储，这最大限度的减少了数据中心之间的流量，避免了读取整个互连性能的影响。

虚拟机的站点关联的概念是由数据存储的读写副本支配，―站点关联‖一些时候也称之为―site bi as‖或者―LUN locality‖，意味着当数据中心A上的虚拟机有站点关联，它读写数据中心A位于数据存储上的副本，这已经在DRS章节中解释得较详细。

不统一：数据中心A上的主机只能访问数据中心本地的阵列，阵列（相反的数

据中心的同级阵列）负责提供全部的数据存储大家访问，在大多数场景中虚拟机用到了这个概念，它允许每个数据中心上的ESXi主机读写同一个数据存储/LUN。

很好理解，即使两个虚拟机在同一个数据存储，但位于不同的数据中心，它们

会写到本地，在此配置的一个关键点是，定义每个LUN/数据存储的站点关联（Site Affinity），还有时候需要涉及到―Site bias‖或者―LUN locality‖。换句话说，如果在站点和站点上的存储系统之间的链路上发生一些事情，站点为了个给数

据存储将只有读写方式的能够访问，这当然是为了在失败的场景下阻止数据损坏。

图161：不统一的存储架构

作为统一的解决方案是当今最常用的部署，我们的测试情况下将使用统一存储，应当指出，许多的设计考虑也适用于非统一配置，若不是这种场景的情况，我们会进行收集。

场景架构

在这部分我们将为场景描述架构配置，我们还将讨论一些基本的配置和多样的vSphere功能，为了更深的解释各自的功能，涉及到此书HA和DRS部分，我们将基于VMware最佳实践和提供的操作手册来提出针对建议，在我们失败的场景中将解释怎样在实践中阻止和限制停机时间。

架构

一个由单个vSphere 5.1群集和4个ESXi主机组成的架构场景，vSphere vCenter 服务器管理这些主机，它决定使用vSphere 5.1来测试提高改进vSphere 5.0 U1

中介绍的―永久设备丢失‖（PDL）场景。介绍的这些加强的功能主要用于扩展群集环境。我们将在此章节讨论vSphere HA部分更详细的内容。值得注意的是在vSphere 5.1中PDL行为方面没有任何改变。

为了我们测试目的，我们模拟有两个站点的用户环境，第一个站点叫Frimley，第二个站点叫Bluefin。Frimley数据中心和Bluefin数据中心之间是扩展2层网络，学校群集之间的距离是最小的距离，vCenter Server和虚拟机运行在同一个

群集上。

每个站点有两个ESXi主机，Bluefin数据中心的vCenter Server配置了

vSphere DRS管理主机，在扩展群集环境中只有一个vCenter Server实例是使用的，不同于传统的VMware Site Recovery Manager配置需要两个vCenter Server。在第15章讨论了配置VM-Host关联规则，在我们的场景中使用ISCSI为主要协议。

在vSphere 5.1群集通过统一设备接入模式的光纤配置连接上

NetApp MetroCluster。此配置在NetApp的技术白皮书―TR- 3548‖中有深入描述。这意味着群集里每个主机连接了两个存储节点。每个节点连接到两个光纤交换机，第二区域的节点还连接到两个类似的交换机，对于任何给定的LUN，两个存储节点中的任何一个呈现的LUN是通过ISCSI读写。

与此相反的存储节点保持着复制，只读副本有效的隐藏起来，直到ESXi主机需要。

当使用NetApp MetroCluster，一个ISCSI连接绑定一个指定的虚拟IP地址，ESXi 主机上的这个虚拟IP地址用来连接存储控制器。在失败的场景中，IP-Address

转换到相反的存储控制器，允许无缝访问目标存储的IP地址，而不需要重新配置。

总计创建了8个LUN：4个通过虚拟ISCSI IP地址访问Frimley数据中心，另外4个通过虚拟ISCSI IP地址访问Bluefin数据中心。

图162：基础结构

表27：基础架构

第二章 vSphere配置

这种情况下，我们的重点是扩展群集环境中vSphere HA，vSphere DRS和存储DRS之间的关系，以及围绕这些vSphere组件在设计和运作方面经常被忽视和低估的考虑。历来很多重点放在存储层，而很少考虑工作负载如何配置和管理。

如我们之前提到的，扩展群集关键的驱动力是工作负载平衡和灾难避免。怎样

确认我们的环境是处在合理的平衡中而没有影响可用性或者大幅减少操作开销？

我们怎样建立配置需求和持续管理过程，我们怎样定期验证我们仍然满足我们的需求？定义和遵从需求失败会使环境混乱难以管理、各种故障场景难以预测，也会希望它来帮助你。事实上，忽略过程会导致故障事件中产生额外的停机时间。

这三个VMware vSphere功能每一个都有特别的配置需求，能加强你环境的弹性和工作负载的可用性，通过这一部分，架构建议将产生，这些建议将基于测试期间的各种场景发现的问题。每一个故障场景测试在接下来的章节中都被记录，请记住，这些故障场景直接应用这些实例的配置，基于你的实施和配置选项你的环境可能会受到额外故障。

vSphere HA 特性

我们的实例环境中有4台主机和一个统一扩展存储解决方案。当全部站点发生故障是需要考虑弹性架构的一个场景，我们建议开启接入控制

（Admission Control），工作负载的可用性是许多扩展群集环境的主要驱动力，它建议有足够的容量允许全站点故障，尽管如此，两个站点将平等的分配主机，来确保所有的工作负载能通过HA重新开始，建议配置接入控制策略为50%。

我们建议使用基于百分比的策略来提供架构的灵活性和减少操作开销，尽管新主机加入环境中没有必要改变百分比，而且没有整合率偏差，导致使用虚拟机级别预留资源的风险，更多详情请见第6章。

HA使用心跳检测机制来验证主机的状态，如第3章解释的有两个心跳检测机制；称为网络和数据存储心跳检测，网络心跳检测时HA验证主机的主要机制，数据存储心跳检测是一旦网络心跳检测失败通过HA来确定主机状态的另一种机制。

如果主机没有收到任何的心跳检测，它检测是否仅仅是从其它主机隔离或者网络中完全隔离。这个过程包括了Ping主机的默认网关，或者一个或者多个手工设置的隔离地址来代替主机网关，从而加强隔离检测的可靠性。我们建议指定最少两个额外的隔离地址并且每个地址能到本地网络，即使在站点之间连接失败的情况下，开启HA能够验证完整的网络隔离，并提供冗余允许一个IP故障。

但是，如果主机被隔离，vSphere HA触发响应，这在之前有解释过，叫做隔离响应，当主机同管理网络之间的连接断开，触发隔离响应来保证妥善管理虚拟机。隔离响应在第三章有深入讨论，根据使用不同的存储和物理网络完成，隔离响应用来在需要时做出决定，我们提到在第四章，表3中支持的决定。

在我们的测试环境中，一部分这些地址将属于Frimley 数据中心，另一部分属于Bluefine数据中心，屏幕截图显示了怎样配置多个隔离地址的实例，vSphereHA 高级设置使用das.isolationaddress，更详细的如何配置可以在KB 文章 1002117中找到。

为了vSphere HA数据存储心跳在任何故障场景中都运行正常，我们建议增加数据存储心跳的数量为2-4，最少的数据存储心跳为2，最大为5，扩展群集环境中

建议4，这样将提供本地的全冗余。还建议定义4个指定数据存储为优先数据存储心跳，选择一个站点的2个然后选择另一个站点的2个。这样做即使站点之间发生连接故障也允许vSphere HA的数据存储心跳。如果站点之间发生连接故障后站点还存在部分网络，这些数据存储将非常有用。

数据存储心跳的数量能通过HA高级设置das.heartbeatDsPerHost.进行增加。

我们建议使用―选择考虑加入我的首选项的任何群集数据存储‖，它将允许vSphere HA选择任意4个设计的数据存储，我们手工选择变得不可用，原因是如果我们建议的站点间4个心跳连接失败，vCenter将最终在一个站点上，这样另一个站点的主机就没有机会HA来改变数据存储心跳。这个设置的截屏如下。

图163：数据存储心跳

vSphere 5.0 U1永久设备丢失（PDL）增强

vSphere 5.0 U1 版本中，介绍了永久设备丢失（PDL）的条件—允许数据存储上的虚拟机自动故障转移，我们将在其中一个故障场景中展示一个PDL环境，沟通的环境是通过阵列控制器经过一个指定的SCSI代码到ESXi，这些条件声明一个设备（LUN）将不可用，并且可能是永久不可用。当存储管理员设置这个LUN脱机，这个实例场景通过阵列通信，当撤回访问LUN，不统一的环境发生故障期间用来确定ESXi进行合适的行动，应该注意的是当全部存储发生故障，可能生成永久磁盘丢失的情况，在阵列和ESXi主机之间没有通信的可能，这个状态通过ESXi主机来识别当做所有路径断开（APD）。

重要的是认识到接下来的设置只应用PDL环境，而不是APD环境，在我们的故障环境中，我们将论证两种环境的不同行为。

为了允许vSphere HA响应PDL环境，vSphere U1里介绍了两个高级设置，第

一个主机设置是disk.terminateVMOnPDL Default。这个设置在

/etc/vmware/settings里配置，由默认设置为―True‖，注意这是每主机的设置，主机需要重新启动这个设置才生效，当数据存储进入了PDL状态，这个设置确保

杀掉虚拟机。PDL环境中一旦杀掉虚拟机，数据存储就磁盘I/O初始化。如果

虚拟机的文件没有在同一个数据存储上，并且PDL存在其中一个数据存储上，

通过HA虚拟机可能不会重新启动，vSphere 5.1里修正了这个问题，为了确保PDL环境中能通过HA进行迁移，我们建议设置

disk.terminateVMonPDL Default 为―True‖，并将虚拟机文件放置单个数据存储上，请注意当数据存储没有产生I/O，虚拟机只是被杀掉，虚拟机可以恢复活动的。正在运行密集内存负载而数据存储没有产生I/O的虚拟机可能恢复活动状态。

第二个设置是vSphere HA的高级设置，称之为das.maskCleanShutdown Enabled。vSphere 5.0 U1中介绍了这个设置，默认是禁用的，需要设置你的HA群集为

―True‖，这个设置允许HA触发PDL环境中自动杀掉的虚拟机重启，HA不能区分虚拟机是被PDL杀掉还是被管理员关闭，设置标记―True‖假定是前者。注意在APD期间用户关机将被行为标记

我们建议设置das.maskCleanShutdown Enabled 为―True‖，为了限制PDL环境数

据存储上虚拟机的停机时间，当das.maskCleanShutdown Enabled没有设置―True‖，PDL环境也存在，disk.terminateVMonPDL Default被设置为―True‖,杀掉虚拟机后，虚拟机重新启动不会发生，HA将假定虚拟机是管理员断电（或者关闭）。

vSphere DRS

vSphere DRS在很多环境中用来分配群集负载。vSphere DRS提供很多其它功能来帮助扩展环境，我们建议开启vSphere DRS允许群集的主机之间的负载平衡，vSphere DRS 负载平衡计算是基于CPU和内存的使用情况，同样，关于存储和

网络资源利用率和流量也必须小心照顾，为了避免扩展群集环境中非预期的存

储和网络流量开销，我们建议执行vSphere DRS关联规则来允许合乎逻辑和可预测的分开虚拟机，这将帮我们提高可用性，负责架构服务的AD，DNS虚拟机，这将有助于确保这些服务跨站点分离。

vSphere DRS关联规则还帮助阻止存储不要的停机时间和网络流量过载，我们建议调整vSphere VM-Host的存储配置关联规则，我们的意思设置VM-Host关联规则，这样虚拟机偏向于运行在同一站点的主机上，同时数据存储阵列的主要读/写节点进行配置。例如，我们的测试配置中，虚拟机存储在Frimley-01数据存储设置了VM-Host关联规则是偏向于Frimley数据中心的主机。这样确保了站点间网络连接发生故障时，虚拟机不会断开与存储系统的连接。VM-Host关联规则配置取决于这些建议，从而确保虚拟机呆在主数据存储本地。巧合的是所有的读

I/O来自于它们站点的本地虚拟机，注意：不同存储厂商使用不同的技术来描述LUN到阵列或者控制器的关系，在这个章节我们将使用通用术语

―Storage Site Affinity‖，―Storage Site Affinity‖意味着偏向于LUN 的本地读写访问。

我们建议执行―should rules‖，这些在HA发生故障时都能够被冲突，服务的可用性应该一直胜过性能。在―Must rule‖情况下，HA将不会同设置的规则冲突，在站点或主机发生故障时它可能导致服务中断。一个数据中心发生故障的场景，―Must rules‖将使它不可能为vSphere HA重启虚拟机，同时他们没有关联规则请求来允许虚拟机在其它数据中心的主机上开启。vSphere DRS同HA的沟通这些规则，把他们存储在允许启动的兼容性列表。vSphere DRS还有一个注意的地方，在某些情况下，如果大量的主机不平衡和激进建议设置，会与―Should rule‖冲突。尽管非常罕见，我们建议监控对你的工作负载产生可用性和性能有冲突的规则。

我们建议手工定义创建站点的一组主机，基于数据存储关联规则添加虚拟机到这个站点上，在我们的场景中只有限制数量的虚拟机被发布，我们建议使用vCenter Orchestrator或者Power CLI自动定义站点关联规则，如果没有选择自动，我们推荐使用一个通用的命名惯例，简化创建这些组，我们建议这些组定期验证，来确保属于组的虚拟机有正确的站点关联规则。

接下来的截屏描述了用于该场景的配置，在第一张截图中，所有的虚拟机应保持在Bluefin本地的虚拟机组内。

图164：DRS组-虚拟机

接下来，创建一个本地包括所有主机的Bluefin 主机组。

图165：DRS组-主机

最终，Bluefin本地创建好了一个新的规则，定义了连接到主机组虚拟机组―should run on‖规则

图166：VM-Host规则

两边本地都应该完成，直接导致了4个组合2个规则。

图167：结果-管理规则

调整关联性规则冲突

DRS分配了高优先级来调整关联性规则冲突，在调用期间，DRS的主要目标是调整任何冲突和为群集主机组主机清单上虚拟机生成迁移建议，这些移动的优先级比负载平衡高，所以将在负载平衡之前开始虚拟机迁移。

DRS 默认每5分钟调用一次，但是如果群集检测到更改DRS还是会触发，当主机重新连接上群集，DRS被调用，并生成建议来调整任何识别的冲突。我们的测试展示了在主机重新连接群集后的30秒内DRS生成建议来调整关联规则冲突。注意DRS限制了vMotion网络的总吞吐量，这意味着在所有的管理规则冲突被调整之前，可能需要多次调用。

vSphere Storage DRS

当定义的性能或者容量阈值超出，Storage DRS从管理员角度和虚拟机、磁盘平衡来考虑启用激进的单一数据存储，存储DRS确保你的工作负载中足够的磁盘资源可用，我们建议开启存储DRS。

存储DRS使用存储vMotion在数据存储群集内的数据存储上来迁移虚拟机，由于底层扩展存储系统使用同步复制，一个迁移或者一系列迁移将对重复流量有影响，导致在移动磁盘的时候出现网络资源争用，可能引起虚拟机临时不可用。从站点的角度，如果虚拟机不一起迁移它们的磁盘，在同一访问配置中迁移漫游数据存储还可能导致额外的I/O延迟。例如，如果Frimley主机上的虚拟机有磁盘迁移到Bluefin的数据存储上，它将继续操作，但可能降低性能。虚拟机读取磁盘受制于站点B读取虚拟iSCSI IP延迟的增加和受制于站点间的延迟。

当迁移发生时能够控制，我们建议配置存储DRS手工模式，这允许人工验证每个建议，并允许在非峰值时间应用建议，同时获得操作的益处和初始化位置的效率。

我们建议基于存储配置遵从存储站点关联来创建数据存储群集，站点A关联的数据存储不能同站点B的数据存储相互混合。这将允许操作的一致性和缓和DRS VM-Host关联规则的创建和持续。因此当数据存储群集和定义存储站点关

联边界之间的虚拟机被迁移，建议来保证所有的vSphere DRS VM-Host关联规

则被更新。我们建议调整数据存储群集和VM-Host关联规则的命名约定，以简

化配置和管理流程。

命名约定在我们的测试中用来给数据存储和数据存储群集一个特别的站点名称，从而简化站点上发布虚拟机的DRS主机关联性。在我们的站点―Bluefin‖和

―Frimley‖里的站点特指存储见下图。请注意vCenter映射功能不能用来查看存储当前的站点关联，同时也不能显示数据存储群集的对象。

图168：数据存储群集架构

第三章故障排错

这里有许多在群集系统故障场景没有介绍，但在一个合理的架构环境中，HA，DRS和存储子系统不会发生这些情况，我们将不解决没有影响力的故障，例如

单根网线的故障。它们在你选择存储厂商提供的解决方案文档中已经有深入解释。我们将讨论接下来的一些―常见‖的故障场景：

?Frimley数据中心的单台主机故障

?Frimley数据中心的单台主机隔离

?存储分割

?数据中心分割

?Frimley数据中心磁盘柜故障

?Frimley数据中心全存储故障

?Frimley数据中心全计算故障

?Frimley数据中心全计算故障和Bluefine数据中心全存储故障

?Frimley数据中心完全损失

我们还将在测试场景中指定设置错误的配置。这些设置会导致虚拟机的可用性和可恢复性发生故障，因此理解错误配置后的影响非常重要。

?VM-Host管理规则配置错误

?心跳数据存储配置错误

?隔离地址配置错误

?永久设备丢失配置错误

?vCenter Server脑裂场景

所有这些厂家都被测试，下面是我们每个方案的结果和可能的建议（如适用）。Frimley 数据中心单台主机故障

在这个场景中，我们通过在Frimley数据中心拔掉运行主机电源线缆来模拟完成了主机故障。这个场景描述如下图。

图169：单个主机故障

结果

通过vSphere HA所有的虚拟机成功启动，但是没有根据VM-Host关联性规则启动。

解释

如果一台主机发生故障，群集的HA主节点检测到故障，从此该主机不再收到

网络心跳。在主节点检测到网络心跳丢失，它将开始监控数据存储的心跳，自从主机完全发生故障，它不能产生数据存储心跳，这些通过HA 主节点检测。在

这段时间，ping故障主机的管理地址，再一次检测完成。如果所有的检测返回都是不成功的，主节点将申明丢失的主机死亡，再主节点与主机失去联系之前，

将尝试重新启动故障主机上所有受保护的虚拟机。

vSphere DRS VM- Host管理规则定义群集级别时―shoud rules‖（的成员虚拟机应

在组），意味着虚拟机可能在其它数据中心的主机上重启。在我们的测试中，我们见证这一行为多次，虚拟机在Bluefin数据中心群集中任一可用的主机上启动。vSphere DRS在首次调用时将尝试调整任何冲突的关联规则，同时按照他们的关联规则排队自动迁移置入虚拟机。我们建议手工调用vSphere DRS来确保所有的虚拟机在正确的主机上，尽可能避免性能降低和减少可用性以及可能的二次故障。在我们的场景中，虚拟机置入位置丢失将导致增加延迟，虚拟机将访问其它地方的存储。下面的截图描述了怎样在vCenter群集对象的DRS项中手工运行DRS。

图170：手工触发DRS

Frimley 数据中心主机隔离故障

在这个场景中，我们通过断开单个主机的所有的网络连接将其从Frimley数据中心隔离，存储网络不受影响。

图171：单个主机隔离

结果

虚拟机保持运行，隔离响应设置的是―保持电源开启‖

解释

当主机被隔离，通过HA 主节点隔离被检测到，同时该主机不再接受网络心跳。当主节点检测到网络心跳丢失，它将开始监控数据存储心跳，自此主机被隔离，它将在第二次HA检测机制时产生数据存储心跳，检测到有效的主机心跳将允许HA主节点来决定主机在运行中但网络隔离。依靠隔离响应配置，受影响的主机可能选择断电或者关闭虚拟机，或者依次让虚拟机通电。主机被隔离后30秒触发隔离响应。

我们建议调整隔离来响应商业需求和物理约束。从最佳实践观点来说，―保持电源开启‖是主流环境的推荐隔离响应。在合理的架构环境中隔离主机是非常罕见的事件，冗余是非常主流的设计，在使用基于网络存储协议的环境中，例如iSCSI 和NFS，建议隔离响应是―关闭电源‖，在这些环境中，它更可能是网络中断引起的主机隔离还将影响主机与数据存储的通信。

如果隔离响应推荐选择―保持开启电源―，当隔离响应被触发，将通过群集上的HA节点重新启动虚拟机。vSphere DRS VM-host管理规则定义了群集级别时

―should rules‖，意味着虚拟机可能在其它的数据中心的主机上重启，在我们的测试中，我们见证过这一行为多次，接下来的主机隔离和群集响应关联，我们建议手工调用vSphere DRS确保所有的虚拟机在合适的主机上，尽可能避免性能降低和无法置入虚拟机。在我们的场景中，无法置入虚拟机将导致增加延迟，同时虚拟机将访问其它地方的存储。

存储分割

在这个场景中，模拟数据中心之间的存储网络发生故障，描述如下图。

图172：存储分割

结果

虚拟机没有受到影响继续运行

解释

每个LUN有定义关联存储站点，vSphere DRS规则与这些关联一致。由于这些配置，没有虚拟机受到影响，同时它们的站点运行的存储保持可用。

如果任何原因虚拟机的关联规则发生冲突，Frimley数据中心内主机上运行的虚拟机，它们的磁盘属于Bluefin数据中心的数据存储，在站点间的存储分割，数据存储在所有路径断开（APC）的条件下，它不能成功的产生I/O。当HA主仍收到来自于群集其它主机的心跳，它将不会有任何行动：它们站点有冲突的任何虚拟机将不同通过HA重新启动，除非手动关闭虚拟机。

我们建议监控vSphere DRS规则的兼容性来避免APD场景中不必要的停机时间，尽管vSphere DRS每分钟调用一次，它不会保证每次调用期间所有的冲突都被解决。因此，建议严格的监控来允许快速识别异常同时阻止不必要的当机时间。

数据中心分割

在这个场景中，我们完全将Frimley数据中心和Bluefin数据中心隔离，描述如下图。

图173：数据中心分割

结果

虚拟机保持运行无影响

解释

在这个场景中，两个数据中心彼此完全隔离，这个场景类似于存储部分和主机部分隔离。发生这样的故障虚拟机不受影响。当vSphere DRS规则正确的执行，没有规则冲突。在群集分割期间HA按照逻辑的过程来决定哪些虚拟机需要重新启动：Frimley数据中心上运行的HA主节点检测到Bluefin数据中心的全部主机不可达，HA主节点首先检测没有接受到网络心跳。在此之后，它将证实是否有任何存储心跳生成；这个检查将检测存储心跳，同时站点之间存储连接发生故障，每个站点的数据存储心跳只更新本地的。虚拟机将关联剩下的正在运行的主机。接下来，HA将证实是否接受重启，因为数据存储的读写版本处于Bluefin 无法访问Frimley的主机，所以不要尝试开启其它站点丢失的虚拟机。

同样的，Bluefin 数据中心的ESXi主机将检测有没有主节点可用，并初始化选举主节点的过程，在新的主节点选出后，它将试图发现发生故障之前运行着的虚拟机，尝试重新启动它们。当所有关联到Bluefin的虚拟机仍运行在Bluefine数据中心，就不需要重启。只有关联到Frimley的虚拟机不可用，vSphere HA不会重启这些虚拟机，因为虚拟机所在的数据存储关联到Frimley，而在Bluefin数据中心不可用。

如果主机关联规则冲突，例如，默认，行为发生改变，虚拟机运行的存储没有定义的读写。我们故意配置冲突关联规则来记录这个行为：我们手工从Frimley 迁移虚拟机到Bluefin，这样做之后，我们创建了一个情况，虚拟机运行在Bluefin 的主机上运行，但是可以访问Frimley 数据中心的数据存储，当数据中心被隔离，接下来的顺序是我们见证的：

1. 虚拟机关联到Frimley但在Bluefin上不能到达数据存储。这导致了虚拟机不能磁盘读写

2. 在Frimley数据中心，虚拟机通过vSphere HA重新启动，同时Frimley数据中心的主节点不知道Bluefin数据中心运行的实例

3. 由于数据存储只有Frimley数据中心的主机能使用，Frimley数据中心的主机能获取锁定的虚拟机文件，并能够开启虚拟机

4. 创建的这个场景，同一个虚拟机在两个数据中心上运行。

图174：上电顺序

这是为什么？

?运行的虚拟机主机网络心跳丢失，因为两个站点之间没有管理网络连接?数据存储心跳丢失，因为两个站点之间没有存储网络连接

?ping运行了虚拟机的主机的管理地址失败，因为两个站点之间没有管理网络连接

?Frimley数据中心本地的主节点知道发生故障之前虚拟机已经开启，因为它不能再发生故障之后同Bluefin数据中心内的主机上的虚拟机通信?通过Bluefin数据中心的主机判断数据存储全部路径断开，同样的，没有采取任何行动。正如之前解释的，只有PDL条件下虚拟机被自动杀掉。

当两个站点之间的连接被修复，经典的―脑裂‖场景就存在了，在短时间内，两个同样MAC地址的虚拟机副本在网络上被激活。但是，它将访问虚拟机文件，HA 也认识到这一点，只要被检测到，所有属于虚拟机的副本不会访问被杀掉的虚拟机，如下图所示。

图175：锁定文件日志信息

在这个例子中，如果站点关联规则维护得比较合理，不必要的停机时间应该等于虚拟机的重启时间，而这个例子不是。所以我们建议更进一步监控vSphere DRS 规则与数据存储站点的关联来阻止不必要的停机时间。

Frimley数据中心磁盘柜故障

在这个场景中，Frimley数据中心的一个磁盘柜发生故障。在存储A 上的Frimley01和Frimley02受到影响。

图176：磁盘柜故障