Planera för distribution av Azure Files

Azure Files kan distribueras på två huvudsakliga sätt: genom att direkt montera de serverlösa Azure-filresurser eller genom att cachelagra Azure-filresurser lokalt med hjälp av Azure File Sync. Vilket distributionsalternativ du väljer ändrar vad du behöver tänka på när du planerar för distributionen.

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

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

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

Tillgängliga protokoll

Azure Files två branschstandardprotokoll för montering av Azure-filresurs: SMB-protokollet (Server Message Block) och NFS-protokollet (Network File System). Azure Files kan du välja det filsystemprotokoll 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 efter dina lagringsbehov och kan användas samtidigt av tusentals klienter.

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 det lagringskontot. Information om aktuella begränsningar för lagringskontot finns Azure Files för skalbarhet och prestanda.

Det finns två huvudsakliga typer av lagringskonton som du använder för Azure Files distributioner:

• GPv2-lagringskonton för generell användning version 2 (GPv2): Med GPv2-lagringskonton kan du distribuera Azure-filresurser på standard-/hårddiskbaserad (HDD-baserad) maskinvara. 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-/solid state-diskbaserad (SSD-baserad) maskinvara. 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 lagringskonto som du kan stöta på Azure Portal, PowerShell eller CLI. Två lagringskontotyper, BlockBlobStorage- och BlobStorage-konton, får inte innehålla Azure-filresurser. De andra två lagringskontotyperna som du kan se är generell användning version 1 (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 funktioner 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 att du 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-konton gör att du kan ha blandade lagringskonton, eftersom lagringsresurser som Azure-filresurser och blobcontainrar delar lagringskontots gränser kan det vara svårare att felsöka prestandaproblem senare om du blandar resurser.

• Var uppmärksam på IOPS-begränsningarna för ett lagringskonto när du distribuerar Azure-filresurser. Vi rekommenderar att du mappar filresurser 1:1 med lagringskonton, men det kanske inte alltid är möjligt på grund av olika 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 i ett lagringskonto bör du överväga vilka resurser som är mycket aktiva och vilka resurser som är mindre aktiva för att säkerställa att de hetsade filresurser inte placeras i samma lagringskonto tillsammans.

• Distribuera endast 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 den användare som har åtkomst till filresursen. Azure Files integreras med tre huvudsakliga identitetsproviders:

• Lokal Active Directory Domain Services (AD DS eller lokal AD DS): Azure Storage-konton kan vara domänägda till en kundägd Active Directory Domain 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 agnostisk för den plats där domänkontrollanten finns. När ett lagringskonto är domänmedlem kan slutanvändaren montera en filresurs med det användarkonto som användaren är inloggad på datorn med. AD-baserad autentisering använder Kerberos-autentiseringsprotokollet.
• Azure Active Directory Domain Services (Azure AD DS): Azure AD DS tillhandahåller en Microsoft-hanterad domänkontrollant som kan användas för Azure-resurser. Domän som ansluter ditt lagringskonto till Azure AD DS ger liknande fördelar som att ansluta det till en kundägd Active Directory. Det här distributionsalternativet är mest användbart för lift and shift-scenarier för program som kräver AD-baserade behörigheter. Eftersom Azure AD DS ad-baserad autentisering använder det här alternativet även Kerberos-autentiseringsprotokollet.
• Nyckel för Azure-lagringskonto: Azure-filresurser kan också monteras med en Azure-lagringskontonyckel. 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 praktiken 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 åtkomstkontrollistor. När du använder lagringskontonyckeln för att montera över SMB används NTLMv2-autentiseringsprotokollet.

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änsefogning av ditt lagringskonto till kundägd Active Directory det rekommenderade alternativet. Mer information om hur du ansluter ditt lagringskonto till ett kundägt Active Directory finns i Azure Files Active Directory-översikt.

Om du tänker använda lagringskontonyckeln för att få åtkomst till dina Azure-filresurser rekommenderar vi att du använder tjänstslutpunkter enligt beskrivningen i avsnittet Nätverk.

Nätverk

Azure-filresurser är tillgängliga var som helst via lagringskontots offentliga slutpunkt. Det innebär att autentiserade begäranden, till exempel begäranden som auktoriserats av en användares inloggningsidentitet, kan komma inifrån eller utanför Azure på ett säkert sätt. I många kundmiljöer misslyckas en inledande montering av Azure-filresursen på din lokala arbetsstation, även om monteringar från virtuella Azure-datorer lyckas. Orsaken till detta är att många organisationer och Internetleverantörer blockerar porten som SMB använder för att kommunicera, port 445. En översikt över Internetleverantörer som tillåter och inte tillåter åtkomst från port 445 finns på TechNet.

Du har två huvudalternativ för att avblockera åtkomsten till din Azure-filresurs:

• Avblockera port 445 för organisationens lokala nätverk. Azure-filresurser kan endast nås externt via den offentliga slutpunkten med hjälp av internetsäkra protokoll som SMB 3.x och FileREST API. Det här är det enklaste sättet att komma åt din Azure-filresurs från en lokal plats eftersom det inte krävs avancerad nätverkskonfiguration utöver att ändra organisationens regler för utgående portar, men vi rekommenderar att du tar bort äldre och föråldrade versioner av SMB-protokollet, nämligen SMB 1.0. Information om hur du gör detta finns i Skydda Windows/Windows Server och Skydda Linux.

• Få åtkomst till Azure-filresurser via en ExpressRoute- eller VPN-anslutning. När du kommer åt din Azure-filresurs via en nätverkstunnel kan du montera din Azure-filresurs som en lokal filresurs eftersom SMB-trafiken inte passerar organisationens gränser.

Även om det ur ett tekniskt perspektiv är betydligt enklare att montera dina Azure-filresurser via den offentliga slutpunkten förväntar vi oss att de flesta kunder väljer att montera sina Azure-filresurser via en ExpressRoute- eller VPN-anslutning. Montering med dessa alternativ är möjligt med både SMB- och NFS-resurser. Om du vill göra detta måste du konfigurera följande för din miljö:

• Nätverkstunnlar med ExpressRoute, plats-till-plats eller punkt-till-plats-VPN: Tunneltrafik till ett virtuellt nätverk tillåter åtkomst till Azure-filresurser från en lokal plats, även om port 445 är blockerad.
• Privata slutpunkter: Privata slutpunkter ger ditt lagringskonto en dedikerad IP-adress inifrån det virtuella nätverkets adressutrymme. Detta möjliggör nätverkstunnlar utan att behöva öppna lokala nätverk upp till alla IP-adressintervall som ägs av Azure Storage-klustren.
• DNS-vidarebefordran: Konfigurera din lokala DNS för att matcha namnet på ditt lagringskonto ( för de offentliga molnregionerna) för att matcha ip-adressen för dina storageaccount.file.core.windows.net privata slutpunkter.

Information om hur du planerar för nätverk som är associerade med att distribuera en Azure-filresurs finns i Azure Files nätverksöverväganden.

Kryptering

Azure Files stöder två olika typer av kryptering: kryptering under överföring, som relaterar till den kryptering som används vid montering/åtkomst till Azure-filresursen och kryptering i vila, som relaterar till hur data krypteras när de lagras på disk.

Kryptering under ö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 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 kommer inte att kunna montera Azure-filresursen om kryptering under överföring har aktiverats. Mer information om vilka operativsystem som stöder SMB 3.x med kryptering finns i vår detaljerade dokumentation för Windows, macOSoch Linux. Alla aktuella versioner av PowerShell, CLI och SDK:er stöder HTTPS.

Du kan inaktivera kryptering under överföring för ett Azure Storage-konto. När kryptering har inaktiverats Azure Files även SMB 2.1, SMB 3.x utan kryptering och okrypterade FileREST API-anrop via HTTP. Den främsta anledningen 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 ä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, kan inte komma åt filresursen.

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

Mer information om kryptering under överföring finns i kräva säker överföring i Azure Storage.

Vilande kryptering

Alla data som lagras i Azure Files krypteras i vila med hjälp av Azure Storage Service Encryption (SSE). Kryptering av lagrings tjänst fungerar på samma sätt som BitLocker i Windows: data krypteras under fil system nivå. Eftersom data krypteras under fil systemet i Azure-filresursen, eftersom de är kodade till disk, 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 både SMB-och NFS-protokollen.

Som standard krypteras data som lagras i Azure Files med Microsoft-hanterade nycklar. Med Microsoft-hanterade nycklar innehåller Microsoft nycklar 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 rotations processen. Om du väljer att kryptera dina fil resurser med Kundhanterade nycklar har Azure Files behörighet att få åtkomst till dina nycklar för att uppfylla Läs-och skriv förfrågningar från dina klienter. Med Kundhanterade nycklar kan du återkalla den här behörigheten när som helst, men det innebär att Azure-filresursen inte längre kan nås via SMB eller det fileraste API: et.

Azure Files använder samma krypterings schema som de andra Azure Storage-tjänsterna, till exempel Azure Blob Storage. Om du vill veta mer om Azure Storage Service Encryption (SSE) kan du läsa mer i Azure Storage-kryptering för data i vila.

Dataskydd

Azure Files har en metod med flera lager för att se till att dina data säkerhetskopieras, återställs och skyddas mot säkerhetshot.

Mjuk borttagning

Mjuk borttagning för filresurser ä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 borttagna tillstånd i stället för att raderas permanent. Du kan konfigurera hur lång tid mjukt borttagna data ska kunna återställas innan de tas bort permanent, och ångra borttagningen av resursen när som helst under den här kvarhållningsperioden.

Vi rekommenderar att du slår på mjuk borttagning för de flesta filresurser. Om du har ett arbetsflöde där borttagning av resurs är vanligt och förväntat kan du välja att ha en kort kvarhållningsperiod eller inte ha mjuk borttagning aktiverat alls.

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

Backup

Du kan säkerhetskopiera Din Azure-filresurs viaögonblicksbilder av resurser, som är skrivskyddade kopior av resursen vid en tidpunkt. Ö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 manuellt ta dessa ögonblicksbilder i Azure Portal, via PowerShell eller kommandoradsgränssnittet (CLI), eller så kan du använda Azure Backup. Ögonblicksbilder lagras i filresursen, vilket innebär att dina ögonblicksbilder också tas bort om du tar bort filresursen. Om du vill skydda säkerhetskopior av ögonblicksbilder från oavsiktlig borttagning ser du till att mjuk borttagning är aktiverat för resursen.

Azure Backup för Azure-filresurser hanterar schemaläggning och kvarhållning av ögonblicksbilder. Dess gfs-son-funktioner innebär att du kan ta ögonblicksbilder varje dag, vecka, månad och år, var och en med sin egen distinkta kvarhållningsperiod. Azure Backup också aktivera mjuk borttagning och tar ett borttagningslås på ett lagringskonto så snart en filresurs i det har konfigurerats för säkerhetskopiering. Slutligen innehåller Azure Backup vissa funktioner för nyckelövervakning och avisering som gör det möjligt för kunder att ha en samlad vy över sin säkerhetskopieringse egendom.

Du kan utföra återställningar på både objektnivå och resursnivå i Azure Portal med 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 (ursprunglig eller alternativ) som du vill återställa till. Säkerhetskopieringstjänsten hanterar kopiering av ögonblicksbilddata över och visar återställningsförloppet i portalen.

Mer information om säkerhetskopiering finns i Om säkerhetskopiering av Azure-filresurs.

Skydda Azure Files med Microsoft Defender för Storage

Microsoft Defender for Storage tillhandahåller ytterligare ett lager med säkerhetsinformation som genererar aviseringar när den identifierar avvikande aktivitet på ditt lagringskonto, till exempel ovanliga åtkomstförsök. Den kör också analys av hash-rykte för skadlig kod och varnar om känd skadlig kod. Du kan konfigurera Microsoft Defender för Storage på prenumerations- eller lagringskontonivå via Microsoft Defender för molnet.

Mer information finns i Introduktion till Microsoft Defender för Storage.

Lagringsnivåer

Azure Files erbjuder fyra olika nivåer av lagring, premium, transaktionsoptimerad, varm och cool så att du kan skräddarsy dina resurser efter prestanda- och priskraven för ditt scenario:

• Premium: Premium-filresurser backas upp av SSD-enheter (Solid State Drives) och 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. Premium-filresurser är lämpliga för en mängd olika arbetsbelastningar som databaser, värdtjänster för webbplatser och utvecklingsmiljöer. Premium-filresurser kan användas med både Server Message Block (SMB) och NFS-protokoll (Network File System).
• Transaktionsoptimerad: Transaktionsoptimerade filresurser möjliggör transaktionsintensiva arbetsbelastningar som inte behöver den svarstid som erbjuds av premiumfilresurser. Transaktionsoptimerade filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar (HDD). Transaktionsoptimerad har tidigare kallats "standard", men detta avser lagringsmedietypen snarare än själva nivån (den heta och den coola är också "standard"-nivåer, eftersom de finns på standardlagringsmaskinvara).
• Hot: Heta filresurser erbjuder lagring som är optimerad för allmänna fildelningsscenarier, till exempel gruppresurser. Heta filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar.
• Låg cool: Lågeffektiva filresurser erbjuder kostnadseffektiv lagring som är optimerad för scenarier med arkivlagring online. Coola filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar.

Premium-filresurser distribueras i typen FileStorage-lagringskonto 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. Standardfilresurser, inklusive transaktionsoptimerade, heta och coola filresurser, distribueras i lagringskontotyp för generell användning version 2 (GPv2) och är tillgängliga via betala per användning-fakturering.

När du väljer en lagringsnivå 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, är premiumnivån förmodligen den bästa. Om låg latens inte är lika stort, till exempel när teamresurser är monterade lokalt från Azure eller cachelagras 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 lagringskonto. 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 för rsync macOS och Linux.

Filresurser som distribueras i GPv2-konton kan flyttas mellan standardnivåer (transaktionsoptimerade, heta och coola) utan att skapa ett nytt lagringskonto och migrera data, men du kommer att dra på dig transaktionskostnader när du ändrar din nivå. När du flyttar en resurs från en lägre nivå till en kallare nivå debiteras du den kallare nivåns transaktionskostnad för skrivtransaktioner för varje fil i resursen. Om du flyttar en filresurs från en kallare nivå till en lägre nivå debiteras den lägre nivåns transaktionskostnad för läsning för varje fil i resursen.

Se Förstå Azure Files fakturering för mer information.

Begränsningar

Standard fil resurser med 100 TiB-kapacitet har vissa begränsningar.

• För närvarande stöds endast lokalt redundant lagring (LRS) och ZRS-konton (Zone redundant Storage).
• När du aktiverar stora fil resurser kan du inte konvertera lagrings konton till GRS-(Geo-redundant lagring) eller GZRS-konton (geo-Zone-redundant lagring).
• När du har aktiverat stora fil resurser kan du inte inaktivera den.

Redundans

För att skydda data i dina Azure-filresurser mot dataförlust eller skadade data lagrar alla Azure-filresurser flera kopior av varje fil när de skrivs. Beroende på kraven för din arbetsbelastning kan du välja ytterligare grader av redundans. 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-lagringskluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof som brand eller översvämningar 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, men dessa kopior är fysiskt isolerade i tre olika 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änglighetszoner.
• Geo-redundant lagring (GRS): Med GRS har du två regioner, en primär och en sekundär region. Filer lagras tre gånger i ett Azure Storage-kluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS innehåller sex kopior av dina data som är fördelade 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 redundans, och den sekundära blir 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 har replikerats till den sekundära regionen förlorade i händelse av en större katastrof. Du kan också utföra en manuell redundans för ett geo-redundant lagringskonto.
• Geo-zonredundant lagring (GZRS): Du kan tänka på GZRS som om det vore som ZRS men med geo-redundans. Med GZRS lagras filer tre gånger över tre olika lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansprocessen för GZRS fungerar på samma sätt som GRS.

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

GPv2-lagringskonton (General purpose version 2) ger två ytterligare redundansalternativ som inte stöds av Azure Files: lästillgänglig geo-redundant lagring, som ofta kallas RA-GRS, och lästillgänglig geo-zonredundant lagring, vilket ofta kallas RA-GZRS. Du kan etablera Azure-filresurser i lagringskonton med dessa alternativ inställda, Azure Files inte stöder läsning från den sekundära regionen. Azure-filresurser som distribueras till lästillgängliga geo- eller geozonredundant lagringskonton debiteras som geo-redundant eller geo-zonredundant lagring.

Migrering

I många fall kommer du inte att upprätta en ny nettofilresurs 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.

Artikeln om migreringsöversikt beskriver kortfattat grunderna och innehåller en tabell som leder dig till migreringsguider som troligen täcker ditt scenario.

Nästa steg

• Planera för en Azure File Sync distribution
• Distribuera Azure Files
• Distribuera Azure File Sync
• Läs artikeln migreringsöversikt för att hitta migreringsguiden för ditt scenario