Beschikbaarheidsproblemen in Azure Storage-accounts oplossen

  • Artikel

Dit artikel helpt u bij het onderzoeken van wijzigingen in de 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 beschikbaarheidswaarde te bewaken. De metrische beschikbaarheidswaarde bevat een percentagewaarde. Deze wordt berekend door de totale waarde van factureerbare aanvragen te nemen en deze te delen door het aantal toepasselijke aanvragen, inclusief aanvragen die onverwachte fouten hebben gegenereerd.

Een waarde van minder dan 100% geeft aan dat sommige opslagaanvragen mislukken. U kunt zien waarom ze mislukken door de dimensie ResponseType te onderzoeken op fouttypen zoals ServerTimeoutError. U zou moeten verwachten dat de beschikbaarheid tijdelijk onder de 100% daalt om redenen zoals tijdelijke time-outs van de server terwijl de service partities verplaatst naar betere taakverdelingsaanvragen; de logica voor opnieuw proberen in uw clienttoepassing moet dergelijke onregelmatige voorwaarden verwerken.

U kunt functies in Azure Monitor gebruiken om u te waarschuwen als de beschikbaarheid voor een service onder een drempelwaarde komt die u opgeeft.

Metrische gegevens geven een toename van beperkingsfouten aan

Beperkingsfouten treden op wanneer u de schaalbaarheidsdoelen van een opslagservice overschrijdt. De opslagservice beperkt om ervoor te zorgen dat geen enkele client of tenant de service kan gebruiken ten koste van anderen. 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 van het percentage aanvragen laat zien dat mislukt met een beperkingsfout, moet u een van de twee scenario's onderzoeken:

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

Een toename van beperkingsfouten treedt vaak tegelijkertijd op als een toename van het aantal opslagaanvragen of wanneer u de belasting van uw toepassing in eerste instantie test. Dit kan zich in de client ook manifesteren als HTTP-statusberichten van opslagbewerkingen als '503 Server bezet' of '500 Bewerkingstime-out'.

Tijdelijke toename van beperkingsfouten

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

Opmerking

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 uw eerste belastingstests voor uw toepassing uitvoert, moet u evalueren hoe uw toepassing opslagpartities gebruikt en of deze de schaalbaarheidsdoelen voor een opslagaccount benadert. Als u bijvoorbeeld beperkingsfouten ziet in een wachtrij (die telt als één partitie), kunt u extra wachtrijen gebruiken om de transacties over meerdere partities te spreiden. Als u beperkingsfouten ziet in een tabel, kunt u overwegen om een ander partitioneringsschema te gebruiken om uw transacties over meerdere partities te spreiden met behulp van een breder bereik van partitiesleutelwaarden. Een veelvoorkomende oorzaak van dit probleem is het antipatroon voor prepend/toevoegen, waarbij u de datum als partitiesleutel selecteert en vervolgens alle gegevens op een bepaalde dag naar één partitie worden geschreven (bij belasting kan dit leiden tot een schrijfknelpunt). Overweeg een ander ontwerp voor partitionering of evalueer of het gebruik van blobopslag een betere oplossing is. Controleer ook of beperking optreedt als gevolg van pieken in uw verkeer en onderzoek manieren om het patroon van aanvragen te versoepelen.

Als u uw transacties over meerdere partities distribueert, moet u zich nog steeds bewust zijn van de schaalbaarheidslimieten die zijn ingesteld voor het opslagaccount. Als u bijvoorbeeld 10 wachtrijen hebt gebruikt, die elk maximaal 2000 1KB-berichten per seconde verwerken, hebt u de totale limiet van 20.000 berichten per seconde voor het opslagaccount bereikt. Als u meer dan 20.000 entiteiten per seconde wilt verwerken, kunt u overwegen om 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 voor zorgen dat u de schaalbaarheidslimieten voor tabelpartities bereikt. Een query met een filter die slechts één procent van de entiteiten in een partitie selecteert, maar die alle entiteiten in een partitie scant, moet bijvoorbeeld toegang hebben tot elke entiteit. Elke entiteit die wordt gelezen, telt mee voor het totale aantal transacties in die partitie. Daarom kunt u de schaalbaarheidsdoelen eenvoudig bereiken.

Opmerking

Uw prestatietests moeten inefficiënte queryontwerpen in uw toepassing aan het licht brengen.

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 volume van '500 operation time-out'-HTTP-statusberichten van opslagbewerkingen.

Opmerking

Er kunnen tijdelijk time-outfouten optreden wanneer de opslagservice de taakverdeling van aanvragen verkrijgt door een partitie naar een nieuwe server te verplaatsen.

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

Time-outs van de server duiden op een probleem met de opslagservice dat nader moet worden onderzocht. U kunt metrische gegevens gebruiken om te zien of u de schaalbaarheidslimieten voor de service bereikt en om eventuele 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 persistent is en niet wordt veroorzaakt doordat uw toepassing de schaalbaarheidslimieten van de service heeft bereikt, moet u een ondersteuningsprobleem melden. Voor clienttime-outs moet u beslissen of de time-out is ingesteld op een juiste waarde in de client en de time-outwaarde wijzigen 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 aan

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 de 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 netwerkanalysehulpprogramma's van derden gebruiken om netwerkverbindingsproblemen van de client te onderzoeken.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.