vSAN環境での仮想マシンのスナップショット作成失敗について
本記事は、VMUG User/con 2019でご紹介があったvSANの運用における注意点について、私個人が検証を加えた技術記事です。（本記事の掲載については、講演者に許可を頂いております）
vSAN create virtual machine snapshot fails (2146281)
皆さんはこちらの記事をご存知でしょうか、vSAN環境において、vSphereネイティブなスナップショット取得が失敗するという内容です。
https://kb.vmware.com/s/article/2146281
例えば、RAID1/FTT=1のvSANクラスターの場合、2n+1のルールに基づくと最小構成のホスト台数は3台です。もちろんFTTの定義は、許容出来る障害数ですのでFTT=1ということは1つの障害、つまりホスト1台の障害まで許容が可能です。
サービス自体が止まるか止まらないか、という点では1台のホスト障害では仮想マシンは停止しません。耐障害性計画においてはこれで良いのです。ですがこの状態ではvSphereベースのスナップショットが取得出来ない事が問題となります。
正常にスナップショットが取得出来る場合
障害発生が無い状態でスナップショットを取得する場合は、次のような動きとなります。
ステップ5で配置されたデータは以下のようなイメージとなります。
各コンポーネントは、3ノードのホストそれぞれに分配されます。
次に障害シナリオを見てみたいと思います。
正常にスナップショットが取得出来ない場合
ここからが本題です。一言で言えば、1ホスト停止するとスナップショットが取得出来ません。
スナップショットが取れない事そのものは、緊急性を伴うものではありませんが、バックアップジョブを実行する上でスナップショットを欠かせないという環境においては致命的です。この記事で最も伝えたいメッセージは、FTTの数値に対する考慮は、サービス提供におけるSLAだけに留まらず、バックアップの運用に対しても影響が出るため、バックアップの重要度に対してもFTTの値やホスト台数を考慮してほしいという事です。
早速ですが本ケースを見てみたいと思います。以下のケースでは3ノードvSANのうち1ノードだけが利用不可な状態です。（パープルスクリーン、電源障害、フリーズなど、ホストが使えないケースであればどれを想像頂いても結構です）
3台目のホストに✗マークがついた事以外は上で紹介した図と代わりありません。この状態で、新規にスナップショットを取得した際のコンポーネントを配置しようとすると次のようになります。
こちらが実際のvSphere Client上でのエラーです。 エラー内容としては、現在は2つのフォールトドメインしかなく、この操作には追加で1つのフォルトドメインが必要であると記述されています。
フォールトドメインという単語だけを拾うと、vSANのラックアウェアネスなコンポーネント配置の機能を連想しますが、ここでは単純にフォールトドメインという単語をホスト、と読み替えた方が解釈しやすいです。
vSAN クラスタのフォールト ドメインの管理
結論
RAID及びFTTにて定義した耐障害性ストレージポリシーを持つ仮想マシンにおいては、スナップショット取得時に完全冗長な状況でなければvSphere スナップショット取得が出来ない。
結果的に、完全冗長状態に戻るまでは社内におけるデータバックアップオペレーションや保護ポリシーに問題が出てしまうため、それも見越してクラスター構成に参加するホスト台数を決定すると尚良い。
おまけ：取得済みのスナップショットは、完全冗長では無い状況で復元可能か？
番外編として、個人的に気になったので検証しました。既に取得されたスナップショットは、非完全冗長状態（例：3ノード vSANにおいて1ノード欠損状態）では、スナップショットロールバックが出来るか、を実験しました。
先に3ノードvSANにてホスト障害がない状態で、一旦スナップショットを取得後、1台のホストをメンテナンスモードにした状態で、取得済みのスナップショットにロールバックをするというオペレーションを実行しました。
それでは”Revert to”ボタンにてロールバックを試します。
ご覧頂いての通り、上図下部にはしっかりとRevert Snapshotに対してエラーが発生しています。予想が的中し、スナップショットのロールバックには失敗しました。
念の為、メンテナンスモードを解除し、完全冗長状態に戻してロールバックを試した所、ロールバックは正常に完了しました。
今回の記事は以上となります。詰まる所、FTTの数値はSLA以外にもオブジェクトに対する操作が発生するあらゆるオペレーションに対しても考慮が必要であるという事が再確認出来ました。もちろん、障害というのは通常運用においては長時間発生するものではありませんが、場合によっては難度障害というのもありますので、システムの重要度によってはハードウェア面の強化、またはストレージポリシー側の設定をうまく制御刷ることで回避ができると言えます。
今回のVMUG総会で聞いた話で、”うまい運用だな～”と思ったのは、RAID1とRAID5のFTT=1ポリシーを2種類使い分けていた環境に4ノードのvSANクラスターを展開している環境でした。
この場合1ノード障害が起きると、前者(RAID1)は以前完全冗長ですが、後者(RAID5)は非完全冗長です。後者側のVMでバックアップを取りたかったが、スナップショットが利用出来ないという事だったので、これを受けてバックアップ取得が必要な仮想マシンだけRAID1に切り替えたという運用カバー事例はとても素晴らしかったです。単純にノードを増やしましょうというだけではなく、運用でカバーするというアプローチもまた、VMUGのようなシニアなエンジニアの方の集まりだからこそ聞けた話だと思いました。
コメント