Dela via

Planera att distribuera Azure Files

  • Artikel

Du kan distribuera Azure Files på två huvudsakliga sätt: genom att montera de serverlösa Azure-filresurserna direkt eller genom att cachelagra Azure-filresurser lokalt med Hjälp av Azure File Sync. Distributionsöverväganden skiljer sig åt beroende på vilket alternativ du väljer.

  • Direkt montering av en Azure-filresurs: Eftersom Azure Files ger antingen åtkomst till Server Message Block (SMB) eller NFS (Network File System) kan du montera Azure-filresurser lokalt eller i molnet med hjälp av standard-SMB- eller NFS-klienterna som är tillgängliga i operativsystemet. Eftersom Azure-filresurser är serverlösa kräver distribution för produktionsscenarier inte någon filserver eller NAS-enhet. Det innebär att du inte behöver tillämpa programkorrigeringar eller byta ut fysiska diskar.

  • Cachelagra Azure-filresurs lokalt med Azure File Sync: Med Azure File Sync kan du centralisera organisationens filresurser i Azure Files, samtidigt som du behåller flexibiliteten, prestandan och kompatibiliteten hos en lokal filserver. Azure File Sync omvandlar en lokal (eller molnbaserad) Windows Server till en snabb cache för din SMB Azure-filresurs.

Den här artikeln tar främst upp distributionsöverväganden för att distribuera en Azure-filresurs som ska monteras direkt av en lokal klient eller molnklient. Information om hur du planerar för en Azure File Sync-distribution finns i Planera för en Azure File Sync-distribution.

Tillgängliga protokoll

Azure Files erbjuder två branschstandardfilsystemprotokoll för montering av Azure-filresurser: SMB-protokollet (Server Message Block) och NFS-protokollet (Network File System), så att du kan välja det protokoll som passar bäst för din arbetsbelastning. Azure-filresurser stöder inte både SMB- och NFS-protokollen på samma filresurs, även om du kan skapa SMB- och NFS Azure-filresurser inom samma lagringskonto. NFS 4.1 stöds för närvarande endast inom den nya lagringskontotypen FileStorage (endast premiumfilresurser).

Med både SMB- och NFS-filresurser erbjuder Azure Files filresurser i företagsklass som kan skalas upp för att uppfylla dina lagringsbehov och som kan nås samtidigt av tusentals klienter.

Funktion SMB NFS
Protokollversioner som stöds SMB 3.1.1, SMB 3.0, SMB 2.1 NFS 4.1
Rekommenderat operativsystem
  • Windows 11, version 21H2+
  • Windows 10, version 21H1+
  • Windows Server 2019+
  • Linux-kernelversion 5.3+
 Linux-kernelversion 4.3+
Tillgängliga nivåer Premium, transaktionsoptimerad, frekvent och lågfrekvent Premium
Faktureringsmodell Etablerad kapacitet
Azure DNS-zonslutpunkter (förhandsversion) Stöds Stöds
Redundans LRS, ZRS, GRS, GZRS LRS, ZRS
Filsystemssemantik Win32 POSIX
Autentisering Identitetsbaserad autentisering (Kerberos), autentisering med delad nyckel (NTLMv2) Värdbaserad autentisering
Auktorisering Åtkomstkontrollistor i Win32-stil (ACL: er) UNIX-behörigheter
Skiftlägeskänslig Skiftlägesokänsligt, skiftlägesbevarande Skiftlägeskänsligt
Ta bort eller ändra öppna filer Endast med lås Ja
Fildelning Delningsläge för Windows Byte-range advisory network lock manager
Stöd för hårdlänk Stöds inte Stöds
Stöd för symbolisk länk Stöds inte Stöds
Du kan också komma åt Internet Ja (endast SMB 3.0+ Nej
Stöder FileREST Ja Delmängd:
Obligatoriska byteintervalllås Stöds Stöds inte
Rådgivande byteintervalllås Stöds inte Stöds
Utökade/namngivna attribut Stöds inte Stöds inte
Alternativa dataströmmar Stöds inte Ej tillämpligt
Objektidentifierare Stöds inte Ej tillämpligt
Referenspunkter Stöds inte Ej tillämpligt
Glesa filer Stöds inte Ej tillämpligt
Komprimering Stöds inte Ej tillämpligt
Namngivna rör Stöds inte Ej tillämpligt
SMB Direct Stöds inte Ej tillämpligt
SMB-Directory-uthyrning Stöds inte Ej tillämpligt
Volym skuggkopia Stöds inte Ej tillämpligt
Korta filnamn (8,3 alias ) Stöds inte Ej tillämpligt
Servertjänst Stöds inte Ej tillämpligt
Filsystemtransaktioner (TxF) Stöds inte Ej tillämpligt

Hanteringsbegrepp

Azure-filresurser distribueras till lagringskonton, som är objekt på den översta nivån som representerar en delad lagringspool. Den här lagringspoolen kan användas för att distribuera flera filresurser, samt andra lagringsresurser som blobcontainrar, köer eller tabeller. Alla lagringsresurser som distribueras till ett lagringskonto delar de gränser som gäller för lagringskontot. Aktuella lagringskontobegränsningar finns i Skalbarhets- och prestandamål för Azure Files.

Det finns två huvudsakliga typer av lagringskonton som du kommer att använda för Azure Files-distributioner:

  • GPv2-lagringskonton (GPv2) för generell användning: Med GPv2-lagringskonton kan du distribuera Azure-filresurser på standard-/hårddiskbaserad maskinvara (HDD-baserad). Förutom att lagra Azure-filresurser kan GPv2-lagringskonton lagra andra lagringsresurser, till exempel blobcontainrar, köer eller tabeller.
  • FileStorage-lagringskonton: Med FileStorage-lagringskonton kan du distribuera Azure-filresurser på premium-/SSD-baserad maskinvara (SSD-baserad). FileStorage-konton kan bara användas för att lagra Azure-filresurser. inga andra lagringsresurser (blobcontainrar, köer, tabeller osv.) kan distribueras i ett FileStorage-konto. Endast FileStorage-konton kan distribuera både SMB- och NFS-filresurser.

Det finns flera andra typer av lagringskonton som du kan stöta på i Azure Portal, PowerShell eller CLI. Två lagringskontotyper, BlockBlobStorage- och BlobStorage-lagringskonton, får inte innehålla Azure-filresurser. De andra två lagringskontotyperna som du kan se är version 1 av generell användning (GPv1) och klassiska lagringskonton, som båda kan innehålla Azure-filresurser. Även om GPv1- och klassiska lagringskonton kan innehålla Azure-filresurser är de flesta nya funktionerna i Azure Files endast tillgängliga i GPv2- och FileStorage-lagringskonton. Därför rekommenderar vi att du endast använder GPv2- och FileStorage-lagringskonton för nya distributioner och uppgraderaR GPv1- och klassiska lagringskonton om de redan finns i din miljö.

När du distribuerar Azure-filresurser till lagringskonton rekommenderar vi:

  • Distribuera endast Azure-filresurser till lagringskonton med andra Azure-filresurser. Även om GPv2-lagringskonton gör att du kan ha lagringskonton med blandad användning, eftersom lagringsresurser som Azure-filresurser och blobcontainrar delar lagringskontots gränser, kan det göra det svårare att felsöka prestandaproblem senare.

  • Var uppmärksam på IOPS-begränsningarna för ett lagringskonto när du distribuerar Azure-filresurser. Helst skulle du mappa filresurser 1:1 med lagringskonton. Detta kanske dock inte alltid är möjligt på grund av olika gränser och begränsningar, både från din organisation och från Azure. När det inte är möjligt att bara ha en filresurs distribuerad på ett lagringskonto bör du överväga vilka resurser som ska vara mycket aktiva och vilka resurser som ska vara mindre aktiva för att säkerställa att de hetaste filresurserna inte placeras i samma lagringskonto tillsammans.

  • Distribuera bara GPv2- och FileStorage-konton och uppgradera GPv1- och klassiska lagringskonton när du hittar dem i din miljö.

Identitet

För att få åtkomst till en Azure-filresurs måste användaren av filresursen autentiseras och ha behörighet att komma åt resursen. Detta görs baserat på identiteten för användaren som har åtkomst till filresursen. Azure Files stöder följande autentiseringsmetoder:

  • Lokala Active Directory-domän Services (AD DS eller lokal AD DS): Azure-lagringskonton kan vara domänanslutna till en kundägd Active Directory-domän Services, precis som en Windows Server-filserver eller NAS-enhet. Du kan distribuera en domänkontrollant lokalt, på en virtuell Azure-dator eller till och med som en virtuell dator i en annan molnleverantör. Azure Files är oberoende av var domänkontrollanten finns. När ett lagringskonto är domänanslutet kan slutanvändaren montera en filresurs med det användarkonto som de loggade in på sin dator med. AD-baserad autentisering använder Kerberos-autentiseringsprotokollet.
  • Microsoft Entra Domain Services: Microsoft Entra Domain Services tillhandahåller en Microsoft-hanterad domänkontrollant som kan användas för Azure-resurser. Domän som ansluter ditt lagringskonto till Microsoft Entra Domain Services ger liknande fördelar som domänanslutning till en kundägd AD DS. Det här distributionsalternativet är mest användbart för program lift-and-shift-scenarier som kräver AD-baserade behörigheter. Eftersom Microsoft Entra Domain Services tillhandahåller AD-baserad autentisering använder det här alternativet även Kerberos-autentiseringsprotokollet.
  • Microsoft Entra Kerberos för hybrididentiteter: Med Microsoft Entra Kerberos kan du använda Microsoft Entra-ID för att autentisera hybridanvändaridentiteter, som är lokala AD-identiteter som synkroniseras till molnet. Den här konfigurationen använder Microsoft Entra-ID för att utfärda Kerberos-biljetter för att få åtkomst till filresursen med SMB-protokollet. Det innebär att dina slutanvändare kan komma åt Azure-filresurser via Internet utan att kräva nätverksanslutning till domänkontrollanter från Microsoft Entra-hybridanslutna och Microsoft Entra-anslutna virtuella datorer.
  • Active Directory-autentisering via SMB för Linux-klienter: Azure Files stöder identitetsbaserad autentisering via SMB för Linux-klienter med hjälp av Kerberos-autentiseringsprotokollet via antingen AD DS eller Microsoft Entra Domain Services.
  • Azure Storage-kontonyckel: Azure-filresurser kan också monteras med en Azure Storage-kontonyckel. Om du vill montera en filresurs på det här sättet används lagringskontonamnet som användarnamn och lagringskontonyckeln används som lösenord. Att använda lagringskontonyckeln för att montera Azure-filresursen är i själva verket en administratörsåtgärd, eftersom den monterade filresursen har fullständig behörighet till alla filer och mappar på resursen, även om de har ACL:er. När du använder lagringskontonyckeln för att montera över SMB används NTLMv2-autentiseringsprotokollet. Om du tänker använda lagringskontonyckeln för att komma åt dina Azure-filresurser rekommenderar vi att du använder privata slutpunkter eller tjänstslutpunkter enligt beskrivningen i avsnittet Nätverk .

För kunder som migrerar från lokala filservrar eller skapar nya filresurser i Azure Files som är avsedda att bete sig som Windows-filservrar eller NAS-enheter är domänanslutning till ditt lagringskonto till kundägd AD DS det rekommenderade alternativet. Mer information om domänanslutning till ditt lagringskonto till en kundägd AD DS finns i Översikt – lokal Active Directory Domain Services-autentisering via SMB för Azure-filresurser.

Nätverk

Att montera din Azure-filresurs direkt kräver ofta en viss tanke på nätverkskonfigurationen eftersom:

  • Porten som SMB-filresurser använder för kommunikation, port 445, blockeras ofta av många organisationer och Internetleverantörer för utgående trafik (Internet).
  • NFS-filresurser förlitar sig på autentisering på nätverksnivå och är därför endast tillgängliga via begränsade nätverk. Att använda en NFS-filresurs kräver alltid en viss nivå av nätverkskonfiguration.

För att konfigurera nätverk tillhandahåller Azure Files en internettillgänglig offentlig slutpunkt och integrering med Azure-nätverksfunktioner som tjänstslutpunkter, som hjälper till att begränsa den offentliga slutpunkten till angivna virtuella nätverk och privata slutpunkter, vilket ger ditt lagringskonto en privat IP-adress inifrån ett virtuellt nätverks IP-adressutrymme. Även om det inte tillkommer någon extra kostnad för användning av offentliga slutpunkter eller tjänstslutpunkter, gäller standardpriser för databearbetning för privata slutpunkter.

Det innebär att du måste överväga följande nätverkskonfigurationer:

  • Om det protokoll som krävs är SMB och all åtkomst via SMB kommer från klienter i Azure krävs ingen särskild nätverkskonfiguration.
  • Om det obligatoriska protokollet är SMB och åtkomsten kommer från klienter lokalt, krävs en VPN- eller ExpressRoute-anslutning från lokalt till ditt Azure-nätverk, med Azure Files exponerat i ditt interna nätverk med privata slutpunkter.
  • Om det protokoll som krävs är NFS kan du använda tjänstslutpunkter eller privata slutpunkter för att begränsa nätverket till angivna virtuella nätverk. Om du behöver en statisk IP-adress och/eller om din arbetsbelastning kräver hög tillgänglighet använder du en privat slutpunkt. Med tjänstslutpunkter kan en sällsynt händelse, till exempel ett zonindelad avbrott, göra att lagringskontots underliggande IP-adress ändras. Även om data fortfarande är tillgängliga på filresursen skulle klienten kräva en återmontering av resursen.

Mer information om hur du konfigurerar nätverk för Azure Files finns i Nätverksöverväganden för Azure Files.

Förutom att ansluta direkt till filresursen med hjälp av den offentliga slutpunkten eller använda en VPN/ExpressRoute-anslutning med en privat slutpunkt, tillhandahåller SMB ytterligare en klientåtkomststrategi: SMB över QUIC. SMB over QUIC erbjuder nollkonfiguration "SMB VPN" för SMB-åtkomst via QUIC-transportprotokollet. Även om Azure Files inte har direkt stöd för SMB via QUIC kan du skapa en enkel cache med dina Azure-filresurser på en virtuell Windows Server 2022 Azure Edition-dator med Hjälp av Azure File Sync. Mer information om det här alternativet finns i SMB over QUIC with Azure File Sync (SMB over QUIC with Azure File Sync).

Kryptering

Azure Files stöder två olika typer av kryptering:

  • Kryptering under överföring, som relaterar till krypteringen som används vid montering/åtkomst till Azure-filresursen
  • Kryptering i vila, som relaterar till hur data krypteras när de lagras på disk

Kryptering vid överföring

Viktigt!

Det här avsnittet beskriver kryptering i överföringsinformation för SMB-resurser. Mer information om kryptering under överföring med NFS-resurser finns i Säkerhet och nätverk.

Som standard har alla Azure-lagringskonton kryptering under överföring aktiverat. Det innebär att när du monterar en filresurs via SMB eller kommer åt den via FileREST-protokollet (till exempel via Azure Portal, PowerShell/CLI eller Azure SDK:er) tillåter Azure Files endast anslutningen om den görs med SMB 3.x med kryptering eller HTTPS. Klienter som inte stöder SMB 3.x eller klienter som stöder SMB 3.x men inte SMB-kryptering kan inte montera Azure-filresursen om kryptering under överföring är aktiverat. Mer information om vilka operativsystem som stöder SMB 3.x med kryptering finns i vår dokumentation för Windows, macOS och Linux. Alla aktuella versioner av PowerShell, CLI och SDK:er stöder HTTPS.

Du kan inaktivera kryptering under överföring för ett Azure-lagringskonto. När krypteringen är inaktiverad tillåter Azure Files även SMB 2.1 och SMB 3.x utan kryptering och okrypterade FileREST API-anrop via HTTP. Den främsta orsaken till att inaktivera kryptering under överföring är att stödja ett äldre program som måste köras på ett äldre operativsystem, till exempel Windows Server 2008 R2 eller en äldre Linux-distribution. Azure Files tillåter endast SMB 2.1-anslutningar inom samma Azure-region som Azure-filresursen. en SMB 2.1-klient utanför Azure-regionen för Azure-filresursen, till exempel lokalt eller i en annan Azure-region, kommer inte att kunna komma åt filresursen.

Vi rekommenderar starkt att kryptering av data under överföring är aktiverat.

Mer information om kryptering under överföring finns i krav på säker överföring i Azure Storage.

Kryptering i vila

Alla data som lagras i Azure Files krypteras i vila med azure storage service encryption (SSE). Kryptering av lagringstjänst fungerar på samma sätt som BitLocker i Windows: data krypteras under filsystemnivån. Eftersom data krypteras under Azure-filresursens filsystem, eftersom de är kodade till disken, behöver du inte ha åtkomst till den underliggande nyckeln på klienten för att läsa eller skriva till Azure-filresursen. Kryptering i vila gäller för både SMB- och NFS-protokollen.

Som standard krypteras data som lagras i Azure Files med Microsoft-hanterade nycklar. Med Microsoft-hanterade nycklar har Microsoft nycklarna för att kryptera/dekryptera data och ansvarar för att rotera dem regelbundet. Du kan också välja att hantera dina egna nycklar, vilket ger dig kontroll över rotationsprocessen. Om du väljer att kryptera dina filresurser med kundhanterade nycklar har Azure Files behörighet att komma åt dina nycklar för att uppfylla läs- och skrivbegäranden från dina klienter. Med kundhanterade nycklar kan du återkalla den här auktoriseringen när som helst, men det innebär att din Azure-filresurs inte längre är tillgänglig via SMB eller FileREST-API:et.

Azure Files använder samma krypteringsschema som de andra Azure Storage-tjänsterna, till exempel Azure Blob Storage. Mer information om Azure Storage Service Encryption (SSE) finns i Azure Storage-kryptering för vilande data.

Dataskydd

Azure Files har en metod med flera lager för att säkerställa att dina data säkerhetskopieras, kan återställas och skyddas mot säkerhetshot. Se Översikt över Azure Files-dataskydd.

Mjuk borttagning

Mjuk borttagning är en inställning på lagringskontonivå som gör att du kan återställa filresursen när den tas bort av misstag. När en filresurs tas bort övergår den till ett mjukt borttaget tillstånd i stället för att raderas permanent. Du kan konfigurera hur lång tid mjuka borttagna resurser kan återställas innan de tas bort permanent och ta bort resursen när som helst under kvarhållningsperioden.

Mjuk borttagning är aktiverat som standard för nya lagringskonton. Om du har ett arbetsflöde där borttagning av resurser är vanligt och förväntat kan du välja att ha en kort kvarhållningsperiod eller inte ha mjuk borttagning aktiverad alls.

Mer information om mjuk borttagning finns i Förhindra oavsiktlig borttagning av data.

Backup

Du kan säkerhetskopiera din Azure-filresurs via resursögonblicksbilder, som är skrivskyddade kopior av din resurs. Ögonblicksbilder är inkrementella, vilket innebär att de bara innehåller så mycket data som har ändrats sedan den föregående ögonblicksbilden. Du kan ha upp till 200 ögonblicksbilder per filresurs och behålla dem i upp till 10 år. Du kan antingen ta ögonblicksbilder manuellt i Azure Portal, via PowerShell eller kommandoradsgränssnittet (CLI) eller använda Azure Backup.

Azure Backup för Azure-filresurser hanterar schemaläggning och kvarhållning av ögonblicksbilder. Dess funktioner för farfar-far-son (GFS) innebär att du kan ta ögonblicksbilder dagligen, varje vecka, varje månad och varje år, var och en med sin egen distinkta kvarhållningsperiod. Azure Backup orkestrerar också aktiveringen av mjuk borttagning och tar ett borttagningslås på ett lagringskonto så snart en filresurs i den har konfigurerats för säkerhetskopiering. Slutligen tillhandahåller Azure Backup vissa viktiga funktioner för övervakning och aviseringar som gör det möjligt för kunder att ha en samlad vy över sin säkerhetskopieringsegendom.

Du kan utföra både återställningar på objektnivå och resursnivå i Azure Portal med hjälp av Azure Backup. Allt du behöver göra är att välja återställningspunkten (en viss ögonblicksbild), den specifika filen eller katalogen om det är relevant och sedan den plats (original eller alternativ) som du vill återställa till. Säkerhetskopieringstjänsten hanterar kopiering av ögonblicksbilddata över och visar återställningsstatusen i portalen.

Skydda Azure Files med Microsoft Defender för Lagring

Microsoft Defender för Storage är ett Azure-inbyggt lager av säkerhetsinformation som identifierar potentiella hot mot dina lagringskonton. Den ger omfattande säkerhet genom att analysera telemetrin för dataplanet och kontrollplanet som genereras av Azure Files. Den använder avancerade funktioner för hotidentifiering som drivs av Microsoft Threat Intelligence för att tillhandahålla kontextuella säkerhetsaviseringar, inklusive steg för att minimera de identifierade hoten och förhindra framtida attacker.

Defender for Storage analyserar kontinuerligt telemetriströmmen som genereras av Azure Files. När potentiellt skadliga aktiviteter identifieras genereras säkerhetsaviseringar. Dessa aviseringar visas i Microsoft Defender för molnet, tillsammans med information om misstänkt aktivitet, undersökningssteg, reparationsåtgärder och säkerhetsrekommendationer.

Defender for Storage identifierar känd skadlig kod, till exempel utpressningstrojan, virus, spionprogram och annan skadlig kod som laddats upp till ett lagringskonto baserat på fullständig filhash (stöds endast för REST API). Detta förhindrar att skadlig kod kommer in i organisationen och sprids till fler användare och resurser. Se Förstå skillnaderna mellan sökning efter skadlig kod och hash-ryktesanalys.

Defender for Storage har inte åtkomst till lagringskontodata och påverkar inte dess prestanda. Du kan aktivera Microsoft Defender för Lagring på prenumerationsnivå (rekommenderas) eller på resursnivå.

Lagringsnivåer

Azure Files erbjuder två olika medienivåer för lagring, SSD (solid state-diskar) och HDD (hårddiskar), som gör att du kan skräddarsy dina resurser efter prestanda- och priskraven i ditt scenario:

  • SSD (premium): SSD-filresurser ger konsekvent hög prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för I/O-intensiva arbetsbelastningar. SSD-filresurser är lämpliga för en mängd olika arbetsbelastningar som databaser, webbplatsvärdar och utvecklingsmiljöer. SSD-filresurser kan användas med både SMB-protokoll (Server Message Block) och NFS(Network File System). SSD-filresurser är tillgängliga i den etablerade v1-faktureringsmodellen . SSD-filresurser erbjuder ett serviceavtal med högre tillgänglighet än HDD-filresurser (se "Azure Files Premium-nivå").

  • HDD (standard): HDD-filresurser ger ett kostnadseffektivt lagringsalternativ för allmänna filresurser. HDD-filresurser som är tillgängliga med de etablerade v2 - och betala per användning-faktureringsmodellerna , även om vi rekommenderar den etablerade v2-modellen för nya filresursdistributioner. Information om serviceavtalet finns på sidan med Serviceavtal på Azure (se "Lagringskonton").

När du väljer en medienivå för din arbetsbelastning bör du tänka på dina prestanda- och användningskrav. Om din arbetsbelastning kräver ensiffrig svarstid, eller om du använder SSD-lagringsmedia lokalt, passar SSD-filresurser förmodligen bäst. Om låg svarstid inte är så mycket av ett problem, till exempel med teamresurser monterade lokalt från Azure eller cachelagrade lokalt med Azure File Sync, kan HDD-filresurser passa bättre ur ett kostnadsperspektiv.

När du har skapat en filresurs i ett lagringskonto kan du inte flytta den direkt till en annan medienivå. Om du till exempel vill flytta en HDD-filresurs till SSD-medienivån måste du skapa en ny SSD-filresurs och kopiera data från den ursprungliga resursen till en ny filresurs i FileStorage-kontot. Vi rekommenderar att du använder AzCopy för att kopiera data mellan Azure-filresurser, men du kan också använda verktyg som robocopy i Windows eller rsync för macOS och Linux.

Mer information finns i Förstå Azure Files-fakturering .

Redundans

För att skydda data i dina Azure-filresurser mot dataförlust eller skada lagrar Azure Files flera kopior av varje fil när de skrivs. Beroende på dina krav kan du välja olika redundansgrader. Azure Files stöder för närvarande följande alternativ för dataredundans:

  • Lokalt redundant lagring (LRS): Med LRS lagras varje fil tre gånger i ett Azure Storage-kluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof, till exempel brand eller översvämning inträffar i datacentret, kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga.
  • Zonredundant lagring (ZRS): Med ZRS lagras tre kopior av varje fil. Dessa kopior är dock fysiskt isolerade i tre distinkta lagringskluster i olika Azure-tillgänglighetszoner. Tillgänglighetszoner är unika fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. En skrivning till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszonerna.
  • Geo-redundant lagring (GRS): Med GRS har du två regioner, en primär region och en sekundär region. Filer lagras tre gånger i ett Azure-lagringskluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS innehåller sex kopior av din dataspridning mellan två Azure-regioner. I händelse av en större katastrof, till exempel permanent förlust av en Azure-region på grund av en naturkatastrof eller någon annan liknande händelse, utför Microsoft en redundansväxling. I det här fallet blir den sekundära den primära, som betjänar alla åtgärder. Eftersom replikeringen mellan de primära och sekundära regionerna är asynkron går data som inte replikerats till den sekundära regionen förlorade i händelse av en större katastrof. Du kan också utföra en manuell redundansväxling av ett geo-redundant lagringskonto.
  • Geo-zonredundant lagring (GZRS): Du kan se GZRS som ZRS, men med geo-redundans. Med GZRS lagras filer tre gånger i tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansväxlingsprocessen för GZRS fungerar på samma sätt som GRS.

Azure-standardfilresurser på upp till 5 TiB stöder alla fyra redundanstyperna. Standardfilresurser som är större än 5 TiB stöder endast LRS och ZRS. Premium Azure-filresurser stöder endast LRS och ZRS.

Lagringskonton för generell användning version 2 (GPv2) tillhandahåller två andra redundansalternativ som Azure Files inte stöder: lästillgänglig geo-redundant lagring (RA-GRS) och lästillgänglig geo-zonredundant lagring (RA-GZRS). Du kan etablera Azure-filresurser i lagringskonton med dessa alternativ inställda, men Azure Files stöder inte läsning från den sekundära regionen. Azure-filresurser som distribueras till RA-GRS- eller RA-GZRS-lagringskonton faktureras som GRS respektive GZRS.

Mer information om redundans finns i Azure Files-dataredundans.

Standard-ZRS-tillgänglighet

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

Premium ZRS-tillgänglighet

ZRS för premiumfilresurser är tillgängligt för en delmängd av Azure-regioner.

Standard GZRS-tillgänglighet

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

Haveriberedskap och redundans

Om det uppstår ett oplanerat avbrott i den regionala tjänsten bör du ha en haveriberedskapsplan (DR) på plats för dina Azure-filresurser. Information om begrepp och processer som ingår i redundansväxling av dr- och lagringskonton finns i Haveriberedskap och redundans för Azure Files.

Migrering

I många fall kommer du inte att upprätta en ny net-filresurs för din organisation, utan i stället migrera en befintlig filresurs från en lokal filserver eller NAS-enhet till Azure Files. Att välja rätt migreringsstrategi och verktyg för ditt scenario är viktigt för att migreringen ska lyckas.

Migreringsöversiktsartikeln beskriver kortfattat grunderna och innehåller en tabell som leder dig till migreringsguider som sannolikt täcker ditt scenario.

Nästa steg