パフォーマンス - AWS Storage Gateway
ファイルゲートウェイのパフォーマンスガイダンステープゲートウェイのパフォーマンスガイダンスゲートウェイのパフォーマンスの最適化VMware High Availability の使用

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

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

パフォーマンス

このセクションでは、Storage Gateway のパフォーマンスについての情報を説明します。

ファイルゲートウェイのパフォーマンスガイダンス

このセクションでは、ファイルゲートウェイ VM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に示されているインスタンスの設定は例であり、参考のために提供されています。

注記

パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。

Amazon EC2 インスタンスの場合、S3 バケット内のオブジェクトが 500 万個を超え、汎用 SSD ボリュームを使用している場合、起動中のゲートウェイで許容できるパフォーマンスを得るには、最小 350 GiB のルート EBS ボリュームが必要です。ボリュームサイズを引き上げる方法については、「Elastic Volumes を使用して EBS ボリュームを変更する (コンソール)」を参照してください。

次に、ファイルゲートウェイの設定例を示します。

Linux クライアントでのファイルゲートウェイのパフォーマンス

設定例 Protocol - 。 書き込みスループット (ファイルサイズ 1 GB) 読み込みスループット 読み込みスループット

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク: 512 GiB キャッシュ、io1、1,500 個のプロビジョンド IOPS

最小ネットワークパフォーマンス: 10 Gbps

CPU: 16 vCPU | RAM: 32 GB

Linuxに推奨されるNFSプロトコル

 NFSv3-1スレッド 110 mib/秒 (0.92 Gbps) 590 MiB/秒 (4.9 Gbps) 310 mib/秒 (2.6 Gbps)
NFSv3-8 スレッド 160 MiB/秒 (1.3 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)
NFSv4-1スレッド 130 mib/秒 (1.1 Gbps) 590 MiB/秒 (4.9 Gbps) 295 MiB/秒 (2.5 Gbps)
NFSv4-8 スレッド 160 MiB/秒 (1.3 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)
SMBV3-1スレッド 115 MiB/秒 (1.0 Gbps) 325 MiB/秒 (2.7 Gbps) 255 Mib/秒 (2.1 Gbps)
SMBV3-8 スレッド 190 mib/秒 (1.6 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)

Storage Gateway ハードウェアアプライアンス

最小ネットワークパフォーマンス: 10 Gbps

 NFSv3-1スレッド 265 MiB/秒 (2.2 Gbps) 590 MiB/秒 (4.9 Gbps) 310 mib/秒 (2.6 Gbps)
NFSv3-8 スレッド 385 Mib/秒 (3.1 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)
NFSv4-1スレッド 310 mib/秒 (2.6 Gbps) 590 MiB/秒 (4.9 Gbps) 295 MiB/秒 (2.5 Gbps)
NFSv4-8 スレッド 385 Mib/秒 (3.1 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)
SMBV3-1スレッド 275 Mib/秒 (2.4 Gbps) 325 MiB/秒 (2.7 Gbps) 255 Mib/秒 (2.1 Gbps)
SMBV3-8 スレッド 455 MiB/秒 (3.8 Gbps) 590 MiB/秒 (4.9 Gbps) 335 MiB/秒 (2.8 Gbps)

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク:4 x 2 TB NVME キャッシュディスク

最小ネットワークパフォーマンス: 10 Gbps

CPU: 32 vCPU | RAM: 244 GB

Linuxに推奨されるNFSプロトコル

 NFSv3-1スレッド 300 MiB/秒 (2.5 Gbps) 590 MiB/秒 (4.9 Gbps) 325 MiB/秒 (2.7 Gbps)
NFSv3-8 スレッド 585 MiB/秒 (4.9 Gbps) 590 MiB/秒 (4.9 Gbps) 580 MiB/秒 (4.8 Gbps)
NFSv4-1スレッド 355 MiB/秒 (3.0 Gbps) 590 MiB/秒 (4.9 Gbps) 340 MiB/秒 (2.9 Gbps)
NFSv4-8 スレッド 575 MiB/秒 (4.8 Gbps) 590 MiB/秒 (4.9 Gbps) 575 MiB/秒 (4.8 Gbps)
SMBV3-1スレッド 230 MiB/秒 (1.9 Gbps) 325 MiB/秒 (2.7 Gbps) 245 MiB/秒 (2.0 Gbps)
SMBV3-8 スレッド 585 MiB/秒 (4.9 Gbps) 590 MiB/秒 (4.9 Gbps) 580 MiB/秒 (4.8 Gbps)

Windows クライアントでのファイルゲートウェイのパフォーマンス

設定例 Protocol - 。 書き込みスループット (ファイルサイズ 1 GB) 読み込みスループット 読み込みスループット

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク: 512 GiB キャッシュ、io1、1,500 個のプロビジョンド IOPS

最小ネットワークパフォーマンス: 10 Gbps

CPU: 16 vCPU | RAM: 32 GB

Windowsに推奨されるSMBプロトコル

 SMBV3-1スレッド 150 MiB/秒 (1.3 Gbps) 180 MiB/秒 (1.5 Gbps) 20 MiB/秒 (0.2 Gbps)
SMBV3-8 スレッド 190 mib/秒 (1.6 Gbps) 335 MiB/秒 (2.8 Gbps) 195 MiB/秒 (1.6 Gbps)
NFSv3-1スレッド 95 MiB/秒 (0.8 Gbps) 130 mib/秒 (1.1 Gbps) 20 MiB/秒 (0.2 Gbps)
NFSv3-8 スレッド 190 mib/秒 (1.6 Gbps) 330 MiB/秒 (2.8 Gbps) 190 mib/秒 (1.6 Gbps)

Storage Gateway ハードウェアアプライアンス

最小ネットワークパフォーマンス: 10 Gbps

 SMBV3-1スレッド 230 MiB/秒 (1.9 Gbps) 255 Mib/秒 (2.1 Gbps) 20 MiB/秒 (0.2 Gbps)
SMBV3-8 スレッド 835 MiB/秒 (7.0 Gbps) 475 MiB/秒 (4.0 Gbps) 195 MiB/秒 (1.6 Gbps)
NFSv3-1スレッド 135 mib/秒 (1.1 Gbps) 185 Mib/秒 (1.6 Gbps) 20 MiB/秒 (0.2 Gbps)
NFSv3-8 スレッド 545 MiB/秒 (4.6 Gbps) 470 MiB/秒 (4.0 Gbps) 190 mib/秒 (1.6 Gbps)

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク:4 x 2 TB NVME キャッシュディスク

最小ネットワークパフォーマンス: 10 Gbps

CPU: 32 vCPU | RAM: 244 GB

Windowsに推奨されるSMBプロトコル

 SMBV3-1スレッド 230 MiB/秒 (1.9 Gbps) 265 MiB/秒 (2.2 Gbps) 30 MiB/秒 (0.3 Gbps)
SMBV3-8 スレッド 835 MiB/秒 (7.0 Gbps) 780 MiB/秒 (6.5 Gbps) 250 mib/秒 (2.1 Gbps)
NFSv3-1スレッド 135 MiB/秒 (1.1. Gbps) 220 MiB/秒 (1.8 Gbps) 30 MiB/秒 (0.3 Gbps)
NFSv3-8 スレッド 545 MiB/秒 (4.6 Gbps) 570 MiB/秒 (4.8 Gbps) 240 MiB/秒 (2.0 Gbps)

テープゲートウェイのパフォーマンスガイダンス

このセクションでは、テープゲートウェイ VM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に示されている Amazon EC2 インスタンスのサイズとタイプは例であり、参考のために提供されています。

  • ファイルゲートウェイはオブジェクトストアキャッシュです。ファイルゲートウェイのパフォーマンス特性は、ファイルサーバーのパフォーマンス特性と異なります。

  • File Gateway は、ワークロードがマルチスレッド化されている（または複数のクライアントを含む）場合に最適にスケーリングされます。Windows エクスプローラ、copy または cp コマンド、/mt スイッチを使用しない robocopy など、多くの基本的なファイル管理ツールがシングルスレッド化されています。これらのツールでは、File Gateway のスケーラビリティを十分に活用することはできません。

  • 最高のパフォーマンスを得るには、スレッドやクライアントを追加してワークロードをスケーリングする必要があります。

  • 複数のスレッドを使用して大きなファイル（それぞれ数十または数百の MiB）を転送する場合、最高のスループット MIB/秒（MIB/秒）が達成されます。

  • 新しいファイル作成のオーバーヘッドにより、多数の小さなファイルを転送すると、大きなファイルを使用する同じワークロードよりもMIB/秒のスループットが低下します。

  • 小さなファイルを転送するときに最高のパフォーマンスを得るには、複数のスレッドやクライアントを使用する必要があります。

  • 小さいファイル転送レートは、で測定することをお勧めします。files-per-secondファイル作成のオーバーヘッドがこのようなワークロードを支配するため、MIB /秒ではありません。

設定 書き込みスループット (Gbps) キャッシュからの読み取りスループット (Gbps) Amazon Web Services から読むクラウドスループット Gbps

ホストプラットフォーム: Amazon EC2 インスタンス — c5.4xlarge

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク: 50 GB、io1 SSD、2000 IOPs

アップロードバッファディスク: 450 GB、io1 SSD、2000 IOPs

CPU: 16 vCPU | RAM: 32 GB

クラウドへのネットワーク帯域幅: 10 Gbps

 2.3 4.0 1.7

ホストプラットフォーム: Storage Gateway ハードウェアアプライアンス

キャッシュディスク: 2.5 TB

アップロードバッファディスク: 2 TB

CPU: 20 コア | RAM: 128 GB

クラウドへのネットワーク帯域幅: 10 Gbps

2.3 4.2 1.4

ホストプラットフォーム: Amazon ec2Instance — c5d.9xlarge

ルートディスク: 80 GB、io1 SSD、4,000 IOPS

キャッシュディスク: 900 GB NVMe ディスク

アップロードバッファディスク: 900 GB NVMe ディスク

CPU: 36 vCPU | RAM: 72 GB

クラウドへのネットワーク帯域幅: 10 Gbps

 5.2 8.2 2.0
注記

このパフォーマンスは、1 MB のブロックサイズと 3 個のテープドライブを同時に使用する場合に達成されます。

パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。

テープゲートウェイの書き込みおよび読み取りスループットのパフォーマンスを向上させるには、「iSCSI 設定を最適化する」、「テープドライブでの大きなブロックサイズの使用」、および「バックアップソフトウェアで仮想テープドライブのパフォーマンスを最適化する」を参照してください。

ゲートウェイのパフォーマンスの最適化

このセクションでは、ゲートウェイのパフォーマンスを最適化する方法について説明します。ガイダンスは、ゲートウェイへのリソースの追加およびアプリケーションサーバーへのリソースの追加に基づいています。

ゲートウェイへのリソースの追加

以下の 1 つ以上の方法でゲートウェイにリソースを追加することで、ゲートウェイのパフォーマンスを最適化できます。

より高性能なディスクの使用

ゲートウェイのパフォーマンスを最適化するには、Solid State Drive (SSD) や NVMe コントローラーなどの高性能のディスクを追加できます。また、Microsoft Hyper-V NTFS ではなく、ストレージエリアネットワーク (SAN) から直接 VM に仮想ディスクをアタッチできます。通常、ディスクパフォーマンスが向上すると、スループットおよび 1 秒あたりの入力/出力操作数 (IOPS) が改善します。

スループットを測定するには、ReadBytes および WriteBytes メトリックスを Samples Amazon CloudWatch 統計と共に使用します。たとえば、5 分間のサンプル期間の ReadBytes メトリックスの Samples 統計を 300 秒で割ると、IOPS がわかります。一般的なルールとして、ゲートウェイのこれらのメトリクスを確認する場合は、ディスク関連のボトルネックを示す低いスループットおよび低い IOPS トレンドを探します。ゲートウェイメトリクスの詳細については、テープゲートウェイとテープゲートウェイの間のパフォーマンスの測定AWS を参照してください。

注記

CloudWatch メトリックスは、すべてのゲートウェイに使用できるわけではありません。ゲートウェイメトリクスについては、「Storage Gateway のモニタリング」を参照してください。

ゲートウェイホストへの CPU リソースの追加

ゲートウェイホストサーバーの最小要件は、4 つの仮想プロセッサです。ゲートウェイのパフォーマンスを最適化するには、ゲートウェイ VM に割り当てられている 4 つの仮想プロセッサが 4 つのコアによってサポートされることを確認します。さらに、ホストサーバーの CPU をオーバーサブスクライブしていないことを確認します。

ゲートウェイホストサーバーに CPU を追加すると、ゲートウェイの処理能力が向上します。これにより、ゲートウェイは、アプリケーションからローカルストレージへのデータの保存とAmazon S3 へのこのデータのアップロードの両方を並行して処理できます。また、CPU を追加すると、ホストが他の VM と共有される場合に、ゲートウェイで十分な CPU リソースを利用できます。十分な CPU リソースを提供することには、スループットを向上させる一般的な効果があります。

Storage Gateway は、ゲートウェイホストサーバーでの 24 個の CPU の使用をサポートしています。24 個の CPU を使用すると、ゲートウェイのパフォーマンスを大幅に向上できます。ゲートウェイホストサーバーのゲートウェイ設定は次のように設定することをお勧めします:

  • 24 個の CPU。

  • ファイルゲートウェイ用の 16 GiB の予約済み RAM

    ボリュームゲートウェイおよびテープゲートウェイの場合は、ハードウェアで次の容量の RAM を専用にする必要があります。

    • 16 TiB までのキャッシュサイズを持つゲートウェイ用の 16 GiB のリザーブド RAM

    • キャッシュサイズが 16 TiB ～ 32 TiB のゲートウェイ用の 32 GiB のリザーブド RAM

    • キャッシュサイズが 32 TiB ～ 64 TiB のゲートウェイ用の 48 GiB のリザーブド RAM

  • 準仮想化コントローラー 1 にアタッチされているディスク 1 (ゲートウェイのキャッシュとして次のように使用する) :

    • NVMe コントローラーを使用する SSD。

  • 準仮想化コントローラー 1 にアタッチされているディスク 2 (ゲートウェイアップロードバッファとして次のように使用する) :

    • NVMe コントローラーを使用する SSD。

  • 準仮想化コントローラー 2 にアタッチされているディスク 3 (ゲートウェイアップロードバッファとして次のように使用する) :

    • NVMe コントローラーを使用する SSD。

  • VM ネットワーク 1 に設定されたネットワークアダプタ 1:

    • VM ネットワーク 1 を使用し、取り込みに使用する VMXnet3 (10 Gbps) を追加する。

  • VM ネットワーク 2 に設定されたネットワークアダプタ 2:

    • VM ネットワーク 2 を使用し、AWS への接続に使用する VMXnet3 (10 Gbps) を追加する。

別の物理ディスクを使用したゲートウェイ仮想ディスクのバックアップ

ゲートウェイのディスクをプロビジョニングする場合は、基になる同じ物理ストレージディスクを使用するアップロードバッファおよびキャッシュストレージ用にローカルディスクをプロビジョニングしないことを強くお勧めします。たとえば、VMware ESXi の場合、基盤となる物理ストレージリソースはデータストアとして表されます。ゲートウェイ VM をデプロイする場合は、VM ファイルを保存するデータストアを選択します。仮想ディスクをプロビジョニングする場合は (アップロードバッファとして使用する場合など)、仮想ディスクを VM と同じデータストアか、別のデータストアに保存できます。

複数のデータストアがある場合は、作成するローカルストレージのタイプごとに 1 つのデータストアを選択することを強くお勧めします。基になる物理ディスク 1 つのみによってサポートされるデータストアでは、パフォーマンスが低下することがあります。たとえば、そのようなディスクを使用して、ゲートウェイ設定のキャッシュストレージとアップロードバッファの両方がサポートされる場合です。同様に、RAID 1 のようなパフォーマンスの低い RAID 構成によってサポートされるデータストアでは、パフォーマンスが低下することがあります。

ボリュームの設定を変更する

ボリュームゲートウェイの場合は、ゲートウェイにボリュームを追加するとゲートウェイへのスループットが低下する場合は、別のゲートウェイにボリュームを追加することを検討してください。特に、ボリュームが高スループットのアプリケーションに使用されている場合は、高スループットのアプリケーション用に別のゲートウェイを作成することを検討してください。ただし、一般的なルールとして、すべての高スループットのアプリケーションに一方のゲートウェイを使用し、すべての低スループットのアプリケーションにもう一方のゲートウェイを使用するといった方法は避けてください。ボリュームのスループットを測定するには、ReadBytes および WriteBytes メトリクスを使用します。

これらのメトリクスの詳細については、アプリケーションとゲートウェイの間のパフォーマンスの測定を参照してください。

iSCSI 設定を最適化する

iSCSI イニシエータの iSCSI 設定を最適化して、I/O パフォーマンスを向上させることができます。MaxReceiveDataSegmentLength と FirstBurstLength には 256 KiB、MaxBurstLength には 1 MiB を選択することをお勧めします。iSCSI 設定の詳細については、「iSCSI 設定のカスタマイズ」を参照してください。

注記

これらの推奨設定により、全体的なパフォーマンスが向上します。ただし、パフォーマンスを最適化するために必要な特定の iSCSI 設定は、使用するバックアップソフトウェアによって異なります。詳細については、バックアップソフトウェアのドキュメントを参照してください。

テープドライブでの大きなブロックサイズの使用

テープゲートウェイの場合は、テープドライブのデフォルトブロックサイズは 64 KB です。ただし、I/O パフォーマンスを向上させるためにブロックサイズを最大 1 MB まで増やすことができます。

選択するブロックサイズは、バックアップソフトウェアがサポートしている最大ブロックサイズによって異なります。バックアップソフトウェアのテープドライブのブロックサイズは、できる限り大きいサイズに設定することをお勧めします。ただし、このブロックサイズは、ゲートウェイがサポートする最大サイズの 1 MB を超えないようにしてください。

テープゲートウェイは、バックアップソフトウェアで設定されているサイズと自動的に一致するように、仮想テープドライブのブロックサイズをネゴシエートします。バックアップソフトウェアのブロックサイズを増やす場合は、設定でホストイニシエータが新しいブロックサイズをサポートしていることを確認することをお勧めします。詳細については、バックアップソフトウェアのドキュメントを参照してください。特定のゲートウェイパフォーマンのガイドについては、「パフォーマンス」を参照してください。

バックアップソフトウェアで仮想テープドライブのパフォーマンスを最適化する

バックアップソフトウェアは、テープゲートウェイの最大 10 個の仮想テープドライブに同時にデータをバックアップできます。テープゲートウェイの 4 個以上の仮想テープドライブを同時に使用するように、バックアップソフトウェアでバックアップジョブを設定することをお勧めします。バックアップソフトウェアが同時に複数の仮想テープにデータをバックアップしていると、書き込みスループットが向上します。

アプリケーション環境へのリソースの追加

アプリケーションサーバーとゲートウェイの間の帯域幅を増やす

ゲートウェイのパフォーマンスを最適化するには、アプリケーションとゲートウェイ間のネットワーク帯域幅が、アプリケーションのニーズを満たすようにしてください。♪ReadBytesそしてWriteBytes総データスループットを測定するためのゲートウェイのメトリック。これらのメトリクスの詳細については、テープゲートウェイとテープゲートウェイの間のパフォーマンスの測定AWSを参照してください。

アプリケーションでは、必要なスループットと測定されたスループットを比較します。測定されたスループットが必要なスループットを下回る場合、アプリケーションとゲートウェイの間の帯域幅を増やすと、ネットワークがボトルネックであれば、パフォーマンスを向上させることができます。同様に、VM とローカルディスクの間の帯域幅を増やすことができます (直接接続されていない場合)。

アプリケーション環境への CPU リソースの追加

アプリケーションが追加の CPU リソースを使用できる場合、CPU の追加はアプリケーションの I/O 負荷の調整に役立つことがあります。

VMware vSphere High Availability の使用

Storage Gateway は、VMware vSphere High Availability (VMware HA) と統合された一連のアプリケーションレベルのヘルスチェックを通じて VMware の高可用性を提供します。このアプローチは、ハードウェア、ハイパーバイザー、またはネットワーク障害からストレージのワークロードを保護するのに役立ちます。また、接続タイムアウトや、ファイル共有またはボリュームを使用できないなどのソフトウェアエラーからの保護にも役立ちます。

この統合により、オンプレミスの VMware 環境または VMware Cloud on AWS 上にデプロイされたゲートウェイは、ほとんどのサービス中断から自動的に回復します。これは通常、60 秒未満でデータ損失なしで行われます。

VMware HA を Storage Gateway で使用するには、次の手順を実行します。

vSphere の VMware HA クラスターの設定

最初に、VMware クラスターをまだ作成していない場合は、作成します。VMware クラスターの作成方法については、VMware のドキュメントの「Create a vSphere HA Cluster」を参照してください。

次に、Storage Gateway で動作するように VMware クラスターを設定します。

VMware クラスターを設定するには

  1. VMware vSphere の [Edit Cluster Settings] ページで、VM のモニタリングが VM とアプリケーションのモニタリング用に設定されていることを確認します。これを行うには、以下の順序でオプションを設定します。

    • ホスト障害応答: VM を再起動します。

    • ホスト分離の応答: VM をシャットダウンして再起動する

    • PDL を使用したデータストア: Disabled

    • [Datastore (データストア)]: Disabled

    • VM モニタリング: [VM およびアプリケーションの監視]

    例については、以下のスクリーンショットを参照してください。

    クラスター設定の更新

  2. 次の値を調整して、クラスターの感度を微調整します。

    • 障害間隔— この間隔の後、VM ハートビートが受信されない場合、VM は再起動されます。

    • 最小稼働時間— クラスターは、VM が VM が VM ツールのハートビートのモニタリングを開始した後でこの時間待機します。

    • [Maximum per-VM]— クラスターは、最大リセット時間枠内で最大数の VM を再起動します。

    • [Maximum Reset]— VM ごとの最大リセット数をカウントする時間枠。

    設定する値がわからない場合は、次の設定例を使用します。

    • [Failure interval]: 30 秒

    • [Minimum uptime]: 120 秒

    • [Maximum per-VM resets]: 3

    • [Maximum resets time window]: 1 時間

クラスターで他の VM が実行されている場合は、VM 専用にこれらの値を設定することもできます。これは、.ova から VM をデプロイするまで実行できません。これらの値の設定の詳細については、「(オプション) クラスター上の他の VM に対する上書きオプションの追加」を参照してください。

ゲートウェイタイプ用の .ova イメージのダウンロード

.ova イメージをダウンロードするには、次の手順を実行します。

ゲートウェイタイプの .ova イメージをダウンロードするには

ゲートウェイのデプロイ

設定したクラスターで、.ova イメージをクラスターのホストの 1 つにデプロイします。

ゲートウェイの .ova イメージをデプロイするには

  1. .ova イメージをクラスター内のホストの 1 つにデプロイします。

  2. ルートディスクおよびキャッシュ用に選択したデータストアが、クラスター内のすべてのホストで使用可能であることを確認します。VMware またはオンプレミス環境にストレージゲートウェイ.ova ファイルを展開する場合、ディスクは準仮想化 SCSI ディスクとして記述されます。ただし、VMware のディスクに pvSCSI アダプタタイプを使用して作成する場合は、AWS管理コンソールは、ディスクを読み取れないことを返します。これに対処するには、代わりにディスクに「LSI Logic SAS」アダプタタイプを使用します。AWS管理コンソールは実際にディスクを認識し、展開を続行できます。

(オプション) クラスター上の他の VM に対する上書きオプションの追加

クラスターで他の VM が実行されている場合は、各 VM 専用にクラスター値を設定することもできます。

クラスター上の他の VM のオーバーライドオプションを追加するには

  1. VMware vSphere の [Summary] ページで、クラスターを選択してクラスターページを開き、[Configure] を選択します。

  2. [Configuration] タブを選択し、[VM Overrides] を選択します。

  3. 新しい VM オーバーライドオプションを追加して、各値を変更します。

    オーバーライドオプションについては、次のスクリーンショットを参照してください。

    クラスター設定のオーバーライド

ゲートウェイのアクティブ化

ゲートウェイの .ova がデプロイされたら、ゲートウェイをアクティブ化します。ゲートウェイの種類ごとの違いについて説明します。

ゲートウェイをアクティブ化するには

VMware High Availability 設定のテスト

ゲートウェイをアクティブ化したら、設定をテストします。

VMware HA 設定をテストするには

  1. でStorage Gateway コンソールを開きます。https://console.aws.amazon.com/storagegateway/home。

  2. ナビゲーションペインで [Gateways] を選択してから、VMware HA をテストするゲートウェイを選択します。

  3. [Actions] で、[Verify VMware HA (VMware HA の確認)] を選択します。

  4. 表示される [Verify VMware High Availability Configuration (VMware High Availability 設定の検証)] ページで、[OK] を選択します。

    注記

    VMware HA 設定をテストすると、ゲートウェイ VM が再起動され、ゲートウェイへの接続が中断されます。テストの完了には数分かかることがあります。

    テストが成功すると、コンソールのゲートウェイの詳細タブに [Verified (検証済み)] というステータスが表示されます。

  5. [終了] を選択します。

Amazon で VMware HA イベントに関する情報があります。CloudWatchロググループ。詳細については、ファイルゲートウェイのヘルスログの取得 CloudWatch ロググループを参照してください。