Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

StorageGRID におけるクラウドストレージプールの要件と制限

クラウドストレージプールを使用して StorageGRID システムからオブジェクトを移動する場合は、クラウドストレージプールの設定と使用に関する考慮事項を確認する必要があります。

一般的な考慮事項

  • 一般的に、Amazon S3 Glacier や Azure Blob ストレージなどのクラウドアーカイブストレージは、オブジェクトデータを安価に保存できる場所です。ただし、クラウドアーカイブストレージからデータを取り出すコストは比較的高額です。全体的なコストを最小限に抑えるには、クラウドストレージプール内のオブジェクトにいつ、どのくらいの頻度でアクセスするかを考慮する必要があります。クラウドストレージプールは、アクセス頻度が低いと予想されるコンテンツにのみ使用することをお勧めします。

  • クラウドストレージプールターゲットからオブジェクトを取得する際のレイテンシが増加するため、FabricPoolでクラウドストレージプールを使用することはサポートされていません。

  • S3オブジェクトロックが有効になっているオブジェクトは、クラウドストレージプールに配置できません。

  • S3 Object Lock と以下のプラットフォーム、認証、プロトコルの組み合わせは、Cloud Storage Pool ではサポートされていません。

    • プラットフォーム:Google Cloud Platform および Azure

    • 認証タイプ:匿名アクセス

    • プロトコル: HTTP

クラウドストレージプールで使用するポートに関する考慮事項

ILMルールが指定されたクラウドストレージプールとの間でオブジェクトを移動できるようにするには、システムのストレージノードを含むネットワークを構成する必要があります。以下のポートがクラウドストレージプールと通信できることを確認する必要があります。

デフォルトでは、クラウドストレージプールは以下のポートを使用します:

  • 80: http で始まるエンドポイント URI の場合

  • 443:https で始まるエンドポイント URI の場合

クラウドストレージプールを作成または編集する際に、別のポートを指定できます。

非透過型のプロキシ サーバを使用する場合は、インターネット上のエンドポイントなどの外部エンドポイントにメッセージを送信できるようにするために、"ストレージ プロキシの設定"も必要です。

費用に関する考慮事項

クラウドストレージプールを使用してクラウド上のストレージにアクセスするには、クラウドへのネットワーク接続が必要です。クラウドストレージプールを使用して StorageGRID とクラウド間で移動するデータ量に基づいて、クラウドへのアクセスに使用するネットワーク インフラのコストを考慮し、適切にプロビジョニングする必要があります。

StorageGRID が外部のクラウドストレージプールエンドポイントに接続すると、接続状況を監視し、必要な操作を実行できることを確認するために、さまざまなリクエストを発行します。これらのリクエストには追加費用が発生しますが、クラウドストレージプールの監視費用は、S3 や Azure にオブジェクトを保存する際の総費用のほんの一部に過ぎません。

外部のクラウドストレージプールエンドポイントから StorageGRID にオブジェクトを移動する必要がある場合は、より大きなコストが発生する可能性があります。次のいずれかの場合、オブジェクトは StorageGRID に移動される可能性があります:

  • オブジェクトの唯一のコピーがクラウドストレージプールにある場合、代わりにStorageGRIDにオブジェクトを保存することができます。この場合は、ILMのルールとポリシーを再構成します。ILM評価が行われると、StorageGRIDはクラウドストレージプールからオブジェクトを取得するために複数のリクエストを発行します。StorageGRIDは次に、指定された数のレプリケートコピーまたはイレイジャーコーディングコピーをローカルに作成します。オブジェクトがStorageGRIDに戻された後、クラウドストレージプール内のコピーは削除されます。

  • ストレージノードの障害により、オブジェクトが失われました。オブジェクトの唯一の残存コピーがクラウドストレージプールにある場合、StorageGRID はオブジェクトを一時的に復元し、復旧したストレージノード上に新しいコピーを作成します。

メモ オブジェクトをクラウドストレージプールから StorageGRID に戻す場合、StorageGRID は各オブジェクトに対してクラウドストレージプールエンドポイントに複数のリクエストを発行します。大量のオブジェクトを移動する前に、所要時間と関連費用の見積もりについてテクニカルサポートにお問い合わせください。

S3: クラウドストレージプールバケットに必要な権限

クラウドストレージプールに使用される外部 S3 バケットのポリシーは、StorageGRID がオブジェクトをバケットに移動したり、オブジェクトのステータスを取得したり、必要に応じて Glacier ストレージからオブジェクトを復元したりするための権限を付与する必要があります。理想的には、StorageGRID はバケットへのフルコントロールアクセス権を持つべきです (s3:*)。ただし、これが不可能な場合は、バケットポリシーで StorageGRID に次の S3 権限を付与する必要があります:

  • s3:AbortMultipartUpload

  • s3:DeleteObject

  • s3:GetObject

  • s3:ListBucket

  • s3:ListBucketMultipartUploads

  • s3:ListMultipartUploadParts

  • s3:PutObject

  • s3:RestoreObject

S3:外部バケットのライフサイクルに関する考慮事項

StorageGRID とクラウドストレージプールで指定された外部 S3 バケット間のオブジェクトの移動は、ILM ルールと StorageGRID のアクティブな ILM ポリシーによって制御されます。一方、クラウドストレージプールで指定された外部 S3 バケットから Amazon S3 Glacier または S3 Glacier Deep Archive (または Glacier ストレージクラスを実装するストレージソリューション)へのオブジェクトの移行は、そのバケットのライフサイクル設定によって制御されます。

クラウドストレージプールからオブジェクトを移行する場合は、外部S3バケットに適切なライフサイクル構成を作成し、Glacierストレージクラスを実装してS3 RestoreObject APIをサポートするストレージソリューションを使用する必要があります。

たとえば、StorageGRID からクラウドストレージプールに移動されたすべてのオブジェクトを、直ちに Amazon S3 Glacier ストレージに移行したいとします。外部 S3 バケットに、以下のように単一のアクション(Transition)を指定するライフサイクル設定を作成します。

<LifecycleConfiguration>
  <Rule>
    <ID>Transition Rule</ID>
    <Filter>
       <Prefix></Prefix>
    </Filter>
    <Status>Enabled</Status>
    <Transition>
      <Days>0</Days>
      <StorageClass>GLACIER</StorageClass>
    </Transition>
  </Rule>
</LifecycleConfiguration>

このルールは、すべてのバケットオブジェクトが作成された日(つまり、StorageGRID からクラウドストレージプールに移動された日)に Amazon S3 Glacier に移行します。

注意 外部バケットのライフサイクルを設定する際は、オブジェクトの有効期限を定義するために Expiration アクションを使用しないでください。有効期限アクションを実行すると、外部ストレージシステムは有効期限切れのオブジェクトを削除します。後で StorageGRID から有効期限切れのオブジェクトにアクセスしようとしても、削除されたオブジェクトは見つかりません。

Cloud Storage Pool 内のオブジェクトを(Amazon S3 Glacier ではなく)S3 Glacier Deep Archive に移行する場合は、バケットのライフサイクルで `<StorageClass>DEEP_ARCHIVE</StorageClass>`を指定してください。ただし、S3 Glacier Deep Archive からオブジェクトを復元するために `Expedited`ティアは使用できないことに注意してください。

Azure:アクセス層に関する考慮事項

Azure ストレージ アカウントを構成する際に、既定のアクセス ティアを Hot または Cool に設定できます。クラウド ストレージ プールで使用するストレージ アカウントを作成する場合は、デフォルトのティアとして Hot ティアを使用する必要があります。StorageGRID はオブジェクトをクラウド ストレージ プールに移動する際にティアを即座に Archive に設定しますが、デフォルト設定として Hot を使用することで、30 日間の最低期間が経過する前に Cool ティアから削除されたオブジェクトに対して早期削除料金が請求されないことが保証されます。

Azure:ライフサイクル管理はサポートされていません

クラウドストレージプールで使用されるコンテナーには、Azure Blob ストレージのライフサイクル管理を使用しないでください。ライフサイクル操作は、クラウドストレージプールの操作に干渉する可能性があります。