Planera för en Azure Files-distribution

Artikel
03/06/2024

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 för premiumfilresurser Betala per användning för standardfilresurser	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: Åtgärder på `FileService` Åtgärder på `FileShares` Åtgärder på `Directories` Åtgärder på `Files`
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-portalen, 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-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 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å för SMB-filresurser 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 från januari 2021 och framåt, och vi rekommenderar att du lämnar det på för de flesta SMB-filresurser. 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. Mjuk borttagning fungerar inte för NFS-resurser, även om det är aktiverat för lagringskontot.

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-portalen, via PowerShell eller kommandoradsgränssnittet (CLI), eller så kan du 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-portalen 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 och HDD, som gör att du kan skräddarsy dina resurser efter prestanda- och priskraven i ditt scenario:

SSD (Premium): Premium-filresurser som används av SSD:er (Solid State Drives) och ger konsekventa höga prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för IO-intensiva arbetsbelastningar. Premium-filresurser är lämpliga för en mängd olika arbetsbelastningar som databaser, webbplatsvärdar och utvecklingsmiljöer. Premium-filresurser kan användas med protokollen Server Message Block (SMB) och Network File System (NFS). Premium-filresurser distribueras i fillagringskontotypen och är endast tillgängliga i en etablerad faktureringsmodell. Mer information om den etablerade faktureringsmodellen för premiumfilresurser finns i Förstå etablering för premiumfilresurser. Premium-filresurser erbjuder ett serviceavtal med högre tillgänglighet än standardfilresurser (se "Azure Files Premium-nivå").
HDD (Standard): Standardfilresurser använder hårddiskar (HDD) och tillhandahåller ett kostnadseffektivt lagringsalternativ för allmänna filresurser. Standardfilresurser distribueras i lagringskontotypen generell användning version 2 (GPv2). Information om serviceavtalet finns på sidan med Serviceavtal på Azure (se "Lagringskonton"). Standardfilresurser använder en betala per användning-modell som tillhandahåller användningsbaserad prissättning. Med åtkomstnivån för en filresurs kan du justera lagringskostnaderna mot IOPS-kostnaden för att optimera din totala faktura:
- Transaktionsoptimerade filresurser erbjuder den lägsta kostnaden för transaktionsintensiva arbetsbelastningar som inte behöver den låga svarstid som erbjuds av Premium-filresurser. Rekommenderas vid migrering av data till Azure Files.
- Frekventa filresurser erbjuder balanserad lagring och transaktionspriser för arbetsbelastningar som har ett bra mått på båda.
- Lågfrekventa filresurser erbjuder de mest kostnadseffektiva lagringspriser för lagringsintensiva arbetsbelastningar.

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 premiumnivån förmodligen bäst. Om låg svarstid inte är lika mycket ett problem, till exempel med teamresurser monterade lokalt från Azure eller cachelagrade lokalt med Azure File Sync, kan standardlagring passa bättre ur ett kostnadsperspektiv.

När du har skapat en filresurs i ett lagringskonto kan du inte flytta den till nivåer som är exklusiva för olika typer av lagringskonton. Om du till exempel vill flytta en transaktionsoptimerad filresurs till premiumnivån måste du skapa en ny filresurs i ett FileStorage-lagringskonto och kopiera data från din ursprungliga resurs 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 .

Begränsningar

För närvarande har standardfilresurser med stora filresurser aktiverade (upp till 100 TiB-kapacitet) vissa begränsningar.

Endast lokalt redundant lagring (LRS) och ZRS-konton (zonredundant lagring) stöds.
När du aktiverar stora filresurser på ett lagringskonto kan du inte konvertera lagringskontot till att använda geo-redundant lagring (GRS) eller geo-zonredundant lagring (GZRS).
När du har aktiverat stora filresurser kan du inte inaktivera det.

Om du vill använda GRS eller GZRS med standard-SMB Azure-filresurser läser du Geo-redundans för Azure Files för förhandsversion av stora filresurser.

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.