Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: ✔️ condivisioni file NFS create con Microsoft.Storage o Microsoft.FileShares
File di Azure supporta due protocolli standard di settore per il montaggio di condivisioni file: il protocollo SMB (Server Message Block) e il protocollo NFS (Network File System). Scegliere il protocollo più adatto al carico di lavoro. Le condivisioni file Azure non supportano l'accesso a una singola condivisione file Azure sia con i protocolli SMB che NFS. Per le condivisioni file classiche, puoi creare condivisioni file SMB e NFS separate all'interno dello stesso account di archiviazione FileStorage. Microsoft. FileShares attualmente supporta solo condivisioni file NFS. File di Azure offre condivisioni file di livello aziendale che possono aumentare le prestazioni per soddisfare le esigenze di archiviazione e possono essere accessibili simultaneamente da migliaia di client.
Questo articolo illustra le condivisioni file di NFS Azure. Per informazioni sulle condivisioni file SMB in Azure, vedere condivisioni file SMB in File di Azure.
Importante
Le condivisioni file NFS Azure non sono supportate per Windows. Prima di usare le condivisioni di file NFS di Azure nell'ambiente di produzione, vedere Risoluzione dei problemi delle condivisioni di file NFS di Azure per una lista di problemi noti. Gli elenchi di controllo di accesso (ACL) NFS non sono supportati.
Casi d'uso comuni per le condivisioni file NFS Azure
Le condivisioni file NFS funzionano bene con carichi di lavoro come il livello applicazione SAP, i backup del database, la replica del database, le code di messaggistica, le home directory per i file server per utilizzo generico e i repository di contenuti per i carichi di lavoro dell'applicazione.
Le condivisioni file NFS vengono spesso usate negli scenari seguenti:
- Archiviazione di backup per applicazioni basate su Linux/UNIX, ad esempio applicazioni line-of-business scritte con API di file system Linux o POSIX
- Carichi di lavoro che richiedono condivisioni file conformi a POSIX, distinzione tra maiuscole e minuscole o autorizzazioni di stile Unix (UID/GID)
- Sviluppo di nuove applicazioni e servizi che richiedono operazioni di I/O casuali e archiviazione gerarchica
Funzionalità di condivisione file NFS Azure
Le condivisioni file NFS di Azure offrono un file system completamente conforme a POSIX. Sono supportati collegamenti rigidi e collegamenti simbolici, ma non è possibile creare un collegamento rigido da un collegamento simbolico esistente.
Le condivisioni file NFS di Azure supportano attualmente la maggior parte delle funzionalità della specifica del protocollo NFSv4.1. Alcune funzionalità, ad esempio le deleghe e il callback di tutti i tipi, l'autenticazione Kerberos e gli ACL, non sono supportate.
L'archiviazione con ridondanza locale e l'archiviazione con ridondanza della zona sono supportate per le condivisioni file di NFS Azure. L'archiviazione con ridondanza geografica (GRS) e l'archiviazione con ridondanza geografica della zona (GZRS) non sono disponibili per le condivisioni NFS perché NFS richiede l'archiviazione su SSD, che non supporta la ridondanza geografica.
Supporto NFS Azure file share per funzionalità di File di Azure
La tabella seguente illustra il livello corrente di supporto delle funzionalità per le condivisioni file NFS di Azure. Salvo diversa indicazione, il supporto si applica sia alle condivisioni file classiche (Microsoft.Storage) sia alle condivisioni file create con Microsoft.FileShares.
Lo stato delle voci visualizzate in questa tabella può cambiare nel tempo man mano che il supporto continua a espandersi.
Note
Il limite di 16 gruppi è un vincolo di protocollo NFS. Ogni utente è limitato a 16 ID gruppo (GID) per ogni connessione.
Modello di gestione
Le condivisioni file NFS Azure supportano due provider di risorse di primo livello:
- Microsoft.FileShares (consigliato per le nuove distribuzioni NFS): crea una condivisione file autonoma senza un account di archiviazione. Supporta solo il modello di fatturazione v2 con provisioning.
- Microsoft. Archiviazione (versione classica): crea condivisioni file classiche all'interno di un account di archiviazione. Supporta modelli di fatturazione provisionati v1 e v2 per le condivisioni NFS.
Per un confronto completo delle funzionalità, vedere Confronto tra provider di risorse: Microsoft. Archiviazione e Microsoft. Condivisioni file.
Sicurezza e rete per condivisioni file NFS Azure
Le condivisioni file NFS di Azure proteggono i dati tramite la crittografia dei dati archiviati e in transito e richiedono controlli di accesso a livello di rete anziché l'autenticazione basata sull'utente.
Encryption
File di Azure crittografa tutti i dati inattivi usando la crittografia del servizio di archiviazione di Azure. La crittografia del servizio di archiviazione funziona in modo analogo a BitLocker in Windows: crittografa i dati sotto il livello del file system. Poiché la crittografia si verifica sotto il file system della condivisione file Azure perché i dati vengono codificati su disco, non è necessario accedere alla chiave sottostante nel client per leggere o scrivere nella condivisione file Azure. La crittografia dati inattivi si applica a entrambi i protocolli SMB e NFS.
Sia le condivisioni di file classiche che le condivisioni di file Microsoft.FileShares supportano la crittografia TLS durante il transito tramite helper di montaggio AZNFS. Si configurano i requisiti di crittografia a diversi livelli:
- Microsoft.FileShares: La crittografia durante il transito è richiesta di default. Configuri questo requisito sulla singola condivisione file. Vedi Impostazioni avanzate quando crei una condivisione file.
- Condivisioni file classiche: Configuri l'opzione Richiedi la crittografia in transito per NFS sull'account di archiviazione. Per i nuovi account di archiviazione creati tramite il portale Azure, questa impostazione è abilitata di default. Quando l'impostazione è Non selezionata, Secure transfer required regola il comportamento di crittografia NFS. Per i valori predefiniti di creazione e i passaggi di configurazione, vedi Imporre la crittografia in transito.
Azure fornisce un livello di crittografia per tutti i dati in transito tra i data center Azure tramite MACSec. Tramite questa tecnologia, la crittografia esiste quando i dati vengono trasferiti tra Azure data center.
Autenticazione e accesso alla rete
Poiché le condivisioni file NFS Azure non supportano l'autenticazione basata sull'utente, si basano su regole di accesso alla rete per autenticare i client. I client devono quindi connettersi tramite un endpoint privato o un endpoint di servizio con restrizioni di rete virtuale.
Sia le condivisioni di file classiche che le condivisioni di file Microsoft.FileShares supportano queste opzioni di connessione. Per le condivisioni file classiche, si configura la rete sull'account di archiviazione. Per Microsoft.FileShares, configuri la rete nella singola condivisione file.
Gli endpoint privati
Un endpoint privato fornisce un indirizzo IP privato nella tua rete virtuale per l'accesso alla condivisione file. Per consentire l'accesso solo tramite endpoint privati, disabilita l'accesso alla rete pubblica. Si applicano le tariffe collegamento privato.
I client possono connettersi dalla rete virtuale o da reti virtuali peered. Per l'accesso on-premises, collega la tua rete alla rete virtuale tramite una VPN o ExpressRoute.
Punti finali del servizio
Un endpoint di servizio permette ai clienti in una subnet di accedere all'endpoint pubblico della condivisione file tramite la backbone di Azure. Abilita l'endpoint del servizio sulla subnet client. Configura le regole di rete della condivisione file per consentire quella subrete. Le subnet consentite possono essere nello stesso abbonamento o in un abbonamento diverso, incluso un tenant Microsoft Entra diverso. Non ci sono costi aggiuntivi per gli endpoint di servizio.
Un endpoint di servizio non assegna un indirizzo IP privato alla condivisione file. Se un evento raro, come un'interruzione di zona, modifica l'indirizzo IP dell'endpoint pubblico, i client potrebbero dover rimontare la condivisione.
Filtraggio in uscita opzionale
Le regole di rete della condivisione file controllano quali client possono accedervi. Non limitano a quali altre risorse di archiviazione tali client possono accedere. Ad esempio, un client che può leggere la tua condivisione file potrebbe copiare i dati su un'altra risorsa su cui ha il permesso di scrivere.
Per le condivisioni file classiche, puoi opzionalmente usare una policy di endpoint di servizio per limitare a quali account di archiviazione i client in una subnet possono accedere tramite endpoint di servizio. Il traffico degli endpoint di servizio bypassa Firewall di Azure e gli appliance virtuali di rete. Un criterio filtra le destinazioni su questo percorso. Non limita altri percorsi in uscita né sostituisce le regole di rete e i requisiti di autorizzazione della destinazione.
I criteri degli endpoint di servizio non sono attualmente supportati per le condivisioni file Microsoft.FileShares. Se la subnet client ha una policy, i client devono utilizzare un endpoint privato per accedere a quelle condivisioni di file. Per maggiori informazioni, vedi Restringi l'accesso in uscita con le policy degli endpoint di servizio.
Per altre informazioni sulle opzioni di rete, vedere File di Azure considerazioni sulla rete.
Disponibilità a livello di area geografica della condivisione file di Azure NFS
La disponibilità regionale dipende dal fornitore di risorse e dall'opzione di ridondanza:
- Microsoft.FileShares: Vedi regioni LRS e regioni ZRS.
- Condivisioni file classiche: vedi regioni LRS e regioni ZRS.
Prestazioni di condivisione file NFS Azure
Le condivisioni file Azure NFS sono disponibili solo per le condivisioni file SSD. Entrambi i fornitori di risorse supportano il modello di fatturazione provisioned v2, che permette di impostare capacità provisioned, IOPS e throughput in modo indipendente. Le condivisioni file classiche supportano anche il modello di fatturazione provisioned v1, in cui IOPS e throughput scalano automaticamente con la capacità provisioned. Per informazioni dettagliate su entrambi i modelli, vedere Informazioni sulla fatturazione File di Azure.
Le latenze di I/O tipiche per le condivisioni file SSD Azure si trovano nell'intervallo di millisecondi a singola cifra bassa per operazioni di I/O di piccole dimensioni. I carichi di lavoro ad alta intensità di metadati, come untar, potrebbero presentare latenze più elevate a causa dell'elevato volume di operazioni di apertura e chiusura.
Per indicazioni sul miglioramento delle prestazioni NFS su larga scala, vedere Migliorare le prestazioni delle condivisioni file di NFS Azure.