本記事では、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上からこのドライブの取り外しを試みてみましょう。
ディスクの削除を行う際ですが、メンテナンス モードの時のように操作対象ドライブ内のデータの移行有無を問われます。
障害が発生し、データアクセスが出来ない場合にデータ移行を試すと次のようにエラーが返されます。
気を取り直して、”データを退避しない”を選択して作業を進行します。無事、障害ドライブの切り離しに成功しました。
この後は保守作業を行うとすれば、障害ドライブを物理的に取り外し、新規ドライブを挿入し、既存のディスク グループに追加をします。
新規ドライブを追加したいディスク グループを選択し、ドライブを追加します。
追加操作後、無事に1キャッシュ ドライブ、2キャパシティ ドライブの構成に戻りました。
念の為vSAN データストアのサイズも60GBに戻ったかを確認します。
ところで、上図内では問題は解決したにも関わらず黄色で目立つ”アラーム”が継続発生しています。アラームは、ユーザーによる確認をしたことを伝えるアクションを行う必要があるため、”確認”または”緑にリセット”をクリックするまでは残り続けます。
完全に表示自体を消す場合は”緑にリセット”をクリック頂ければOKです。
<シナリオ2>
キャッシュ ドライブ1本障害：重複排除無しの場合
キャッシュ ドライブの障害＝ディスク グループレベルでの障害相当となります。
実際、同一ディスク グループ内のキャパシティ ドライブは見た目上エラーはありませんが、実際にvSAN データストアの容量を見てみると20GB分減っています。
ユーザー視点では”たった1本のキャパシティ ドライブの障害で、なぜキャパシティが2本分減ってしまうのか？”と感じてしまうかもしれません。これは現時点でのvSANにおけるディスク グループの仕様によるものです。
この場合、物理的にキャッシュ ドライブ(SSD)を交換するケースでは、通常ディスク グループ自体の削除と再作成を行います。
今回は実験としてディスク グループの削除では無く、キャッシュ ドライブ単体の削除を試してみます。
この結果、実際には”ディスク グループの削除”が行われました。
理由としてはディスク グループを構成するには、必ず1本のキャッシュ ドライブが必要です。言い換えるならば、vSANにおけるディスク グループの最小構成は、”1本のキャッシュ ドライブと1本のキャパシティ ドライブ”ですから、最小構成を保てなくなるためディスク グループ自体が消失する形となります。
物理的な交換を行うタイミングとしてはこのタイミングで行い、SSDの交換を終えた後は、”ディスク グループの作成”を行えばGUI上の作業は完了となります。
ディスク グループの作成ウィザードは次の通りです。
作成が終わりましたら以下のように元のディスク グループが復活しました。
上記操作に加え、最初に紹介したケースと同様にvSANの容量面でも欠損した容量が復活したかも合わせて確認をするとよりよいと言えるでしょう。
<シナリオ3>
キャパシティ ドライブ1本障害：重複排除有りの場合
”重複排除と圧縮”が有効な場合、キャパシティ ドライブ1本の障害であってもディスク グループレベルでの障害扱いとなります。
このため、交換作業を行う上ではディスクグループの削除が必要となります。
ディスク グループの削除は可能なので、削除を行います。本メニューは問題なく動作します。
ディスク グループの削除が完了しました。作業対象だったesx-01a.corp.localのみディスク グループが存在しない状態になりました。(これは想定される正常な結果です)
この後は、新規のディスク グループ作成が出来ますので、障害ディスクを物理的に交換後、元のディスク グループに存在した正常なドライブと交換後のドライブで元のディスク グループを構成すれば交換完了だと言えます。
上記の作業の画像キャプチャについては、本記事内シナリオ2内のものと同じであるため割愛致します。
<シナリオ4>
キャッシュ ドライブ1本障害：重複排除有りの場合
上記のケースは、シナリオ3と同じです。そのため画像や記事そのものも割愛致します。
以上です。本記事の内容が、皆様のvSANクラスター内でのディスク障害解決の役に立つことを祈ります。
<本検証を行った上で利用した追加情報>
- Disk Failures内のスクリプトを利用した疑似エラーフラグを利用して障害を発生させています。
- 上記スクリプトを利用した際、即座に障害フラグが発生しない場合は”ストレージの再スキャン”を該当ホストに対して行えば結果が反映されます
- HOL内ではHOL起動直後はvSANが構成されていません。そのためデスクトップ上のスクリプトを利用して自動的にvSANは構成可能ですが、それを利用した場合”重複排除と圧縮”が有効化されます。
手動でそれを無効化した場合、無効化後のディスク グループは”重複排除と圧縮”ベースのディスク フォーマットを持っているため、一旦手動でディスク グループ自体も削除、再作成を行うことで、
”重複排除と圧縮”未使用状態としてのvSANを検証材料ついて利用することが出来ます。
コメント