Nutanixの回復力 - パート 6 - CVMのメンテナンスや障害時のWrite I/Oについて | Nutanix Community
Skip to main content

 本記事は2018年6月8日に Josh Odgers 氏が投稿した記事の翻訳版です。

原文はこちら。本シリーズの牽引はこちら

 

パート5では、CVMのメンテナンスや障害時のI/Oの処理方法について説明しましたが、今度は同じメンテナンスや障害シナリオでWrite I/Oを処理するという、間違いなくより困難で重要なタスクを説明する必要があります。

パート5をお読みになった方であれば、この次のセクションがよくわかると思います。パート5を読んでいない方は、ぜひ読んでいただきたいのですが、ここではNutanix ADSFがどのようにデータを書き込み、保護するのかという基本的なことを簡単に説明します。

 

以下の図を見ると、3ノードのクラスターに1台の仮想マシンがあります。仮想マシンはa,b,c,dで表されるデータを書き込んでいます。通常の状況では、すべての書き込みは、1つのレプリカが仮想マシンを実行しているホスト(この場合はノード1)に書き込まれ、他のレプリカ(RF3の場合は1つまたは複数)はディスク適合性の値に基づいてクラスター全体に分配されます。ディスクの適合性の値(私は「インテリジェント・レプリカ・プレースメント」と呼んでいます)は、容量とパフォーマンスに基づいて、データが最初から最適な場所に配置されることを保証します。

 

 

クラスターに1つ以上のノードが追加された場合、インテリジェント・レプリカ・プレースメントは、クラスターがバランスの取れた状態になるまで、それらのノード数に比例して多くのレプリカを(分散して)送信します。万が一、新たな書き込みが発生しなかった場合でも、ADSFにはバックグラウンドでディスクバランスをとるプロセスがあり、低い優先度でクラスター内のバランスをとります。

 

Nutanixが複数のレプリカを使用してデータを保護する方法(「レジリエンシーファクター(RF)」と呼ばれるもの)の基本がわかったところで、Nutanix ADSFストレージ層のアップグレード時に何が起こるかについて説明します。

 

アップグレードはワンクリックで開始され、設定されたレジリエンシーファクター(RF)やイレイジャーコーディング (EC-X) の使用の有無に関わらず、一度に1つのコントローラVM (CVM)をローリング方式で実行します。ローリングアップグレードでは、一度に1つのCVMをオフラインにしてアップグレードを実行し、セルフチェックを行った後にクラスターに復帰させ、次のCVMで同じプロセスを繰り返すだけです。

 

Nutanixがストレージをハイパーバイザーから切り離している(カーネルにストレージを組み込まない)ことの多くの利点の1つは、アップグレードやストレージ層の障害であっても、稼働中の仮想マシンに影響を与えないことです。

 

VMの再起動(HAイベントのようなもの)や他のノードへの移行(vMotionなど)の必要がありません。ローカルコントローラが何らかの理由でオフラインになった場合でも、VMのストレージ処理は中断することなく継続されます。

 

ローカルCVMがメンテナンスや故障で停止した場合、書き込みI/Oはクラスター全体に動的に再配置されます。

 

VMのローカルにあるCVMが(何らかの理由で)オフラインになったときの書き込みI/Oを見てみましょう。

 

ローカルのCVMがオフラインになるということは、物理ドライブ(NVMe、SSD、HDDなど)が利用できず、ローカルのデータ(レプリカ)が利用できないことを意味します。

 

すべての書き込みI/Oは継続して機能し、設定されたレジリエンシーファクター(RF)に準拠しますが、1つ目のレプリカがローカルに書き込まれるのではなく、他のレプリカと同様にネットワーク経由でリモートCVMに書き込まれます。

 

以下の例では、3ノードで構成されているため、ノード1のVMがネットワーク経由でノード2と3に「E」のレプリカを書き込んでいます。このようにして、新しいデータが配置されます。

 

 

 

クラスター内にもっと多くのノードが存在する場合、書き込みトラフィックはインテリジェント・レプリカ・プレースメントを使用して、以下のようにクラスター内のすべてのノードに均等に分散されます。

 

 

データ(新しいデータではなく既存のデータ)が上書きされる際に、CVMがオフラインであるためにローカルレプリカが利用できない場合、Nutanixは利用可能なレプリカを上書きし、クラスタ内の別のノードに2つ目(RF3の場合は3つ目)のコピーを書き込むことで、データの整合性が維持されるようにします。

 

 

これは、データが常にレジリエンシーファクター(VMware vSANの場合はFTT)に準拠して維持されていない場合、その続のドライブやノードの障害によってデータが失われてしまうため、非常に重要なことです。

NutanixvSANに対して持っている主な回復力の優位性は、全ての障害やメンテナンスシナリオの間も含めて、設定されたレジリエンシーファクター(RF)に常に準拠している事です。しかし、vSANは、すべてのホストのメンテナンスや障害のシナリオにおいて、設定されたFTTレベルを維持しません。 FTT=1で構成されたvSAN上のVMでは、1つのvSANディスク「オブジェクト」のホストがメンテナンスのためにオフラインになった場合、新しい上書きは保護されないため、1台のドライブの故障でデータが失われる可能性があります。

 

VMware社のチーフテクノロジストであるDuncan Epping氏は、先日、 「vSAN 6.2 : 今後FTT=2をデフォルトにする理由」と題した記事を掲載し、vSANのお客様にFTT=2を新しいデフォルトとして推奨しています。

 

Duncan氏に同意せざるを得ません。しかし、私は「vSANはFTT=2に設定するのがおすすめです」とは言わないでしょう。そうではなく「vSANは必ずFTT=2に設定しなければなりません」と言います。なぜならFTT=1ではメンテナンスや障害時の上書き処理で単一障害点が発生するからです。これはほとんどの本番ワークロードでは受け入れられません。VDIは数少ない例外になり得ますが。

 

一方、Nutanixには、vSANのようなアーキテクチャ上の欠陥はなく、そのため、RF2は非常に回復力が高く、このシリーズで説明したように、最も重要な環境にも適しています。

 

また、 ADSFがこのようにタイムリーに回復させることができるため、 RF2はvSAN FTT=1と比べてはるかに優れた回復力を持っていると言えます。

 

次のパートでは、ハイパーバイザー(ESXi、Hyper-V、XenServer、AHV)のアップグレード時にVMがどのような影響を受けるかという、非常に重要なトピックを取り上げます。

 

まとめ:

  1. ローカルCVMがオフラインになっても書き込みI/Oは中断されない
  2. インテリジェント・レプリカ・プレースメントにより、書き込みI/Oがクラスター全体に均等に分散される
  3. すべての新しいデータは、設定されたレジリエンシーファクター(RF)に準拠して書き込まれる。
  4. 既存データの上書きは、元のレプリカが利用できない場所に新しいレプリカを書き込むことで、常に設定されたレジリエンシーファクター(RF)に準拠して書き込まれる。
  5. データの整合性は、CVM のメンテナンス中や故障に関わらず、常に維持される。
  6. Nutanix RF2は、vSAN FTT=1と比較して、データのコピーを2つ保持するとしているにもかかわらず、より高い回復力を持っている。 
Be the first to reply!

Reply