ESXi の APD(All-path-Down)はご存知でしょうか。

こんにちは。

今回はESXiの運用をしたことがある人であればだいたいの人が
遭遇したことがありそうなAPD(All-path-Down)内容になります。

中規模・大規模環境になってくると共有ディスクを利用し、
それぞれのESXiから参照することが一般的な構成かと思います。
図で表すと以下のような接続図です。

そして、共有ディスクへの接続パスは冗長性の観点から、
複数あることが望ましいことは言うまでもありません。
しかし、ストレージ側の障害よってストレージがパワーオフしてしまった場合は、
どうでしょうか？いくらESXiからストレージへ複数のパスを使って接続できるように
なっていても、ストレージがパワーオフになってしまえば、完全に無意味です。
このような状態に陥った状態のことをAPDやPDL状態といいます。

もう少し定義について詳細がVMwareのストレージガイドに記載されています。
vSphere 6.0 ストレージガイド　124ページ
◇抜粋◇
全パス ダウン (APD）
ストレージ デバイスがホストに対してアクセス不能となり、
デバイスへのパスが使用できなくなった場合に発生する状態です。
通常デバイスのこの問題は一時的なものであり、デバイスが再び
使用できるようになることが期待できるため、ESXi は、
これを一時的な状態として扱います。

---------------------------------

上記の例で示したストレージ側の障害では、障害復旧後は再度障害前に
提供していたボリュームをESXiに提供することが想定されます。
つまり、APDということです。

APDについてもうすこし理解を深める場合は、
VMware KB 2081089 が大変参考になります。
+ vSphere 5.x および 6.x での永続的なデバイスの損失 (PDL) と全パス ダウン (APD)
https://kb.vmware.com/kb/2081089

全パス ダウン (APD)

PDL SCSI 認識コードがデバイスから戻されない場合（ストレージ アレイに接続できない場合、
またはサポートされる PDL SCSI コードを戻さないストレージ アレイの場合）、
そのデバイスは全パス ダウン (APD) 状態にあり、ESXi ホストは応答を受信するまで I/O 要求を送信し続けます。

 

このように記載もされています。

 

つまり、APD状態に陥ったESXiホストは I/O要求を送信し続けます。

これは何を意味するのかというと、ESXiは軽量なOSです。

多くのリソースを仮想マシン側に提供したいので、
限られたリソースの範囲で稼働しています。

しかし、ESXiからストレージに対してI/O要求を送信し続けるということは、
それだけDriverからSCSIコマンドが発行され続け、ESXiが利用可能なリソースの
限り延々と要求し続けます。

その結果、時間が経つとESXiはその他のESXiの稼働に必要なリソースまで使ってしまい、最後にはESXiはvCenter Server から見ると "応答なし" なホストになってしまいます。

ここまでくると、もはやSSH接続もできなくなることが多いです。
当然稼働していた仮想マシンたちも移行（vMotion/Storage vMotion）もできないことが

多いです。

ではどうしたらいいのか。
対処方法はまずESXiホストの再起動です。

（VMware KB 2081089）

• APD 状況は、ストレージ アレイ/ファブリック レイヤーで解決して、ホストへの接続を復元する必要があります。
• 影響を受けるすべての ESXi ホストでは、再起動して、影響を受ける APD 状態のデバイスに対する残存参照すべてを取り除く必要があります。

APDにならないようにするには、きちんと事前に、利用しないボリュームを
vSphere Client からアンマウントしたあと、デバイスを分離します。
これは大変重要な作業です。この作業をしないままストレージ側でLUNを削除したり
すると、APD状態に陥ります。

Windows Server などの感覚で、適当な操作をしていると痛い目に遭うので、
ストレージを操作するときは十分に注意し、操作を行うことをお勧めします。

今回はこのへんで。

SSDのStorageを使うときには。(VMware KB 2013188)

近年、SSDの需要が高まっていることは周知のとおりかと思います。
特に、ディスクI/O が高速であることもさながら、価格も下がってきており、
採用される企業も増加傾向にあります。

私が知る限りでも、増加傾向にあります。

ESXi でSSD ベースのディスク/LUN Arrayを利用する場合は、オプションを有効にする必要があります。

そのため、きちんとVMware KB が公開されています。

Enabling the SSD option on SSD based disks/LUNs that are not detected as SSD by default (2013188)

https://kb.vmware.com/kb/2013188

確認方法は簡単で、esxcli コマンドを実行して確認します。
---------------------------------------------------------------------------------

esxcli storage core device list
naa.60002ac000000000000000100xxxxxx
Display Name: 3PARdata Fibre Channel Disk (naa.60002ac00000000000000xxxxxx)

Has Settable Display Name: true
Size: 409600
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.60002ac000000000000000xxxxxxxx
Vendor: 3PARdata
Model: VV
Revision: 3222
SCSI Level: 6
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: false
Is VVOL PE: false
Is Offline: false

---------------------------------------------------------------------------------

赤字の箇所です。

日本語版のVMware KB 2092902　も公開されていますが、端折られている内容も多く、

英語版を見るほうがより確実です。

デフォルトでは SSD として検出されない SSD ベースのディスク/LUN に対して SSD オプションを有効にする (2092902)

https://kb.vmware.com/kb/2092902

このような部分は、ほとんどの場合は導入および構築したベンダーや企業で行われていることがほとんどです。

しかし、サイジング時の想定よりI/Oパフォーマンスが出ていない場合などは、念のために確認してみるのもよいかと思います。

今回はこのへんで。

ESXiのログの種類と見るべきログファイル - 3 （仮想マシンのログvmware.logを見よう）

今回は取得したサポートバンドル（vm-support）の中を見ていく第3弾。

地道に3回目を迎えた vm-support の記事。

ESXi上で稼働する仮想マシンたちは、当然ながら個々の仮想マシン内でログを吐きます。
Windows Server であれば、システムログ、アプリケーションログ などが一般的ですし、Linuxであればmessagesなどがありますね。

それらに加え、ESXiは個別にそれぞれの仮想マシンのログ（vmware.log）というログを保持しています。

場所はデフォルトではここです。
vm-supportを取得して解凍したファイルのディレクトリ構造も同じです。

> /vmfs/volumes/<データストア名>/<仮想マシン名>/

ログは仮想マシンが再起動 or 起動するたびにローテーションされ、数字で連番がついていきます。

vmware.log
vmware-1.log
vmware-2.log
vmware-3.log
vmware-4.log

ここで注意したいのは、このvmware.log は、仮想マシンの再起動のタイミングでローテーションするので、
長期間稼働し続けている仮想マシンが存在する場合、特大サイズになっていることがあります。

いざ、VMware社へ vm-support を提供しようした際、
ログバンドル（vm-support）が特大サイズで生成され、解凍した際のログのサイズが
100GBを超えたことがある環境もあるらしいです。（恐ろしい）

話はもどりますが、仮想マシンに問題が発生した場合、
主に見るべきログは、ゲストOS自体のログとESXiに保持されているvmware.log です。

もしvMotion や Cold Migration 時に挙動がおかしくなった場合はhostd.logを見る場合もありますが、まずは上記のログを見ます。

vmware.logですが、多くの情報を残してくれます。
例として、ゲストOSとして動作しているWindows Server 2008 R2 にNMIを発行し、
BSOD(Blue Screen of Death)を発生させ、vmware.log に何が記録されるか見てみましょう。

1.　Windows Server 2008 R2 のゲストにNMIを発行します。
　esxcli vm process listコマンドを実行し、パワーオン中の仮想マシンの情報を表示させます。
クラッシュダンプ作成対象の仮想マシンのWorld IDをメモします。
ここでは「World ID : 3891077 」と表示されています。

2．ゲストOSである Windows Server 2008 R2 側以下のレジストリ設定をしておく。

　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

[新規] から [DWORD 値] をクリックし、追加された DWORD 値の名前に ”NMICrashDump” と入力し、ENTER キーを押したあと、
[値のデータ] の空欄に ”1” を入力し [OK] ボタンをクリックします。
この部分はここを見てほしい。

メモリ ダンプ ファイルを生成する方法について | Ask CORE

3．ではESXiから vmdumper コマンドでNMIを発行します。
 　先ほどWorld ID を調べたので、World ID を指定したコマンドを実行します。
　> vmdumper 3891077 nmi　

実行後↓

4.　コマンド実行直後に仮想マシンはBSODになります。

5.　BSODになったので、vmware.log を見てみます。
きちんとBSODが発生したことや、STOPコードまで記録されています。
◆vmware.log（テキスト）
2016-05-09T14:10:38.751Z| svga| I120: WinBSOD: ( 1) `A problem has been detected and Windows has been shut down to prevent damage '

2016-05-09T14:10:38.751Z| svga| I120: WinBSOD: ( 2) `to your computer. '
2016-05-09T14:10:38.752Z| svga| I120: WinBSOD: ( 4) `Hardware malfunction. '
2016-05-09T14:10:38.763Z| svga| I120: WinBSOD: ( 6) `If this is the first time you've seen this Stop error screen, '
2016-05-09T14:10:38.764Z| svga| I120: WinBSOD: ( 7) `restart your computer. If this screen appears again, follow '
2016-05-09T14:10:38.764Z| svga| I120: WinBSOD: ( 8) `these steps: '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (10) `Check to make sure any new hardware or software is properly installed. '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (11) `If this is a new installation, ask your hardware or software manufacturer '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (12) `for any Windows updates you might need. '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (14) `If problems continue, disable or remove any newly installed hardware '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (15) `or software. Disable BIOS memory options such as caching or shadowing. '
2016-05-09T14:10:38.781Z| svga| I120: WinBSOD: (16) `If you need to use Safe Mode to remove or disable compone '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (16) `If you need to use Safe Mode to remove or disable components, restart '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (17) `your computer, press F8 to select Advanced Startup Options, and then '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (18) `select Safe Mode. '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (20) `Technical information: '
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (22) `*** STOP: 0x00000080 (0x00000000004F4454,0x0000000000000000,0x0000000000000000,0'
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (23) `x0000000000000000) '
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (27) `Collecting data for crash dump ... '
2016-05-09T14:10:38.813Z| svga| I120: WinBSOD: (28) `Initializing disk for crash dump ... '
2016-05-09T14:10:42.972Z| svga| I120: WinBSOD: (29) `Beginning dump of physical memory. '
2016-05-09T14:10:42.972Z| svga| I120: WinBSOD: (30) `Dumping physical memory to disk: 0 '

+vmware.log（画面キャプチャ）

このように、仮想マシンで何か発生した際には、
vmware.logを見てみてください。

では、よい仮想化ライフを。

ESXiのログの種類と見るべきログファイル - 2 （ネットワーク障害時）

今回は取得したサポートバンドル（vm-support）の中を見ていく第二弾。

ネットワーク障害時のトラブルシュートしていくときに見ていくログを挙げていく。

【ESXi5.x】
　　◆ファイル名（主なログ）
　　　　/var/log/vmkernel.log　->　vmkernel のログ
　　　　/var/run/log/vmkernel.*.gz　->　vmkernel のログ (過去分)
　　　　/var/log/vobd.log　->　vmkernel observation events

主にこれらのログを見ていくことになる。
その他のログについては、VMware KBも公開されている。
+ESXi 5.1 および 5.5 ログ ファイルの場所 (2080773)

https://kb.vmware.com/kb/2080773

しかし、いきなりvmkernelログを見ていくのは無謀である。
事前に  ESXiのログの種類と見るべきログファイル - 2　で記載したとおり、
「commands」ディレクトリ配下にある「nicinfo.sh.txt」や「 esxcfg-vmknic_-l.txt」を
見てから、どのvmkernel port での事象なのか、またはどのvmnic（物理NIC）での
事象なのかをきちんと確認したうえで、vmkernelログを見るようにしよう。

「nicinfo.sh.txt」のサンプルを記載する。
（かなり長いので冒頭のみを記載）
============

# more nicinfo.sh.txt
Network Interface Cards Information.

Name PCI Device Driver Link Speed Duplex MAC Address MTU Description
----------------------------------------------------------------------------------------
vmnic0 0000:004:00.0 igb Up 1000 Full e4:11:5b:96:c1:ee 1500 Intel Corporation I350 Gigabit Backplane Connection
vmnic1 0000:004:00.1 igb Down 0 Half e4:11:5b:96:c1:ef 1500 Intel Corporation I350 Gigabit Backplane Connection

NIC: vmnic0

NICInfo:
Advertised Auto Negotiation: true
Advertised Link Modes: 1000baseT/Full
Auto Negotiation: true
Cable Type: FIBRE
Current Message Level: 7
Driver Info:
NICDriverInfo:
Bus Info: 0000:04:00.0
Driver: igb
Firmware Version: 1.53, 0x80000bc6, 1.464.0
Version: 5.0.5.1
Link Detected: true
Link Status: Up
Name: vmnic0
PHY Address: 0
Pause Autonegotiate: true
Pause RX: true
Pause TX: true
====================================

この一部だけでこのサーバーのネットワーク構成の概要がわかる。
結果からわかることを抜粋します。

物理NICとしてvmnic0とvmnic1 が存在し、vmnic0 がLinkUpしていて、vmnic1はLinkDownしている。vmnic0は1000baseT/Full でLinkUpしており、Driverは igb Driverで動作していてNICのFirmwareは5.0.5.1である。スピードはオートネゴシエーションの設定となっている。

このあたりだろうか。

ネットワーク構成情報を踏まえたうえで、vmkernelログを見てください。

vmkernelログをみるときの注意点が１つあります。
ESXiのログは基本的にすべてUTC時刻で記録されます。
UTCとは全世界で時刻を記録する際に使われる公式な時刻のことです。
日本時間はUTC +9 時間ということになっています。

UTC: 2016-04-21 16:20:00　→　JST：2016-04-22 01:20:00

つまり、日本でトラブルが発生した時間が2016年4月22日01時20分である場合、

ESXiのログ上の事象発生時刻は2016年4月21日16時20分になります。
間違えてJSTのまま想定してログを見ていると意味不明な結論にたどり着いてしまう可能性もあるため、注意が必要です。

今回はこの辺で。

ESXiのログの種類と見るべきログファイル - 1 （収集したコマンド結果）

今回は取得したサポートバンドル（vm-support）の中を見ていく第一弾。

とはいっても、まずはどのファイルをトラブルシュート時に見ていくのかを
ある程度知っておくと便利であるため、そのあたりから書いていこうと思う。

◆環境
ESXi5.5 Update 2
---
vm-supportのファイル名は↓の命名規則で生成される。

<IP Address or hostname> -vmsupport-<取得日付>@<時間>.tgz 

tgz 形式であるため、Linux上で解凍するでもよし、Windowsに便利なツールをいれて解凍するもよし。

解凍すると、ディレクトリやファイルが数多く散見できる。

主にみることが多いところを列挙する。

commands　→　各コマンドの結果をテキストファイルにまとめてこのディレクトリに入れてくれる。（トラブルシュート時に超重要情報がたくさん入っている。）

var　→　配下に log ディレクトリおよびvar/run/log などが存在し、見ることが多い。
vmfs　→　配下にはESXiがマウントしているデータストアなどの情報が含まれる。当然ながら、データストアには仮想マシンが配置されているため、仮想マシンに関する情報はここを見ることが多い。

まずは「commands」ディレクトリの中を見ていこう。
その前に、上記の画面に 「reconstruct.sh」というシェルがあることがわかる。

これは予め実行しておこう。理由は後述させていただく。
実行はLinux上で実行する

ここからは何かとWindows で開くよりもLinuxでファイルを開いたほうがわかりやすいため、Linuxでログを表示した画面を紹介していく。

まずはサポートバンドルの上位ディレクトリはこのような構造になっている。
（上記Windowsの画面と同じ場所）

  # cd commands　でディレクトリを移動する。
ls コマンドの結果を見ると数多くの結果を見ることができる。
これはすべてコマンド結果のテキストファイルである。

これらのテキストファイルには構成を知ることができる情報が満載である。
例えば、「esxcfg-vswitch_-l.txt」を開くと以下のようなvSwitchの結果が記録されている。
また、どのような vmkernel Port が表示されている。

--------------------------------------------
# cat esxcfg-vswitch_-l.txt

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 1536 6 128 1500 vmnic0

PortGroup Name VLAN ID Used Ports Uplinks
VM Network 0 0 vmnic0
VMkernel_vMotion 0 1 vmnic0
VMkernel_iSCSIStorege 0 1 vmnic0
Management Network 0 1 vmnic0
--------------------------------------------
ログバンドルを収集した環境のvSwitchの構成は以下のとおりである。

さらにもっとvmkernel Port の情報が欲しい場合は、「 esxcfg-vmknic_-l.txt」を見ると良い。（画像小さくてすみません）

NIC関連の情報を一気に見たいときは「nicinfo.sh.txt」を見るのもアリだ。

その他にもどのようなデータストアがあるかを確認する場合は、
「localcli_storage-vmfs-extent-list.txt」を見ると良い。
Device Nameまでわかるため、その他の調査にも役立つ。

その他にもStorage と接続しているHBAやサーバー情報など、
トラブル時に必要な構成情報や環境面の情報はほとんど確認ができる。
Windows でも msinfo32 や各サーバーベンダーが収集ツールなどを提供していると思うが、ここまでOS標準のログ収集機能で収集できるとなると、大変便利である。

もし興味があるようであれば、commandsディレクトリ内のファイルはすべて見ておくと何かと便利である。

[補足]
ESX4.xのときは別のディレクトリにコマンド結果が吐かれる。
たしか tmp 配下だったような。（忘れました）

今回はこの辺で。

ESXi やvCenter Server のログを収集しよう。

VMware製品では、ログの収集方法を知ることすら一苦労だなと感じている。

KB も多数公開されているが、本当に使えるものが取れるのか、

"この方法であってる？"  であったり、正直不安な部分が多い。

VMware KB だとこの辺だろう。

+ VMware ESX/ESXi における vm-support コマンドを使用した診断情報の収集 (1036179)
https://kb.vmware.com/kb/1036179

今回はきちんとログを収集する順番を記載していこうと思う。
といってもすごく簡単ですが。画面に表示されるIP Addressなどの名前はマスクさせてもらう。

まず、vSphere Client からvCenter Server に接続し、
ツリーの一番上（vCenter Server）をクリックした状態にする。

上部のメニューから [ファイル] - [エクスポート] - [システムログのエクスポート] を
クリックする。

ログを収集するESXiホストにチェックを入れる。
また、vCenter Server の情報も一括で収集したい場合は、
[vCenter Server およびvSphere Client からの情報を含む] にチェックをいれておく。

デフォルトで [次へ] をクリックだ。

任意の保存先を選ぶのみ。

[終了] をクリックするとログ収集が開始される。

あとは待つだけだ。

ここまでの操作で収集されるものは、VMWare KB などでいうところの、

vm-support , vc-support  というログバンドルになる。

・　vm-support　-> ESXi上のログをまとめて圧縮したもの

・　vc-support　->　vCenter のログバンドル

vm-supportというログバンドルは、一括収集しているだけでなく、
いろんなコマンド結果をテキストファイルに保存してログバンドルとして保存してくれている。すごくいい奴なんです。

VMware社に問い合わせるときにもこれらを収集するよう言われることが多いみたいです。

vm-supportの中身については、次回の記事に記載したいなと思う。