Share via

Azure Well-Architected Framework-perspektiv på Azure Blob Storage

  • Artikel

Azure Blob Storage är en Microsoft-objektlagringslösning för molnet. Blob Storage är optimerat för att lagra enorma mängder ostrukturerade data. Ostrukturerade data är data som inte följer en viss datamodell eller definition, till exempel text eller binära data.

Den här artikeln förutsätter att du som arkitekt har granskat dina lagringsalternativ och valt Blob Storage som lagringstjänst för att köra dina arbetsbelastningar. Vägledningen i den här artikeln innehåller arkitektoniska rekommendationer som är mappade till principerna för grundpelarna i Azure Well-Architected Framework.

Viktigt!

Så här använder du den här guiden

Varje avsnitt har en checklista för design som presenterar arkitekturområden som är viktiga tillsammans med designstrategier.

Dessutom ingår rekommendationer om de teknikfunktioner som kan hjälpa dig att implementera dessa strategier. Rekommendationerna representerar inte en fullständig lista över alla konfigurationer som är tillgängliga för Blob Storage och dess beroenden. I stället listar de de viktigaste rekommendationerna som mappats till designperspektiven. Använd rekommendationerna för att skapa ditt konceptbevis eller optimera dina befintliga miljöer.

Tillförlitlighet

Syftet med grundpelare för tillförlitlighet är att tillhandahålla fortsatt funktionalitet genom att skapa tillräckligt med motståndskraft och möjlighet att återhämta sig snabbt från fel.

Designprinciperna för tillförlitlighet ger en övergripande designstrategi som tillämpas för enskilda komponenter, systemflöden och systemet som helhet.

Checklista för design

Starta din designstrategi baserat på checklistan för designgranskning för tillförlitlighet.

  • Analys av felläge: Minimera felpunkter genom att överväga interna beroenden, till exempel tillgängligheten för virtuella nätverk, Azure Key Vault eller Azure Content Delivery Network eller Azure Front Door-slutpunkter. Fel kan inträffa om autentiseringsuppgifter som krävs av arbetsbelastningar för åtkomst till Blob Storage försvinner från Key Vault, eller om arbetsbelastningar använder en slutpunkt baserat på ett nätverk för innehållsleverans som har tagits bort. I dessa fall kan arbetsbelastningar behöva använda en alternativ slutpunkt för att ansluta. Allmän information om analys av felläge finns i Rekommendationer för analys av felläge.

  • Definiera tillförlitlighets- och återställningsmål: Granska Azure-serviceavtal (SLA). Härled servicenivåmålet (SLO) för lagringskontot. SLO kan till exempel påverkas av den redundanskonfiguration som du har valt. Tänk på effekten av ett regionalt avbrott, risken för dataförlust och den tid som krävs för att återställa åtkomsten efter ett avbrott. Tänk också på tillgängligheten för eventuella interna beroenden som du har identifierat som en del av fellägesanalysen.

  • Konfigurera dataredundans: För maximal hållbarhet väljer du en konfiguration som kopierar data mellan tillgänglighetszoner eller globala regioner. För maximal tillgänglighet väljer du en konfiguration som gör att klienter kan läsa data från den sekundära regionen under ett avbrott i den primära regionen.

  • Designprogram: Utforma program för att sömlöst övergå till att läsa data från den sekundära regionen om den primära regionen blir otillgänglig av någon anledning. Detta gäller endast geo-redundant lagring (GRS) och GZRS-konfigurationer (geo-zone-redundant lagring). Att utforma program för att hantera avbrott minskar stilleståndstiden för slutanvändarna.

  • Utforska funktioner som hjälper dig att uppfylla dina återställningsmål: Gör blobar återställningsbara så att de kan återställas om de är skadade, redigerade eller borttagna av misstag.

  • Skapa en återställningsplan: Överväg dataskyddsfunktioner, säkerhetskopierings- och återställningsåtgärder eller redundansprocedurer. Förbered för potentiella dataförluster och datainkonsekvenser samt tid och kostnad för redväxling. Mer information finns i Rekommendationer för att utforma en strategi för haveriberedskap.

  • Övervaka potentiella tillgänglighetsproblem: Prenumerera på Azure Service Health-instrumentpanelen för att övervaka potentiella tillgänglighetsproblem. Använd lagringsmått i Azure Monitor och diagnostikloggar för att undersöka aviseringar.

Rekommendationer

Rekommendation Förmån
Konfigurera ditt konto för redundans.

För maximal tillgänglighet och hållbarhet konfigurerar du ditt konto med zonredundant lagring (ZRS) eller GZRS.		 Redundans skyddar dina data mot oväntade fel. Konfigurationsalternativen ZRS och GZRS replikeras mellan olika tillgänglighetszoner och gör det möjligt för program att fortsätta läsa data under ett avbrott. Mer information finns i Hållbarhet och tillgänglighet efter avbrottsscenario och parametrar för hållbarhet och tillgänglighet.
Innan du påbörjar en redundansväxling eller återställning efter fel utvärderar du risken för dataförlust genom att kontrollera värdet för den senaste synkroniseringstidsegenskapen. Den här rekommendationen gäller endast GRS- och GZRS-konfigurationer. Den här egenskapen hjälper dig att uppskatta hur mycket data du kan förlora genom att initiera en redundansväxling av ett konto.

Alla data och metadata som skrivits före den senaste synkroniseringstiden är tillgängliga i den sekundära regionen, men data och metadata som skrivits efter den senaste synkroniseringstiden kan gå förlorade eftersom de inte har skrivits till den sekundära regionen.
Som en del av din strategi för säkerhetskopiering och återställning aktiverar du alternativen mjuk borttagning av containrar, mjuk borttagning av blobar, versionshantering och återställning till tidpunkt. Med alternativet mjuk borttagning kan ett lagringskonto återställa borttagna containrar och blobar.

Versionsalternativet spårar automatiskt ändringar som gjorts i blobar. Med det här alternativet kan du återställa en blob till ett tidigare tillstånd.

Återställningsalternativet för tidpunkt skyddar mot oavsiktlig borttagning eller skada av blobar och gör att du kan återställa blockblobdata till ett tidigare tillstånd.

Mer information finns i Översikt över dataskydd.

Säkerhet

Syftet med säkerhetspelare är att tillhandahålla garantier för konfidentialitet, integritet och tillgänglighet för arbetsbelastningen.

Principerna för säkerhetsdesign ger en övergripande designstrategi för att uppnå dessa mål genom att tillämpa metoder för den tekniska utformningen av bloblagringskonfigurationen.

Checklista för design

Starta din designstrategi baserat på checklistan för designgranskning för Säkerhet. Identifiera säkerhetsrisker och kontroller för att förbättra säkerhetsstatusen. Utöka strategin till att omfatta fler metoder efter behov.

  • Granska säkerhetsbaslinjen för Azure Storage: Kom igång genom att först granska säkerhetsbaslinjen för Storage.

  • Använd nätverkskontroller för att begränsa inkommande och utgående trafik: Inaktivera all offentlig trafik till lagringskontot. Använd kontonätverkskontroller för att ge den minimala åtkomstnivå som krävs av användare och program. Mer information finns i Så här närmar du dig nätverkssäkerhet för ditt lagringskonto.

  • Minska attackytan: Förhindra anonym åtkomst, åtkomst till kontonycklar eller åtkomst via icke-säkra anslutningar (HTTP) kan minska attackytan. Kräv att klienter skickar och tar emot data med hjälp av den senaste versionen av TLS-protokollet (Transport Layer Security).

  • Auktorisera åtkomst utan att använda lösenord eller nycklar: Microsoft Entra-ID ger överlägsen säkerhet och användarvänlighet jämfört med delade nycklar och signaturer för delad åtkomst. Bevilja säkerhetsobjekt endast de behörigheter som krävs för att de ska kunna utföra sina uppgifter.

  • Skydda känslig information: Skydda känslig information, till exempel kontonycklar och signaturtoken för delad åtkomst. Dessa auktoriseringsformer rekommenderas vanligtvis inte, men du bör se till att rotera, förfalla och lagra dem på ett säkert sätt.

  • Aktivera alternativet säker överföring: Om du aktiverar den här inställningen för alla dina lagringskonton ser du till att alla begäranden som görs mot lagringskontot måste ske via säkra anslutningar. Alla begäranden som görs via HTTP misslyckas.

  • Skydda kritiska objekt: Använd oföränderlighetsprinciper för att skydda kritiska objekt. Principer skyddar blobar som lagras för juridiska ändamål, efterlevnad eller andra affärsändamål från att ändras eller tas bort. Konfigurera undantag för angivna tidsperioder eller tills begränsningarna hävs av en administratör.

  • Identifiera hot: Aktivera Microsoft Defender för Lagring för att identifiera hot. Säkerhetsaviseringar utlöses när avvikelser i en aktivitet inträffar. Aviseringarna meddelar prenumerationsadministratörer via e-post med information om misstänkt aktivitet och rekommendationer om hur du undersöker och åtgärdar hot.

Rekommendationer

Rekommendation Förmån
Inaktivera anonym läsåtkomst till containrar och blobar. När anonym åtkomst tillåts för ett lagringskonto kan en användare som har rätt behörighet ändra en containers inställning för anonym åtkomst för att aktivera anonym åtkomst till data i containern.
Tillämpa ett Azure Resource Manager-lås på lagringskontot. Att låsa ett konto förhindrar att det tas bort och orsakar dataförlust.
Inaktivera trafik till de offentliga slutpunkterna för ditt lagringskonto . Skapa privata slutpunkter för klienter som körs i Azure. Aktivera endast den offentliga slutpunkten om klienter och tjänster utanför Azure kräver direkt åtkomst till ditt lagringskonto. Aktivera brandväggsregler som begränsar åtkomsten till specifika virtuella nätverk. Börja med noll åtkomst och auktorisera sedan stegvis de lägsta åtkomstnivåer som krävs för klienter och tjänster för att minimera risken för att skapa onödiga öppningar för angripare.
Auktorisera åtkomst med hjälp av rollbaserad åtkomstkontroll i Azure (RBAC). Med RBAC finns det inga lösenord eller nycklar som kan komprometteras. Säkerhetsobjektet (användare, grupp, hanterad identitet eller tjänstens huvudnamn) autentiseras av Microsoft Entra-ID för att returnera en OAuth 2.0-token. Token används för att auktorisera en begäran mot Blob Storage-tjänsten.
Tillåt inte auktorisering av delad nyckel. Detta inaktiverar inte bara åtkomst till kontonycklar utan även signaturtoken för delad åtkomst för tjänst och konto eftersom de baseras på kontonycklar. Endast skyddade begäranden som är auktoriserade med Microsoft Entra-ID är tillåtna.
Vi rekommenderar att du inte använder en kontonyckel. Om du måste använda kontonycklar lagrar du dem i Key Vault och ser till att du återskapar dem regelbundet. Med Key Vault kan du hämta nycklar vid körning i stället för att spara dem med hjälp av ditt program. Key Vault gör det också enkelt att rotera dina nycklar utan avbrott i dina program. Om du roterar kontonycklarna med jämna mellanrum minskar risken för att exponera dina data för skadliga attacker.
Vi rekommenderar att du inte använder signaturtoken för delad åtkomst. Utvärdera om du behöver signaturtoken för delad åtkomst för att skydda åtkomsten till Blob Storage-resurser. Om du måste skapa en kan du granska den här listan med metodtips för signatur för delad åtkomst innan du skapar och distribuerar den. Metodtips kan hjälpa dig att förhindra att en signaturtoken för delad åtkomst läcker och snabbt återställas om en läcka inträffar.
Konfigurera ditt lagringskonto så att klienter kan skicka och ta emot data med hjälp av den lägsta versionen av TLS 1.2. TLS 1.2 är säkrare och snabbare än TLS 1.0 och 1.1, som inte stöder moderna kryptografiska algoritmer och chiffersviter.
Överväg att använda din egen krypteringsnyckel för att skydda data i ditt lagringskonto. Mer information finns i Kundhanterade nycklar för Azure Storage-kryptering. Kundhanterade nycklar ger större flexibilitet och kontroll. Du kan till exempel lagra krypteringsnycklar i Key Vault och rotera dem automatiskt.

Kostnadsoptimering

Kostnadsoptimering fokuserar på att identifiera utgiftsmönster, prioritera investeringar inom kritiska områden och optimera i andra för att uppfylla organisationens budget- och affärskrav.

Designprinciperna för kostnadsoptimering ger en övergripande designstrategi för att uppnå dessa mål och göra avvägningar vid behov i den tekniska designen som rör Blob Storage och dess miljö.

Checklista för design

Starta din designstrategi baserat på checklistan för designgranskning för kostnadsoptimering för investeringar. Finjustera designen så att arbetsbelastningen är i linje med den budget som allokeras för arbetsbelastningen. Din design bör använda rätt Azure-funktioner, övervaka investeringar och hitta möjligheter att optimera över tid.

  • Identifiera de mätare som används för att beräkna din faktura: Mätare används för att spåra mängden data som lagras i kontot (datakapacitet) och antalet och typen av åtgärder som utförs för att skriva och läsa data. Det finns också mätare som är associerade med användningen av valfria funktioner som blobindextaggar, blobinventering, stöd för ändringsflöde, krypteringsomfång och SSH-stöd för filöverföringsprotokoll (SFTP). Mer information finns i Så här debiteras du för Blob Storage.

  • Förstå priset för varje mätare: Se till att använda lämplig prissida och tillämpa lämpliga inställningar på den sidan. Mer information finns i Hitta enhetspriset för varje mätare. Överväg antalet åtgärder som är associerade med varje pris. Priset som är associerat med skriv- och läsåtgärder gäller till exempel för 10 000 åtgärder. Om du vill fastställa priset för en enskild åtgärd delar du upp det angivna priset med 10 000.

  • Beräkna kostnaden för kapacitet och åtgärder: Du kan modellera kostnaderna för datalagring, ingress och utgående data med hjälp av Priskalkylatorn för Azure. Använd fält för att jämföra kostnaden som är associerad med olika regioner, kontotyper, namnområdestyper och redundanskonfigurationer. I vissa scenarier kan du använda exempelberäkningar och kalkylblad som är tillgängliga i Microsoft-dokumentationen. Du kan till exempel beräkna kostnaden för att arkivera data eller uppskatta kostnaden för att använda AzCopy-kommandot för att överföra blobar.

  • Välj en faktureringsmodell för kapacitet: Utvärdera om det är mer kostnadseffektivt att använda en åtagandebaserad modell än att använda en förbrukningsbaserad modell. Om du är osäker på hur mycket kapacitet du behöver kan du börja med en förbrukningsbaserad modell, övervaka kapacitetsmåtten och sedan utvärdera senare.

  • Välj en kontotyp, en redundansnivå och en standardåtkomstnivå: Du måste välja ett värde för var och en av dessa inställningar när du skapar ett lagringskonto. Alla värden påverkar transaktionsavgifter och kapacitetsavgifter. Alla dessa inställningar förutom kontotypen kan ändras när kontot har skapats.

  • Välj den mest kostnadseffektiva standardåtkomstnivån: Om inte en nivå anges med varje blobuppladdning, härleder blobar sin åtkomstnivå från standardinställningen för åtkomstnivå. En ändring av standardinställningen för åtkomstnivå för ett lagringskonto gäller för alla blobar i kontot som en åtkomstnivå inte uttryckligen har angetts för. Den här kostnaden kan vara betydande om du har samlat in ett stort antal blobar. Mer information om hur en nivåändring påverkar varje befintlig blob finns i Ändra åtkomstnivån för en blob.

  • Ladda upp data direkt till den mest kostnadseffektiva åtkomstnivån: Om standardinställningen för åtkomstnivån för ditt konto är het, men du laddar upp filer i arkiveringssyfte, anger du en coolare nivå som arkiv eller en kall nivå som en del av uppladdningen. När du har laddat upp blobar använder du livscykelhanteringsprinciper för att flytta blobar till de mest kostnadseffektiva nivåerna baserat på användningsstatistik, till exempel den senast använda tiden. Om du väljer den mest optimala nivån i förväg kan du minska kostnaderna. Om du ändrar nivån för en blockblob som du redan har laddat upp betalar du kostnaden för att skriva till den första nivån när du först laddar upp bloben och betalar sedan kostnaden för att skriva till önskad nivå.

  • Ha en plan för att hantera datalivscykeln: Optimera transaktions- och kapacitetskostnader genom att dra nytta av åtkomstnivåer och livscykelhantering. Data som används mindre ofta bör placeras på lågfrekventa åtkomstnivåer medan data som används ofta ska placeras på varmare åtkomstnivåer.

  • Bestäm vilka funktioner du behöver: Vissa funktioner som versionshantering och mjuk borttagning av blobar medför ytterligare transaktions- och kapacitetskostnader samt andra avgifter. Se till att granska pris- och faktureringsavsnitten i artiklar som beskriver dessa funktioner när du väljer vilka funktioner som ska läggas till i ditt konto.

    Om du till exempel aktiverar blobinventeringsfunktionen debiteras du för antalet objekt som genomsöks. Om du använder blobindextaggar debiteras du för antalet indextaggar. Om du aktiverar SFTP-support debiteras du en timavgift, även om det inte finns några SFTP-överföringar. Om du väljer att inte använda en funktion kontrollerar du att funktionen är inaktiverad eftersom vissa funktioner aktiveras automatiskt när du skapar kontot.

  • Skapa skyddsräcken: Skapa budgetar baserat på prenumerationer och resursgrupper. Använd styrningsprinciper för att begränsa resurstyper, konfigurationer och platser. Dessutom kan du använda RBAC för att blockera åtgärder som kan leda till överförbrukning.

  • Övervaka kostnader: Se till att kostnaderna håller sig inom budgetar, jämför kostnader med prognoser och se var överförbrukning sker. Du kan använda fönstret kostnadsanalys i Azure-portalen för att övervaka kostnaderna. Du kan också exportera kostnadsdata till ett lagringskonto och analysera dessa data med hjälp av Excel eller Power BI.

  • Övervaka användning: Övervaka användningsmönster kontinuerligt och identifiera oanvända eller underutnyttjade konton och containrar. Använd Storage-insikter för att identifiera konton utan eller med låg användning. Aktivera blobinventeringsrapporter och använd verktyg som Azure Databricks eller Azure Synapse Analytics och Power BI för att analysera kostnadsdata. Se upp för oväntade ökningar av kapaciteten, vilket kan tyda på att du samlar in många loggfiler, blobversioner eller mjuk borttagna blobar. Utveckla en strategi för att förfalla eller överföra objekt till mer kostnadseffektiva åtkomstnivåer. Ha en plan för att förfalla objekt eller flytta objekt till mer prisvärda åtkomstnivåer.

Rekommendationer

Rekommendation Förmån
Packa små filer i större filer innan du flyttar dem till lågfrekventa nivåer. Du kan använda filformat som TAR eller ZIP. Coolare nivåer har högre kostnader för dataöverföring. Genom att ha färre stora filer kan du minska antalet åtgärder som krävs för att överföra data.
Använd rehydrering med standardprioritet när du extraherar blobar från arkivlagring. Använd endast högprioriterad rehydrering för återställning av nöddata. Mer information finns i Rehydrate an archived blob to an online tier (Återskapa en arkiverad blob till en onlinenivå) Högprioriterad rehydrering från arkivnivån kan leda till högre fakturor än normalt.
Minska kostnaden för att använda resursloggar genom att välja lämplig logglagringsplats och genom att hantera loggkvarhållningsperioder. Om du bara planerar att köra frågor mot loggar ibland (till exempel genom att fråga loggar för efterlevnadsgranskning) bör du överväga att skicka resursloggar till ett lagringskonto i stället för att skicka dem till en Azure Monitor Logs-arbetsyta. Du kan använda en serverlös frågelösning som Azure Synapse Analytics för att analysera loggar. Mer information finns i Optimera kostnader för vanliga frågor. Använd livscykelhanteringsprinciper för att ta bort eller arkivera loggar. Att lagra resursloggar i ett lagringskonto för senare analys kan vara ett billigare alternativ. Om du använder principer för livscykelhantering för att hantera loggkvarhållning på ett lagringskonto förhindrar du att ett stort antal loggfiler byggs upp över tid, vilket kan leda till onödiga kapacitetsavgifter.
Om du aktiverar versionshantering använder du en livscykelhanteringsprincip för att automatiskt ta bort gamla blobversioner. Varje skrivåtgärd till en blob skapar en ny version. Detta ökar kapacitetskostnaderna. Du kan hålla kostnaderna i schack genom att ta bort versioner som du inte längre behöver.
Om du aktiverar versionshantering placerar du blobar som ofta skrivs över till ett konto som inte har versionshantering aktiverat. Varje gång en blob skrivs över läggs en ny version till, vilket leder till ökade avgifter för lagringskapacitet. Om du vill minska kapacitetsavgifterna lagrar du ofta överskrivna data i ett separat lagringskonto med versionshantering inaktiverat.
Om du aktiverar mjuk borttagning placerar du blobar som ofta skrivs över till ett konto som inte har mjuk borttagning aktiverat. Ange kvarhållningsperioder. Överväg att börja med en kort kvarhållningsperiod för att bättre förstå hur funktionen påverkar din faktura. Den minsta rekommenderade kvarhållningsperioden är sju dagar. Varje gång en blob skrivs över skapas en ny ögonblicksbild. Orsaken till ökade kapacitetsavgifter kan vara svår att komma åt eftersom det inte visas några ögonblicksbilder i loggarna. Om du vill minska kapacitetsavgifterna lagrar du ofta överskrivna data i ett separat lagringskonto med mjuk borttagning inaktiverad. En kvarhållningsperiod hindrar mjuk borttagna blobar från att staplas upp och öka kostnaden för kapaciteten.
Aktivera endast SFTP-stöd när det används för att överföra data. Att aktivera SFTP-slutpunkten medför en timkostnad. Genom att eftertänksamt inaktivera SFTP-stöd och sedan aktivera det efter behov kan du undvika passiva avgifter från att ackumuleras i ditt konto.
Inaktivera krypteringsomfång som inte behövs för att undvika onödiga avgifter. Krypteringsomfång medför en avgift per månad.

Driftseffektivitet

Operational Excellence fokuserar främst på procedurer för utvecklingsmetoder, observerbarhet och versionshantering.

Designprinciperna för operational excellence tillhandahåller en övergripande designstrategi för att uppnå dessa mål för arbetsbelastningens driftskrav.

Checklista för design

Starta din designstrategi baserat på checklistan för designgranskning för operational excellence för att definiera processer för observerbarhet, testning och distribution som är relaterade till din Blob Storage-konfiguration.

  • Skapa planer för underhåll och nödåterställning: Överväg dataskyddsfunktioner, säkerhetskopierings- och återställningsåtgärder samt redundansprocedurer. Förbered för potentiella dataförluster och datainkonsekvenser samt tid och kostnad för redväxling.

  • Övervaka hälsotillståndet för ditt lagringskonto: Skapa instrumentpaneler för Lagringsinsikter för att övervaka mått för tillgänglighet, prestanda och motståndskraft. Konfigurera aviseringar för att identifiera och åtgärda problem i systemet innan kunderna märker dem. Använd diagnostikinställningar för att dirigera resursloggar till en Arbetsyta för Azure Monitor-loggar. Sedan kan du köra frågor mot loggar för att undersöka aviseringar djupare.

  • Aktivera blobinventeringsrapporter: Aktivera blobinventeringsrapporter för att granska kvarhållning, bevarande av juridiska skäl eller krypteringsstatus för ditt lagringskontoinnehåll. Du kan också använda blobinventeringsrapporter för att förstå den totala datastorleken, åldern, nivåfördelningen eller andra attribut för dina data. Använd verktyg som Azure Databricks eller Azure Synapse Analytics och Power BI för att bättre visualisera inventeringsdata och skapa rapporter för intressenter.

  • Konfigurera principer som tar bort blobar eller flytta dem till kostnadseffektiva åtkomstnivåer: Skapa en livscykelhanteringsprincip med en inledande uppsättning villkor. Principen körs automatiskt ta bort eller ange åtkomstnivån för blobar baserat på de villkor som du definierar. Analysera regelbundet containeranvändningen med hjälp av Övervaka mått och blobinventeringsrapporter så att du kan förfina villkoren för att optimera kostnadseffektiviteten.

Rekommendationer

Rekommendation Förmån
Använd infrastruktur som kod (IaC) för att definiera information om dina lagringskonton i Azure Resource Manager-mallar (ARM-mallar), Bicep eller Terraform. Du kan använda dina befintliga DevOps-processer för att distribuera nya lagringskonton och använda Azure Policy för att framtvinga deras konfiguration.
Använd Storage-insikter för att spåra hälsotillståndet och prestandan för dina lagringskonton. Lagringsinsikter ger en enhetlig vy över fel, prestanda, tillgänglighet och kapacitet för alla dina lagringskonton. Du kan spåra hälsotillståndet och driften för vart och ett av dina konton. Skapa enkelt instrumentpaneler och rapporter som intressenter kan använda för att spåra hälsotillståndet för dina lagringskonton.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att upprätthålla användarupplevelsen även när belastningen ökar genom att hantera kapaciteten. Strategin omfattar skalning av resurser, identifiering och optimering av potentiella flaskhalsar och optimering för högsta prestanda.

Designprinciperna för prestandaeffektivitet ger en designstrategi på hög nivå för att uppnå dessa kapacitetsmål mot den förväntade användningen.

Checklista för design

Starta din designstrategi baserat på checklistan för designgranskning för prestandaeffektivitet. Definiera en baslinje som baseras på viktiga prestandaindikatorer för bloblagringskonfigurationen.

  • Planera för skalning: Förstå skalningsmålen för lagringskonton.

  • Välj den optimala lagringskontotypen: Om din arbetsbelastning kräver höga transaktionshastigheter, mindre objekt och en konsekvent låg transaktionsfördröjning bör du överväga att använda premium-blockbloblagringskonton. Ett standardkonto för generell användning v2 är lämpligast i de flesta fall.

  • Minska resavståndet mellan klienten och servern: Placera data i regioner närmast anslutande klienter (helst i samma region). Optimera för klienter i regioner långt borta med hjälp av objektreplikering eller ett nätverk för innehållsleverans. Standardnätverkskonfigurationer ger bästa möjliga prestanda. Ändra endast nätverksinställningar för att förbättra säkerheten. I allmänhet minskar inte nätverksinställningarna reseavståndet och förbättrar inte prestandan.

  • Välj ett effektivt namngivningsschema: Minska svarstiden för list-, list-, fråge- och läsåtgärder med hashtaggens prefix närmast början av blobpartitionsnyckeln (konto, container, virtuell katalog eller blobnamn). Det här schemat gynnar främst konton som har ett platt namnområde.

  • Optimera prestanda för dataklienter: Välj ett dataöverföringsverktyg som passar bäst för arbetsbelastningarnas datastorlek, överföringsfrekvens och bandbredd. Vissa verktyg som AzCopy är optimerade för prestanda och kräver lite åtgärder. Tänk på de faktorer som påverkar svarstiden och finjustera prestanda genom att granska vägledningen för prestandaoptimering som publiceras med varje verktyg.

  • Optimera prestanda för anpassad kod: Överväg att använda Lagrings-SDK:er i stället för att skapa egna omslutningar för blob-REST-åtgärder. Azure SDK:er är optimerade för prestanda och tillhandahåller mekanismer för att finjustera prestanda. Granska prestanda- och skalbarhetschecklistan för Blob Storage innan du skapar ett program. Överväg att använda frågeacceleration för att filtrera bort oönskade data under lagringsbegäran och hindra klienter från att i onödan överföra data i nätverket.

  • Samla in prestandadata: Övervaka ditt lagringskonto för att identifiera flaskhalsar i prestanda som uppstår vid begränsning. Mer information finns i Övervaka din lagringstjänst med Monitor Storage-insikter. Använd både mått och loggar. Mått ger tal, till exempel begränsningsfel. Loggar beskriver aktivitet. Om du ser begränsningsmått kan du använda loggar för att identifiera vilka klienter som får begränsningsfel. Mer information finns i Granska dataplansåtgärder.

Rekommendationer

Rekommendation Förmån
Etablera lagringskonton i samma region där beroende resurser placeras. För program som inte finns i Azure, till exempel mobilappar eller lokala företagstjänster, letar du upp lagringskontot i en region närmare dessa klienter. Mer information finns i Azure-geografiska områden.

Om klienter från en annan region inte behöver samma data skapar du ett separat konto i varje region.

Om klienter från en annan region bara behöver vissa data bör du överväga att använda en princip för objektreplikering för att asynkront kopiera relevanta objekt till ett lagringskonto i den andra regionen.		 Om du minskar det fysiska avståndet mellan lagringskontot och de virtuella datorerna, tjänsterna och de lokala klienterna kan du förbättra prestanda och minska nätverksfördröjningen. Att minska det fysiska avståndet minskar också kostnaderna för program som finns i Azure eftersom bandbreddsanvändningen i en enda region är kostnadsfri.
För bred användning av webbklienter (strömmande video, ljud eller statiskt webbplatsinnehåll) bör du överväga att använda ett nätverk för innehållsleverans via Azure Front Door. Innehållet levereras snabbare till klienter eftersom det använder Microsofts globala gränsnätverk med hundratals globala och lokala närvaropunkter runt om i världen.
Lägg till en hash-teckensekvens (till exempel tre siffror) så tidigt som möjligt i partitionsnyckeln för en blob. Partitionsnyckeln är kontonamnet, containernamnet, namnet på den virtuella katalogen och blobnamnet. Om du planerar att använda tidsstämplar i namn kan du överväga att lägga till ett sekundersvärde i början av den stämpeln. Mer information finns i Partitionering. Om du använder ett hash-kod eller sekundersvärde närmast början av en partitionsnyckel minskar den tid som krävs för att lista frågor och läsa blobar.
När du laddar upp blobar eller block använder du en blob- eller blockstorlek som är större än 256 KiB. Blob- eller blockstorlekar över 256 KiB drar nytta av prestandaförbättringar på plattformen som görs specifikt för större blobar och blockstorlekar.

Azure-principer

Azure tillhandahåller en omfattande uppsättning inbyggda principer som rör Blob Storage och dess beroenden. Några av föregående rekommendationer kan granskas via Azure-principer. Du kan till exempel kontrollera om:

  • Anonym offentlig läsåtkomst till containrar och blobar är inte aktiverad.
  • Diagnostikinställningar för Blob Storage är inställda på att strömma resursloggar till en Azure Monitor Logs-arbetsyta.
  • Endast begäranden från säkra anslutningar (HTTPS) godkänns.
  • En förfalloprincip för signatur för delad åtkomst är aktiverad.
  • Replikering av objekt mellan klientorganisationer är inaktiverad.
  • Auktorisering av delad nyckel är inaktiverad.
  • Brandväggsregler för nätverk tillämpas på kontot.

Omfattande styrning finns i de inbyggda Definitionerna för Azure Policy för Lagring och andra principer som kan påverka säkerheten för beräkningslagret.

Azure Advisor-rekommendationer

Azure Advisor är en anpassad molnkonsult som hjälper dig att följa metodtipsen för att optimera dina Azure-distributioner. Här följer några rekommendationer som kan hjälpa dig att förbättra bloblagringens tillförlitlighet, säkerhet, kostnadseffektivitet, prestanda och driftsprestanda.

Gå vidare

Mer information om Blob Storage finns i Dokumentation om Blob Storage.