Planning voor de implementatie van Azure Files

Azure Files kunnen op twee belangrijke manieren worden geïmplementeerd: door de serverloze Azure-bestands shares rechtstreeks te mounten of door Azure-bestands shares on-premises op te Azure File Sync. Met welke implementatieoptie u kiest, wijzigt u de zaken die u moet overwegen bij het plannen van uw implementatie.

• Directe bevestiging van een Azure-bestands share: omdat Azure Files toegang biedt tot Server Message Block (SMB) of Network File System (NFS), kunt u Azure-bestands shares on-premises of in de cloud aan elkaar toevoegen met behulp van de standaard-SMB- of NFS-clients die beschikbaar zijn in uw besturingssysteem. Omdat Azure-bestands shares serverloos zijn, is voor implementatie voor productiescenario's geen beheer van een bestandsserver of NAS-apparaat vereist. Dit betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven hoeft te verwisselen.

• Azure-bestands share on-premises cachen met Azure File Sync: met Azure File Sync kunt u de bestands shares van uw organisatie centraliseren in Azure Files, terwijl u de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver be behouden. Azure File Sync transformeert een on-premises (of cloud) Windows Server naar een snelle cache van uw Azure SMB-bestands share.

In dit artikel worden met name overwegingen voor de implementatie van een Azure-bestands share beschreven die rechtstreeks door een on-premises client of cloudclient moeten worden bevestigd. Zie Planning for an Azure File Sync deployment (Planning vooreen Azure File Sync implementatie) om een Azure File Sync plannen.

Beschikbare protocollen

Azure Files biedt twee standaardprotocollen voor het maken van een Azure-bestands share: het Server Message Block-protocol (SMB) en het NFS-protocol (Network File System). Azure Files kunt u het bestandssysteemprotocol kiezen dat het meest geschikt is voor uw workload. Azure-bestands shares bieden geen ondersteuning voor zowel de SMB- als NFS-protocollen op dezelfde bestands share, hoewel u SMB- en NFS Azure-bestands shares binnen hetzelfde opslagaccount kunt maken. NFS 4.1 wordt momenteel alleen ondersteund binnen het nieuwe type FileStorage-opslagaccount (alleen Premium-bestands shares).

Met zowel SMB- als NFS-bestands shares biedt Azure Files bestands shares van ondernemingsklasse die omhoog kunnen worden geschaald om te voldoen aan uw opslagbehoeften en die gelijktijdig kunnen worden gebruikt door duizenden clients.

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 Schaalbaarheids- en prestatiedoelen voor Azure Files opslagaccountlimieten.

Er zijn twee belangrijke soorten opslagaccounts die u voor Azure Files-implementatie gaat gebruiken:

• GPv2-opslagaccounts (versie twee voor algemeen gebruik) : Met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op (HDD-)hardware met een standaard/harde schijf. 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 (SSD-)hardware met een premium/solid-state schijf. 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.

Wanneer u Azure-bestands shares implementeert in opslagaccounts, raden we het volgende aan:

• Alleen Azure-bestands shares implementeren in opslagaccounts met andere Azure-bestands shares. Hoewel u met GPv2-opslagaccounts opslagaccounts voor gemengde doeleinden kunt gebruiken, kan het, omdat opslagresources zoals Azure-bestands shares en blobcontainers de limieten van het opslagaccount delen, het combineren van resources het moeilijker maken om later prestatieproblemen op te lossen.

• Let op de IOPS-beperkingen van een opslagaccount bij het implementeren van Azure-bestands shares. In het ideale moment kunt u bestands shares 1:1 koppelen aan opslagaccounts, maar dit is mogelijk niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel vanuit uw organisatie als vanuit Azure. Wanneer het niet mogelijk is om slechts één bestands share te hebben geïmplementeerd in één opslagaccount, moet u overwegen welke shares zeer actief zijn en welke shares minder actief zijn om ervoor te zorgen dat de belangrijkste bestands shares niet samen in hetzelfde opslagaccount worden geplaatst.

• Implementeer alleen GPv2- en FileStorage-accounts en werk GPv1- en klassieke opslagaccounts bij wanneer u ze in uw omgeving vindt.

Identiteit

Voor toegang tot een Azure-bestands share moet de gebruiker van de bestands share worden geverifieerd en zijn autorisatie hebben voor toegang tot de share. Dit wordt gedaan op basis van de identiteit van de gebruiker die toegang heeft tot de bestands share. Azure Files kan worden geïntegreerd met drie hoofdidentiteitsproviders:

• On-premises Active Directory Domain Services (AD DS of on-premises AD DS): Azure-opslagaccounts kunnen net als een Windows Server-bestandsserver of NAS-apparaat lid worden van een domein dat eigendom is van de klant, Active Directory Domain Services. U kunt een domeincontroller on-premises, in een Azure-VM of zelfs als een VM bij een andere cloudprovider implementeren; Azure Files is onafhankelijk van waar uw domeincontroller wordt gehost. Zodra een opslagaccount lid is van een domein, kan de eindgebruiker een bestands share aan het gebruikersaccount toevoegen dat hij/zij heeft aangemeld bij zijn pc. Verificatie op basis van AD maakt gebruik van het Kerberos-verificatieprotocol.
• Azure Active Directory Domain Services (Azure AD DS): Azure AD DS biedt een door Microsoft beheerde domeincontroller die kan worden gebruikt voor Azure-resources. Domein dat uw opslagaccount aan Azure AD DS biedt vergelijkbare voordelen als domein toevoegen aan een Active Directory die eigendom is van de klant. Deze implementatieoptie is het handigst voor lift-and-shift-scenario's voor toepassingen waarvoor AD-machtigingen zijn vereist. Omdat Azure AD DS ad-verificatie biedt, maakt deze optie ook gebruik van het Kerberos-verificatieprotocol.
• Azure-opslagaccountsleutel: Azure-bestands shares kunnen ook worden bevestigd met een Azure-opslagaccountsleutel. Als u een bestands share op deze manier wilt toevoegen, wordt de naam van het opslagaccount gebruikt als de gebruikersnaam en wordt de sleutel van het opslagaccount gebruikt als wachtwoord. Het gebruik van de sleutel van het opslagaccount voor het toevoegen van de Azure-bestands share is in de meeste plaats een beheerdersbewerking, omdat de bestands share volledige machtigingen heeft voor alle bestanden en mappen op de share, zelfs als deze ACL's hebben. Wanneer u de sleutel van het opslagaccount gebruikt om te worden bevestigd via SMB, wordt het NTLMv2-verificatieprotocol gebruikt.

Voor klanten die migreren van on-premises bestandsservers of voor het maken van nieuwe bestands shares in Azure Files bedoeld om zich te gedragen als Windows-bestandsservers of NAS-apparaten, is domein dat uw opslagaccount lid maakt van Active Directory in eigendom van de klant de aanbevolen optie. Zie overzicht van Active Directory voor meer informatie over het toevoegen van uw opslagaccount aan een Active Directory van de klant Azure Files active directory.

Als u van plan bent om de sleutel van het opslagaccount te gebruiken voor toegang tot uw Azure-bestands shares, raden we u aan service-eindpunten te gebruiken, zoals beschreven in de sectie Netwerken.

Netwerken

Azure-bestands shares zijn vanaf elke locatie toegankelijk via het openbare eindpunt van het opslagaccount. Dit betekent dat geverifieerde aanvragen, zoals aanvragen die zijn geautoriseerd door de aanmeldingsidentiteit van een gebruiker, veilig kunnen zijn van binnen of buiten Azure. In veel klantomgevingen kan een initiële koppeling van de Azure-bestandsshare op uw on-premises werkstation mislukken, zelfs als het wel lukt om Azure-VM's te koppelen. De reden hiervoor is dat veel organisaties en internetproviders (ISP's) de poort blokkeren die door SMB wordt gebruikt voor communicatie: poort 445. Ga naar TechNet voor een overzicht van welke internetproviders toegang via poort 445 toestaan en welke niet.

Als u de toegang tot uw Azure-bestands share wilt deblokkeren, hebt u twee hoofdopties:

• Blokkering van poort 445 opheffen voor het on-premises netwerk van uw organisatie. Azure-bestands shares kunnen alleen extern worden gebruikt via het openbare eindpunt met behulp van internetveilige protocollen zoals SMB 3.x en de FileREST-API. Dit is de eenvoudigste manier om on-premises toegang te krijgen tot uw Azure-bestands share, omdat er geen geavanceerde netwerkconfiguratie nodig is naast het wijzigen van de regels voor uitgaande poort van uw organisatie. U wordt echter aangeraden verouderde en afgeschafte versies van het SMB-protocol te verwijderen, namelijk SMB 1.0. Zie Securing Windows/Windows Server and Securing Linux (Server Windows/Windows beveiligen en Linux beveiligen)voor meer informatie.

• Toegang tot Azure-bestands shares via een ExpressRoute- of VPN-verbinding. Wanneer u toegang hebt tot uw Azure-bestands share via een netwerktunnel, kunt u uw Azure-bestands share als een on-premises bestands delen, omdat SMB-verkeer uw organisatiegrens niet passeert.

Hoewel het vanuit technisch oogpunt aanzienlijk eenvoudiger is om uw Azure-bestands shares te verbinden via het openbare eindpunt, verwachten we dat de meeste klanten ervoor kiezen om hun Azure-bestands shares te verbinden via een ExpressRoute- of VPN-verbinding. Met deze opties kunt u zowel SMB- als NFS-shares gebruiken. Hiervoor moet u het volgende configureren voor uw omgeving:

• Netwerktunneling met Behulp van ExpressRoute, site-naar-site of punt-naar-site-VPN: Tunneling naar een virtueel netwerk maakt toegang tot Azure-bestands shares vanaf on-premises mogelijk, zelfs als poort 445 is geblokkeerd.
• Privé-eindpunten: privé-eindpunten geven uw opslagaccount een toegewezen IP-adres vanuit de adresruimte van het virtuele netwerk. Dit maakt netwerktunneling mogelijk zonder dat on-premises netwerken hoeven te worden geopend tot alle IP-adresbereiken die eigendom zijn van de Azure-opslagclusters.
• Doorsturen via DNS: configureer uw on-premises DNS om de naam van uw opslagaccount (voor de openbare cloudregio's) om te zetten in het IP-adres van uw storageaccount.file.core.windows.net privé-eindpunten.

Als u de netwerken wilt plannen die zijn gekoppeld aan het implementeren van een Azure-bestandsshare, Azure Files aandachtspunten voor netwerken.

Versleuteling

Azure Files ondersteunt twee verschillende soorten versleuteling: versleuteling 'in transit', die betrekking heeft op de versleuteling die wordt gebruikt bij het mounteren/openen van de Azure-bestands share, en versleuteling in rust, die betrekking heeft op de manier waarop de gegevens worden versleuteld wanneer ze op schijf worden opgeslagen.

Versleuteling tijdens overdracht

Standaard is versleuteling in-transit ingeschakeld voor alle Azure-opslagaccounts. Dit betekent dat wanneer u een bestands delen via SMB of toegang via het FileREST-protocol (zoals via de Azure Portal, PowerShell/CLI of Azure SDK's), Azure Files alleen de verbinding toestaat als deze wordt 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-bestands share niet aan elkaar toevoegen als versleuteling in transit is ingeschakeld. Zie onze gedetailleerde documentatie voor Windows, macOSen Linux voor meer informatie over welke besturingssystemen ondersteuning bieden voor SMB 3.x 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, Azure Files ook SMB 2.1, SMB 3.x zonder versleuteling en niet-versleutelde FileREST API-aanroepen via HTTP. De belangrijkste reden om versleuteling in transit uit te schakelen, 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. In Azure Files worden SMB 2.1-verbindingen alleen toegestaan binnen dezelfde Azure-regio als de Azure-bestandsshare. SMB 2.1-clients buiten de Azure-regio van de Azure-bestandsshare, zoals on-premises clients of clients in een andere Azure-regio, hebben geen toegang tot de bestandsshare.

We raden u ten zeerste aan ervoor te zorgen dat versleuteling van gegevens die onderweg zijn 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).

Gegevensbeveiliging

Azure Files een aanpak met meerdere lagen om ervoor te zorgen dat er een back-up van uw gegevens wordt gemaakt, herstelbaar is en wordt beschermd tegen beveiligingsrisico's.

Voorlopig verwijderen

Soft Delete voor bestands shares is een instelling op opslagaccountniveau waarmee u de bestands share kunt herstellen wanneer deze per ongeluk wordt verwijderd. Wanneer een bestands share wordt verwijderd, wordt deze overgeslagen naar een voorlopig verwijderde status in plaats van permanent te worden gewist. U kunt configureren hoe lang tijdelijke verwijderde gegevens kunnen worden hersteld voordat ze permanent worden verwijderd. U kunt de share tijdens deze bewaarperiode op elk gewenst moment weer herstellen.

We raden u aan om voor de meeste bestands shares de knop Voor zacht verwijderen in te laten. Als u een werkstroom hebt waarin het verwijderen van een share gebruikelijk en verwacht is, kunt u besluiten een korte retentieperiode in te stellen of helemaal geen zachte verwijdering in te stellen.

Zie Onopzettelijk verwijderen van gegevens voorkomen voor meer informatie over het verwijderen van gegevens.

Backup

U kunt een back-up maken van uw Azure-bestands share via share-momentopnamen.Dit zijn alleen-lezen, point-in-time kopieën van uw share. Momentopnamen zijn incrementeel, wat betekent dat ze alleen zoveel gegevens bevatten als sinds de vorige momentopname is gewijzigd. U kunt maximaal 200 momentopnamen per bestands share hebben en deze maximaal 10 jaar bewaren. U kunt deze momentopnamen handmatig maken in de Azure Portal, via PowerShell of via de opdrachtregelinterface (CLI), of u kunt Azure Backup. Momentopnamen worden opgeslagen in uw bestands share, wat betekent dat als u uw bestands share verwijdert, uw momentopnamen ook worden verwijderd. Als u de back-ups van momentopnamen wilt beveiligen tegen onbedoeld verwijderen, moet u ervoor zorgen dat voor uw share de functie voor het verwijderen van de momentopname is ingeschakeld.

Azure Backup voor Azure-bestands shares worden de planning en retentie van momentopnamen verwerkt. De mogelijkheden van zijn vader-vader-zoon (GFS) betekenen dat u dagelijkse, wekelijkse, maandelijkse en jaarlijkse momentopnamen kunt maken, elk met hun eigen afzonderlijke retentieperiode. Azure Backup ook de inschakelen van de functie voor zacht verwijderen in en wordt een verwijdervergrendeling voor een opslagaccount gebruikt zodra een bestands share in het account is geconfigureerd voor back-up. Ten laatste biedt Azure Backup bepaalde belangrijke bewakings- en waarschuwingsmogelijkheden waarmee klanten een geconsolideerde weergave van hun back-upmogelijkheden kunnen krijgen.

U kunt herstel op item- en shareniveau uitvoeren in de Azure Portal met behulp Azure Backup. U hoeft alleen maar het herstelpunt (een bepaalde momentopname), het betreffende bestand of de betreffende map, indien relevant, te kiezen en vervolgens de locatie (oorspronkelijk of alternatief) waar u naar wilt herstellen. De back-upservice verwerkt het kopiëren van de momentopnamegegevens en toont de voortgang van het herstellen in de portal.

Zie Over back-ups van Azure-bestands delen voor meer informatie over back-ups.

Uw Azure Files beveiligen met Microsoft Defender voor Storage

Microsoft Defender for Storage biedt een extra beveiligingslaag die waarschuwingen genereert wanneer afwijkende activiteiten in uw opslagaccount worden gedetecteerd, bijvoorbeeld ongebruikelijke toegangspogingen. Er wordt ook een malware-hashreputatieanalyse uitgevoerd en er wordt een waarschuwing over bekende malware gegenereerd. U kunt Microsoft Defender for Storage op abonnements- of opslagaccountniveau configureren via Microsoft Defender for Cloud.

Zie Introduction to Microsoft Defender for Storage (Inleiding tot Microsoft Defender voor meer Storage.

Opslaglagen

Azure Files biedt vier verschillende opslaglagen: premium, geoptimaliseerd voor transacties, dynamisch en statisch. Hiermee kunt u uw shares aanpassen aan de prestaties en prijsvereisten van uw scenario:

• Premium: Premium-bestandsshares worden ondersteund door SSD's (solid-state drives) en bieden consistente hoge prestaties en lage latentie in milliseconden voor de meeste IO-bewerkingen, voor IO-intensieve workloads. Premium-bestandsshares zijn geschikt voor een groot aantal werkbelastingen, zoals databases, hosting van websites en ontwikkelomgevingen. Premium-bestandsshares kunnen worden gebruikt in combinatie met SMB-protocollen (Server Message Block) en NFS-protocollen (Network File System).
• Geoptimaliseerd voor transacties: Voor transacties geoptimaliseerde bestandsshares maken werkbelastingen mogelijk met veel transacties die niet de latentie hebben van Premium bestandsshares. Voor transactie geoptimaliseerde bestandsshares worden aangeboden voor standaard opslaghardware die wordt ondersteund door harde schijven. Transactiegeoptimaliseerd is vaak 'Standaard' genoemd, hoewel dit verwijst naar de opslagmedia in plaats van de laag zelf (de dynamische en statische lagen zijn ook 'standaard' lagen, omdat ze zich in standaard opslaghardware bevinden).
• Dynamisch: Dynamische bestandsshares bieden opslag die is geoptimaliseerd voor scenario's met algemeen gebruik, bijvoorbeeld teamshares. Dynamische bestandsshares worden aangeboden via de standaardopslag die worden ondersteund door HDD's.
• Statisch: Statische bestandsshares bieden kostenefficiënte opslag die is geoptimaliseerd voor online archieven. Statische bestandsshares worden aangeboden via de standaardopslag die worden ondersteund door HDD's.

Premium bestandsshares worden geïmplementeerd in het FileStorage-opslagaccount en zijn alleen beschikbaar in een ingericht factureringsmodel. Raadpleeg Inzicht in inrichting voor premium bestandsshares voor meer informatie over ingerichte factureringsmodellen voor premium bestandsshares. Standaard bestandsshares, zoals geoptimaliseerde, dynamische en statische bestandsshares, worden geïmplementeerd in het opslagaccount voor algemeen gebruik versie 2 (GPv2) en zijn beschikbaar bij betalen als u gaat factureren.

Wanneer u een opslaglaag selecteer voor uw werkbelasting. kunt u uw prestatie- en gebruiksvereisten overwegen. Als voor uw werkbelasting een hogere latentie van één cijfer nodig is, of als u SSD-opslagmedia on-premises gebruikt, is de premium laag waarschijnlijk de beste keuze. Als lage latentie geen probleem is, bijvoorbeeld met teamshares die on-premises zijn gekoppeld aan Azure, of die zich on-premises in de cache bevinden met Azure File Sync, is standaardopslag mogelijk een betere keuze vanuit een kostenperspectief.

Wanneer u een bestandsshare hebt gemaakt in een opslaglaag, kunt u die niet verplaatsen naar andere soorten opslagaccounts. Als u bijvoorbeeld een voor transactie geoptimaliseerde bestandsshare verplaatst naar de premium laag, moet u een nieuwe bestandsshare maken in een FileStorage-opslagaccount en de gegevens kopiëren van uw oorspronkelijke share 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.

Bestandsshares die geïmplementeerd zijn binnen GPv2-opslagaccounts, kunnen worden verplaatst tussen de standaardlagen (voor transactie geoptimaliseerd, dynamisch en statisch) zonder een nieuw opslagaccount te maken en gegevens migreren, maar er worden transactiekosten in rekening gebracht wanneer u uw laag veranderd. Wanneer u een bestandsshare van een dynamischere laag naar een statischere laag verplaatst, worden de schrijftransactiekosten voor de statischere laag in rekening gebracht voor elk bestand in de share. Wanneer u een bestandsshare verplaatst vaan een statischere laag naar een dynamischere laag, worden de leestransactiekosten in rekening gebracht voor elk bestand in de share.

Raadpleeg Azure Files-facturering begrijpen voor meer informatie.

Beperkingen

Standaardbestandsshares met een capaciteit van 100 TiB hebben bepaalde beperkingen.

• Op dit moment worden alleen accounts met lokaal redundante opslag (LRS) en zone-redundante opslag (ZRS) ondersteund.
• Wanneer u grote bestandsshares inschakelt, kunt u opslagaccounts niet converteren naar accounts met geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS).
• Wanneer u grote bestandsshares inschakelt, kunt u deze niet meer uitschakelen.

Redundantie

Om uw gegevens in uw Azure-bestandsshares te beschermen tegen gegevensverlies of beschadiging, bewaren alle Azure-bestandsshares meerdere kopieën van elk bestand wanneer ze worden geschreven. Afhankelijk van de vereisten van uw werkbelasting, kan u aanvullende maten 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. Zo wordt u beschermd tegen gegevensverlies door hardwarefouten, zoals een beschadigd schijfstation. Als zich echter een noodlot voordoet, zoals brand of overstromingen binnen het datacenter, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherkenbaar zijn.
• Zone-redundante opslag (ZRS): met ZRS zijn er drie kopieën van elk bestand opgeslagen, maar deze kopieën zijn 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 de opslag wordt niet geaccepteerd totdat er naar de opslagclusters in alle drie de beschikbaarheidszones wordt geschreven.
• Geografisch redundante opslag (GRS): met GRS hebt u twee regio's, een primaire en secundaire regio. Bestanden worden drie keer opgeslagen in een Azure-opslagcluster in de primaire regio. Schrijf schrijven 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 als gevolg van een natuurramp of een andere vergelijkbare gebeurtenis, voert Microsoft een failover uit en wordt de secundaire regio de primaire regio, die alle bewerkingen verwerkt. Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan gegevens die nog niet zijn gerepliceerd naar de secundaire regio verloren in het geval van een ernstige ramp. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.
• Geografisch zone-redundante opslag (GZRS): U kunt GZRS zien 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.

Standaard Azure-bestands shares van maximaal 5 TiB ondersteunen alle vier de redundantietypen. Standaardbestands shares die groter zijn dan 5 TiB ondersteunen alleen LRS en ZRS. Premium Azure-bestands shares ondersteunen alleen LRS en ZRS.

Opslagaccount voor algemeen gebruik versie 2 (GPv2) bieden twee aanvullende redundantie-opties die niet worden ondersteund door Azure Files: geografisch redundante opslag met leestoegang, vaak RA-GRS genoemd, en geografisch zone-redundante opslag met leestoegang, vaak RA-GZRS genoemd. U kunt Azure-bestandsshares inrichten in opslagaccounts waarin deze opties zijn ingesteld, maar Azure Files ondersteunt het lezen vanuit de secundaire regio niet. Azure-bestandsshares die in geografisch redundante of geografisch zone-redundante opslagaccounts met leestoegang worden geïmplementeerd, worden gefactureerd als respectievelijk geografisch redundante of geografisch zone-redundante opslag.

Migratie

In veel gevallen maakt u geen nieuwe netbestands share voor uw organisatie, maar migreert u in plaats daarvan een bestaande bestands share van 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 slagen van uw migratie.

Het overzichtsartikel over migratie bevat kort de basisprincipes en bevat een tabel die u naar migratiehandleidingen leidt die waarschijnlijk betrekking hebben op uw scenario.

Volgende stappen

• Planning voor een Azure File Sync implementatie
• Implementatie van Azure Files
• Implementatie van Azure File Sync
• Raadpleeg het artikel Over migratieoverzicht om de migratiehandleiding voor uw scenario te vinden