Actieve partities in Azure Blob Storage: detectie, bewaking en mitigatie

Azure Blob Storage verdeelt data over partities om schaalbare prestaties te leveren. Wanneer het verkeer zich concentreert op één partitie, kan die partitie een bottleneck worden, een toestand die bekend staat als een hot partition. Dit artikel legt uit wat hot partitions zijn, hoe je ze herkent via Azure Monitor-metrics en resource logs, en welke stappen je kunt nemen om de belasting gelijkmatiger te verdelen en throttling-fouten te verminderen.

Begrijp zwaarbelaste partities

Azure Blob Storage verdeelt data automatisch over partities om prestaties en doorvoer te schalen. Wanneer een enkele partitie aanzienlijk meer verkeer ontvangt dan andere partities, wordt deze een hot partitie. Een hot partition ontstaat wanneer een groot aantal lees-, schrijf- of updateverzoeken naar dezelfde partitie wordt gestuurd, waardoor het vermogen van de service om de werklast effectief te verdelen wordt beperkt. Als gevolg hiervan ervaren verzoeken verhoogde latentie, throttling en timeout-fouten totdat de werklast wordt herverdeeld of het toegangspatroon is geoptimaliseerd. Partitionerings- of naamgevingsschema's die het verkeer concentreren op een kleine subset van data in plaats van verzoeken over meerdere partities te verspreiden, veroorzaken vaak hot partitions.

Symptomen en impact van hete scheidingswanden

Wanneer een opslagpartitie heet wordt, kan deze verzoeken niet meer zo efficiënt verwerken. Naarmate de partitie haar schaalbaarheidslimieten nadert, begint Azure Storage verzoeken te beperken om de dienst te beschermen en de betrouwbaarheid voor andere workloads te behouden. Clientapplicaties ervaren verhoogde latentie, verminderde doorvoersnelheid en tijdelijke verzoekfouten.

Veelvoorkomende symptomen van een oververhitte partitie zijn onder andere:

• HTTP 503 (Server Busy) antwoorden die aangeven dat de partitie tijdelijk geen verdere verzoeken kan verwerken.
• HTTP 500 (Operation Timeout)-reacties wanneer verzoeken te lang duren voordat ze zijn voltooid omdat de partitie zwaar wordt belast.
• Verhoogde verzoeklatentie, zelfs bij verzoeken die uiteindelijk slagen.
• Automatische nieuwe pogingen van clients, wat het verkeer verder kan doen toenemen en prestatieproblemen langer kan laten aanhouden als veel clients tegelijkertijd een nieuwe poging doen.
• Verminderde doorvoersnelheid, waarbij de applicatie minder bewerkingen per seconde verwerkt dan verwacht ondanks voldoende totale opslagcapaciteit.

Hot partities worden vaak veroorzaakt door toegangspatronen die het verkeer concentreren op één enkele partitie. Veelvoorkomende voorbeelden zijn sequentiële blob-namen, append-only workloads en partitiesleutelontwerpen die een onevenredig grote hoeveelheid verkeer naar één partitie sturen. Wanneer de werklast niet gelijkmatig verdeeld is, bereikt de getroffen partitie zijn limieten vóór de rest van het opslagaccount, wat een bottleneck creëert die de applicatieprestaties beïnvloedt.

Voor veel toepassingen is de eerste aanwijzing van een hot partition een combinatie van toenemende latency, toenemende herhaalpercentages en een groeiend aantal fouten van 503 of 500 tijdens periodes van hoge vraag.

Detecteer throttlingfouten door gebruik te maken van Azure Monitor-metrics en resource logs

Azure Storage beperkt verzoeken wanneer een werklast de schaalbaarheidsdoelen van een opslagaccount of partitie overschrijdt. Je ziet vaak throttling als HTTP 503 (Server Busy) of 500 (Operation Timeout) reacties. Azure Storage-clientbibliotheken proberen vaak automatisch throttled requests opnieuw, dus monitoring is essentieel om throttling te detecteren voordat het de applicatieprestaties significant beïnvloedt.

Gebruik Azure Monitor-metrics om throttlingfouten te identificeren

Om throttling te detecteren, analyseer je Azure Monitor-metrics voor een opslagaccount. De Transactions-metric , gecombineerd met de ResponseType-dimensie , biedt inzicht in de uitkomst van opslagverzoeken en helpt u om storingen gerelateerd aan throttling te identificeren.

Meetmethoden voor het identificeren van throttling

De volgende Azure Monitor-metrics zijn nuttig bij het onderzoeken van throttling:

Een veelvoorkomend patroon van throttling is een toename van de latentie, gepaard gaand met een toename van throttling-gerelateerde typen reacties en een afname van de beschikbaarheid.

Gebruik de ResponseType-dimensie om throttling te identificeren

De ResponseType-dimensie is het primaire hulpmiddel om throttling-condities in Azure Monitor-metrics te identificeren. Relevante waarden zijn onder andere:

Het volgen van deze waarden in de tijd kan je helpen om tijdelijke throttlingpieken en aanhoudende schaalbaarheidsproblemen te identificeren.

Gebruik afmetingen om de bron van de throttling te bepalen

Azure Monitor-metriekafmetingen kunnen helpen om de werklast te isoleren die verantwoordelijk is voor throttling:

Als throttling bijvoorbeeld vooral plaatsvindt bij PutBlob operaties, kan de werklast schrijfintensief zijn. Als een specifieke API-operatie verhoogde throttling-snelheden vertoont, kunnen optimalisatie-inspanningen zich richten op die operatie in plaats van op de hele applicatie.

Azure Monitor-resourcelogboeken analyseren

Hoewel metrics de aanwezigheid van throttling aantonen, bieden Azure Monitor-resourcelogs details op verzoekniveau die kunnen helpen bij het diagnosticeren van de oorzaak. Resourcelogs registreren zowel succesvolle als mislukte verzoeken, waaronder throttling, timeout, autorisatie en netwerkgerelateerde fouten.

Voor Azure Blob Storage zijn records beschikbaar in de StorageBlobLogs-tabel nadat resourcelogs naar een Log Analytics-werkruimte zijn gestuurd.

Raadpleeg resourcelogs voor throttling-events

Voordat je deze queries uitvoert, zorg ervoor dat resourcelogs naar een Log Analytics-werkruimte worden gestuurd.

Gebruik Kusto Query Language (KQL) om verzoeken te identificeren die veelvoorkomende statuscodes met betrekking tot throttling teruggeven:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

Breid deze query uit door resultaten te groeperen op bewerking, authenticatietype, aanroeper IP-adres of applicatieidentiteit om de werklastgenererende gesmoorde verzoeken te identificeren. Resourcelogs zijn vooral nuttig om te bepalen of throttling geconcentreerd is binnen een specifieke toepassing, operatie of tijdsperiode.

Waarschuwingscondities voor gaskoppeling

Azure Monitor-waarschuwingen maken voor:

• Aanhoudende incidenten van ServerBusyError-transacties .
• Toenames in throttling-gerelateerde ResponseType-waarden.
• Dalingen in de beschikbaarheidsmetriek tot onder een aanvaardbare drempel.
• Toename in latentie die samenhangt met throttling-gebeurtenissen.
• Plotselinge toename van het aantal verzoeken die de schaalbaarheidslimieten van opslag naderen.

Aanbevolen workflow voor bewaking

1. Monitor de transactiemaatstaf en verdeel de resultaten op ResponseType.
2. Let op toename in responstypen gerelateerd aan throttling, zoals ServerBusyError en ClientThrottlingError.
3. Gebruik de ApiName-dimensie om de getroffen bewerkingen te identificeren.
4. Breng throttlinggebeurtenissen in verband met wijzigingen in Beschikbaarheid, Succesvolle E2E-latentie en Succesvolle serverlatentie.
5. Gebruik Azure Monitor resource logs om te bepalen welke verzoeken, operaties of applicaties beperkt verkeer genereren.
6. Configureer waarschuwingen zodat throttlingproblemen worden gedetecteerd voordat ze van invloed zijn op gebruikers.

Door Azure Monitor-metrics, afmetingen en resource logs te combineren, kun je snel throttling-condities detecteren, de bron van overmatige vraag identificeren en corrigerende maatregelen nemen voordat de applicatieprestaties verslechteren.

Hot partitions beperken

Om hot partitions te voorkomen, verdeel verzoeken gelijkmatig over partities en zorg ervoor dat applicaties passend reageren wanneer throttling plaatsvindt.

Gebruik efficiënte partitionerings- en naamgevingsschema's

Ontwerp partitiesleutels, blobnamen en andere identificaties zodat verzoeken over meerdere partities worden verdeeld. Vermijd sequentiële of alleen toevoegingspatronen die de meeste verzoeken naar dezelfde partitie sturen. Zie Optimaliseer blob-partities en naamgevingsschema's.

Gebruik exponentiële backoff voor herpogingen

Als aanvragen worden beperkt en de foutcodes 503 (Server Busy) of 500 (Operation Timeout) retourneren, probeer de aanvragen dan opnieuw met behulp van een exponentiële back-offstrategie. Deze aanpak vermindert de druk op de getroffen partitie en geeft Azure Storage tijd om de belasting te herbalanceren of te herstellen van tijdelijke pieken in vraag.

Het gedrag van opnieuw proberen met exponentiële wachttijden is vooral relevant voor maatwerktoepassingen die toegang hebben tot Azure Storage met behulp van Azure Storage-clientbibliotheken, SDK's of REST API's. Veel Microsoft-services, managed applications en externe clients implementeren al passende herkansingslogica, dus je hoeft misschien niets extra's te configureren. Als je een aangepaste applicatie ontwikkelt, zorg er dan voor dat retry-beleidsregels zijn ingeschakeld en geconfigureerd volgens de best practices van Azure Storage. Bekijk een van deze berichten:

• Implementeer een herprobeerbeleid voor .NET
• Voer een herkansingsbeleid uit voor Java
• Implementeer een herhalingsbeleid voor JavaScript
• Implementeer een herprobeerbeleid voor Python
• Voer een herkansingsbeleid uit voor Go

Vermijd plotselinge pieken in het aanvraagvolume

Bij het introduceren van een nieuwe werklast, het uitvoeren van prestatietests of het verwerken van grote hoeveelheden data, verhoog je de aanvraagpercentages geleidelijk in plaats van direct piekverkeer te genereren. Azure Storage balanceert partities automatisch als de vraag verandert, maar plotselinge verkeerspieken kunnen een partitie tijdelijk overweldigen en leiden tot beperking totdat de dienst zich kan aanpassen.

Volgende stappen 

Voor gedetailleerde implementatierichtlijnen, zie:

• Schaalbaarheids- en prestatiedoelstellingen voor Azure Storage
• Optimaliseer blob-partities en naamgevingsschema's
• Azure Blob Storage monitoren
• Aanbevolen procedures voor het bewaken van Azure Blob Storage-
• Azure Monitor-metrieken en referentiedocumentatie voor resourcelogboeken voor Azure Storage
• Controlelijst voor prestaties voor Azure Blob Storage
• Controlelijst voor prestaties voor ontwikkelaars (Azure Blob Storage)