Planera att distribuera Azure Files

2025-05-04

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-fildelningar är serverlösa, kräver distribution i 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-fildelning på plats med Azure File Sync: Med Azure File Sync kan du centralisera organisationens fildelningar 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.

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.

Funktionalitet	små och medelstora företag	NFS (Network File System)
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	SSD och HDD	Endast SSD
Redundans	Lokalt (LRS) Zon (ZRS) Geo (GRS) GeoZone (GZRS)	Lokalt (LRS) Zon (ZRS)
Filsystemssemantik	Win32	POSIX
Autentisering	Identitetsbaserad autentisering (Kerberos), autentisering med delad nyckel (NTLMv2)	Värdbaserad autentisering
Auktorisering	Åtkomstkontrollistor i stil med Win32 (ACL:er)	UNIX-stil behörigheter
Skiftlägeskänslighet	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	Byteintervall-rådgivande nätverkslåshanterare
Stöd för hårdlänk	Stöds inte	Stödd
Stöd för symbolisk länk	Stöds inte	Stödd
Internetåtkomst är valfri	Ja (endast SMB 3.0+	Nej
Stödjer FileREST	Ja	Delmängd: Åtgärder på `FileService` Åtgärder på `FileShares` Åtgärder på `Directories` Åtgärder på `Files`
Obligatoriska byteintervalllås	Stödd	Stöds inte
Rådgivande byteintervalllås	Stöds inte	Stödd
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-leasning av katalogtjänster	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. Lagringskonton kan användas för att distribuera flera filresurser samt andra lagringsresurser beroende på lagringskontotyp. 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 används för Azure Files-distributioner:

Etablerade lagringskonton: Etablerade lagringskonton särskiljs med lagringskontots FileStorage typ. Med etablerade lagringskonton kan du distribuera etablerade filresurser på antingen SSD- eller HDD-baserad maskinvara. Tilldelade lagringskonton kan bara användas för att lagra Azure-fildelningar. NFS-filresurser kan bara distribueras i etablerade lagringskonton på SSD-medienivån. Vi rekommenderar att du använder etablerade lagringskonton för alla nya distributioner av Azure Files.
Betala per användning-lagringskonton: Betala per användning-lagringskonton särskiljs med lagringskontots StorageV2 typ. Med betala per användning-lagringskonton kan du distribuera betala per användning-filresurser på HDD-baserad maskinvara. Förutom att lagra Azure-filresurser kan GPv2-lagringskonton lagra andra lagringsresurser, till exempel blobcontainrar, köer eller tabeller.

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 anslutet till domänen kan slutanvändaren montera en fildelning 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 fildelningen 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: Även om det inte rekommenderas av säkerhetsskäl kan du även montera Azure-filresurser med hjälp av en Azure-lagringskontonyckel i stället för att använda en identitet. För att montera en filresurs med hjälp av lagringskontonyckeln, används lagringskontonamnet som användarnamn och lagringskontonyckeln 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. I nästan alla fall rekommenderar vi att du använder identitetsbaserad autentisering i stället för lagringskontonyckeln för att få åtkomst till SMB Azure-filresurser. Men om du måste använda lagringskontonyckeln 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 fungera som Windows-filservrar eller NAS-enheter rekommenderar vi att domänen ansluter ditt lagringskonto till kundägd AD DS . 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 direkt montera din Azure-fildelning kräver ofta en viss övervägande av 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-fildelning 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å fildelningen skulle klienten kräva en återanslutning av delningen.

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

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-portalen, 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 kryptering är inaktiverat 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.

Säkerhetskopiering

Du kan säkerhetskopiera din Azure-fildelning via fildelningsögonblicksbilder, som är skrivskyddade, ögonblicksbaserade kopior av din delning. Ö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-fildelningar ger konsekvent hög prestanda och låg latens inom ensiffriga millisekunder för de flesta I/O-åtgärder vid I/O-intensiva arbetsbelastningar. SSD-fildelningar är lämpliga för en mängd olika arbetsbelastningar som databaser, webbhotell och utvecklingsmiljöer. SSD-fildelningar kan användas med både Server Message Block (SMB) och Network File System (NFS)-protokoll. SSD-filresurser är tillgängliga i den tilldelade v1-faktureringsmodellen. SSD-filresurser erbjuder ett serviceavtal med högre tillgänglighet än HDD-filresurser (se "Azure Files Premium-nivå").
HDD (standard): HDD-fildelningar ger ett kostnadseffektivt lagringsalternativ för allmänt bruk. HDD-fillagringsresurser som är tillgängliga med de etablerade v2 och faktureringsmodellerna för betala per användning, även om vi rekommenderar den etablerade v2-modellen för nya fillagringsimplementeringar. 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 den nya filresursen. Se migrera filer från en filresurs till en annan

Mer information om medienivåerna SSD och HDD finns i Förstå Azure Files-fakturering och Förstå Azure Files-prestanda.

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 lokal redundans 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 zonredundans 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 skrivoperation till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszonerna.
Geo-redundant lagring (GRS): Med geo-redundans 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. Geo-redundans ger sex kopior av dina data spridda mellan två Azure-regioner. Om en större katastrof inträffar, till exempel permanent förlust av en Azure-region på grund av en naturkatastrof eller en annan liknande händelse, utför Microsoft en redundansväxling. I det här fallet förvandlas den sekundära till den primära, som betjänar alla operationer. Eftersom replikeringen mellan de primära och sekundära regionerna är asynkron går data som ännu inte replikerats till den sekundära regionen förlorade om en större katastrof inträffar. Du kan också utföra en manuell överflyttning av ett geo-redundant lagringskonto.
Geo-zonredundant lagring (GZRS): Med GeoZone-redundans lagras filer tre gånger över tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansväxlingsprocessen för GeoZone-redundans fungerar på samma sätt som geo-redundans.

HDD-filresurser stöder alla fyra redundanstyper. SSD-fildelningar stöder endast LRS och ZRS.

Betala per användning-lagringskonton ger 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 Geo- respektive GeoZone.

Mer information om redundans finns i Azure Files-dataredundans.

Tillgänglighet för zonredundanta SSD-filresurser

Zonredundanta SSD-filresurser är tillgängliga 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. För att förstå begrepp och processer som rör katastrofåterställning och redundansväxling av lagringskonton, se 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.

Dela via