Posted inVMware

VMware vSphereにおけるAPDおよびPDLエラーの識別と対処法：All Paths Down・Permanent Device Lossの違いと解決手順

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

午前2時、電話が振動した。vCenterからのアラートが大量のVMがNot Responding状態になっていることを知らせていた。コンソールを開くと、データストアが黄色に変わり、vmkernelのログがエラーで真っ赤になっていた。これは、会社で8台のESXiホストを持つVMwareクラスタを管理してきた数年間で3回経験したシナリオだ — そして毎回、最初の疑問は必ず同じだった：これはAPDなのかPDLなのか？

この2つの状態は表面上は似て見える — VMのフリーズ、I/Oタイムアウト、ストレージへのアクセス不能 — だが、原因と対処法は全く異なる。2つを混同すると1時間以上の無駄な作業につながり、最悪の場合はデータ損失を招く。

APDとPDLの違い

All Paths Down (APD)

APDはESXiホストからストレージデバイスへの全パス（path）が失われたが、ESXiがそれが一時的なものか永続的なものかをまだ判断できていない状態に発生する。ホストはI/Oキューを保持し続け、リトライを繰り返し、デフォルトの140秒後にデバイスを「APDタイムアウト」状態に設定する。

一般的な原因：

  • FCケーブルの断線、SFPの故障、SANスイッチの突然の再起動
  • iSCSIネットワークの中断（VLANの設定ミス、NICフラップ）
  • 事前通知なしのメンテナンスによるストレージアレイの一時的なオフライン
  • FCスイッチのゾーニング変更

Permanent Device Loss (PDL)

PDLはAPDより一段深刻だ。ストレージアレイがデバイスが存在しないことを確認するSCSIセンスコードを返す — 具体的にはセンスコード0x05/0x25（logical unit not supported）または0x02/0x3a（medium not present）だ。ESXiはこの明確なシグナルを受け取り、即座に判断する：永続的な損失であり、タイムアウトを待つ必要はない。

PDLにつながる状況：

  • LUNがストレージアレイ上で直接削除またはunmapされた
  • ストレージアレイのフェイルオーバーが不完全
  • vSAN上のディスクグループが完全に障害
  • HBAドライバのクラッシュによりカーネルレベルでデバイスがdetachされた

簡単な比較

  • APD：一時的か永続的か不明 — ESXiは140秒待機後タイムアウト状態に移行、VMはハング状態になるが、接続が回復すると自動復旧の可能性あり
  • PDL：SCSIセンスコードにより即座に永続的と確認 — 即時応答、VMはI/Oエラーを受け取り、リカバリには手動介入が必要

APDかPDLかを特定する

推測は禁物だ。影響を受けているESXiホストにSSH接続し、すぐに以下のコマンドを実行する：

# ストレージデバイスへのパス状態を確認
esxcli storage nmp path list | grep -A5 "State"

# vmkernelログでAPD/PDLイベントを検索
grep -i "APD\|PDL\|permanent device\|all paths down" /var/log/vmkernel.log | tail -50

# デバイスの状態を確認
esxcli storage nmp device list

# SCSIセンスコードを確認（PDL判別に重要）
grep -i "H:0x0 D:0x2 P:0x0 Valid sense\|sense data" /var/log/vmkernel.log | tail -20

同時に、vCenterのイベントログを開き、影響を受けているホストでフィルタリングする。APDの場合はesx.problem.storage.apd.startイベントが、PDLの場合はesx.problem.storage.permanentDeviceLoss.setイベントが表示される。どちらが表示されているかですぐに判断できる。

APDへの対処

手順1：物理的な接続を確認する

ソフトウェアを触る前に、まずハードウェアを確認する。CLIでのトラブルシューティングに20分費やした後、データセンターのオペレータが誤ってFCケーブルを抜いていたことに気づいたことがある。高い授業料だった。

# HBAポートの状態を確認
esxcli storage san fc list

# iSCSIの場合、ネットワーク接続を確認
esxcli iscsi adapter list
esxcli iscsi session list

# VMkernelインターフェースからストレージIPにPing
vmkping -I vmk1 192.168.10.50

手順2：ストレージアダプタをRescanする

物理的な接続に問題はない？RescanでESXiにパスを再検出させる：

# 全ストレージアダプタをRescan
esxcli storage core adapter rescan --all

# または特定のアダプタをRescan（例：vmhba1）
esxcli storage core adapter rescan --adapter vmhba1

Rescan後、接続が回復していればVMは通常自動的に再開する。VMの再起動は不要だ。

APDタイムアウトとレスポンスのカスタマイズ

デフォルトでESXiはAPDタイムアウトに入る前に140秒待機する。その後、HAはハング中のVMを自動的にpower offできる — VMを無期限にハング状態にしておく代わりに。PowerCLIで設定する：

# vCenterに接続
Connect-VIServer -Server vcenter.company.com

# クラスタ内の全ホストでAPD処理を有効化
# APDタイムアウト時、HAはハング中のVMを無期限に待機せず、power offできる
$cluster = Get-Cluster "Production-Cluster"
Get-VMHost -Location $cluster | ForEach-Object {
    $esxHost = $_
    Get-AdvancedSetting -Entity $esxHost -Name "Disk.APDHandlingEnable" |
        Set-AdvancedSetting -Value 1 -Confirm:$false
    Write-Host "APD処理を有効化しました: $($esxHost.Name)"
}

PDLへの対処

PDLの方がずっと厄介だ。VMが自動的に回復することは決してないからだ。同僚がメンテナンス中にNetApp上のLUNを誤って削除したことがある — 12台のVMが即座にPDL状態に陥り、1台も起動できなくなった。全てをリカバリするのに約3時間かかった。

手順1：影響を受けているVMを特定する

# PDLの影響を受けているVMを検索
Get-VM | Get-View | Where-Object {
    $_.Runtime.ConnectionState -eq "inaccessible" -or
    ($_.Runtime.PowerState -eq "poweredOn" -and
    $_.Runtime.ConnectionState -eq "disconnected")
} | Select-Object Name, @{N="ConnectionState";E={$_.Runtime.ConnectionState}}

手順2：ハング中のVMを強制power off

PDL状態のVMは通常のシャットダウンができない。killを使う必要がある：

# 対象VMを実行中のESXiホストにSSH接続
# VMのworld IDを確認
esxcli vm process list

# VMを強制終了（12345を実際のworld IDに置き換え）
esxcli vm process kill --type=force --world-id=12345

# forceで終了できない場合はhard killを使用
esxcli vm process kill --type=hard --world-id=12345

手順3：ストレージを復元してVMを再登録する

ストレージの問題を修正した後（LUNの再作成、remapまたはストレージアレイのバックアップスナップショットからのリストア）：

# ESXiがdatastoreを再認識するためにRescan
esxcli storage core adapter rescan --all

# datastoreがアクセス可能か確認
esxcli storage vmfs extent list
# インベントリから削除されたVMを再登録
$datastore = Get-Datastore "DS-Production-01"
$vmxFiles = Get-ChildItem -Path "vmstore:\datacenter\$($datastore.Name)" -Recurse -Filter "*.vmx"

foreach ($vmx in $vmxFiles) {
    $resourcePool = Get-ResourcePool "Resources" -Location (Get-Cluster "Production-Cluster")
    New-VM -VMFilePath $vmx.DatastoreFullPath -ResourcePool $resourcePool
    Write-Host "登録完了: $($vmx.Name)"
}

早期検知のための監視スクリプト

午前2時に叩き起こされるのは3回で十分だ。このスクリプトをTask Schedulerで5分ごとに実行するよう設定した — 問題がエスカレートする前に警告を送信する：

# apd-pdl-monitor.ps1 — Task SchedulerまたはCronで5分ごとに実行
Connect-VIServer -Server vcenter.company.com -User admin -Password $env:VC_PASS

$alerts = @()

# 全datastoreを確認
Get-Datastore | ForEach-Object {
    $ds = $_
    if ($ds.State -ne "Available") {
        $alerts += "[CRITICAL] Datastore '$($ds.Name)' state: $($ds.State)"
    }

    # ホストのマウント状態を確認
    $ds.ExtensionData.Host | ForEach-Object {
        $mountInfo = $_.MountInfo
        if (-not $mountInfo.Accessible) {
            $alerts += "[CRITICAL] Datastore '$($ds.Name)' inaccessible on host $($_.Key)"
        }
    }
}

# 切断されたVMを確認
Get-VM | Where-Object {$_.ExtensionData.Runtime.ConnectionState -eq "inaccessible"} | ForEach-Object {
    $alerts += "[WARNING] VM '$($_.Name)' is inaccessible — possible APD/PDL"
}

if ($alerts.Count -gt 0) {
    $body = $alerts -join "`n"
    # メールまたはSlack/TeamsのWebhookで送信
    Send-MailMessage -To "[email protected]" -Subject "vSphere Storage Alert" -Body $body -SmtpServer "smtp.company.com"
    Write-Host $body
}

Disconnect-VIServer -Confirm:$false

障害対応の夜から学んだこと

それらの経験から、ストレージ問題が発生した際に即座に行うべき4つのことを学んだ：

  1. ESXiホストをすぐに再起動しない — 自然な反応だが誤りだ。VMが実行中のホストを再起動すると、さらなるデータ損失のリスクがある。
  2. まずvmkernel.logを読む — 5分のログ読解で2時間の闇雲なトラブルシューティングを節約できる。
  3. 行動する前にAPD/PDLを区別する — APDは自己解決する可能性があるが、PDLはしない。間違った場所で待つことは時間の無駄だ。
  4. vSphere HAでHA/APDレスポンスを設定する — クラスタ設定 → vSphere HA → 詳細オプションで、das.config.fdm.apd.timeoutを必要に応じて設定し、睡眠中にHAが自動的に処理できるようにする。

そして最も基本的なこと：マルチパスは最初から正しく設定する必要がある。1つのLUNに1つのパスは、APDの発生を待っているようなものだ。最低でも2つの独立したパスが必要 — 理想的には4つ（2つのHBA × 2つのファブリック）。

Share:
Tags: