Planera för en Azure Files-distribution

Att planera en Azure Files-distribution innebär några viktiga beslut. Använd den här artikeln för att välja rätt alternativ för din arbetsbelastning.

Du behöver bestämma följande:

  1. Hur kommer kunderna att få tillgång till andelen? Montera direkt från moln- eller lokala klienter, eller cache lokalt med Azure File Sync?
  2. Vilken förvaltningsmodell? Klassiska filresurser (lagringskonton) eller den nya resursprovidern Microsoft.FileShares?
  3. Vilket protokoll?SMB (Windows/Linux/macOS) eller NFS (endast Linux)?
  4. Hur kommer användarna att autentisera sig?Identitetsbaserad autentisering eller lagringskontonyckel?
  5. Vilken nätverkskonfiguration? Offentlig slutpunkt, tjänstslutpunkter eller privata slutpunkter?
  6. Vilken prestandanivå och redundansalternativ?SSD eller HDD, och vilket redundansalternativ?

Följande avsnitt täcker varje beslut i detalj.

Tip

Om du planerar att använda Azure File Sync, se Plan for a Azure File Sync-installation istället.

Hanteringsbegrepp

Azure Files erbjuder två hanteringsmodeller för att distribuera fildelningar:

  • Klassiska fildelningar (Microsoft. Lagringsresursleverantör): Distribuera fildelningar inom ett lagringskonto. Stöder SMB och NFS, SSD och HDD, alla redundanstyper och alla regioner.
  • Fildelningar (Microsoft. FileShares-resursleverantör): Distribuera fildelningar som toppnivå Azure-resurser utan lagringskonto. Förenkla hanteringen med nätverk, fakturering och säkerhet per resursdelning. För närvarande endast tillgängligt för NFS-fildelningar.

För detaljer om resursleverantörer, funktionsjämförelser och regional tillgänglighet, se Azure Files managementkoncept.

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). Välj 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 tusentals klienter kan komma åt dem samtidigt.

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 medienivå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 Windows delningsläge 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 Ja (Microsoft.Storage endast)
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
Filsystemtransaktioner (TxF) Stöds inte Ej tillämpligt

Identitet

För att få åtkomst till en Azure filresurs måste du autentiseras och ha behörighet att komma åt resursen. I nästan alla fall använder du identitetsbaserad autentisering i stället för lagringskontonyckeln för att få åtkomst till SMB-Azure filresurser.

Azure Files stöder följande autentiseringsmetoder för SMB-resurser:

  • Lokal Doménové služby Active Directory (AD DS): Du kan domänansluta Azure lagringskonton till en kundägd Doménové služby Active Directory, precis som en Windows Server filserver eller NAS-enhet. Du kan distribuera en domänkontrollant lokalt, på en Azure virtuell dator eller till och med som en virtuell dator i en annan molnleverantör. Azure Files är oberoende av var domänkontrollanten finns. Efter att du domänanslutit ett lagringskonto kan slutanvändaren montera en fildelning med det användarkonto 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 du kan använda 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 Domain Services tillhandahåller AD-baserad autentisering använder det här alternativet även Kerberos-autentiseringsprotokollet.
  • Microsoft Entra Kerberos: med Microsoft Entra Kerberos kan du använda Microsoft Entra ID för att autentisera hybrid eller molnbaserade identiteter. Den här konfigurationen använder Microsoft Entra ID för att utfärda Kerberos-biljetter för att komma åt fildelningen med SMB-protokollet. Det innebär att slutanvändarna kan komma åt Azure filresurser via Internet från Microsoft Entra hybridanslutna och Microsoft Entra anslutna virtuella datorer.
  • služba 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 AD DS eller Microsoft Entra Domain Services.
  • Azure lagringskontonyckel: Ä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. Om du vill montera en filresurs med hjälp av lagringskontonyckeln använder du lagringskontots namn som användarnamn och lagringskontonyckeln som lösenord. Att använda lagringskontonyckeln för att montera Azure filresurs ä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 ACL:er. När du använder lagringskontonyckeln för att montera över SMB används NTLMv2-autentiseringsprotokollet. Om du måste använda lagringskontonyckeln använder du 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 Server filservrar eller NAS-enheter kan domänen ansluta ditt lagringskonto till den kundägda AD DS. Mer information finns i Overview – lokal AD DS-autentisering via SMB för Azure filresurser.

Nätverk

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

  • Många organisationer och Internetleverantörer blockerar port 445, som SMB-filresurser använder för kommunikation, 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.

Överväg 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 protokoll som krävs är SMB och åtkomsten kommer från klienter lokalt krävs en VPN- eller Azure ExpressRoute-anslutning från lokalt till ditt Azure nätverk, där Azure Files exponeras 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 zonfel, 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 finns i Azure Files nätverksöverväganden.

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 direkt stöder SMB över QUIC, kan du skapa en lättviktig cache av dina Azure fildelningar på en Windows Server 2022 Azure Edition VM genom att använda Azure File Sync. För att lära dig mer om detta alternativ, se SMB över QUIC med Azure File Sync.

Kryptering för Azure Files

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

  • Kryptering under överföring, som relaterar till krypteringen som används vid montering eller åtkomst till Azure filresurs
  • 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. Den här funktionen 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 filresurs om kryptering under överföring är aktiverat. Mer information om vilka operativsystem som stöder SMB 3.x med kryptering finns i dokumentationen 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 du inaktiverar kryptering 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 den Azure regionen för Azure filresurs, till exempel lokalt eller i en annan Azure region, kan inte komma åt filresursen.

Se till 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-lagringen och kryptering under överföring för NFS Azure-fildelningar.

Kryptering i vila

Azure Files använder samma krypteringsschema som de andra Azure lagringstjänster, till exempel Azure Blob Storage. Alla data som lagras i Azure Files krypteras i vila via kryptering på tjänstsidan (SSE), som fungerar på samma sätt som BitLocker på Windows.

Eftersom data krypteras under Azure filresursens filsystem, eftersom de är kodade till disken, behöver du inte å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 innehåller Microsoft nycklarna för att kryptera och dekryptera data. Microsoft ansvarar för att rotera dessa nycklar regelbundet.

För Azure klassiska fillagringar kan du välja att kryptera dina data med hjälp av kundhanterade nycklar. Om du väljer 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 utan den här auktoriseringen är din Azure filresurs inte längre tillgänglig via SMB eller FileREST-API:et.

Du kan inte använda kundhanterade nycklar för kryptering i vila med Azure-filresurser som skapats med resursprovidern Microsoft.FileShares. Du måste använda Microsoft-hanterade nycklar.

Dataskydd

Azure Files använder 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 Azure Files dataskyddsöversikt.

Mjuk borttagning

Mjuk borttagning är en inställning på lagringskontonivå som du kan använda för att återställa filresursen när den tas bort av misstag. När du tar bort en fildelning övergår den till ett tillstånd för mjuk borttagning 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 ange en kort kvarhållningsperiod eller inte aktivera mjuk borttagning.

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

Säkerhetskopiering

Säkerhetskopiera dina Azure-filresurser med hjälp av ögonblicksbilder av filresurser, som är skrivskyddade kopior av filresursen från en viss tidpunkt. Ögonblicksbilder är inkrementella, så de innehåller bara data som har ändrats sedan den föregående ögonblicksbilden. Varje filresurs har stöd för upp till 200 ögonblicksbilder och du kan behålla dem i upp till 10 år. Du kan skapa ögonblicksbilder manuellt i Azure-portalen eller använda PowerShell eller kommandoradsgränssnittet (CLI). Du kan också använda Azure Backup.

Azure Backup för SMB 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 samordnar även aktiveringen av mjuk borttagning och tar ett borttagningslås på ett lagringskonto så snart en filresurs i den har konfigurerats för säkerhetskopiering. Azure Backup tillhandahåller 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. Välj återställningspunkten (en viss snapshot), den specifika filen eller katalogen om det är relevant, och sedan platsen (original eller alternativ) 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 för 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 för Storage identifierar känd skadlig kod, till exempel utpressningstrojaner, 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 för Storage har inte åtkomst till lagringskontodata och påverkar inte dess prestanda. Du kan aktivera Microsoft Defender för lagring på prenumerationsnivå (rekommenderas) eller resursnivå.

Lagringsnivåer

Azure Files erbjuder två medienivåer för lagring: SSD (Solid State Disk) och hårddisk (HDD). Med de här nivåerna kan du anpassa dina resurser efter prestanda- och priskraven i ditt scenario:

När du väljer en medienivå för din arbetsbelastning bör du överväga 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 lika mycket ett problem kan HDD-filresurser passa bättre ur ett kostnadsperspektiv. Låg svarstid kan till exempel vara mindre av ett problem med teamdelningar som monterade lokalt från Azure eller cachelagrades lokalt via Azure File Sync.

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.

Du hittar mer information om SSD- och HDD-medienivåerna i Understand Azure Files faktureringsmodeller och Förstå och optimera Azure filresursprestanda.

Redundans

För att skydda data i 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 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 lagringskluster. Den här metoden hjälper till att skydda 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 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 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 dataspridningen mellan de två Azure regionerna. Om en större katastrof inträffar, 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 och hanterar 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 om ett större haveri inträffar. Du kan också utföra en manuell överflyttning av ett geo-redundant lagringskonto.

  • Geo-zonredundant lagring (GZRS): Med geo-zonredundans 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 geo-zonredundans fungerar på samma sätt som för geo-redundans.

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

Lagringskonton med betalning per användning ger två andra redundansalternativ som Azure Files inte stöder: geo-redundant lagring med läsåtkomst (RA-GRS) och geo-zonredundant lagring med läsåtkomst (RA-GZRS). Du kan etablera Azure fillagringar 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-redundanta respektive geo-zonredundanta.

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 mängd av Azure regioner.

Haveriberedskap och redundans

Vid ett oplanerat regionalt tjänststopp bör du ha en haveriberedskapsplan (DR) på plats för dina Azure filresurser. För att förstå de koncept och processer som är involverade i återställning efter katastrof och failover av DR och lagringskonton, se Katastrofåterställning och failover 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 är viktigt för att migreringen ska lyckas.

Information om SMB-migreringar finns i Översikt över SMB-migrering som innehåller en tabell som leder dig till migreringsguider som sannolikt täcker ditt scenario.

Information om NFS-migreringar finns i Migrera till NFS Azure filresurser.

Nästa steg