Nutanixの回復力 – パート 4 – RF3からイレイジャーコーディング(EC-X)への変換

  • 1 September 2021
  • 0 replies
  • 44 views

Userlevel 3

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

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

 

これまでの本シリーズの過程で、クラスタはRF2からRF3へと変換されている状態です。ここで、お客様は回復力に影響を与えることなく、容量効率の向上を図りたいと考えています。ここから我々はイレイジャーコーディング(EC-X)を有効化する際のプロセスとそのスピードについて見ていこうと思います。

 

これまでに議論してきたように、NutanixEC-Xはバックグラウンドタスクとして動作し、そしてWrite Cold(上書きの頻度が小さい)データのみを対象として実行されます。つまり、構成されているRF処理が通常通り完了し、そしてさらにポストプロセスとしてEC-Xの処理が行われます。これは初回の書き込みI/Oにクラスタ内の数多くのノードの参加が必要になることで、書き込みのプロセスが遅くなってしまわないことを保証するためです

 

Nutanix EC-Xの実装についての更に詳しい情報については私の「Nutanix – Erasure Coding (EC-X) Deep Dive」という記事をご参照ください。

 

What I/O will Nutanix Erasure coding (EC-X) take effect on? (Nutanixのイレイジャーコーディング(EC-X)はどのようなI/Oに対して適用されますか?)」:

良いご質問です、Write Coldデータのみです。ですから、EC-Xでの削減効果はデータが徐々にColdになってゆき、NutanixのADSFのCuratorスキャンが低優先度タスクとしてバックグラウンドで変換を行っていくに従って時とともに向上していきます。

 

ADSFのRF2/3からEC-Xストライプへの変換の速さは? :

極端な話をすれば、本シリーズの最初の部分で示したとおり、ハードウェアとして搭載されたドライブが可能な速さで行なえます、ですが、EC-Xは容量を削減するためのテクノロジーで、データをリスクに晒すものではないため、例えばノードやドライブの障害時の動作と同じ速さでやる意味はありません。

 

ですから、内部的な「ErasureCode:Encode(イレイジャーコード:エンコード)」タスクの優先順位は以下に示すとおり3で、それに対し、ノード/ドライブ障害時のタスクは1に設定されています。

 

 

もしもお客様がデータをできる限り早くエンコードしたいという場合には、ソフトウェア上の制限を取り払い、キュレーターがクラスタで実施できる限り多くのバックグラウンドI/Oを行うことができるようにする「curator maintenance mode(Curatorメンテナンスモード)」を有効にすることを含め多くの方法がありますが、これはNutanixのサポートの監督のもとでのみ利用されるべきです。ですから、ここで公にどのように行うかを共有することはいたしません。

以下はEC-Xを適用した後のスループットとストレージプールの利用率です。中間での谷間ができている理由は私がEC-XをバックグラウンドのCuratorスキャン経由で有効にしたため、データの一部が変換されました。その後、マニュアルで別にCuratorのフルスキャンを開始させ、これによって5GBps以上の一貫して高いスループットでジョブが完了しています。

 

 

以下のとおり、キャパシティの最適化の結果は1.97 : 1となっています。これは論理的に最大の2:1とほぼ一致します。EC-Xがほぼ最大の効果を達成できる理由としては、検証の最中にクラスタ上にアクティブなワークロードがなかった結果、全てのデータが「Write Cold」となり、EC-Xによってストライプされる対象となったからです。

 

 

ですから、全体として37.7TBのデータセットを読み込み、4+2のEC-Xストライプ(4データ、2パリティ)として18TB程度のスペースを利用するデータを再度書き戻しています。結果として18.54TBの物理ストレージの削減が実現されています。

ちょっとした算数を行うと、37.7TBのデータがADSFで読み込まれて、18TBのEC-Xのストライプを書き込むということは、90分足らずでトータルで56TBものIOADSF実施したお異なります。

 

サマリ:

  • Nutanix EC-XはRF3と比べ追加の書き込みペナルティなく、最適な書き込み性能を保証する一方で、同様の回復力レベル内で最大2倍のキャパシティ効率性を提供します
  • ADSFはその分散ストレージファブリックを利用して効率的にデータストライプを実現します
  • バックグラウンドのEC-Xストライプ化は低優先度タスクとしてフロントエンドの仮想マシンのI/Oへの影響を最小に抑えてあります
  • ADSFはEC-X(バックグラウンド)操作の最中非常に高いスループットを継続することができます
  • RF3とEC-Xを利用することで、最高の回復力とキャパシティ効率を保証することができ、結果としてRAWストレージの66%をキャパシティとして利用することができます(RF3に対して最大2:1の効率) 

0 replies

Be the first to reply!

Reply