Heta partitioner i Azure Blob Storage: upptäckt, övervakning och åtgärder

Azure Blob Storage distribuerar data över partitioner för att leverera skalbar prestanda. När trafiken koncentreras på en enda partition kan den partitionen bli en flaskhals, ett tillstånd som kallas en het partition. Den här artikeln förklarar vad hot partitions är, hur man känner igen dem via Azure Monitor-metrik och resursloggar, samt vilka steg du kan vidta för att fördela belastningen jämnare och minska strypningsfel.

Förstå heta partitioner

Azure Blob Storage distribuerar automatiskt data över partitioner för att skala prestanda och genomströmning. När en enskild partition får betydligt mer trafik än andra partitioner blir den en het partition. En het partition uppstår när ett stort antal läs-, skriv- eller uppdateringsförfrågningar går till samma partition, vilket begränsar tjänstens förmåga att effektivt balansera arbetsbelastningen. Som ett resultat upplever förfrågningar ökad latens, strypning och timeout-fel tills arbetsbelastningen omfördelas eller åtkomstmönstret optimeras. Partitionerings- eller namngivningsscheman som koncentrerar trafiken på en liten delmängd data istället för att sprida förfrågningar över flera partitioner orsakar ofta heta partitioner.

Symtom och påverkan av heta partitioner

När en lagringspartition blir het kan den inte längre behandla förfrågningar lika effektivt. När partitionen närmar sig sina skalbarhetsgränser börjar Azure Storage strypa förfrågningar för att skydda tjänsten och upprätthålla tillförlitligheten för andra arbetsbelastningar. Klientapplikationer upplever ökad latens, minskad genomströmning och tillfälliga fel i begäranden.

Vanliga symtom på en överbelastad partition är:

• HTTP 503 (Server Busy) -svar som indikerar att partitionen tillfälligt inte kan hantera fler förfrågningar.
• HTTP 500 (Operation Timeout) svarar när förfrågningar tar för lång tid att slutföra eftersom partitionen är under tung belastning.
• Ökad förfrågningslatens, även för förfrågningar som slutligen lyckas.
• Automatiska återförsök från klienter, vilket kan öka trafiken ytterligare och förlänga problemen med prestandan om många klienter gör återförsök samtidigt.
• Minskad genomströmning, där applikationen hanterar färre operationer per sekund än förväntat trots tillräcklig total lagringskontokapacitet.

Heta partitioner orsakas ofta av åtkomstmönster som koncentrerar trafiken på en enda partition. Vanliga exempel inkluderar sekventiella blobnamn, append-only-arbetsbelastningar och partitionnyckeldesigner som skickar en oproportionerligt stor mängd trafik till en enda partition. När arbetsbelastningen inte är jämnt fördelad når den berörda partitionen sina gränser före resten av lagringskontot, vilket skapar en flaskhals som påverkar applikationens prestanda.

För många tillämpningar är den första indikationen på en het partition en kombination av ökande latens, ökande återförsöksfrekvenser och ökande antal 503 eller 500 fel under perioder med hög efterfrågan.

Upptäck strypningsfel genom att använda Azure Monitor-metrik och resursloggar

Azure Storage stryper förfrågningar när en arbetsbelastning överskrider skalbarhetsmålen för ett lagringskonto eller en partition. Du ser ofta strypning som HTTP 503 (Server Busy) eller 500 (Operation Timeout) svar. Azure Storage-klientbibliotek försöker ofta automatiskt om strypta förfrågningar, så övervakning är avgörande för att upptäcka strypning innan den påverkar applikationens prestanda avsevärt.

Använd Azure Monitor-metrik för att identifiera strypningsfel

För att upptäcka throttling, analysera Azure Monitor-mått för ett lagringskonto. Transaktionsmåttet, kombinerat med dimensionen ResponseType, ger insyn i resultatet av lagringsförfrågningar och hjälper dig att identifiera fel relaterade till strypning.

Mätvärden för att identifiera strypning

Följande Azure Monitor-mått är användbara vid undersökning av strypning:

Ett vanligt strypningsmönster är en ökning av latens åtföljd av fler responstyper relaterade till strypning och minskad tillgänglighet.

Använd dimensionen ResponseType för att identifiera strypning

ResponseType-dimensionen är det primära verktyget för att identifiera begränsningsvillkor i Azure Monitor-metrik. Relevanta värden inkluderar:

Att följa dessa värden över tid kan hjälpa dig att identifiera övergående stryptoppar samt långvariga skalbarhetsproblem för att spåra dessa värden.

Använd mått för att exakt fastställa källan till strypningen.

Måttdimensioner i Azure Monitor kan hjälpa till att isolera den arbetsbelastning som orsakar begränsningen:

Till exempel, om strypning främst sker under PutBlob operationer kan arbetsbelastningen vara skrivintensiv. Om en specifik API-operation visar förhöjda strypningshastigheter kan optimeringsinsatser fokusera på den operationen snarare än hela applikationen.

Analysera Azure Monitor-resursloggar

Medan mätvärden identifierar närvaron av strypning, ger Azure Monitor-resursloggar detaljer på begäransökningsnivå som kan hjälpa till att diagnostisera grundorsaken. Resursloggar registrerar både begäranden som lyckas och som misslyckas, inklusive fel på grund av begränsning, tidsgränsöverskridanden, auktoriseringsfel och nätverksrelaterade fel.

För Azure Blob Storage finns poster tillgängliga i tabellen StorageBlobLogs efter att resursloggar skickats till en Log Analytics-arbetsyta.

Sök i resursloggar efter strypningshändelser

Innan du kör dessa frågor, se till att resursloggar skickas till en arbetsyta för Log Analytics.

Använd Kusto Query Language (KQL) för att identifiera begäranden som returnerar vanliga throttling-relaterade statuskoder:

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

Utöka denna fråga genom att gruppera resultat efter operation, autentiseringstyp, anroparens IP-adress eller applikationsidentitet för att identifiera arbetsbelastningen som genererar strypta förfrågningar. Resursloggar är särskilt användbara för att avgöra om strypning är koncentrerad inom en specifik applikation, åtgärd eller tidsperiod.

Varningsvillkor för strypning

Skapa Azure Monitor-aviseringar för följande:

• Långvariga förekomster av ServerBusyError-transaktioner .
• Ökningar i ResponseType-värden relaterade till strypning.
• Fall i Tillgänglighet-måttet under ett acceptabelt tröskelvärde.
• Ökningar i latens som korrelerar med strypningshändelser.
• Plötsliga ökningar av förfrågningsvolymen som närmar sig skalbarhetsgränser för lagring.

Rekommenderat övervakningsarbetsflöde

1. Övervaka transaktionsmåttet och dela upp resultaten efter ResponseType.
2. Sök efter ökningar i responstyper relaterade till strypning som ServerBusyError och ClientThrottlingError.
3. Använd dimensionen ApiName för att identifiera påverkade operationer.
4. Korrelera strypningshändelser med förändringar i tillgänglighet, Success E2E-latens och Success Server Latency.
5. Använd Azure Monitor-resursloggar för att avgöra vilka förfrågningar, operationer eller applikationer som genererar strypt trafik.
6. Konfigurera varningar så att strypningsproblem upptäcks innan de påverkar användarna.

Genom att kombinera Azure Monitor-mått, dimensioner och resursloggar kan du snabbt upptäcka strypningsförhållanden, identifiera källan till den överdrivna efterfrågan och vidta korrigerande åtgärder innan applikationsprestandan försämras.

Minska effekterna av hårt belastade partitioner

För att förhindra heta partitioner, fördela förfrågningar jämnt över partitioner och se till att applikationer svarar korrekt när strypning sker.

Använd effektiva partitionerings- och namngivningsscheman

Designa partitionsnycklar, blobnamn och andra identifierare så att förfrågningar distribueras över flera partitioner. Undvik sekventiella eller endast append-namngivningsmönster som riktar de flesta förfrågningar till samma partition. Se Optimera blobpartitioner och namngivningsscheman.

Använd exponentiell backoff för omförsök

Om begäranden stryps och returnerar felen 503 (Server Busy) eller 500 (Operation Timeout), försök igen med en exponentiell backoffstrategi. Denna metod minskar trycket på den berörda partitionen och ger Azure Storage tid att ombalansera belastningen eller återhämta sig från tillfälliga efterfrågetoppar.

Exponentiellt backoff-återförsöksbeteende är mest relevant för anpassade applikationer som får tillgång till Azure Storage genom att använda Azure Storage-klientbibliotek, SDK:er eller REST-API:er. Många Microsoft-tjänster, hanterade applikationer och tredjepartsklienter implementerar redan lämplig retry-logik, så du kanske inte behöver konfigurera något extra. Om du utvecklar en anpassad applikation, se till att återförsökspolicyer är aktiverade och konfigurerade enligt Azure Storage:s bästa praxis. Se någon av följande artiklar:

• Implementera en återförsökspolicy för .NET
• Implementera en återupptagningspolicy för Java
• Implementera en återupptagningspolicy för JavaScript
• Implementera en återförsökspolicy för Python
• Implementera en återbesökspolicy för Go

Undvik plötsliga ökningar i förfrågningsvolymen

När man introducerar en ny arbetsbelastning, kör prestandatester eller bearbetar stora datamängder, ökar man förfrågningshastigheten gradvis istället för att omedelbart generera topptrafik. Azure Storage lastbalanserar automatiskt partitioner när efterfrågan förändras, men plötsliga trafiktoppar kan tillfälligt överbelasta en partition och leda till strypning tills tjänsten får möjlighet att justera.

Nästa steg

För detaljerad implementeringsvägledning, se:

• Skalbarhets- och prestandamål för Azure Storage
• Optimera blob-partitioner och namngivningsscheman
• Övervaka Azure Blob Storage
• Bäste metoder för övervakning Azure Blob Storage
• Referensdokumentation för mått i Azure Monitor och resursloggar för Azure Storage
• Prestandachecklista för Azure Blob Storage
• Prestandachecklista för utvecklare (Azure Blob Storage)