ネットワーク パフォーマンスのトラブルシューティング

まとめ

Azureは、オンプレミス ネットワークをAzureに接続するための安定した高速な方法を提供します。 サイト間 VPN や ExpressRoute などの方法は、あらゆる規模のお客様がAzureでビジネスを実行するために正常に使用されます。 しかし、パフォーマンスが期待や以前のエクスペリエンスを満たしていない場合はどうなりますか? この記事は、特定の環境をテストしてベースラインを設定する方法を標準化するのに役立ちます。

2 つのホスト間のネットワーク待機時間と帯域幅を簡単かつ一貫してテストする方法について説明します。 また、Azure ネットワークを見て問題の特定に役立つ方法に関するアドバイスを受け取ります。 説明されている PowerShell スクリプトとツールには、ネットワーク上の 2 つのホストが必要です (テスト対象のリンクの両端)。 1 つのホストはWindows Serverまたはデスクトップである必要があり、もう 1 つは Windows または Linux のいずれかです。

ネットワーク コンポーネント

トラブルシューティングを行う前に、いくつかの一般的な用語とコンポーネントについて説明しましょう。 この説明により、Azureでの接続を可能にするエンド ツー エンド チェーン内の各コンポーネントについて検討しています。

ExpressRoute または VPN を使用したオンプレミスから Azure へのネットワーク ルーティング ドメインのダイアグラム

最上位レベルでは、3 つの主要なネットワーク ルーティング ドメインがあります。

• Azure ネットワーク (ブルー クラウド)
• インターネットまたは WAN (緑色の雲)
• 企業ネットワーク (オレンジ色の雲)

右から左の図を見て、各コンポーネントについて簡単に説明しましょう。

• 仮想マシン - サーバーに複数の NIC がある可能性があります。 静的ルート、既定のルート、オペレーティング システムの設定が、思い通りにトラフィックを送受信していることを確認します。 また、各 VM SKU には帯域幅の制限があります。 小さい VM SKU を使用している場合、トラフィックは NIC で使用可能な帯域幅によって制限されます。 テストには DS5v2 を使用して、VM で十分な帯域幅を確保することをお勧めします。

• 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 - User-Defined ルートは、トラフィックを中間ホップ (ファイアウォールやロード バランサーなど) に転送できます。 トラフィックに 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接続ツールキット

AzureCT PowerShell モジュールには、Availability Testing と Performance Testing の 2 つのコンポーネントが含まれています。 このドキュメントでは、パフォーマンス テスト、特にこの PowerShell モジュールの 2 つのリンク パフォーマンス コマンドについて説明します。

パフォーマンス テストにこのツールキットを使用する 3 つの基本的な手順を次に示します。

1. PowerShell モジュールをインストールする

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   このコマンドは、PowerShell モジュールをローカルにダウンロードしてインストールします。

2. サポート アプリケーションのインストール

   Install-LinkPerformance
   

   この AzureCT コマンドは、iPerf と PSPing を新しいディレクトリ C:\ACTTools にインストールし、ICMP およびポート 5201 (iPerf) トラフィックを許可する Windows ファイアウォール ポートを開きます。

3. パフォーマンス テストを実行する

   まず、リモート ホストで、サーバー モードで iPerf をインストールして実行します。 リモート ホストが 3389 (rdp for Windows) または 22 (Linux の場合は SSH) でリッスンし、iPerf のポート 5201 でトラフィックを許可していることを確認します。 リモート ホストがWindowsされている場合は、AzureCT をインストールし、Install-LinkPerformance コマンドを実行して iPerf と必要なファイアウォール規則を設定します。

   リモート コンピューターの準備ができたら、ローカル コンピューターで PowerShell を開き、テストを開始します。

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   このコマンドは、一連の同時読み込みと待機時間のテストを実行して、ネットワーク リンクの帯域幅の容量と待機時間を見積もります。

4. テスト出力を確認する

   PowerShell の出力形式は次のようになります。

   リンク パフォーマンス テストの PowerShell 出力のスクリーンショット。

   すべての iPerf テストと PSPing テストの詳細な結果は、 の AzureCT ツール ディレクトリ内の個々のテキスト ファイルに保存されます。

トラブルシューティング

パフォーマンス テストの結果が期待どおりでない場合は、体系的なアプローチに従って問題を特定します。 パス内のコンポーネントの数を考えると、段階的なプロセスはランダム テストよりも効果的です。

1. 想定に挑戦する

   期待が妥当であることを確認します。 たとえば、1 Gbps の ExpressRoute 回線と 100 ミリ秒の待機時間では、1 Gbps の完全なトラフィックは、待機時間の長いリンクに対する TCP のパフォーマンス特性により非現実的です。 パフォーマンスの前提条件の詳細については、「 リファレンス」セクション を参照してください。

2. ネットワークの端から開始する

   ルーティング ドメイン間の端から始め、問題を 1 つの主要なルーティング ドメインに分離します。 詳細な調査を行わずにパス内の "ブラック ボックス" を非難することは避けてください。これにより解決が遅れる可能性があります。

3. ダイアグラムを作成する

   問題を体系的に処理して分離するために、問題の領域の図を描画します。 領域を明確にしたり深く掘り下げる際に、テスト ポイントを計画し、マップを更新します。

4. 分割して征服する

   ネットワークをセグメント化し、問題を絞り込みます。 動作する場所と機能しない場所を特定し、問題のあるコンポーネントを分離するためにテスト ポイントを移動し続けます。

5. すべての OSI レイヤーを検討する

   ネットワークとレイヤー 1 ~ 3 (物理、データ、ネットワークレイヤー) に焦点を当てることは一般的ですが、問題はレイヤー 7 (アプリケーション層) でも発生する可能性があります。 先入観を抱かずに、すべての想定を確認します。

ExpressRoute の高度なトラブルシューティング

クラウドのエッジがどこにあるかわからない場合、Azureコンポーネントを分離することは困難な場合があります。 ExpressRoute では、エッジは Microsoft Enterprise Edge (MSEE) と呼ばれるネットワーク コンポーネントです。 MSEE は、Microsoft のネットワークへの最初の接触点であり、離れる際の最後のホップです。 仮想ネットワーク ゲートウェイと ExpressRoute 回線の間に接続を作成すると、MSEE に接続します。 MSEE を最初または最後のホップとして認識することは、Azureネットワークの問題を特定するために重要です。 トラフィックの方向を把握することは、問題がAzureにあるか、WAN または企業ネットワークのダウンストリームにあるかを判断するのに役立ちます。

ExpressRoute 回線に接続されている複数の仮想ネットワークの図。

2 つの VNet が same ExpressRoute 回線に接続されている場合は、Azureで問題を特定するためのテストを実行できます。

テスト計画

1. VM1 と VM2 の間で Get-LinkPerformance テストを実行します。 このテストでは、問題がローカルかどうかについての分析情報が提供されます。 テストで許容可能な待機時間と帯域幅の結果が生成される場合は、ローカル仮想ネットワークを適切なものとしてマークできます。

2. ローカル仮想ネットワーク トラフィックが適切であると仮定して、VM1 と VM3 の間で Get-LinkPerformance テストを実行します。 このテストでは、Microsoft ネットワーク経由で MSEE に接続し、Azureに戻ります。 テストで許容可能な待機時間と帯域幅の結果が生成される場合は、Azure ネットワークを良好としてマークできます。

3. Azureが除外された場合は、企業ネットワークで同様のテストを実行します。 これらのテストも適切な場合は、サービス プロバイダーまたは ISP と連携して WAN 接続を診断してください。 たとえば、2 つのブランチ オフィス間、またはデスクとデータ センター サーバーの間でテストを実行します。 テストするパスを実行できるサーバーやクライアント PC などのエンドポイントを見つけます。

問題は分離されました。次はどうしますか？

問題を分離すればするほど、ソリューションの検出速度が速くなります。 トラブルシューティングを進めることができない場合があります。 たとえば、サービスプロバイダーのリンクがアジアに留まっていることを期待している場合に、ヨーロッパを経由してホップしていることがわかるかもしれません。 この時点で、問題を分離したルーティング ドメインに基づいて、誰かに支援を求めてください。 特定のコンポーネントに絞り込む方が優れています。

企業ネットワークの問題については、社内の IT 部門またはサービス プロバイダーがデバイスの構成やハードウェアの修復に役立ちます。

WAN の問題については、テスト結果をサービス プロバイダーまたは ISP と共有して、作業を支援し、冗長なタスクを回避します。 信頼しても検証するという原則に基づいて、彼らが結果を確認したいと思うかもしれません。

Azureの問題については、できるだけ詳細に問題を特定したら、Azureネットワーク ドキュメントを確認し、必要に応じてサポート チケットをを開きます。

References

待機時間/帯域幅の期待値

たとえば、米国ワシントン州シアトルに ExpressRoute を設定します。 次の表は、さまざまなAzureの場所へのテスト時に観察される待機時間と帯域幅と、推定距離を示しています。

テストセットアップ:

• ExpressRoute 回線に接続された、10 Gbps NIC でWindows Server 2016を実行している物理サーバー。

• プライベート ピアリングが有効になっている 10 Gbps Premium ExpressRoute 回線。

• 指定したリージョンに UltraPerformance ゲートウェイがあるAzure仮想ネットワーク。

• AzureCT がインストールされた既定のAzure イメージを使用して、仮想ネットワーク上でWindows Server 2016実行されている DS5v2 VM。

• すべてのテストでは、6 つのテスト実行ごとに 5 分間のロード テストで AzureCT Get-LinkPerformance コマンドを使用しました。 例えば次が挙げられます。

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• 各テストのデータ フローは、オンプレミス サーバー (シアトルの iPerf クライアント) から Azure VM (一覧に示されている Azure リージョンの iPerf サーバー) に送信されました。

• [待機時間] 列には、ロード テストなし (iPerf が実行されていない TCP 待機時間テスト) のデータが表示されます。

• [最大帯域幅] 列には、1 MB のウィンドウ サイズを持つ 16 TCP フロー ロード テストのデータが表示されます。

AzureCT がインストールされているテスト環境の図。

待機時間/帯域幅の結果

※ブラジルまでの待ち時間は、ファイバーラン距離が直線距離と大きく異なる例です。 予想される待機時間は約 160 ミリ秒ですが、ファイバー ルートが長いため、実際には 189 ミリ秒です。

次のステップ

• Azure Connectivity Toolkit
• link パフォーマンス テストの手順に従います