【vSAN画像まとめ】vSANクラスター内でのディスク1本障害画像キャプチャーまとめ

本記事では、VMware HOL環境を用いて、障害をシミュレートした結果を画像と解説を入れながら、次の4つのシナリオ向けに纏めています。

キャパシティドライブ1本障害：重複排除無しの場合
キャッシュドライブ1本障害：重複排除無しの場合
キャパシティドライブ1本障害：重複排除有りの場合
キャッシュドライブ1本障害：重複排除無しの場合

記事内では、各事象に対する障害箇所確認と、物理的なドライブ交換前後の画面操作を紹介しています。

<免責事項及び諸注意>

環境情報については、次のHOLに準じます。(vSAN 6.7ベースでの情報です)

HOL-1908-01-HCI – vSAN v6.7 – Getting Started

同環境内にて、ESXiホスト3台(各ホスト1ディスクグループ構成, 1ディスクグループ当たり20GBのキャパシティを提供)の環境をベースに、ドライブ1本障害のみを複数のシナリオで解説しています。ドライブ障害に伴う画面確認や物理的なドライブ交換後のGUI上の作業手順を紹介しています。将来的な製品アップデートに伴う仕様変更並びに環境依存設定やストレージポリシー、仮想マシンのサイズなどにも依存し、本記事の内容が適用しないケースもあるため、本記事を参考とした結果のデータロストなどは一切責任を負いかねる点をご理解頂いた方のみ記事の内容をご確認下さい。記事内部の内容についても、ブログトップで記述があるように一個人の検証結果レポートという記事である点も合わせてご留意下さい。(特定の所属団体が推奨とする保守作業手順でもございません)

vSAN製品をご購入されたベンダーによっては特殊な管理アプライアンスを経由した交換手順を推奨または必須かしている場合もありますので、本記事内の手順を実施する前に購入元にお問い合わせにて、本記事で紹介が無い差分作業などがあるかを確認されることをお勧めいたします。

<シナリオ1>

キャパシティドライブ1本障害：重複排除無しの場合

このケースは、最もメジャーな障害ケースだと言えるかもしれません。

重複排除と圧縮(無効) / キャパシティドライブの障害のケース

上図のように障害発生をさせた単一のドライブのみが障害ドライブとしてマークされます。試しにvSphere Web Client上からこのドライブの取り外しを試みてみましょう。

障害ディスクを選択後、ディスクの削除メニューをクリックします。

ディスクの削除を行う際ですが、メンテナンスモードの時のように操作対象ドライブ内のデータの移行有無を問われます。

障害が発生し、データアクセスが出来ない場合にデータ移行を試すと次のようにエラーが返されます。

中のデータにアクセスが出来ないので、そもそも移動は出来ませんよね。

気を取り直して、”データを退避しない”を選択して作業を進行します。無事、障害ドライブの切り離しに成功しました。

キャパシティドライブの数が2本から1本に減りました。

この後は保守作業を行うとすれば、障害ドライブを物理的に取り外し、新規ドライブを挿入し、既存のディスクグループに追加をします。

新規ドライブを追加したいディスクグループを選択し、ドライブを追加します。

リストの上の方にある”緑のプラスマーク”が目印のアイコンから、ドライブ追加作業が可能です。

追加をしたいドライブを選択して、OKボタンをクリックします。

追加操作後、無事に1キャッシュドライブ、2キャパシティドライブの構成に戻りました。

これで無事作業完了と言えます。

念の為vSAN データストアのサイズも60GBに戻ったかを確認します。

60GBに戻っていますね。完全に正常に戻ったと言えます。

ところで、上図内では問題は解決したにも関わらず黄色で目立つ”アラーム”が継続発生しています。アラームは、ユーザーによる確認をしたことを伝えるアクションを行う必要があるため、”確認”または”緑にリセット”をクリックするまでは残り続けます。

完全に表示自体を消す場合は”緑にリセット”をクリック頂ければOKです。

<シナリオ2>

キャッシュドライブ1本障害：重複排除無しの場合

重複排除と圧縮(無効) / キャッシュドライブの障害のケース

キャッシュドライブの障害＝ディスクグループレベルでの障害相当となります。

実際、同一ディスクグループ内のキャパシティドライブは見た目上エラーはありませんが、実際にvSAN データストアの容量を見てみると20GB分減っています。

図内右下の”vSAN容量”内のゲージの最大値が39.99GBと、約40GBを示しています。

ユーザー視点では”たった1本のキャパシティドライブの障害で、なぜキャパシティが2本分減ってしまうのか？”と感じてしまうかもしれません。これは現時点でのvSANにおけるディスクグループの仕様によるものです。

この場合、物理的にキャッシュドライブ(SSD)を交換するケースでは、通常ディスクグループ自体の削除と再作成を行います。

今回は実験としてディスクグループの削除では無く、キャッシュドライブ単体の削除を試してみます。

障害が発生したキャッシュドライブを選択し、ディスクグループからの削除を実行します。

この結果、実際には”ディスクグループの削除”が行われました。

図内下の”最近のタスク”内をご覧頂くと、”Remove disk group from the vSAN…”と記述があり、DG自体の削除操作になっていることが確認出来ます。

理由としてはディスクグループを構成するには、必ず1本のキャッシュドライブが必要です。言い換えるならば、vSANにおけるディスクグループの最小構成は、”1本のキャッシュドライブと1本のキャパシティドライブ”ですから、最小構成を保てなくなるためディスクグループ自体が消失する形となります。

物理的な交換を行うタイミングとしてはこのタイミングで行い、SSDの交換を終えた後は、”ディスクグループの作成”を行えばGUI上の作業は完了となります。

作業対象のホストを選択後、緑のプラスマークを持つアイコンをクリックします。

ディスクグループの作成ウィザードは次の通りです。

上のリストではキャッシュドライブ、下のリストではキャパシティドライブを選択します。

作成が終わりましたら以下のように元のディスクグループが復活しました。

上記操作に加え、最初に紹介したケースと同様にvSANの容量面でも欠損した容量が復活したかも合わせて確認をするとよりよいと言えるでしょう。

<シナリオ3>

キャパシティドライブ1本障害：重複排除有りの場合

重複排除と圧縮(有効) / キャパシティドライブの障害のケース

”重複排除と圧縮”が有効な場合、キャパシティドライブ1本の障害であってもディスクグループレベルでの障害扱いとなります。

重複排除および圧縮の使用

このため、交換作業を行う上ではディスクグループの削除が必要となります。

”重複排除と圧縮”が有効な場合、DG内からのドライブ削除時にはこのようなメッセージが表示されます。

ディスクグループの削除は可能なので、削除を行います。本メニューは問題なく動作します。

本シナリオでは、”データを移行しない”のみ利用可能です。理由は既に本DG内のデータは全てアクセス不可という扱いのため移行対象のデータへアクセスが出来ません。

ディスクグループの削除が完了しました。作業対象だったesx-01a.corp.localのみディスクグループが存在しない状態になりました。(これは想定される正常な結果です)

この後は、新規のディスクグループ作成が出来ますので、障害ディスクを物理的に交換後、元のディスクグループに存在した正常なドライブと交換後のドライブで元のディスクグループを構成すれば交換完了だと言えます。

上記の作業の画像キャプチャについては、本記事内シナリオ2内のものと同じであるため割愛致します。

<シナリオ4>

キャッシュドライブ1本障害：重複排除有りの場合

上記のケースは、シナリオ3と同じです。そのため画像や記事そのものも割愛致します。

こちらに記述があります。”重複排除と圧縮”が有効である以上、キャパシティかキャッシュか問わず発生しうるケースは同じだと言えます。

以上です。本記事の内容が、皆様のvSANクラスター内でのディスク障害解決の役に立つことを祈ります。

<本検証を行った上で利用した追加情報>

Disk Failures内のスクリプトを利用した疑似エラーフラグを利用して障害を発生させています。
上記スクリプトを利用した際、即座に障害フラグが発生しない場合は”ストレージの再スキャン”を該当ホストに対して行えば結果が反映されます
HOL内ではHOL起動直後はvSANが構成されていません。そのためデスクトップ上のスクリプトを利用して自動的にvSANは構成可能ですが、それを利用した場合”重複排除と圧縮”が有効化されます。
手動でそれを無効化した場合、無効化後のディスクグループは”重複排除と圧縮”ベースのディスクフォーマットを持っているため、一旦手動でディスクグループ自体も削除、再作成を行うことで、
”重複排除と圧縮”未使用状態としてのvSANを検証材料ついて利用することが出来ます。