Delen via

Problemen met resourcestatus en binnenkomende beschikbaarheid oplossen

  • Artikel

Dit artikel is een handleiding voor het onderzoeken van problemen die van invloed zijn op de beschikbaarheid van front-end-IP- en back-endbronnen van uw load balancer.

De Resource Health Check (RHC) voor de Load Balancer wordt gebruikt om de status van uw load balancer te bepalen. Het analyseert de metrische gegevens over beschikbaarheid van gegevenspaden gedurende een interval van 2 minuten om te bepalen of de eindpunten voor taakverdeling, het front-end-IP-adres en de front-endpoorten combinaties met taakverdelingsregels beschikbaar zijn.

Opmerking: RHC wordt niet ondersteund voor Basic SKU Load Balancer

In de onderstaande tabel wordt de RHC-logica beschreven die wordt gebruikt om de status van uw load balancer te bepalen.

Integriteitsstatus van de resource Beschrijving
Beschikbaar Uw standaard load balancer-resource is in orde en beschikbaar.
Verminderd beschikbaar Uw standaard load balancer heeft door het platform of de gebruiker geïnitieerde gebeurtenissen die van invloed zijn op de prestaties. De metrische gegevens over beschikbaarheid van gegevenspaden gerapporteerd als minder dan 90%, maar langer dan 25% gedurende ten minste twee minuten. U ondervindt matige tot ernstige prestatievermindering.
Niet beschikbaar Uw standard load balancer-resource is niet in orde. De metrische gegevens over beschikbaarheid van gegevenspaden hebben ten minste twee minuten een status van minder dan 25% gerapporteerd. U ondervindt aanzienlijke prestatievermindering of een gebrek aan beschikbaarheid voor binnenkomende connectiviteit. Er kunnen gebruikers- of platform-gebeurtenissen zijn die onbeschikbaarheid veroorzaken.
Onbekend De status van de resource voor uw standaard load balancer-resource heeft in de afgelopen tien minuten geen beschikbaarheidsinformatie over gegevenspaden bijgewerkt of ontvangen. Deze status is tijdelijk en geeft de juiste status weer zodra gegevens worden ontvangen.

Over de metrische gegevens die we gebruiken

De twee metrische gegevens die moeten worden gebruikt, zijn beschikbaarheid van gegevenspaden en statustest en het is belangrijk om inzicht te krijgen in hun betekenis om de juiste inzichten af te leiden.

Gegevenspadbeschikbaarheid

De metrische gegevens over beschikbaarheid van gegevenspaden worden elke 25 seconden gegenereerd door een TCP-ping op alle front-endpoorten waarvoor taakverdeling en binnenkomende NAT-regels zijn geconfigureerd. Deze TCP-ping wordt doorgestuurd naar een van de back-endinstanties die in orde zijn (getest). Als de service een reactie op de ping ontvangt, is het een geslaagd antwoord en wordt de som van de metrische gegevens eenmaal cursoreerd. Als er geen antwoord is, gebeurt er geen herhaling. Het aantal van deze metrische gegevens is 1/100 van de totale TCP-pings per voorbeeldperiode. Daarom willen we rekening houden met het gemiddelde, wat het gemiddelde is van de som/het aantal voor de periode. De gegevens tonen de metrische gegevens voor de beschikbaarheid van paden die gemiddeld zijn geaggregeerd, geven ons dus een percentage slagingspercentage voor TCP-pings op uw front-end-IP:port voor elk van uw taakverdelings- en inkomende NAT-regels.

Status van statustest

De metrische status van de statustest wordt gegenereerd door een ping van het protocol dat is gedefinieerd in de statustest. Deze ping wordt verzonden naar elk exemplaar in de back-endpool en op de poort die is gedefinieerd in de statustest. Voor HTTP- en HTTPS-tests is een geslaagde ping een HTTP 200 OK-antwoord vereist, terwijl bij TCP-tests alle reacties als geslaagd worden beschouwd. De opeenvolgende geslaagde of mislukte pogingen van elke test bepalen de status van het back-endexemplaren en of de toegewezen back-endpool verkeer kan ontvangen. Net als bij de beschikbaarheid van gegevenspaden gebruiken we de gemiddelde aggregatie, wat aangeeft dat het gemiddelde geslaagde/totale pings tijdens het steekproefinterval zijn. Deze statuswaarde van de statustest geeft de back-endstatus in isolatie van uw load balancer aan door uw back-endexemplaren te doorzoeken zonder verkeer via de front-end te verzenden.

Belangrijk

De status van de statustest wordt op basis van één minuut gecontroleerd. Dit kan leiden tot kleine schommelingen in een anders stabiele waarde. Als er bijvoorbeeld twee back-endexemplaren zijn, één test omhoog en één uitgevoerd, kan de statustestservice 7 voorbeelden vastleggen voor het exemplaar in orde en 6 voor het beschadigde exemplaar. Dit leidt tot een eerder stabiele waarde van 50 die wordt weergegeven als 46,15 voor een interval van één minuut.

Problemen met gedegradeerde en niet-beschikbare load balancers vaststellen

Zoals beschreven in het artikel over resourcestatus, is een gedegradeerde load balancer een load balancer die de beschikbaarheid van gegevenspaden tussen 25% en 90% laat zien. Een niet-beschikbare load balancer is een met minder dan 25% beschikbaarheid van gegevenspaden gedurende een periode van twee minuten. Dezelfde stappen kunnen worden uitgevoerd om de fout te onderzoeken die wordt weergegeven in waarschuwingen voor statustest of beschikbaarheid van gegevenspaden die u hebt geconfigureerd. We verkennen de situatie waarin we onze resourcestatus hebben gecontroleerd en hebben vastgesteld dat onze load balancer niet beschikbaar is met een beschikbaarheid van een gegevenspad van 0%. Onze service is niet beschikbaar.

Eerst gaan we naar de gedetailleerde metrische gegevensweergave van onze pagina met load balancer-inzichten in Azure Portal. Open de weergave op de resourcepagina van uw load balancer of de koppeling in uw resourcestatusbericht. Vervolgens gaan we naar het tabblad Front-end- en back-endbeschikbaarheid en bekijken we een periode van dertig minuten van de periode waarin de gedegradeerde of niet-beschikbare status is opgetreden. Als we zien dat de beschikbaarheid van ons gegevenspad 0% is, weten we dat er een probleem is waardoor verkeer voor al onze taakverdelings- en inkomende NAT-regels wordt voorkomen. We kunnen zien hoe lang dit probleem heeft geduurd.

De volgende plaats waar we moeten kijken, is de metrische status van de statustest om te bepalen of ons gegevenspad niet beschikbaar is, omdat er geen back-endinstanties in orde zijn om verkeer te verwerken. Als we ten minste één goed back-endexemplaren hebben voor al onze regels voor taakverdeling en inkomend verkeer, weten we dat het niet onze configuratie is waardoor onze gegevenspaden niet beschikbaar zijn. In dit scenario wordt een probleem met het Azure-platform aangegeven. Hoewel platformproblemen zeldzaam zijn, wordt er een geautomatiseerde waarschuwing naar ons team verzonden om snel alle platformproblemen op te lossen.

Statustestfouten diagnosticeren

Stel dat we de status van de statustest controleren en erachter komen dat alle exemplaren als beschadigd worden weergegeven. In deze bevindingen wordt uitgelegd waarom ons gegevenspad niet beschikbaar is omdat verkeer nergens heen kan. We moeten vervolgens de volgende controlelijst doorlopen om veelvoorkomende configuratiefouten uit te sluiten:

  • Controleer het CPU-gebruik voor uw resources om te bepalen of ze onder hoge belasting vallen.
  • Als u een HTTP- of HTTPS-test gebruikt, controleert u of de toepassing in orde is en reageert.
    • Valideer of de toepassing functioneel is door rechtstreeks toegang te krijgen tot de toepassingen via het privé-IP-adres of het openbare IP-adres op exemplaarniveau dat is gekoppeld aan uw back-endinstantie.
  • Controleer de netwerkbeveiligingsgroepen die zijn toegepast op onze back-endbronnen. Zorg ervoor dat er geen regels met een hogere prioriteit zijn dan AllowAzureLoadBalancerInBound die de statustest blokkeert.
    • U kunt dit doen door naar de netwerkinstellingen van uw back-end-VM's of virtuele-machineschaalsets te gaan.
    • Als dit probleem met de NSG het geval is, verplaatst u de bestaande regel Toestaan of maakt u een nieuwe regel met hoge prioriteit om Verkeer van AzureLoadBalancer toe te staan.
  • Controleer uw besturingssysteem. Controleer of uw VM's luisteren op de testpoort en controleer de firewallregels van het besturingssysteem om ervoor te zorgen dat het testverkeer dat afkomstig is van het IP-adres 168.63.129.16niet wordt geblokkeerd.
    • U kunt luisterende poorten controleren door uit te voeren netstat -a vanaf een Windows-opdrachtprompt of netstat -l vanuit een Linux-terminal.
  • Zorg ervoor dat u het juiste protocol gebruikt. Een test die HTTP gebruikt om een poort te testen die luistert naar een niet-HTTP-toepassing, mislukt bijvoorbeeld.
  • Azure Firewall mag niet worden geplaatst in de back-endpool van load balancers. Zie Azure Firewall integreren met Azure Standard Load Balancer om Azure Firewall correct te integreren met load balancer.

Als u deze controlelijst hebt doorlopen en nog steeds mislukte statustests vindt, kunnen er zeldzame platformproblemen zijn die van invloed zijn op de testservice voor uw exemplaren. In dit geval heeft Azure uw rug en wordt er een geautomatiseerde waarschuwing naar ons team verzonden om snel alle platformproblemen op te lossen.

Volgende stappen