Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: ✔️ NFS-bestandsshares
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 bestandsshares bieden geen ondersteuning voor toegang tot een afzonderlijke Azure bestandsshare met zowel de SMB- als NFS-protocollen, hoewel u SMB- en NFS-bestandsshares binnen hetzelfde FileStorage-opslagaccount kunt maken. 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.
Belangrijk
NFS-Azure bestandsshares worden niet ondersteund voor Windows. Zie Roubleshoot NFS Azure bestandsshares voor een lijst met bekende problemen voordat u NFS Azure in productie gebruikt. NFS-toegangsbeheerlijsten (ACL's) worden niet ondersteund.
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.
Ondersteuning voor NFS-Azure bestandsshares voor Azure-opslagfuncties
In de volgende tabel ziet u het huidige niveau van functieondersteuning voor NFS-Azure bestandsshares.
De status van items die in deze tabel worden weergegeven, kan na verloop van tijd veranderen naarmate de ondersteuning blijft uitbreiden.
| Opslagfunctie | Ondersteund voor NFS-shares |
|---|---|
| REST API voor bestandsbeheervlak | ✔️ |
| REST API voor bestandsdatavlak | ✔️ |
| Versleuteling 'at rest' | ✔️ |
| versleuteling tijdens overdracht | ✔️ |
| LRS- of ZRS-redundantietypen | ✔️ |
| Conversie van LRS naar ZRS of omgekeerd (alleen privé-eindpunten) | ✔️ |
| GRS- of GZRS-redundantietypen | ⛔ |
| Azure DNS Zone-eindpunten (preview) | ✔️ |
| Privé-eindpunten | ✔️ |
| Onderbevestigingen voor submappen | ✔️ |
| Verleen netwerktoegang tot specifieke Azure virtuele netwerken | ✔️ |
| Netwerktoegang verlenen tot specifieke IP-adressen | ⛔ |
| SSD-opslaglaag | ✔️ |
| HDD-mediumlaag | ⛔ |
| POSIX-machtigingen | ✔️ |
| Wortelpompoen | ✔️ |
| Dezelfde gegevens openen vanuit Windows- en Linux-client | ⛔ |
| Verificatie op basis van identiteit | ⛔ |
| Azure bestandsshare voorlopig verwijderen | ✔️ |
| Azure File Sync | ⛔ |
| Azure back-ups van bestandsdeling | ⛔ |
| Azure momentopnamen van bestandsdeling | ✔️ |
| AzCopy | ✔️ |
| Azure Storage Explorer | ✔️ |
| Azure Storage Browser op Azure portal | ⛔ |
| Ondersteuning voor meer dan 16 groepen | ⛔ |
Notitie
De limiet van 16 groepen is een NFS-protocolbeperking. Elke gebruiker is beperkt tot 16 groeps-id's (GID's) per verbinding.
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 ingerichte v1- en v2-factureringsmodellen en de volledige Azure Files functieset.
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.
Voor versleuteling in transit verbeteren Azure Files NFSv4.1-volumes de netwerkbeveiliging door beveiligde TLS-verbindingen tussen de server en de client in te schakelen, waardoor gegevens die worden verzonden, worden beschermd tegen onderschepping. Azure Files biedt een toegewezen Versleuteling in transit voor NFS om onafhankelijk te bepalen of versleuteling vereist is voor NFS-toegang. Voor nieuwe opslagaccounts die zijn gemaakt met behulp van de Azure-portal, is deze instelling standaard ingeschakeld. Opslagaccounts die zijn gemaakt met behulp van Azure PowerShell, Azure CLI of de FileREST-API, stellen deze waarde in op Not selected om compatibiliteit met eerdere versies te garanderen. Voor bestaande opslagaccounts blijft de vereiste instelling voor veilige overdracht het gedrag van NFS-versleuteling beheren totdat u de instelling per protocol expliciet configureert.
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
In tegenstelling tot Azure Files, die het SMB-protocol gebruiken, bieden bestandsshares die gebruikmaken van het NFS-protocol geen gebruikersgebaseerde verificatie. Verificatie voor NFS-shares is gebaseerd op de geconfigureerde netwerkbeveiligingsregels. Om deze reden moet u, om ervoor te zorgen dat uw NFS-share alleen beveiligde verbindingen accepteert, een privé-eindpunt of een service-eindpunt instellen voor uw opslagaccount.
Een privé-eindpunt (ook wel een privékoppeling genoemd) geeft uw opslagaccount een privé, statisch IP-adres in uw virtuele netwerk, waardoor onderbrekingen van de connectiviteit niet kunnen worden gewijzigd door dynamische IP-adressen. Verkeer naar uw opslagaccount blijft binnen gekoppelde virtuele netwerken, inclusief die in andere regio's en on-premises. Standaardtarieven voor gegevensverwerking zijn van toepassing.
Als u geen statisch IP-adres nodig hebt, kunt u een service-eindpunt inschakelen voor Azure Files in het virtuele netwerk. Een service-eindpunt configureert opslagaccounts om alleen toegang vanaf specifieke subnetten toe te staan. De toegestane subnetten kunnen deel uitmaken van een virtueel netwerk in hetzelfde abonnement of een ander abonnement, inclusief subnetten die deel uitmaken van een andere Microsoft Entra tenant. Er worden geen extra kosten in rekening gebracht voor het gebruik van service-eindpunten. Een zeldzame gebeurtenis, zoals een zonestoring, kan echter het onderliggende IP-adres van het opslagaccount wijzigen. Hoewel de gegevens nog steeds beschikbaar zijn op de bestandsshare, moet u de share opnieuw koppelen.
Als u toegang wilt krijgen tot shares vanuit on-premises, stelt u een VPN of ExpressRoute in naast een privé-eindpunt. Aanvragen die niet afkomstig zijn van de volgende bronnen, worden geweigerd:
Zie Azure Files netwerkoverwegingen voor meer informatie over netwerkopties.
Regionale beschikbaarheid van NFS-Azure bestandsshare
NFS Azure-bestandsshares worden ondersteund in alle regio's die SSD-bestandsshares ondersteunen. Zie Azure producten beschikbaar per regio.
Prestaties van NFS-Azure bestandsshare
NFS-Azure bestandsshares zijn alleen beschikbaar op SSD-bestandsshares. Onder het ingerichte v2-factureringsmodel kunt u ingerichte capaciteit, IOPS en doorvoer onafhankelijk instellen, zodat u nauwkeurige kostenbeheer hebt voor NFS-workloads met voorspelbare I/O-patronen. Volgens het geprovisioneerde v1-facturatiemodel schalen IOPS en doorvoer automatisch mee 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.