Felsöka svar på serverdelstrafik i Azure Load Balancer

  • Artikel

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

Virtuella datorer bakom en lastbalanserare får ojämn fördelning av trafiken

Om du misstänker att medlemmar i serverdelspoolen tar emot trafik kan det bero på följande orsaker. Azure Load Balancer distribuerar trafik baserat på anslutningar. Kontrollera trafikdistributionen per anslutning och inte per paket. Kontrollera att du använder fliken Flödesdistribution på din förkonfigurerade instrumentpanel för Load Balancer Insights.

Azure Load Balancer stöder inte verklig resursallokeringsbelastningsutjämning men stöder ett hashbaserat distributionsläge.

Orsak 1: Du har konfigurerat sessionspersistence

Om du använder distributionsläget för källpersistence kan det orsaka en ojämn fördelning av trafiken. Om den här distributionen inte önskas uppdaterar du sessionspersistensen till Ingen så att trafiken distribueras över alla felfria instanser i serverdelspoolen. Läs mer om distributionslägen för Azure Load Balancer.

Orsak 2: Du har en proxy konfigurerad

Klienter som körs bakom proxyservrar kan ses som ett unikt klientprogram från lastbalanserarens synvinkel.

Virtuella datorer bakom en lastbalanserare svarar inte på trafik på den konfigurerade dataporten

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

  • En virtuell dator för lastbalanserarens serverdelspool lyssnar inte på dataporten

  • Nätverkssäkerhetsgruppen blockerar porten på den virtuella datorn för lastbalanserarens serverdelspool

  • Åtkomst till lastbalanseraren från samma virtuella dator och nätverkskort

  • Åtkomst till Internet-lastbalanserarens klientdel från den virtuella datorn för den deltagande lastbalanserarens serverdelspool

Orsak 1: En virtuell dator för lastbalanserarens serverdelspool lyssnar inte på dataporten

Om en virtuell dator inte svarar på datatrafiken kan det bero på att 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 serverdelsdatorn.

  2. Öppna en kommandotolk och kör följande kommando för att verifiera att ett program lyssnar på dataporten: 

    netstat -an

  3. Om porten inte visas med tillståndet LYSSNA konfigurerar du rätt lyssnarport

  4. Om porten är markerad som LYSSNAR kontrollerar du målprogrammet på porten för eventuella problem.

Orsak 2: En nätverkssäkerhetsgrupp blockerar porten på den virtuella datorn för lastbalanserarens serverdelspool

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 för lastbalanserarens serverdel. Kontrollera att IP-adressen för klienterna tillåts i serverdelsdatorns nätverkssäkerhetsgrupp.

  1. Visa en lista över nätverkssäkerhetsgrupper som konfigurerats på den virtuella serverdelsdatorn. 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 störningar.

    • En regel för neka alla nätverkssäkerhetsgrupper på nätverkskortet för den virtuella datorn eller det undernät som har högre prioritet än standardregeln som tillåter lastbalanserarens avsökningar och trafik (nätverkssäkerhetsgrupper måste tillåta lastbalanserings-IP på 168.63.129.16, dvs. 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 den interna lastbalanseraren från samma virtuella dator och nätverksgränssnitt

Om ditt program som finns på den virtuella serverdelsdatorn för en intern lastbalanserare försöker komma åt ett annat program som finns på samma virtuella serverdelsdator via samma nätverksgränssnitt, är det ett scenario som inte stöds och kommer att misslyckas.

Lösning

Du kan lösa det här problemet via någon av följande metoder:

  • Konfigurera separata virtuella datorer i serverdelspoolen per program.

  • Konfigurera programmet på virtuella datorer med dubbla nätverkskort så att varje program använde sitt eget nätverksgränssnitt och sin IP-adress.

Orsak 4: Åtkomst till den interna lastbalanserarens klientdel från den virtuella datorn för den deltagande lastbalanserarens serverdelspool

Om en intern lastbalanserare har konfigurerats i ett virtuellt nätverk och en av de virtuella datorerna i deltagarens serverdel försöker komma åt den interna lastbalanserarens klientdel kan fel inträffa när flödet mappas till den ursprungliga virtuella datorn. Det här scenariot stöds inte.

Lösning

Det finns flera sätt att avblockera det här scenariot, inklusive att använda en proxy. Utvärdera Application Gateway eller andra proxyservrar 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 till klientdelen av en intern lastbalanserare eftersom båda är i privat IP-adressutrymme. 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 bieffekt är att om ett utgående flöde från en virtuell dator i serverdelspoolen försöker ett flöde till klientdelen av den interna lastbalanseraren i poolen och mappas tillbaka till sig själv, matchar inte flödets två ben. Eftersom de inte matchar misslyckas flödet. Flödet lyckas om flödet inte mappas tillbaka till samma virtuella dator i serverdelspoolen som skapade flödet till klientdelen.

När flödet mappas tillbaka till sig självt verkar det utgående flödet komma från den virtuella datorn till klientdelen, och motsvarande inkommande flöde verkar komma från den virtuella datorn till sig själv. Från gästoperativsystemets synpunkt matchar inte de inkommande och utgående delarna av samma flöde inuti 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 serverdelspoolen matchar flödeshalvorna och den virtuella datorn kan svara på flödet.

Symptomet för det här scenariot är tillfälliga tidsgränser för anslutningen när flödet återgår till samma serverdel som kom från flödet. Vanliga lösningar är infogning av ett proxylager bakom den interna lastbalanseraren och användning av DSR-formatregler (Direct Server Return). Mer information finns i Flera klientdelar för Azure Load Balancer.

Du kan kombinera en intern lastbalanserare med valfri proxy från tredje part eller använda en intern Application Gateway för proxyscenarier med HTTP/HTTPS. Även om du kan använda en offentlig lastbalanserare för att åtgärda det här problemet är det resulterande scenariot utsatt för SNAT-överbelastning. Undvik den här andra metoden om den inte hanteras noggrant.

Nästa steg

Om föregående steg inte löser problemet öppnar du ett supportärende.