イレイジャーコーディングデータのリバランシングに関する考慮事項
-
このドキュメント ページのPDF
-
アプライアンスハードウェアを設置して保守します
-
ソフトウェアをインストールしてアップグレードする
-
システム管理を実行する
-
![](/ja-jp/storagegrid-116/images/pdf-zip.png)
PDF版ドキュメントのセット
Creating your file...
ストレージノードを追加するために拡張を実行する際に、 ILM ポリシーにデータをイレイジャーコーディングするための ILM ルールが 1 つ以上含まれている場合は、拡張完了後に EC のリバランシング手順 の実行が必要になることがあります。
たとえば、使用しているイレイジャーコーディングスキームに推奨される数のストレージノードを追加できない場合は、追加のイレイジャーコーディングオブジェクトの格納を許可するために、 EC のリバランシング手順 の実行が必要になることがあります。
これらの考慮事項を確認したら、拡張を実行し、に進みます ストレージノードの追加後にイレイジャーコーディングデータをリバランシングします をクリックして手順 を実行します。
EC のリバランシングとは何ですか?
EC のリバランシングは、ストレージノードの拡張後に必要になる可能性がある StorageGRID 手順 です。手順 は、プライマリ管理ノードからコマンドラインスクリプトとして実行されます。EC Rebalance 手順 を実行すると、 StorageGRID は、サイト内の既存および新しく拡張されたストレージノード間でイレイジャーコーディングフラグメントを再配分します。
EC のリバランシング手順 :
-
イレイジャーコーディングされたオブジェクトデータのみを移動します。レプリケートされたオブジェクトデータは移動されません。
-
サイト内のデータを再配布します。サイト間でデータを移動することはありません。
-
サイトのすべてのストレージノードにデータを再配分します。ストレージボリューム内でデータが再配置されることはありません。
-
では、イレイジャーコーディングデータの移動先を決定する際に、各ストレージノードでのレプリケートされたデータの使用量は考慮されません
EC Rebalance 手順 が完了すると、次のようになります。
-
イレイジャーコーディングされたデータは、使用可能なスペースが少ないストレージノードから、使用可能なスペースが多いストレージノードに移動されます。
-
EC のリバランシング手順 によってレプリケートされたオブジェクトコピーが移動されないため、ストレージノード間で使用済み( % )値が異なるままになることがあります。
-
イレイジャーコーディングオブジェクトのデータ保護は変更されません。
EC のリバランシング手順 が実行されている場合、 ILM 処理と S3 および Swift クライアント処理のパフォーマンスに影響する可能性があります。そのため、この手順 は限られた場合にのみ実行してください。
EC のリバランシングを実行しない場合
EC のリバランシングを実行する必要がない状況の例としては、次の点を考慮してください。
-
StorageGRID は、 3 つのストレージノードで構成される単一サイトで実行されています。
-
ILM ポリシーでは、 1.0 MB を超えるすべてのオブジェクトに 2+1 のイレイジャーコーディングルールを使用し、サイズの小さいオブジェクトには 2-copy レプリケーションルールを使用します。
-
すべてのストレージノードがいっぱいになり、 Major 重大度レベルで * Low Object Storage * アラートがトリガーされています。推奨される方法は、拡張手順 を実行してストレージノードを追加することです。
この例でサイトを拡張するには、新しいストレージノードを 3 つ以上追加することを推奨します。StorageGRID では、 2 つのデータフラグメントと 1 つのパリティフラグメントを別々のノードに配置できるように、 2+1 イレイジャーコーディング用に 3 つのストレージノードが必要です。
3 つのストレージノードを追加したあとも、元のストレージノードはいっぱいになりますが、オブジェクトは引き続き新しいノード上の 2+1 イレイジャーコーディングスキームに取り込むことができます。この場合、 EC Rebalance 手順 を実行することは推奨されません。手順 を実行すると、パフォーマンスが一時的に低下し、クライアントの処理に影響する可能性があります。
![3 ノード拡張後の使用済みスペース](../media/used_space_after_3_node_expansion.png)
EC のリバランシングを実行するタイミング
EC のリバランシングを行う手順 の例としては、同じ例を考えてみてください。ただし、ストレージノードを 2 つしか追加できないとします。2+1 イレイジャーコーディングには少なくとも 3 つのストレージノードが必要であるため、新しいノードをイレイジャーコーディングデータに使用することはできません。
![2 ノード拡張後の使用済みスペース](../media/used_space_after_2_node_expansion.png)
この問題 を解決して新しいストレージノードを利用するには、 EC Rebalance 手順 を実行します。この手順 を実行すると、 StorageGRID によって、イレイジャーコーディングされたデータフラグメントとパリティフラグメントがサイト内のすべてのストレージノードに再配分されます。この例では、 EC Rebalance 手順 が完了すると、 5 つのノードすべてが 60% フルになり、すべてのストレージノード上の 2+1 イレイジャーコーディングスキームにオブジェクトを引き続き取り込むことができます。
![EC の再バランスに使用した容量](../media/used_space_after_ec_rebalance.png)
EC のリバランシングの要件
一般に、 EC Rebalance 手順 は限られた場合にのみ実行してください。具体的には、次の条件がすべて当てはまる場合にのみ EC のリバランシングを実行する必要があります。
-
オブジェクトデータにイレイジャーコーディングを使用します。
-
Low Object Storage * アラートがトリガーされました。このアラートは、ノードが 80% 以上フルであることを示します。
-
使用中のイレイジャーコーディングスキームに推奨される数の新しいストレージノードを追加することはできません。を参照してください イレイジャーコーディングオブジェクトのストレージ容量を追加します。
-
S3 / Swift クライアントは、 EC のリバランシング手順 が実行されている間の書き込み処理と読み取り処理のパフォーマンスの低下を許容できます。
EC のリバランシングが手順 と他のメンテナンスタスクと連携する仕組み
特定のメンテナンス手順を、 EC Rebalance 手順 の実行中に同時に実行することはできません。
手順 | EC のリバランシングで許可される手順 ? |
---|---|
追加の EC リバランシング手順 |
いいえ 一度に実行できる EC のリバランシング手順 は 1 つだけです。 |
手順 の運用を停止 EC データの修復ジョブ |
いいえ
|
Expansion 手順 の略 |
いいえ 拡張時に新しいストレージノードを追加する必要がある場合は、すべての新しいノードを追加するまで、 EC Rebalance 手順 を実行します。新しいストレージノードの追加時に EC Rebalance 手順 が進行中の場合、それらのノードにデータは移動されません。 |
手順 をアップグレードします |
いいえ StorageGRID ソフトウェアをアップグレードする必要がある場合は、 EC Rebalance 手順 を実行する前または実行したあとにアップグレード手順 を実行する必要があります。必要に応じて、ソフトウェアアップグレードを実行するために EC Rebalance 手順 を終了できます。 |
アプライアンスノードのクローン手順 |
いいえ アプライアンスストレージノードをクローニングする必要がある場合は、新しいノードを追加してから EC 手順 のリバランシングを実行する必要があります。新しいストレージノードの追加時に EC Rebalance 手順 が進行中の場合、それらのノードにデータは移動されません。 |
Hotfix 手順 の略 |
はい。 StorageGRID ホットフィックスは、 EC Rebalance 手順 の実行中に適用できます。 |
その他のメンテナンス手順 |
いいえ 他のメンテナンス手順を実行する前に、 EC Rebalance 手順 を終了する必要があります。 |
EC のリバランシングが行われる手順 と ILM の相互作用
EC のリバランシング手順 を実行している間は、 ILM を変更して既存のイレイジャーコーディングオブジェクトの場所が変更されないようにしてください。たとえば、別のイレイジャーコーディングプロファイルを持つ ILM ルールは使用しないでください。このよう手順 な ILM の変更が必要になった場合は、 EC のリバランシングを中止します。