整合性制御

整合性制御では、アプリケーションでの必要に応じて、ストレージ ノード間およびサイト間でオブジェクトの可用性と整合性のトレードオフを行うことができます。

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

別の整合性レベルでオブジェクトの処理を実行する場合は、各バケットまたは各API処理に対して、整合性制御を指定できます。

整合性制御

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

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

整合性制御 説明
all すべてのノードが即座にデータを受け取り、受け取れない場合は要求が失敗します。
strong-global すべてのサイトのすべてのクライアント要求について、リードアフターライト整合性が保証されます。
strong-site あるサイト内のすべてのクライアント要求について、リードアフターライト整合性が保証されます。
read-after-new-write (デフォルト)新規オブジェクトにはリードアフターライト整合性を、オブジェクトの更新には結果整合性を提供します。高可用性が確保され、データ保護が保証されます。Amazon S3の整合性に相当します。
注: 存在しないオブジェクトに対してアプリケーションがHEAD要求を使用すると、使用できないストレージ ノードがある場合に「500 Internal Server Error」が大量に返される可能性があります。このエラーを回避するには、Amazon S3と同様の整合性の保証が必要ないかぎり、整合性制御をavailableに設定します。
available(HEAD処理は結果整合性) read-after-new-write整合性レベルと動作は同じですが、HEAD処理については結果整合性のみを提供します。ストレージ ノードを使用できない場合に、HEAD処理に対してread-after-new-writeよりも高い可用性が提供されます。Amazon S3の整合性と異なるのはHEAD処理のみです。
weak 結果整合性と高い可用性を提供し、特にストレージ ノードに障害が発生したりストレージ ノードを使用できない場合のデータ保護の保証は最小限です。高可用性を必要とし、リードアフターライト整合性は必要とせず、ノードに障害が発生した場合のデータ損失を許容できる、書き込み負荷の高いワークロードにのみ適しています。

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処理には、同じ整合性制御を使用する必要があります。たとえば、weakを使用して書き込んだオブジェクトをstrong-globalを使用して再度読み取った場合、すべてのサイトにおける強い整合性は保証されません。

バケットに対する整合性制御の指定

バケットに対して整合性制御を設定するには、StorageGRIDのPUT Bucket整合性要求およびGET Bucket整合性要求を使用できます。あるいは、Tenant Managerまたはテナント管理APIを使用できます。

バケットの整合性制御を設定する際は、次の点にご注意ください。

整合性制御とILMルールの相互作用によるデータ保護への影響

整合性制御とILMルールは、どちらもオブジェクトの保護方法に影響します。この2つの設定は相互に作用します。

たとえば、オブジェクトの格納時に使用される整合性制御はオブジェクト メタデータの初期配置に影響し、ILMルールで選択された取り込み動作はオブジェクト コピーの初期配置に影響します。StorageGRIDはクライアント要求に対応するためにオブジェクトのメタデータとデータの両方にアクセスする必要があります。そのため、整合性レベルと取り込み動作で同じ保護レベルを使用すると、初期のデータ保護を適切に実施し、システムの動作をより予測できるようになります。

ILMルールでは、次の取り込み動作を選択できます。
  • Strict:ILMルールで指定されたすべてのコピーが作成されるまで、クライアントに処理の成功は返されません。
  • Balanced:ILMルールで指定されたすべてのコピーの作成が取り込み時にStorageGRIDで試行され、作成できない場合は中間コピーが作成されてクライアントに成功が返されます。可能な場合は、ILMルールで指定されたコピーが作成されます。
  • Dual Commit:オブジェクトの中間コピーがStorageGRIDでただちに作成されてクライアントに成功が返されます。可能な場合は、ILMルールで指定されたコピーが作成されます。
注: ILMルールの取り込み動作にはそれぞれメリットと制限があるため、選択する前にStorageGRIDの管理手順で各オプションの詳細を確認してください。

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

2サイトのグリッドで次のILMルールと整合性レベル設定を使用しているとします。
  • ILMルール:ローカル サイトとリモート サイトに1つずつ、2つのオブジェクト コピーを作成します。取り込み動作はStrictが選択されています。
  • 整合性レベル:strong-global(オブジェクト メタデータがすべてのサイトにただちに分散されます)。
クライアントがこのグリッドにオブジェクトを格納すると、StorageGRIDは両方のオブジェクト コピーを作成し、両方のサイトにメタデータを分散し、その後クライアントに成功を返します。

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

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

整合性レベルとILMルールの関係は複雑になることがあります。サポートが必要な場合は、ネットアップにお問い合わせください。