NFS Azure-bestandsshares

Van toepassing op: ✔️ NFS-bestandsdelingen gemaakt met Microsoft.Storage of Microsoft.FileShares

Azure Files ondersteunt twee industriestandaard protocollen voor het koppelen van bestandsshares: het SMB-protocol (Server Message Block) en het NFS-protocol (Network File System). Kies het protocol dat het beste past bij uw workload. Azure-bestandsdelingen ondersteunen geen toegang tot een individuele Azure-bestandsdeling met zowel het SMB- als het NFS-protocol. Voor klassieke bestandsdelingen kun je aparte SMB- en NFS-bestandsdelingen aanmaken binnen hetzelfde FileStorage opslagaccount. Microsoft.FileShares ondersteunt momenteel alleen NFS-bestandsdelingen. Azure Files biedt hoogwaardige bestandsshares die kunnen worden geschaald om te voldoen aan uw opslagbehoeften en die gelijktijdig toegankelijk zijn voor duizenden clients.

In dit artikel worden NFS-Azure bestandsshares behandeld. Zie voor informatie over SMB-bestandsshares in Azure SMB-bestandsshares in Azure Files.

Veelvoorkomende use cases voor NFS-Azure bestandsshares

NFS-bestandsshares werken goed met workloads zoals SAP-toepassingslaag, databaseback-ups, databasereplicatie, berichtenwachtrijen, basismappen voor bestandsservers voor algemeen gebruik en inhoudsopslagplaatsen voor toepassingsworkloads.

NFS-bestandsshares worden vaak gebruikt in de volgende scenario's:

• Back-upopslag voor Linux-/UNIX-toepassingen, zoals Line-Of-Business-toepassingen die zijn geschreven met behulp van Linux- of POSIX-bestandssysteem-API's
• Workloads waarvoor POSIX-compatibele bestandsshares, hoofdlettergevoeligheid of Unix-stijlmachtigingen (UID/GID) zijn vereist
• Nieuwe toepassings- en serviceontwikkeling waarvoor willekeurige I/O en hiërarchische opslag is vereist

Functies voor NFS-Azure bestandsshares

NFS Azure bestandsshares bieden een volledig POSIX-compatibel bestandssysteem. Harde koppelingen en symbolische koppelingen worden ondersteund, maar u kunt geen harde koppeling maken op basis van een bestaande symbolische koppeling.

NFS Azure bestandsshares ondersteunen momenteel de meeste functies uit de protocolspecificatie van NFSv4.1. Sommige functies, zoals delegaties en callback van allerlei soorten, Kerberos-verificatie en ACL's, worden niet ondersteund.

Lokaal redundante opslag (LRS) en zone-redundante opslag (ZRS) worden ondersteund voor NFS-Azure bestandsshares. Geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS) zijn niet beschikbaar voor NFS-shares, omdat NFS SSD-opslag vereist, die geen ondersteuning biedt voor geo-redundantie.

NFS Azure file share-ondersteuning voor Azure Files-functies

In de volgende tabel ziet u het huidige niveau van functieondersteuning voor NFS-Azure bestandsshares. Tenzij anders vermeld, geldt ondersteuning voor zowel klassieke bestandsdelingen (Microsoft.Storage) als bestandsdelingen die met Microsoft.FileShares zijn aangemaakt.

De status van items die in deze tabel worden weergegeven, kan na verloop van tijd veranderen naarmate de ondersteuning blijft uitbreiden.

Beheermodel

NFS Azure bestandsshares ondersteunen twee resourceproviders op het hoogste niveau:

• Microsoft. FileShares (aanbevolen voor nieuwe NFS-implementaties): Hiermee maakt u een zelfstandige bestandsshare zonder opslagaccount. Ondersteunt alleen het ingerichte v2-factureringsmodel.
• Microsoft. Opslag (klassiek): Maakt klassieke bestandsshares binnen een opslagaccount. Ondersteunt geprovisioneerde v1- en v2-factureringsmodellen voor NFS-shares.

Zie Resourceproviders vergelijken: Microsoft.Storage versus Microsoft.FileShares voor een volledige vergelijking van functies.

Beveiliging en netwerken voor NFS-Azure bestandsshares

NFS Azure-bestandsshares beveiligen gegevens met versleuteling van gegevens in rust en tijdens overdracht, en vereisen toegangsbeheer op netwerkniveau in plaats van gebruikersverificatie.

Encryption

Azure Files versleutelt alle in rust opgeslagen gegevens met Azure-opslagserviceversleuteling (SSE). Versleuteling van de opslagservice werkt op dezelfde manier als BitLocker op Windows: hiermee worden gegevens versleuteld onder het bestandssysteemniveau. Omdat versleuteling plaatsvindt onder het bestandssysteem van de Azure bestandsshare, omdat gegevens worden gecodeerd op schijf, hebt u geen toegang nodig tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te lezen of schrijven. Inactieve versleuteling geldt voor zowel SMB- als NFS-protocollen.

Zowel klassieke bestandsdelingen als Microsoft. FileShares-bestandsdelingen ondersteunen TLS-encryptie tijdens transport via de AZNFS-mounthulp. Je configureert encryptie-eisen op verschillende scopes:

• Microsoft. FileShares: Encryptie tijdens transport is standaard vereist. Je stelt deze eis in op de individuele bestandsshare. Bekijk Geavanceerde instellingen bij het aanmaken van een bestandsdeling.
• Klassieke bestandsdelingen: Je stelt Versleuteling in Transit vereisen voor NFS in op het opslagaccount. Voor nieuwe opslagaccounts die via het Azure-portaal worden aangemaakt, is deze instelling standaard ingeschakeld. Wanneer de instelling Niet geselecteerd is, beheert Secure Transfer required het NFS-encryptiegedrag. Voor standaardinstellingen voor het maken en configuratiestappen, zie Enforce encryption in transit.

Azure biedt een versleutelingslaag voor alle gegevens die worden overgedragen tussen Azure datacenters met behulp van MACSec. Via deze technologie bestaat versleuteling wanneer gegevens worden overgedragen tussen Azure datacenters.

Verificatie en netwerktoegang

Omdat NFS Azure-bestandsshares geen gebruikersgebaseerde authenticatie ondersteunen, zijn ze afhankelijk van netwerktoegangsregels om clients te authenticeren. Clients moeten daarom verbinding maken via een privé-endpoint of een service-endpoint met virtuele netwerkbeperkingen.

Zowel klassieke bestandsdelingen als Microsoft.FileShares-bestandsdelingen ondersteunen deze verbindingsopties. Voor klassieke bestandsdelingen configureer je netwerkinstellingen op het opslagaccount. Voor Microsoft.FileShares configureer je de netwerkinstellingen op de afzonderlijke bestandsdeling.

Privé-eindpunten

Een privé-endpoint levert een privé IP-adres in je virtuele netwerk voor toegang tot de bestandsdeling. Om toegang alleen via privé-endpoints toe te staan, schakel de toegang tot het publieke netwerk uit. Er zijn kosten voor Private Link van toepassing.

Clients kunnen verbinding maken vanaf het virtuele netwerk of vanuit peered virtuele netwerken. Voor on-premises toegang verbind je netwerk met het virtuele netwerk via een VPN of ExpressRoute.

Service-eindpunten

Een service-endpoint stelt clients in een subnet in staat toegang te krijgen tot het publieke endpoint van de file share via de Azure-backbone. Schakel het service-eindpunt in op het clientsubnet. Configureer de netwerkregels van de bestandsdeling zo dat dat subnet is toegestaan. Toegestane subnetten kunnen in hetzelfde abonnement zitten of in een ander abonnement, inclusief een andere Microsoft Entra-tenant. Er zijn geen extra kosten voor service-endpoints.

Een service-endpoint wijst geen privé-IP-adres toe aan de bestandsdeling. Als een zeldzame gebeurtenis, zoals een zone-uitval, het IP-adres van het publieke eindpunt verandert, moeten clients mogelijk de share opnieuw mounten.

Optionele uitgaande filtering

De netwerkregels van de bestandsdeling bepalen welke clients erbij kunnen. Ze beperken niet welke andere opslagbronnen die clients kunnen benaderen. Bijvoorbeeld, een client die je bestandsdeling kan lezen, kan data kopiëren naar een andere bron waar hij toestemming voor heeft om naartoe te schrijven.

Voor klassieke bestandsdelingen kun je optioneel een service-endpointbeleid gebruiken om te beperken welke opslagaccounts clients in een subnet via service-endpoints kunnen bereiken. Service endpoint-verkeer omzeilt Azure Firewall en netwerkvirtuele appliances. Een beleidsregel filtert bestemmingen op dit pad. Het beperkt andere uitgaande paden niet en vervangt ook niet de netwerkregels en autorisatievereisten van de bestemming.

Service-endpointbeleid wordt momenteel niet ondersteund voor Microsoft.FileShares-bestandsshares. Als het clientsubnet een beleid heeft, moeten clients een privé-endpoint gebruiken om toegang te krijgen tot die bestandsshares. Voor meer informatie, zie Uitgaande toegang beperken met service-endpointbeleid.

Zie Azure Files netwerkoverwegingen voor meer informatie over netwerkopties.

Regionale beschikbaarheid van NFS-Azure bestandsshare

Regionale beschikbaarheid hangt af van de resourceprovider en de redundantieoptie:

• Microsoft. FileShares: Zie LRS-regio's en ZRS-regio's.
• Klassieke bestandsdelingen: Zie LRS-regio's en ZRS-regio's.

Prestaties van NFS-Azure bestandsshare

NFS-Azure bestandsshares zijn alleen beschikbaar op SSD-bestandsshares. Beide resourceproviders ondersteunen het provisioned v2-facturatiemodel, waarmee je onafhankelijk provisioned capacity, IOPS en throughput kunt instellen. Klassieke bestandsdelingen ondersteunen ook het provisioned v1 facturatiemodel, waarbij IOPS en doorvoersnelheid automatisch schalen met de geprovisioneerde capaciteit. Zie Inzicht in Azure Files facturering voor meer informatie over beide modellen.

Typische I/O-latenties voor Azure-bestandsshares op SSD's liggen voor kleine I/O-bewerkingen in het lage enkelcijferige millisecondebereik. Workloads met veel metagegevens, zoals untar, kunnen hogere latenties ervaren vanwege het grote aantal open- en sluitbewerkingen.

Raadpleeg NFS-prestaties van Azure-bestandsshares verbeteren voor richtlijnen voor het verbeteren van NFS-prestaties op grote schaal.

Volgende stappen

• Maak een bestandsshare met Microsoft.FileShares
• Een klassieke bestandsshare maken
• NFS-opties vergelijken tussen Azure opslagservices