Condivisioni file di Azure NFS
File di Azure offre due protocolli di file system standard del settore per il montaggio di condivisioni file di Azure: il protocollo SMB (Server Message Block) e il protocollo NFS (Network File System), per consentire agli utenti di scegliere il protocollo più adatto al carico di lavoro. Le condivisioni file di Azure non supportano l'accesso a una singola condivisione file di Azure con entrambi i protocolli SMB e NFS, anche se è possibile creare condivisioni file SMB e NFS all'interno dello stesso account di archiviazione FileStorage. 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 Azure NFS. Per informazioni sulle condivisioni file di Azure SMB, vedere Condivisioni file SMB in File di Azure.
Importante
Le condivisioni file di Azure NFS non sono supportate per Windows. Prima di usare condivisioni file di Azure NFS nell'ambiente di produzione, vedere Risolvere i problemi relativi alle condivisioni file di Azure NFS per un elenco dei problemi noti. Gli elenchi di controllo di accesso (ACL) NFS non sono supportati.
Scenari comuni
Le condivisioni file NFS vengono spesso usate negli scenari seguenti:
- Archiviazione di supporto per applicazioni basate su Linux/UNIX, ad esempio applicazioni line-of-business scritte con API file system Linux o POSIX (anche se non richiedono la conformità POSIX).
- Carichi di lavoro che richiedono condivisioni file conformi a POSIX, distinzione tra maiuscole e minuscole o autorizzazioni di tipo Unix (UID/GID).
- Sviluppo di nuove applicazioni e servizi, in particolare se tale applicazione o servizio ha un requisito per l'I/O casuale e l'archiviazione gerarchica.
Funzionalità
- File system completamente conforme a POSIX.
- Supporto per collegamenti reali.
- Supporto per collegamenti simbolici.
- Le condivisioni file NFS supportano attualmente solo la maggior parte delle funzionalità della specifica del protocollo 4.1. Alcune funzionalità, come deleghe e callback di tutte le tipologie, autenticazione Kerberos, elenchi di controllo di accesso e crittografia dei dati in transito non sono supportate.
Nota
La creazione di un collegamento reale da un collegamento simbolico esistente non è attualmente supportata.
Sicurezza e rete
Tutti i dati archiviati in File di Azure vengono crittografati quando sono inattivi usando la crittografia del servizio di archiviazione di Azure. La crittografia del servizio di archiviazione funziona in modo analogo a BitLocker in Windows in quanto i dati vengono crittografati sotto il livello del file system. Dal momento che i dati vengono crittografati sotto il file system della condivisione file di Azure, perché sono codificati su disco, non è necessario avere accesso alla chiave sottostante nel client per leggere o scrivere nella condivisione file di Azure. La crittografia dati inattivi si applica a entrambi i protocolli SMB e NFS.
Per la crittografia in transito, Azure fornisce un livello di crittografia per tutti i dati in transito tra i data center di Azure usando lo standard di sicurezza MACSec. In questo caso, i dati sono crittografati quando vengono trasferiti tra i data center di Azure.
A differenza delle condivisioni file di Azure che usano il protocollo SMB, le condivisioni file che usano il protocollo NFS non offrono l'autenticazione basata sull'utente. L'autenticazione per le condivisioni NFS è basata sulle regole di sicurezza di rete configurate. Per questo motivo, per garantire che vengano stabilite solo connessioni sicure alla condivisione NFS, è necessario configurare un endpoint privato o un endpoint servizio per l'account di archiviazione.
Un endpoint privato (denominato anche collegamento privato) fornisce all'account di archiviazione un indirizzo IP privato statico all'interno della rete virtuale, evitando interruzioni della connettività causate da modifiche all'indirizzo IP dinamico. Il traffico verso l'account di archiviazione rimane all'interno di reti virtuali con peering, incluse quelle in altre aree e in locale. Si applicano le tariffe di elaborazione dati Standard.
Se non è necessario un indirizzo IP statico, è possibile abilitare un endpoint servizio per File di Azure all'interno della rete virtuale. Un endpoint servizio configura gli account di archiviazione per consentire l'accesso solo da subnet specifiche. Le subnet consentite possono appartenere a una rete virtuale nella stessa sottoscrizione o a una sottoscrizione diversa, incluse quelle appartenenti a un tenant Microsoft Entra diverso. Non sono previsti costi aggiuntivi per l'uso degli endpoint di servizio. Tenere tuttavia presente che un evento raro, ad esempio un'interruzione di servizio a livello di zona, potrebbe causare la modifica dell'indirizzo IP sottostante dell'account di archiviazione. Anche se i dati saranno ancora disponibili nella condivisione file, il client richiederebbe un rimontaggio della condivisione.
Se si vuole accedere alle condivisioni dall'ambiente locale, è necessario configurare una VPN o ExpressRoute oltre a un endpoint privato. Le richieste che non provengono dalle origini seguenti verranno rifiutate:
Per informazioni dettagliate sulle opzioni di rete disponibili, vedere Considerazioni sulla rete di File di Azure.
Supporto per le funzionalità di Archiviazione di Azure
La tabella seguente mostra il livello corrente di supporto per le funzionalità di Archiviazione di Azure negli account con la funzionalità NFS 4.1 abilitata.
Lo stato delle voci visualizzate in questa tabella può cambiare nel tempo man mano che il supporto continua a espandersi.
Disponibilità a livello di area
Le condivisioni file NFS di Azure sono supportate in tutte le stesse aree che supportano l'archiviazione file Premium.
Per l'elenco più aggiornato, vedere la voce Archiviazione file Premium nella pagina per i prodotti Azure disponibili in base all'area.
Prestazioni
Le condivisioni file di Azure NFS sono disponibili solo nelle condivisioni file Premium, che archiviano i dati su unità SSD (Solid State Drive). Le operazioni di I/O al secondo e la velocità effettiva delle condivisioni NFS vengono ridimensionate in base alla capacità di cui è stato effettuato il provisioning. Vedere la sezione modello con provisioning dell'articolo Informazioni sulla fatturazione per comprendere le formule per operazioni di I/O al secondo, bursting di I/O e velocità effettiva. Le latenze medie di I/O sono di pochissimi millisecondi per dimensioni di I/O, mentre le latenze medie dei metadati sono più elevate, ma inferiori ai 10 millisecondi. Le operazioni che prevedono un utilizzo elevato di metadati, ad esempio untar e carichi di lavoro come WordPress, potrebbero riscontrare ulteriori latenze a causa del numero elevato di operazioni di apertura e di chiusura.
Nota
È possibile usare l'opzione di montaggio nconnect Linux per migliorare le prestazioni per le condivisioni file di Azure NFS su larga scala. Per altre informazioni, vedere Migliorare le prestazioni delle condivisioni file di Azure NFS.
Carichi di lavoro
Importante
Prima di usare condivisioni file di Azure NFS nell'ambiente di produzione, vedere Risolvere i problemi relativi alle condivisioni file di Azure NFS per un elenco dei problemi noti.
Il protocollo NFS è stato convalidato per garantire un funzionamento corretto con carichi di lavoro come livello applicazione SAP, backup del database, replica di database, code di messaggistica, home directory per i file server per utilizzo generico e repository di contenuto per i carichi di lavoro dell'applicazione.