第四章 重新启动虚拟机
在前面的章节中，我们描述了大多是比较基本的HA的概念。我们已经向您展示了vSphere5.0引入的多种机制以及增加了vSphereHA的弹性和可靠性，HA的可靠性在这节中主要谈到虚拟机的重新启动，这仍然是HA的首要任务。
当主机的状态改变，HA将会响应，或者更好的说，当一个或者多个虚拟机状态已经改变，大多数情况下，HA会回应故障，最常见的如下：
-
主机出现故障
-
主机隔离
-
虚拟机操作故障
根据故障的不同类型，以及对主机的依赖于作用，过程会略有不同，过程不同就会有不同的恢复时间。因为有许多不同的情况，也不能全部都介绍到，所以我们将尝试描述最常见的场景和常可能出现的时间点。
在我们深入到不同的故障场景时，我们会拿vSphere 5.0之前的版本和vSphere 5.0的重启优先级和重试来进行对比，这将适合我们描述的每一种情况。
在vSphere 5.0之前，当多个虚拟机需要重新启动时，HA的虚拟机启动优先级才激活，这里来说，本身没有改变，HA同样会配置虚拟机的优先级，但是在vSphere 5.0中，引入了一种新的类型的虚拟机：代理虚拟机，这些虚拟机为其它虚拟机提供服务，因此，在重新启动虚拟机时可以优先考虑它们，一个很好的例子是代理虚拟机可以为vShield Endpoint虚拟机提供服务，这些代理虚拟机被认为是最高优先级的虚拟机。
优先级是以主机为单位的，而非全局，每个主机接收到重新启动的需求时，首先启动最高优先级的虚拟机，如果最高优先级的主机出现故障，它会延迟重试，然而，在此期间，HA会继续开启剩余的虚拟机，请记住，某些虚拟机可能依赖于代理虚拟机，你应该记录哪些虚拟机依赖于代理虚拟机，并记录下当自动重启代理服务器失败，开启代理服务的正确的顺序。
基本设计原则
虚拟机可以依赖代理虚拟机或者其它虚拟机的可用性，尽管HA将尽最大的努力使得所有的虚拟机按照正确的顺序启动，但不能绝对保证。
除了代理虚拟机，HA还优先启动辅助FT的虚拟机，我们列出完整的虚拟机重新启动的顺序如下：
-
代理虚拟机
-
辅助FT的虚拟机
-
优先级最高的虚拟机
-
优先级居中的虚拟机
-
优先级最低的虚拟机
应该指出，如果需要相当数量的代理虚拟机，HA不会在一台主机上放置所有的虚拟机。
现在，我们已经简要的介绍了它，我们还要解决“重启重试”和“并行重启”，这些或多或少的决定了虚拟机出现故障或者主机隔离情况下重启的时间。
重启尝试
在vCenter 2.5 U4版本时候，虚拟机重启重试的次数在”das.maxvmrestartcount”选项下可以修改，默认是5次，在vCenter 2.5 U4之前的版本中，HA会一直永远尝试重启，这样会带来一些问题，这会出现多个虚拟机同时在多台主机上注册，导致混乱和不一致的情况，详情见VMware KB（http://kb.vmware.com/kb/1009625）
提示
在vSphere 5.0之前的版本中，”das.maxvmrestartcount”的选项中不包括重启重试次数的配置，意思是总计重启6次，和vSphere 5.0的默认值一样。
HA会在群集上的其它主机上，启动受影响的主机，如果在主机上启动失败，那么重新启动的计数增加1，在我们开始确认时间前，可以把T0记录成主机第一次尝试启动虚拟机，这个故障时间间隔为30S，虚拟机重试启动的总体的时间还要取决于失败的次数，我们将在本章讨论。
正如我们所说，vSphere之前默认启动5次，加上第一次的启动失败，总计6次。每次尝试重启有特定的时间，接下来的清单将阐明这个概念，清单中的‘m’代表分钟。
-
T0 ——首次启动
-
T2m——第一次重启重试
-
T6m——第二次重启重试
-
T14m——第三次重启重试
-
T30m——第四次重启重试
图17：高可用重启时间线
图17中清楚的描绘到，如果多次尝试不成功，直到一个成功的启动可能需要约30分钟，这一点来说，没有确切的科学依据，例如，在首次重启和第一次重启直接，有一个2分钟的等待时间，而这个时间也有可能是2分钟+8秒钟，另一个重要的事实，我们一直强调的是如果没有master的相互协调，多个虚拟机试图重新启动，而且还要保留自己的启动队列。在vSphere 5.0 U1中，多个master会尝试重新启动虚拟机，虽然只有一个会成功，它仍然可能会改变时间线。
让我们在这样一个场景中举个例子来阐明它，虚拟机在重启队列中时master发生故障：
群集：4个主机（esxi01，esxi02，esxi03，esxi04）
Master：esxi01
主机esxi02上运行着一台叫VM01的虚拟机，现在它发生了故障，master esxi01尝试重启启动该虚拟机，但是失败，它将会尝试重新启动该虚拟机5次，很不走运，在进行到第四次的时候，master也出现了故障，esxi03被选举出来成为新的master，它也尝试重新启动vm01，如果第1次重启失败，它会再重启4次，如果包括第1此重启就是5次了。
不过注意，如果重新启动的次数达到了默认值次数（5次）还是没有成功，那么虚拟机就可能再也不会触发重新启动了。
当涉及到重新启动时，一件事非常重要，主机重启尝试的并发是32个，如果有33个虚拟机需要重启，无论第32次是成功还是失败，都需要完成重启的次数，第33台虚拟机才能触发重启尝试。
现在再来个例子，如果是32个虚拟机是个低优先级，而第33个虚拟机是一个高优先级的，那么直到高优先级的虚拟机完成重启尝试，低优先级的虚拟机才能进行重启尝试，而理论上，如果重启尝试失败，低优先级的虚拟机应该在高优先级的虚拟机之前启动。
当虚拟机的位置安排好后，重新启动的优先级是会按照设定的规则来的，高优先级的虚拟机将首先有权利获取可用资源。
基本设计原则
配置虚拟机重新启动优先级是不能保证在这个顺序，实际上虚拟机的重新启动。确保合适的位置启动合适的服务以及确定在故障时按照合适的顺序启动。
现在我们知道勒虚拟机重新启动的优先级和重启尝试处理方式，下面来看一个不同的情况。
-
主机发生故障
-
master发现故障
-
slave发生故障
-
主机隔离响应
主机发生故障
在vSphere 5.0中，从一个发生故障的主机上重新启动虚拟机很简单。通过引入master/slave和数据存储心跳，了解到重启过程中发生的变化，以及相应的时间点。master和slave出现故障有明显的区别，我们强调这些是因为两种场景下重新启动的开始时间也不同。例如我们最提到的一个故障，主机发生故障，但这个故障大多数环境中很少发生，因为硬件很少故障。就算它发生，也不会影响过程和时间点。
slave发生故障
对比vSphere5.0之前的版本来说，HA怎样处理主机故障，这是一个相当复杂的场景，
复杂来自于引进了新的心跳机制，事实上，有2种不同的情况，一种心跳数据存储的配置和心跳数据存储没有配置。请记住，这是一个实际的主机故障，时间安排如下：
T0：slave发生故障
T3s：master开始监测数据存储心跳，持续15s
T10s：声明主机不可达，master将在管理网络ping发生故障的主机，这个ping持续5s
T15s：如果没有配置数据存储心跳，主机将声明挂掉
T18s：如果配置了数据存储心跳，主机将被声明挂掉
master监控网络心跳的奴隶。当slave发生故障，心跳不再被master收到的。我们把它定义为T0。 3秒钟后（T3s），master会开始监控数据存储的心跳，它会持续15秒。 在第10s（T10s），当已经没有网络或数据存储的心跳检测到时，主机将被宣布为“不可达的”。master也将开始在第10秒出现故障的主机的管理网络执行ping命令，它会做这样持续5秒钟。如果没有心跳数据存储进行配置，主机在第15s将被宣布“死亡”（T15s），master将在主机上发起重新启动虚拟机。如果已配置心跳数据存储，主机将被宣告死亡，在第18秒（T18s）将开始重新启动。我们认识到这可能会造成困惑，并希望在图18所示的时间轴使得它更容易消化。
图18：slave发生故障重新启动时间节点
master开始重启虚拟机时，过滤掉它认为已经重试失败的虚拟机。在vSphere 5.0 U1之前，master用protectedlist，如果master不知道虚拟机处理保护状态，master不会尝试重新启动它。并且在磁盘开启独占模式后，磁盘状态才只能被master获取。在vSphere 5.0 U1（和以上版本），这个行为被改变了，如果有一个网络分区中多个master试图重启同一个虚拟机，vCenter Server也需要为重启虚拟机提供必要的信息。例如，一个master在存储上锁定了一台虚拟机的文件，同时其它的master也与vCenter Server保持着联系，它们也知道所需的虚拟机的状态信息，在这种情况下，其它master虽然没有存储访问权限，但会根据vCenter Server提供的信息重新启动该锁定虚拟机。
这种机制是为了避免当重新启动虚拟机的分区资源不足而导致虚拟机启动失败，随着这一变化，其它分区的master使用由vCenter Server提供信息重新启动虚拟机的情况会很少发生。
那么留给我们一个问题，master发生故障后会发生什么呢？
Master发生故障
在一个master发生故障的情况下，过程和时间表有所不同，原因是在虚拟机重新启动之前必须要一个master，意思是要在slave之间选举出master，时间表如下
T0—master发生故障
T10s—开始master的选举
T25s—新的master被选举出来、读取protectedlist
T35s—新的master尝试重启protectedlist上所有未启动的虚拟机
slaves 从其它的master接收到网络心跳信号，如果master发生故障，当slave没有接收到网络心跳信号，我们定义为T0。由于每个群集都需要master，slave将启动T10s选举，选举过程需要T25s，在T25s时，新的master读到了protectedlist，这个清单中包含了HA保护的所有的虚拟机，在T35s时，master开始启动清单中没有运行的虚拟机。在图19中的时间轴清楚的描述了这个过程。
图19：master发生故障重启时间轴
除了主机发生故障，还有一个原因会发生重启虚拟机：隔离事件。
隔离响应与检测
在我们讨论关于虚拟机隔离后的时间轴和过程，我们还要讨论隔离响应和隔离检测，当配置HA隔离响应时，第一步就是隔离响应。
隔离响应
隔离响应是， 当主机同网络或者群集内其它主机连接断开时，HA对虚拟机采用的相应措施，这并不意味着整个网络断开，而只是特定的主机的管理网络端口，目前有3种隔离响应方式，“关闭电源”，“保持打开电源”“关机”。隔离响应回答了这样一个问题，当检测到网络隔离主机应该做些什么？，让我们更深入的讨论这三个观点：
-
关闭电源—当发生隔离，所有虚拟机将被关闭电源，直截了当的说，虚拟机的电源线类似于被拔出来了
-
关机—当发生隔离，虚拟机使用VMware tools正常关闭。如果该任务在5分钟内不能成功完成，关闭电源操作马上实行。如果VMware tools未被安装，则立刻执行关闭电源操作。
-
保持打开电源—当主机发生隔离时，虚拟机不变仍处于开机状态
这个设置可以在群集下面的虚拟机选项里进行更改，如图20所示。
图20： 群集默认设置
默认设置的主机隔离响应在过去几年改变了很多次，并且也曾经引起过紊乱。
-
直到ESXi 3.5 U2 / vCenter 2.5 U2 默认隔离响应是“关闭电源”
-
到了ESXi 3.5 U3/ vCenter 2.5 U3 默认隔离响应改为“保持打开电源”
-
到了vSphere 4.0 它被改变成“关机”
-
到了vSphere 5.0 她被改变成“保持打开电源”
请记住，这些变化仅仅适用于新创建的群集，当创建一个新的群集，可能会根据客户的需求变更默认的隔离响应方式，当升级版本的时候，你可能需要注意，很多客户会反馈升级后默认隔离响应变成了”保持打开电源”.
基本设计原则
在升级以前版本的环境之前，确认您验证过的最近实践和默认设置。并记录成文档，包括详细理由，这样其它人也能理解你这样那样配置的原因。
那么就有一个问题，我们应该设置哪个隔离响应方式呢？答案很明显，选择最合适的。我们选择“保持电源打开”是因为它可以减少了发生错误的可能性和停机时间，有一个问题相信大家都有经历过，当管理网络断开，HA触发隔离响应，虚拟机并没有重新启动，在vSphere 5.0版本中，这个问题得到了缓解，HA会确认是否可以尝试重启虚拟机-没有任何理由出现任何停机，除非必要的，它通过master数据存储上的虚拟机文件来验证，当然，独立主机也可以去验证，如果它可以访问数据存储，例如，在一个iscsi存储的环境中，独立主机就不可访问数据存储。
我们认为当管理网络发生的故障与虚拟机生产网络故障有关联时，改变隔离响应的方式非常有用，如果管理网络的故障与虚拟机生产网络故障没有关联，隔离响应会引起不必要的当机时间，同时虚拟机会在没有管理网络的情况下继续在主机上运行。
第二个用处是在关闭电源/关机的场景中，当虚拟机与虚拟机生产网络通信正常，但与存储之间的网络断开，留下来的虚拟机电源还是继续打开的，结果可能生产网络中有两台同样IP地址的虚拟机。
这样我们仍很难判断去选用哪一种隔离响应，接下来的表格可能会提供你一些信息。
表3：隔离响应指南
这里有个问题我们还未曾回答，HA怎么知道哪些已经关闭电源的虚拟机需要触发隔离响应呢？为什么隔离响应比之前版本的HA更可靠呢？在之前的版本中，HA是根据主机最后记录的虚拟机状态来一直尝试重新启动虚拟机。而在vSphere 5.0中，隔离响应首先被触发，隔离主机会检测master是否负责该虚拟机，正如前面提到的，它做这些是为了确认master拥有数据存储上该虚拟机，当隔离响应被触发，隔离的主机将移除“poweron”文件中已经断开电源或者关闭的虚拟机，master将确认哪些虚拟机已经消失，那些需要重启，另外，当隔离响应被触发，它会在“poweredoff”目录下为每个虚拟机建立一个文件，master关闭虚拟机，同时触发隔离响应，这些信息会被master节点读到，当它开始尝试按照顺序重启，只有HA触发虚拟机的关闭的虚拟机才会由HA再次触发重启。
然而，一方面HA增加可靠性，隔离响应也增加了可靠性的考虑，接下来我们描述这一部分。
隔离检测
我们已经解释了什么条件会发生隔离响应事件，当触发隔离响应的时候会发生什么。我们不会广泛的讨论怎样隔离检测，它的机制也非常简单，和之前解释过的心跳类似，这里有两个场景，他们的过程和时间轴不太一样。
-
slave的隔离
-
master的隔离
在我们解释这两种情况下的差异之前，我们需要明确的是一个小的改变不能导致任何一个场景被触发，意思是如果ping成功到达主机或者主机观察选举的流量，master或者slave被选举出来，隔离响应将不被触发，而这正是你想要的，因为这避免了恢复停机所需的时间，当一台主机宣布自己被隔离，观察选举的流量可以声明自己不再隔离。
slave的隔离
相比之前版本的vSphere，隔离检测机制已经发生了翻天覆地的变化，主要区别是，在声明主机隔离之前，HA会触发master选举，在这个时间上，“s”代表秒，下面是vSphere 5.0主机的时间线。
-
T0—slave隔离
-
T10s—slave进入选举状态
-
T25s—slave选举自己为master
-
T25s—slave ping隔离地址
-
T30s—slave声明自己被隔离并且触发隔离响应
vSphere 5.1的时间线略有不同，在声明自己隔离和触发隔离响应之间，有最少30s的延迟。
-
T0—slave隔离
-
T10s—slave进入选举状态
-
T25s—slave选举自己为master
-
T25s—slave ping 隔离地址
-
T30s—slave声明自己隔离
-
T60s—slave触发隔离响应
当隔离响应被触发，不管是5.0还是5.1，HA会为可以访问存储的虚拟机建立一个“power-off”文件，接下来关闭虚拟机，更新主机上的“poweron”文件，power-off文件用来记录HA关闭的虚拟机，这样HA就方便重启它们，当虚拟机启动后，这些power-off文件被删除，HA被暂时禁用。
完成这些操作，master通过“poweron”文件学习到slave被隔离的信息，并基于slave提供的信息重新启动虚拟机。
图21：slave 隔离时间线
master的隔离
在master隔离的情况下，时间线就不会那么复杂，因为它没有选举的过程，在下面这个时间线上，“s“代表秒
-
T0—master隔离
-
T0—master ping隔离地址
-
T5s—master声明自己被隔离
-
T35s—master触发隔离响应
附加检查
在主机声明自己隔离之前，它会ping默认的隔离地址，通常是管理网络的网关，一直ping直到它变成非隔离状态，HA在高级选项设置中可以定义一个或者多个额外的隔离地址，这个高级设置叫做“das.isolationaddress “，它能够减少发生错误的几率，我们推荐增加一个的隔离地址。如果第二管理网络被配置，这个隔离地址应该和第二管理网络在同一个网段，如果需要，你可以配置最多10个额外的隔离地址，第二管理网络也可以是子网。
图22:隔离地址
选择额外隔离地址
许多人会问，什么样的地址适合做额外隔离地址，我们一般推荐隔离地址离主机网络较近，尽量避免IP地址跳转太多，在许多情况下，最合乎逻辑的选择是主机直接连接的物理交换机。基本上，使用管理网络的子网的网关，另一个是路由器或者其它设备的IP地址，或者NFS或者ISCSI共享存储的IP地址也是一个很好的选择。
基本设计原则
选择可靠的第二隔离地址，尽量选择主机和该地址之间的跳数最小。
故障检测时间
一些熟悉vSphere 4.x或者3.x VI的朋友，可能想知道什么是“故障检测时间”，在vSphere 5.0之前的版本中，选项内高级设置的“das.failuredetectiontime”用来设置故障检测时间，而在vSphere 5.0中，它不在是选项内高级设置的一项，当HA被重写时，该功能也被移除，但是vSphere 5.1中，一个类似的概念再次被介绍，同时也是客户希望的一个功能，允许调整网络服务水平协议。
“das.config.fdm.isolationPplicyDelaySec”在vSphere 5.1中被介绍，这个高级功能允许在隔离策略生效前修改等待时间，这个值最低是30s，如果你设置的值少于30s，延迟仍然以30s来计算，我们不推荐在高级选项中修改该值，除非你有个性化需求，通常30s就够用了。
重新启动虚拟机
最重要的一个环节还没有讲解：重新启动虚拟机，我们将用一整节来介绍这个概念，它是vSphere 5.0的又一重大变化。
当master节点和slave节点发生故障时，我们已经以时间的角度来解释了虚拟机重新启动的不同行为。现在，让我们假设一个slave节点发生故障，当master节点声明slave被分区或者隔离，它预先读取主机上”poweron”文件，通过该信息决定哪些虚拟机将会执行重启，这些文件大约每30s执行一次异步读取，如果主机在发生故障前没有被分区或者隔离，那么master将通过缓存数据来判断，发生故障之前虚拟机在哪个主机上运行。
在它尝试重新启动虚拟机之前，master将首先验证需要启动的虚拟机，这个验证使用的保护信息是vCenter Server提供给每个master的，或者如果master不联系vCenter Server，这个信息是保存在protectedlist文件中，如果master不联系vCenter或者没有锁定这个文件，虚拟机将会进行筛选，也就是说，所有虚拟机重启优先级为禁用的都会被筛选出来。
现在HA知道哪些虚拟机应该重新启动，现在是决定虚拟机启动后将放在哪个主机上，HA将通过多种条件来考虑：
-
CPU和内存预留情况，包括虚拟机的开销
-
群集内未预留容量的主机
-
相对于其它虚拟机，重启的优先级
-
虚拟机与主机的兼容性设置
-
虚拟机端口的数量和候选主机上的可用端口数量（分布式交换机）
-
主机上能提供最大的vCPU和虚拟机的数量
-
重启等待时间
-
活动主机是否运行着所需数目的代理虚拟机。（本章开篇有详细提到代理虚拟机）
重启等待时间是指启动虚拟机所需的时间总量，这意味着虚拟机重新启动被分布在不同的master执行，这样可以有效的避免启动风暴和单个主机承担延迟。
如果一个适合虚拟机启动的位置被发现，主机将通告每个目标主机设置该虚拟机需要重新启动，如果启动清单中超过了32个虚拟机，HA将限制启动并发数为32个虚拟机，如果一个虚拟机成功启动，该虚拟机所在的节点将电源状态改变的消息发送给master，master则将该虚拟机从重新启动的清单中移除。
如果无法找到适合虚拟机启动的位置，master将把该虚拟机放置进”待安置名单”，当以下条件发生改变时，再次为该虚拟机找合适的位置。
-
vCenter提供一个新的虚拟机与主机的兼容性清单
-
主机报告它未预留的容量增加了
-
主机加入群集（例如，当一个主机退出维护模式，一个主机被加入群集）
-
检测出一个新的故障，虚拟机不得不进行故障转移
-
虚拟机正在故障转移，出现故障时
也许你会想到DRS，那么当所有这些都失败了，DRS是否会帮助找虚拟机的位置呢？DRS做的，master节点将报告vCenter，虚拟机因为资源不足而没有地方放置，现在的情况，如果启用了DRS功能，这些信息将用于DRS尝试帮助虚拟机找到合适的位置。更深入的描述将在第8章讲解。
最坏的场景：脑裂
在过去的版本中（vSphere 4.1之前），脑裂的场景可能会发生，这一个场景中的脑裂意味着虚拟机将在两台不同的主机上同时开启，这个场景中可能是由于虚拟机使用的共享存储，而隔离响应设置成了”保持打开电源”，这种场景在全网隔离的情况下会发生，可能会导致虚拟机的VMDK文件解锁，HA的功能会打开该虚拟机的电源，同时虚拟机在原主机并未关闭（隔离响应的设置选项是”保持打开电源”），它还存在于原主机的内存中，而另一个锁定了磁盘的主机也被要求重新启动该虚拟机。
vSphere 4.1和vSphere 5.0中带来了多种增强功能，以避免这样的情况。请记住，这种最坏的情况通过在大多数的环境中不太可能发生，如果它发生，HA会依赖”锁定丢失检测”机制缓解这种情况。总之,vSphere 4.0 U2,ESXi已经能检测vmdk锁丢失，并且当数据存储可以再次访问时,锁定将不能重新获得，问题是虚拟机是否应该关闭；HA自动回答”是的”,但是，如果你在发生故障的时候连接ESXi主机，你只看到这个问题。不过HA将会为自动应答生成事件。
如上所述，ESXi 4 U2,这个问题将自动应答，虚拟机从脑裂的场景中恢复将关闭电源。
这个问题依然存在，在一个ISCSI或者NFS隔离的情况下，是应该让虚拟机关闭电源还是开启电源呢？
正如刚刚解释的，当HA检测到脑裂情况，它将自动关闭原始虚拟机的电源，这个过程不是瞬间完成的，因此建议使用隔离响应”关闭电源”或者”保持电源开启”，我们还建议增加心跳的弹性来避免这种情况，我们将在下一章讨论增强管理网络的弹性。
永久设备丢失(Permanent Device Loss)
在vSphere 5.0 U1版本中，将介绍一个增强功能，它允许自动故障转移时，虚拟机继续留在数据存储上，那么它就具有”永久设备丢失（PDL）”的条件，一个”永久设备丢失”条件，它是阵列控制器通过SCSI感测码通ESXi通信，这种情况表明LUN不可用，并且是永久不可用，举个例子，当LUN脱机，这个情况传送到阵列控制器，在发生故障的场景中，该条件被用在不均匀的模式下，当ESXi主机访问LUN被撤回，用来确保ESXi采取合适的行动，应该指出的是当整个存储发生故障，它不可能产生永久设备丢失，同时因为阵列控制器同ESXi主机之美没有通信，这种状态将被ESXi主机鉴别全路径（All Paths Down（APD））的条件
重要的是认识到接下来的设置适用于PDL条件，而非APD条件，在发生故障的场景中，我们将为两种不同的条件演示不同的行为的差异，为了让vSphere 5.0 U1的HA为响应PDL条件，两个高级配置将被介绍，第一个设置是配置主机级别为disk.terminateVMOnPDLDefault，它在/etc/vmware/settings下配置，设置其值为”true”，这是个全局值，这个设置保证当数据存储进入PDL状态时，虚拟机将被杀死，，数据存储上发出磁盘I/O的虚拟机迅速被杀死，在vSphere 5.0 U1中的虚拟机文件跨越了多个存储，而这是不支持的，在vSphere 5.1中，我们也不支持此类虚拟机。
我们建议将diskterminateVMonPDLDefault设置为true。请注意，虚拟机只杀死时发出I/ O的数据存储。如果虚拟机没有发出I/ O的数据存储，那么虚拟机仍然活着。在这种情况下，
运行内存密集型工作负载的虚拟机，而不会发出I / O的数据存储可能保持活跃。需要注意的是，这可能会导致同一个虚拟机，在虚拟机上网络有两个实例。
第二个设置是在vSphere HA高级设置das.maskCleanShutdownEnabled。在vSphere5.0 Update 1的设置，默认是不启用的，这将需要将其设置为“true”，这个设置可以让HA杀死的虚拟机自动由于PDL条件，而自动触发响应而重新启动。这个设置被介绍是因为HA无法区分虚拟机是被PDL杀掉还是管理关闭了电源，通过将其设置为true，你可以告诉HA假设这样的关闭虚拟机是PDL杀掉的，如果设置为true，注意的是在APD期间每个虚拟机关闭电源还会被HA认为触发失败，并将重新启动。（PDL翻译得不太好，后面会再修订下，^v^）
图23：PDL高级设置
