Redundans i Azure Storage

Azure Storage lagrar alltid flera kopior av dina data så att de skyddas från planerade och oplanerade händelser, inklusive tillfälliga maskinvarufel, nätverks- eller strömavbrott och massiva naturkatastrofer. Redundans säkerställer att ditt lagringskonto uppfyller sina tillgänglighets- och hållbarhetsmål även vid fel.

När du bestämmer vilket redundansalternativ som är bäst för ditt scenario bör du överväga kompromisserna mellan lägre kostnader och högre tillgänglighet. De faktorer som hjälper dig att avgöra vilket redundansalternativ du bör välja är:

  • Hur dina data replikeras i den primära regionen.
  • Om dina data replikeras till en andra region som är geografiskt avlägsen till den primära regionen, för att skydda mot regionala katastrofer (geo-replikering).
  • Om ditt program kräver läsåtkomst till replikerade data i den sekundära regionen om den primära regionen blir otillgänglig av någon anledning (geo-replikering med läsåtkomst).

Anteckning

De funktioner och regional tillgänglighet som beskrivs i den här artikeln är också tillgängliga för konton som har ett hierarkiskt namnområde (Azure Blob Storage).

De tjänster som utgör Azure Storage hanteras via en vanlig Azure-resurs som kallas lagringskonto. Lagringskontot representerar en delad lagringspool som kan användas för att distribuera lagringsresurser som blobcontainrar (Blob Storage), filresurser (Azure Files), tabeller (Table Storage) eller köer (Queue Storage). Mer information om Azure Storage-konton finns i Översikt över lagringskonto.

Redundansinställningen för ett lagringskonto delas för alla lagringstjänster som exponeras av det kontot. Alla lagringsresurser som distribueras i samma lagringskonto har samma redundansinställning. Du kanske vill isolera olika typer av resurser i separata lagringskonton om de har olika redundanskrav.

Redundans i den primära regionen

Data i ett Azure Storage-konto replikeras alltid tre gånger i den primära regionen. Azure Storage innehåller två alternativ för hur dina data replikeras i den primära regionen:

  • Lokalt redundant lagring (LRS) kopierar dina data synkront tre gånger inom en enda fysisk plats i den primära regionen. LRS är det billigaste replikeringsalternativet, men rekommenderas inte för program som kräver hög tillgänglighet eller hållbarhet.
  • Zonredundant lagring (ZRS) kopierar dina data synkront över tre Azure-tillgänglighetszoner i den primära regionen. För program som kräver hög tillgänglighet rekommenderar Microsoft att du använder ZRS i den primära regionen och även replikerar till en sekundär region.

Anteckning

Microsoft rekommenderar att du använder ZRS i den primära regionen för Azure Data Lake Storage Gen2 arbetsbelastningar.

Lokalt redundant lagring

Lokalt redundant lagring (LRS) replikerar ditt lagringskonto tre gånger inom ett enda datacenter i den primära regionen. LRS ger minst 99,99999999999 % (11 nior) objekthållbarhet under ett visst år.

LRS är det lägsta redundansalternativet och erbjuder minst hållbarhet jämfört med andra alternativ. LRS skyddar dina data mot serverrack- och enhetsfel. Men om en katastrof som brand eller översvämning inträffar i datacentret kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga. För att minska den här risken rekommenderar Microsoft att du använder zonredundant lagring (ZRS), geo-redundant lagring (GRS) eller geozonredundant lagring (GZRS).

En skrivbegäran till ett lagringskonto som använder LRS sker synkront. Skrivåtgärden returneras först när data har skrivits till alla tre replikerna.

Följande diagram visar hur dina data replikeras i ett enda datacenter med LRS:

Diagram som visar hur data replikeras i ett enda datacenter med LRS

LRS är ett bra alternativ för följande scenarier:

  • Om ditt program lagrar data som enkelt kan rekonstrueras om data går förlorade kan du välja LRS.
  • Om ditt program är begränsat till att endast replikera data inom ett land eller en region på grund av datastyrningskrav kan du välja LRS. I vissa fall kan de parkopplade regionerna som data är geo-replikerade över finnas i ett annat land eller en annan region. Mer information om länkade regioner finns i Azure-regioner.
  • Om ditt scenario använder ohanterade Azure-diskar kan du välja LRS. Även om det är möjligt att skapa ett lagringskonto för ohanterade Azure-diskar som använder GRS, rekommenderas det inte på grund av potentiella problem med konsekvens över asynkron geo-replikering.

Zonredundant lagring

Zonredundant lagring (ZRS) replikerar ditt lagringskonto synkront över tre Azure-tillgänglighetszoner i den primära regionen. Varje tillgänglighetszon är en separat fysisk plats med fristående strömförsörjning, nedkylning och nätverk. ZRS erbjuder hållbarhet för lagringsresurser på minst 99,99999999999 % (12 nior) under ett visst år.

Med ZRS är dina data fortfarande tillgängliga för både läs- och skrivåtgärder även om en zon blir otillgänglig. Om en zon blir otillgänglig utför Azure nätverksuppdateringar, till exempel DNS-ompunktning. Dessa uppdateringar kan påverka ditt program om du kommer åt data innan uppdateringarna har slutförts. När du utformar program för ZRS följer du metoderna för hantering av tillfälliga fel, inklusive implementering av återförsöksprinciper med exponentiell backoff.

En skrivbegäran till ett lagringskonto som använder ZRS sker synkront. Skrivåtgärden returneras endast när data har skrivits till alla repliker i de tre tillgänglighetszonerna.

Microsoft rekommenderar att du använder ZRS i den primära regionen för scenarier som kräver hög tillgänglighet. ZRS rekommenderas också för att begränsa replikering av data till ett visst land eller en viss region för att uppfylla kraven för datastyrning.

Microsoft rekommenderar att du använder ZRS för Azure Files arbetsbelastningar. Om en zon blir otillgänglig krävs ingen återmontering av Azure-filresurser från de anslutna klienterna.

Följande diagram visar hur dina data replikeras mellan tillgänglighetszoner i den primära regionen med ZRS:

Diagram som visar hur data replikeras i den primära regionen med ZRS

ZRS ger utmärkt prestanda, låg svarstid och återhämtning för dina data om de blir tillfälligt otillgängliga. ZRS i sig kanske dock inte skyddar dina data mot en regional katastrof där flera zoner påverkas permanent. För skydd mot regionala katastrofer rekommenderar Microsoft att du använder geozonredundant lagring (GZRS), som använder ZRS i den primära regionen och även geo-replikerar dina data till en sekundär region.

Arkivnivån för Blob Storage stöds för närvarande inte för ZRS-, GZRS- eller RA-GZRS-konton. Ohanterade diskar stöder inte ZRS eller GZRS.

Mer information om vilka regioner som stöder ZRS finns i Azure-regioner med tillgänglighetszoner.

Standardlagringskonton

ZRS stöds för alla Azure Storage-tjänster via standardlagringskonton för generell användning v2, inklusive:

  • Azure Blob Storage (frekvent och lågfrekvent blockblobb och tilläggsblobar, sidblobar som inte är diskar)
  • Azure Files (alla standardnivåer: transaktionsoptimerad, frekvent och lågfrekvent)
  • Azure Table Storage
  • Azure Queue Storage

ZRS för standardlagringskonton för generell användning v2 är tillgängligt för en delmängd av Azure-regioner:

  • (Afrika) Sydafrika, norra
  • (Asien och stillahavsområdet) Australien, östra
  • (Asien och stillahavsområdet) Indien, centrala
  • (Asien och stillahavsområdet) Asien, östra
  • (Asien och stillahavsområdet) Japan, östra
  • (Asien och stillahavsområdet) Sydkorea, centrala
  • (Asien och stillahavsområdet) Sydostasien
  • (Europa) Frankrike, centrala
  • (Europa) Tyskland, västra centrala
  • (Europa) Europa, norra
  • (Europa) Norge, östra
  • (Europa) Sverige, centrala
  • (Europa) Schweiz, norra
  • (Europa) Storbritannien, södra
  • (Europa) Europa, västra
  • (Nordamerika) Kanada, centrala
  • (Nordamerika) USA, centrala
  • (Nordamerika) USA, östra
  • (Nordamerika) USA, östra 2
  • (Nordamerika) USA, södra centrala
  • (Nordamerika) US Gov, Virginia
  • (Nordamerika) USA, västra 2
  • (Nordamerika) USA, västra 3
  • (Sydamerika) Brasilien, södra

Premium-blockblobkonton

ZRS stöds för premium-blockblobbkonton. Mer information om Premium-blockblobar finns i Premium blockbloblagringskonton.

Premium-blockblobar är tillgängliga i en delmängd av Azure-regioner:

  • (Asien och stillahavsområdet) Australien, östra
  • (Asien och stillahavsområdet) Asien, östra
  • (Asien och stillahavsområdet) Japan, östra
  • (Asien och stillahavsområdet) Sydostasien
  • (Europa) Frankrike, centrala
  • (Europa) Europa, norra
  • (Europa) Europa, västra
  • (Europa) Storbritannien, södra
  • (Nordamerika) USA, östra
  • (Nordamerika) USA, östra 2
  • (Nordamerika) USA, västra 2
  • (Nordamerika) USA, södra centrala
  • (Sydamerika) Brasilien, södra

Premium-filresurskonton

ZRS stöds för Premium-filresurser (Azure Files) via lagringskontotypenFileStorage.

ZRS för Premium-filresurser är tillgängligt för en delmängd av Azure-regioner:

  • (Asien och stillahavsområdet) Australien, östra
  • (Asien och stillahavsområdet) Japan, östra
  • (Asien och stillahavsområdet) Sydostasien
  • (Asien och stillahavsområdet) Sydkorea, centrala
  • (Europa) Frankrike, centrala
  • (Europa) Europa, norra
  • (Europa) Europa, västra
  • (Europa) Storbritannien, södra
  • (Mellanöstern) Qatar, centrala
  • (Nordamerika) USA, östra
  • (Nordamerika) USA, östra 2
  • (Nordamerika) USA, västra 2
  • (Nordamerika) USA, södra centrala
  • (Sydamerika) Brasilien, södra

Redundans i en sekundär region

För program som kräver hög hållbarhet kan du välja att kopiera data i ditt lagringskonto till en sekundär region som ligger hundratals mil från den primära regionen. Om ditt lagringskonto kopieras till en sekundär region är dina data hållbara även vid ett fullständigt regionalt avbrott eller en katastrof där den primära regionen inte kan återställas.

När du skapar ett lagringskonto väljer du kontots primära region. Den kopplade sekundära regionen bestäms baserat på den primära regionen och kan inte ändras. Mer information om regioner som stöds av Azure finns i Azure-regioner.

Azure Storage erbjuder två alternativ för att kopiera data till en sekundär region:

  • Geo-redundant lagring (GRS) kopierar dina data synkront tre gånger inom en enda fysisk plats i den primära regionen med hjälp av LRS. Därefter kopieras dina data asynkront till en enda fysisk plats i den sekundära regionen. I den sekundära regionen kopieras dina data synkront tre gånger med hjälp av LRS.
  • Geozonredundant lagring (GZRS) kopierar dina data synkront över tre Azure-tillgänglighetszoner i den primära regionen med ZRS. Därefter kopieras dina data asynkront till en enda fysisk plats i den sekundära regionen. I den sekundära regionen kopieras dina data synkront tre gånger med hjälp av LRS.

Anteckning

Den främsta skillnaden mellan GRS och GZRS är hur data replikeras i den primära regionen. Inom den sekundära regionen replikeras data alltid synkront tre gånger med hjälp av LRS. LRS i den sekundära regionen skyddar dina data mot maskinvarufel.

Med GRS eller GZRS är data i den sekundära regionen inte tillgängliga för läs- eller skrivåtkomst om det inte sker en redundansväxling till den sekundära regionen. För läsåtkomst till den sekundära regionen konfigurerar du lagringskontot så att det använder geo-redundant lagring med läsbehörighet (RA-GRS) eller geozonredundant lagring med läsbehörighet (RA-GZRS). Mer information finns i Läs åtkomst till data i den sekundära regionen.

Om den primära regionen blir otillgänglig kan du välja att redundansväxla till den sekundära regionen. När redundansväxlingen har slutförts blir den sekundära regionen den primära regionen och du kan läsa och skriva data igen. Mer information om haveriberedskap och information om hur du redundansväxlar till den sekundära regionen finns i Haveriberedskap och redundansväxling av lagringskonto.

Viktigt

Eftersom data replikeras till den sekundära regionen asynkront kan ett fel som påverkar den primära regionen leda till dataförlust om den primära regionen inte kan återställas. Intervallet mellan de senaste skrivningar till den primära regionen och den senaste skrivningen till den sekundära regionen kallas för mål för återställningspunkt (RPO). RPO anger den tidpunkt till vilken data kan återställas. Azure Storage-plattformen har vanligtvis ett återställningspunktmål på mindre än 15 minuter, även om det för närvarande inte finns något serviceavtal om hur lång tid det tar att replikera data till den sekundära regionen.

Geo-redundant lagring

Geo-redundant lagring (GRS) kopierar dina data synkront tre gånger inom en enda fysisk plats i den primära regionen med hjälp av LRS. Sedan kopieras dina data asynkront till en enda fysisk plats i en sekundär region som ligger hundratals mil från den primära regionen. GRS erbjuder hållbarhet för lagringsresurser på minst 99,999999999999999 % (16 nior) under ett visst år.

En skrivåtgärd checkas först in på den primära platsen och replikeras med hjälp av LRS. Uppdateringen replikeras sedan asynkront till den sekundära regionen. När data skrivs till den sekundära platsen replikeras de också på den platsen med hjälp av LRS.

Följande diagram visar hur dina data replikeras med GRS eller RA-GRS:

Diagram som visar hur data replikeras med GRS eller RA-GRS

Geografiskt zonredundant lagring

Geo-zonredundant lagring (GZRS) kombinerar den höga tillgängligheten som tillhandahålls av redundans mellan tillgänglighetszoner med skydd mot regionala avbrott som tillhandahålls av geo-replikering. Data i ett GZRS-lagringskonto kopieras till tre Azure-tillgänglighetszoner i den primära regionen och replikeras också till en sekundär geografisk region för skydd mot regionala katastrofer. Microsoft rekommenderar att du använder GZRS för program som kräver maximal konsekvens, hållbarhet och tillgänglighet, utmärkta prestanda och återhämtning vid haveriberedskap.

Med ett GZRS-lagringskonto kan du fortsätta att läsa och skriva data om en tillgänglighetszon blir otillgänglig eller inte kan återställas. Dessutom är dina data också hållbara vid ett fullständigt regionalt avbrott eller en katastrof där den primära regionen inte kan återställas. GZRS är utformat för att ge minst 99,99999999999999% (16 nior) hållbarhet för objekt under ett visst år.

Följande diagram visar hur dina data replikeras med GZRS eller RA-GZRS:

Diagram som visar hur data replikeras med GZRS eller RA-GZRS

Endast standardlagringskonton för generell användning v2 stöder GZRS. GZRS stöds av alla Azure Storage-tjänster, inklusive:

  • Azure Blob Storage (frekventa och lågfrekventa blockblobar, sidblobar som inte är diskar)
  • Azure Files (alla standardnivåer: transaktionsoptimerad, frekvent och lågfrekvent)
  • Azure Table Storage
  • Azure Queue Storage

GZRS är tillgängligt för en delmängd av Azure-regioner:

  • (Afrika) Sydafrika, norra
  • (Asien och stillahavsområdet) Australien, östra
  • (Asien och stillahavsområdet) Asien, östra
  • (Asien och stillahavsområdet) Japan, östra
  • (Asien och stillahavsområdet) Sydkorea, centrala
  • (Asien och stillahavsområdet) Sydostasien
  • (Asien och stillahavsområdet) Indien, centrala
  • (Europa) Frankrike, centrala
  • (Europa) Tyskland, västra centrala
  • (Europa) Europa, norra
  • (Europa) Norge, östra
  • (Europa) Sverige, centrala
  • (Europa) Schweiz, norra
  • (Europa) Storbritannien, södra
  • (Europa) Europa, västra
  • (Nordamerika) Kanada, centrala
  • (Nordamerika) USA, centrala
  • (Nordamerika) USA, östra
  • (Nordamerika) USA, östra 2
  • (Nordamerika) USA, södra centrala
  • (Nordamerika) USA, västra 2
  • (Nordamerika) USA, västra 3
  • (Nordamerika) US Gov Virginia
  • (Sydamerika) Brasilien, södra

Läsa åtkomst till data i den sekundära regionen

Geo-redundant lagring (med GRS eller GZRS) replikerar dina data till en annan fysisk plats i den sekundära regionen för att skydda mot regionala avbrott. Med ett konto konfigurerat för GRS eller GZRS är data i den sekundära regionen inte direkt tillgängliga för användare eller program, såvida inte en redundansväxling sker. Redundansväxlingen uppdaterar DNS-posten som tillhandahålls av Azure Storage så att den sekundära slutpunkten blir den nya primära slutpunkten för ditt lagringskonto. Under redundansväxlingen är dina data otillgängliga. När redundansväxlingen är klar kan du läsa och skriva data till den nya primära regionen. Mer information om redundans och haveriberedskap finns i Så här fungerar redundansväxling för ett konto.

Om dina program kräver hög tillgänglighet kan du konfigurera ditt lagringskonto för läsåtkomst till den sekundära regionen. När du aktiverar läsåtkomst till den sekundära regionen är dina data alltid tillgängliga för läsning från den sekundära, även i en situation där den primära regionen blir otillgänglig. Geo-redundant lagring med läsåtkomst (RA-GRS) eller ra-GZRS-konfigurationer (read-access geo-zone-redundant storage) tillåter läsåtkomst till den sekundära regionen.

Varning

Eftersom data replikeras asynkront från den primära till den sekundära regionen ligger den sekundära regionen vanligtvis bakom den primära regionen när det gäller skrivåtgärder. Om en katastrof skulle drabba den primära regionen är det troligt att vissa data skulle gå förlorade. Mer information om hur du planerar för potentiell dataförlust finns i Förutse dataförlust.

Anteckning

Azure Files stöder inte geo-redundant lagring med läsåtkomst (RA-GRS) eller geo-zonredundant lagring med läsåtkomst (RA-GZRS).

Utforma dina program för läsåtkomst till den sekundära

Om ditt lagringskonto har konfigurerats för läsåtkomst till den sekundära regionen kan du utforma dina program så att de smidigt övergår till att läsa data från den sekundära regionen om den primära regionen blir otillgänglig av någon anledning.

Den sekundära regionen är tillgänglig för läsåtkomst när du har aktiverat RA-GRS eller RA-GZRS, så att du kan testa ditt program i förväg för att kontrollera att det kommer att läsas korrekt från den sekundära i händelse av ett avbrott. Mer information om hur du utformar dina program för att dra nytta av geo-redundans finns i Använda geo-redundans för att utforma program med hög tillgänglighet.

När läsåtkomst till den sekundära är aktiverad kan ditt program läsas från den sekundära slutpunkten samt från den primära slutpunkten. Den sekundära slutpunkten lägger till suffixet – sekundärt till kontonamnet. Om din primära slutpunkt för Blob Storage till exempel är myaccount.blob.core.windows.netär myaccount-secondary.blob.core.windows.netden sekundära slutpunkten . Kontoåtkomstnycklarna för ditt lagringskonto är desamma för både de primära och sekundära slutpunkterna.

Kontrollera egenskapen Tidpunkt för senaste synkronisering

Eftersom data replikeras till den sekundära regionen asynkront ligger den sekundära regionen ofta bakom den primära regionen. Om ett fel inträffar i den primära regionen är det troligt att alla skrivningar till den primära ännu inte har replikerats till den sekundära.

För att avgöra vilka skrivåtgärder som har replikerats till den sekundära regionen kan ditt program kontrollera egenskapen Senaste synkroniseringstid för ditt lagringskonto. Alla skrivåtgärder som skrivits till den primära regionen före den senaste synkroniseringstiden har replikerats till den sekundära regionen, vilket innebär att de är tillgängliga för läsning från den sekundära. Skrivåtgärder som skrivs till den primära regionen efter den senaste synkroniseringstiden kan ha replikerats till den sekundära regionen, vilket innebär att de kanske inte är tillgängliga för läsåtgärder.

Du kan fråga värdet för egenskapen Last Sync Time med hjälp av Azure PowerShell, Azure CLI eller något av Azure Storage-klientbiblioteken. Egenskapen Last Sync Time är ett GMT-datum/tid-värde. Mer information finns i Kontrollera egenskapen Senaste synkroniseringstid för ett lagringskonto.

Sammanfattning av redundansalternativ

Tabellerna i följande avsnitt sammanfattar de redundansalternativ som är tillgängliga för Azure Storage.

Parametrar för hållbarhet och tillgänglighet

I följande tabell beskrivs nyckelparametrar för varje redundansalternativ:

Parameter LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Procent hållbarhet för objekt under ett visst år minst 99,9999999999 % (11 9) minst 99,99999999999 % (12 9) minst 99,999999999999999999 % (16 9) minst 99,999999999999999999 % (16 9)
Tillgänglighet för läsbegäranden Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) för GRS

Minst 99,99 % (99,9 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) för RA-GRS
Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) för GZRS

Minst 99,99 % (99,9 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) för RA-GZRS
Tillgänglighet för skrivbegäranden Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer) Minst 99,9 % (99 % för lågfrekvent åtkomstnivå eller arkivåtkomstnivåer)
Antal kopior av data som underhålls på separata noder Tre kopior inom en enda region Tre kopior över separata tillgänglighetszoner i en enda region Sex kopior totalt, varav tre i den primära regionen och tre i den sekundära regionen Totalt sex kopior, inklusive tre över separata tillgänglighetszoner i den primära regionen och tre lokalt redundanta kopior i den sekundära regionen

Mer information finns i serviceavtalet för lagringskonton.

Hållbarhet och tillgänglighet efter avbrottsscenario

Följande tabell anger om dina data är varaktiga och tillgängliga i ett visst scenario, beroende på vilken typ av redundans som gäller för ditt lagringskonto:

Avbrottsscenario LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
En nod i ett datacenter blir otillgänglig Ja Ja Ja Ja
Ett helt datacenter (zonindelat eller icke-zonindelat) blir otillgängligt Inga Ja Ja1 Yes
Ett regionomfattande avbrott inträffar i den primära regionen Inga Inga Ja1 Ja1
Läsåtkomst till den sekundära regionen är tillgänglig om den primära regionen blir otillgänglig Inga Inga Ja (med RA-GRS) Ja (med RA-GZRS)

1 Kontoredundans krävs för att återställa skrivtillgängligheten om den primära regionen blir otillgänglig. Mer information finns i Haveriberedskap och redundans för lagringskonto.

Azure Storage-tjänster som stöds

Följande tabell visar vilka redundansalternativ som stöds av varje Azure Storage-tjänst.

LRS ZRS GRS RA-GRS GZRS RA-GZRS
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1,2
Azure-hanterade diskar
Sidblobar
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1,2
Azure-hanterade diskar3
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1
Bloblagring (inklusive Data Lake Storage)
Queue Storage
Table Storage

1 Standardfilresurser stöds på LRS och ZRS. Standardfilresurser stöds på GRS och GZRS så länge de är mindre än eller lika med 5 TiB i storlek.
2 Premium-filresurser stöds på LRS och ZRS.
3 ZRS-hanterade diskar har vissa begränsningar. Mer information finns i avsnittet Begränsningar i redundansalternativen för hanterade diskar.

Lagringskontotyper som stöds

I följande tabell visas vilka redundansalternativ som stöds för varje typ av lagringskonto. Information om lagringskontotyper finns i Översikt över lagringskonto.

Lagringskontotyper LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Rekommenderas Standard generell användning v2 (StorageV2)1

Premium-blockblobar (BlockBlobStorage)1

Premium-filresurser (FileStorage)

Premium-sidblobar (StorageV2)
Standard generell användning v2 (StorageV2)1

Premium-blockblobar (BlockBlobStorage)1

Premium-filresurser (FileStorage)
Standard generell användning v2 (StorageV2)1 Standard generell användning v2 (StorageV2)1
Legacy Standard generell användning v1 (Storage)

Äldre blob (BlobStorage)
Ej tillämpligt Standard generell användning v1 (Storage)

Äldre blob (BlobStorage)
Ej tillämpligt

1 Konton av den här typen med ett hierarkiskt namnområde aktiverat stöder också det angivna redundansalternativet.

Alla data för alla lagringskonton kopieras från den primära till den sekundära enligt redundansalternativet för lagringskontot. Objekt som blockblobar, tilläggsblobar, sidblobar, köer, tabeller och filer kopieras.

Data på alla nivåer, inklusive arkivnivån, kopieras alltid från den primära till den sekundära under geo-replikering. Arkivnivån för Blob Storage stöds för närvarande för LRS-, GRS- och RA-GRS-konton, men inte för ZRS-, GZRS- eller RA-GZRS-konton. Mer information om blobnivåer finns i Frekvent, Lågfrekvent och Arkiv-åtkomstnivåer för blobdata.

Ohanterade diskar stöder inte ZRS eller GZRS.

Prisinformation för varje redundansalternativ finns i Prissättning för Azure Storage.

Anteckning

Azure Premium Disk Storage stöder för närvarande endast lokalt redundant lagring (LRS). Blockbloblagringskonton stöder lokalt redundant lagring (LRS) och zonredundant lagring (ZRS) i vissa regioner.

Support för redundansväxling av kundhanterade konton

Alla geo-redundanta erbjudanden stöder Microsoft-hanterad redundans vid en katastrof i den primära regionen. Dessutom stöder vissa kontotyper redundansväxling av kundhanterade konton, enligt följande tabell. Kontotyper som stöds måste använda Azure Resource Manager-distributioner. Mer information om haveriberedskap och kundhanterad redundans finns i Haveriberedskap och redundans för lagringskonto.

Typ av redundans GRS/RA-GRS GZRS/RA-GZRS
Kundhanterad redundans Allmänna v2-konton
Allmänna v1-konton
Äldre Blob Storage-konton
General-purpose v2-konton (GPv2)
Microsoft-hanterad redundans Alla kontotyper General-purpose v2-konton (GPv2)

Anteckning

Redundansväxling av kundhanterade konton stöds ännu inte i konton som har ett hierarkiskt namnområde (Azure Data Lake Storage Gen2). Mer information finns i Blob Storage-funktioner som är tillgängliga i Azure Data Lake Storage Gen2.

I händelse av en katastrof som påverkar den primära regionen hanterar Microsoft redundansväxlingen för konton med ett hierarkiskt namnområde. Mer information finns i Microsoft-hanterad redundans.

Dataintegritet

Azure Storage verifierar regelbundet integriteten för data som lagras med hjälp av cykliska redundanskontroller (CRC). Om skadade data identifieras repareras de med hjälp av redundanta data. Azure Storage beräknar även kontrollsummor på all nätverkstrafik för att identifiera skadade datapaket när data lagras eller hämtas.

Se även