Delen via

Beschikbaarheidsproblemen in Azure-opslagaccounts oplossen

  • Artikel

Dit artikel helpt u bij het onderzoeken van wijzigingen in beschikbaarheid (zoals het aantal mislukte aanvragen). Deze wijzigingen in beschikbaarheid kunnen vaak worden geïdentificeerd door metrische opslaggegevens in Azure Monitor te bewaken. Zie de volgende artikelen voor algemene informatie over het gebruik van metrische gegevens en logboeken in Azure Monitor:

Beschikbaarheid bewaken

U moet de beschikbaarheid van de opslagservices in uw opslagaccount bewaken door de waarde van de metrische beschikbaarheidsgegevens te controleren. De metrische waarde beschikbaarheid bevat een percentagewaarde. Dit wordt berekend door de totale waarde voor factureerbare aanvragen te nemen en te delen door het aantal toepasselijke aanvragen, inclusief aanvragen die onverwachte fouten hebben gegenereerd.

Elke waarde kleiner dan 100% geeft aan dat sommige opslagaanvragen mislukken. U kunt zien waarom ze mislukken door de dimensie ResponseType te controleren op fouttypen zoals ServerTimeoutError. U kunt verwachten dat de beschikbaarheid tijdelijk onder de 100% valt vanwege redenen zoals tijdelijke servertime-outs terwijl de service partities verplaatst naar betere load balance-aanvragen. De logica voor opnieuw proberen in uw clienttoepassing moet dergelijke onregelmatige voorwaarden verwerken. De metrische gegevens over beschikbaarheid zijn alleen beschikbaar voor perioden wanneer transacties ook op het account plaatsvinden.

U kunt functies in Azure Monitor gebruiken om u te waarschuwen als beschikbaarheid voor een service lager is dan een drempelwaarde die u opgeeft.

Metrische gegevens geven een toename van beperkingsfouten weer

Beperkingsfouten treden op wanneer u de schaalbaarheidsdoelen van een opslagservice overschrijdt. De opslagservice beperkt zich om ervoor te zorgen dat geen enkele client of tenant de service ten koste van anderen kan gebruiken. Zie schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts voor meer informatie over schaalbaarheidsdoelen voor opslagaccounts en prestatiedoelen voor partities binnen opslagaccounts.

Als de waarde ClientThrottlingError of ServerBusyError van de dimensie ResponseType een toename toont van het percentage aanvragen dat mislukt met een beperkingsfout, moet u een van de twee scenario's onderzoeken:

  • Tijdelijke toename in PercentThrottlingError
  • Permanente toename in percentthrottlingError-fout

Een toename van beperkingsfouten treedt vaak op op hetzelfde moment als een toename van het aantal opslagaanvragen of wanneer u de toepassing in eerste instantie laadt. Dit kan zich ook in de client voordoen als HTTP-statusberichten van de HTTP-status '503 Server Bezet' of 'Time-out van 500 bewerkingen' voor bewerkingen.

Tijdelijke toename van beperkingsfouten

Als u pieken ziet in beperkingsfouten die overeenkomen met perioden met hoge activiteit voor de toepassing, implementeert u een exponentiële (niet lineaire) back-offstrategie voor nieuwe pogingen in uw client. Back-off-nieuwe pogingen verminderen de onmiddellijke belasting van de partitie en helpen uw toepassing pieken in het verkeer op te vlakken. Zie de eigenschap RetryOptions.MaxRetries voor meer informatie over het implementeren van beleid voor opnieuw proberen met behulp van de Opslagclientbibliotheek.

Notitie

Mogelijk ziet u ook pieken in beperkingsfouten die niet samenvallen met perioden van hoge activiteit voor de toepassing. De meest waarschijnlijke oorzaak is dat de opslagservice partities verplaatst om de taakverdeling te verbeteren.

Permanente toename van beperkingsfouten

Als u een consistent hoge waarde ziet voor beperkingsfouten na een permanente toename van uw transactievolumes of wanneer u de eerste belastingstests uitvoert op uw toepassing, moet u evalueren hoe uw toepassing opslagpartities gebruikt en of deze de schaalbaarheidsdoelen voor een opslagaccount nadert. Als u bijvoorbeeld bandbreedtebeperkingsfouten ziet in een wachtrij (die telt als één partitie), kunt u overwegen om extra wachtrijen te gebruiken om de transacties over meerdere partities te verdelen. Als u bandbreedtebeperkingsfouten in een tabel ziet, kunt u overwegen een ander partitioneringsschema te gebruiken om uw transacties over meerdere partities te verdelen met behulp van een breder scala aan partitiesleutelwaarden. Een veelvoorkomende oorzaak van dit probleem is het antipatroon voor vooraf/toevoegen, waarbij u de datum als partitiesleutel selecteert en vervolgens alle gegevens op een bepaalde dag naar één partitie worden geschreven (onder belasting kan dit leiden tot een knelpunt voor schrijven). Overweeg een ander partitioneringsontwerp of evalueer of het gebruik van blobopslag een betere oplossing kan zijn. Controleer ook of er beperkingen optreden vanwege pieken in uw verkeer en onderzoek manieren om uw patroon van aanvragen te vereffenen.

Als u uw transacties over meerdere partities distribueert, moet u nog steeds rekening houden met de schaalbaarheidslimieten die zijn ingesteld voor het opslagaccount. Als u bijvoorbeeld 10 wachtrijen hebt gebruikt, wordt elke verwerking van het maximum van 20.000 1 KB-berichten per seconde bereikt, de totale limiet van 20.000 berichten per seconde voor het opslagaccount. Als u meer dan 20.000 entiteiten per seconde moet verwerken, kunt u overwegen meerdere opslagaccounts te gebruiken. Houd er ook rekening mee dat de grootte van uw aanvragen en entiteiten van invloed is wanneer de opslagservice uw clients beperkt. Als u grotere aanvragen en entiteiten hebt, wordt u mogelijk eerder beperkt.

Inefficiënt queryontwerp kan er ook toe leiden dat u de schaalbaarheidslimieten voor tabelpartities bereikt. Een query met een filter dat bijvoorbeeld slechts één procent van de entiteiten in een partitie selecteert, maar dat alle entiteiten in een partitie scant, moet toegang krijgen tot elke entiteit. Elke entiteit die wordt gelezen, telt mee voor het totale aantal transacties in die partitie. Daarom kunt u eenvoudig de schaalbaarheidsdoelen bereiken.

Notitie

Uw prestatietests moeten inefficiënte queryontwerpen in uw toepassing onthullen.

Metrische gegevens geven een toename van time-outfouten aan

Time-outfouten treden op wanneer de dimensie ResponseType gelijk is aan ServerTimeoutError of ClientTimeout.

Uw metrische gegevens tonen een toename van time-outfouten voor een van uw opslagservices. Tegelijkertijd ontvangt de client een groot aantal HTTP-statusberichten van '500 Bewerkingstime-out' van opslagbewerkingen.

Notitie

Mogelijk ziet u tijdelijk time-outfouten wanneer de load balancer van de opslagservice aanvragen verdeelt door een partitie naar een nieuwe server te verplaatsen.

De time-outs van de server (ServerTimeOutError) worden veroorzaakt door een fout op de server. De time-outs van de client (ClientTimeout) vinden plaats omdat een bewerking op de server de time-out heeft overschreden die is opgegeven door de client. Een client die de Opslagclientbibliotheek gebruikt, kan bijvoorbeeld een time-out voor een bewerking instellen.

Servertime-outs geven een probleem aan met de opslagservice waarvoor nader onderzoek is vereist. U kunt metrische gegevens gebruiken om te zien of u de schaalbaarheidslimieten voor de service bereikt en om pieken in het verkeer te identificeren die dit probleem kunnen veroorzaken. Als het probleem af en toe optreedt, kan dit worden veroorzaakt door taakverdelingsactiviteit in de service. Als het probleem permanent is en niet wordt veroorzaakt door uw toepassing die de schaalbaarheidslimieten van de service bereikt, moet u een ondersteuningsprobleem veroorzaken. Voor clienttime-outs moet u bepalen of de time-out is ingesteld op een geschikte waarde in de client en de time-outwaarde die is ingesteld in de client of onderzoeken hoe u de prestaties van de bewerkingen in de opslagservice kunt verbeteren, bijvoorbeeld door uw tabelquery's te optimaliseren of de grootte van uw berichten te verkleinen.

Metrische gegevens geven een toename van netwerkfouten weer

Netwerkfouten treden op wanneer de dimensie ResponseType gelijk is aan NetworkError. Deze treden op wanneer een opslagservice een netwerkfout detecteert wanneer de client een opslagaanvraag indient.

De meest voorkomende oorzaak van deze fout is dat de verbinding met een client wordt verbroken voordat een time-out verloopt in de opslagservice. Onderzoek de code in uw client om te begrijpen waarom en wanneer de client de verbinding met de opslagservice verbreekt. U kunt ook hulpprogramma's voor netwerkanalyse van derden gebruiken om problemen met de netwerkverbinding van de client te onderzoeken.

Zie ook

Contact met ons opnemen voor ondersteuning

Als u vragen hebt of hulp nodig hebt, maakt u een ondersteuningsaanvraag of stelt u ondersteuning voor de Azure-community. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.