翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Tape Gateway のパフォーマンスと最適化
このセクションでは、Storage Gateway のパフォーマンスについて説明します。
テープゲートウェイのパフォーマンスガイダンス
このセクションでは、テープゲートウェイ VM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に記載されている Amazon EC2インスタンスのサイズとタイプは例であり、参照用に提供されています。
構成 | 書き込みスループット (Gbps) | キャッシュからの読み取りスループット (Gbps) | Amazon Web Services Cloud からの読み取りスループット (Gbps) |
---|---|---|---|
ホストプラットフォーム: Amazon EC2インスタンス — c5.4xlarge CPU: 16 vCPU | RAM: 32 GB ルートディスク: 80 GB、io1SSD、4,000 IOPS キャッシュディスク: ストライプ RAID (2 x 500 GB、io1EBSSSD、25000IOPs) バッファディスクのアップロード: 450 GB、io1SSD、2000 IOPs クラウドへのネットワーク帯域幅: 10 Gbps |
2.3 | 4.0 | 2.2 |
ホストプラットフォーム: Storage Gateway ハードウェアアプライアンス キャッシュディスク: 2.5 TB アップロードバッファディスク: 2 TB クラウドへのネットワーク帯域幅: 10 Gbps |
2.3 | 8.8 | 3.8 |
ホストプラットフォーム: Amazon EC2instance— c5d.9xlarge CPU: 36 vCPU | RAM: 72 GB ルートディスク: 80 GB、io1SSD、4,000 IOPS キャッシュディスク: 900 GB NVMeディスク バッファディスクのアップロード: 900 GB NVMeディスク クラウドへのネットワーク帯域幅: 10 Gbps |
5.2 | 11.6 | 5.2 |
ホストプラットフォーム: Amazon EC2instance— c5d.metal CPU: 96 vCPU | RAM: 192 GB ルートディスク: 80 GB、io1SSD、4,000 IOPS キャッシュディスク: ストライプ RAID (2 x 900 GB NVMeディスク) バッファディスクのアップロード: 900 GB NVMeディスク クラウドへのネットワーク帯域幅: 10 Gbps |
5.2 | 11.6 | 7.2 |
注記
このパフォーマンスは、1 MB のブロックサイズと 10 台のテープドライブを同時に使用することで実現しました。
上記の表EC2の設定は、同様のリソースを持つ独自の物理サーバーで達成できるパフォーマンスを表すことのみを目的としています。例えば、ストライプを使用するEC2設定は、 のゲートウェイで一般的にサポートされていない特別なメカニズムを使用して行われRAIDましたEC2。同様のパフォーマンスを実現するには、代わりにゲートウェイを実行しているオンプレミスサーバーにアタッチされたハードウェアRAIDコントローラーを使用する必要があります。
パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。
テープゲートウェイの書き込みおよび読み取りスループットのパフォーマンスを向上させるには、「iSCSI 設定の最適化」、「テープドライブでの大きなブロックサイズの使用」、および「バックアップソフトウェアで仮想テープドライブのパフォーマンスを最適化する」を参照してください。
ゲートウェイパフォーマンスの最適化
ゲートウェイサーバーの推奨構成
ゲートウェイのパフォーマンスを最大限に引き出せるように、Storage Gateway では、ゲートウェイのホストサーバーに対して以下のゲートウェイ構成を推奨しています。
-
少なくとも 64 個の専用物理CPUコア
-
Tape Gateway の場合、ハードウェアは次の量の を専用にする必要がありますRAM。
-
キャッシュサイズが最大 16 TiB のゲートウェイ用に 16 GiB 以上予約 RAM TiB
-
キャッシュサイズが 16 TiB GiBのゲートウェイRAM用に少なくとも 32 TiB を予約
-
キャッシュサイズが 32 TiB~64 TiB のゲートウェイ用に少なくとも 48 GiB TiB を予約 RAM
注記
ゲートウェイのパフォーマンスを最適化するには、少なくとも 32 GiB の をプロビジョニングする必要がありますRAM。
-
-
ディスク 1。ゲートウェイキャッシュとして次のように使用します。
-
で構成されるストライプ RAID (独立ディスクの冗長配列)NVMeSSDs。
-
-
ディスク 2。ゲートウェイアップロードバッファとして次のように使用します。
-
でRAID構成されたストライプNVMeSSDs。
-
-
ディスク 3。ゲートウェイアップロードバッファとして次のように使用します。
-
でRAID構成されたストライプNVMeSSDs。
-
-
VM ネットワーク 1 に設定されたネットワークアダプタ 1:
-
VM ネットワーク 1 を使用し、取り込みに使用する VMXnet3 (10 Gbps) を追加します。
-
-
VM ネットワーク 2 に設定されたネットワークアダプタ 2:
-
VM ネットワーク 2 を使用して、 への接続に使用する VMXnet3 (10 Gbps) を追加します AWS。
-
ゲートウェイへのリソースの追加
次のボトルネックにより、テープゲートウェイのパフォーマンスが理論上の最大持続スループット ( AWS クラウドへの帯域幅) を下回る可能性があります。
-
CPU コア数
-
キャッシュ/アップロードバッファのディスクスループット
-
合計RAM金額
-
へのネットワーク帯域幅 AWS
-
イニシエータからゲートウェイまでのネットワーク帯域幅
このセクションでは、ゲートウェイのパフォーマンスを最適化するための対策について説明します。以下のガイダンスは、ゲートウェイまたはアプリケーションサーバーへのリソースの追加を前提としています。
以下の 1 つ以上の方法でゲートウェイにリソースを追加することで、ゲートウェイのパフォーマンスを最適化できます。
- より高性能なディスクの使用
-
キャッシュとアップロードバッファのディスクスループットによって、ゲートウェイのアップロードとダウンロードのパフォーマンスが制限される可能性があります。ゲートウェイのパフォーマンスが予想を大幅に下回っている場合は、キャッシュとアップロードバッファのディスクスループットを次の方法で改善することを検討してください。
-
10 RAID RAIDなどのストライプを使用して、理想的にはハードウェアRAIDコントローラーでディスクスループットを向上させます。
注記
RAID (独立ディスクの冗長配列) または特に 10 RAID のようなディスクストライプRAID設定は、データの本文をブロックに分割し、複数のストレージデバイスにデータブロックを分散するプロセスです。使用するRAIDレベルは、達成できる正確な速度と耐障害性に影響します。IO ワークロードを複数のディスクにストライピングすることで、RAIDデバイスの全体的なスループットは、単一のメンバーディスクのスループットよりもはるかに高くなります。
-
高性能ディスクを直接接続して使用する。
ゲートウェイのパフォーマンスを最適化するには、ソリッドステートドライブ (SSDs) やNVMeコントローラーなどの高性能ディスクを追加できます。Microsoft Hyper-V の代わりに、ストレージエリアネットワーク (SAN) から直接 VM に仮想ディスクをアタッチすることもできますNTFS。ディスクパフォーマンスの向上により、通常、スループットが向上し、1 秒あたりの入出力オペレーションが増えます (IOPS)。
スループットを測定するには、
Samples
Amazon CloudWatch 統計でReadBytes
およびWriteBytes
メトリクスを使用します。例えば、5 分間のサンプル期間をSamples
300 秒で割ったReadBytes
メトリクスの統計は、 を提供しますIOPS。原則として、これらのメトリクスでゲートウェイを確認するときは、ディスク関連のボトルネックを示す低スループットと低IOPSトレンドを探します。ゲートウェイメトリクスの詳細については、「テープゲートウェイと 間のパフォーマンスの測定 AWS」を参照してください。注記
CloudWatch メトリクスは、すべてのゲートウェイで利用できるわけではありません。ゲートウェイメトリクスについては、「Storage Gateway のモニタリング」を参照してください。
-
- アップロードバッファディスクをさらに追加する
-
書き込みスループットを高めるには、少なくとも 2 つのアップロードバッファディスクを追加します。データがゲートウェイに書き込まれると、アップロードバッファディスクにローカルに書き込まれて保存されます。その後、保存されたローカルデータはディスクから非同期的に読み取られ、処理と AWSへのアップロードが行われます。アップロードバッファディスクをさらに追加すると、個別のディスクに対して実行される同時 I/O 操作の量が減る可能性があります。これにより、ゲートウェイへの書き込みスループットが増える可能性があります。
- 別の物理ディスクを使用したゲートウェイ仮想ディスクのバックアップ
-
ゲートウェイのディスクをプロビジョニングする場合は、同じ物理ストレージディスクを基盤として使用しているアップロードバッファおよびキャッシュストレージ用にローカルディスクをプロビジョニングしないことを強くお勧めします。例えば、 VMware の場合ESXi、基盤となる物理ストレージリソースはデータストアとして表されます。ゲートウェイ VM をデプロイする場合は、VM ファイルを保存するデータストアを選択します。仮想ディスクをプロビジョニングする場合は (アップロードバッファとして使用する場合など)、仮想ディスクを VM と同じデータストアか、別のデータストアに保存できます。
複数のデータストアがある場合は、作成するローカルストレージのタイプごとに 1 つのデータストアを選択することを強くお勧めします。基になる物理ディスク 1 つのみによってサポートされるデータストアでは、パフォーマンスが低下することがあります。たとえば、そのようなディスクを使用して、ゲートウェイ設定のキャッシュストレージとアップロードバッファの両方がサポートされる場合です。同様に、1 や RAID 6 RAID などのパフォーマンスの低いRAID設定に支えられているデータストアは、パフォーマンスの低下につながる可能性があります。
- ゲートウェイホストにCPUリソースを追加する
-
ゲートウェイホストサーバーの最小要件は、4 つの仮想プロセッサです。ゲートウェイのパフォーマンスを最適化するには、ゲートウェイ VM に割り当てられた各仮想プロセッサが専用CPUコアによってバックアップされていることを確認します。さらに、ホストサーバーの CPUsを過剰にサブスクライブしていないことを確認します。
ゲートウェイホストサーバーCPUsに追加を追加すると、ゲートウェイの処理能力が向上します。これにより、ゲートウェイは、アプリケーションからローカルストレージへのデータの保存と Amazon S3 へのこのデータのアップロードの両方を並行して処理できます。さらにCPUs、ホストが他の と共有されるときにゲートウェイが十分なCPUリソースを確実に取得するのに役立ちますVMs。十分なCPUリソースを提供することは、スループットを向上させる一般的な効果があります。
- ゲートウェイと AWS クラウドの間の帯域幅を広げる
-
帯域幅を との間で増加させる AWS と、ゲートウェイへのデータ進入と AWS クラウドへの進入の最大レートが増加します。低速のディスクや、ゲートウェイとイニシエータ間の接続帯域幅不足といった他の要因ではなく、ネットワーク速度がゲートウェイ構成における制限要因となっている場合は、これでゲートウェイのパフォーマンスを向上させることができます。
とのネットワーク帯域幅は、持続的なワークロード中のテープゲートウェイの理論上の最大平均パフォーマンス AWS を定義します。
-
テープゲートウェイへのデータの書き込み速度の長時間平均が、 AWSへのアップロード帯域幅を超えることはありません。
-
テープゲートウェイから長い間隔でデータを読み取ることができる平均レートは、 へのダウンロード帯域幅を超えないものとします AWS。
注記
キャッシュ/アップロードバッファディスクのスループット、CPUコア数、合計RAM量、イニシエータとゲートウェイ間の帯域幅など、ここにリストされている他の制限要因により、ゲートウェイのパフォーマンスがネットワーク帯域幅よりも低くなる可能性があります。また、ゲートウェイの通常運用に際しては、データ保護のために多くの対策が実施されるため、ネットワーク帯域幅よりもパフォーマンスの実測値が低くなる場合があります。
-
iSCSI 設定の最適化
iSCSI イニシエータの iSCSI 設定を最適化して、より高い I/O パフォーマンスを実現できます。MaxReceiveDataSegmentLength
と FirstBurstLength
には 256 KiB、MaxBurstLength
には 1 MiB を選択することをお勧めします。iSCSI 設定の設定の詳細については、「」を参照してくださいiSCSI 設定のカスタマイズ。
注記
これらの推奨設定により、全体的なパフォーマンスが向上します。ただし、パフォーマンスを最適化するために必要な特定の iSCSI 設定は、使用するバックアップソフトウェアによって異なります。詳細については、バックアップソフトウェアのドキュメントを参照してください。
テープドライブでの大きなブロックサイズの使用
テープゲートウェイの場合、テープドライブのデフォルトブロックサイズは 64 KB です。ただし、I/O パフォーマンスを向上させるためにブロックサイズを最大 1 MB まで増やすことができます。
選択するブロックサイズは、バックアップソフトウェアがサポートしている最大ブロックサイズによって異なります。バックアップソフトウェアのテープドライブのブロックサイズは、できる限り大きいサイズに設定することをお勧めします。ただし、このブロックサイズは、ゲートウェイがサポートする最大サイズの 1 MB を超えないようにしてください。
テープゲートウェイは、バックアップソフトウェアで設定されているサイズと自動的に一致するように、仮想テープドライブのブロックサイズをネゴシエートします。バックアップソフトウェアのブロックサイズを増やす場合は、設定でホストイニシエータが新しいブロックサイズをサポートしていることを確認することをお勧めします。詳細については、バックアップソフトウェアのドキュメントを参照してください。特定のゲートウェイパフォーマンのガイドについては、「Tape Gateway のパフォーマンスと最適化」を参照してください。
バックアップソフトウェアで仮想テープドライブのパフォーマンスを最適化する
バックアップソフトウェアは、テープゲートウェイの最大 10 個の仮想テープドライブに同時にデータをバックアップできます。テープゲートウェイの 4 個以上の仮想テープドライブを同時に使用するように、バックアップソフトウェアでバックアップジョブを設定することをお勧めします。バックアップソフトウェアが同時に複数の仮想テープにデータをバックアップしていると、書き込みスループットが向上します。
原則として、同時に処理 (読み取りまたは書き込み) する仮想テープを増やすことで、最大スループットを高めることができます。テープドライブの数を増やせば、ゲートウェイが同時に処理できるリクエストの件数が増え、パフォーマンスの向上を見込めます。
アプリケーション環境へのリソースの追加
- アプリケーションサーバーとゲートウェイの間の帯域幅を増やす
-
iSCSI イニシエータとゲートウェイ間の接続により、アップロードとダウンロードのパフォーマンスが制限される可能性があります。ゲートウェイのパフォーマンスが予想よりも大幅に悪く、CPUコア数とディスクスループットが既に向上している場合は、次の点を考慮してください。
-
ネットワークケーブルをアップグレードして、イニシエータとゲートウェイ間の帯域幅を広げる。
-
できるだけ多くのテープドライブを同時に使用します。同じSCSIターゲットに対する複数のリクエストのキューイングをサポートしていません。つまり、使用するテープドライブが多いほど、ゲートウェイが同時に処理できるリクエストの数が増えます。これにより、ゲートウェイとイニシエータの間の帯域幅を有効活用できるようになり、ゲートウェイの見かけ上のスループットが向上します。
ゲートウェイのパフォーマンスを最適化するには、アプリケーションとゲートウェイ間のネットワーク帯域幅が、アプリケーションのニーズを満たすようにしてください。ゲートウェイの
ReadBytes
メトリクスとWriteBytes
メトリクスを使用して、データの合計スループットを測定できます。これらのメトリクスの詳細については、「テープゲートウェイと 間のパフォーマンスの測定 AWS」を参照してください。アプリケーションでは、必要なスループットと測定されたスループットを比較します。測定されたスループットが必要なスループットを下回る場合、アプリケーションとゲートウェイの間の帯域幅を増やすと、ネットワークがボトルネックであれば、パフォーマンスを向上させることができます。同様に、VM とローカルディスクの間の帯域幅を増やすことができます (直接接続されていない場合)。
-
- アプリケーション環境にCPUリソースを追加する
-
アプリケーションが追加のCPUリソースを使用できる場合、さらに追加CPUsすると、アプリケーションが I/O 負荷をスケーリングするのに役立ちます。