Informazioni sui protocolli NAS in Azure NetApp Files

Articolo
10/24/2023

I protocolli NAS sono il modo in cui le conversazioni avvengono tra client e server. NFS e SMB sono i protocolli NAS usati in Azure NetApp Files. Ognuno offre metodi distinti per la comunicazione, ma alla loro radice operano principalmente nello stesso modo.

Entrambi servono un singolo set di dati a molti client collegati in rete diversi.
Entrambi possono usare metodi di autenticazione crittografati per la condivisione dei dati.
Entrambi possono essere gestiti con autorizzazioni di condivisione e file.
Entrambi possono crittografare i dati in anteprima.
Entrambi possono usare più connessioni per parallelizzare le prestazioni.

File system di rete (NFS)

NFS viene usato principalmente con client basati su Linux/UNIX, ad esempio Red Hat, SU edizione Standard, Ubuntu, AIX, Solaris e Apple OS. Azure NetApp Files supporta qualsiasi client NFS che opera negli standard RFC. Windows può anche usare NFS per l'accesso, ma non funziona usando gli standard RFC (Request for Comments).

Gli standard RFC per i protocolli NFS sono disponibili qui:

NFSv3

NFSv3 è un'offerta di base del protocollo e presenta gli attributi chiave seguenti:

NFSv3 è senza stato, ovvero il server NFS non tiene traccia degli stati delle connessioni (inclusi i blocchi).
Il blocco viene gestito all'esterno del protocollo NFS, usando Network Lock Manager (NLM). Poiché i blocchi non sono integrati nel protocollo, a volte possono verificarsi blocchi non aggiornati.
Poiché NFSv3 è senza stato, le prestazioni con NFSv3 possono essere notevolmente migliori in alcuni carichi di lavoro, in particolare nei carichi di lavoro con operazioni con metadati elevati, ad esempio OPEN, CLO edizione Standard, edizione Standard TATTR e GETATTR. Questo è il caso perché è necessario eseguire operazioni meno generali per elaborare le richieste sul server e sul client.
NFSv3 usa un modello di autorizzazione file di base in cui solo il proprietario del file, un gruppo e tutti gli altri utenti possono essere assegnate una combinazione di autorizzazioni di lettura/scrittura/esecuzione.
NFSv3 può usare ACL NFSv4.x, ma per configurare e gestire gli ACL è necessario un client di gestione NFSv4.x. Azure NetApp Files non supporta l'uso di ACL di bozza POSIX non standard.
NFSv3 richiede anche l'uso di altri protocolli ausiliari per operazioni regolari, ad esempio l'individuazione delle porte, il montaggio, il blocco, il monitoraggio dello stato e le quote. Ogni protocollo ausiliario usa una porta di rete univoca, il che significa che le operazioni NFSv3 richiedono un'esposizione maggiore tramite firewall con numeri di porta noti.
Azure NetApp Files usa i numeri di porta seguenti per le operazioni NFSv3. Non è possibile modificare questi numeri di porta:
- Portmapper (111)
- Montaggio (635)
- NFS (2049)
- NLM (4045)
- NSM (4046)
- Rquota (4049)
NFSv3 può usare miglioramenti per la sicurezza, ad esempio Kerberos, ma Kerberos influisce solo sulla parte NFS dei pacchetti; i protocolli ausiliari (ad esempio NLM, portmapper, montaggio) non sono inclusi nella conversazione Kerberos.
- Azure NetApp Files supporta solo la crittografia Kerberos NFSv4.1
NFSv3 usa ID numerici per l'autenticazione utente e gruppo. Nomi utente e nomi di gruppo non sono necessari per la comunicazione o le autorizzazioni, che possono semplificare lo spoofing di un utente, ma la configurazione e la gestione sono più semplici.
NFSv3 può usare LDAP per le ricerche di utenti e gruppi.

Supporto della versione del servizio NFSv3

NFSv3 supporta attualmente le versioni seguenti di ogni protocollo ausiliario in Azure NetApp Files:

Service	Versioni supportate
Portmapper	4, 3, 2
NFS	4, 3*
Montaggio	3, 2, 1
Nlockmgr	4
Status	1
Rquotas	1

* Le versioni supportate di NFS vengono visualizzate in base alla versione selezionata per il volume di Azure NetApp Files.

Queste informazioni possono essere raccolte dal volume di Azure NetApp Files con il comando seguente:

# rpcinfo -s <Azure NetApp Files IP address>

NFSv4.x

NFSv4.x fa riferimento a tutte le versioni NFS o le versioni secondarie incluse in NFSv4, tra cui NFSv4.0, NFSv4.1 e NFSv4.2. Azure NetApp Files supporta attualmente solo NFSv4.1.

NFSv4.x presenta le caratteristiche seguenti:

NFSv4.x è un protocollo con stato, il che significa che il client e il server tengono traccia degli stati delle connessioni NFS, inclusi gli stati di blocco. Il montaggio NFS usa un concetto noto come "ID stato" per tenere traccia delle connessioni.
Il blocco è integrato nel protocollo NFS e non richiede protocolli di blocco ausiliari per tenere traccia dei blocchi NFS. I blocchi vengono invece concessi in base al lease. Scadono dopo una determinata durata se una connessione client o server viene persa, restituendo così il blocco al sistema da usare con altri client NFS.
Il livello di stato di NFSv4.x contiene alcuni svantaggi, ad esempio potenziali interruzioni durante interruzioni di rete o failover di archiviazione e sovraccarico delle prestazioni in determinati tipi di carico di lavoro, ad esempio carichi di lavoro con metadati elevati.
NFSv4.x offre molti vantaggi significativi rispetto a NFSv3, tra cui:
- Concetti di blocco migliori (blocco basato su lease)
- Maggiore sicurezza (meno porte del firewall necessarie, integrazione standard con Kerberos, controlli di accesso granulari)
- Altre funzionalità
- Operazioni NFS composte (più comandi in una singola richiesta di pacchetti per ridurre la chatter di rete)
- Solo TCP
NFSv4.x può usare un modello di autorizzazione file più affidabile simile alle autorizzazioni NTFS di Windows. Questi elenchi di controllo di accesso granulari possono essere applicati a utenti o gruppi e consentono di impostare le autorizzazioni per un'ampia gamma di operazioni rispetto alle operazioni di lettura/scrittura/esecuzione di base. NFSv4.x può anche usare i bit in modalità POSIX standard usati da NFSv3.
Poiché NFSv4.x non usa protocolli ausiliari, Kerberos viene applicato all'intera conversazione NFS quando in uso.
NFSv4.x usa una combinazione di nomi utente/gruppo e stringhe di dominio per verificare le informazioni su utenti e gruppi. Il client e il server devono accettare le stringhe di dominio affinché venga eseguita l'autenticazione corretta di utenti e gruppi. Se le stringhe di dominio non corrispondono, l'utente o il gruppo NFS viene sottoposto a squash all'utente specificato nel file /etc/idmapd.conf nel client NFS ,ad esempio nessuno.
Anche se per impostazione predefinita NFSv4.x usa stringhe di dominio, è possibile configurare il client e il server per eseguire il fallback sugli ID numerici classici visualizzati in NFSv3 quando AUTH_SYS è in uso.
NFSv4.x include un'integrazione approfondita con stringhe di nome utente e gruppo e il server e i client devono accettare questi utenti e gruppi. Di conseguenza, prendere in considerazione l'uso di un server del servizio dei nomi per l'autenticazione utente, ad esempio LDAP in server e client NFS.

Per domande frequenti su NFS in Azure NetApp Files, vedere domande frequenti su NFS di Azure NetApp Files.

Server Message Block (SMB)

SMB viene usato principalmente con i client Windows per la funzionalità NAS. Tuttavia, può anche essere usato in sistemi operativi basati su Linux, ad esempio AppleOS, RedHat e così via. Questa distribuzione viene eseguita usando un'applicazione denominata Samba. Azure NetApp Files offre il supporto ufficiale per SMB con Windows e macOS. SMB/Samba nei sistemi operativi Linux può funzionare con Azure NetApp Files, ma non è disponibile alcun supporto ufficiale.

Azure NetApp Files supporta solo le versioni SMB 2.1 e SMB 3.1.

SMB presenta le caratteristiche seguenti:

SMB è un protocollo con stato: i client e il server mantengono uno "stato" per le connessioni di condivisione SMB per una maggiore sicurezza e blocco.
Il blocco in SMB è considerato obbligatorio. Quando un file è bloccato, nessun altro client può scrivere in tale file fino al rilascio del blocco.
SMBv2.x e versioni successive usano chiamate composte per eseguire operazioni.
SMB supporta l'integrazione Kerberos completa. Con il modo in cui vengono configurati i client Windows, Kerberos viene spesso usato senza che gli utenti finali sappiano mai.
Quando Kerberos non è in grado di essere usato per l'autenticazione, è possibile usare Windows NT LAN Manager (NTLM) come fallback. Se NTLM è disabilitato nell'ambiente Active Directory, le richieste di autenticazione che non possono usare Kerberos hanno esito negativo.
SMBv3.0 e versioni successive supporta la crittografia end-to-end per le condivisioni SMB.
SMBv3.x supporta il multicanale per ottenere miglioramenti delle prestazioni in determinati carichi di lavoro.
SMB usa nomi di utenti e gruppi (tramite conversione SID) per l'autenticazione. Le informazioni relative a utenti e gruppi vengono fornite da un controller di dominio di Active Directory.
SMB in Azure NetApp Files usa gli ACL standard di Windows New Technology File System (NTFS) per le autorizzazioni per file e cartelle.

Per domande frequenti su SMB in Azure NetApp Files, vedere domande frequenti su SMB di Azure NetApp Files.

Protocolli duali

Alcune organizzazioni dispongono di ambienti Windows o UNIX puri (omogenei) in cui tutti i dati sono accessibili usando solo uno degli approcci seguenti:

Sicurezza dei file SMB e NTFS
Sicurezza dei file NFS e UNIX : bit in modalità o elenchi di controllo di accesso NFSv4.x (ACL)

Tuttavia, molti siti devono consentire l'accesso ai set di dati dai client Windows e UNIX (eterogenei). Per gli ambienti con questi requisiti, Azure NetApp Files include il supporto NAS a doppio protocollo nativo. Dopo che l'utente è stato autenticato in rete e ha autorizzazioni di condivisione o esportazione appropriate e le autorizzazioni necessarie a livello di file, l'utente può accedere ai dati dagli host UNIX usando NFS o da host Windows usando SMB.

Motivi per l'uso di volumi a doppio protocollo

L'uso di volumi a doppio protocollo con Azure NetApp Files offre diversi vantaggi distinti. Quando i set di dati possono essere facilmente accessibili contemporaneamente dai client che usano protocolli NAS diversi, è possibile ottenere i vantaggi seguenti:

Ridurre le attività generali di gestione dell'amministratore di archiviazione.
Richiedere solo una singola copia dei dati da archiviare per l'accesso NAS da più tipi di client.
Il protocollo NAS indipendente consente agli amministratori di archiviazione di controllare lo stile dell'ACL e il controllo di accesso presentati agli utenti finali.
Centralizzare le operazioni di gestione delle identità in un ambiente NAS.

Considerazioni comuni con ambienti a doppio protocollo

L'accesso NAS a doppio protocollo è auspicabile da molte organizzazioni per la sua flessibilità. Tuttavia, esiste una percezione di difficoltà che crea un set di considerazioni univoche per il concetto di condivisione tra protocolli. Queste considerazioni includono, ma non sono limitate a:

Requisito di conoscenza tra più protocolli, sistemi operativi e sistemi di archiviazione.
Conoscenza dei server del servizio dei nomi, ad esempio DNS, LDAP e così via.

Inoltre, i fattori esterni possono entrare in gioco, ad esempio:

Gestione di più reparti e gruppi IT (ad esempio gruppi windows e gruppi UNIX)
Acquisizioni aziendali
Consolidamento dei domini
Riorganizzazioni

Nonostante queste considerazioni, la configurazione, la configurazione e l'accesso nas a doppio protocollo possono essere semplici e perfettamente integrati in qualsiasi ambiente.

In che modo Azure NetApp Files semplifica l'uso con doppio protocollo

Azure NetApp Files consolida l'infrastruttura necessaria per ambienti NAS a doppio protocollo in un unico piano di gestione, inclusi i servizi di gestione delle identità e di archiviazione.

La configurazione a doppio protocollo è semplice e la maggior parte delle attività è schermata dal framework di gestione delle risorse di Azure NetApp Files per semplificare le operazioni per gli operatori cloud.

Dopo aver stabilito una connessione Active Directory con Azure NetApp Files, i volumi a doppio protocollo possono usare la connessione per gestire sia la gestione delle identità Windows che UNIX necessarie per l'autenticazione corretta di utenti e gruppi con i volumi di Azure NetApp Files senza passaggi di configurazione aggiuntivi al di fuori della normale gestione di utenti e gruppi all'interno dei servizi Active Directory o LDAP.

Rimuovendo i passaggi aggiuntivi incentrati sullo spazio di archiviazione per le configurazioni con doppio protocollo, Azure NetApp Files semplifica la distribuzione complessiva a doppio protocollo per le organizzazioni che cercano di passare ad Azure.

Funzionamento dei volumi a doppio protocollo di Azure NetApp Files

A livello generale, i volumi a doppio protocollo di Azure NetApp Files usano una combinazione di stili di mapping dei nomi e autorizzazioni per offrire un accesso coerente ai dati indipendentemente dal protocollo in uso. Ciò significa che se si accede a un file da NFS o SMB, è possibile assicurarsi che gli utenti con accesso a tali file possano accedervi e gli utenti senza accesso a tali file non possono accedervi.

Quando un client NAS richiede l'accesso a un volume a doppio protocollo in Azure NetApp Files, si verificano le operazioni seguenti per offrire un'esperienza trasparente all'utente finale.

Un client NAS stabilisce una connessione NAS al volume a doppio protocollo di Azure NetApp Files.
Il client NAS passa le informazioni sull'identità utente ad Azure NetApp Files.
Azure NetApp Files verifica che il client NAS o l'utente abbia accesso alla condivisione NAS.
Azure NetApp Files accetta tale utente e lo esegue il mapping a un utente valido trovato nei servizi dei nomi.
Azure NetApp Files confronta l'utente con le autorizzazioni a livello di file nel sistema.
Le autorizzazioni per i file controllano il livello di accesso dell'utente.

Nella figura seguente viene user1 eseguita l'autenticazione ad Azure NetApp Files per accedere a un volume a doppio protocollo tramite SMB o NFS. Azure NetApp Files trova le informazioni windows e UNIX dell'utente in Microsoft Entra ID e quindi esegue il mapping delle identità Windows e UNIX dell'utente uno a uno. L'utente viene verificato come user1 e ottiene user1le credenziali di accesso.

In questo caso, user1 ottiene il controllo completo sulla propria cartella (user1-dir) e nessun accesso alla HR cartella. Questa impostazione si basa sugli ACL di sicurezza specificati nel file system e user1 otterrà l'accesso previsto indipendentemente dal protocollo da cui accedono i volumi.

Considerazioni per i volumi a doppio protocollo di Azure NetApp Files

Quando si usano volumi di Azure NetApp Files per l'accesso a SMB e NFS, si applicano alcune considerazioni:

È necessaria una connessione Active Directory. Di conseguenza, è necessario soddisfare i requisiti per le connessioni di Active Directory.
I volumi a doppio protocollo richiedono una zona di ricerca inversa in DNS con un record PTR (Pointer) associato del computer host DI AD per evitare errori di creazione del volume a doppio protocollo.
Il client NFS e i pacchetti associati (ad esempio nfs-utils) devono essere aggiornati per garantire la massima sicurezza, affidabilità e supporto delle funzionalità.
I volumi a doppio protocollo supportano sia Dominio di Active Directory Services (AD DS) che Microsoft Entra Domain Services.
I volumi a doppio protocollo non supportano l'uso di LDAP tramite TLS con Microsoft Entra Domain Services. Vedere Considerazioni su LDAP su TLS.
Le versioni NFS supportate includono: NFSv3 e NFSv4.1.
Le funzionalità NFSv4.1, ad esempio pNFS (Parallel Network File System), i trunking delle sessioni e le segnalazioni non sono attualmente supportate con i volumi di Azure NetApp Files.
Gli attributi set/get estesi di Windows non sono supportati nei volumi a doppio protocollo.
Vedere considerazioni aggiuntive per la creazione di un volume a doppio protocollo per Azure NetApp Files.

Condividi tramite