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