Delen via


Problemen met resourcestatus en binnenkomende beschikbaarheid oplossen

Dit artikel kan u helpen bij het onderzoeken van problemen die van invloed zijn op de beschikbaarheid van front-end-IP- en back-endbronnen van uw load balancer.

U kunt de resourcestatusfunctie in Azure Load Balancer gebruiken om de status van uw load balancer te bepalen. Het analyseert de metrische gegevens over beschikbaarheid van gegevenspaden om te bepalen of de taakverdelingseindpunten, het front-end-IP-adres en de front-endpoortcombinaties met taakverdelingsregels beschikbaar zijn.

Notitie

Basic Load Balancer biedt geen ondersteuning voor de resourcestatusfunctie.

In de volgende tabel wordt de logica beschreven voor het bepalen van de status van uw load balancer.

Integriteitsstatus van de resource Beschrijving
beschikbaar Uw load balancer-resource is in orde en beschikbaar.
Verminderd beschikbaar Uw load balancer heeft platformgebeurtenissen of door de gebruiker geïnitieerde gebeurtenissen die van invloed zijn op de prestaties. De metrische gegevens over beschikbaarheid van gegevenspaden hebben ten minste twee minuten een status van minder dan 90% gerapporteerd, maar groter dan 25%. Mogelijk ondervindt u matige tot ernstige prestatievermindering.
Niet beschikbaar Uw 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. Mogelijk ondervindt u aanzienlijke prestatievermindering of een gebrek aan beschikbaarheid voor binnenkomende connectiviteit. Gebruikers- of platform gebeurtenissen kunnen leiden tot onbeschikbaarheid.
Onbekend De status van de resource voor uw load balancer-resource heeft in de afgelopen 10 minuten geen beschikbaarheidsinformatie over gegevenspaden bijgewerkt of ontvangen. Deze status kan tijdelijk zijn of uw load balancer biedt mogelijk geen ondersteuning voor de resourcestatusfunctie.

De beschikbaarheid van uw load balancer bewaken

De twee metrische gegevens die door Azure Load Balancer worden gebruikt om de status van de resource te controleren, zijn beschikbaarheid van gegevenspaden en statustest. Het is belangrijk om inzicht te krijgen in hun betekenis om juiste inzichten af te leiden.

Beschikbaarheid van gegevenspad

Een TCP-ping genereert elke 25 seconden de metrische gegevens over beschikbaarheid van gegevenspaden op alle front-endpoorten waar u taakverdelingsregels hebt geconfigureerd. Deze TCP-ping wordt doorgestuurd naar een van de back-endinstanties die in orde zijn (getest). De metrische waarde is een geaggregeerd percentage slagingspercentages van TCP-pings op elke combinatie van front-end-IP/poort voor elk van uw taakverdelingsregels gedurende een voorbeeldperiode.

Status van de statustest

Met een ping van het protocol dat in de statustest is gedefinieerd, wordt de meetwaarde Status van de statustest gegenereerd. 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. Bij TCP-tests wordt elk antwoord beschouwd als geslaagd.

Azure Load Balancer bepaalt de status van elk back-endexemplaren wanneer de test het aantal opeenvolgende geslaagde of mislukte pogingen bereikt dat u hebt geconfigureerd voor de eigenschap testdrempel. De status van elk back-endexemplaren bepaalt of het back-endexemplaren verkeer mogen ontvangen.

Net als de metrische gegevens over beschikbaarheid van gegevenspaden worden met de metrische statusstatus van de statustest het gemiddelde geslaagde en totale pings tijdens het steekproefinterval geaggregeerd. De waarde status 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 gesampleerd. Deze steekproef kan leiden tot kleine schommelingen in een anders stabiele waarde.

Denk bijvoorbeeld aan actieve/passieve scenario's waarbij er twee back-endexemplaren zijn, één die omhoog en één test omlaag is uitgevoerd. De statustestservice kan zeven voorbeelden vastleggen voor het gezonde exemplaar en zes voor het beschadigde exemplaar. Deze situatie 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 dit artikel over resourcestatus, toont een gedegradeerde load balancer tussen 25% en 90% voor beschikbaarheid van gegevenspaden. Een niet-beschikbare load balancer is een met minder dan 25% voor beschikbaarheid van gegevenspaden gedurende een periode van twee minuten.

U kunt dezelfde stappen uitvoeren om de fout te onderzoeken die wordt weergegeven in waarschuwingen voor statusteststatus of beschikbaarheid van gegevenspaden die u hebt geconfigureerd. De volgende stappen verkennen wat u moet doen als u de status van uw resource controleert en uw load balancer vindt dat deze niet beschikbaar is met een beschikbaarheidswaarde voor gegevenspaden van 0%. Uw service is niet beschikbaar.

  1. Ga in Azure Portal naar de gedetailleerde metrische gegevensweergave van de pagina voor uw load balancer-inzichten. Open de weergave vanaf de pagina voor uw load balancer-resource of via de koppeling in uw resourcestatusbericht.

  2. Ga naar het tabblad voor front-end- en back-endbeschikbaarheid en bekijk een periode van 30 minuten van de periode waarin de gedegradeerde of niet-beschikbare status heeft plaatsgevonden. Als de beschikbaarheidswaarde van het gegevenspad 0% is, weet u dat er iets verkeer voorkomt voor al uw taakverdelingsregels. U kunt ook zien hoe lang dit probleem heeft geduurd.

  3. Controleer de meetwaarde status van uw statustest om te bepalen of uw gegevenspad niet beschikbaar is, omdat u geen goede back-endinstanties hebt om verkeer te verwerken. Als u ten minste één back-endinstantie in orde hebt voor al uw taakverdelings- en inkomende regels, weet u dat uw configuratie niet is wat ervoor zorgt dat uw gegevenspaden niet beschikbaar zijn. In dit scenario wordt een probleem met het Azure-platform aangegeven. Hoewel platformproblemen zeldzaam zijn, activeren ze een geautomatiseerde waarschuwing voor ons team voor snelle oplossing.

Statustestfouten diagnosticeren

Als uw metrische statustest aangeeft dat uw back-endinstanties niet in orde zijn, raden we u aan de volgende controlelijst te gebruiken om veelvoorkomende configuratiefouten uit te sluiten:

  • Controleer het CPU-gebruik voor uw resources om te bepalen of ze onder hoge belasting staan.

    U kunt dit controleren door het cpu-percentage van de resource weer te geven via de pagina Metrische gegevens . Zie Problemen met hoog CPU-gebruik voor virtuele Azure Windows-machines oplossen voor meer informatie.

  • Als u een HTTP- of HTTPS-test gebruikt, controleert u of de toepassing in orde is en reageert.

    Controleer of uw toepassing functioneel is door deze rechtstreeks te openen via het privé-IP-adres of het openbare IP-adres op exemplaarniveau dat is gekoppeld aan uw back-endinstantie.

  • Controleer de netwerkbeveiligingsgroepen (NSG's) die zijn toegepast op uw back-endbronnen. Zorg ervoor dat geen regels een hogere prioriteit hebben dan AllowAzureLoadBalancerInBound die de statustest blokkeren.

    U kunt deze taak uitvoeren door naar de netwerkinstellingen van uw back-end-VM's of virtuele-machineschaalsets te gaan. Als u merkt dat dit NSG-probleem het geval is, verplaatst u de bestaande Allow regel of maakt u een nieuwe regel met hoge prioriteit om Verkeer van Azure Load Balancer toe te staan.

  • Controleer uw besturingssysteem. Zorg ervoor dat uw VM's luisteren op de testpoort. Controleer ook de firewallregels van het besturingssysteem voor de VM's 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 gebruikmaakt van HTTP om een poort te testen die luistert naar een niet-HTTP-toepassing, mislukt bijvoorbeeld.

  • Plaats Azure Firewall niet in de back-endpool van load balancers. Zie Azure Firewall integreren met Azure Standard Load Balancer voor meer informatie.