整合性
変更を提案
PDF
整合性では、オブジェクトの可用性と、異なるストレージノードおよびサイト間でのオブジェクトの整合性のバランスが維持されます。アプリケーションの必要に応じて整合性を変更できます。
デフォルトでは、 StorageGRID は新しく作成されたオブジェクトの書き込み後の読み取り一貫性を保証します。正常に完了した PUT に続く GET では、新しく書き込まれたデータを読み取ることができます。既存のオブジェクトの上書き、メタデータの更新、および削除は、最終的に一貫性が保たれます。
別の整合性でオブジェクトの処理を実行する場合は、次の操作を実行できます。
整合性の値
一貫性は、 StorageGRID がオブジェクトを追跡するために使用するメタデータがノード間でどのように分散されるかに影響します。一貫性は、クライアント要求に対するオブジェクトの可用性に影響します。
バケットまたはAPI処理の整合性は、次のいずれかの値に設定できます。
-
* all *：すべてのノードがオブジェクトメタデータをただちに受信しないと要求が失敗します。
-
強力なグローバル: すべてのサイトにわたるすべてのクライアント要求の書き込み後の読み取り一貫性を保証します。クォーラム セマンティクスが構成されている場合、次の動作が適用されます。
-
グリッドに 3 つ以上のサイトがある場合、クライアント要求に対するサイト障害許容度を許可します。 2 サイト グリッドではサイト障害の許容度はありません。
-
1 つのサイトがダウンすると、次の S3 操作は成功しません。
-
DeleteBucketEncryption
-
PutBucketBranch
-
PutBucketEncryptionの略
-
PutBucketVersioning
-
PutObjectLegalHold
-
PutObjectLockConfiguration
-
PutObjectRetention
-
-
-
* 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-operation-consistency-control]] API処理の整合性を指定します。
個 々 のAPI処理に対して整合性を設定するには、処理でサポートされている整合性の値を要求ヘッダーで指定する必要があります。この例では、GetObject処理の整合性を「strong-site」に設定しています。
GET /bucket/object HTTP/1.1 Date: date Authorization: authorization name Host: host Consistency-Control: strong-site
|
PutObject処理とGetObject処理では、同じ整合性を使用する必要があります。 |
バケットの一貫性を指定する
バケットに整合性を設定するには、StorageGRID要求を使用し"PUT Bucket consistency"ます。または、Tenant Managerから実行することもできます"バケットの整合性を変更する"。
バケットに整合性を設定する場合は、次の点に注意してください。
-
バケットに整合性を設定することで、バケット内のオブジェクトまたはバケット設定に対して実行されるS3処理に使用する整合性が決まります。バケット自体に対する処理には影響しません。
-
個 々 のAPI処理の整合性がバケットの整合性よりも優先されます。
-
通常、バケットではデフォルト整合性の「Read-after-new-write」を使用する必要があります。要求が正しく動作しない場合は、可能であればアプリケーションクライアントの動作を変更します。または、API要求ごとに整合性を指定するようにクライアントを設定します。バケットレベルの整合性は最後の手段として設定してください。
一貫性とILMルールの相互作用がデータ保護にどのように影響するか
選択した整合性とILMルールは、どちらもオブジェクトの保護方法に影響します。これらの設定は対話的に操作できます。
たとえば、オブジェクトの格納時に使用される整合性はオブジェクトメタデータの初期配置に影響し、ILMルールで選択された取り込み動作はオブジェクトコピーの初期配置に影響します。StorageGRIDでは、クライアント要求に対応するためにオブジェクトのメタデータとそのデータの両方にアクセスする必要があるため、整合性と取り込み動作で同じ保護レベルを選択すると、初期データ保護が向上し、システム応答の予測性が向上します。
ILMルールで使用できる項目は次の"取り込みオプション"とおりです。
- デュアルコミット
-
StorageGRIDはオブジェクトの中間コピーをただちに作成し、クライアントに成功を返します。可能な場合は、 ILM ルールで指定されたコピーが作成されます。
- strict
-
クライアントに成功が返される前に、ILMルールで指定されたすべてのコピーが作成されている必要があります。
- バランス
-
StorageGRIDは、取り込み時にILMルールで指定されたすべてのコピーの作成を試みます。作成できない場合は中間コピーが作成され、クライアントに成功が返されます。可能な場合は、 ILM ルールで指定されたコピーが作成されます。
整合性とILMルールの相互作用の例
次の ILM ルールと次の一貫性を持つ 3 つのサイト グリッドがあるとします。
-
ILM ルール: ローカル サイトに 1 つ、各リモート サイトに 1 つ、合計 3 つのオブジェクト コピーを作成します。厳密な取り込み動作を使用します。
-
一貫性: 強力なグローバル (オブジェクト メタデータは複数のサイトに即座に配布されます)。
クライアントがオブジェクトをグリッドに保存すると、 StorageGRID は3 つのオブジェクト コピーをすべて作成し、メタデータを複数のサイトに配布してから、クライアントに成功を返します。
オブジェクトは、取り込み成功メッセージの時点で損失から完全に保護されます。たとえば、取り込み直後にローカル サイトが失われた場合でも、オブジェクト データとオブジェクト メタデータの両方のコピーがリモート サイトに残ります。オブジェクトは他のサイトから完全に取得可能です。
代わりに同じ ILM ルールと強力なサイト一貫性を使用した場合、オブジェクト データがリモート サイトにレプリケートされた後、オブジェクト メタデータがそこに配布される前に、クライアントは成功メッセージを受信する可能性があります。この場合、オブジェクト メタデータの保護レベルは、オブジェクト データの保護レベルと一致しません。取り込み直後にローカル サイトが失われた場合、オブジェクト メタデータは失われます。オブジェクトを取得できません。
整合性ルールとILMルールの関係は複雑になる可能性があります。サポートが必要な場合は、NetAppにお問い合わせください。