Diagnostisera problem genom att granska konfigurationer och mått

Slutförd

Genom att övervaka prestanda för Azure Load Balancer kan du tidigt få tecken på eventuella fel. Azure Monitor har flera viktiga mått som du kan använda till att undersöka prestandatrender för Load Balancer. Du kan också utlösa aviseringar om en eller flera virtuella datorer (VM) inte tar emot hälsoavsökningens förfrågningar.

I exempelscenariot övervakar du prestanda för det belastningsutjämnade systemet för att säkerställa att systemet uppfyller kraven. Om prestandan spårar av och anslutningarna till virtuella datorer börjar misslyckas, felsöker du systemet för att fastställa orsaken och åtgärda problemet. I slutet av den här lektionen kan du:

  • Beskriva de mått som är tillgängliga för mätning av dataflöde och prestanda i ett belastningsutjämnat system.
  • Använda sidan Resurshälsa i Azure-portalen till att övervaka systemets hälsotillstånd.
  • Förklara hur du löser vanliga problem i ett belastningsutjämnat system.

Använda Azure Monitor till att felsöka Load Balancer

Med Azure Monitor kan du samla in och undersöka diagnostikloggar och prestandadata för Load Balancer.

Övervaka anslutningar

Du kan visualisera mått för Load Balancer med hjälp av fönstret Mått i Azure-portalen. När du ska felsöka anslutningar är de viktigaste måtten Tillgänglighet för datavägar och Status för hälsoavsökningen).

Screenshot of the Metrics page for Azure Load Balancer.

Load Balancer testar kontinuerligt tillgängligheten för sökvägen till klientdelens IP-adress, via reglerna för belastningsutjämning och serverdelspoolen till de program som körs på de virtuella datorerna. Den här informationen registreras som måttet Tillgänglighet för datavägar. Genom att tillämpa måttet Genomsnitt visar du den genomsnittliga tillgängligheten för ett visst tidsintervall. Den här aggregeringen är ett värde mellan 0 (ingen tillgänglighet) och 100, när det finns minst en lyckad sökväg tillgänglig från klientdelens IP-adress till en virtuell dator i serverdelspoolen.

Måttet Status för hälsoavsökningen fungerar ungefär likadant, men gäller endast hälsoavsökningen för de virtuella datorerna snarare än hela vägen via Load Balancer. Återigen ger genomsnittlig aggregering för det här måttet ett värde mellan 0 (alla virtuella datorer är inte felfria och svarar inte) och 100, där alla virtuella datorer svarar på hälsoavsökningen.

Följande skärmbild visar diagrammet för genomsnittlig datasökvägstillgänglighet och genomsnittlig hälsoavsökningsstatus för en lastbalanserare med två virtuella datorer i serverdelspoolen. En av datorerna svarar inte på hälsoavsökningen. Den genomsnittliga hälsoavsökningsstatusen hovrar runt 50-procentsmarkeringen.

Screenshot of the Metrics page for Azure Load Balancer that shows data for the average Health Probe Status and Data Path Availability. The Health Probe status is at 50%.

Ett annat sätt att undersöka de här måtten är med aggregeringen Count (angel). Den här metoden kan ge andra insikter om potentiella problem med din konfiguration. I följande exempel visas ett diagram med antal för måtten Status för hälsoavsökningen och Tillgänglighet för datavägar. Diagrammet visar antalet lyckade avsökningar som utförts under den angivna tiden.

Screenshot of the Metrics page for Azure Load Balancer shows data captured for the Health Probe Status and Data Path Availability metrics.

En intressant punkt i det här diagrammet är att antalet lyckade datasökvägstillgänglighetsavsökningar ligger inom ett konsekvent intervall. Antalet lyckade Status för hälsoavsökningen-kontroller steg dock kraftigt för att sedan falla tillbaka till ungefär hälften av värdet innan toppen.

I konfigurationen som användes för att generera den här grafen innehöll serverdelspoolen bara två virtuella datorer. En av de här datorerna stoppades för att simulera ett haveri. Måttet Tillgänglighet för datavägar visar att klientprogram fortfarande kan ansluta till programmet som körs på den återstående fungerande virtuella datorn. Måttet Status för hälsoavsökningen visar dock att serverdelspoolens övergripande hälsa bara är hälften av normalt.

Visa hälsotillstånd för tjänst

På sidan Resurshälsa för Load Balancer kan du se rapporter om systemets allmänna tillstånd. Du kommer åt den här sidan via Azure Monitor i portalen. Välj Tjänsthälsa och sedan Resurshälsa och sedan Lastbalanserare som resurstyp.

Screenshot that shows the Monitor and Service Health pages in the Azure portal.

Välj din lastbalanserare. Du ser en rapport som beskriver tjänstens hälsohistorik. Du kan visa mer information om objekten i rapporten genom att expandera dem. På följande bild ser du en sammanfattning av när den ena av de virtuella datorerna i serverdelspoolen kopplades ned.

Screenshot of the Resource health page for Azure Load Balancer showing the report that indicates at least one endpoint is unavailable.

Övervaka arbetsbelastningen per virtuell dator

Med de andra måtten som är tillgängliga för Load Balancer kan du spåra antalet byte och nätverkspaket som passerar genom Load Balancer per klientanslutning. En klientanslutning definieras som en kombination av IP-adressen för Load Balancer, protokollet som används för att acceptera inkommande förfrågningar och portnumret som belastningsutjämningsregeln använder för anslutning till de virtuella datorerna. De här måtten kan visa på dataflödet i systemet per aktiv virtuell dator.

I följande diagram visas det genomsnittliga antalet paket som flödar genom Load Balancer när du kör en testarbetsbelastning på 500 samtidiga användare i två minuter. Arbetsbelastningen kördes två gånger. Första gången innehöll serverdelspoolen två VM-instanser. Under den andra körningen stängdes en av de virtuella datorerna av (för att simulera ett haveri).

Screenshot of the average packet count metrics charts for two runs of a test workload.

I det här diagrammet är det genomsnittliga antalet paket per klientdel dubbelt så stort när den ena virtuella datorn stängdes av. Den här arbetsvolymen skulle kunna överbelasta den återstående virtuella datorn, vilket kan ge längre svarstider och eventuella tidsgränsfel.

Undersöka och åtgärda vanliga problem med Load Balancer

I det här avsnittet går vi igenom några vanliga felsituationer som du kan stöta på i Load Balancer. Varje scenario sammanfattar felsymptomen och hur du kan lösa problemet.

Virtuella datorer bakom Load Balancer svarar inte på trafik över avsökningsporten

Det här felet kan bero på följande problem:

  • De virtuella datorerna i serverdelspoolen lyssnar inte på rätt avsökningsport.

    Kontrollera att hälsoavsökningen är rätt inställd i Load Balancer. Se till att programkoden som körs på varje virtuell dator svarar korrekt på avsökningsförfrågningar. Svarsmeddelandet som returneras ska vara HTTP 200 (OK).

  • Nätverkssäkerhetsgruppen för det virtuella undernät som är värd för de virtuella datorerna blockerar avsökningsporten.

    Kontrollera konfigurationen av nätverkssäkerhetsgruppen för det virtuella undernät som innehåller de virtuella datorerna. Se till att nätverkssäkerhetsgruppen tillåter att trafik från Load Balancer passerar genom avsökningsporten.

  • Du försöker komma åt Load Balancer från samma virtuella dator och virtuella nätverkskort. Det här problemet gäller inte själva avsökningen, men det är ett datavägsscenario som inte stöds.

  • Du försöker komma åt klientdelen i Load Balancer från en virtuell dator i serverdelspoolen.

    Båda de här problemen gäller programdesignen. Undvik att skicka förfrågningar till samma instans av Load Balancer från en virtuell dator i serverdelspoolen.

Det är fel på en virtuell dator i serverdelspoolen

I det här fallet svarar de flesta virtuella datorer normalt, men en eller två andra gör det inte. Eftersom vissa virtuella datorer accepterar trafik är hälsoavsökningen troligtvis korrekt konfigurerad. NSG för undernätet blockerar inte porten som används av hälsoavsökningen. Problemet beror förmodligen på de felaktiga virtuella datorerna. Problemet kan bero på att det inte går att komma åt de virtuella datorerna, eller att det är problem med programmen som körs på dessa datorer.

Använd följande steg när du ska ta reda på orsaken till problem med en virtuell dator som inte är felfri:

  • Logga in på en virtuell dator som inte är felfri för att kontrollera att den är igång. Kontrollera att den virtuella datorn kan svara på grundläggande förfrågningar som ping, rdpeller ssh från en annan virtuell dator i serverdelspoolen.
  • Om den virtuella datorn är igång och tillgänglig kontrollerar du att programmet körs.
  • netstat -an Kör kommandot och kontrollera att portarna som används av hälsoavsökningen och programmet visas som LISTENING.

Felaktig konfiguration i Load Balancer

Du måste konfigurera hanteringsreglerna som dirigerar inkommande trafik från klientdelen till serverdelspoolen på rätt sätt i Load Balancer. Om en routningsregel saknas eller inte har konfigurerats korrekt släpps trafik som kommer till klientdelen. När trafiken har släppts rapporteras programmet till klienter som otillgängligt.

Verifiera vägen genom Load Balancer från klientdelen till serverdelspoolen. Du kan använda verktyg som Ping, TCPing och netsh, som är tillgängliga för Windows och Linux. Du kan också använda psping på windows. I följande avsnitt beskrivs hur du använder dessa verktyg.

Använda ping

Pingkommandot testar ping-anslutningen via en slutpunkt med hjälp av ICMP-protokollet. Kontrollera att en väg är tillgänglig från klienten till en virtuell dator via Load Balancer genom att köra följande kommando. Ersätt <ip-adressen> med IP-adressen för Load Balancer-instansen.

ping -n 10 <ip address>
Växling Beskrivning
-n Den här växeln anger antalet ping-begäranden som ska skickas.

Utdata kan se ut så här:

ping -n 10 nn.nn.nn.nn

Pinging nn.nn.nn.nn with 32 bytes of data:
Reply from nn.nn.nn.nn: bytes=32 time=34ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114

Ping statistics for nn.nn.nn.nn:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 29ms, Maximum = 34ms, Average = 30ms

Använda PsPing

Kommandot PsPing testar en ping-anslutning via en slutpunkt. Det här kommandot mäter också svarstiden och bandbredden som är tillgänglig för en tjänst. Kontrollera att en väg är tillgänglig från klienten till en virtuell dator via Load Balancer genom att köra följande kommando. Ersätt <ip address> och <port> med IP-adressen och klientdelsporten för Load Balancer-instansen.

psping -n 100 -i 0 -q -h <ip address>:<port>
Flagga Beskrivning
-n Anger antalet ping-avsökningar som ska göras.
-i Anger intervallet i sekunder mellan iterationerna.
-q Ignorerar utdata under ping-avsökningarna. En sammanfattning visas i slutet.
-h Skriver ut ett histogram som visar förfrågningarnas svarstider.

Utdata kan se ut så här:

TCP connect to nn.nn.nn.nn:nn:
101 iterations (warmup 1) ping test: 100%

TCP connect statistics for nn.nn.nn.nn:nn:
  Sent = 100, Received = 100, Lost = 0 (0% loss),
  Minimum = 7.48ms, Maximum = 9.08ms, Average = 8.30ms

Latency Count
7.48    3
7.56    2
7.65    2
7.73    2
7.82    7
7.90    4
7.98    4
8.07    6
8.15    9
8.24    9
8.32    11
8.40    7
8.49    11
8.57    12
8.66    3
8.74    2
8.82    2
8.91    1
8.99    2
9.08    1

Använda tcping

Tcping-verktyget liknar ping förutom att det fungerar via en TCP-anslutning i stället för ICMP. Använd tcping så här:

tcping <ip address> <port>

Utdata kan se ut så här:

Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.042ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.810ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.266ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.181ms

Ping statistics for nn.nn.nn.nn:nn
     4 probes sent.
     4 successful, 0 failed.  (0.00% fail)
Approximate trip times in milli-seconds:
     Minimum = 9.042ms, Maximum = 9.810ms, Average = 9.325ms

Använda netsh

Verktyget netsh är ett universalverktyg för nätverkskonfiguration. Använd kommandot trace i netsh för att samla in nätverkstrafik. Analysera den sedan med hjälp av ett verktyg som Wireshark. Så här använder du netsh trace till att undersöka de nätverkspaket som skickas och tas emot av psping när du testar anslutningen via Load Balancer:

  1. Starta en nätverksspårning från en kommandotolk du kör som administratör. I följande exempel spåras internettrafik (HTTP-förfrågningar) till och från den angivna IP-adressen. Ersätt <ip address> med adressen till Load Balancer-instansen. Spårningsdata skrivs till en fil med namnet trace.etl.

    netsh trace start ipv4.address=<ip address> capture=yes scenario=internetclient tracefile=trace.etl
    
  2. Kör psping för att testa anslutningen via Load Balancer.

    psping -n 100 -i 0 -q <ip address>:<port>
    
  3. Stoppa spårning.

    netsh trace stop
    

    Det här kommandot tar några minuter att slutföra eftersom det korrelerar och sammanfogar information samtidigt som det skapar utdatafilen.

  4. Starta Wireshark och öppna spårningsfilen.

  5. Lägg till följande filter för spårningen. Ersätt <nn> med portnumret för klientdelen i Load Balancer.

    TCP.Port==80 or TCP.Port==<nn>
    
  6. Lägg till källan och målet för HTTP-förfrågan som fält i spårningsresultatet.

  7. Granska spårningsmeddelandena:

    • Om inga paket kommer in till Load Balancer beror det förmodligen på ett problem med nätverkssäkerheten eller en användardefinierad routning.
    • Om inga utgående paket returneras till klienten är det förmodligen problem med programkonfigurationen eller med en användardefinierad routning.

En VM-brandvägg eller nätverkssäkerhetsgrupp blockerar porten

Om nätverket och Lastbalanseraren är korrekt konfigurerade är den virtuella datorn igång och programmet körs, brandväggen eller NSG-konfigurationen för de virtuella datorerna kan blockera porten som används av hälsoavsökningen eller programmet. Använd följande steg för att avgöra om så är fallet:

  • Om den virtuella datorn har en brandvägg så kan den blockera förfrågningar via portarna som hälsoavsökningen och programmet använder. Kontrollera brandväggskonfigurationen på värden så att den tillåter trafik via portarna som hälsoavsökningen och programmet använder.

  • Kontrollera att nätverkssäkerhetsgruppen för den virtuella datorns nätverkskort tillåter ingående och utgående trafik via de portar som används. Leta efter en regel av typen Neka alla i nätverkssäkerhetsgruppen för den virtuella datorns nätverkskort som har högre prioritet än standardregeln.

Viktigt!

Du kan associera en nätverkssäkerhetsgrupp med ett undernät och de enskilda nätverkskorten för virtuella datorer i undernätet. Du kan ha konfigurerat nätverkssäkerhetsgruppen för ett undernät att tillåta trafik via en port. Om nätverkssäkerhetsgruppen för en virtuell dator däremot stänger samma port går det inte att skicka förfrågningar till den virtuella datorn.

Begränsningar i Load Balancer

Load Balancer körs i lager 4 i ISO-nätverksstacken och varken granskar eller på annat sätt ändrar innehållet i nätverkspaket. Du kan inte använda det till att implementera innehållsbaserad routning.

Alla klientförfrågningar hamnar hos en virtuell dator i serverdelspoolen. Klienterna ser inte Load Balancer. Om inga virtuella datorer är tillgängliga misslyckas klientbegäran. Klientprogram kan inte kommunicera med eller kontrollera status för Load Balancer eller någon av dess komponenter.

Om du behöver implementera belastningsutjämning baserat på innehållet i meddelanden kan du använda Azure Application Gateway. Du kan också konfigurera en proxyserver som ska hantera inkommande klientförfrågningar och skicka dem till specifika virtuella datorer.

Testa dina kunskaper

1.

Vad anger måttet genomsnittlig Status för hälsoavsökningen?

2.

Du övervakar måttet Genomsnittligt antal paket för en lastbalanserare. Genomsnittligt antal paket ökar plötsligt avsevärt trots att antalet klienter inte verkar ha ändrats. Vad är den troligaste orsaken?