Aracılığıyla paylaş

SDN için Yazılım Yük Dengeleyici sorunlarını giderme

Şunlar için geçerlidir: Azure Yerel 2311.2 ve üzeri; Windows Server 2022, Windows Server 2019

Yazılım Tanımlı Ağ (SDN) için Yazılım Yük Dengeleyici (SLB) ayarladıysanız ve veri yolunuz SLB üzerinden çalışmıyorsa, bunun arkasında birkaç neden olabilir. Bu makale, SDN için SLB'deki bazı yaygın sorunları belirlemenize ve gidermenize yardımcı olur.

SLB'ye genel bakış ve nasıl yönetileceğini öğrenmek için bkz. SDN için Yazılım Yük Dengeleyici (SLB) nedir? ve SDN için Yazılım Yük Dengeleyiciyi Yönetme.

İş akışı sorunlarını giderme

SLB sorunlarını gidermek için üst düzey iş akışı aşağıdadır:

  • SLB Multiplexer (MUX) VM'lerinin yapılandırma durumunu denetleme
  • Yaygın yapılandırma durumu hatalarını giderme
  • SLB durum dökümünü toplayın

SLB Multiplexer VM'lerinin yapılandırma durumunu denetleme

Önce SLB MUX VM'lerinin yapılandırma durumunu denetlemeniz gerekir. Bunu yapmak için Windows Yönetim Merkezi'ni veya PowerShell'i kullanabilirsiniz.

Windows Yönetim Merkezi aracılığıyla SLB MUX'ın yapılandırma durumunu denetlemek için şu adımları izleyin:

  1. Windows Admin Center giriş ekranında, Tüm bağlantılar'ın altında, bağlanmak istediğiniz sistemi seçin.

  2. Araçlar'ın altında aşağı kaydırarak Ağ alanına gidin. SDN Altyapısı'nın ardından Özet'i seçin. SLB ile ilgili sorunlar varsa, Bunu Yük Dengeleyiciler MUX bölümünde görürsünüz. Sorun yoksa, tüm MUX VM'leri Sağlıklı durumdadır.

    Windows Yönetim merkezinde Yük Dengeleyiciler MUX'ın durumunu gösteren SDN Altyapısı sayfasının ekran görüntüsü.

Yaygın yapılandırma durumu hatalarını giderme

Bu bölümde, SLB MUX VM'lerinin yapılandırma durumu iyi durumda değilse yaygın hataların nasıl giderilir açıklanmaktadır.

SLB MUX bir BGP yönlendiricisine bağlı değil

MUX VM'leri, raf üstü (ToR) anahtarlarıyla Sınır Ağ Geçidi Protokolü (BGP) eşlemesi oluşturamadığında bu hata oluşur. MUX'un 179 numaralı bağlantı noktasında BGP aracılığıyla ToR ile eşlendiğini unutmayın.

MUX VM'leri ve BGP yönlendiricisi bağlantı hatasını çözmek için:

  • MUX VM'leri ile ToR anahtarları arasında bağlantınız olduğundan emin olun. Ağ sanallaştırma kullanıyorsanız eşleme, Hyper-V Ağ Sanallaştırma Sağlayıcısı Adresi (HNV PA) ağı üzerinden gerçekleşmelidir.

  • MUX VM'lerinde aşağıdakileri çalıştırarak bağlantının kurulup kurulmadığını denetleyin:

    Netstat -anp tcp | findstr 179

    MUX ile ToR arasında bağlantı yoksa, MUX'tan Test-NetConnection kullanarak ToR'ye ulaşılıp ulaşılamadığını kontrol edin. MUX, ToR'a ulaşamıyorsa, altındaki ağ yapısı veya ToR ile ilgili bir sorun vardır.

    Test-NetConnection -ComputerName <ToR_IP> -Port 179

    nerede:

    • ToR_IP loadBalancerMuxes kaynağının bir parçasıdır.

    Aşağıda, ToR IP adresi 192.168.200.1 olan LoadBalancerMux kaynağının bir parçacığı yer alır:

        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" 
        }

  • Birden fazla anahtar yapılandırılmışsa, bunların tümünün MUX VM'leriyle eşleştirildiğinden emin olun.

  • Başarısız BGP eşlemesiyle ilgili daha ayrıntılı hata ayıklama yapmak için betiği herhangi bir fiziksel konakta çalıştırın Test-SDNExpressBGP.

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

    nerede:

    • RouterIPAddress ToR IP'dir
    • LocalIPAddress SLBMUX VM'sinden gelen PA IP adresidir
    • LocalASN SDN SLB ASN'dir
    • ComputerName SLBMUX VM'sinin adıdır

    Betik, MUX VM'sinde SLBMUX hizmetini durdurur, ardından başarısız veya başarılı olan bir bağlantı kurmaya çalışır. Eğer bir hata oluşursa, daha fazla ayrıntı sağlar.

Sanal sunucuya ulaşılamıyor

Sanal sunucuda ağ hataları veya kimlik doğrulaması reddi nedeniyle bu hatayı alabilirsiniz. Bu durum genellikle Ağ Denetleyicisi'nin SLB MUX VM'lerine bağlanamadığını gösterir.

Sanal sunucuya ulaşılamama sorununu gidermek için şunları denetleyin:

  • Ağ Denetleyicisi ile MUX VM'leri arasında bağlantı vardır. Bağlantıyı denetlemek için aşağıdaki komutu çalıştırın:

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

  • MUX hizmeti MUX VM'lerinde çalışıyor. Bunu denetlemek için, MUX VM'lerinde bir PowerShell oturumundan aşağıdaki komutu çalıştırın. Durum Çalışır durumda olmalıdır.

    Get-Service slbmux

  • Güvenlik duvarı sorunları yoktur. 8560 numaralı bağlantı noktasının MUX VM'sinde güvenlik duvarı tarafından engellenmediğinden emin olun. Test-NetConnection Komut başarılı olursa güvenlik duvarı sorunu olmadığı anlamına gelir.

Sertifika güvenilir değil veya sertifika yetkilendirilmedi

SLB MUX tarafından Ağ Denetleyicisi'ne sunulan sertifikada bazı sorunlar varsa bu hatayı alabilirsiniz.

  1. Sertifikayı tanımlamak için MUX VM'lerinde aşağıdaki komutu çalıştırın:

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

    nerede:

    • NodeFQDN , MUX VM'sinin FQDN'sini ifade eder.

  2. Sertifikayı tanımladıktan sonra sertifikayı denetleyin:

    1. Sertifikayı test etmek için aşağıdaki komutu çalıştırın:

      Test-Certificate $cert

    2. Sertifikaya Ağ Denetleyicisi VM'leri tarafından güvenildiğinden emin olun. Sertifika otomatik olarak imzalanan bir sertifikaysa, tüm Ağ Denetleyicisi VM'lerinin kök deposunda aynı sertifika bulunmalıdır. Sertifika CA imzalıysa, CA sertifikası tüm Ağ Denetleyicisi VM'lerinin kök deposunda bulunmalıdır. Ağ Denetleyicisi VM'lerinin kök deposundaki tüm sertifikaları listelemek için, tüm Ağ Denetleyicisi VM'lerinde aşağıdaki komutu çalıştırın:

      get-childitem "cert:\localmachine\root"

İlke yapılandırma hatası

Bu hata şunlardan biri olarak bildirimde bulunabilir: PolicyConfigurationFailureonHost, PolicyConfigurationFailureonMux, PolicyConfigurationFailureonVfp veya PolicyConfigurationFailure.

Ağ Denetleyicisi, ulaşılabilirlik veya sertifika sorunları ya da başka bir sorun nedeniyle SLB MUX VM'lerine veya Hyper-V konaklarına ilke gönderemiyorsa bu hata oluşur.

İlke yapılandırması hatasını gidermek için önce herhangi bir ulaşılabilirlik ve sertifika sorunu olup olmadığını denetleyin. Önceki bölümlerde yer alan adımlara bakın: SLB MUX bir BGP yönlendiricisine bağlı değil, Sanal sunucuya ulaşılamıyor ve Sertifika güvenilir değil veya sertifika yetkilendirilmedi.

Herhangi bir ulaşılabilirlik ve sertifika sorunu yoksa, Ağ Denetleyicisi ile SLB MUX VM'leri ile konak üzerindeki SLB konak aracısı arasındaki bağlantıyı denetlemek için aşağıdaki adımları gerçekleştirin:

  1. Ağ Denetleyicisi ile SLB MUX VM'leri arasındaki bağlantıyı denetleyin. Ağ Denetleyicisi'nin (SlbManager hizmeti) 8560 numaralı bağlantı noktasında MUX'a bağlandığını unutmayın. Ağ Denetleyicisi bağlantıyı başlatır. Çeşitli sanal IP adresi (VIP) yapılandırmaları, Kaynak Ağ Adresi Çevirisi (SNAT) bağlantı noktaları vb. bu bağlantı üzerinden gönderilir.

    Ağ Denetleyicisi ile SLB MUX arasındaki bağlantıyı denetlemek için SLB MUX VM'lerinde komutunu çalıştırın netstat .

    Aşağıda komut kullanımının örnek bir çıktısı verilmiştir:

    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. Ağ Denetleyicisi ile SLB konak aracısı arasındaki bağlantıyı denetleyin. SLB konak aracısının 8571 numaralı bağlantı noktası üzerinden Ağ Denetleyicisi'ne (SlbManager hizmeti) bağlandığını unutmayın. Bu bağlantı aracılığıyla çeşitli SLB politikaları gönderiliyor.

    Ağ Denetleyicisi ile SLB konak aracısı arasındaki bağlantıyı denetlemek için fiziksel konakta komutunu çalıştırın netstat .

    Aşağıda komut kullanımının örnek bir çıktısı verilmiştir:

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

Veri yolu bağlantı sorunları

SLB MUX VM'leri iyi durumdayken bile veri yolu bağlantı sorunlarıyla karşılaşabilirsiniz. Bu, SLB trafiğinin yol boyunca bir yerde kaybolduğunu gösterir. Trafiğin nerede kesildiğini belirlemek için veri yolu izlemelerini toplamanız gerekir. Bunu gerçekleştirmeden önce aşağıdakilerden emin olun:

  • ToR anahtarı tanıtılan VIP'leri görebilir. Yük dengeleme, gelen NAT, giden NAT veya bunların bir bileşimi için bir yük dengeleyici ayarladığınızda, yük dengeleyicinin VIP'si ToR'a tanıtılır. Switch CLI'sini kullanarak VIP'nin ilan edilip edilmediğini kontrol edin.

  • SLBM VIP'sinin ToR'da veya fiziksel güvenlik duvarlarında engellenmemesi gerekir. Bu, Ağ Denetleyicisinin LoadBalancerManager/config kaynağında loadBalancerManagerIPAddress olarak belirtilen IP adresidir. Gelen paket geldiğinde ve MUX VM paketin gönderileceği doğru arka uç IP adresini belirlediğinde, paketi MUX SLBM VIP olarak kaynak IP adresiyle gönderir. Bunun ToR'de dışarıda bırakıldığı senaryolar olabilir.

  • SLB Sağlık sondaları çalışır durumda. SLB sistem durumu yoklamalarını yapılandırdıysanız arka uç VM'lerinden en az birinin etkin olduğundan ve sistem durumu yoklamasına yanıt verebildiğinden emin olun. Ayrıca, bu makalenin devamında açıklandığı gibi SLB durum dökümü aracılığıyla yoklamaların durumunu alabilirsiniz.

  • Arka uç VM'sinin içindeki güvenlik duvarı trafiği engellemez. Arka uç VM'lerindeki konak güvenlik duvarının gelen SLB trafiğini engellemediğinden emin olun.

  • SDN Ağ Güvenlik Grupları trafiği engellemez. Doğrudan arka uç NIC'sinde veya alt ağda yapılandırılmış bazı ağ güvenlik gruplarınız olabilir. Ağ güvenlik grubunun gelen SLB trafiğini engellemediğinden emin olun.

    1. PowerShell aracılığıyla ağ güvenlik gruplarını denetlemek için bir makinede aşağıdaki komutları çalıştırın; bu komutlar Ağ Denetleyicisi'ne REST komutları verebilir:

      • NetworkInterface kaynağının ayrıntılarını almak için aşağıdaki komutu çalıştırın:

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

      • VirtualNetworkSubnet kaynağının ayrıntılarını almak için aşağıdaki komutu çalıştırın:

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

      • LogicalNetworkSubnet kaynağının ayrıntılarını almak için aşağıdaki komutu çalıştırın:

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

    2. Önceki komutların çıktısında, AccessControlList için bir bölüm vardır. Bu kaynaklara herhangi bir AccessControlList eklenmiş mi kontrol edebilirsiniz. Evet ise, AccessControlList öğesinin herhangi bir SLB trafiğini engelleyip engellemediğini kontrol etmek için AccessControlList öğesinin ayrıntılarını doğrulamak adına aşağıdaki komutu çalıştırabilirsiniz.

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

    Tüm bu bilgileri aşağıdaki Windows Admin Center uzantılarını kullanarak da bulabilirsiniz:

    • Mantıksal Ağlar için mantıksal ağ ayrıntıları
    • Sanal Ağlar hakkında ayrıntılar için
    • ACL ayrıntıları için Ağ Güvenlik Grupları

SLB durum dökümünü toplayın

Gerekirse, bir SLB durum dökümü oluşturabilir ve hataları denetleyebilirsiniz. Ayrıca, gelişmiş sorun giderme amacıyla durum dökümünü Microsoft ile paylaşabilirsiniz. SLB durum dökümü tüm VIP'ler hakkında uçtan uca bilgi verir. SLB durum dökümünü toplamak için DumpSlbRestState.ps1 betiğini çalıştırabilirsiniz. Aşağıdaki bölümde, durum dökümünü denetleyebileceğiniz çeşitli hata senaryoları açıklanmaktadır.

MuxAdvertisedRoutes'un boş olup olmadığını veya etkilenen VIP'lerin eksik olup olmadığını denetleyin

Aşağıda boş olan MuxAdvertisedRoutes bir örnek verilmiştir. Bu, MUX'in ToR'a herhangi bir güzergah bildirmediğini gösterir. Bu durumda, tüm VIP'ler devre dışıdır.

"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=[]"

  • Yollar boşsa, sorun MUX-ToR eşlemesi veya SLBM'nin doğru hedef durumunu göndermemesi olabilir.

  • Diğer durumlarda, yollarda yalnızca birkaç VIP eksiktir ve bu durum yalnızca onların bağlantısının başarısız olmasına neden olur. Öyleyse, sorun SLBM'nin hedef durumu itmemesi.

Hafifletme

SlbManager hizmetinin ve ControllerService hizmetinin birincil sunucusunu taşıyın ve ana bilgisayar ajanlarını yeniden başlatın.

  • SlbManager ve ControllerService'in birincil öğesini taşımak için Ağ Denetleyicisi VM'sinde aşağıdaki komutları çalıştırın:

    1. Ağ Denetleyicisi hizmet modüllerinin birincil olarak hangi makineyi kullandığını belirlemek için aşağıdaki komutu çalıştırın:

      Get-NetworkControllerReplica

    2. SlbManagerService ve ControllerService için MachineName değerini bulun. İlgili makinelere gidin ve aşağıdaki komutu çalıştırın:

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

      Bu işlem, farklı bir Ağ Denetleyicisi VM'sinde işlemleri yeniden başlatır.

  • Konak aracılarını yeniden başlatmak için her fiziksel konakta aşağıdaki komutu çalıştırın:

    Restart-Service nchostagent --force
Start-Service slbhostagent

VipAddress için programlama ve bağlantı durumunu denetleme

SLB durum dökümünün bu bölümü VIP hakkında ayrıntılı bilgi sağlar. SLBM, MUX ve konaklarda VIP'nin durumunu sağlar. Sunucu altında, şu anda VIP'nin parçası olan tüm "dips" verilerini boşaltır. Listenin yapılandırmayla tutarlı olduğundan emin olun. Sorun giden bağlantılarla ilgiliyse, SNAT yapılandırmalarını denetleyin ve MUX'lar ile konak arasındaki port ayırımlarının tutarlı olduğundan emin olun.

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

Veri yolu izlemelerini toplama

Önceki yöntemlerden hiçbiri çözüm sağlamadıysa veri yolu günlüklerini toplayın ve Microsoft'a gönderin.

Aşağıdaki günlükleri toplayın:

Aşağıdaki günlükler yalnızca kısa bir süre için toplanmalıdır. Kaydı başlatın, senaryoyu yeniden çalıştırın ve ardından kaydı durdurun.

  • MUX izleri. Bu izlemelerin MUX VM'lerinde toplanması gerekir. İzlemeleri toplamak için şu adımları izleyin:

    1. Günlüğe kaydetmeye başlamak için aşağıdaki komutu çalıştırın:

      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. Senaryoyu yeniden oluştur.

    3. Günlüğe kaydetmeyi durdurmak için aşağıdaki komutu çalıştırın:

      netsh trace stop

    4. İzleme dosyasını ETL biçiminde belirtilen biçime dönüştürmek için aşağıdaki komutu çalıştırın:

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

  • SLB ana bilgisayar ajanı izlemeleri. Bu izler fiziksel konaklarda toplanmalıdır. İzlemeleri toplamak için şu adımları izleyin:

    1. Günlüğe kaydetmeye başlamak için aşağıdaki komutu çalıştırın:

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

    2. Senaryoyu yeniden oluştur.

    3. Günlüğe kaydetmeyi durdurmak için aşağıdaki komutu çalıştırın:

      netsh trace stop

    4. İzleme dosyasını ETL biçiminde belirtilen biçime dönüştürmek için aşağıdaki komutu çalıştırın:

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

  • VFP izlemeleri. Bu izlemeler, MUX VM'sinin ve kiracı VM'lerin bulunduğu fiziksel konaklarda toplanmalıdır. İzlemeleri toplamak için şu adımları izleyin:

    1. Günlüğe kaydetmeye başlamak için aşağıdaki komutu çalıştırın:

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

    2. Senaryoyu yeniden oluştur.

    3. Günlüğe kaydetmeyi durdurmak için aşağıdaki komutu çalıştırın:

      netsh trace stop

    4. İzleme dosyasını ETL biçiminde belirtilen biçime dönüştürmek için aşağıdaki komutu çalıştırın:

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

Sonraki adımlar