Storage Gateway の仕組み(アーキテクチャ) - AWS Storage Gateway

Amazon S3 ファイルゲートウェイのドキュメントはAmazon S3 ファイルゲートウェイとは

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Storage Gateway の仕組み(アーキテクチャ)

以下では、現在利用できる Storage Gateway ソリューションのアーキテクチャ的な概要を紹介します。

ファイルゲートウェイ

ファイルゲートウェイを使用するには、最初にファイルゲートウェイの VM イメージをダウンロードします。次に、ファイルゲートウェイをAWS Management Consoleを使用するか、Storage Gateway API を介して接続します。Amazon EC2 イメージを使用してファイルゲートウェイを作成することもできます。

ファイルゲートウェイを有効化したら、ファイル共有を作成して設定し、この共有を Amazon Simple Storage Service (Amazon S3) バケットに関連付けます。これにより、クライアントがネットワークファイルシステム (NFS) またはサーバーメッセージブロック (SMB) プロトコルを使用してアクセスできるようになります。ファイル共有に書き込まれたファイルは Amazon S3 内のオブジェクトになり、そのパスがキーになります。ファイルとオブジェクトの間には 1 対 1 のマッピングがあり、ファイルを変更するときに、ゲートウェイは Amazon S3 のオブジェクトを非同期的に更新します。Amazon S3 バケット内の既存のオブジェクトは、ファイルシステム内のファイルとして表示され、そのキーはパスになります。オブジェクトは Amazon S3 — サーバー側の暗号化キー (SSE-S3) で暗号化されます。すべてのデータ転送は、HTTPS 経由で実行されます。

このサービスは、ゲートウェイとAWSマルチパート並列アップロードまたはバイト範囲のダウンロードを使用して、利用可能な帯域幅をより有効に活用できます。ローカルキャッシュの目的は、最近アクセスしたデータへの低レイテンシーアクセスを提供し、データ出力の料金を削減することにあります。CloudWatch メトリクスからは、VM でのリソースの使用状況と、AWS。CloudTrail はすべての API コールを追跡します。

ファイルゲートウェイストレージを使用すると、クラウドのワークロードの Amazon S3 への取り込み、バックアップとアーカイブの実行、Amazon Web Services クラウドへのストレージデータの階層化と移行などのタスクを行うことができます。下の図は、Storage Gateway のファイルストレージのデプロイの概要を示しています。

ファイルゲートウェイは、ファイルを Amazon S3 にアップロードするときにファイルを S3 オブジェクトに変換します。File Gateway オブジェクトと S3 オブジェクト上のファイル共有に対して実行されるファイル操作の間のやり取りでは、ファイルとオブジェクト間の変換時に、特定の操作を慎重に検討する必要があります。

一般的なファイル操作によってファイルのメタデータが変更されるため、現在の S3 オブジェクトが削除され、新しい S3 オブジェクトが作成されます。次の表は、ファイル操作の例と S3 オブジェクトへの影響を示しています。

ファイル操作 S3 オブジェクトの影響 ストレージクラスの含意

ファイル名変更

既存の S3 オブジェクトを置き換え、ファイルごとに新しい S3 オブジェクトを作成します。

早期削除手数料および取り出し手数料が適用される場合があります

フォルダの名前変更

既存のすべての S3 オブジェクトを置き換え、フォルダ構造内の各フォルダおよびファイルに対して新しい S3 オブジェクトを作成します。

早期削除手数料および取り出し手数料が適用される場合があります

ファイル/フォルダの権限の変更

既存の S3 オブジェクトを置き換え、ファイルまたはフォルダごとに新しい S3 オブジェクトを作成します。

早期削除手数料および取り出し手数料が適用される場合があります

ファイル/フォルダの所有権の変更

既存の S3 オブジェクトを置き換え、ファイルまたはフォルダごとに新しい S3 オブジェクトを作成します。

早期削除手数料および取り出し手数料が適用される場合があります

ファイルに追加する

既存の S3 オブジェクトを置き換え、ファイルごとに新しい S3 オブジェクトを作成します。

早期削除手数料および取り出し手数料が適用される場合があります

NFS または SMB クライアントによってファイルゲートウェイにファイルが書き込まれると、ファイルゲートウェイはファイルのデータを Amazon S3 にアップロードし、その後にメタデータ(所有者、タイムスタンプなど)をアップロードします。ファイルデータをアップロードすると S3 オブジェクトが作成され、ファイルのメタデータをアップロードすると S3 オブジェクトのメタデータが更新されます。このプロセスでは、オブジェクトの別のバージョンが作成され、2 つのバージョンのオブジェクトが作成されます。S3 バージョニングが有効な場合、両方のバージョンが保存されます。

Amazon S3 にアップロードされた後に NFS または SMB クライアントによってファイルゲートウェイでファイルが変更されると、ファイルゲートウェイはファイル全体をアップロードするのではなく、新しいデータまたは変更されたデータをアップロードします。ファイルを変更すると、新しいバージョンの S3 オブジェクトが作成されます。

ファイルゲートウェイが大きなファイルをアップロードする場合、クライアントがファイルゲートウェイへの書き込みを完了する前に、ファイルの小さなチャンクをアップロードする必要がある場合があります。その理由として、キャッシュ領域を解放したり、ファイル共有への書き込み率が高いことが挙げられます。これにより、S3 バケットで複数バージョンのオブジェクトが作成される可能性があります。

オブジェクトを異なるストレージクラスに移動するライフサイクルポリシーを設定する前に、S3 バケットを監視して、オブジェクトのバージョン数を確認する必要があります。以前のバージョンのライフサイクルの有効期限を設定して、S3 バケット内のオブジェクトのバージョン数を最小限に抑える必要があります。S3 バケット間で同一リージョンレプリケーション (SRR) またはクロスリージョンレプリケーション (CRR) を使用すると、使用するストレージが増加します。

ボリュームゲートウェイ

ボリュームゲートウェイの場合、キャッシュ型ボリュームまたは保管型ボリュームのどちらかを使用できます。

キャッシュ型ボリュームのアーキテクチャ

キャッシュ型ボリュームを使用することで、頻繁にアクセスされるデータはローカルのストレージゲートウェイに保持しながら、Amazon S3 をプライマリデータストレージとして使用できます。キャッシュ型ボリュームは、オンプレミスのストレージインフラストラクチャをスケールする必要性を最小限に抑えます。同時に、アプリケーションからは引き続き、頻繁にアクセスするデータへの低レイテンシーなアクセスが可能になります。作成できるストレージボリュームのサイズは最大 32 TiB で、それを iSCSI デバイスとしてオンプレミスのアプリケーションサーバーにアタッチすることが可能です。ゲートウェイは、書き込まれたデータを Amazon S3 に作成されたストレージボリュームに保存し、最近読み込まれたデータはオンプレミスのストレージゲートウェイのキャッシュに保持して、バッファストレージにアップロードします。

キャッシュ型ボリュームの容量は 1 GiB~32 TiB の範囲で設定できますが、1 GiB 未満の端数は切り上げとなります。キャッシュ型ボリュームに対して設定されているゲートウェイごとに最大 32 個のボリュームがサポートされ、合計ストレージボリュームは最大 1,024 TiB (1 PiB) です。

キャッシュ型ボリュームによるソリューションでは、オンプレミスのアプリケーションデータはすべての Amazon S3 ストレージボリュームに Storage Gateway 保存されます。下の図は、キャッシュ型ボリュームデプロイメントの概要を示しています。

Storage Gateway ソフトウェアアプライアンス (VM) をオンプレミスのデータセンターのホストにインストールして起動したら、AWS Management Consoleを使用して、Amazon S3 にバックアップされたストレージボリュームをプロビジョニングします。ストレージボリュームは、プログラムから Storage Gateway API またはAWSSDK ライブラリ。次に、そのストレージボリュームをオンプレミスのアプリケーションサーバーに iSCSI デバイスとしてマウントします。

さらにオンプレミスのディスクも VM に割り当てます。ここで割り当てたオンプレミスのディスクは、以下の役割を果たします。

  • ゲートウェイがキャッシュストレージとして使用するディスク— アプリケーションがストレージボリュームにデータを書き込むときAWSゲートウェイは、最初にデータをキャッシュストレージに使用されるオンプレミスのディスクに保存します。次に、ゲートウェイはデータを Amazon S3 にアップロードします。キャッシュストレージは、オンプレミスで耐久性の高い保存場所として、アップロードバッファから Amazon S3 へのアップロードを保留中のデータを保存する働きをします。

    また、キャッシュストレージはアプリケーションが最近アクセスしたデータをオンプレミスに保存し、低レイテンシーでアクセスできるようにもします。アプリケーションがデータをリクエストすると、ゲートウェイはまずキャッシュストレージでそのデータを探し、見つからない場合は Amazon S3 をチェックします。

    キャッシュストレージに割り当てるディスク容量を決定するには、次のガイドラインを使用できます。通常、既存のファイルストアサイズの少なくとも 20% をキャッシュストレージとして割り当てる必要があります。また、キャッシュストレージの容量はアップロードバッファより大きくする必要があります。このガイドラインは、Amazon S3 にまだアップロードされていないアップロードバッファのすべてのデータを永続的に保持するために十分なキャッシュストレージを確保するために有効です。

  • ゲートウェイがアップロードバッファとして使用するディスク— Amazon S3 へのアップロードを準備するため、ゲートウェイは受け取ったデータをステージング領域にいったん保存します。アップロードバッファです。ゲートウェイは、暗号化された Secure Sockets Layer (SSL) 接続で、AWSに保存され、Amazon S3 で暗号化されて保存されます。

増分バックアップは、次に使用されているスナップショット、Amazon S3 のストレージボリュームの。こうしたポイントインタイムのスナップショットは、Amazon EBS スナップショットとして Amazon S3 に保存されます。新たにスナップショットをとる際には、前回のスナップショット以降に変更されたデータのみが保存されます。スナップショットは、スケジュールに基づいて、または 1 回のみ実行可能です。スナップショットを削除する場合、他のスナップショットが必要ないデータのみが削除されます。Amazon EBS スナップショットの詳細については、「」を参照してください。Amazon EBS スナップショット

データのバックアップを復元する必要がある場合には、Amazon EBS スナップショットをゲートウェイストレージボリュームに復元できます。また、16 TiB までのスナップショットの場合、新しい Amazon EBS ボリュームの場合は、開始点としてスナップショットを使用できます。次に、この新しい Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチできます。

キャッシュボリューム用のすべてのゲートウェイデータとスナップショットデータは、Amazon S3 に保存され、サーバー側の暗号化 (SSE) 機能を使用して保管時に暗号化されます。ただし、このデータには Amazon S3 API や Amazon S3 マネジメントコンソールなどのツールでアクセスすることはできません。

保管型ボリュームのアーキテクチャ

保管型ボリュームを使用することで、プライマリデータをローカルに保存する一方で、そのデータを非同期にAWS。保管型ボリュームを使用することにより、オンプレミスのアプリケーションがそのデータセット全体に低レイテンシーでアクセスできます。同時に、耐久性のあるオフサイトのバックアップが提供されます。ストレージボリュームを作成し、それを iSCSI デバイスとしてオンプレミスのアプリケーションサーバーからマウントできます。保管型ボリュームに書き込まれたデータは、オンプレミスのストレージハードウェアに保管されます。このデータは Amazon Elastic Block Store (Amazon EBS) スナップショットとして Amazon S3 に非同期でバックアップされます。

保管型ボリュームの容量は 1 GiB~32 TiB の範囲で設定できますが、1 GiB 未満の端数は切り上げとなります。保管型ボリュームに対して設定されるゲートウェイごとに、最大 32 個のボリュームがサポートされ、合計ボリュームストレージは最大 512 TiB (0.5 PiB) です。

保管型ボリュームでは、ボリュームストレージをオンプレミスのデータセンターに維持します。つまり、アプリケーションデータはすべてオンプレミスのストレージハードウェアに保存されます。その後、ゲートウェイはデータセキュリティの維持に役立つ機能を使用して、コスト効率の高いバックアップと迅速な障害復旧のため、Amazon Web Services ラウドにデータをアップロードします。すべてのデータに低レイテンシーでアクセスできる必要があるため、データをオンプレミスに保持したいが、AWS。

下の図は、保管型ボリュームのデプロイの概要を示しています。

Storage Gateway ソフトウェアアプライアンス (VM) をオンプレミスのデータセンターのホストにインストールして起動したら、ストレージボリューム。次に、オンプレミスのダイレクトアタッチドストレージ (DAS) またはストレージエリアネットワーク (SAN) ディスクにマッピングできます。起動は、新規ディスクからでも、すでにデータを保持しているディスクからでも行えます。次に、そのストレージボリュームをオンプレミスのアプリケーションサーバーに iSCSI デバイスとしてマウントします。オンプレミスのアプリケーションがゲートウェイのストレージボリュームに対してデータの読み書きを行う時、そのデータはボリュームに割り当てられたディスクに保存され、読み込まれます。

Amazon S3 にアップロードする前にデータを準備するため、ゲートウェイは受け取ったデータをステージング領域にいったん保存します。アップロードバッファ。作業用ストレージとしてオンプレミスの DAS または SAN ディスクが使用できます。ゲートウェイはデータをアップロードバッファから、暗号化 Secure Sockets Layer (SSL) 接続経由で、アマゾンウェブサービスクラウドで実行される Storage Gateway サービスにアップロードします。次に、サービスは、暗号化されたデータを Amazon S3 に保存します。

ストレージボリュームは、増分バックアップ (スナップショットと呼びます) をとることができます。ゲートウェイは、これらのスナップショットを Amazon EBS スナップショットとして Amazon S3 に保存します。新たにスナップショットをとる際には、前回のスナップショット以降に変更されたデータのみが保存されます。スナップショットは、スケジュールに基づいて、または 1 回のみ実行可能です。スナップショットを削除する場合、他のスナップショットが必要ないデータのみが削除されます。

データのバックアップを復元する必要がある場合には、Amazon EBS スナップショットをオンプレミスのゲートウェイストレージボリュームに復元できます。このスナップショットは、新しい Amazon EBS ボリュームの出発点として使用し、これを Amazon EC2 インスタンスにアタッチすることもできます。

テープゲートウェイ

Tape Gateway は、データを Amazon Web Services クラウドにアーカイブすることで、耐久性が高くコスト効率的なソリューションを提供します。仮想テープライブラリ (VTL) のインターフェイスを使用することで、既存のテープベースのバックアップインフラストラクチャを利用して、テープゲートウェイ上に作成する仮想テープカートリッジにデータを保存できます。各テープゲートウェイには、メディアチェンジャーとテープドライブがあらかじめ組み込まれています。これらは、既存のクライアントバックアップアプリケーションから iSCSI デバイスとして利用できます。データをアーカイブするには、必要に応じてテープカートリッジを追加します。

次の図は、テープゲートウェイデプロイメントの概要を示しています。

この図では、次のテープゲートウェイコンポーネントを特定します。

  • 仮想テープ— 仮想テープは物理テープカートリッジに似ています。ただし、仮想テープデータはAmazon Web Services ラウドに保存されます。物理テープと同様、仮想テープには空白のものもデータが書き込まれたものもあります。仮想テープを作成するには、Storage Gateway コンソールを使うか、プログラムから Storage Gateway API を利用します。ゲートウェイごとに最大 1,500 本のテープ (合計で最大 1 PiB のテープデータ) を保管できます。各仮想テープの容量は、それぞれの作成時に、100 GiB ~ 5 TiB の範囲で設定できます。

  • VTL(仮想テープ・ライブラリ)— VTL は、オンプレミスで利用できる、ロボットアームとテープドライブを備えた物理テープライブラリに似ています。VTL には、保存されている仮想テープのコレクションが含まれています。テープゲートウェイには、VTL が 1 つ組み込まれています。

    仮想テープを作成すると、ゲートウェイの VTL に表示されます。VTL 内のテープは Amazon S3 によってバックアップされます。バックアップソフトウェアがゲートウェイにデータを書き込むと、ゲートウェイはそのデータをローカルに保存した後、VTL 内の仮想テープ (Amazon S3) に非同期的にアップロードします。

    • テープドライブ— VTL テープドライブは物理テープドライブに相当し、テープに対して I/O やシーク操作を行います。各 VTL には、テープドライブが 10 セット組み込まれており、バックアップアプリケーションから iSCSI デバイスとして使用することができます。

    • メディアチェンジャー— VTL メディアチェンジャーは、物理テープライブラリの保管スロットやテープドライブにテープを出し入れするロボットに相当します。各 VTL にはメディアチェンジャーが 1 つ組み込まれており、バックアップアプリケーションから iSCSI デバイスとして使用することができます。

  • アーカイブ— アーカイブは現実でいえばオフサイトのテープ保管施設に相当します。ゲートウェイ VTL からアーカイブに仮想テープをアーカイブできます。必要に応じて、アーカイブからゲートウェイ VTL にテープを取得できます。

    • テープのアーカイブ— バックアップソフトウェアがテープを取り出すと、ゲートウェイは長期保存のためにテープをアーカイブに移動します。アーカイブは、AWSゲートウェイをアクティブ化したリージョン。アーカイブ内のテープは仮想テープシェルフ (VTS) に保存されます。VTSは、S3 GlacierまたはS3 Glacier Deep Archiveデータのアーカイブ、バックアップ、長期データ保持のための低コストのストレージサービスです。

    • テープの取得— アーカイブされたテープは、直接読み取ることができません。アーカイブされたテープを読み込むには、まずテープゲートウェイに回収する必要があります。これには Storage Gateway コンソールまたは Storage Gateway API を使います。

      重要

      テープを GLACIER にアーカイブした場合、通常 3 〜 5 時間以内に取り出すことができます。テープを DEEP_ARCHIVE にアーカイブした場合、通常 12 時間以内に取り出すことができます。

テープゲートウェイをデプロイし起動したら、仮想テープドライブとメディアチェンジャーを iSCSI デバイスとして、オンプレミスのアプリケーションサーバーにマウントします。必要なだけ仮想テープを作成します。次に、既存のバックアップソフトウェアアプリケーションを使ってデータを仮想テープに書き込みます。メディアチェンジャーは仮想テープを仮想テープドライブに装填/排出し、読み書き操作ができるようにします。

ゲートウェイ VM へのローカルディスクの割り当て

ゲートウェイ VM には、以下の目的のために割り当てるローカルディスクが必要です。

  • キャッシュストレージ— キャッシュストレージは、アップロードバッファから Amazon S3 へのアップロードを保留中のデータを保存する、耐久性の高い保管場所となります。

    アプリケーションが仮想テープからデータを読み込むと、そのデータはキャッシュストレージに保存されます。最近アクセスがあったデータもキャッシュストレージに保存され、低レイテンシーでアクセスできるようにします。アプリケーションがテープのデータをリクエストすると、ゲートウェイはまずキャッシュストレージでそのデータを探し、見つからない場合はAWS。

  • アップロードバッファ— アップロードバッファは、データを仮想テープにアップロードする前に、ゲートウェイのステージング領域を提供します。また、アップロードバッファは予期しない障害からテープを復元するための復元ポイントを作成する際にも重要な役割を果たします。詳細については、「正常に機能していないテープゲートウェイから仮想テープを復旧する必要がある」を参照してください。

バックアップアプリケーションがデータをゲートウェイに書き込むと、ゲートウェイはそのデータをキャッシュストレージとアップロードバッファの両方にコピーします。次に、書き込みオペレーションの完了をバックアップアプリケーションに対して確認します。

キャッシュストレージおよびアップロードバッファに割り当てるディスク容量のガイドラインについては、「ローカルディスクストレージの容量の決定」を参照してください。