ネットワーク アップロードを最適化する
Jumbo Frame は、既定の 1,500 バイトより大きいイーサネット フレームです。 一般的な Jumbo Frame のサイズは 9,000 バイトです。 ソース DB サーバーでフレームのサイズを大きくすると、スイッチなどのすべての中間ネットワーク デバイスと Intel R3load サーバーで CPU 使用量が減少し、ネットワーク スループットが向上します。 フレーム サイズはすべてのデバイスで同じにする必要があります。そうしないと、リソースを大量に消費する変換が発生します。
Receive Side Scaling (RSS) などの追加のネットワーク機能を、オンにしたり、複数のプロセッサにネットワーク処理を分散するように構成したりすることができます。VMware 上で R3load サーバーを実行すると、Jumbo Frame と RSS のネットワーク チューニングがいっそう複雑になることがわかっており、非常に高度なスキル レベルがある場合を除いてお勧めできません。
R3load によって、DBMS テーブルからデータがエクスポートされ、この形式に依存しない生のデータがダンプ ファイルに圧縮されます。 これらのダンプ ファイルを Azure にアップロードし、ターゲットの SQL Server データベースにインポートする必要があります。
これらのダンプ ファイルを Azure にコピーしてアップロードするパフォーマンスは、移行プロセス全体での重要なコンポーネントです。
R3load ダンプ ファイルをアップロードするには、2 つの基本的な方法があります。
AzCopy を使用して、パブリック インターネット経由で、オンプレミスの R3load エクスポート サーバーから Azure Blob Storage にコピーする
各 R3load サーバーで、次のコマンド ラインを使用して AzCopy のコピーを実行します。
Azcopy copy "C:\ExportServer_1\Dumpfiles" "https://[storage_account].blob.core.windows.net/ExportServer_1/Dumpfiles?[SAS_Token]" --recursive
AZCOPY_CONCURRENCY_VALUE 環境変数の値を設定することにより、スループットを上げることができます。 この変数は、同時に発生することができる要求の数を指定します。
コンピューターの CPU が 5 個未満の場合、この変数の [value] は 32 に設定されます。 それ以外の場合、既定値は CPU の数に 16 を掛けた数です。 この変数の最大の既定値は 300 ですが、この値を手動で上げたり下げたりできます。
| オペレーティング システム | コマンド |
|---|---|
| Windows | set AZCOPY_CONCURRENCY_VALUE=[value] |
| Linux | export AZCOPY_CONCURRENCY_VALUE=[value] |
| macOS | export AZCOPY_CONCURRENCY_VALUE=[value] |
azcopy env を使って、AZCOPY_CONCURRENCY_VALUE 環境変数の現在の値を確認します。 値が空白の場合は、AzCopy ログ ファイルの先頭を調べることで、使用されている値を読み取ることができます。 選択された値と選択された理由が報告されています。
コンカレンシー値を設定する前に、ベンチマーク テストを実行します。 ベンチマーク テスト プロセスによって、推奨されるコンカレンシー値が報告されます。 または、ネットワークの状態とペイロードが変化する場合は、この変数を特定の数値ではなく、AUTO という単語に設定します。 AUTO 値の場合、AzCopy はベンチマーク テストで使うのと同じ自動チューニング プロセスを常に実行します。
お客様が強力なサーバーと高速なインターネットを使っている場合は、コンカレンシー値を増やすことができます。 コンカレンシー値を大きくし過ぎると、ネットワークが飽和するため、R3load エクスポート サーバーへの接続が失われます。 Windows タスク マネージャーでネットワークのスループットを監視してください。 R3load エクスポート サーバーあたり 1 ギガビット/秒を超えるコピー スループットを簡単に実現できます。 R3load サーバーを増やすことで (前の図では 4 台)、コピー スループットをスケールアップできます
R3load がアクセスできるファイル システムに BLOB からファイルをコピーするには、Azure の R3load インポート サーバーに対して同様のスクリプトを実行する必要があります。
AzCopy、Robocopy、または同様のツールを使用し、専用の ExpressRoute 接続を介して、オンプレミスの R3load エクスポート サーバーから Azure 仮想マシンまたは BLOB ストレージにコピーする
Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log
次のブロック図は、R3load を実行する 4 台の Intel R3load サーバーを示しています。 バックグラウンドで、Robocopy によってダンプフ ァイルのアップロードが開始されます。 分割テーブルとパッケージの全体が完了したら、手動またはスクリプトで SGN ファイルをコピーします。 パッケージの SGN ファイルがインポート R3load サーバーに到着すると、このパッケージのインポートが自動的にトリガーされます。
Note
NFS または Windows SMB プロトコルによるファイルのコピーは、AzCopy などのメカニズムほど高速でも堅牢でもありません。 両方のファイル アップロード手法のパフォーマンスをテストすることをお勧めします。 非常に高いスループットのネットワーク操作はサービス拒否攻撃と誤認される可能性があるため、VLDB 移行プロジェクトについて Microsoft サポートに通知することをお勧めします。