ネットワーク パフォーマンスのトラブルシューティング
概要
Azure では、オンプレミスのネットワークから Azure に接続するための高速で安定した方法を提供します。 サイト間 VPN や ExpressRoute などの方法が、Azure でビジネスを実行するために、あらゆる規模のお客様によって正常に使用されています。 ただし、パフォーマンスが期待どおりでなかったり、以前のレベルに達しなかったりするとどうなるでしょうか。 この記事は、特定の環境をテストしてベースラインを作成する方法を標準化するのに役立ちます。
ここでは、2 つのホスト間のネットワーク待ち時間と帯域幅を簡単に、かつ一貫してテストする方法について説明します。 また、問題点を分離するのに役立つ Azure ネットワークの調査方法に関するアドバイスも提供します。 ここで取り上げる PowerShell スクリプトとツールでは、ネットワーク上 (テストするリンクの両端) に 2 つのホストが必要です。 1 つのホストは Windows Server またはデスクトップである必要がありますが、もう一方は Windows または Linux のどちらでもかまいません。
ネットワーク コンポーネント
トラブルシューティングの詳細を説明する前に、一般的な用語とコンポーネントについて見ていきましょう。 これにより、Azure の接続性を実現するエンドツーエンド チェーン内の各コンポーネントについて考えていくことができます。
最上位のレベルには、主要なネットワーク ルーティング ドメインが 3 つあります。
- Azure ネットワーク (青色のクラウド)
- インターネットまたは WAN (緑色のクラウド)
- 企業ネットワーク (オレンジ色のクラウド)
この図を右から左に見ながら、各コンポーネントについて簡単に説明しましょう。
仮想マシン - サーバーには複数の NIC がある場合があります。 すべての静的ルート、既定ルート、およびオペレーティング システムの設定で、想定どおりにトラフィックの送受信が行われていることを確認します。 また、各 VM の SKU には、帯域幅制限があります。 SKU のサイズが小さい VM を使用している場合、NIC で使用可能な帯域幅によってトラフィックが制限されます。 VM に十分な帯域幅を確保するために、テストには DS5v2 を使うことをお勧めします。
NIC - 問題の NIC に割り当てられているプライベート IP を把握していることを確認します。
NIC NSG - NIC レベルで適用される特定の NSG が存在する可能性があります。 渡そうとしているトラフィックに対して NSG のルール セットが適切であることを確認します たとえば、iPerf 用のポート 5201、RDP 用のポート 3389、または SSH 用のポート 22 が開いていて、テスト トラフィックを渡すことが許可されていることを確認します。
VNet サブネット - NIC は、特定のサブネットに割り当てられています。 どのサブネットか、またそのサブネットに関連付けられている規則がわかっていることを確認してください。
サブネット NSG - NIC と同様に、NSG もサブネット レベルで適用できます。 渡そうとしているトラフィックに対して NSG のルール セットが適切であることを確認します NIC に受信されるトラフィックの場合は、最初にサブネット NSG が、次に NIC NSG が適用されます。 トラフィックが VM から送信されるときは、最初に NIC NSG が適用され、次にサブネット NSG が適用されます。
サブネットの UDR - ユーザー定義ルートでは、中間のホップ (ファイアウォールやロードバランサーなど) にトラフィックを向けることができます。 トラフィックに UDR が設定されているかどうかを必ず確認してください。 その場合は、その宛先と、トラフィックに対して次ホップで行われる処理を把握しておいてください。 たとえば、同じ 2 つのホスト間でも、ファイアウォールで許可されるトラフィックもあれば、拒否されるトラフィックもあります。
ゲートウェイ サブネット、NSG、UDR - VM サブネットと同様に、ゲートウェイ サブネットも NSG と UDR を持つことができます。 それらがあるかどうか、およびトラフィックに対してどのような影響があるかを確認してください。
VNet ゲートウェイ (ExpressRoute) - ピアリング (ExpressRoute) または VPN を有効にすると、トラフィックのルーティングの有無や方法に影響を与える設定はあまりありません。 複数の ExpressRoute 回線または VPN トンネルに接続されている仮想ネットワーク ゲートウェイがある場合は、接続の重み設定に注意する必要があります。 接続の重みは接続の優先順位に影響し、トラフィックのパスを決定します。
ルート フィルター (表示されません) - ExpressRoute 経由で Microsoft ピアリングを使用する場合は、ルート フィルターが必要です。 ルートを受信していない場合は、ルート フィルターが構成され、回線に正しく適用されているかどうかを確認してください。
ここで、リンクの WAN の部分に来ました。 このルーティング ドメインは、サービス プロバイダー、会社の WAN、またはインターネットの場合があります。 これらのリンクには多くのホップ、デバイス、および企業が関係しているため、トラブルシューティングが困難になる場合があります。 間にあるホップを調査する前に、まず Azure と企業ネットワークの両方を除外する必要があります。
上の図の一番左にあるのが企業ネットワークです。 会社の規模によって、このルーティング ドメインはユーザーと WAN との間のいくつかのネットワーク デバイスである場合もあれば、キャンパスまたは企業ネットワーク内の複数レイヤーのデバイスである場合もあります。
これらの 3 つの異なる高レベル ネットワーク環境の複雑さを考慮すると、多くの場合は、エッジから開始し、パフォーマンスがどこで高く、どこで低下するかを示してみることが最適です。 この方法は、この 3 つの中で問題があるルーティング ドメインを特定するのに役立ちます。 その後、その特定の環境にトラブルシューティングを集中できます。
ツール
ネットワークのほとんどの問題は、ping や traceroute などの基本的なツールを使用して分析し、特定できます。 Wireshark などのツールを使用したパケット分析にまで進む必要があることはほとんどありません。
トラブルシューティングに役立つように、Azure Connectivity Toolkit (AzureCT) が開発されて、これらのツールの一部が使いやすいパッケージにまとめられました。 パフォーマンス テストでは、iPerf や PSPing などのツールによって、ネットワークに関する情報が提供されます。 iPerf は、基本的なパフォーマンス テストによく使用される、非常に使いやすいツールです。 PSPing は、SysInternals によって開発された ping ツールです。 PSPing では、リモート ホストに到達するために ICMP と TCP の両方の ping を実行できます。 これらのツールはどちらも軽量であり、ファイルをホスト上のディレクトリにコピーすることによって、簡単に "インストール" されます。
これらのツールとメソッドは、インストールして使用できる PowerShell モジュール (AzureCT) にラップされています。
AzureCT - Azure Connectivity Toolkit
AzureCT PowerShell モジュールには、可用性テストとパフォーマンス テストの 2 つのコンポーネントが含まれています。 このドキュメントでは、パフォーマンス テスト、特に、この PowerShell モジュール内の 2 つのリンク パフォーマンス コマンドに焦点を絞ります。
このツールキットをパフォーマンス テストに使用するための 3 つの基本的な手順を次に示します。
PowerShell モジュールをインストールする
(new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expressionこのコマンドは PowerShell モジュールをダウンロードし、ローカルにインストールします。
サポートしているアプリケーションをインストールする
Install-LinkPerformanceこの AzureCT コマンドは、iPerf と PSPing を新しいディレクトリ
C:\ACTToolsにインストールし、Windows ファイアウォール ポートを開いて ICMP とポート 5201 (iPerf) トラフィックを許可します。パフォーマンス テストを実行する
まず、リモート ホストで、iPerf をインストールしてサーバー モードで実行します。 リモート ホストは 3389 (Windows の RDP) または 22 (Linux の SSH) のいずれかでリッスンし、iPerf 用のポート 5201 でトラフィックが許可されていることを確認します。 リモート ホストが Windows である場合は、AzureCT をインストールし、Install-LinkPerformance コマンドを実行して iPerf と必要なファイアウォール規則を設定します。
リモート マシンの準備ができたら、ローカル コンピューターで PowerShell を開き、テストを開始します。
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10このコマンドは、一連の同時実行負荷および待ち時間テストを実行して、ネットワーク リンクの帯域幅容量と待ち時間を見積もります。
テスト出力を確認する
PowerShell の出力形式は次のようになります。
すべての iPerf および PSPing テストの詳細な結果は、
C:\ACTToolsにある AzureCT ツール ディレクトリ内の個々のテキスト ファイルに保存されます。
トラブルシューティング
パフォーマンス テストの結果が期待どおりでない場合は、体系的なアプローチに従って問題を識別します。 パス内のコンポーネントの数を考慮すると、ランダムなテストより段階的なプロセスの方が効果的です。
Note
ここで紹介するシナリオはパフォーマンスの問題であり、接続の問題ではありません。 Azure ネットワークへの接続の問題を分離するには、ExpressRoute 接続の確認に関する記事に従ってください。
前提を見直す
期待が妥当であることを確認します。 たとえば、1 Gbps の ExpressRoute 回線で待ち時間が 100 ms の場合、待ち時間の長いリンク上での TCP のパフォーマンス特性のために、完全な 1 Gbps のトラフィックを期待することは非現実的です。 パフォーマンスの前提の詳細については、「参照」のセクションを参照してください。
ネットワークのエッジから開始する
ルーティング ドメイン間のエッジから開始し、問題を 1 つの主要なルーティング ドメインに分離してみてください。 徹底的な調査なしで、パス内の "ブラック ボックス" のせいにすることは避けてください。それにより、解決が遅れる場合があります。
図を作成する
問題になっている領域の図を描くことにより、問題を系統的に処理し、分離します。 テスト ポイントを計画し、領域をクリアするか、またはさらに詳細に調べたらマップを更新します。
分割して統治する
ネットワークをセグメント化し、問題を絞り込みます。 どこで機能し、どこで機能しないかを識別し、問題のあるコンポーネントを分離するためにテスト ポイントを移動し続けます。
すべての OSI レイヤーを考慮する
ネットワークとレイヤー 1 から 3 (物理、データ、ネットワークの各レイヤー) に焦点を絞ることが一般的ですが、問題がレイヤー 7 (アプリケーション レイヤー) でも発生する場合があることに注意してください。 先入観を持つことなく、すべての前提を確認します。
ExpressRoute の高度なトラブルシューティング
クラウドのエッジがどこに存在するか自信がないと、Azure コンポーネントの分離は難しい場合があります。 ExpressRoute では、エッジは Microsoft Enterprise Edge (MSEE) と呼ばれるネットワーク コンポーネントです。 MSEE は、Microsoft のネットワークへの最初の接続点であり、そこを離れるときの最後のホップです。 仮想ネットワーク ゲートウェイと ExpressRoute 回線の間に接続を作成すると、MSEE に接続していることになります。 MSEE を最初または最後のホップとして認識することは、Azure ネットワークの問題を分離するためにきわめて重要です。 トラフィックの方向の認識は、その問題が Azure、WAN 内のさらに下流、または企業ネットワークのいずれの場所に存在するかを判定するのに役立ちます。
Note
MSEE は Azure クラウド内にはありません。 ExpressRoute は Microsoft ネットワークのエッジに位置し、実際に Azure 内にはありません。 ExpressRoute で MSEE に接続されると、Microsoft のネットワークに接続されるため、Microsoft 365 (Microsoft ピアリングを使用) や Azure (プライベート ピアリングまたは Microsoft ピアリング、あるいはその両方を使用) などのクラウド サービスにアクセスできます。
2 つの VNet が同じ ExpressRoute 回線に接続されている場合は、Azure 内での問題を分離するためのテストを実行できます。
テスト計画
VM1 と VM2 の間で Get-LinkPerformance テストを実行します。 このテストは、その問題がローカルなものかどうかに関する分析情報を提供します。 このテストで許容可能な待ち時間と帯域幅の結果が生成された場合は、ローカル仮想ネットワークを良好としてマークできます。
ローカルの仮想ネットワーク トラフィックの状態は良好であると想定し、VM1 と VM3 の間で Get-LinkPerformance テストを実行します。 このテストでは、Microsoft ネットワークから MSEE を経由し Azure に戻るまでの接続が実行されます。 このテストで許容可能な待ち時間と帯域幅の結果が生成された場合は、Azure ネットワークを良好としてマークできます。
Azure が除外された場合は、企業ネットワークに対して同様のテストを実行します。 これらのテストも良好である場合は、サービス プロバイダーまたは ISP と協力して WAN 接続を診断します。 たとえば、2 つのブランチ オフィス間で、または自分のデスクとデータ センター サーバーの間でテストを実行します。 テスト対象のパスを試すことができるサーバーやクライアント PC などのエンドポイントを見つけます。
重要
テストごとに、時刻をマークし、結果を共通の場所に記録します。 一貫性のあるデータ比較を行うには、各テスト実行で同じ出力が得られる必要があります。 複数のテストにまたがる一貫性が、トラブルシューティングに AzureCT を使用する主な理由です。 重要なのは、毎回、一貫性のあるテストとデータ出力を取得することです。 時刻の記録と一貫性のあるデータの取得は、問題が散発的である場合に特に役立ちます。 同じシナリオを再テストする時間を回避するために、事前のデータ収集に努めてください。
問題特定後の手順
問題を細かく分離すればするほど、解決策は早く見つかるようになります。 場合によっては、トラブルシューティングをそれ以上進めることができない地点に達することがあります。 たとえば、リンクがアジア内に留まることを期待しているのに、サービス プロバイダーを超えてホップがヨーロッパに達してしまっていることがあります。 この時点で、問題を分離して突き止めたルーティング ドメインに基づいて、だれかに支援を求めてください。 特定のコンポーネントに絞り込むことができると、さらに好都合です。
企業ネットワークの問題の場合は、社内の IT 部門またはサービス プロバイダーが、デバイスの構成やハードウェアの修理を助けてくれます。
WAN の問題の場合は、テスト結果をサービス プロバイダーまたは ISP と共有して、そこの担当者が冗長なタスクを避け本来の作業をできるようにします。 その担当者が "信頼はするが検証は行う" の原則に基づいて、結果を確認することもできます。
Azure の問題の場合は、その問題をできるだけ詳細に分離したら、Azure ネットワークのドキュメントを確認し、必要な場合はサポート チケットを開きます。
関連情報
待機時間と帯域幅の期待値
ヒント
エンドポイント間の地理的な距離は、待ち時間における最大の要因です。 機器の待ち時間 (物理および仮想コンポーネント、ホップの数など) も役割を果たしますが、ファイバー敷設の距離 (直線距離ではありません) が主要な要因です。 この距離は正確に測定することが困難なため、多くの場合は、大まかな推定値として都市間の距離計算機を使用します。
たとえば、私たちは米国ワシントン州シアトルで ExpressRoute をセットアップしました。 次の表は、さまざまな Azure の場所に対してテストしたときに観察された待ち時間と帯域幅のほか、推定距離を示しています。
テストの設定
Windows Server 2016 を稼働している物理サーバーには、10 Gbps の NIC が 1 枚搭載され、ExpressRoute 回線に接続されています。
プライベート ピアリングが有効になっている 10 Gbps Premium ExpressRoute 回線。
指定されたリージョンには、UltraPerformance ゲートウェイを備えた Azure 仮想ネットワークがあります。
仮想ネットワーク上で Windows Server 2016 を実行している DS5v2 VM。AzureCT がインストールされている既定の Azure イメージを使用しています。
すべてのテストで AzureCT Get-LinkPerformance コマンドを使用し、6 回のテスト実行のそれぞれで 5 分間のロード テストを行いました。 次に例を示します。
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300各テストのデータ フローは、オンプレミス サーバー (シアトルの iPerf クライアント) から Azure VM (一覧表示されている Azure リージョン内の iPerf サーバー) へのものでした。
"待機時間" 列は、ロードなしテスト (iPerf が実行されていない TCP 待機時間テスト) からのデータを示しています。
"最大帯域幅" 列は、1 Mb のウィンドウ サイズの 16 TCP フロー ロード テストからのデータを示しています。
待機時間と帯域幅の結果
重要
これらの数値は一般的な参照用です。 多くの要因が待ち時間に影響を与えます。これらの値は一般に、一定期間にわたって一貫性がありますが、Azure またはサービス プロバイダーのネットワーク内の条件が変化し、待ち時間や帯域幅に影響を与える場合があります。 一般には、これらの変化が大きな違いをもたらすことはありません。
| ExpressRoute の場所 | Azure リージョン | 推定距離 (km) | Latency | 1 セッションの帯域幅 | 最大帯域幅 |
|---|---|---|---|---|---|
| Seattle | 米国西部 2 | 191 km | 5 ミリ秒 | 262.0 メガビット/秒 | 3.74 ギガビット/秒 |
| Seattle | 米国西部 | 1,094 km | 18 ミリ秒 | 82.3 メガビット/秒 | 3.70 ギガビット/秒 |
| Seattle | 米国中部 | 2,357 km | 40 ミリ秒 | 38.8 メガビット/秒 | 2.55 ギガビット/秒 |
| Seattle | 米国中南部 | 2,877 km | 51 ミリ秒 | 30.6 メガビット/秒 | 2.49 ギガビット/秒 |
| Seattle | 米国中北部 | 2,792 km | 55 ミリ秒 | 27.7 メガビット/秒 | 2.19 ギガビット/秒 |
| Seattle | 米国東部 2 | 3,769 km | 73 ミリ秒 | 21.3 メガビット/秒 | 1.79 ギガビット/秒 |
| Seattle | 米国東部 | 3,699 km | 74 ミリ秒 | 21.1 メガビット/秒 | 1.78 ギガビット/秒 |
| Seattle | 東日本 | 7,705 km | 106 ミリ秒 | 14.6 メガビット/秒 | 1.22 ギガビット/秒 |
| Seattle | 英国南部 | 7,708 km | 146 ミリ秒 | 10.6 メガビット/秒 | 896 メガビット/秒 |
| Seattle | 西ヨーロッパ | 7,834 km | 153 ミリ秒 | 10.2 メガビット/秒 | 761 メガビット/秒 |
| Seattle | オーストラリア東部 | 12,484 km | 165 ミリ秒 | 9.4 メガビット/秒 | 794 メガビット/秒 |
| Seattle | 東南アジア | 12,989 km | 170 ミリ秒 | 9.2 メガビット/秒 | 756 メガビット/秒 |
| Seattle | ブラジル南部* | 10,930 km | 189 ミリ秒 | 8.2 メガビット/秒 | 699 メガビット/秒 |
| Seattle | インド南部 | 12,918 km | 202 ミリ秒 | 7.7 メガビット/秒 | 634 メガビット/秒 |
* ブラジルへの待ち時間は、ファイバー敷設の距離が直線距離と大幅に異なっている例です。 予測される待ち時間は約 160 ms ですが、ファイバー ルートが長いために、実際には 189 ms です。
Note
これらの数値は、PowerShell 経由の Windows の iPerf に基づいて、AzureCT を使用してテストされました。 iPerf は、スケール ファクターのための既定の Windows TCP オプションには従わず、TCP ウィンドウ サイズにより小さなシフト カウントを使用します。
-w スイッチとより大きな TCP ウィンドウ サイズで iPerf コマンドを調整することによって、より優れたスループットを実現できます。 また、複数のマシンからマルチスレッド モードで iPerf を実行しても、最大のリンク パフォーマンスに達しやすくなります。 Windows 上で iPerf での最高の結果を得るには、"Set-NetTCPSetting -AutoTuningLevelLocal Experimental" を使用します。 何らかの変更を行う前に、組織のポリシーを確認してください。
次のステップ
- Azure Connectivity Toolkit をダウンロードする
- リンクのパフォーマンス テストの手順に従います