翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
パフォーマンス
このセクションでは、Storage Gateway のパフォーマンスに関する情報を示します。
ファイルゲートウェイのパフォーマンスガイダンス
このセクションでは、ファイルゲートウェイ VM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に示されている Amazon EC2 インスタンスのサイズとタイプは例であり、参考のために提供されています。
最高のパフォーマンスを得るには、キャッシュディスクのサイズをアクティブな作業セットのサイズ合わせる必要があります。キャッシュに複数のローカルディスクを使用すると、データへのアクセスを並列処理することで書き込みパフォーマンスが上がり、IOPS が向上します。
次の表では、キャッシュヒット読み取りオペレーションは、キャッシュから提供されるファイル共有からの読み取りです。キャッシュミス読み取りオペレーションは、Amazon S3 から提供されるファイル共有からの読み取りです。
注記
エフェメラルストレージの使用はお勧めしません。エフェメラルストレージの使用については、「EC2 ゲートウェイでのエフェメラルストレージの使用」を参照してください。
ファイルゲートウェイの設定例を次に示します。
Linux クライアントでの S3 ファイルゲートウェイのパフォーマンス
設定例 | Protocol - 。 | 書き込みスループット (ファイルサイズ 1 GB) | キャッシュヒット読み取りスループット | キャッシュミス読み取りスループット |
---|---|---|---|---|
ルートディスク: 80 GB io1、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) | |
最小ネットワークパフォーマンス: 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、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) | 30MiB/秒 (2.8 Gbps) | 190 mib/秒 (1.6 Gbps) | |
最小ネットワークパフォーマンス: 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) |
注記
パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。
ゲートウェイのパフォーマンスの最適化
このセクションでは、ゲートウェイのパフォーマンスを最適化する方法について説明します。ガイダンスは、ゲートウェイへのリソースの追加およびアプリケーションサーバーへのリソースの追加に基づいています。
ゲートウェイへのリソースの追加
以下の 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 トレンドを探します。注記
CloudWatch メトリックスは、すべてのゲートウェイで使用できるわけではありません。ゲートウェイメトリクスについては、「ファイルゲートウェイの監視」を参照してください。
- ゲートウェイホストへの CPU リソースの追加
-
ゲートウェイホストサーバーの最小要件は、4 つの仮想プロセッサです。ゲートウェイのパフォーマンスを最適化するには、ゲートウェイ VM に割り当てられている 4 つの仮想プロセッサが 4 つのコアによってサポートされることを確認します。さらに、ホストサーバーの CPU をオーバーサブスクライブしていないことを確認します。
ゲートウェイホストサーバーに CPU を追加すると、ゲートウェイの処理能力が向上します。これにより、ゲートウェイは、アプリケーションからローカルストレージへのデータの保存とへのこのデータのアップロードの両方を並行して処理できます。また、CPU を追加すると、ホストが他の VM と共有される場合に、ゲートウェイで十分な CPU リソースを利用できます。十分な CPU リソースを提供することには、スループットを向上させる一般的な効果があります。
Storage Gateway では、ゲートウェイホストサーバーで 24 個の CPU を使用できます。24 個の CPU を使用すると、ゲートウェイのパフォーマンスを大幅に向上できます。ゲートウェイホストサーバーのゲートウェイ設定は次のように設定することをお勧めします:
-
24 個の CPU。
-
ファイルゲートウェイ用の 16 GiB の予約済み 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
総データスループットを測定するためのゲートウェイのメトリック。アプリケーションでは、必要なスループットと測定されたスループットを比較します。測定されたスループットが必要なスループットを下回る場合、アプリケーションとゲートウェイの間の帯域幅を増やすと、ネットワークがボトルネックであれば、パフォーマンスを向上させることができます。同様に、VM とローカルディスクの間の帯域幅を増やすことができます (直接接続されていない場合)。
- アプリケーション環境への CPU リソースの追加
-
アプリケーションが追加の CPU リソースを使用できる場合、CPU の追加はアプリケーションの I/O 負荷の調整に役立つことがあります。
Storage Gateway での VMware vSphere High Availabil
Storage Gateway は、VMware vSphere High Availability (VMware HA) と統合された一連のアプリケーションレベルのヘルスチェックを通じて VMware の高可用性を提供します。このアプローチは、ハードウェア、ハイパーバイザー、またはネットワーク障害からストレージのワークロードを保護するのに役立ちます。また、接続タイムアウトや、ファイル共有またはボリュームを使用できないなどのソフトウェアエラーからの保護にも役立ちます。
この統合により、オンプレミスの VMware 環境または VMware Cloud on AWS 上にデプロイされたゲートウェイは、ほとんどのサービス中断から自動的に回復します。これは通常、60 秒未満でデータ損失なしで行われます。
Storage Gateway で VMware HA を使用するには、次の手順を実行します。
トピック
vSphere の VMware HA クラスターの設定
最初に、VMware クラスターをまだ作成していない場合は、作成します。VMware クラスターの作成方法については、VMware のドキュメントの「Create a vSphere HA Cluster
次に、Storage Gateway で動作するように VMware クラスターを設定します。
VMware クラスターを設定するには
-
VMware vSphere の [Edit Cluster Settings] ページで、VM のモニタリングが VM とアプリケーションのモニタリング用に設定されていることを確認します。これを行うには、以下の順序でオプションを設定します。
-
ホスト障害レスポンス: VM を再起動します。
-
ホスト分離の応答: VM をシャットダウンして再起動する
-
PDL を使用したデータストア: Disabled
-
APD を使用したデータストア: Disabled
-
VM モニタリング: VM およびアプリケーションの監視
例については、以下のスクリーンショットを参照してください。
-
-
次の値を調整して、クラスターの感度を微調整します。
-
障害間隔— この間隔の後、VM ハートビートが受信されない場合、VM は再起動されます。
-
最小稼働時間— クラスターは、VM が VM ツールのハートビートのモニタリングを開始してからこの時間を長く待機します。
-
VM ごとの最大リセット— クラスターは、最大リセット時間枠内で最大数の VM を再起動します。
-
[Maximum restets— 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 イメージを、次のいずれかからダウンロードします。
-
ファイルゲートウェイ —
-
ゲートウェイのデプロイ
設定したクラスターで、.ova イメージをクラスターのホストの 1 つにデプロイします。
ゲートウェイの .ova イメージをデプロイするには
-
.ova イメージをクラスター内のホストの 1 つにデプロイします。
-
ルートディスクとキャッシュ用に選択したデータストアが、クラスター内のすべてのホストで使用可能であることを確認します。
(オプション) クラスター上の他の VM に対する上書きオプションの追加
クラスターで他の VM が実行されている場合は、各 VM 専用にクラスター値を設定することもできます。
クラスター上の他の VM のオーバーライドオプションを追加するには
-
VMware vSphere の [Summary] ページで、クラスターを選択してクラスターページを開き、[Configure] を選択します。
-
[Configuration] タブを選択し、[VM Overrides] を選択します。
-
新しい VM オーバーライドオプションを追加して、各値を変更します。
オーバーライドオプションについては、次のスクリーンショットを参照してください。
ゲートウェイのアクティブ化
ゲートウェイの .ova がデプロイされたら、ゲートウェイをアクティブ化します。ゲートウェイの種類ごとの違いについて説明します。
ゲートウェイをアクティブ化するには
-
ゲートウェイの種類に基づいてアクティベーションの手順を選択します。
-
ファイルゲートウェイ —
-
VMware High Availability 設定のテスト
ゲートウェイをアクティブ化したら、設定をテストします。
VMware HA 設定をテストするには
-
でStorage Gateway コンソールを開きます。https://console.aws.amazon.com/storagegateway/home
。 -
ナビゲーションペインで [Gateways] を選択してから、VMware HA をテストするゲートウェイを選択します。
-
[Actions] で、[Verify VMware HA (VMware HA の確認)] を選択します。
-
表示される [Verify VMware High Availability Configuration (VMware High Availability 設定の検証)] ページで、[OK] を選択します。
注記
VMware HA 設定をテストすると、ゲートウェイ VM が再起動され、ゲートウェイへの接続が中断されます。テストの完了には数分かかることがあります。
テストが成功すると、コンソールのゲートウェイの詳細タブに [Verified (検証済み)] というステータスが表示されます。
-
[終了] を選択します。
Amazon CloudWatch ロググループで VMware HA イベントに関する情報があります。詳細については、CloudWatch ロググループを使用したファイルゲートウェイのヘルスログの取得を参照してください。