vSphere ESXiのスクラッチ パーティションについて
スクラッチ パーティションとは？
vSphere ESXiにおいて、スクラッチ パーティションとはログを保存する領域のことです。
英語でScratchを形容詞で調べると”集める”という意味合いがあるので、後述していますが情報収集をする、という意味合いだと解釈出来ます。
この領域は運用上はオプションとしての設定ではあるものの、トラブル対処を行う上では大変重要な設定になります。ユーザーはESXiに対して、ログの排出先をどこに設定するかを計画する必要があります。
メモリ上のスクラッチ パーティションについて
ESXiのインストール先の容量が5.2GBを下回る場合には、システムのメモリ上にスクラッチ パーティションが自動的に設定されます。
言い換えるならばログが排出される動きとなります。一般的にメモリは揮発性(電力供給が無い状況ではデータを保持出来ない)ため、例えばESXiで電源障害などが発生してしまうと、メモリ上のログ情報は消失してしまい、トラブルの原因調査が出来なくなります。
こちらの図では、単一のESXiのスクラッチ パーティション設定が現在では/tmp/scratchに設定されている状況が確認出来ました。
WinSCPにてログの排出状況を確認した結果がこちらです。
次にlogディレクトリ内部を確認すると80個ほどのログが排出されています。
ここで一旦、疑似電源障害をシミュレートするため本ESXiホストの再起動を実施します。
現在メモリ上に排出をされていたため、先程のログは消失し新しいログが生成されています。
ログ数も46個まで減っており、見た目にはしっかりログが残っていますが、ログサイズが再起動後に小さくなっているものが確認出来ます。
2つの図を並べて比較すると一目瞭然です。
スクラッチ パーティションの保存先変更
ここで、ホストが持つVMFS領域にスクラッチ パーティションを作成し、そこにログが排出されるよう設定を変更してみようと思います。
下図では本ホストが”RAID-VMFS”という名前のデータストアがマウントされており（右図）、
本データストアが、ESXi内部では/vmfs/volumes ディレクトリ配下に”RAID-VMFS”と書かれたエイリアスパスで保存されていることが確認出来ました。
このパス確認は、後のスクラッチ パーティションの移行先指定で必要なためこのステップで確認をしています。
ここで、同VMFS内に、”scratch-on-VMFS”というディレクトリを作成してみました。
(この名前は運用者が任意で作成可能です)
ちなみに、上図の水色の列をご覧頂くと、/vmfs/volumes/5c6d6c25-6a386380-a837-509a4cab3cc2というパスが記述されていますが、この英数字の羅列がESXiが内的にこの”RAID-VMFS”に対してつけている管理識別子(UUID)です。
ここで確認をしたパス名を、下図内の1つ目の設定キーである”ScracthConfig.ConfiguredScratchLocation”に入力します。
この設定値に、次のうちどちらかを入力します。
/vmfs/volumes/5c6d6c25-6a386380-a837-509a4cab3cc2/Scratch-on-VMFS/
または
/vmfs/volumes/RAID-VMFS/RAID-VMFS/
どちらを入力したとしても、再起動後の設定値はUUIDを含むフォーマットで設定が行われます（上の入力値で設定が保存されます）
再起動後に本設定が保存され、ログも移動されていることを確認が出来ました。
設定変更前に取得されていたログ情報も残ったままログ保存先の変更が出来ました。
(下図内の水色の行を確認するとVMFS内のパスに表示が変わっています)
ハードドライブ/SSDにESXiをインストールした場合のデフォルト設定
手元にあったPowerEdge T620を利用し、RAIDを構成したドライブにESXiをインストールしました。
筐体内蔵のRAIDコントローラーとハードドライブ2本を使い、RAID1を構成しました。
Dell EMC iDRACから見たRAID構成は次の通りです、RAID仮想ディスクのサイズは278GBです。
ESXiインストールを終えた直後のVMware Host Clientの画面です。
VMFSも同一ボリューム上に作成されました。(一番下の水色の箇所/271.5GB)
これまでの内容に従えば、スクラッチ パーティションはメモリ上ではなく、このRAID仮想ディスク上に設定されているはずですので、上記で確認した項目と同じ箇所を確認してみましょう。
/tmpディレクトリではなく、初めから/vmfs/volumes配下が指定されています。この点からもファイルシステム内（物理ドライブ内にログが保存されていることが確認出来ました）
vSANにおけるログ管理
vSAN環境においても、ログ管理は重要です。上記の操作紹介ではVMFS上にログ排出先指定を行いました。
しかしvSAN環境においては”vSANデータストアにログを排出することは非サポート”と明言されています。
上記情報は”起動デバイスとvSANの使用(vSphere 6.7)“からの抜粋です。
vSANを構成する要素として、ESXiはまさにストレージとして振る舞うと言えます。
一方でストレージであるESXiはサーバーであり、そのログをvSANに保存するとなると、ログ自体が自分自身に出力されてしまうことになります。
例えばハードウェア損傷などに伴い、サーバー自体の起動プロセスに問題を抱えてしまった場合、ログはそのサーバーの中に入っているため取り出しが出来ません。
vSANが登場する以前のストレージのスタイルはSANストレージ(iSCSIやFibre Channel)でしたので、
ログを排出する先のストレージ＝サーバー内部ではないと言えます。
このため、vSAN環境では”ただスクラッチ パーティションを設定しましょう”ではなく、その設定が”vSANノードではない所に保存されるように”という点を注意として促しています。この点を考慮するといくつかのパターンが見えてきます。
ESXiインストール領域が大容量デバイスの場合
最近のHCIのトレンドとして、ESXiのインストール領域にM.2 SSDドライブなどがあります。
Dell EMC PowerEdgeの場合は、”Boot Optimized Storage Solution”（通称BOSS)と読んでいるデバイスが第14世代のPowerEdgeから登場しています。
この製品は、PCIカード上に最大2枚までのM.2 SSDを搭載するというもので、容量も100GB以上です。
この場合、このカード上にESXiのインストールを行い、残った領域にVMFSを作成後その中にログ保存領域を配置するという選択肢が生まれます。
もちろんこうした新世代のデバイスでなくとも、vSANノード上に非vSANディスク(SASのHDDなど)を配置し、そこにESXiをインストールし、上記と同様に余った領域にログ保存用のVMFSを設定するという方法もあります。
但しこの場合、vSAN用のディスクと同じストレージコントローラー配下のディスクにESXiの領域にはハードウェアRAIDは構成出来ません。詳細についてはこちらのKBを参照ください。
vSAN と非 vSAN ディスクを同じストレージ コントローラで使用する場合のベスト プラクティス (2129050)
ESXiインストール領域が小容量デバイスの場合
本項で取り扱う小容量デバイスとは、例えばSDカード、USBメモリスティックなどを言います。
vSANに限らずですがESXiをインストールするには最低1GBの容量のデバイスであればインストールが可能です。
これに加えESXiはインストール時に、インストール先となるデバイスのIO感度を確認し、USBメモリやSDカードなどのデバイスはログ保存領域としては不適切とし、これらにログを配置しません。
ESXiのハードウェア要件
ログの出力というのは大量の書き込みを発生させる動きとなるため、一定のIOをさばけるデバイスでないと行けないということですね。
その点についてはこちらのKBでも言及があります。
vSphere SSD とフラッシュ デバイスのサポート (2145210)
SDカードやUSBメモリスティックにESXiをインストールする場合にはやはり別途vSANノードにマウントをするVMFSやNFSを用意する必要が出てくると言えますね。
関連リンク
スクラッチ パーティションについて – vSphere 6.7
ESXi 4.x/5.x/6.x の永続的スクラッチの場所の作成 (1033696)
Creating a persistent scratch location for ESXi 4.x/5.x/6.x (1033696)
スクラッチ パーティションが VMware ESXi ホストに対して小さすぎる (2057602)
vSphere SSD とフラッシュ デバイスのサポート (2145210)
vSAN のログに「RAM ディスク「vsantraces」がいっぱいです (The ramdisk “vsantraces” is full)」エラーが記録される (2150320)
コメント