━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ケーススタディ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
VMware vSAN の運用、トラブルシューティングについて
今回はvSAN環境における運用についてご紹介します。
VMware vSAN は ESXi ホストのローカル物理ストレージリソースを抽象化することで単一のデータストアに集約し、クラスタのすべてのホストで共有する技術です。
外部ストレージが不要であるため手軽にご利用頂ける反面、初めてご利用になられる方は、運用やトラブルシューティングに不安を覚える方もいらっしゃるかと思います。実際 vSAN 環境では各ホストの内部ストレージを利用するため、従来までのストレージ環境とは異なるアプローチが必要なケースがあります。
今回取り上げるテーマは以下3点です。
1. 耐障害性(FTT)とそれに伴うホストの台数について
2. メンテナンスモードへの移行について
3. 運用上の推奨事項(最新のパッチの適用)
なお vSAN には色々と専門用語があります。
以下リファレンスに記載の内容も併せてご覧ください。
参考： vSAN の用語および定義
1. 耐障害性(FTT)とそれに伴うホストの台数について
vSAN ではストレージポリシーを利用して、仮想マシンの耐障害性を管理しています。この耐障害性とはホスト/コンポーネントに同時に何台まで障害が発生しても可用性を担保できる、という設定です。耐障害性は FTT (failures to tolerate) と表現されます。デフォルトのストレージポリシーの設定では FTT=1と設定されており、1つのホスト/コンポーネントに障害が発生した場合でも可用性は担保されます。
vSAN では仮想マシンの構成ファイルやディスクなどをオブジェクトという単位で管理しています。このオブジェクトはコンポーネントの集合体として構成され、FTT によってコンポーネントの数が調整されます。
例えば、FTT=1 の場合に必要なホストの台数について考えてみます。
FTT=1とするとデータを保持しているコンポーネントが 2 つ、コンポーネントを監視する役割をもつ Witness コンポーネントが 1 つ作成されます。各コンポーネントが vSAN クラスタ内のホスト上に分散して配置されるため、最低 3 台のホストが vSAN 構成で必要となります。
ホスト/コンポーネントに障害が発生した場合には、通常対象のホストに保持されていたコンポーネントについては別のホストで再構築が行われます。しかし 3 台のみの場合、別のホストへのコンポーネントの再構築ができず、冗長性が失われます。そのため、障害が発生したホストの復旧が早急に必要となります。ホスト/コンポーネントに障害が発生した場合でも冗長性を保つためのデータの移行先が存在するように、最低 1 台分余裕を持たせて vSAN 環境を構築することをおすすめします。
例： FTT=1 、ホスト4台構成における障害発生時の動作
2. メンテナンスモードへの移行について
トラブルシューティングや ESXi ホストのメンテナンスで、ESXi ホストの停止/再起動をするケースがあります。
vSAN では各 ESXi ホスト毎に仮想マシンのコンポーネントを分散して保持しています。ESXi ホストを停止するとコンポーネントへのアクセスが出来ず、稼働中の仮想マシンへ影響を及ぼしてしまう可能性があります。ESXi ホスト停止時には、このコンポーネントの保持を考慮した操作が必要です。
ESXi ホスト停止時には事前にメンテナンスモードに移行しますが vSAN 環境ではこのデータの可用性をコントロールできるように、メンテナンスモードに 3 つのオプションが用意されています。
- 全データ移行
このオプションはメンテナンス対象の ESXi ホスト上の全てのコンポーネントを他の ESXi ホストへ移行するオプションとなります。
対象の ESXi ホスト上のコンポーネントを他 ESXi ホストへ移動させるため、データ量に応じて時間がかかります。移行時には事前にコンポーネントの移動が可能かどうかの計算をしますが、移動ができない場合メンテナンスモードへの移行ができません。
FTT=1 として ESXi ホスト 3 台で構築した場合、このオプションを使用したメンテナンスモードへの移行ができません。
- アクセシビリティの確保
このオプションはメンテナンス対象の ESXi ホスト上のコンポーネントにアクセスできなくなった場合、オブジェクトの可用性の担保ができるかどうかを内部的に計算し、必要なコンポーネントのみ他のESXi ホストに移動させます。そのため全データ移行と比較すると、データの移動量は少なくて済みます。全データの移行と同様に計算の結果移動ができないと判断された場合、メンテナンスモードへの移行ができません。
図： アクセシビリティの確保によるメンテナンスモード移行時の動作例
図を用いて具体的な例を説明いたします。メンテナンス対象のESXiホスト(B)上にコンポーネントを持つオブジェクトにおいて、ESXiホスト(A)上にアクセスできるコンポーネントが存在しているので、メンテナンスモードへの移行時にメンテナンス対象の ESXi ホスト(B)上に保持されているコンポーネントの移動は発生しません。
メンテナンス中の ESXi ホスト(B)上のコンポーネントへのアクセスができない状況が発生しますが、その他アクセスできるコンポーネントが ESXi ホスト(A)に存在するため、コンポーネントの移動が発生することなくメンテナンスモードへ移行します。
更に、ESXi ホスト(A) のメンテナンスモードに移行させる場合は、アクセスできるコンポーネントが無くなるため、コンポーネントの移動が発生します。
いずれの場合も、コンポーネントの冗長性が一時的に失われていますが仮想マシンの動作に問題はありません。この状態のコンポーネントは、特定の時間内 (デフォルト60分)にて復旧することを想定しています。時間内にコンポーネントが復旧せず、コンポーネントの移動先が存在する場合は、コンポーネントの再構成処理を試みます。
参考： vSAN コンポーネントの障害状態
一般にアクセシビリティの確保を利用してメンテナンスモードへの移行を実施するユースケースは、パッチの適用など、一時的に ESXi ホストを停止する場合です。
- データ移行無し
このオプションは特にデータを移動させずメンテナンスモードに移行します。そのためメンテナンスモードへの移行は3つのオプションの中で一番早く終了しますが、データの可用性は担保されません。
このオプションは、vSAN クラスタ内の仮想マシンを全て停止した状態で ESXi ホストを全台同時にメンテナンスするような場合に使用します。
参考：
日本語版：
* vCenter Server が VSAN の最上部で実行しているときに VSAN 6.0 クラスタをシャットダウンおよびパワーオンする (2144517)
英語版：
* Shutting down and powering on a vSAN 6.x Cluster when vCenter Server is running on top of vSAN (2142676)
-メンテナンスモード移行時の注意点
一般にメンテナンスモードへの移行のスピードについては以下となります。
[遅い] ： 全データ移行 > アクセシビリティの確保 > データ移行無し ： [早い]
一部の ESXi ホストをメンテナンスモードに移行する際には、データの完全な保全といった観点では全データ移行によるメンテナンスモードをおすすめします。限られた時間にてメンテナンスを実施する必要がある場合はアクセシビリティの確保にてメンテナンスモードへの移行をご検討頂ければと思います。
なお注意すべき点があり、vSAN データストアでは、vSAN クラスタへ参加している ESXi ホストがメンテナンスモードへ移行してしまうと vSAN 全体で利用できる容量が一時的に少なくなってしまいます。
vSAN では 70% 未満の利用率に留めて運用いただくことを推奨しています。
小規模な環境にて vSAN クラスタを組まれている場合は、メンテナンスモードに移行する際データ容量が逼迫する可能性があるため、ある程度余裕を持った運用をお願いします。
参考： vSAN での容量の計画
3. 運用上の推奨事項 (最新のパッチ適用)
vSphere 環境と同様に vSAN 環境でも最新のパッチでは多数の修正を含んでいます。vSAN に関する修正は、vSphere のパッチに含まれております。vSphere 6.0 では vSphere 6.0 patch 5 以降、vSphere 6.5 では vSphere 6.5 patch 2 以降にて vSAN に関する障害報告が少なくなっています。最新バージョンで修正された問題が顧客環境で発生し、重要障害として対応したケースも少なくありません。
既知の問題で深刻な事象が発生し、ビジネスに影響を与えるといったことがないように、 vSAN 環境については特に最新のバージョンへのアップデートをお願いいたします。
|
