SDN のソフトウェア Load Balancerのトラブルシューティング

適用対象: Azure Stack HCI、バージョン 23H2 および 22H2。Windows Server 2022、Windows Server 2019

ソフトウェア定義ネットワーク (SDN) 用にソフトウェア Load Balancer (SLB) を設定していて、データ パスが SLB を介して動作しない場合、その背後にはいくつかの理由が考えられます。 この記事は、SLB for SDN の一般的な問題を特定してトラブルシューティングするのに役立ちます。

SLB の概要と管理方法については、「SDN のソフトウェア Load Balancer (SLB) とは」および「SDN のソフトウェア Load Balancerの管理」を参照してください。

トラブルシューティングのワークフロー

SLB の問題をトラブルシューティングするためのワークフローの概要を次に示します。

• SLB マルチプレクサー (MUX) VM の構成状態を確認する
• 一般的な構成状態エラーのトラブルシューティング
• SLB 状態ダンプの収集

SLB マルチプレクサー VM の構成状態を確認する

まず、SLB MUX VM の構成状態をチェックする必要があります。 これを行うには、Windows Admin Centerまたは PowerShell を使用します。

Windows Admin Center

Windows Admin Centerを使用して SLB MUX の構成状態をチェックするには、次の手順に従います。

1. Windows Admin Centerホーム画面の [すべての接続] で、接続するクラスターを選択します。

2. [ ツール] で、[ ネットワーク ] 領域まで下にスクロールします。 [ SDN インフラストラクチャ] を選択し、[概要] を選択 します。 SLB に問題がある場合は、 Load Balancers MUX セクションに表示されます。 問題がない場合は、すべての MUX VM が 正常 な状態になります。

   

PowerShell

PowerShell を使用して MUX の構成状態をチェックするには、いずれかのネットワーク コントローラー VM で次のコマンドを実行します。

1. ネットワーク コントローラー アプリケーションの設定を取得するには、次のコマンドを実行します。 出力から、パラメーター値を RestName 書き留めます。

   Get-NetworkController
   

2. REST Uniform Resource Identifier (URI) をパラメーターに割り当てるには、次のコマンドを実行します。

   $uri="https://<RestName>"
   

3. ネットワーク コントローラーによって管理されている SLB MUX VM の構成状態を取得するには、次のコマンドレットを実行します。

   (Get-NetworkControllerLoadBalancerMux -ConnectionUri $uri).Properties.ConfigurationState.DetailedInfo
   

   コマンドの使用例を次に示します。

   (Get-NetworkControllerLoadBalancerMux -ConnectionUri $uri).Properties.ConfigurationState.DetailedInfo
   
   Source                      Message                      Code
   ------                      -------                      ----
   SoftwareLoadBalancerManager Loadbalancer Mux is Healthy. Success
   SoftwareLoadBalancerManager Loadbalancer Mux is Healthy. Success
   

一般的な構成状態エラーのトラブルシューティング

このセクションでは、SLB MUX VM の構成状態が正常でない場合に一般的なエラーをトラブルシューティングする方法について説明します。

SLB MUX が BGP ルーターに接続されていません

このエラーは、MUX VM がラック (ToR) スイッチの上部との Border Gateway Protocol (BGP) ピアリングを確立できなかった場合に発生します。 MUX は、ポート 179 で BGP 経由で ToR にピアリングされます。

MUX VM と BGP ルーターの接続エラーを解決するには:

• MUX VM と ToR スイッチの間に接続されていることを確認します。 ネットワーク仮想化を使用している場合は、Hyper-V ネットワーク仮想化プロバイダー アドレス (HNV PA) ネットワーク経由でピアリングが行われます。

• MUX VM で次を実行して、接続が確立されていることを確認します。

  Netstat -anp tcp | findstr 179
  

  MUX と ToR の間に接続がない場合は、 を使用して Test-NetConnectionToR に MUX から到達できるかどうかをチェックします。 MUX が ToR に到達できない場合は、基になるファブリック ネットワークまたは ToR に問題があります。

  Test-NetConnection -ComputerName <ToR_IP> -Port 179 
  

  各値の説明:

  • ToR_IPは loadBalancerMuxes リソースの一部です。

  ToR IP アドレスが 192.168.200.1 である LoadBalancerMux リソースのスニペットを次に示します。

      Get-NetworkControllerLoadBalancerMux -ConnectionUri $uri|ConvertTo-Json -Depth 10 
  
      "peerRouterConfigurations": [ 
          { 
            "localIPAddress": "", 
            "routerName": "BGPGateway-64000-64001", 
            "routerIPAddress": "192.168.200.1", 
            "peerASN": 64001, 
            "id": "be5850aa-4dce-4203-a9f2-f3de25eaacba" 
          } 
  

• 複数のスイッチが構成されている場合は、それらのすべてが MUX VM とピアリングされていることを確認します。

• 失敗した BGP ピアリングに関連するさらにデバッグを行うには、物理ホストのいずれかでスクリプトを実行 Test-SDNExpressBGP します。

  Install-Module test-sdnexpressbgp
  Test-SDNExpressBGP -RouterIPAddress 10.10.182.3 -LocalIPAddress 10.10.182.7 -LocalASN 64628 -verbose -ComputerName sa18n22mux02 -force
  

  各値の説明:

  • RouterIPAddress は ToR IP です
  • LocalIPAddress は SLBMUX VM からの PA IP アドレスです
  • LocalASN は SDN SLB ASN です
  • ComputerName は SLBMUX VM の名前です

  スクリプトは、MUX VM 上の SLBMUX サービスを停止し、接続の確立 (失敗または完了) を試み、障害が発生した場合に詳細を提供します。

仮想サーバーに到達できない

このエラーは、仮想サーバーでのネットワーク エラーまたは認証拒否が原因で発生する可能性があります。 これは通常、ネットワーク コントローラーが SLB MUX VM に接続できないことを示します。

仮想サーバーに到達できない理由をトラブルシューティングするには、次のようにチェックします。

• ネットワーク コントローラーと MUX VM の間に接続があります。 接続をチェックするには、次のコマンドを実行します。

  Test-NetConnection -ComputerName <MUX IP address> -Port 8560
  

• MUX サービスは、MUX VM で実行されています。 これをチェックするには、MUX VM 上の PowerShell セッションから次のコマンドを実行します。 状態は [実行中] である必要があります。

  Get-Service slbmux
  

• ファイアウォールの問題はありません。 ポート 8560 が MUX VM 上のファイアウォールによってブロックされていないことを確認します。 コマンドが Test-NetConnection 成功した場合は、ファイアウォールの問題がないことを意味します。

証明書が信頼されていないか、証明書が承認されていません

SLB MUX によってネットワーク コントローラーに提示された証明書に問題がある場合は、このエラーが発生する可能性があります。

1. 証明書を識別するには、MUX VM で次のコマンドを実行します。

   $cert= get-childitem "cert:\localmachine\my"| where-object {$_.Subject.ToUpper() eq "CN=$NodeFQDN".ToUpper()} 
   

   各値の説明:

   • NodeFQDN は、MUX VM の FQDN です。

2. 証明書を識別したら、証明書をチェックします。

   1. 証明書をテストするには、次のコマンドを実行します。

      Test-Certificate $cert
      

   2. 証明書がネットワーク コントローラー VM によって信頼されていることを確認します。 証明書が自己署名証明書の場合は、すべてのネットワーク コントローラー VM のルート ストアに同じ証明書が存在する必要があります。 証明書が CA 署名されている場合、CA 証明書は、すべてのネットワーク コントローラー VM のルート ストアに存在する必要があります。 ネットワーク コントローラー VM のルート ストア内のすべての証明書を一覧表示するには、すべてのネットワーク コントローラー VM で次のコマンドを実行します。

      get-childitem "cert:\localmachine\root"
      

ポリシー構成エラー

このエラーは、 PolicyConfigurationFailureonHost、PolicyConfigurationFailureonMux、PolicyConfigurationFailureonVfp、または PolicyConfigurationFailure のいずれかとして表示されます。

このエラーは、到達可能性や証明書の問題、またはその他の問題が原因で、ネットワーク コントローラーが SLB MUX VM または Hyper-V ホストにポリシーをプッシュできない場合に発生します。

ポリシー構成エラーエラーのトラブルシューティングを行うには、まず、到達可能性と証明書の問題があるかどうかをチェックします。 前のセクションの手順を参照してください。 SLB MUX が BGP ルーターに接続されていない、 仮想サーバーに到達できない、 証明書が信頼されていない、または証明書が承認されていません。

到達可能性と証明書の問題がない場合は、次の手順を実行して、ネットワーク コントローラーと SLB MUX VM とホスト上の SLB ホスト エージェントの間の接続をチェックします。

1. ネットワーク コントローラーと SLB MUX VM の間の接続を確認します。 ネットワーク コントローラー (SlbManager サービス) がポート 8560 の MUX に接続されていることに注意してください。 ネットワーク コントローラーが接続を開始します。 この接続を介して、さまざまな仮想 IP アドレス (VIP) 構成、送信元ネットワーク アドレス変換 (SNAT) ポートなどがプッシュされます。

   ネットワーク コントローラーと SLB MUX の間の接続をチェックするには、SLB MUX VM で を実行netstatします。

   コマンドの使用例を次に示します。

   netstat -anp tcp | findstr 8560 
   TCP    0.0.0.0:8560           0.0.0.0:0              LISTENING 
   TCP    100.88.79.12:8560      100.88.79.9:59977      ESTABLISHED 
   

2. ネットワーク コントローラーと SLB ホスト エージェントの間の接続を確認します。 SLB ホスト エージェントがポート 8571 のネットワーク コントローラー (SlbManager サービス) に接続されていることに注意してください。 この接続を介して、さまざまな SLB ポリシーがプッシュされます。

   ネットワーク コントローラーと SLB ホスト エージェント間の接続をチェックするには、物理ホストで を実行netstatします。

   コマンドの使用例を次に示します。

   netstat -anp tcp | findstr 8571 
   TCP    100.88.79.128:56258    100.88.79.9:8571       ESTABLISHED 
   

データ パスの接続に関する問題

SLB MUX VM が正常な構成状態にある場合でも、データ パス接続の問題が発生する可能性があります。 これは、SLB トラフィックが途中でどこかにドロップされていることを意味します。 トラフィックがドロップされる場所を特定するには、データ パス トレースを収集する必要があります。 その前に、次のことを確認します。

• ToR スイッチはアドバタイズされた VIP を見ることができます。 負荷分散、受信 NAT、送信 NAT、またはその組み合わせ用にロード バランサーを設定すると、ロード バランサー VIP が ToR にアドバタイズされます。 スイッチ CLI を使用して、VIP がアドバタイズされているかどうかをチェックします。

• SLBM VIP は、ToR または物理ファイアウォールでブロックしないでください。 これは、ネットワーク コントローラーの LoadBalancerManager/config リソースで loadBalancerManagerIPAddress として指定された IP アドレスです。 受信パケットが着信し、MUX VM がパケットを送信する正しいバックエンド IP を決定すると、送信元 IP アドレスを MUX SLBM VIP としてパケットを送信します。 ToR でドロップされるシナリオが存在する可能性があります。

• SLB 正常性プローブが稼働しています。 SLB 正常性プローブを構成した場合は、少なくとも 1 つのバックエンド VM がアクティブであり、正常性プローブに応答できることを確認します。 この記事で後述するように、 SLB 状態ダンプを使用してプローブの状態を取得することもできます。

• バックエンド VM 内のファイアウォールがトラフィックをブロックしていません。 バックエンド VM 内のホスト ファイアウォールが受信 SLB トラフィックをブロックしていないことを確認します。

• SDN ネットワーク セキュリティ グループはトラフィックをブロックしていません。 一部のネットワーク セキュリティ グループは、バックエンド NIC またはサブネットで直接構成されている場合があります。 ネットワーク セキュリティ グループが受信 SLB トラフィックをブロックしていないことを確認します。

  1. PowerShell を使用してネットワーク セキュリティ グループをチェックするには、コンピューターで次のコマンドを実行します。これにより、REST コマンドをネットワーク コントローラーに発行できます。

     • NetworkInterface リソースの詳細を取得するには、次のコマンドを実行します。

       Get-NetworkControllerNetworkInterface –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the backend NIC>|ConvertTo-Json –Depth 10
       

     • VirtualNetworkSubnet リソースの詳細を取得するには、次のコマンドを実行します。

       Get-NetworkControllerVirtualNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10 
       

     • LogicalNetworkSubnet リソースの詳細を取得するには、次のコマンドを実行します。

       Get-NetworkControllerLogicalNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10 
       

  2. 前のコマンドからの出力には、 の AccessControlListセクションがあります。 これらのリソースにアタッチされている場合AccessControlListは、チェックできます。 はいの場合は、次のAccessControlListコマンドを実行して、 が SLB トラフィックをブロックしているかどうかをチェックする の詳細をAccessControlList確認できます。

     Get-NetworkControllerAccessControlList –ConnectionUri <REST uri of Network Controller> - ResourceId <Resource ID of the AccessControlList>|ConvertTo-Json –Depth 10
     

  また、次のWindows Admin Center拡張機能を使用して、この情報をすべて見つけることもできます。

  • 論理ネットワーク の詳細の論理ネットワーク
  • 仮想ネットワーク の詳細の仮想ネットワーク
  • ACL の詳細に関するネットワーク セキュリティ グループ

SLB 状態ダンプを収集する

必要に応じて、SLB 状態ダンプを作成し、エラーに対してチェックできます。 さらに、高度なトラブルシューティングの目的で、状態ダンプを Microsoft と共有することもできます。 SLB 状態ダンプは、すべての VIP に関するエンド ツー エンドの情報を提供します。 DumpSlbRestState.ps1 スクリプトを実行して、SLB 状態ダンプを収集できます。 次のセクションでは、状態ダンプでチェックできるさまざまなエラー シナリオについて説明します。

MuxAdvertisedRoutes が空か、影響を受ける VIP がないか確認します

が空の例を次に示 MuxAdvertisedRoutes します。 これは、MUX が ToR へのルートをアドバタイズしていないことを意味します。 この場合、すべての VIP がダウンしています。

"name": "MuxRoutes", 
"description": "Mux Routes", 
"dataRetrievalFailed": false, 
"dataUnits": [ 
		{ 
		"value": [ 

"MuxAdvertisedRouteInfo: MuxId=3951dc43-4764-4c65-a4b5-35558c479ce6 MuxDipEndpoint=[172.24.47.12:8560] MuxAdvertisedRoutes=[]", 

"MuxAdvertisedRouteInfo: MuxId=a150f826-6069-4da7-9771-642e80a45c8d MuxDipEndpoint=[172.24.47.13:8560] MuxAdvertisedRoutes=[]"

• ルートが空の場合、問題はピアリング MUX-ToR か、SLBM が正しい目標状態をプッシュしていない可能性があります。

• それ以外の場合は、ルートに少数の VIP のみが存在しないので、接続エラーが発生します。 その場合、SLBM が目標状態をプッシュしないことが問題になります。

軽減策

SlbManager サービスと ControllerService のプライマリを移動し、ホスト エージェントを再起動します。

• SlbManager と ControllerService のプライマリを移動するには、ネットワーク コントローラー VM で次のコマンドを実行します。

  1. ネットワーク コントローラー サービス モジュールがプライマリとして使用するノードを確認するには、次のコマンドを実行します。

     Get-NetworkControllerReplica
     

  2. SlbManagerService と ControllerService の NodeName を見つけます。 それぞれのノードに移動し、次のコマンドを実行します。

     Get-Process Sdnctlr| Stop-Process and Get-Process SdnSlbm | Stop-Process
     

     これにより、別のネットワーク コントローラー VM 上のプロセスが再起動されます。

• ホスト エージェントを再起動するには、すべての物理ホストで次のコマンドを実行します。

  Restart-Service nchostagent --force
  Start-Service slbhostagent
  

VipAddress のプログラミングと接続状態を確認する

SLB 状態ダンプのこのセクションでは、VIP に関する詳細情報を提供します。 これは、SLBM、MUX、およびホスト上の VIP の状態を提供します。 ホストの下では、現在 VIP の一部であるすべての dip がダンプされます。 一覧が構成と一致していることを確認します。 送信接続に問題がある場合は、SNAT 構成をチェックし、MUXes とホスト間のポート割り当てが一貫していることを確認します。

"name": "192.168.102.1", 
"value": [ 
"Programming and Connectivity state for VipAddress: 192.168.102.1", 

データ パス トレースを収集する

前の方法で解決策が提供されていない場合は、データ パス ログを収集して Microsoft に送信します。

次のログを収集します。

• ネットワーク コントローラーのデータ収集ログ。 SDN ログを収集する方法については、「 ソフトウェア定義ネットワーク ログの収集」を参照してください。

次のログは、短時間だけ収集する必要があります。 ログ記録を開始し、シナリオを再現してから、ログ記録を停止します。

• MUX トレース。 これらのトレースは、MUX VM で収集する必要があります。 トレースを収集するには、次の手順に従います。

  1. ログ記録を開始するには、次のコマンドを実行します。

     netsh trace start tracefile=c:\mux.etl globallevel=5 provider=`{645b8679-5451-4c36-9857-a90e7dbf97bc`} provider=`{6C2350F8-F827-4B74-AD0C-714A92E22576`} ov=yes report=disabled
     

  2. シナリオを再現します。

  3. ログ記録を停止するには、次のコマンドを実行します。

     netsh trace stop
     

  4. ETL 形式のトレース ファイルを指定した形式に変換するには、次のコマンドを実行します。

     netsh trace convert input=<trace file> ov=yes
     

• SLB ホスト エージェントトレース。 これらのトレースは、物理ホストで収集する必要があります。 トレースを収集するには、次の手順に従います。

  1. ログ記録を開始するには、次のコマンドを実行します。

     netsh trace start tracefile=c:\slbHA.etl globallevel=5 provider=`{2380c5ee-ab89-4d14-b2e6-142200cb703c`} ov=yes report=disabled
     

  2. シナリオを再現します。

  3. ログ記録を停止するには、次のコマンドを実行します。

     netsh trace stop
     

  4. ETL 形式のトレース ファイルを指定した形式に変換するには、次のコマンドを実行します。

     netsh trace convert input=<trace file> ov=yes
     

• VFP トレース。 これらのトレースは、MUX VM とテナント VM が存在する物理ホストで収集する必要があります。 トレースを収集するには、次の手順に従います。

  1. ログ記録を開始するには、次のコマンドを実行します。

     Netsh trace start scenario=virtualization  capture=yes capturetype=both tracefile=vfp.etl ov=yes report=di
     

  2. シナリオを再現します。

  3. ログ記録を停止するには、次のコマンドを実行します。

     netsh trace stop
     

  4. ETL 形式のトレース ファイルを指定した形式に変換するには、次のコマンドを実行します。

     netsh trace convert input=<trace file> ov=yes
     

次の手順

• Microsoft サポートに問い合わせる