Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

一貫性の値

一貫性は、オブジェクトの可用性と、異なるストレージ ノードおよびサイト間でのオブジェクトの一貫性との間のバランスを提供します。アプリケーションの必要に応じて一貫性を変更できます。

デフォルトでは、 StorageGRID は新しく作成されたオブジェクトの書き込み後の読み取り一貫性を保証します。正常に完了した PUT に続く GET では、新しく書き込まれたデータを読み取ることができます。既存のオブジェクトの上書き、メタデータの更新、および削除は、最終的に一貫性が保たれます。上書きが反映されるまでには通常数秒または数分かかりますが、最大 15 日かかる場合があります。

異なる一貫性でオブジェクト操作を実行する場合は、次の操作を実行できます。

  • 一貫性を指定する各バケツ

  • 一貫性を指定する各API操作

  • 次のいずれかのタスクを実行して、グリッド全体のデフォルトの一貫性を変更します。

    • グリッド マネージャーで、構成 > システム > ストレージ設定 > デフォルトの一貫性 に移動します。

    • メモ グリッド全体の一貫性の変更は、設定の変更後に作成されたバケットにのみ適用されます。変更の詳細を確認するには、次の場所にある監査ログを参照してください。 /var/local/log (*consistencyLevel*を検索してください)。

一貫性の値

一貫性は、 StorageGRID がオブジェクトを追跡するために使用するメタデータがノード間でどのように分散されるかに影響し、したがってクライアント要求に対するオブジェクトの可用性に影響します。

バケットまたは API 操作の一貫性を次のいずれかの値に設定できます。

  • すべて: すべてのノードがデータを直ちに受信します。そうでない場合、要求は失敗します。

  • 強力なグローバル: すべてのサイトにわたるすべてのクライアント要求の書き込み後の読み取り一貫性を保証します。

  • 強力なサイト: サイト内のすべてのクライアント要求に対して、書き込み後の読み取りの一貫性を保証します。

  • 新規書き込み後の読み取り: (デフォルト) 新しいオブジェクトに対して書き込み後の読み取りの一貫性を提供し、オブジェクトの更新に対して最終的な一貫性を提供します。高可用性とデータ保護の保証を提供します。ほとんどの場合に推奨されます。

  • 利用可能: 新しいオブジェクトとオブジェクトの更新の両方に対して最終的な一貫性を提供します。 S3 バケットの場合は、必要な場合にのみ使用してください (たとえば、めったに読み取られないログ値を含むバケットの場合や、存在しないキーに対する HEAD または GET 操作の場合など)。 S3 FabricPoolバケットではサポートされていません。

「新規書き込み後の読み取り」と「利用可能」の一貫性を使用する

HEAD または GET 操作で「Read-after-new-write」一貫性を使用する場合、 StorageGRID は次のように複数のステップで検索を実行します。

  • まず、低い一貫性を使用してオブジェクトを検索します。

  • その検索が失敗した場合、strong-global の動作と同等の一貫性に達するまで、次の一貫性値での検索を繰り返します。

HEAD または GET 操作で「新規書き込み後の読み取り」一貫性が使用され、オブジェクトが存在しない場合は、オブジェクトの検索は常に strong-global の動作と同等の一貫性に到達します。この一貫性を保つには、各サイトでオブジェクト メタデータの複数のコピーが使用可能である必要があるため、同じサイトにある 2 つ以上のストレージ ノードが使用できない場合、多数の 500 内部サーバー エラーが発生する可能性があります。

Amazon S3 と同様の一貫性の保証が必要ない場合は、一貫性を「利用可能」に設定することで、HEAD および GET 操作でこれらのエラーを防ぐことができます。 HEAD または GET 操作で「使用可能」な一貫性が使用される場合、 StorageGRID は最終的な一貫性のみを提供します。一貫性が増すにつれて失敗した操作を再試行することはないため、オブジェクト メタデータの複数のコピーが利用可能である必要はありません。

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 バケットの一貫性"リクエスト。あるいは"バケットの一貫性を変更する"テナントマネージャーより。

バケットの一貫性を設定するときは、次の点に注意してください。

  • バケットの一貫性を設定すると、バケット内のオブジェクトまたはバケット設定に対して実行される S3 操作に使用される一貫性が決まります。バケット自体の操作には影響しません。

  • 個々の API 操作の一貫性は、バケットの一貫性よりも優先されます。

  • 一般に、バケットではデフォルトの一貫性である「新規書き込み後の読み取り」を使用する必要があります。リクエストが正しく機能しない場合は、可能であればアプリケーション クライアントの動作を変更します。または、各 API リクエストの一貫性を指定するようにクライアントを構成します。最後の手段としてのみ、バケット レベルで一貫性を設定します。

一貫性とILMルールがどのように相互作用してデータ保護に影響を与えるか

一貫性の選択と ILM ルールの両方が、オブジェクトの保護方法に影響します。これらの設定は相互作用する可能性があります。

たとえば、オブジェクトの保存時に使用される一貫性は、オブジェクト メタデータの初期配置に影響し、ILM ルールに選択された取り込み動作は、オブジェクト コピーの初期配置に影響します。 StorageGRID はクライアントの要求を満たすためにオブジェクトのメタデータとそのデータの両方にアクセスする必要があるため、一貫性と取り込み動作に一致する保護レベルを選択すると、初期データ保護が向上し、システム応答がより予測可能になります。

次の"取り込みオプション"ILM ルールに使用できるもの:

Dual commit

StorageGRID は直ちにオブジェクトの中間コピーを作成し、クライアントに成功を返します。 ILM ルールで指定されたコピーは、可能な場合に作成されます。

厳しい

クライアントに成功が返される前に、ILM ルールで指定されたすべてのコピーを作成する必要があります。

バランスの取れた

StorageGRID は、取り込み時に ILM ルールで指定されたすべてのコピーを作成しようとします。これが不可能な場合は、中間コピーが作成され、クライアントに成功が返されます。 ILM ルールで指定されたコピーは、可能な場合に作成されます。

一貫性とILMルールがどのように相互作用するかの例

次の ILM ルールと次の一貫性を持つ 2 つのサイト グリッドがあるとします。

  • ILM ルール: ローカル サイトとリモート サイトに 1 つずつ、合計 2 つのオブジェクト コピーを作成します。厳密な取り込み動作を使用します。

  • 一貫性: 強力なグローバル (オブジェクト メタデータはすべてのサイトに直ちに配布されます)。

クライアントがオブジェクトをグリッドに保存すると、 StorageGRID は両方のオブジェクトのコピーを作成し、両方のサイトにメタデータを配布してから、クライアントに成功を返します。

オブジェクトは、取り込み成功メッセージの時点で損失から完全に保護されます。たとえば、取り込み直後にローカル サイトが失われた場合でも、オブジェクト データとオブジェクト メタデータの両方のコピーがリモート サイトに残ります。オブジェクトは完全に取得可能です。

代わりに同じ ILM ルールと強力なサイト一貫性を使用した場合、オブジェクト データがリモート サイトにレプリケートされた後、オブジェクト メタデータがそこに配布される前に、クライアントは成功メッセージを受信する可能性があります。この場合、オブジェクト メタデータの保護レベルは、オブジェクト データの保護レベルと一致しません。取り込み直後にローカル サイトが失われた場合、オブジェクト メタデータは失われます。オブジェクトを取得できません。

一貫性と ILM ルール間の相互関係は複雑になる可能性があります。サポートが必要な場合は、 NetAppにお問い合わせください。