整合性制御
変更を提案
PDF
整合性制御では、アプリケーションでの必要に応じて、オブジェクトの可用性と、異なるストレージノード間およびサイト間でのオブジェクトの整合性のどちらかを犠牲にしなければなりません。
StorageGRID では、デフォルトで、新しく作成したオブジェクトのリードアフターライト整合性が保証されます。正常に完了した PUT に続く GET では、新しく書き込まれたデータを読み取ることができます。既存のオブジェクトの上書き、メタデータの更新、および削除の整合性レベルは、結果整合性です。上書きは通常、数秒から数分で反映されますが、最大で 15 日かかることがあります。
別の整合性レベルでオブジェクトの処理を実行する場合は、各バケットまたは各 API 処理に対して整合性制御を指定できます。
整合性制御
整合性制御は、 StorageGRID がオブジェクトの追跡に使用するメタデータがノード間に分散される方法、つまりクライアント要求で使用できるオブジェクトの有無に影響します。
バケットまたは API 処理の整合性制御は、次のいずれかの値に設定できます。
| 整合性制御 | 説明 |
|---|---|
すべて |
すべてのノードが即座にデータを受け取り、受け取れない場合は要求が失敗します。 |
strong-global |
すべてのサイトのすべてのクライアント要求について、リードアフターライト整合性が保証されます。 |
strong-site |
1 つのサイト内のすべてのクライアント要求について、リードアフターライト整合性が保証されます。 |
read-after-new-write の場合 |
（デフォルト）新規オブジェクトにはリードアフターライト整合性を、オブジェクトの更新には結果整合性を提供します。高可用性が確保され、データ保護が保証されます。Amazon S3の整合性に相当します。
|
available （ HEAD 処理は結果整合性） |
「 read-after-new-write 」整合性レベルと動作は同じですが、 HEAD 処理については結果整合性のみを提供します。ストレージ・ノードが使用できない場合 ' リードアフター・新規ライトよりもヘッド操作の可用性が高くなりますAmazon S3 の整合性と異なるのは HEAD 処理のみです。 |
「read-after-new-write」および「available」整合性制御を使用する
HEAD操作またはGET操作で「read-after-new-write」整合性制御を使用する場合、またはGET操作で「available」整合性制御を使用する場合、StorageGRID は次のように複数の手順で検索を実行します。
-
まず、低い整合性レベルを使用してオブジェクトを検索します。
-
このルックアップが失敗すると、最も高い整合性レベル「 all 」に到達するまで、次の整合性レベルでルックアップが繰り返されます。このとき、オブジェクトメタデータのすべてのコピーが使用可能になります。
HEAD 操作または GET 操作で「 read-after-new-write 」整合性制御が使用されているが、オブジェクトが存在しない場合、オブジェクトの検索は常に「 all 」整合性レベルに到達します。この整合性レベルでは、オブジェクトのメタデータのすべてのコピーが利用可能である必要があるため、使用できないストレージノードがあると、 500 Internal Server Error が大量に発生する場合があります。
Amazon S3と同様の整合性の保証が必要でない限り、整合性制御を「available」に設定することで、HEAD処理でのこれらのエラーを防ぐことができます。HEAD処理で「available」整合性制御を使用すると、StorageGRID は結果整合性のみを提供します。整合性レベルが「 all 」に達するまで失敗した処理は再試行されないため、オブジェクトメタデータのすべてのコピーが利用可能である必要はありません。
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 ルールと次の整合性レベル設定の 2 サイトグリッドがあるとします。
-
* ILM ルール * ：ローカルサイトとリモートサイトに 1 つずつ、 2 つのオブジェクトコピーを作成します。Strict 取り込み動作が選択されています。
-
* 整合性レベル *:"Strong-GLOBAL" ( オブジェクトメタデータはすべてのサイトにただちに分散されます )
クライアントがオブジェクトをグリッドに格納すると、 StorageGRID は両方のオブジェクトをコピーし、両方のサイトにメタデータを分散してからクライアントに成功を返します。
オブジェクトは、取り込みが成功したことを示すメッセージが表示された時点で損失から完全に保護されます。たとえば、取り込み直後にローカルサイトが失われた場合、オブジェクトデータとオブジェクトメタデータの両方のコピーがリモートサイトに残っています。オブジェクトを完全に読み出し可能にしている。
代わりに同じILMルールと「strong-site」整合性レベルを使用する場合は、オブジェクトデータがリモートサイトにレプリケートされたあとで、オブジェクトメタデータが分散される前に、クライアントに成功メッセージが送信される可能性があります。この場合、オブジェクトメタデータの保護レベルがオブジェクトデータの保護レベルと一致しません。取り込み直後にローカルサイトが失われると、オブジェクトメタデータが失われます。オブジェクトを読み出すことができません。
整合性レベルと ILM ルールの間の関係は複雑になる可能性があります。サポートが必要な場合は、ネットアップにお問い合わせください。