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

整合性の値

共同作成者
PDF

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

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

別の整合性でオブジェクトの処理を実行する場合は、次の操作を実行できます。

  • 整合性の指定 各バケット。

  • 整合性の指定 各API処理。

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

    • Grid Managerで、[設定]>*>[ストレージ設定]>[デフォルトの整合性]*の順に選択します。

    • 。

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

整合性の値

整合性は、StorageGRIDがオブジェクトの追跡に使用するメタデータがノード間でどのように分散されるかに影響し、その結果、クライアント要求に対するオブジェクトの可用性にも影響します。

バケットまたはAPI処理の整合性は、次のいずれかの値に設定できます。

  • * all *：すべてのノードがすぐにデータを受信しないと、要求は失敗します。

  • * strong-global *：すべてのサイトのすべてのクライアント要求について、リードアフターライト整合性が保証されます。

  • *strong-site *：サイト内のすべてのクライアント要求に対してリードアフターライト整合性が保証されます。

  • * 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ルールで指定されたすべてのコピーが作成されている必要があります。

中間（ Balanced ）

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

整合性とILMルールの相互作用の例

2サイトのグリッドで次のILMルールと整合性が設定されているとします。

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

  • * consistency *：strong-global（オブジェクトメタデータがすべてのサイトに即座に分散されます）。

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

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

同じILMルールでstrong-site整合性を使用した場合、オブジェクトデータがリモートサイトにレプリケートされたあと、オブジェクトメタデータが分散される前にクライアントに成功メッセージが返されることがあります。この場合、オブジェクトメタデータの保護レベルがオブジェクトデータの保護レベルと一致しません。取り込み直後にローカルサイトが失われると、オブジェクトメタデータが失われます。オブジェクトを取得できません。

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