Felsöka Azure Load Balancer svar på backend-trafik

  • Artikel
  • 5 minuter för att läsa

Den här sidan innehåller felsökningsinformation för Azure Load Balancer frågor.

Virtuella datorer bakom Load Balancer härledning av ojämn distribution av trafik

Om du misstänker att medlemmar i backend-poolen tar emot trafik kan det bero på följande orsaker. Azure Load Balancer distribuerar trafik baserat på anslutningar. Se till att kontrollera trafikdistribution per anslutning och inte per paket. Kontrollera med hjälp Flow fliken Distribution på den förkonfigurerade Load Balancer Insights instrumentpanelen.

Observera att Azure Load Balancer inte stöder true round robin load balancing men stöder ett hash-baserat distributionsläge.

Orsak 1: Sessionspersistence har konfigurerats

Om du använder distributionsläget för källpersens kan det orsaka en ojämn fördelning av trafiken. Om detta inte önskas kan du uppdatera sessionspersensen till Ingen så att trafiken distribueras över alla felfria instanser i backend-poolen. Läs mer om distributionslägen för Azure Load Balancer.

Orsak 2: Du har en konfigurerad proxy

Klienter som körs bakom proxys kan ses som ett unikt klientprogram ur Load Balancer perspektiv.

Virtuella datorer bakom Load Balancer svarar inte på trafik på den konfigurerade dataporten

Om en virtuell dator i en backend-pool visas som felfri och svarar på hälsoavsökningarna, men fortfarande inte deltar i belastningsutjämning eller inte svarar på datatrafiken, kan det bero på någon av följande orsaker:

  • Load Balancer den virtuella datorn i backend-poolen lyssnar inte på dataporten
  • Nätverkssäkerhetsgruppen blockerar porten på den virtuella Load Balancer i backend-poolen
  • Åtkomst till Load Balancer från samma virtuella dator och nätverkskort
  • Åtkomst till Internet Load Balancer från den deltagande Load Balancer virtuella datorn i backend-poolen

Orsak 1: Load Balancer den virtuella datorn i backend-poolen inte lyssnar på dataporten

Om en virtuell dator inte svarar på datatrafiken kan det beror på att antingen målporten inte är öppen på den deltagande virtuella datorn eller att den virtuella datorn inte lyssnar på den porten.

Validering och lösning

  1. Logga in på den virtuella datorn i backend-datorn.
  2. Öppna en kommandotolk och kör följande kommando för att verifiera att det finns ett program som lyssnar på dataporten:
    netstat -an
  3. Om porten inte visas med Status "LYSSNAR" konfigurerar du rätt lyssnarport
  4. Om porten är markerad som Lyssnar kontrollerar du om det finns några möjliga problem i målprogrammet på porten.

Orsak 2: Nätverkssäkerhetsgruppen blockerar porten på den virtuella Load Balancer i backend-poolen

Om en eller flera nätverkssäkerhetsgrupper som konfigurerats i undernätet eller på den virtuella datorn blockerar käll-IP-adressen eller porten kan den virtuella datorn inte svara.

För den offentliga lastbalanseraren används IP-adressen för Internetklienterna för kommunikation mellan klienterna och de virtuella datorerna i lastbalanseringsklienten. Kontrollera att IP-adressen för klienterna tillåts i den virtuella datorns nätverkssäkerhetsgrupp på backend-datorn.

  1. Visa en lista över de nätverkssäkerhetsgrupper som konfigurerats på den virtuella datorn i backend-datorn. Mer information finns i Hantera nätverkssäkerhetsgrupper
  2. I listan över nätverkssäkerhetsgrupper kontrollerar du om:
    • inkommande eller utgående trafik på dataporten har interferens.
    • en Regel för att neka alla nätverkssäkerhetsgrupper på nätverkskortet för den virtuella datorn eller undernätet som har högre prioritet än standardregeln som tillåter Load Balancer-avsökningar och trafik (nätverkssäkerhetsgrupper måste tillåta Load Balancer IP-adress 168.63.129.16, som är avsökningsport)
  3. Om någon av reglerna blockerar trafiken tar du bort och konfigurerar om reglerna så att datatrafiken tillåts.
  4. Testa om den virtuella datorn nu har börjat svara på hälsoavsökningarna.

Orsak 3: Åtkomst till Load Balancer från samma virtuella dator och nätverksgränssnitt

Om ditt program som finns på den virtuella datorn i en Load Balancer-dator i en Load Balancer försöker komma åt ett annat program som finns på samma virtuella dator i en backend-dator via samma nätverksgränssnitt, är det ett scenario som inte stöds och kommer att misslyckas.

Upplösning Du kan lösa problemet med någon av följande metoder:

  • Konfigurera separata virtuella datorer i en backend-pool per program.
  • Konfigurera programmet i dubbla virtuella nätverkskort så att varje program använder ett eget nätverksgränssnitt och en egen IP-adress.

Orsak 4: Åtkomst till den interna Load Balancer från den deltagande Load Balancer virtuella datorn i backend-poolen

Om en intern Load Balancer har konfigurerats i ett virtuellt nätverk och en av de virtuella datorerna i deltagardelsdatorn försöker få åtkomst till den interna Load Balancer-frontend, kan fel uppstå när flödet mappas till den ursprungliga virtuella datorn. Det här scenariot stöds inte.

Upplösning Det finns flera sätt att avblockera det här scenariot, inklusive att använda en proxyserver. Utvärdera Application Gateway eller andra proxyproxy från tredje part (till exempel nginx eller haproxy). Mer information om Application Gateway finns i Översikt över Application Gateway

Detaljer Interna lastbalanserare översätter inte utgående anslutningar från ursprung till frontend-delen av en intern Load Balancer eftersom båda finns i det privata IP-adressutrymmet. Offentliga lastbalanserare tillhandahåller utgående anslutningar från privata IP-adresser i det virtuella nätverket till offentliga IP-adresser. För interna lastbalanserare undviker den här metoden potentiell SNAT-portöverbelastning i ett unikt internt IP-adressutrymme, där översättning inte krävs.

En sidoeffekt är att om ett utgående flöde från en virtuell dator i backend-poolen försöker ett flöde till frontend av den interna Load Balancer:en i dess pool och mappas tillbaka till sig själv, matchar inte de två flödesförsöken. Eftersom de inte matchar misslyckas flödet. Flödet lyckas om flödet inte mappade tillbaka till samma virtuella dator i backend-poolen som skapade flödet till frontend.

När flödet mappar tillbaka till sig självt verkar det utgående flödet komma från den virtuella datorn till frontend och motsvarande inkommande flöde verkar komma från den virtuella datorn till sig själv. Från gästoperativsystemets perspektiv matchar inte de inkommande och utgående delarna i samma flöde i den virtuella datorn. TCP-stacken känner inte igen dessa halvor av samma flöde som en del av samma flöde. Källan och målet matchar inte. När flödet mappar till en annan virtuell dator i backend-poolen matchar halvorna av flödet och den virtuella datorn kan svara på flödet.

Symtomet för det här scenariot är tillfälliga tidsgränser för anslutningar när flödet återgår till samma backend som kom från flödet. Vanliga lösningar är infogning av ett proxylager bakom den interna Load Balancer och användning av regler för DSR-format (Direct Server Return). Mer information finns i Multiple Frontends for Azure Load Balancer.

Du kan kombinera en intern Load Balancer med en proxy från tredje part eller använda interna Application Gateway för proxyscenarier med HTTP/HTTPS. Du kan använda en offentlig Load Balancer för att åtgärda problemet, men det resulterande scenariot är känsligt för SNAT-utmattning. Undvik den här andra metoden om du inte hanteras noggrant.

Nästa steg

Om ovanstående steg inte löser problemet öppnar du en supportbiljett.