Felsöka problem med resurshälsa och inkommande tillgänglighet

  • Artikel

Den här artikeln är en guide för att undersöka problem som påverkar tillgängligheten för lastbalanserarens IP-adress och serverdelsresurser.

Resource Health Check (RHC) för lastbalanseraren används för att fastställa hälsotillståndet för lastbalanseraren. Den analyserar måttet för datasökvägstillgänglighet under ett intervall på 2 minuter för att avgöra om slutpunkterna för belastningsutjämning, klientdelens IP- och klientdelsportar med belastningsutjämningsregler är tillgängliga.

Tabellen nedan beskriver RHC-logiken som används för att fastställa hälsotillståndet för lastbalanseraren.

Status för resurshälsa Beskrivning
Tillgängligt Din standardresurs för lastbalanserare är felfri och tillgänglig.
Degraderad Din standardlastbalanserare har plattforms- eller användarinitierade händelser som påverkar prestanda. Datapath-tillgänglighetsmåttet rapporterades som mindre än 90 % men större än 25 % hälsa i minst två minuter. Du upplever måttlig till svår prestandaförsämring.
Inte tillgänglig Standardresursen för lastbalanseraren är inte felfri. Datapath-tillgänglighetsmåttet rapporterade mindre än 25 % hälsa i minst två minuter. Du upplever betydande prestandaförsämring eller brist på tillgänglighet för inkommande anslutningar. Det kan finnas användar- eller plattformshändelser som orsakar otillgänglighet.
Okänt Resursens hälsostatus för standardresursen för lastbalanseraren har inte uppdaterats eller tagit emot tillgänglighetsinformation för datasökvägen under de senaste 10 minuterna. Det här tillståndet är tillfälligt och återspeglar korrekt status så snart data tas emot.

Om de mått vi använder

De två mått som ska användas är Tillgänglighet för datasökväg och Status för hälsoavsökning och det är viktigt att förstå deras innebörd för att härleda korrekta insikter.

Tillgänglighet för databana

Tillgänglighetsmåttet för datasökvägen genereras av en TCP-ping var 25:e sekund på alla klientdelsportar som har konfigurerat belastningsutjämning och inkommande NAT-regler. Den här TCP-pingen dirigeras till någon av de felfria (avsökningsbaserade) serverdelsinstanserna. Om tjänsten får ett svar på pingen är det ett lyckat svar och summan av måttet itereras en gång. Om det inte finns något svar sker ingen iteration. Antalet mått är 1/100 av de totala TCP-pingarna per exempelperiod. Därför vill vi ta hänsyn till medelvärdet, vilket är medelvärdet av summa/antal för tidsperioden. Data visar sökvägens tillgänglighetsmått aggregerat efter genomsnitt, vilket ger oss en procentuell framgångsgrad för TCP-pingar på din klientdels-IP:port för var och en av dina belastningsutjämnings- och inkommande NAT-regler.

Status för hälsoavsökning

Statusmåttet för hälsoavsökning genereras av en ping för protokollet som definierats i hälsoavsökningen. Den här pingen skickas till varje instans i serverdelspoolen och på den port som definierats i hälsoavsökningen. För HTTP- och HTTPS-avsökningar kräver en lyckad ping ett HTTP 200 OK-svar, medan med TCP-avsökningar anses alla svar vara lyckade. Efterföljande lyckade eller misslyckade avsökningar avgör hälsotillståndet för serverdelsinstansen och om den tilldelade serverdelspoolen kan ta emot trafik. På samma sätt som tillgängligheten för datasökvägar använder vi den genomsnittliga aggregeringen, vilket anger de genomsnittliga lyckade/totala pingarna under samplingsintervallet. Det här statusvärdet för hälsoavsökningen anger serverdelshälsan isolerat från lastbalanseraren genom att avsöka dina serverdelsinstanser utan att skicka trafik via klientdelen.

Viktigt!

Status för hälsoavsökning samplas på en minut. Detta kan leda till mindre variationer i ett annars stabilt värde. Om det till exempel finns två serverdelsinstanser, en avsökt uppåt och en avsökning ned, kan hälsoavsökningstjänsten samla in 7 exempel för den felfria instansen och 6 för den felaktiga instansen. Detta leder till ett tidigare stabilt värde på 50 som visas som 46,15 under ett intervall på en minut.

Diagnostisera degraderade och otillgängliga lastbalanserare

Som beskrivs i artikeln om resurshälsa är en degraderad lastbalanserare en som visar mellan 25 % och 90 % datasökvägstillgänglighet. En otillgänglig lastbalanserare är en med mindre än 25 % tillgänglighet för datasökväg under en tvåminutersperiod. Samma steg kan vidtas för att undersöka det fel som visas i eventuella hälsoavsökningsstatus eller tillgänglighetsaviseringar för datasökväg som du har konfigurerat. Vi utforskar fallet där vi har kontrollerat resurshälsan och funnit att lastbalanseraren inte är tillgänglig med en datasökvägstillgänglighet på 0 % – tjänsten är nere.

Först går vi till den detaljerade måttvyn för vår informationssida för lastbalanserare i Azure-portalen. Få åtkomst till vyn från resurssidan för lastbalanseraren eller länken i meddelandet om resurshälsa. Sedan går vi till fliken Klientdels- och serverdelstillgänglighet och granskar ett trettio minuter långt fönster i tidsperioden då det försämrade eller otillgängliga tillståndet inträffade. Om vi ser att tillgängligheten för vår datasökväg är 0 %, vet vi att det finns ett problem som förhindrar trafik för alla våra belastningsutjämnings- och inkommande NAT-regler, och vi kan se hur länge problemet har pågått.

Nästa plats vi behöver titta på är vårt mått för hälsoavsökningsstatus för att avgöra om vår datasökväg inte är tillgänglig eftersom vi inte har några felfria serverdelsinstanser för att hantera trafik. Om vi har minst en felfri serverdelsinstans för alla våra regler för belastningsutjämning och inkommande trafik vet vi att det inte är vår konfiguration som gör att våra datasökvägar inte är tillgängliga. Det här scenariot anger ett Problem med Azure-plattformen. Även om plattformsproblem är sällsynta skickas en automatiserad avisering till vårt team för att snabbt lösa alla plattformsproblem.

Diagnostisera fel med hälsoavsökningar

Anta att vi kontrollerar statusen för vår hälsoavsökning och tar reda på att alla instanser visas som felaktiga. Den här sökningen förklarar varför vår datasökväg inte är tillgänglig eftersom trafiken inte har någonstans att ta vägen. Vi bör sedan gå igenom följande checklista för att utesluta vanliga konfigurationsfel:

  • Kontrollera processoranvändningen för dina resurser för att avgöra om de är under hög belastning.
  • Om du använder en HTTP- eller HTTPS-avsökning kontrollerar du om programmet är felfritt och responsivt.
    • Verifiera att programmet fungerar genom att direkt komma åt programmen via den privata IP-adressen eller den offentliga IP-adress på instansnivå som är associerad med din serverdelsinstans.
  • Granska de nätverkssäkerhetsgrupper som tillämpas på våra serverdelsresurser. Se till att det inte finns några regler med högre prioritet än AllowAzureLoadBalancerInBound som blockerar hälsoavsökningen.
    • Du kan göra detta genom att besöka nätverksinställningarna för dina virtuella datorer på serverdelen eller vm-skalningsuppsättningar.
    • Om du upptäcker att det här NSG-problemet är fallet flyttar du den befintliga regeln Tillåt eller skapar en ny regel med hög prioritet för att tillåta AzureLoadBalancer-trafik.
  • Kontrollera operativsystemet. Se till att dina virtuella datorer lyssnar på avsökningsporten och granska deras brandväggsregler för operativsystem för att säkerställa att de inte blockerar avsökningstrafiken från IP-adressen 168.63.129.16.
    • Du kan kontrollera lyssnarportar genom att köra netstat -a från en Windows-kommandotolk eller netstat -l från en Linux-terminal.
  • Kontrollera att du använder rätt protokoll. En avsökning som använder HTTP för att avsöka en port som lyssnar efter ett icke-HTTP-program misslyckas till exempel.
  • Azure Firewall ska inte placeras i serverdelspoolen med lastbalanserare. Se Integrera Azure Firewall med Azure Standard Load Balancer för korrekt integrering av Azure Firewall med lastbalanserare.

Om du har gått igenom den här checklistan och fortfarande hittar fel i hälsoavsökningen kan det finnas sällsynta plattformsproblem som påverkar avsökningstjänsten för dina instanser. I det här fallet har Azure ryggen och en automatiserad avisering skickas till vårt team för att snabbt lösa alla plattformsproblem.

Nästa steg