翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
SQL Server データベースバックアップ用の S3 File Gateway の最適化
データベースバックアップは、S3 File Gateway の一般的で推奨されるユースケースです。これにより、Amazon S3 にデータベースバックアップを保存することで、コスト効率の高い短期および長期の保持を実現できます。また、必要に応じてライフサイクルを短縮して、低コストのストレージ階層を実現できます。このソリューションを使用すると、SQL Server Management Studio や Oracle RMAN などの組み込みツールを使用して、エンタープライズバックアップアプリケーションの必要性を減らすことができます。
以下のセクションでは、数百テラバイトの SQL データベースバックアップのパフォーマンスとコスト効率の高いサポートを最適化するために S3 File Gateway のデプロイを調整するためのベストプラクティスについて説明します。各セクションで提供されるガイダンスは、全体的なスループットの向上に段階的に貢献します。これらの推奨事項はいずれも必要ではなく、相互に依存しませんが、 サポート が S3 File Gateway 実装のテストとチューニングに使用する論理的な方法で選択および順序付けされています。これらの提案を実装してテストするときは、S3 File Gateway の各デプロイは一意であるため、結果が異なる場合があります。
S3 File Gateway は、業界標準の NFS または SMB ファイルプロトコルを使用して Amazon S3 オブジェクトを保存および取得するためのファイルインターフェイスを提供し、ファイルとオブジェクト間のネイティブ 1:1 マッピングを提供します。S3 File Gateway は、VMware、Microsoft Hyper-V、Linux KVM 環境でオンプレミスの仮想マシンとしてデプロイするか、Amazon EC2 インスタンスとして AWS クラウドにデプロイします。S3 File Gateway は、完全なエンタープライズ NAS 置換として機能するように設計されていません。S3 File Gateway はファイルシステムをエミュレートしますが、ファイルシステムではありません。Amazon S3 を耐久性のあるバックエンドストレージとして使用すると、I/O オペレーションごとに追加のオーバーヘッドが発生するため、既存の NAS またはファイルサーバーに対して S3 File Gateway のパフォーマンスを評価することは同等の比較ではありません。
SQL Server と同じ場所にゲートウェイをデプロイする
S3 File Gateway 仮想アプライアンスは、S3 File Gateway 仮想アプライアンスと SQL サーバー間のネットワークレイテンシーをできるだけ小さくして、物理的な場所にデプロイすることをお勧めします。ゲートウェイの場所を選択するときは、次の点を考慮してください。
-
ゲートウェイへのネットワークレイテンシーを短くすると、SQL サーバーなどの SMB クライアントのパフォーマンスを向上させることができます。
-
S3 File Gateway は、ゲートウェイとクライアント間よりもゲートウェイと Amazon S3 間のネットワークレイテンシーが高くなるように設計されています。
-
Amazon EC2 にデプロイされた S3 File Gateway インスタンスの場合、ゲートウェイと SQL サーバーを同じプレイスメントグループに保持することをお勧めします。詳細については、Amazon EC2 インスタンスのプレイスメントグループ」を参照してください。
ディスクの速度低下によるボトルネックの軽減
IoWaitPercent CloudWatch メトリクスをモニタリングして、S3 File Gateway の低速ストレージディスクに起因するパフォーマンスのボトルネックを特定することをお勧めします。ディスク関連のパフォーマンス問題を最適化する場合は、次の点を考慮してください。
-
IoWaitPercentは、CPU がルートディスクまたはキャッシュディスクからの応答を待っている時間の割合を報告します。 -
IoWaitPercentが 5～10% を超えると、通常、パフォーマンスの低いディスクに起因するゲートウェイパフォーマンスのボトルネックを示します。このメトリクスはできるだけ 0% に近い値にする必要があります。つまり、ゲートウェイはディスクを待たないので、CPU リソースの最適化に役立ちます。 -
Storage Gateway コンソールのモニタリングタブ
IoWaitPercentで確認するか、メトリクスが特定のしきい値を超えた場合に自動的に通知するように推奨 CloudWatch アラームを設定できます。詳細については、「ゲートウェイの推奨 CloudWatch アラームの作成」を参照してください。 -
を最小限に抑えるには、ゲートウェイのルートディスクとキャッシュディスクに NVMe または SSD を使用することをお勧めします
IoWaitPercent。
CPU、RAM、キャッシュディスクの S3 File Gateway 仮想マシンリソース割り当てを調整する
S3 File Gateway のスループットを最適化しようとするときは、CPU、RAM、キャッシュディスクなど、ゲートウェイ VM に十分なリソースを割り当てることが重要です。4 CPUs、16GB RAM、150GB キャッシュストレージの最小仮想リソース要件は、通常、小規模なワークロードにのみ適しています。大規模なワークロードに仮想リソースを割り当てる場合は、次のことをお勧めします。
-
S3 File Gateway によって生成される一般的な CPUs 使用率に応じて、割り当てられた CPU の数を 16～48 に増やします。
UserCpuPercentメトリクスを使用して CPU 使用率をモニタリングできます。詳細については、「ゲートウェイメトリクスについて」を参照してください。 -
割り当てられた RAM を 32～64 GB に増やします。
注記
S3 File Gateway は 64 GB を超える RAM を使用できません。
-
ルートディスクとキャッシュディスクに NVMe または SSD を使用し、ゲートウェイに書き込む予定のピーク作業データセットに合わせてキャッシュディスクのサイズを設定します。詳細については、公式の Amazon Web Services YouTube チャンネルのS3 File Gateway キャッシュサイジングのベストプラクティス
」を参照してください。 -
1 つの大きなディスクを使用するのではなく、少なくとも 4 つの仮想キャッシュディスクをゲートウェイに追加します。複数の仮想ディスクは、基盤となる同じ物理ディスクを共有していてもパフォーマンスを向上させることができますが、仮想ディスクが異なる基盤となる物理ディスクに配置されると、通常は改善点が大きくなります。
たとえば、12TB のキャッシュをデプロイする場合は、次のいずれかの設定を使用できます。
-
4 x 3 TB キャッシュディスク
-
8 x 1.5 TB キャッシュディスク
-
12 x 1 TB キャッシュディスク
これにより、パフォーマンスに加えて、時間の経過とともに仮想マシンをより効率的に管理できます。ワークロードの変化に応じて、個々の仮想ディスクの元のサイズを維持しながら、キャッシュディスクの数と全体的なキャッシュ容量を段階的に増やして、ゲートウェイの整合性を維持できます。
詳細については、「ローカルディスクストレージの量を決定する」を参照してください。
-
S3 File Gateway を Amazon EC2 インスタンスとしてデプロイする場合は、次の点を考慮してください。
-
選択したインスタンスタイプは、ゲートウェイのパフォーマンスに大きな影響を与える可能性があります。Amazon EC2 は、S3 File Gateway インスタンスのリソース割り当てを柔軟に調整できます。
-
S3 File Gateway に推奨される Amazon EC2 インスタンスタイプについては、Amazon EC2 インスタンスタイプの要件」を参照してください。
-
アクティブな S3 File Gateway をホストする Amazon EC2 インスタンスタイプを変更できます。これにより、Amazon EC2 ハードウェアの生成とリソースの割り当てを簡単に調整して、理想的なprice-to-performanceの比率を見つけることができます。インスタンスタイプを変更するには、Amazon EC2 コンソールで次の手順を使用します。
-
Amazon EC2 インスタンスを停止します。
-
Amazon EC2 インスタンスタイプを変更します。
-
Amazon EC2 インスタンスの電源を入れます。
注記
S3 File Gateway をホストするインスタンスを停止すると、ファイル共有アクセスが一時的に中断されます。必要に応じて、メンテナンスウィンドウを必ずスケジュールしてください。
-
-
Amazon EC2 インスタンスのprice-to-performance比は、支払う料金に対して得られるコンピューティング能力を示します。通常、新世代の Amazon EC2 インスタンスは、price-to-performance比を提供します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、費用対効果を最適化するには、特定のワークロードに適したインスタンスを選択することが重要です。
S3 File Gateway のセキュリティレベルを調整して SMB クライアントのスループットを向上させる
SMBv3 プロトコルでは、SMB 署名と SMB 暗号化の両方が許可され、パフォーマンスとセキュリティにいくつかのトレードオフがあります。スループットを最適化するには、ゲートウェイの SMB セキュリティレベルを調整して、クライアント接続に適用されるこれらのセキュリティ機能を指定できます。詳細については、「ゲートウェイのセキュリティレベルを設定する」を参照してください。
SMB セキュリティレベルを調整するときは、次の点を考慮してください。
-
S3 File Gateway のデフォルトのセキュリティレベルは、Enforce 暗号化です。この設定では、ゲートウェイファイル共有への SMB クライアント接続の暗号化と署名の両方が適用されます。つまり、クライアントからゲートウェイへのすべてのトラフィックが暗号化されます。この設定は、ゲートウェイから へのトラフィックには影響せず AWS、常に暗号化されます。
ゲートウェイは、暗号化された各クライアント接続を 1 つの vCPU に制限します。たとえば、暗号化されたクライアントが 1 つしかない場合、4 つ以上の vCPU がゲートウェイに割り当てられていても、そのクライアントは 1 つの vCPUs に制限されます。このため、単一のクライアントから S3 File Gateway への暗号化された接続のスループットは通常、40～60 MB/秒の間でボトルネックになります。
-
セキュリティ要件でより緩やかな体制が許可されている場合には、セキュリティレベルをクライアントネゴシエートに変更できます。これにより、SMB 暗号化が無効になり、SMB 署名のみが適用されます。この設定では、ゲートウェイへのクライアント接続で複数の vCPUsを利用できるため、通常、スループットパフォーマンスが向上します。
注記
S3 File Gateway の SMB セキュリティレベルを変更したら、ファイル共有ステータスが Storage Gateway コンソールの更新から使用可能に変わるのを待ってから、新しい設定を有効にするために SMB クライアントを切断して再接続する必要があります。
SQL バックアップを複数のファイルに分割して SMB クライアントのスループットを向上させる
-
単一の SQL サーバーからのシーケンシャル書き込みはシングルスレッドオペレーションであるため、一度に 1 つの SQL サーバーだけがファイルを書き込む S3 File Gateway で最大スループットパフォーマンスを実現することは困難です。代わりに、各 SQL サーバーの複数のスレッドを使用して複数のファイルを並行して書き込み、複数の SQL サーバーを同時に S3 ファイルゲートウェイに使用してゲートウェイのスループットを最大化することをお勧めします。SQL バックアップでは、バックアップを複数のファイルに分割することで、各ファイルで個別のスレッドを使用できます。これにより、複数のファイルが同時に S3 File Gateway ファイル共有に書き込まれます。スレッドが多いほど、ゲートウェイの制限まで達成できるスループットが向上します。
-
SQL Server は、1 回のバックアップオペレーション中に複数のファイルへの書き込みを同時にサポートします。例えば、T-SQL コマンドまたは SQL Server Management Studio (SSMS) を使用して、複数のファイル送信先を指定できます。各ファイルは、個別のスレッドを使用して SQL Server からゲートウェイファイル共有にデータを送信します。このアプローチにより、I/O スループットが向上し、バックアップの速度と効率が大幅に向上します。
SQL Server バックアップを設定するときは、次の点を考慮してください。
-
バックアップを複数のファイルに分割することで、SQL Server 管理者はバックアップ時間を最適化し、大規模なデータベースバックアップをより効果的に管理できます。
-
使用するファイル数は、サーバーのストレージ設定とパフォーマンス要件によって異なります。大規模なデータベースでは、バックアップをそれぞれ 10 GB から 20 GB までのいくつかの小さなファイルに分割することをお勧めします。
-
SQL Server がバックアップ中に書き込むことができるファイルの数には厳密な制限はありませんが、ストレージアーキテクチャやネットワーク帯域幅などの実用的な考慮事項がこの選択の指針となるはずです。
詳細については、以下を参照してください。
SMB タイムアウト設定を増やして大きなファイルコピーの失敗を防ぐ
S3 File Gateway が大きな SQL バックアップファイルを SMB ファイル共有にコピーすると、SMB クライアント接続は長期間経過するとタイムアウトする可能性があります。ファイルのサイズとゲートウェイの書き込み速度に応じて、SQL Server SMB クライアントの SMB セッションタイムアウト設定を 20 分以上に拡張することをお勧めします。デフォルトは 300 秒、つまり 5 分です。詳細については、「ゲートウェイバックアップジョブが失敗するか、ゲートウェイへの書き込み時にエラーが発生します。」を参照してください。
Amazon S3 アップローダースレッドの数を増やす
デフォルトでは、S3 File Gateway は Amazon S3 データアップロード用に 8 つのスレッドを開き、ほとんどの一般的なデプロイに十分なアップロード容量を提供します。ただし、ゲートウェイが標準の 8 スレッド容量で Amazon S3 にアップロードできるよりも高いレートで SQL サーバーからデータを受信する可能性があります。これにより、ローカルキャッシュがストレージ制限に達する可能性があります。
特定の状況では、ゲートウェイの Amazon S3 アップロードスレッドプールの数を 8 から 40 に増やす サポート ことができます。これにより、より多くのデータを並行してアップロードできます。デプロイに固有の帯域幅やその他の要因によっては、アップロードパフォーマンスが大幅に向上し、ワークロードのサポートに必要なキャッシュストレージの量を減らすことができます。
CachePercentDirty CloudWatch メトリクスを使用して、Amazon S3 にまだアップロードされていないローカルゲートウェイキャッシュディスクに保存されているデータ量をモニタリングし、 サポート に連絡して、アップロードスレッドプール数を増やすことで S3 File Gateway のスループットが向上するかどうかを判断することをお勧めします。詳細については、「ゲートウェイメトリクスについて」を参照してください。
注記
この設定では、追加のゲートウェイ CPU リソースを消費します。ゲートウェイの CPU 使用率をモニタリングし、必要に応じて割り当てられた CPU リソースを増やすことをお勧めします。
自動キャッシュ更新をオフにする
自動キャッシュ更新機能を使用すると、S3 File Gateway はメタデータを自動的に更新できます。これにより、ユーザーまたはアプリケーションがファイルセットに加えた変更を、ゲートウェイではなく Amazon S3 バケットに直接書き込むことでキャプチャできます。詳細については、Amazon S3バケットオブジェクトキャッシュの更新」を参照してください。
ゲートウェイのスループットを最適化するために、Amazon S3 バケットへのすべての読み取りと書き込みが S3 ファイルゲートウェイを介して実行されるデプロイでは、この機能をオフにすることをお勧めします。
自動キャッシュ更新を設定するときは、次の点を考慮してください。
-
デプロイ内のユーザーまたはアプリケーションが Amazon S3 に直接書き込むことがあるため、自動キャッシュ更新を使用する必要がある場合は、ビジネスニーズにはまだ現実的な更新間隔をできるだけ長く設定することをお勧めします。キャッシュ更新間隔を長くすると、ディレクトリを参照したりファイルを変更したりするときにゲートウェイが実行する必要があるメタデータオペレーションの数を減らすことができます。
例えば、ワークロードに許容できる場合、自動キャッシュ更新を 5 分ではなく 24 時間に設定します。
-
最小時間間隔は 5 分です。最大間隔は 30 日です。
-
非常に短いキャッシュ更新間隔を設定する場合は、SQL サーバーのディレクトリブラウジングエクスペリエンスをテストすることをお勧めします。ゲートウェイキャッシュの更新にかかる時間は、Amazon S3 バケット内のファイルとサブディレクトリの数に応じて大幅に増加する可能性があります。
ワークロードをサポートするために複数のゲートウェイをデプロイする
Storage Gateway は、ワークロードを複数のゲートウェイに分割することで、数百の SQL データベース、複数の SQL Server、数百テラバイトのバックアップデータを持つ大規模な環境の SQL バックアップをサポートできます。
複数のゲートウェイと SQL サーバーを使用してデプロイを計画する場合は、次の点を考慮してください。
-
通常、1 つのゲートウェイで 1 日あたり最大 20 TB のハードウェアリソースと帯域幅をアップロードできます。Amazon Amazon S3まで増やすことができます。
-
proof-of-conceptテストを実施してパフォーマンスを測定し、デプロイ内のすべての変数を考慮することをお勧めします。SQL バックアップワークロードのピークスループットを決定したら、要件を満たすようにゲートウェイの数をスケールできます。
-
データベースの数とデータベースのサイズは時間の経過とともに増加する可能性があるため、成長を念頭に置いてソリューションを設計することをお勧めします。増え続けるワークロードを引き続きスケーリングしてサポートするには、必要に応じて追加のゲートウェイをデプロイできます。
データベースバックアップワークロードの追加リソース
