Azure Files implementeren
U kunt Azure Files op twee manieren implementeren: door de serverloze Azure-bestandsshares rechtstreeks te koppelen of door on-premises Azure-bestandsshares in de cache op te slaan met behulp van Azure File Sync. Overwegingen bij de implementatie verschillen op basis van de optie die u kiest.
Directe koppeling van een Azure-bestandsshare: Omdat Azure Files server message block (SMB) of NFS-toegang (Network File System) biedt, kunt u Azure-bestandsshares on-premises of in de cloud koppelen met behulp van de standaard-SMB- of NFS-clients die beschikbaar zijn in uw besturingssysteem. Omdat Azure-bestandsshares serverloos zijn, is het implementeren voor productiescenario's niet nodig om een bestandsserver of NAS-apparaat te beheren. Dit betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven te wisselen.
Cache Azure-bestandsshare on-premises met Azure File Sync: Met Azure File Sync kunt u de bestandsshares van uw organisatie centraliseren in Azure Files, terwijl u de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver houdt. Azure File Sync transformeert een on-premises (of cloud) Windows Server in een snelle cache van uw SMB Azure-bestandsshare.
In dit artikel worden voornamelijk overwegingen voor implementatie besproken voor het implementeren van een Azure-bestandsshare die rechtstreeks moet worden gekoppeld door een on-premises of cloudclient. Als u een Azure File Sync-implementatie wilt plannen, raadpleegt u Planning voor een Azure File Sync-implementatie.
Beschikbare protocollen
Azure Files biedt twee industriestandaard bestandssysteemprotocollen voor het koppelen van Azure-bestandsshares: het SMB-protocol (Server Message Block) en het NFS-protocol (Network File System), zodat u het protocol kunt kiezen dat het meest geschikt is voor uw workload. Azure-bestandsshares bieden geen ondersteuning voor zowel de SMB- als NFS-protocollen op dezelfde bestandsshare, hoewel u SMB- en NFS Azure-bestandsshares binnen hetzelfde opslagaccount kunt maken. NFS 4.1 wordt momenteel alleen ondersteund binnen het nieuwe type FileStorage-opslagaccount (alleen premium-bestandsshares).
Met zowel SMB- als NFS-bestandsshares biedt Azure Files hoogwaardige bestandsshares die omhoog kunnen worden geschaald om te voldoen aan uw opslagbehoeften en gelijktijdig toegankelijk zijn voor duizenden clients.
| Functie | SMB | NFS |
|---|---|---|
| Ondersteunde protocolversies | SMB 3.1.1, SMB 3.0, SMB 2.1 | NFS 4.1 |
| Aanbevolen besturingssysteem |
|
Linux-kernelversie 4.3+ |
| Beschikbare lagen | Premium, geoptimaliseerde transacties, dynamisch en statisch | Premium |
| Factureringsmodel | Ingerichte capaciteit | |
| Azure DNS-zone-eindpunten (preview) | Ondersteund | Ondersteund |
| Redundantie | LRS, ZRS, GRS, GZRS | LRS, ZRS |
| Semantiek van bestandssysteem | Win32-apps | POSIX |
| Verificatie | Verificatie op basis van identiteit (Kerberos), verificatie met gedeelde sleutels (NTLMv2) | Verificatie op basis van host |
| Autorisatie | Win32-achtige toegangsbeheerlijsten (ACL's) | Machtigingen voor UNIX-stijl |
| Hoofdlettergevoelig | Hoofdlettergevoelig, hoofdlettergevoelig, hoofdletterbehoud | Hoofdlettergevoelig |
| Geopende bestanden verwijderen of wijzigen | Alleen vergrendelen | Ja |
| Bestanden delen | Windows-modus voor delen | Byte-range adviserende netwerkvergrendelingsmanager |
| Ondersteuning voor vaste koppelingen | Niet ondersteund | Ondersteund |
| Ondersteuning voor symbolische koppelingen | Niet ondersteund | Ondersteund |
| Optioneel toegankelijk via internet | Ja (alleen SMB 3.0+ ) | Nee |
| Ondersteunt FileREST | Ja | Deelverzameling: |
| Verplichte bytebereikvergrendelingen | Ondersteund | Niet ondersteund |
| Vergrendelingen van advies bytebereik | Niet ondersteund | Ondersteund |
| Uitgebreide/benoemde kenmerken | Niet ondersteund | Niet ondersteund |
| Alternatieve gegevensstreams | Niet ondersteund | N.v.t. |
| Object-id's | Niet ondersteund | N.v.t. |
| Reparsepunten | Niet ondersteund | N.v.t. |
| Sparse-bestanden | Niet ondersteund | N.v.t. |
| Compressie | Niet ondersteund | N.v.t. |
| Benoemde pijpen | Niet ondersteund | N.v.t. |
| SMB Direct | Niet ondersteund | N.v.t. |
| SMB Directory Leasing | Niet ondersteund | N.v.t. |
| Volume Shadow Copy | Niet ondersteund | N.v.t. |
| Korte bestandsnamen (alias 8.3) | Niet ondersteund | N.v.t. |
| Server-service | Niet ondersteund | N.v.t. |
| Bestandssysteemtransacties (TxF) | Niet ondersteund | N.v.t. |
Beheerconcepten
Azure-bestandsshares worden geïmplementeerd in opslagaccounts. Dat zijn objecten op het hoogste niveau die een gedeelde opslagpool vertegenwoordigen. Deze opslagpool kan worden gebruikt om meerdere bestandsshares en andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, te implementeren. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Zie Azure Files-schaalbaarheids- en prestatiedoelen voor huidige opslagaccountlimieten.
Er zijn twee belangrijke soorten opslagaccounts die u voor Azure Files-implementatie gaat gebruiken:
- Opslagaccounts voor algemeen gebruik versie 2 (GPv2): met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op hardware op basis van standard/harde schijven (HDD). Naast het opslaan van Azure-bestandsshares kunnen GPv2-opslagaccounts andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, opslaan.
- FileStorage-opslagaccounts: Met FileStorage-opslagaccounts kunt u Azure-bestandsshares implementeren op premium-/SSD-hardware op basis van ssd's. FileStorage-accounts kunnen alleen worden gebruikt voor het opslaan van Azure-bestandsshares. Er kunnen geen andere opslagresources (blobcontainers, wachtrijen, tabellen enz.) worden geïmplementeerd in een FileStorage-account. Alleen FileStorage-accounts kunnen zowel SMB- als NFS-bestandsshares implementeren.
Er zijn verschillende andere typen opslagaccounts die u kunt tegenkomen in Azure Portal, PowerShell of CLI. Twee typen opslagaccounts, BlockBlobStorage- en BlobStorage-opslagaccounts, mogen geen Azure-bestandsshares bevatten. De andere twee typen opslagaccounts die u mogelijk ziet, zijn GPv1-opslagaccounts (versie 1 voor algemeen gebruik) en klassieke opslagaccounts. Beide typen kunnen Azure-bestandsshares bevatten. Hoewel GPv1-opslagaccounts en klassieke opslagaccounts Azure-bestandsshares kunnen bevatten, zijn de meeste nieuwe functies van Azure Files alleen beschikbaar in GPv2-en FileStorage-opslagaccounts. Daarom raden we u aan om alleen GPv2- en FileStorage-opslagaccounts te gebruiken voor nieuwe implementaties en om GPv1-opslagaccounts en klassieke opslagaccounts bij te werken als deze al in uw omgeving aanwezig zijn.
Bij het implementeren van Azure-bestandsshares in opslagaccounts raden we het volgende aan:
Alleen Azure-bestandsshares implementeren in opslagaccounts met andere Azure-bestandsshares. Hoewel GPv2-opslagaccounts u in staat stellen om opslagaccounts voor gemengde doeleinden te hebben, omdat opslagresources zoals Azure-bestandsshares en blobcontainers de limieten van het opslagaccount delen, kan het combineren van resources het lastiger maken om prestatieproblemen later op te lossen.
Let op de IOPS-beperkingen van een opslagaccount bij het implementeren van Azure-bestandsshares. In het ideale instantie wijst u bestandsshares 1:1 toe met opslagaccounts. Dit is echter niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel van uw organisatie als van Azure. Wanneer het niet mogelijk is om slechts één bestandsshare in één opslagaccount te implementeren, moet u overwegen welke shares zeer actief zijn en welke shares minder actief zijn om ervoor te zorgen dat de heetste bestandsshares niet samen in hetzelfde opslagaccount worden geplaatst.
Alleen GPv2- en FileStorage-accounts implementeren en GPv1- en klassieke opslagaccounts upgraden wanneer u deze in uw omgeving vindt.
Identiteit
Voor toegang tot een Azure-bestandsshare moet de gebruiker van de bestandsshare worden geverifieerd en gemachtigd voor toegang tot de share. Dit wordt gedaan op basis van de identiteit van de gebruiker die toegang heeft tot de bestandsshare. Azure Files ondersteunt de volgende verificatiemethoden:
- On-premises Active Directory-domein Services (AD DS of on-premises AD DS): Azure-opslagaccounts kunnen lid zijn van een domein dat is gekoppeld aan een Active Directory-domein Services van de klant, net zoals een Windows Server-bestandsserver of NAS-apparaat. U kunt een domeincontroller on-premises, in een Azure-VM of zelfs als een VM in een andere cloudprovider implementeren; Azure Files is agnostisch voor de locatie waar uw domeincontroller wordt gehost. Zodra een opslagaccount lid is van een domein, kan de eindgebruiker een bestandsshare koppelen aan het gebruikersaccount waarmee hij of zij zich heeft aangemeld bij zijn pc. Verificatie op basis van AD maakt gebruik van het Kerberos-verificatieprotocol.
- Microsoft Entra Domain Services: Microsoft Entra Domain Services biedt een door Microsoft beheerde domeincontroller die kan worden gebruikt voor Azure-resources. Domein dat uw opslagaccount aan Microsoft Entra Domain Services voegt, biedt vergelijkbare voordelen als het domein dat deelneemt aan een AD DS die eigendom is van de klant. Deze implementatieoptie is het handigst voor lift-and-shift-scenario's van toepassingen waarvoor ad-machtigingen zijn vereist. Aangezien Microsoft Entra Domain Services ad-verificatie biedt, wordt met deze optie ook het Kerberos-verificatieprotocol gebruikt.
- Microsoft Entra Kerberos voor hybride identiteiten: Met Microsoft Entra Kerberos kunt u Microsoft Entra ID gebruiken om hybride gebruikersidentiteiten te verifiëren, die on-premises AD-identiteiten zijn die met de cloud worden gesynchroniseerd. Deze configuratie gebruikt Microsoft Entra ID om Kerberos-tickets uit te geven voor toegang tot de bestandsshare met het SMB-protocol. Dit betekent dat uw eindgebruikers toegang hebben tot Azure-bestandsshares via internet zonder dat netwerkconnectiviteit met domeincontrollers van hybride Microsoft Entra-gekoppelde en aan Microsoft Entra gekoppelde VM's is vereist.
- Active Directory-verificatie via SMB voor Linux-clients: Azure Files ondersteunt verificatie op basis van identiteiten via SMB voor Linux-clients met behulp van het Kerberos-verificatieprotocol via AD DS of Microsoft Entra Domain Services.
- Azure Storage-accountsleutel: Azure-bestandsshares kunnen ook worden gekoppeld aan een Azure-opslagaccountsleutel. Als u een bestandsshare op deze manier wilt koppelen, wordt de naam van het opslagaccount gebruikt als gebruikersnaam en wordt de sleutel van het opslagaccount gebruikt als een wachtwoord. Het gebruik van de sleutel van het opslagaccount om de Azure-bestandsshare te koppelen is in feite een beheerdersbewerking, omdat de gekoppelde bestandsshare volledige machtigingen heeft voor alle bestanden en mappen op de share, zelfs als ze ACL's hebben. Wanneer u de sleutel van het opslagaccount gebruikt om te koppelen via SMB, wordt het NTLMv2-verificatieprotocol gebruikt. Als u de sleutel van het opslagaccount wilt gebruiken voor toegang tot uw Azure-bestandsshares, raden we u aan privé-eindpunten of service-eindpunten te gebruiken, zoals beschreven in de sectie Netwerken .
Voor klanten die migreren van on-premises bestandsservers of het maken van nieuwe bestandsshares in Azure Files die bedoeld zijn om zich te gedragen als Windows-bestandsservers of NAS-apparaten, is domein dat uw opslagaccount aan AD DS in eigendom van de klant voegt, de aanbevolen optie. Zie Overzicht : on-premises Active Directory-domein Services-verificatie via SMB voor Azure-bestandsshares voor meer informatie over domein dat lid wordt van uw opslagaccount aan een AD DS van de klant.
Netwerken
Voor het rechtstreeks koppelen van uw Azure-bestandsshare moet u vaak nadenken over de netwerkconfiguratie, omdat:
- De poort die SMB-bestandsshares gebruiken voor communicatie, poort 445, wordt vaak geblokkeerd door veel organisaties en internetproviders (ISP's) voor uitgaand (internet) verkeer.
- NFS-bestandsshares zijn afhankelijk van verificatie op netwerkniveau en zijn daarom alleen toegankelijk via beperkte netwerken. Voor het gebruik van een NFS-bestandsshare is altijd een netwerkconfiguratie vereist.
Voor het configureren van netwerken biedt Azure Files een openbaar interneteindpunt en integratie met Azure-netwerkfuncties zoals service-eindpunten, waarmee het openbare eindpunt wordt beperkt tot opgegeven virtuele netwerken en privé-eindpunten, waardoor uw opslagaccount een privé-IP-adres krijgt vanuit een IP-adresruimte van een virtueel netwerk. Hoewel er geen extra kosten in rekening worden gebracht voor het gebruik van openbare eindpunten of service-eindpunten, gelden standaardgegevensverwerkingstarieven voor privé-eindpunten.
Dit betekent dat u rekening moet houden met de volgende netwerkconfiguraties:
- Als het vereiste protocol SMB is en alle toegang via SMB afkomstig is van clients in Azure, is er geen speciale netwerkconfiguratie vereist.
- Als het vereiste protocol SMB is en de toegang afkomstig is van clients on-premises, is een VPN- of ExpressRoute-verbinding van on-premises naar uw Azure-netwerk vereist, waarbij Azure Files beschikbaar is in uw interne netwerk met behulp van privé-eindpunten.
- Als het vereiste protocol NFS is, kunt u service-eindpunten of privé-eindpunten gebruiken om het netwerk te beperken tot opgegeven virtuele netwerken. Als u een statisch IP-adres nodig hebt en/of uw workload hoge beschikbaarheid vereist, gebruikt u een privé-eindpunt. Bij service-eindpunten kan een zeldzame gebeurtenis, zoals een zonegebonden storing, ertoe leiden dat het onderliggende IP-adres van het opslagaccount wordt gewijzigd. Hoewel de gegevens nog steeds beschikbaar zijn op de bestandsshare, moet de client de share opnieuw koppelen.
Zie Aandachtspunten voor Azure Files-netwerken voor meer informatie over het configureren van netwerken voor Azure Files.
Naast rechtstreeks verbinding maken met de bestandsshare via het openbare eindpunt of via een VPN/ExpressRoute-verbinding met een privé-eindpunt, biedt SMB een extra clienttoegangsstrategie: SMB via QUIC. SMB via QUIC biedt zero-config 'SMB VPN' voor SMB-toegang via het QUIC-transportprotocol. Hoewel Azure Files SMB niet rechtstreeks ondersteunt via QUIC, kunt u een lichtgewicht cache van uw Azure-bestandsshares maken op een Virtuele Machine met Windows Server 2022 Azure Edition met behulp van Azure File Sync. Zie SMB via QUIC met Azure File Sync voor meer informatie over deze optie.
Versleuteling
Azure Files ondersteunt twee verschillende typen versleuteling:
- Versleuteling tijdens overdracht, die betrekking heeft op de versleuteling die wordt gebruikt bij het koppelen/openen van de Azure-bestandsshare
- Versleuteling-at-rest, die betrekking heeft op de wijze waarop de gegevens worden versleuteld wanneer ze op schijf worden opgeslagen
Versleuteling 'in transit'
Belangrijk
Deze sectie bevat informatie over versleuteling tijdens overdracht voor SMB-shares. Zie Beveiliging en netwerken voor meer informatie over versleuteling tijdens overdracht met NFS-shares.
Standaard is versleuteling in-transit ingeschakeld voor alle Azure-opslagaccounts. Dit betekent dat wanneer u een bestandsshare koppelt via SMB of deze opent via het FileREST-protocol (zoals via Azure Portal, PowerShell/CLI of Azure SDK's), Azure Files alleen de verbinding toestaat als deze is gemaakt met SMB 3.x met versleuteling of HTTPS. Clients die geen ondersteuning bieden voor SMB 3.x of clients die SMB 3.x ondersteunen, maar geen SMB-versleuteling, kunnen de Azure-bestandsshare niet koppelen als versleuteling tijdens overdracht is ingeschakeld. Zie onze documentatie voor Windows, macOS en Linux voor meer informatie over welke besturingssystemen SMB 3.x ondersteunen met versleuteling. Alle huidige versies van PowerShell, CLI en SDK's ondersteunen HTTPS.
U kunt versleuteling in transit uitschakelen voor een Azure-opslagaccount. Wanneer versleuteling is uitgeschakeld, worden in Azure Files ook SMB 2.1 en SMB 3.x zonder versleuteling en niet-versleutelde FileREST API-aanroepen via HTTP toegestaan. De primaire reden voor het uitschakelen van versleuteling tijdens overdracht is het ondersteunen van een verouderde toepassing die moet worden uitgevoerd op een ouder besturingssysteem, zoals Windows Server 2008 R2 of een oudere Linux-distributie. Azure Files staat alleen SMB 2.1-verbindingen toe binnen dezelfde Azure-regio als de Azure-bestandsshare; een SMB 2.1-client buiten de Azure-regio van de Azure-bestandsshare, zoals on-premises of in een andere Azure-regio, heeft geen toegang tot de bestandsshare.
We raden u ten zeerste aan ervoor te zorgen dat versleuteling van gegevens in transit is ingeschakeld.
Zie Veilige overdracht vereisen in Azure Storage voor meer informatie over versleuteling in-transit.
Versleuteling 'at rest'
Alle gegevens die zijn opgeslagen in Azure Files worden inactief versleuteld met behulp van Azure Storage Service Encryption (SSE). Versleuteling van de opslagservice werkt op dezelfde manier als BitLocker op Windows: gegevens worden versleuteld onder het bestandssysteemniveau. Omdat gegevens worden versleuteld onder het bestandssysteem van de Azure-bestandsshare (vanwege codering naar de schijf) hoeft u geen toegang te hebben tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te kunnen lezen of schrijven. Inactieve versleuteling geldt voor zowel SMB- als NFS-protocollen.
Standaard worden gegevens die zijn opgeslagen in Azure Files versleuteld met door Microsoft beheerde sleutels. Bij door Microsoft beheerde sleutels heeft Microsoft de sleutels voor het versleutelen/ontsleutelen van de gegevens en is Microsoft verantwoordelijk voor het regelmatig rouleren van de sleutels. U kunt er ook voor kiezen om uw eigen sleutels te beheren. Dit geeft u controle over het roulatieproces. Als u ervoor kiest om uw bestandsshares te versleutelen met door de klant beheerde sleutels, is Azure Files gemachtigd om toegang te krijgen tot uw sleutels om te voldoen aan lees- en schrijfaanvragen van uw klanten. Bij door de klant beheerde sleutels kunt u deze autorisatie op elk gewenst moment intrekken, maar dit houdt wel in dat uw Azure-bestandsshare niet langer toegankelijk is via SMB of de FileREST-API.
Azure Files gebruikt hetzelfde versleutelingsschema als de andere Azure-opslagservices zoals Azure Blob Storage. Raadpleeg Azure storage encryption for data at rest (Azure Storage-versleuteling voor inactieve gegevens) voor meer informatie over Azure Storage Service Encryption (SSE).
Gegevensbescherming
Azure Files heeft een benadering met meerdere lagen om ervoor te zorgen dat er een back-up van uw gegevens wordt gemaakt, kan worden hersteld en beveiligd tegen beveiligingsrisico's. Zie het overzicht van Azure Files-gegevensbeveiliging.
Voorlopig verwijderen
Voorlopig verwijderen is een instelling op opslagaccountniveau waarmee u uw bestandsshare kunt herstellen wanneer deze per ongeluk wordt verwijderd. Wanneer een bestandsshare wordt verwijderd, wordt deze overgezet naar een voorlopig verwijderde status in plaats van permanent te worden gewist. U kunt configureren hoe lang voorlopig verwijderde shares kunnen worden hersteld voordat ze permanent worden verwijderd en de share op elk gewenst moment tijdens deze bewaarperiode ongedaan maken.
Voorlopig verwijderen is standaard ingeschakeld voor nieuwe opslagaccounts. Als u een werkstroom hebt waarin het verwijderen van delen gebruikelijk is en verwacht, kunt u besluiten om een korte bewaarperiode te hebben of voorlopig verwijderen helemaal niet ingeschakeld te hebben.
Zie Onopzettelijke gegevensverwijdering voorkomen voor meer informatie over voorlopig verwijderen.
Backup
U kunt een back-up maken van uw Azure-bestandsshare via momentopnamen van shares, die alleen-lezen, point-in-time kopieën van uw share zijn. Momentopnamen zijn incrementeel, wat betekent dat ze alleen zoveel gegevens bevatten als sinds de vorige momentopname is gewijzigd. U kunt maximaal 200 momentopnamen per bestandsshare hebben en ze maximaal 10 jaar bewaren. U kunt handmatig momentopnamen maken in Azure Portal, via PowerShell of opdrachtregelinterface (CLI), of u kunt Azure Backup gebruiken.
Azure Backup voor Azure-bestandsshares verwerkt de planning en retentie van momentopnamen. De mogelijkheden van grootvader-vader-zoon (GFS) betekenen dat u dagelijkse, wekelijkse, maandelijkse en jaarlijkse momentopnamen kunt maken, elk met een eigen afzonderlijke bewaarperiode. Azure Backup organiseert ook het inschakelen van voorlopig verwijderen en neemt een verwijderingsvergrendeling op een opslagaccount zodra een bestandsshare in het account is geconfigureerd voor back-up. Ten slotte biedt Azure Backup bepaalde belangrijke bewakings- en waarschuwingsmogelijkheden waarmee klanten een geconsolideerde weergave van hun back-upomgeving kunnen hebben.
U kunt herstelbewerkingen op item- en shareniveau uitvoeren in Azure Portal met behulp van Azure Backup. U hoeft alleen het herstelpunt (een bepaalde momentopname) te kiezen, het specifieke bestand of de map, indien relevant, en vervolgens de locatie (oorspronkelijk of alternatief) waarnaar u wilt herstellen. De back-upservice verwerkt het kopiëren van de momentopnamegegevens en toont uw herstelvoortgang in de portal.
Azure Files beveiligen met Microsoft Defender for Storage
Microsoft Defender for Storage is een systeemeigen beveiligingslaag van Azure waarmee potentiële bedreigingen voor uw opslagaccounts worden gedetecteerd. Het biedt uitgebreide beveiliging door de telemetrie van het gegevensvlak en het besturingsvlak te analyseren die worden gegenereerd door Azure Files. Het maakt gebruik van geavanceerde mogelijkheden voor detectie van bedreigingen die worden mogelijk gemaakt door Microsoft Threat Intelligence om contextuele beveiligingswaarschuwingen te bieden, inclusief stappen om de gedetecteerde bedreigingen te beperken en toekomstige aanvallen te voorkomen.
Defender for Storage analyseert continu de telemetriestroom die door Azure Files wordt gegenereerd. Wanneer mogelijk schadelijke activiteiten worden gedetecteerd, worden beveiligingswaarschuwingen gegenereerd. Deze waarschuwingen worden weergegeven in Microsoft Defender voor Cloud, samen met de details van de verdachte activiteit, onderzoeksstappen, herstelacties en beveiligingsaanbeveling.
Defender for Storage detecteert bekende malware, zoals ransomware, virussen, spyware en andere malware die is geüpload naar een opslagaccount op basis van volledige bestands-hash (alleen ondersteund voor REST API). Dit helpt voorkomen dat malware de organisatie binnenkomt en zich verspreidt naar meer gebruikers en resources. Zie Inzicht in de verschillen tussen malwarescans en hashreputatieanalyse.
Defender for Storage heeft geen toegang tot de gegevens van het opslagaccount en heeft geen invloed op de prestaties. U kunt Microsoft Defender for Storage inschakelen op abonnementsniveau (aanbevolen) of op resourceniveau.
Opslaglagen
Azure Files biedt twee verschillende medialagen opslag, SSD (solid-state disks) en HDD (harde schijven), waarmee u uw shares kunt aanpassen aan de prestatie- en prijsvereisten van uw scenario:
SSD (Premium): SSD-bestandsshares bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste IO-bewerkingen, voor IO-intensieve workloads. SSD-bestandsshares zijn geschikt voor een groot aantal workloads, zoals databases, hosting van websites en ontwikkelomgevingen. SSD-bestandsshares kunnen worden gebruikt met zowel SMB-protocollen (Server Message Block) als NFS-protocollen (Network File System). SSD-bestandsshares zijn beschikbaar in het ingerichte v1-factureringsmodel . SSD-bestandsshares bieden een SLA met een hogere beschikbaarheid dan HDD-bestandsshares (zie 'Azure Files Premium Tier').
HDD (standaard): HDD-bestandsshares bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik. HDD-bestandsshares die beschikbaar zijn met de ingerichte v2 - en betalen per gebruik-factureringsmodellen, hoewel we het ingerichte v2-model aanbevelen voor nieuwe implementaties van bestandsshares. Zie de pagina Azure-serviceovereenkomsten (zie 'Opslagaccounts') voor meer informatie over de SLA.
Wanneer u een medialaag voor uw workload selecteert, moet u rekening houden met uw prestatie- en gebruiksvereisten. Als voor uw workload latentie van één cijfer is vereist of als u ssd-opslagmedia on-premises gebruikt, is de ssd-bestandssharelaag waarschijnlijk het meest geschikt. Als lage latentie niet zo belangrijk is, bijvoorbeeld als teamshares on-premises zijn gekoppeld vanuit Azure of on-premises in de cache zijn opgeslagen met behulp van Azure File Sync, zijn HDD-bestandsshares mogelijk beter geschikt vanuit kostenperspectief.
Nadat u een bestandsshare in een opslagaccount hebt gemaakt, kunt u deze niet rechtstreeks verplaatsen naar een andere medialaag. Als u bijvoorbeeld een HDD-bestandsshare naar de SSD-medialaag wilt verplaatsen, moet u een nieuwe SSD-bestandsshare maken en de gegevens van de oorspronkelijke share kopiëren naar een nieuwe bestandsshare in het FileStorage-account. We raden aan AzCopy te gebruiken om gegevens tussen Azure-bestandsshares te kopiëren, maar u kunt ook hulpprogramma's gebruiken als robocopy op Windows of rsync voor macOS en Linux.
Raadpleeg Azure Files-facturering begrijpen voor meer informatie.
Redundantie
Om de gegevens in uw Azure-bestandsshares te beschermen tegen gegevensverlies of beschadiging, worden in Azure Files meerdere kopieën van elk bestand opgeslagen terwijl ze worden geschreven. Afhankelijk van uw vereisten kunt u verschillende mate van redundantie selecteren. Azure Files ondersteunt momenteel de volgende opties voor gegevensredundantie:
- Lokaal redundante opslag (LRS):met LRS wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Dit beschermt tegen gegevensverlies als gevolg van hardwarefouten, zoals een ongeldig schijfstation. Als een noodgeval, zoals brand of overstromingen, zich echter in het datacenter voordoet, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherstelbaar zijn.
- Zone-redundante opslag (ZRS):met ZRS worden drie kopieën van elk bestand opgeslagen. Deze kopieën worden echter fysiek geïsoleerd in drie afzonderlijke opslagclusters in verschillende Azure-beschikbaarheidszones. Beschikbaarheidszones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Een schrijfbewerking naar opslag wordt pas geaccepteerd als deze naar de opslagclusters in alle drie de beschikbaarheidszones wordt geschreven.
- Geografisch redundante opslag (GRS):met GRS hebt u twee regio's, een primaire regio en een secundaire regio. Bestanden worden drie keer opgeslagen in een Azure-opslagcluster in de primaire regio. Schrijfbewerkingen worden asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. GRS biedt zes kopieën van uw gegevens verspreid over twee Azure-regio's. In het geval van een grote ramp, zoals het permanente verlies van een Azure-regio vanwege een natuurramp of een andere soortgelijke gebeurtenis, voert Microsoft een failover uit. In dit geval wordt de secundaire de primaire, die alle bewerkingen bedient. Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan in het geval van een grote noodgeval de gegevens die nog niet naar de secundaire regio worden gerepliceerd, verloren. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.
- Geografisch zone-redundante opslag (GZRS):u kunt GZRS beschouwen als ZRS, maar met geo-redundantie. Met GZRS worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. Het failoverproces voor GZRS werkt hetzelfde als GRS.
Standard Azure-bestandsshares tot 5 TiB ondersteunen alle vier de redundantietypen. Standaardbestandsshares die groter zijn dan 5 TiB bieden alleen ondersteuning voor LRS en ZRS. Premium Azure-bestandsshares ondersteunen alleen LRS en ZRS.
Opslagaccounts voor algemeen gebruik versie 2 (GPv2) bieden twee andere redundantieopties die azure Files niet ondersteunt: leesbare geografisch redundante opslag (RA-GRS) en leesbare geografisch zone-redundante opslag (RA-GZRS). U kunt Azure-bestandsshares inrichten in opslagaccounts met deze optieset, maar Azure Files biedt geen ondersteuning voor lezen vanuit de secundaire regio. Azure-bestandsshares die zijn geïmplementeerd in RA-GRS- of RA-GZRS-opslagaccounts, worden respectievelijk gefactureerd als GRS of GZRS.
Zie Azure Files-gegevensredundantie voor meer informatie over redundantie.
Beschikbaarheid van Standard ZRS
ZRS voor standaard v2-opslagaccounts voor algemeen gebruik is beschikbaar voor een subset van Azure-regio's.
Premium ZRS-beschikbaarheid
ZRS voor premium bestandsshares is beschikbaar voor een subset van Azure-regio's.
Beschikbaarheid van Standard GZRS
GZRS is beschikbaar voor een subset van Azure-regio's.
Herstel na noodgevallen en failover
In het geval van een niet-geplande regionale servicestoring moet u een noodherstelplan (DR) hebben voor uw Azure-bestandsshares. Zie Herstel na noodgevallen en failover voor Azure Files voor meer informatie over de concepten en processen die betrokken zijn bij failover van herstel na noodgeval en opslagaccount.
Migratie
In veel gevallen maakt u geen nieuwe net-bestandsshare voor uw organisatie, maar migreert u in plaats daarvan een bestaande bestandsshare vanaf een on-premises bestandsserver of NAS-apparaat naar Azure Files. Het kiezen van de juiste migratiestrategie en het juiste hulpprogramma voor uw scenario is belangrijk voor het succes van uw migratie.
In het overzichtsartikel over migratie worden de basisbeginselen kort besproken en wordt een tabel weergegeven die u naar migratiehandleidingen leidt die waarschijnlijk betrekking hebben op uw scenario.