vmware的APD和PDL详细解析

APD和PDL的情形在虚拟化运维中，是相对来说比较棘手的问题，需要谨慎处理。

全部路径异常 (APD)： • 数据存储在“存储”视图中显示为不可用。 • 存储适配器指示设备的“操作状态”为“不活动或出错”

永久设备丢失 (PDL) • 数据存储在“存储”视图中显示为不可用 • 存储适配器指示设备的“操作状态”为“通信中断”

vmware的APD和PDL详细解析

APD解析： 在 vSphere 4.x 中，如果设备的所有路径都出现故障,则将发生全部路径异常 (APD) 状况。 由于没有迹象表明这是永久性还是暂时性设备丢失，ESXi 主机会保持重新尝试建立连接。 当从 ESXi/ESX 主机错误取消提供 LUN 时，通常会发生 APD 状况。 ESXi/ESX 主机仍然认为该设备可用，将无限期重新尝试所有的 SCSI 命令。 这会对管理代理产生影响，因为在重新可访问该设备之前不会对其命令作出响应。 这将导致 ESXi/ESX 主机在 vCenter Server 中变得不可访问/无响应。

在 vSphere 5.x/6.x 中，已在永久丢失 (PDL) 的设备和由于未知原因而发生全部路径异常 (APD) 这一暂时性问题的设备之间进行了明确的区分。

例如，在 VMkernel 日志中，如果存储设备将 SCSI 感知代码 H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 或 Logical Unit Not Supported 记录到 ESXi 5.x/6.x 主机中，则表明 ESXi 主机永久不可访问该设备，或者该设备处于永久设备丢失 (PDL) 状态。 ESXi 主机不再尝试重新建立连接或向该设备发出命令。

遇到不可恢复的硬件错误的设备也会被识别为正处于永久设备丢失 (PDL) 状态。

如果未从设备返回 PDL SCSI 感知代码（当无法联系存储阵列，或者所具有的存储阵列未返回受支持的 PDL SCSI 代码时），则该设备处于全部路径异常 (APD) 状态，ESXi 主机将继续发送 I/O 请求，直到主机收到响应。

由于 ESXi 主机无法确定设备丢失是永久性 (PDL) 还是暂时性 (APD) 的，因此它会无限期重试 SCSI I/O，包括： • 用户领域 I/O（hostd 管理代理） • 虚拟机客户机 I/O

注意： 如果从客户机发出 I/O 请求，则操作系统将超时并中止 I/O。 由于 APD 状况的性质，没有简便的方法进行恢复。 • 需要在存储阵列/结构层来解决 APD 状况，才能还原与主机的连接。 • 所有受影响的 ESXi 主机都可能需要重新引导，以移除到处于 APD 状态的受影响设备的任何残留引用。 注意： • 无法对未受影响的虚拟机执行 vMotion 迁移，因为管理代理可能会受到 APD 状况的影响，且 ESXi 主机可能变为非受管状态。 因此，重新引导受影响的 ESXi 主机会强制中断该主机上所有未受影响的虚拟机。 • vSphere 6.0 和更高版本随 vSphere HA 一起引入了强大的新功能，称为虚拟机组件保护 (VMCP)。VMCP 可防止虚拟机出现与存储相关的事件，尤其是永久设备丢失 (PDL) 和全部路径异常 (APD) 事件。

注意：发生 APD 事件时，连接到 ESXi 的 LUN 可能会在 LUN 路径恢复后仍无法访问。
即使存储路径恢复后，140 秒的 APD 超时时间可能仍会到期。
在 /var/log/vmkernel.log 文件中，您会依次遇到以下事件：

    设备进入 APD 状态。
    设备退出 APD 状态。
    由于超时或未找到或忙碌，设备上的检测信号恢复和文件系统操作失败。
    尽管设备之前已退出 APD 状态，但是“APD 超时”仍会到期。

此状况与以下一个或多个行为有关：

    虚拟机无法访问。
    主机无响应。
    即使路径已恢复且可用，存储仍处于脱机状态。
    即使虚拟机仍在数据存储上，vSphere Client 也不显示数据存储。

以下一个或多个事件可能会触发 APD 事件：

    上游光纤通道或以太网交换链路失败会影响存储阵列的所有路径
    存储阵列故障或重新引导
    存储阵列固件更新（某些供应商）

当然并非所有 APD 事件均会出现此行为。 大多数情况下，LUN 和数据存储会按预期正常退出 APD 超时状况。 原因： 出现此问题的原因是 APD 处理时发生故障。 出现此问题时，LUN 路径在 APD 事件期间可用且处于联机状态，但 APD 定时器会继续计数，直到 LUN 进入“APD 超时”状态。 初始 APD 事件后，只要活动工作负载与数据存储关联，该数据存储将无法访问。

遇到此问题时，必须终止虚拟机才能恢复数据存储。HA（如果已启用）应在其他主机上恢复这些虚拟机。如果必须重新启动管理代理，则暂时将无法通过 vCenter Server 管理主机。

计划内 PDL 与计划外 PDL 解析： 当试图移除向 ESXi 主机提供的设备时，将发生计划内 PDL。 必须首先卸载数据存储，然后分离设备，这样才能在存储阵列上取消提供该存储设备。 有关如何在 ESXi 5.x 中正确取消提供 LUN 的详细信息，请参见 如何从ESXi 主机卸载 LUN 或分离数据存储设备 (2072353) 。

如果意外从存储阵列取消提供存储设备，而未在 ESXi 主机上执行卸载和分离，则将发生计划外 PDL。 在 ESXi 5.5 中，VMware 提供了一种名为“自动移除”的功能，以便在计划外 PDL 期间自动移除设备。 有关详细信息，请参见 PDL AutoRemove feature in vSphere 5.5 (2059622)。

要清除计划外 PDL，请执行以下操作：

1. 数据存储中所有运行的虚拟机必须关闭电源并从 vCenter Server 中取消注册。
2. 从 vSphere Client 中，转到 ESXi 主机的配置选项卡，然后单击存储。
3. 右键单击要移除的数据存储，然后单击卸载。

此时将显示确认卸载数据存储窗口。 如果符合必备条件，则会显示确定按钮。

如果您在卸载 LUN 时看到以下错误：

在 vCenter Server <name_of_vCenter> 上为对象 <name_of_LUN> 调用数据存储刷新失败 (Call datastore refresh for object <name_of_LUN> on vCenter server <name_of_vCenter> failed)

您可能提供了快照 LUN。 要解决此问题，请在阵列端移除该快照 LUN。

1. 在该 LUN 对其可见的所有 ESXi 主机上执行重新扫描。

注意： 如果存在对该设备或挂起 I/O 的活动引用，ESXi 主机在重新扫描后仍会列出该设备。 检查可能仍具有对该设备或数据存储的活动引用的虚拟机、模板、ISO 映像、软盘映像和裸设备映射。

1. 如果该 LUN 仍在使用中且再次可用，请转到每个主机，右键单击该 LUN，然后单击挂载。

注意： 计划外 PDL 的一个可能原因是 LUN 的空间不足，从而导致其变得无法访问。

Vc 6.0解决方案： 如果启用虚拟机组件保护 (VMCP)，vSphere HA 可以检测到数据存储可访问性故障，并为受影响的虚拟机提供自动恢复。 VMCP 可防止发生数据存储可访问性故障，这些故障可能会影响 vSphere HA 群集中主机上正在运行的虚拟机。当发生数据存储可访问性故障时，受影响的主机无法再访问特定数据存储的存储路径。您可以确定 vSphere HA 将对此类故障作出的响应，从创建事件警报到虚拟机在其他主机上重新启动。 注： 使用虚拟机组件保护功能时，ESXi 主机的版本必须为 6.0 或更高版本。 故障类型 存在两种类型的数据存储可访问性故障： PDL PDL（永久设备丢失）是在存储设备报告主机无法再访问数据存储时发生的不可恢复的可访问性丢失。如果不关闭虚拟机的电源，此状况将无法恢复。 APD APD（全部路径异常）表示暂时性或未知的可访问性丢失，或 I/O 处理中的任何其他未识别的延迟。此类型的可访问性问题是可恢复的。

配置 VMCP 在 vSphere Web Client 中配置虚拟机组件保护。转到配置选项卡并单击 vSphere 可用性和编辑。在故障和响应下，可以选择处于 PDL 状态的数据存储或处于 APD 状态的数据存储。您可选择的存储保护级别以及可用的虚拟机修复操作根据数据库可访问性故障的类型而异。 PDL 故障 在处于 PDL 状态的数据存储下，可以选择发布事件或关闭虚拟机电源再重新启动虚拟机。 APD 故障 响应 APD 事件是更加复杂的，相应地配置是更加精细的。可以选择发布事件、关闭虚拟机电源再重新启动虚拟机 - 保守的重新启动策略或关闭虚拟机电源再重新启动虚拟机 - 激进的重新启动策略

针对APD和PDL的时间调度有几个周期，分别是：

APD说明：

0s - 此时APD会激活时间计数器；

140s APD - ESXi主机会生命APDTimeout然后会针对故障设备执行NON VM I/O激活Fast Fail动作。这个Timeout的周期可以被修改；

140-320s APD - APD Timeout的时间到达之后，这之前VMCP的Timeout已经到达。如果故障存储设备在这之前恢复正常，则可以通过对Response for APD recovery after APD timeout配置选项的配置来确保VM不会被强行重置；

320s APD - VMCP Timeout，同时激活Response for Datastore with All Paths Down（APD）；

PDL说明：

0s PDL - VMs会立刻在正常ESXi主机上重新启动；

VMCP的Timeout时间会是320秒，里面包含了APD的默认140秒。VMCP组件的配置可以通过勾选vSphereHA设定选项中Protect against Storage Connectivity Loss选项来激活；

针对VMCP的配置选项如下：

VM restartpriority - VM重启优先级设定；

Response for Host Isolation - 主机被隔离时的响应方式；

Response for Datastore with Permanent Device Losss（PDL） - 三个配置选项，分别是Disabled、Issue events（不激活处理动作，只发通知讯息）、Power off and restart VMs（针对故障Vms尝试做重启动作）；

Response for Datastore with All Path Down（APD） - 四个配置选项，分别是Disabled、Issue events（不激活处理动作，只发通知讯息）、Power off and restart（conservative）（受影响的Vms会被Kill掉，然后在连接正常的ESXi主机上重启。如果故障主机无法与Master主机通讯则将无法激活）、Power off and restart VMs（aggressive）（受影响的Vms会被Kill掉，无论是否有主机可以通过重启承载这些Vms。不论Master主机是否存在，是否能和其它主机通讯以及是否有足够的资源）；

Response for APD recovery after APD timeout - 这个选项表示在APDTimeout（140s）之后VMCP Timeout之前（320s）存储设备恢复正常时的处理方式。它有2个可用配置选项，分别是：Disabled、Reset VMs（Vms会被强行于APD发生前所在主机重置）；

注： 如果禁用“主机监控”或“虚拟机重新启动优先级”设置，VMCP 将无法执行虚拟机重新启动。但是，仍可监控存储运行状况，且可发布事件。

vmware的APD和PDL详细解析

vmware的APD和PDL详细解析

APD的解决方案补充： 此问题已在 ESXi 6.0 Update 1（可从 VMware Downloads 获得）中得到解决。 有关详细信息，请参见 VMware ESXi 6.0 Update 1 Release Notes。

如果无法升级，没有其他措施可以保证在 APD 事件期间不会遇到此问题。 但是，出现此问题时有两种权宜措施可以恢复生产。

要临时解决此问题，请使用以下选项之一：

1、执行终止 LUN 的所有未完成 I/O 的过程。 有关非计划 PDL 的信息，请参见 Cannot remount a datastore after an unplanned permanent device loss (PDL) (2014155)。

2、 注意： 可能还需要重新启动 ESXi 管理代理。 有关详细信息，请参见 Restarting the Management agents on an ESXi or ESX host (1003490)。

3、重新引导卷处于“APD 超时”状态的所有主机。

其他补充： 脑裂 当群集发生裂脑的状况时候，因为无法进行任何沟通而误会对方无法运作，所以主与备份服务器都会启动浮动IP和相关服务，此时若两部服务器对外连线亦未短线，那么势必导致有些使用者存取的是主要服务器，另外一些则存取备份服务器的情形。此外，如果两部服务器共享一个存储装置，发生裂脑时两部服务器会同时挂载该存储装置，亦同时存取相同的档案，因此若共享存储装备缺乏良好的锁定机制，更可能使得存储装置上的档案因同时读写而损坏。更有可能导致硬盘中写入不一致的信息，导致后期数据错误，甚至整个数据库损坏，后果不堪设想。 对付HA系统“裂脑”的对策，目前我所了解的大概有以下几条： 1）添加冗余的心跳线，例如双线条线。尽量减少“裂脑”发生机会。 2）启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。 3）设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端，不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。