イレイジャーコーディングデータのリバランシングに関する考慮事項
拡張を実行してストレージノードを追加し、ILMルールを使用してデータをイレイジャーコーディングする場合、使用しているイレイジャーコーディングスキームに必要な数のストレージノードを追加できない場合は、ECリバランシング手順 の実行が必要になることがあります。
これらの考慮事項を確認したら、拡張を実行し、に進みます "ストレージノードの追加後にイレイジャーコーディングデータをリバランシングします" をクリックして手順 を実行します。
EC のリバランシングとは何ですか?
EC のリバランシングは、ストレージノードの拡張後に必要になる可能性がある StorageGRID 手順 です。手順 は、プライマリ管理ノードからコマンドラインスクリプトとして実行されます。ECのリバランシング手順 を実行すると、StorageGRID はサイトの既存のストレージノードと新しく追加したストレージノードにイレイジャーコーディングフラグメントを再配分します。
EC のリバランシング手順 :
-
イレイジャーコーディングされたオブジェクトデータのみを移動します。レプリケートされたオブジェクトデータは移動されません。
-
サイト内のデータを再配布します。サイト間でデータを移動することはありません。
-
サイトのすべてのストレージノードにデータを再配分します。ストレージボリューム内でデータが再配置されることはありません。
-
では、イレイジャーコーディングデータの移動先を決定する際に、各ストレージノードでのレプリケートデータの使用量は考慮されません。
-
各ノードの相対的な容量を考慮せずに、イレイジャーコーディングデータをストレージノード間に均等に再配分します。
-
70%以上使用されているストレージノードにイレイジャーコーディングデータを分散しません。
-
ILM処理およびS3およびSwiftクライアント処理の実行時にパフォーマンスが低下する可能性があります。イレイジャーコーディングフラグメントの再配置には追加のリソースが必要です。
-
イレイジャーコーディングオブジェクトが大量にあるシステムの場合は、複数回の実行が必要になることがあります。リソース使用量を制限するために、ジョブごとに移動の上限が設定されています。
EC Rebalance 手順 が完了すると、次のようになります。
-
イレイジャーコーディングデータは、利用可能なスペースが少ないストレージノードから利用可能なスペースが多いストレージノードに移動されます。
-
イレイジャーコーディングオブジェクトのデータ保護は変更されません。
-
次の2つの理由により、ストレージノード間で使用済み(%)の値が異なる可能性があります。
-
レプリケートオブジェクトコピーは既存のノードのスペースを引き続き消費します。ECのリバランシング手順 では、レプリケートデータは移動されません。
-
すべてのノードでほぼ同じ量のイレイジャーコーディングデータが生成されるにもかかわらず、大容量のノードは小容量のノードに比べて使用率が比較的低くなります。
たとえば、3つの200TBノードがそれぞれ80%使用されたとします(200×0.8=160TB(サイトの場合は480TB)。400TBのノードを追加して手順 のリバランシングを実行すると、すべてのノードにほぼ同じ量のイレイジャーコーディングデータ(480 / 4 = 120TB)が格納されます。ただし、大きいノードの使用済み容量(%)は、小さいノードの使用済み容量(%)よりも少なくなります。
-
イレイジャーコーディングデータをリバランシングするタイミング
次のシナリオを考えてみましょう。
-
StorageGRID は、 3 つのストレージノードで構成される単一サイトで実行されています。
-
ILM ポリシーでは、 1.0 MB を超えるすべてのオブジェクトに 2+1 のイレイジャーコーディングルールを使用し、サイズの小さいオブジェクトには 2-copy レプリケーションルールを使用します。
-
すべてのストレージノードが完全にいっぱいになりました。Low Object Storage *アラートがMajor重大度レベルでトリガーされました。
十分な数のノードを追加した場合、リバランシングは必要ありません
ECのリバランシングが不要な状況を把握するために、新しいストレージノードを3つ以上追加したとします。この場合、ECリバランシングを実行する必要はありません。元のストレージノードはフルのままですが、新しいオブジェクトは3つの新しいノードを2+1のイレイジャーコーディングに使用します。2つのデータフラグメントと1つのパリティフラグメントを別 々 のノードに格納できます。
この場合、ECのリバランシング手順 は実行できますが、既存のイレイジャーコーディングデータを移動するとグリッドのパフォーマンスが一時的に低下し、クライアント処理に影響する可能性があります。 |
十分な数のノードを追加できない場合は、リバランシングが必要です
ECのリバランシングが必要な状況を把握するために、ストレージノードを3つではなく2つしか追加できないとします。2+1スキームでは、利用可能なスペースを確保するために少なくとも3つのストレージノードが必要であるため、空のノードを新しいイレイジャーコーディングデータに使用することはできません。
新しいストレージノードを使用するには、EC Rebalance手順 を実行する必要があります。この手順 を実行すると、StorageGRID はサイトのすべてのストレージノードに既存のイレイジャーコーディングデータフラグメントとパリティフラグメントを再配分します。この例では、 EC Rebalance 手順 が完了すると、 5 つのノードすべてが 60% フルになり、すべてのストレージノード上の 2+1 イレイジャーコーディングスキームにオブジェクトを引き続き取り込むことができます。
ECのリバランシングに関する推奨事項
次のステートメントの_all_が当てはまる場合、ECのリバランシングが必要になります。
-
オブジェクトデータにイレイジャーコーディングを使用します。
-
Low Object Storage * アラートがトリガーされました。このアラートは、ノードが 80% 以上フルであることを示します。
-
使用中のイレイジャーコーディングスキームに使用する十分な数の新しいストレージノードを追加できません。を参照してください "イレイジャーコーディングオブジェクトのストレージ容量を追加します"。
-
S3 / Swift クライアントは、 EC のリバランシング手順 が実行されている間の書き込み処理と読み取り処理のパフォーマンスの低下を許容できます。
ストレージノードをほぼ同じレベルに配置し、S3およびSwiftクライアントでECのリバランシング手順 の実行中も書き込み処理と読み取り処理のパフォーマンス低下に対応できる場合は、必要に応じてECのリバランシング手順 を実行できます。
EC のリバランシングが手順 と他のメンテナンスタスクと連携する仕組み
ECリバランシング手順 を実行するときに一部のメンテナンス手順を実行することはできません。
手順 | EC のリバランシングで許可される手順 ? |
---|---|
追加の EC リバランシング手順 |
いいえ 一度に実行できる EC のリバランシング手順 は 1 つだけです。 |
手順 の運用を停止 EC データの修復ジョブ |
いいえ
|
Expansion 手順 の略 |
いいえ 拡張時に新しいストレージノードを追加する必要がある場合は、すべての新しいノードを追加したあとにECリバランシング手順 を実行します。 |
手順 をアップグレードします |
いいえ StorageGRID ソフトウェアをアップグレードする必要がある場合は、EC rebalance手順 の実行前または実行後にアップグレード手順 を実行します。必要に応じて、ソフトウェアアップグレードを実行するために EC Rebalance 手順 を終了できます。 |
アプライアンスノードのクローン手順 |
いいえ アプライアンスストレージノードをクローニングする必要がある場合は、新しいノードの追加後にECリバランシング手順 を実行します。 |
Hotfix 手順 の略 |
はい。 StorageGRID ホットフィックスは、 EC Rebalance 手順 の実行中に適用できます。 |
その他のメンテナンス手順 |
いいえ 他のメンテナンス手順を実行する前に、 EC Rebalance 手順 を終了する必要があります。 |
EC のリバランシングが行われる手順 と ILM の相互作用
EC のリバランシング手順 を実行している間は、 ILM を変更して既存のイレイジャーコーディングオブジェクトの場所が変更されないようにしてください。たとえば、イレイジャーコーディングプロファイルが異なるILMルールは使用しないでください。このようなILMの変更が必要な場合は、ECのリバランシング手順 を終了する必要があります。