Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Du kan distribuera Azure Files på två huvudsakliga sätt: genom att montera de serverlösa Azure-filresurserna direkt eller genom att cachelagra 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. Du kan antingen välja att använda klassiska Azure-filresurser eller Microsoft.FileShares (förhandsversion) som hanteringsmodell.
Cachelagra Azure-filresurser 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.
Hanteringsbegrepp
I Azure är en resurs ett hanterbart objekt som du skapar och konfigurerar i dina Azure-prenumerationer och resursgrupper. Resurser erbjuds av resursprovidrar, som är hanteringstjänster som levererar specifika typer av resurser. Även om du kan arbeta med många resurser för att distribuera en arbetsbelastning i Azure, fokuserar Azure Files på två viktiga resurser:
Lagringskonton som erbjuds av
Microsoft.Storageresursprovidern. Lagringskonton är resurser på den översta nivån som representerar en delad pool med lagring, IOPS och dataflöde där du kan distribuera klassiska filresurser eller andra lagringsresurser, beroende på typ av lagringskonto. Alla lagringsresurser som distribueras till ett lagringskonto delar de gränser som gäller för lagringskontot. Klassiska filresurser stöder både SMB- och NFS-fildelningsprotokollen.Filresurser (förhandsversion) som erbjuds av
Microsoft.FileSharesresursprovidern. Filresurser är en ny resurs på den översta nivån som förenklar distributionen av Azure Files genom att eliminera lagringskontot. Till skillnad från klassiska filresurser, som måste distribueras till ett lagringskonto, distribueras filresurser direkt till resursgruppen, till exempel själva lagringskonton eller andra Azure-resurser som du kanske är bekant med, till exempel virtuella datorer, diskar eller virtuella nätverk. Filresurser stöder NFS-fildelningsprotokollet – om du behöver SMB väljer du klassiska filresurser för distributionen.
Den här videon ger en omfattande översikt över skillnaderna mellan lagringskontot och hanteringsmodellerna för filresurser:
Klassiska filresurser (Microsoft.Storage)
Klassiska filresurser eller filresurser som distribueras i lagringskonton är det traditionella sättet att distribuera filresurser för Azure Files. De stöder alla viktiga funktioner som Azure Files stöder, inklusive SMB- och NFS-, SSD- och HDD-medienivåer, varje redundanstyp och i varje region. Även om klassiska filresurser stöder hela bredden av Azure Files-funktioner har de viktiga viktiga begränsningar:
Kapacitetsplanering: Klassiska filresurser och underordnade objekt för andra lagringstjänster som blobcontainrar som finns i samma lagringskonto delar en gemensam pool med lagring, IOPS och dataflöde. Det innebär att det krävs planering för att undvika kapacitetsflaskhalsar för att placera flera klassiska filresurser på ett lagringskonto. När du planerar kapacitet för klassiska filresurser måste du överväga både de aktuella och framtida behoven för varje klassisk filresurs som placeras på ett lagringskonto eftersom tillväxten av en klassisk filresurs kan tränga ut andra filresurser.
Delade inställningar: Många viktiga inställningar, till exempel nätverk och säkerhetsregler, tillämpas på lagringskontonivå, så därför måste du noga överväga att placera klassiska filresurser i samma lagringskonto. Du bör betrakta lagringskontot som en förtroendegräns och endast placera klassiska filresurser i samma lagringskonto om du är okej med att de har samma säkerhetsinställningar.
Skalningskomplexitet: Storskaliga distributioner av Azure Files kan kräva hantering av många Azure-prenumerationer på grund av begränsningarna för lagringskonton från
Microsoft.Storageresursprovidern. Mer information finns i begränsningar för lagringskonton .
Det finns två huvudsakliga typer av lagringskonton som används för klassiska filresursdistributioner:
-
Etablerade lagringskonton: Etablerade lagringskonton särskiljs med lagringskontots
FileStoragetyp. Med etablerade lagringskonton kan du distribuera etablerade klassiska filresurser på antingen SSD- eller HDD-baserad maskinvara. Etablerade lagringskonton kan bara användas för att lagra klassiska filresurser och kan inte användas för lagring av andra lagringsresurser, till exempel blobcontainrar, köer och tabeller. Vi rekommenderar att du använder etablerade lagringskonton för alla nya klassiska filresursdistributioner. -
Betala per användning-lagringskonton: Betala per användning-lagringskonton särskiljs med lagringskontots
StorageV2typ. Med betala per användning-lagringskonton kan du distribuera betala per användning-filresurser på HDD-baserad maskinvara. Betala per användning-lagringskonton kan användas för att lagra klassiska filresurser och andra lagringsresurser, till exempel blobcontainrar, köer eller tabeller.
Mer information finns i Skapa en klassisk filresurs.
Filresurser (Microsoft.FileShares)
Filresurser (förhandsversion) är en ny Azure-resurs på den översta nivån som tillhandahålls av Microsoft.FileShares resursprovidern. Filresurser erbjuder följande fördelar jämfört med klassiska filresurser:
Förenklad hantering: Filresurser skapas direkt som resurser på den översta nivån i portalen eller via hanterings-API:er. Detta tar bort kravet på att hantera ett lagringskonto och effektiviserar distributionsupplevelsen.
Oberoende kapacitet och prestanda: Varje filresurs har sin egen dedikerade lagring, IOPS och dataflöde. Detta undviker behovet av kapacitetsplanering mot begränsade resurser för lagringskonton och gör det möjligt för filresurser att växa fritt i takt med att arbetsbelastningskraven ökar.
Detaljerad konfiguration: Nätverks- och säkerhetsinställningar tillämpas på filresursnivå, vilket ger dig exakt kontroll över åtkomstgränser och isolering. Det gör det enklare att tillämpa säkerhetsprinciper för specifika appar, team eller miljöer.
Förutsägbar, flexibel fakturering: Filresurser använder den etablerade v2-faktureringsmodellen, som gör att du oberoende kan etablera lagring, IOPS och dataflöde per resurs. Eftersom faktureringen i Azure görs per azure-resurs på den översta nivån kan du enkelt spåra kostnaderna för varje enskild resurs för kostnadstilldelning tillbaka till projektet, teamet eller kunden som använder filresursen.
Förbättrad skalning och prestanda: Filresurser stöder högre gränser och lägre distributionstider än klassiska filresurser. Mer information finns i Skalbarhets- och prestandamål för Azure Files.
Regional tillgänglighet
För närvarande är det tillgängligt att skapa en filresurs med Microsoft.FileShares (förhandsversion) i följande regioner:
- Australia East
- Australien centrala
- Australia Southeast
- Östasien
- East US
- Tyskland Nord
- Sydkorea
- Sydostasien
- North Europe
- Sydafrika Väst
- South India
- Förenade Arabemiraten Centrala
För närvarande är privat slutpunktsstöd för fildelning med Microsoft.FileShares (förhandsversion) tillgängligt i ett begränsat antal regioner.
- Alla offentliga Azure-molnregioner.
Jämföra resursprovidrar: Microsoft.Storage jämfört med Microsoft.FileShares
| Funktionalitet | Klassiska filresurser |
Filresurser (Microsoft.FileShares) |
|---|---|---|
| Supportgaranti | Allmänt tillgänglig | Offentlig förhandsversion |
| Resurs på toppnivå för tjänsten |
|
Filresurser |
| SMB-protokoll |
|
|
| NFS-protokoll |
|
|
| Stöd för filsynkronisering |
|
|
| Kräv lagringskonto |
|
|
| Betala per användning-faktureringsmodell |
|
|
| Etablerad v1-faktureringsmodell |
|
|
| Etablerad v2-faktureringsmodell |
|
|
| HDD-support |
|
|
| SSD-support |
|
|
| LRS |
|
|
| ZRS |
|
|
| GRS |
|
|
| GZRS |
|
|
| Fakturering, nätverk och säkerhetskonfigurationer per resursnivå |
|
|
| Konfigurationer av ett virtuellt nätverk för en filresurs |
|
|
| Konfiguration av ett virtuellt nätverk för flera filresurser |
|
|
| AKS CSI-drivrutin |
|
|
| REST-API:er för dataplan |
|
|
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 |
|
Linux kernelversion 4.3+ |
| Tillgängliga nivåer | SSD och HDD | Endast SSD |
| Redundans |
|
|
| 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 | Ja (endast Microsoft.Storage) |
| 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 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 och Kryptering under överföring för NFS Azure-filresurser.
Kryptering i vila
Alla data som lagras i Azure Files krypteras i vila via Azure Storage-kryptering på tjänstsidan (SSE). SSE 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 disk, 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.
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 utan den här auktoriseringen är din Azure-filresurs inte längre 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 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å medienivåer för lagring: solid state-disk (SSD) och hårddisk (HDD). Med de här nivåerna kan du anpassa dina resurser efter prestanda- och priskraven i ditt scenario:
SSD (premium): SSD-filresurser ger konsekvent hög prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för I/O-intensiva arbetsbelastningar. SSD-filresurser är lämpliga för en mängd olika arbetsbelastningar, till exempel databaser, webbplatsvärdar och utvecklingsmiljöer.
Du kan använda SSD-filresurser med både SMB- och NFS-protokollen. SSD-filresurser är tillgängliga i de etablerade v2 - och etablerade v1-faktureringsmodellerna . SSD-filresurser erbjuder ett serviceavtal med högre tillgänglighet än HDD-filresurser.
HDD (standard): HDD-filresurser ger ett kostnadseffektivt lagringsalternativ för allmänna filresurser. HDD-filresurser är tillgängliga med de etablerade v2- och betala per användning-faktureringsmodellerna, även om vi rekommenderar den etablerade v2-modellen för nya distributioner av filresurser. Mer information om serviceavtalet finns på azure-SLA-sidan för onlinetjänster.
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. Till exempel kan korta svarstider vara mindre problem med teamresurser som monterats lokalt från Azure eller cachelagrats 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 Förstå Azure Files-faktureringsmodeller och Förstå och optimera Prestanda för Azure-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 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 olika 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 din dataspridning 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-filresurser stöder endast LRS och ZRS.
Betala per användning-lagringskonton 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-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-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 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.