整合性制御
変更を提案
PDF
整合性制御では、アプリケーションの必要に応じて、オブジェクトの可用性と異なるストレージノードおよびサイト間でのオブジェクトの整合性のバランスを調整できます。
StorageGRID では、デフォルトで、新しく作成したオブジェクトのリードアフターライト整合性が保証されます。正常に完了した PUT に続く GET では、新しく書き込まれたデータを読み取ることができます。既存のオブジェクトの上書き、メタデータの更新、および削除の整合性レベルは、結果整合性です。上書きは通常、数秒から数分で反映されますが、最大で 15 日かかることがあります。
別の整合性レベルでオブジェクトの処理を実行する場合は、各バケットまたは各 API 処理に対して整合性制御を指定できます。
整合性制御
整合性制御は、 StorageGRID がオブジェクトの追跡に使用するメタデータがノード間に分散される方法、つまりクライアント要求で使用できるオブジェクトの有無に影響します。
バケットまたは API 処理の整合性制御は、次のいずれかの値に設定できます。
-
* all *：すべてのノードがすぐにデータを受信しないと、要求は失敗します。
-
* strong-global * ：すべてのサイトにおけるすべてのクライアント要求について、リードアフターライト整合性が保証されます。
-
* strong-site * ： 1 つのサイトにおけるすべてのクライアント要求について、リードアフターライト整合性が保証されます。
-
* read-after-new-write *：（デフォルト）新規オブジェクトにはリードアフターライト整合性が提供され、オブジェクトの更新には結果整合性が提供されます。高可用性が確保され、データ保護が保証されます。ほとんどの場合に推奨されます。
-
* available *：新しいオブジェクトとオブジェクトの更新の両方について、結果整合性を提供します。S3バケットの場合は、必要な場合にのみ使用します（読み取り頻度の低いログ値を含むバケットや、存在しないキーに対するHEAD処理やGET処理など）。S3 FabricPool バケットではサポートされません。
「read-after-new-write」および「available」の整合性制御を使用します
HEAD 操作または GET 操作で「 read-after-new-write 」整合性制御を使用する場合、 StorageGRID は次のように複数の手順で検索を実行します。
-
まず、低い整合性レベルを使用してオブジェクトを検索します。
-
そのルックアップが失敗した場合は、次の整合性レベルでルックアップを繰り返し、strong-globalの動作と同じ整合性レベルに達します。
HEAD処理またはGET処理で「read-after-new-write」整合性制御が使用されているが、オブジェクトが存在しない場合、オブジェクトの検索は常にstrong-globalの動作と同じ整合性レベルに達します。この整合性レベルでは、オブジェクトメタデータの複数のコピーを各サイトで使用できる必要があるため、同じサイトで使用できないストレージノードがあると、「500 Internal Server Error」が大量に発生する可能性があります。
Amazon S3 と同様の整合性の保証が必要でない限り、整合性制御を「 available 」に設定することで、 HEAD 処理と GET 処理でのこれらのエラーを防ぐことができます。 HEAD 操作または GET 操作で「 available 」整合性制御を使用する場合、 StorageGRID は結果整合性のみを提供します。失敗した処理が整合性レベルを上げて再試行されることはないため、オブジェクトメタデータの複数のコピーがある必要はありません。
API 処理に対して整合性制御を指定する
個々の API 処理に対して整合性制御を設定するには、その処理でサポートされている整合性制御を要求ヘッダーで指定する必要があります。次の例では、 GET Object 処理に対して、整合性制御を「 strong-site 」に設定しています。
GET /bucket/object HTTP/1.1 Date: date Authorization: authorization name Host: host Consistency-Control: strong-site
|
PUT Object 処理と GET Object 処理には、同じ整合性制御を使用する必要があります。 |
バケットの整合性制御を指定します
バケットに対して整合性制御を設定するには、 StorageGRID の PUT Bucket 整合性要求および GET Bucket 整合性要求を使用できます。または、 Tenant Manager またはテナント管理 API を使用できます。
バケットの整合性制御を設定する際は、次の点に注意してください。
-
バケットの整合性制御を設定することで、バケット内のオブジェクトまたはバケット設定に対して実行される S3 処理に、どの整合性制御を使用するかを指定できます。バケット自体に対する処理には影響しません。
-
個々の API 処理の整合性制御は、バケットの整合性制御よりも優先されます。
-
通常、バケットはデフォルトの整合性制御「 read-after-new-write 」を使用する必要があります。 要求が正しく機能しない場合は、可能であればアプリケーションクライアントの動作を変更します。または、 API 要求ごとに整合性制御を指定するようにクライアントを設定します。バケットレベルの整合性制御は最後の手段と考えてください。
整合性制御と ILM ルールの相互作用によるデータ保護への影響
整合性制御と ILM ルールのどちらを選択した場合も、オブジェクトの保護方法に影響します。これらの設定は対話的に操作できます。
たとえば、オブジェクトの格納に使用される整合性制御はオブジェクトメタデータの初期配置に影響し、 ILM ルールで選択される取り込み動作はオブジェクトコピーの初期配置に影響します。StorageGRID では、クライアント要求に対応するためにオブジェクトのメタデータとそのデータの両方にアクセスする必要があるため、整合性レベルと取り込み動作に一致する保護レベルを選択することで、より適切な初期データ保護と予測可能なシステム応答を実現できます。
ILM ルールでは、次の取り込み動作を使用できます。
-
* Strict * ： ILM ルールに指定されたすべてのコピーを作成しないと、クライアントに成功が返されません。
-
* Balanced * ： StorageGRID は、取り込み時に ILM ルールで指定されたすべてのコピーを作成しようとします。作成できない場合、中間コピーが作成されてクライアントに成功が返されます。可能な場合は、 ILM ルールで指定されたコピーが作成されます。
-
* デュアルコミット * ： StorageGRID はオブジェクトの中間コピーをただちに作成し、クライアントに成功を返します。可能な場合は、 ILM ルールで指定されたコピーが作成されます。
|
|
ILMルールの取り込み動作を選択する前に、に記載されている設定の完全な概要 をお読みください ILM を使用してオブジェクトを管理する。 |
整合性制御と ILM ルールの連動の例
次の ILM ルールと次の整合性レベル設定の 2 サイトグリッドがあるとします。
-
* ILM ルール * ：ローカルサイトとリモートサイトに 1 つずつ、 2 つのオブジェクトコピーを作成します。Strict 取り込み動作が選択されています。
-
* 整合性レベル *:"Strong-GLOBAL" ( オブジェクトメタデータはすべてのサイトにただちに分散されます )
クライアントがオブジェクトをグリッドに格納すると、 StorageGRID は両方のオブジェクトをコピーし、両方のサイトにメタデータを分散してからクライアントに成功を返します。
オブジェクトは、取り込みが成功したことを示すメッセージが表示された時点で損失から完全に保護されます。たとえば、取り込み直後にローカルサイトが失われた場合、オブジェクトデータとオブジェクトメタデータの両方のコピーがリモートサイトに残っています。オブジェクトを完全に読み出し可能にしている。
代わりに同じ ILM ルールと「 strong-site 」整合性レベルを使用する場合は、オブジェクトデータがリモートサイトにレプリケートされたあとで、オブジェクトメタデータがそこに分散される前に、クライアントに成功メッセージが送信される可能性があります。この場合、オブジェクトメタデータの保護レベルがオブジェクトデータの保護レベルと一致しません。取り込み直後にローカルサイトが失われると、オブジェクトメタデータが失われます。オブジェクトを読み出すことができません。
整合性レベルと ILM ルールの間の関係は複雑になる可能性があります。サポートが必要な場合は、ネットアップにお問い合わせください。