Protocollo NFS. File System di rete (NFS) - file system di rete

Quando si tratta di reti di computer, spesso si sente parlare di NFS. Cosa significa questo acronimo?

È un protocollo di file system distribuito originariamente sviluppato da Sun Microsystems nel 1984 che consente a un utente su un computer client di accedere ai file su una rete in modo simile all'accesso all'archiviazione locale. NFS, come molti altri protocolli, si basa sul sistema Open Network Computing Remote Procedure Call (ONC RPC).

In altre parole, cos'è NFS? Si tratta di uno standard aperto, definito nella Request for Comments (RFC), che consente a chiunque di implementare il protocollo.

Versioni e varianti

L'inventore utilizzò solo la prima versione per i propri scopi sperimentali. Quando il team di sviluppo ha aggiunto modifiche significative all'NFS originale e l'ha rilasciato al di fuori della proprietà di Sun, ha designato la nuova versione come v2 in modo da poter testare l'interoperabilità tra le distribuzioni e fare un fallback.

NFS v2

La versione 2 originariamente funzionava solo con lo User Datagram Protocol (UDP). I suoi sviluppatori volevano mantenere il lato server senza bloccare al di fuori del protocollo principale.

L'interfaccia del file system virtuale consente un'implementazione modulare riflessa in un semplice protocollo. Nel febbraio 1986, furono dimostrate soluzioni per sistemi operativi come System V release 2, DOS e VAX / VMS utilizzando Eunice. NFS v2 consentiva la lettura solo dei primi 2 GB di un file a causa delle limitazioni a 32 bit.

NFS v3

La prima proposta per sviluppare NFS versione 3 presso Sun Microsystems è stata annunciata poco dopo il rilascio della seconda distribuzione. La motivazione principale era cercare di mitigare il problema delle prestazioni di scrittura sincrona. Nel luglio 1992, miglioramenti pratici avevano risolto molte delle carenze della versione 2 di NFS, lasciando solo un supporto file inadeguato (dimensioni dei file a 64 bit e offset).

• Supporto per dimensioni di file a 64 bit e offset per l'elaborazione di dati superiori a 2 gigabyte (GB);
• supporto per la registrazione asincrona sul server per migliorare le prestazioni;
• attributi di file aggiuntivi in ​​molte risposte per evitare di doverli recuperare di nuovo;
• un'operazione READDIRPLUS per ottenere dati e attributi insieme ai nomi dei file durante la scansione di una directory;
• molti altri miglioramenti.

Durante l'introduzione della versione 3, il supporto per TCP come protocollo di livello di trasporto iniziò ad aumentare. L'uso di TCP come mezzo di trasferimento dei dati, eseguito utilizzando NFS sulla WAN, ha iniziato a consentire il trasferimento di file di grandi dimensioni per la visualizzazione e la scrittura. Ciò ha permesso agli sviluppatori di superare il limite di 8K imposto dallo User Datagram Protocol (UDP).

Che cos'è NFS v4?

La versione 4, influenzata da Andrew File System (AFS) e Server Message Block (SMB, chiamato anche CIFS), include miglioramenti delle prestazioni, maggiore sicurezza e un protocollo condizionale.

La versione 4 è stata la prima distribuzione sviluppata dalla Internet Engineering Task Force (IETF) dopo lo sviluppo del protocollo in outsourcing di Sun Microsystems.

NFS versione 4.1 mira a fornire il supporto del protocollo per sfruttare le distribuzioni di server in cluster, inclusa la capacità di fornire un accesso simultaneo ai file scalabile su più server (estensione pNFS).

Il più recente protocollo del file system, NFS 4.2 (RFC 7862), è stato rilasciato ufficialmente a novembre 2016.

Altre estensioni

Con lo sviluppo dello standard, sono apparsi strumenti appropriati per lavorare con esso. Ad esempio, WebNFS, un'estensione per le versioni 2 e 3, consente al Network File System Access Protocol di integrarsi più facilmente nei browser Web e abilitare il lavoro attraverso i firewall.

Anche vari protocolli di terze parti sono stati associati a NFS. I più famosi sono:

• Network Lock Manager (NLM) con supporto del protocollo byte (aggiunto per supportare l'API di blocco file UNIX System V);
• quota remota (RQUOTAD), che consente agli utenti NFS di visualizzare le quote di archiviazione sui server NFS;
• NFS su RDMA - un adattamento di NFS che utilizza l'accesso diretto alla memoria remota (RDMA) come mezzo di trasmissione;
• NFS-Ganesha è un server NFS in spazio utente che supporta CephFS FSAL (Filesystem Abstraction Layer) utilizzando libcephfs.

Piattaforme

Il Network File System viene spesso utilizzato con i sistemi operativi Unix (come Solaris, AIX, HP-UX), macOS di Apple e sistemi operativi simili a Unix (come Linux e FreeBSD).

È disponibile anche per piattaforme come Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare e IBM AS/400.

I protocolli alternativi di accesso remoto ai file includono Server Message Block (SMB, chiamato anche CIFS), Apple Transfer Protocol (AFP), NetWare Core Protocol (NCP) e OS/400 Server File System (QFileSvr.400).

Ciò è dovuto ai requisiti di NFS, che sono orientati principalmente verso "shell" simili a Unix.

Allo stesso tempo, i protocolli SMB e NetWare (NCP) vengono utilizzati più spesso di NFS sui sistemi che eseguono Microsoft Windows. AFP è più comune sulle piattaforme Apple Macintosh e QFileSvr.400 è più comune su OS / 400.

Implementazione tipica

Supponendo un tipico scenario in stile Unix in cui un computer (client) ha bisogno di accedere ai dati archiviati su un altro (server NFS):

• Il server implementa i processi di Network File System, avviati per impostazione predefinita come nfsd, per rendere i propri dati pubblicamente disponibili ai client. L'amministratore del server determina come esportare i nomi delle directory e le opzioni, solitamente utilizzando il file di configurazione /etc/exports e il comando exportfs.
• L'amministrazione della sicurezza del server garantisce che possa riconoscere e approvare un client verificato. La sua configurazione di rete assicura che i client appropriati possano negoziare con esso attraverso qualsiasi sistema firewall.
• La macchina client richiede l'accesso ai dati esportati, di solito emettendo il comando appropriato. Interroga il server (rpcbind) che sta utilizzando la porta NFS e successivamente si connette ad esso.
• Se tutto va bene, gli utenti sulla macchina client saranno in grado di visualizzare e interagire con i file system installati sul server entro le opzioni consentite.

Va notato che può avvenire anche l'automazione del processo di Network File System, magari utilizzando etc/fstab e/o altri mezzi simili.

Sviluppo fino ad oggi

Nel 21° secolo, i protocolli rivali DFS e AFS non hanno ottenuto alcun grande successo commerciale sul Network File System. IBM, che in precedenza aveva acquisito tutti i diritti commerciali sulle tecnologie di cui sopra, ha donato la maggior parte del codice sorgente AFS alla comunità del software libero nel 2000. Il progetto Open AFS esiste ancora oggi. All'inizio del 2005, IBM ha annunciato il completamento delle vendite di AFS e DFS.

A sua volta, nel gennaio 2010, Panasas ha introdotto NFS v 4.1, una tecnologia che migliora le capacità di accesso simultaneo ai dati. Il protocollo Network File System v 4.1 definisce un metodo per separare i metadati del file system dalla posizione di file specifici. Quindi va oltre la semplice separazione nome/dati.

Che cos'è in pratica NFS di questa versione? La caratteristica di cui sopra lo distingue dal protocollo tradizionale, che contiene i nomi dei file e i loro dati sotto lo stesso legame al server. Con Network File System v 4.1, alcuni file possono essere distribuiti su server multisito, ma la partecipazione del client alla separazione di metadati e dati è limitata.

Nell'implementazione del quarto kit di distribuzione del protocollo NFS, il server è un insieme di risorse o componenti del server; si presume che siano controllati dal server dei metadati.

Il client contatta ancora lo stesso server MDS per eseguire la scansione o interagire con lo spazio dei nomi. Quando sposta i file da e verso il server, può interagire direttamente con il set di dati appartenente al gruppo NFS.

Per la distribuzione di file all'interno di una rete locale si possono distinguere le seguenti tecnologie (sono considerati sistemi basati su Linux):

• Network File System (NFS) - un protocollo per l'accesso di rete ai file system;
• I file trasferiti tramite il protocollo Shell (FISH) è un protocollo di rete che utilizza o RSH trasferire file tra computer;
• Secure SHell FileSystem (SSHFS) - un client di file system per il montaggio di dispositivi disco su sistemi remoti, utilizzato per interagire con un sistema remoto SFTP;
• Samba è un pacchetto software che consente di accedere a unità di rete e stampanti su vari sistemi operativi utilizzando il protocollo SMB/CIFS;

Questa nota si concentrerà su NFS.

NFS (sistema di file di rete) utile quando è necessario distribuire file/directory a tutti sulla rete. Accedi alla trasparenza usando NFS Consente ai client di montare un file system remoto come directory locale e i file system possono essere di diversi tipi. Ciò significa che qualsiasi applicazione client in grado di funzionare con un file locale può funzionare altrettanto bene con un file connesso da NFS, senza alcuna modifica al programma stesso.

Ai vantaggi NFS può essere attribuito:

Attualmente disponibile NFS v4.1, che ha introdotto una nuova funzionalità pNFS consentendoti di parallelizzare l'implementazione della condivisione di file. C'è anche un'estensione per NFS 2 e 3 - WebNFS che facilita l'integrazione nei browser Web e consente di lavorare attraverso un firewall.

Schema di lavoro NFS protocollo.

Installazione e configurazione di un server NFS sotto Linux

Controlla se il sistema supporta NFS

Cat / proc / filesystem | grep nfs

Sotto Arch Linux server e client sono nello stesso pacchetto

Yaourt -S nfs-utils

Per installare il server ( nfs-kernel-server) e cliente ( nfs-comune) sotto Ubuntu pacchetti necessari

Sudo apt-get install nfs-kernel-server nfs-common portmap

Più avanti nella nota verrà utilizzato l'IP del server 192.168.1.100 ... Affinché al server venga assegnato sempre lo stesso IP, è necessario specificare la distribuzione di un IP specifico a un indirizzo MAC specifico nel server DHCP (il più delle volte un router). Oppure apri il tuo server DNS locale. Ad esempio o.

L'indirizzo MAC può essere trovato usando ifconfig (campo etere v Arch Linux).

NFSv4 presuppone che ci sia una directory radice all'interno della quale si trovano già i file di distribuzione. Ad esempio, / srv / nfs- radice, / srv / nfs / audio- una directory per la distribuzione di musica. Se non segui questa nuova direttiva nella versione 4 , quindi puoi ricevere un errore durante la connessione da parte del client:

Mount.nfs: accesso negato dal server durante il montaggio 192.168.1.100:/home/proft/torrents

Se vuoi ancora utilizzare un approccio senza server senza una directory principale per NFS, quindi durante il montaggio da parte del client, è necessario specificare esplicitamente la versione 3

# per il comando mount mount -o "vers = 3" 192.168.1.100:/home/proft/torrents / home / proft / nfs / torrents # per fstab 192.168.1.100:/home/proft/torrents / home / proft / nfs / torrent nfs soft, nfsvers = 3 0 0

userò NFSv4 con la directory principale in /srv/nfs/ e montare le sottodirectory usando mount --bind.

Supponiamo di volere

• distribuire una directory ~ / torrent Con rw accesso per di tutti all'interno della rete locale;
• distribuire una directory ~ / foto Con ro accesso per host con IP 192.168.1.101 ;

Per prima cosa, creiamo la directory principale e quelle nidificate necessarie.

Sudo mkdir -p / srv / nfs / (torrent, foto)

Monta directory esistenti torrent, foto v / srv / nfs.

# sudo vim / etc / fstab / home / proft / torrents / srv / nfs / torrent nessuno bind 0 0 / home / proft / photos / srv / nfs / photos nessuno bind 0 0

Modifichiamo / etc / esporta che descrive tutte le directory condivise

# sudo vim / etc / exports # formato file: directory allow-hosts (opzioni) / srv / nfs / torrents 192.168.1.1/24(rw, async) / srv / nfs / photos 192.168.1.101 (ro, async)

Nota che non c'è spazio tra host-permessi e (opzioni)... La presenza di uno spazio introduce una diversa interpretazione delle regole.

Opzioni disponibili:

• ro (rw) - consente l'accesso in sola lettura (lettura/scrittura);
• subtree_check (no_subtree_check) - in alcuni casi, devi esportare non l'intera sezione, ma solo una parte di essa. In questo caso, il server NFS dovrebbe eseguire un'ulteriore convalida sulle richieste del client per garantire che stiano tentando di accedere solo ai file nelle sottodirectory appropriate. Tale controllo del sottoalbero ( controlli del sottoalbero) rallenta leggermente l'interazione con i client, ma se lo abbandoni, potrebbero esserci problemi con la sicurezza del sistema. Puoi rimuovere il controllo di un sottoalbero usando l'opzione no_subtree_check... Opzione subtree_check l'abilitazione di tali controlli è presunta per impostazione predefinita. Il controllo della sottostruttura può essere saltato se la directory esportata coincide con la partizione del disco;
• sync (async): indica che il server deve rispondere alle richieste solo dopo che le modifiche apportate da tali richieste sono state scritte su disco. Opzione asincrono indica al server di non attendere che le informazioni vengano scritte su disco, il che migliora le prestazioni, ma diminuisce l'affidabilità, perché se la connessione è interrotta o l'apparecchiatura si guasta, è possibile la perdita di dati;
• noaccess - nega l'accesso alla directory specificata. Può essere utile se in precedenza hai concesso l'accesso a tutti gli utenti della rete a una determinata directory e ora desideri limitare l'accesso nella sottodirectory solo ad alcuni utenti;
• no_root_squash - utente predefinito radice sulla macchina client non avrà gli stessi diritti sulla directory sul server. Questa opzione rimuove questa limitazione;
• non nascondersi - NFS non mostra automaticamente le risorse non locali (ad esempio, montate usando mount --bind), questa opzione attiva la visualizzazione di tali risorse;
• non sicuro: usa porte non privilegiate (> 1024);

Avvio del server NFS

# sotto archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # sotto ubuntu sudo /etc/init.d/nfs-kernel-server start

In futuro, quando si cambia il file di configurazione, è sufficiente rileggerlo con il comando:

Sudo exportfs -rav

Rpcinfo -p comando | grep nfs ti consente di verificare se il server è stato avviato correttamente.

client Linux

Installazione

# per archlinux yaourt -S nfs-utils # per ubuntu sudo apt-get install portmap nfs-common

Crea directory per il montaggio delle risorse di rete torrenti e fotografie

Mkdir -p ~ / nfs / (torrent, foto)

Per il montaggio manuale, eseguire

Sudo mount -t nfs -o rw, soft 192.168.1.100:/srv/nfs/torrents / home / proft / nfs / torrents sudo mount -t nfs -o rw, soft 192.168.1.100:/srv/nfs/photos / home / proft / nfs / foto

Opzione morbido indica di annullare silenziosamente i tentativi di collegare la palla dopo un certo periodo di tempo (il tempo è impostato dall'opzione ritrasformare). Di più in uomo nfs.

Questo metodo non è molto conveniente, poiché dovrai eseguire questi comandi ogni volta dopo il riavvio. Rendiamo automatico il montaggio.

Per il montaggio automatico, modificare il file / etc / fstab

# sudo vim / etc / fstab 192.168.1.100:/srv/nfs/torrents / home / proft / net / torrents nfs rw, soft 0 0 192.168.1.100:/srv/nfs/photos / home / proft / net / photos nfs ro, morbido 0 0

Ma questo metodo ha anche i suoi svantaggi, ad esempio, se il server non è disponibile, il caricamento del client potrebbe bloccarsi a causa dei tentativi di connessione al server NFS. Per risolvere questo problema vedi sotto su AutoFS.

AutoFS - connessione automatica delle risorse di rete

È possibile montare una risorsa remota usando AutoFS la prima volta che si accede e smonta automaticamente quando non c'è attività.

AutoFS usa i modelli che si trovano in / etc / autofs... Il modello principale si chiama auto.master, può puntare a uno o più altri modelli per tipi di media specifici.

Installazione

# per archlinux yaourt -S autofs # per ubuntu sudo apt-get install autofs

Esistono diversi modi per specificare come eseguire il montaggio automatico. Io uso questo: in / home / prot / nfs viene creata automaticamente una directory con il nome del server NFS, nella quale vengono create automaticamente le directory disponibili sul server.

# sudo vim /etc/autofs/auto.master / home / proft / nfs /etc/autofs/auto.nfs --timeout = 60

Parametro aggiuntivo tempo scaduto imposta il numero di secondi dopo i quali il dispositivo verrà smontato. Parametro fantasma indica che le risorse configurate verranno sempre visualizzate e non solo quando sono disponibili (questa opzione è abilitata per impostazione predefinita in AutoFS 5)

Descriviamo in /etc/autofs/auto.nfs Server NFS e directory principale.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Ora alla prima chiamata / home / proft / nfs / torrents la condivisione NFS verrà montata automaticamente.

Riavviamo il servizio autofs:

# in archlinux sudo systemctl restart autofs # in ubuntu sudo /etc/init.d/autofs restart

È inoltre possibile specificare il tempo di attesa per la disponibilità della risorsa NFS. Per fare ciò, è necessario modificare i valori MONTA_ATTESA.

# sotto archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT = 5 # sotto ubuntu sudo / etc / default / autofs MOUNT_WAIT = 5

Forzare l'uso di NFS v3

In alcuni casi NFSv4 potrebbe essere lento. Per risolvere questo problema, puoi forzare l'uso della terza versione.

Soluzione conveniente per accedere a un file system distribuito

Il file system è un must. Lavoriamo su computer che forniscono accesso a stampanti, fotocamere, database, sensori remoti, telescopi, compilatori e telefoni cellulari. Questi dispositivi hanno poco in comune - in particolare, molti di loro sono diventati realtà dopo che Internet è diventato onnipresente (ad esempio, fotocamere elettroniche e dispositivi mobili che fungono da piccoli computer). Tuttavia, tutti hanno bisogno di un file system per archiviare e accedere in modo sicuro alle informazioni.

Di solito non ci interessa come i dati, le applicazioni che li utilizzano e le interfacce che ce li presentano sono archiviati sui computer stessi. La maggior parte degli utenti vorrebbe vedere (e giustamente) il filesystem come un muro che li separa dal metallo nudo che immagazzina bit e byte. Pertanto, gli stack di protocollo che collegano i file system sono solitamente scatole nere per la maggior parte degli utenti, e in effetti per i programmatori. In definitiva, tuttavia, il collegamento in rete di tutti questi dispositivi si riduce a consentire lo scambio di dati tra i file system.

File system di rete e altre pratiche sacre

Per molti versi, lo scambio di dati non è altro che la copia di informazioni su lunghe distanze. I protocolli di rete non sono stati l'unico mezzo attraverso il quale è diventata possibile la comunicazione universale. Dopotutto, ogni sistema informatico deve tradurre i datagrammi in qualcosa che il sistema operativo dall'altra parte possa capire. TCP è un protocollo di trasferimento molto efficiente, ma non è ottimizzato per l'accesso rapido ai file o il controllo remoto del software applicativo.

Informatica distribuita e in rete

I protocolli di rete tradizionali hanno poco da offrire per organizzare i calcoli distribuiti tra computer e, inoltre, tra reti. Solo i programmatori spericolati farebbero affidamento sul protocollo dati e sui cavi ottici per il calcolo parallelo. Solitamente ci affidiamo a un modello sequenziale, in cui, una volta stabilita una connessione, i protocolli a livello di collegamento iniziano a funzionare, eseguendo una procedura di ciao piuttosto complessa tra le schede di rete. Il calcolo parallelo e i file system distribuiti non si basano più su IP o Ethernet. Attualmente, possiamo semplicemente ignorarli quando parliamo di prestazioni. I problemi di sicurezza, tuttavia, sono una questione diversa.

Un pezzo del puzzle è come è organizzato l'accesso ai file su un sistema informatico. Ora per il sistema che accede ai file, è irrilevante se i file necessari sono disponibili su un computer o se si trovano per qualche motivo su più computer. Attualmente, la semantica del filesystem e le strutture dei dati del filesystem sono due argomenti molto diversi. La semantica del file system distribuito in stile Plan 9 o Andrew File System (AFS) nasconde il modo in cui i file sono organizzati o il modo in cui il file system si mappa all'hardware e alla rete. NFS non nasconde necessariamente il modo in cui file e directory sono archiviati su file system remoti, ma non rivela nemmeno l'effettiva archiviazione hardware di file system, directory e file.

NFS: risoluzione del problema UNIX

L'accesso al file system distribuito, tuttavia, richiede poco più di un paio di comandi per consentire agli utenti di montare una directory che si trova su un altro computer della rete. Sun Microsystems si è imbattuta in questo problema alcuni anni fa, quando ha iniziato a distribuire qualcosa chiamato Chiamate di procedura remota(RPC) e NFS.

Il problema principale che Sun stava cercando di risolvere era come connettere più macchine UNIX per creare un unico ambiente di lavoro distribuito senza dover riscrivere la semantica del filesystem UNIX e aggiungere troppe strutture di dati specifiche per i filesystem distribuiti: l'integrità di ogni sistema aveva da preservare, fornendo agli utenti la possibilità di lavorare con la directory su un altro computer senza causare ritardi o restrizioni indesiderati nel loro flusso di lavoro.

Naturalmente, NFS fa di più che fornire l'accesso ai file di testo. Puoi anche distribuire applicazioni di "avvio" su NFS. Le procedure di sicurezza vengono utilizzate per proteggere la rete da interferenze dannose da parte di file eseguibili. Ma come avviene esattamente questo?

NFS è RPC

NFS è tradizionalmente definito come un'applicazione RPC che richiede TCP per il server NFS e TCP o un altro protocollo non travolgente per il client NFS. L'Internet Engineering Task Force (IETF) ha pubblicato una richiesta di commenti (RFC) per RPC in RFC 1832. Un altro standard vitale per il funzionamento di un'implementazione NFS sono i formati di dati utilizzati da NFS; è stato pubblicato nella RFC 1831 come documento XDR (External Data Representation).

Altri RFC si occupano della sicurezza e degli algoritmi di crittografia utilizzati nello scambio di informazioni di autenticazione durante le sessioni NFS, ma ci concentreremo prima sui meccanismi di base. Uno dei protocolli che ci interessa è Protocollo di montaggio descritto nell'appendice 1 della RFC 1813.

Questo RFC descrive quali protocolli consentono a NFS di funzionare, ma non descrive come funziona NFS in tempo presente... Hai già imparato qualcosa di importante, ovvero che i protocolli NFS sono documentati come standard IETF. Dopo che l'ultima versione di NFS è rimasta bloccata al numero 3, i protocolli RPC non si sono evoluti oltre la fase di informazione RFC e sono stati generalmente percepiti come di competenza del (presumibilmente) enorme gruppo di lavoro di ingegneria di Sun Microsystems e delle versioni UNIX proprietarie. Dal 1985, Sun ha rilasciato diverse versioni di NFS, anticipando di diversi anni la maggior parte dei file system moderni. Sun Microsystems ha trasferito il controllo di NFS all'IETF nel 1998 e gran parte del lavoro sulla versione 4 di NSF (NFSv4) è stato svolto sotto gli auspici dell'IETF.

Cioè, quando lavori con RPC e NFS oggi, stai lavorando con una versione che riflette gli interessi di aziende e gruppi non Sun. Tuttavia, molti ingegneri Sun rimangono profondamente interessati allo sviluppo di NFS.

NFS versione 3

NFS nella sua incarnazione come versione 3 (NFSv3) è stateless (non stateful), ma NFSv4 sì. Questa espressione fondamentale non sorprende quasi nessuno oggi, sebbene il mondo TCP / IP su cui è costruito NFS sia per la maggior parte stateless - un fatto che aiuta le aziende di analisi del traffico e software di sicurezza a sentirsi abbastanza bene.

Il protocollo NFSv3 doveva fare affidamento su diversi protocolli aggiuntivi per montare in modo trasparente le directory sui computer remoti in modo da non dipendere dai meccanismi del file system che utilizzavano. NFS non è sempre stato bravo in questo. Un buon esempio è il protocollo Mount chiamato identificatore di file iniziale, mentre il protocollo Network Lock Manager ha eseguito il blocco del file. Entrambe le operazioni richiedevano uno stato corrente che NFSv3 non forniva. Di conseguenza, c'erano interazioni complesse tra i livelli di protocollo che non riflettevano meccanismi di flusso di dati simili. Inoltre, quando si aggiunge il fatto che la creazione di file e directory è completamente diversa in Microsoft® Windows® rispetto a UNIX, la situazione diventa ancora più complicata.

Il protocollo NFSv3 doveva utilizzare le porte per fornire alcuni dei suoi protocolli ausiliari; questo fornisce un quadro piuttosto complesso delle porte, dei livelli di protocollo e dei problemi di sicurezza associati. Oggi questo modello di funzionamento è stato abbandonato e tutte le operazioni che in precedenza eseguivano le implementazioni del protocollo ausiliario tramite singole porte sono controllate dal protocollo NFSv4 tramite una porta nota.

NFSv3 era anche pronto per i file system Unicode, un vantaggio rimasto in qualche modo teorico fino alla fine degli anni '90. Corrispondeva bene alla semantica del filesystem UNIX ed era la ragione per la creazione di implementazioni di filesystem concorrenti come AFS e Samba. Non sorprende che il supporto di Windows fosse scarso, ma i file server Samba fornivano la condivisione di file tra i sistemi UNIX e Windows.

NFS versione 4

Il protocollo NFSv4 è, come abbiamo notato, un protocollo stateful. Diversi cambiamenti radicali hanno reso possibile questo comportamento. Abbiamo già detto che i protocolli di supporto dovrebbero essere chiamati poiché i processi a livello di utente sono stati eliminati. Invece, tutte le operazioni di apertura dei file e alcune chiamate RPC sono state implementate come operazioni del file system a livello di kernel.

Tutte le versioni di NFS hanno definito ogni unità di lavoro in termini di operazioni client e server RPC. Ogni richiesta NFSv3 richiedeva un numero piuttosto significativo di chiamate RPC e porte aperte per restituire il risultato. La versione 4 lo ha semplificato introducendo il concetto del cosiddetto composito(composto) un'operazione che include un numero elevato di operazioni su oggetti nel file system. L'effetto diretto, ovviamente, è stato un numero significativamente inferiore di chiamate RPC e meno dati da trasferire sulla rete, anche se ogni chiamata RPC trasportava effettivamente più dati, svolgendo una quantità notevolmente maggiore di lavoro. È stato stimato che le chiamate RPC in NFSv3 richiedono cinque volte il numero di interazioni client-server rispetto alle procedure RPC composite.

RPC in realtà non è più di tale importanza e essenzialmente racchiude alcune operazioni che sono incapsulate nello stack NFSv4. Questa modifica ha anche reso lo stack del protocollo molto meno dipendente dalla semantica del filesystem utilizzato. Ma questo non significa che le operazioni del file system su altri sistemi operativi siano state ignorate: ad esempio, la condivisione delle risorse di Windows richiede lo stato persistente tra le chiamate per aprire la risorsa. La statefulness non solo semplifica l'analisi del traffico, ma se implementata a livello di semantica del file system rende le operazioni del file system molto più controllabili. Le chiamate di risorse aperte con stato consentono ai client di memorizzare nella cache i dati dei file e lo stato che altrimenti si verificherebbero sul server. Nella vita reale (dove i client Windows sono onnipresenti), rendere i server NFS trasparenti e unificati con le risorse condivise di Windows vale il tempo dedicato alla configurazione della configurazione NFS.

Utilizzo di NFS

L'installazione di NFS è generalmente simile all'installazione di Samba. Sul lato server, definisci i filesystem o le directory da esportare, oppure condivisione; il lato client monta queste directory. Quando un client remoto monta una directory NFS, la directory è accessibile proprio come qualsiasi altra directory nel file system locale. L'impostazione di NFS su un server è un processo semplice. Come minimo, è necessario creare o modificare il file /etc/exports e avviare il demone NFS. Per configurare un servizio NFS più sicuro, è necessario modificare anche i file /etc/hosts.allow e /etc/hosts.deny. Il client NFS richiede solo il comando mount. Per ulteriori informazioni e opzioni, vedere la documentazione in linea di Linux® (pagina man).

Nfs server

Le voci nel file / etc / exports sono chiare. Per condividere il filesystem, modificare il file /etc/exports e descrivere il filesystem (con parametri) nel seguente formato generale:

Parametri comuni

Sono disponibili diverse opzioni generali per personalizzare l'implementazione di NFS. Questi includono:

• sicuro: Questo parametro (per impostazione predefinita) utilizza una porta TCP/IP disponibile inferiore a 1024 per le connessioni NFS. Se si specifica non sicuro, questo viene disabilitato.
• rw: Questo parametro consente l'accesso in lettura/scrittura ai client NFS. L'accesso predefinito è di sola lettura.
• asincrono: Questa opzione può migliorare le prestazioni, ma può anche causare la perdita di dati quando il server NFS viene riavviato senza prima arrestare il demone NFS. L'impostazione predefinita è sincronizzazione.
• no_wdelay: Questa opzione disabilita il ritardo di registrazione. Se impostato in modalità asincrona, NFS ignora questo parametro.
• non nascondersi: Se monti una directory sopra un'altra, la vecchia directory di solito è nascosta o sembra vuota. Per disabilitare questo comportamento, abilitare il parametro hide.
• no_subtree_check: Questa opzione disabilita il monitoraggio delle sottodirectory per alcuni controlli di sicurezza che potresti non voler ignorare. L'impostazione predefinita è abilitare il controllo delle sottodirectory.
• no_auth_nlm: Questo parametro, se impostato su insecure_locks, indica al demone NFS di non autenticarsi durante le richieste di blocco. L'impostazione predefinita è auth_nlm o secure_locks.
• mp (punto di montaggio = percorso): Dichiarando esplicitamente questo parametro, NSF richiede il montaggio della directory esportata.
• fsid = numero: Questo parametro viene comunemente utilizzato durante l'impostazione di un sistema di ripristino di emergenza NFS. Se si desidera implementare il ripristino di emergenza per NFS, fare riferimento alla documentazione di NFS.

Mappatura utente

Attraverso la mappatura degli utenti NFS, è possibile identificare uno pseudo-utente o un utente reale e un gruppo con l'utente che accede al volume NFS. L'utente NFS dispone dei diritti utente o di gruppo consentiti dalla mappatura. L'utilizzo di un singolo utente e gruppo (generico) per i volumi NFS fornisce un livello di protezione e flessibilità senza sforzi amministrativi significativi.

Quando si utilizzano file su un filesystem montato su NFS, l'accesso dell'utente viene solitamente ridotto. Ciò significa che l'utente accede ai file come utente anonimo che ha accesso in sola lettura a quei file. Questo comportamento è particolarmente importante per l'utente root. Tuttavia, ci sono situazioni in cui si desidera che un utente acceda ai file su un sistema remoto come root o un altro utente specifico. NFS consente di specificare un utente (tramite numero di identificazione utente (UID) e numero di identificazione di gruppo (GID)) per accedere ai file remoti ed è possibile disabilitare il normale comportamento di "soppressione" per impostazione predefinita.

Le opzioni di visualizzazione dell'utente includono:

• root_squash: Questa opzione impedisce all'utente root di accedere al volume NFS montato.
• no_root_squash: Questo parametro consente all'utente root di accedere al volume NFS montato.
• all_squash: Questa opzione, utile per i volumi NFS ad accesso aperto, elimina tutti gli UID e i GID e utilizza solo l'account utente anonimo. Il valore predefinito è no_all_squash.
• anonuid e anongid: Questi parametri modificano l'UID e il GID dell'utente anonimo nell'account specificato.

Il Listato 1 mostra esempi di voci /etc/exports.

Listato 1. Esempi di voci / etc / exports

La prima voce esporta la directory /opt/files per tutti gli host sulla rete 192.168.0. La seguente voce esporta / opt / file per un singolo host: 192.168.0.120. La terza voce specifica l'host 192.168.0.125 e fornisce l'accesso in lettura/scrittura ai file con diritti utente con ID utente = 210 e ID gruppo = 100. L'ultima voce viene utilizzata per la directory pubblica e consente l'accesso in sola lettura e solo con l'account utente anonimo.

client NFS

Avvertenze

Una volta utilizzato NFS per montare un file system remoto, questo farà anche parte di qualsiasi backup di sistema condiviso eseguito sul computer client. Questo comportamento può portare a risultati potenzialmente dannosi se non si escludono le directory montate durante il backup.

Per utilizzare NFS come client, il computer client deve eseguire rpc.statd e portmap. Puoi eseguire ps -ef per verificare la presenza di questi due demoni. Se funzionano (come dovrebbero), puoi montare la directory esportata dal server con il seguente comando generale:

In generale, è necessario essere in esecuzione come utente root durante il montaggio del filesystem. Sulla macchina remota, puoi usare il seguente comando (assumendo che il server NFS abbia un indirizzo IP di 192.168.0.100):

La tua distribuzione di sistema potrebbe richiedere di specificare il tipo di filesystem quando lo monti. In tal caso, usa il comando:

La directory remota dovrebbe essere montata senza problemi se il server è stato configurato correttamente. Ora esegui il comando cd per passare alla directory /mnt, quindi il comando ls per visualizzare i file. Per rendere permanente questo montaggio, è necessario modificare il file /etc/fstab e creare una voce simile alla seguente:

Nota: Per ulteriori informazioni sulle voci /etc/fstab, vedere la guida in linea di fstab.

Critiche a NFS

Le critiche guidano il miglioramento

Le critiche alla sicurezza di NFS sono state la ragione di molti dei miglioramenti in NSFv4. I creatori della nuova versione hanno adottato misure concrete per rafforzare la sicurezza delle interazioni client-server. Hanno infatti deciso di implementare un modello completamente nuovo del sistema di protezione.

Per comprendere il modello di sicurezza, dovresti avere familiarità con l'API. Servizi di sicurezza generici (GSS-API) versione 2, revisione 1. La GSS-API è completamente descritta nella RFC 2743, che è purtroppo una delle RFC più difficili da comprendere.

Dalla nostra esperienza con NFSv4, sappiamo che non è molto facile rendere il filesystem di rete indipendente dal sistema operativo. Ma è ancora più difficile rendere tutte le aree del sistema di sicurezza indipendenti dal sistema operativo e dai protocolli di rete. Abbiamo bisogno di entrambi, poiché NFS deve essere in grado di gestire un numero abbastanza elevato di operazioni utente e di farlo senza considerare le specifiche della comunicazione sul protocollo di rete.

Le connessioni tra client e server NFS sono protette da un cosiddetto sistema di sicurezza (piuttosto superficiale). forte RPC. NFSv4 utilizza lo standard Open Network Computing Remote Procedure Call (ONCRPC) come definito nella RFC 1831. Il sistema di sicurezza doveva essere rafforzato, quindi invece della semplice autenticazione (nota come AUTH_SYS) come parte obbligatoria del protocollo NFSv4, una forma di sistema di sicurezza basato su GSS-API noto come RPCSEC_GSS... I meccanismi di sicurezza più importanti disponibili in NFSv4 sono Kerberos versione 5 e LIPKEY.

Sebbene Kerberos abbia dei limiti quando viene utilizzato su Internet, LIPKEY ha un bel vantaggio: agendo come Secure Sockets Layer (SSL), richiede agli utenti i loro nomi utente e password, evitando la dipendenza TCP da SSL, una dipendenza che NFSv4 non ha Condividere. È possibile configurare NFS per implementare le modalità di sicurezza se RPCSEC_GSS non è richiesto. Le versioni precedenti di NFS non avevano questa capacità e, pertanto, non potevano fornire sicurezza di qualità, integrità dei dati, requisiti di autenticazione o tipi di crittografia.

Il protocollo NFSv3 ha ricevuto critiche significative sulla sicurezza. Se i server NFSv3 erano in esecuzione su TCP, era assolutamente realistico eseguire reti NFSv3 su Internet. Sfortunatamente, è stato necessario aprire anche diversi porti, il che ha portato a diverse falle di sicurezza ben pubblicizzate. Rendendo la porta 2049 obbligatoria per NFS, è diventato possibile utilizzare NFSv4 con i firewall senza dover prestare troppa attenzione alle porte su cui erano in ascolto gli altri protocolli, come il protocollo Mount. Pertanto, l'esclusione del protocollo Mount ha avuto diversi effetti positivi:

• Meccanismi di autenticazione forte obbligatori: NFSv4 ha reso obbligatori i meccanismi di autenticazione forte. I sapori di Kerberos sono abbastanza comuni. Deve essere supportato anche il meccanismo a chiave pubblica dell'infrastruttura inferiore (LIPKEY). NFSv3 non ha mai supportato nient'altro che la crittografia UNIX standard per l'autenticazione dell'accesso: ciò poneva un grave problema di sicurezza nelle reti di grandi dimensioni.
• Schemi di elenchi di controllo di accesso obbligatori (ACL) in stile Microsoft Windows NT Nota: sebbene NFSv3 consentisse una crittografia avanzata per l'autenticazione, non utilizzava schemi di accesso ACL in stile Windows NT. Gli ACL in stile POSIX (Portable Operating System Interface) sono stati talvolta implementati ma non sono mai stati generalmente accettati. NFSv4 ha reso obbligatori gli ACL in stile Windows NT.
• Meccanismi e stili di autenticazione negoziata: NFSv4 ha fornito la possibilità di negoziare meccanismi e stili di autenticazione. In NSFv3, era impossibile fare di più che definire manualmente lo stile di crittografia da utilizzare. L'amministratore di sistema ha quindi dovuto negoziare i protocolli di crittografia e sicurezza.

NFS è ancora avanti rispetto alla concorrenza?

NFSv4 sostituisce NFSv3 sulla maggior parte dei sistemi UNIX e Linux. Come file system di rete, NSFv4 ha pochi concorrenti. Un valido concorrente sarebbe il Common Internet File System (CIFS) / Server Message Block (SMB), dato che è presente in tutte le versioni di Windows e (attualmente) Linux. AFS non ha mai avuto molto peso commerciale; ha enfatizzato gli elementi dei file system distribuiti che facilitano la migrazione e la replica dei dati.

Le versioni Linux di NFS sono state rilasciate dopo che il kernel ha raggiunto la versione 2.2, ma uno degli errori più comuni delle versioni del kernel Linux è stato che Linux ha adottato NFSv3 piuttosto tardi. In effetti, è passato molto tempo prima che Linux fosse pienamente in grado di supportare NSFv3. Con l'avvento di NSFv4, questa mancanza è stata rapidamente eliminata e il supporto completo per NSFv4 è stato implementato non solo su Solaris, AIX e FreeBSD.

NFS è attualmente considerata una tecnologia matura che ha un vantaggio piuttosto grande: è sicura e conveniente: la maggior parte degli utenti trova conveniente utilizzare un login sicuro per accedere alla rete e utilizzare le sue capacità, anche quando i file e le applicazioni si trovano su sistemi diversi. Anche se questo può sembrare uno svantaggio rispetto ai file system distribuiti, che nascondono le strutture di sistema agli utenti, tieni presente che molte applicazioni utilizzano file che risiedono su sistemi operativi diversi e quindi su computer diversi. NFS semplifica il lavoro con diversi sistemi operativi senza doversi preoccupare troppo della semantica del filesystem e delle caratteristiche prestazionali.

NFS: un file system di rete conveniente e a prova di futuro

File system di reteÈ un'astrazione di rete su un normale filesystem, che consente a un client remoto di accedervi attraverso la rete nello stesso modo in cui si accede ai filesystem locali. Sebbene NFS non sia stato il primo file system in rete, si è evoluto fino a diventare il file system di rete più funzionale e richiesto in UNIX® oggi. NFS consente a più utenti di condividere un file system comune e centralizza i dati per ridurre al minimo la quantità di spazio su disco necessaria per archiviarli.

Questo articolo inizia con una breve panoramica della storia di NFS, quindi passa all'esplorazione dell'architettura NFS e di come si evolverà.

Una breve storia di NFS

Il primo file system di rete si chiamava FAL (File Access Listener) ed è stato sviluppato nel 1976 da DEC (Digital Equipment Corporation). Era un'implementazione del Data Access Protocol (DAP) e faceva parte della suite di protocolli DECnet. Come con TCP/IP, DEC ha pubblicato le specifiche per i suoi protocolli di rete, incluso DAP.

NFS è stato il primo file system di rete moderno costruito su IP. Il suo prototipo può essere considerato un file system sperimentale sviluppato da Sun Microsystems nei primi anni '80. Data la popolarità di questa soluzione, il protocollo NFS è stato introdotto come specifica RFC e successivamente si è evoluto in NFSv2. NFS si è rapidamente affermato come standard grazie alla sua capacità di interagire con altri client e server.

Lo standard è stato successivamente aggiornato alla versione NFSv3 definita in RFC 1813. Questa versione del protocollo era più scalabile rispetto alle versioni precedenti e supportava file più grandi (oltre 2 GB), scrittura asincrona e TCP come protocollo di trasporto. NFSv3 imposta la direzione per i file system per le reti WAN (Wide Area). Nel 2000, come parte della specifica RFC 3010 (rivista nella versione RFC 3530), NFS è stato portato nell'ambiente aziendale. Sun ha introdotto un NFSv4 più sicuro con supporto con stato (le versioni precedenti di NFS non supportavano lo stato, cioè erano senza stato). Attualmente, l'ultima versione di NFS è la versione 4.1, definita in RFC 5661, in cui il protocollo tramite l'estensione pNFSè stato aggiunto il supporto per l'accesso parallelo per i server distribuiti.

La storia dello sviluppo di NFS, incluse specifiche RFC che descrivono le sue versioni, è mostrata nella Figura 1.

Sorprendentemente, NFS è in sviluppo da quasi 30 anni. È un file system di rete estremamente stabile e portatile con scalabilità, prestazioni e qualità del servizio eccezionali. Con l'aumento della velocità e la diminuzione della latenza dello scambio di dati all'interno di una rete, NFS continua a essere un modo popolare per implementare un file system all'interno di una rete. Anche con le LAN, la virtualizzazione incoraggia l'archiviazione dei dati sulla rete per fornire alle macchine virtuali una mobilità aggiuntiva. NFS supporta anche gli ambienti di elaborazione più recenti progettati per ottimizzare le infrastrutture virtuali.

Architettura NFS

NFS utilizza un modello di architettura client-server standard (come mostrato nella Figura 2). Il server è responsabile dell'implementazione del file system condiviso e dell'archiviazione a cui i client si connettono. Il client implementa un'interfaccia utente su un file system condiviso montato all'interno dello spazio file locale del client.

Figura 2. Implementazione del modello client-server nell'architettura NFS

Su Linux®, uno switch di file system virtuale (VFS) fornisce i mezzi per supportare più file system su un singolo host (ad esempio, un file system ISO 9660 su un CD-ROM e un file system ext3fs su un disco rigido locale). Lo switch virtuale determina a quale unità viene inviata la richiesta e quindi quale file system deve essere utilizzato per elaborare la richiesta. Pertanto, NFS ha la stessa compatibilità di altri file system utilizzati in Linux. L'unica differenza con NFS è che le richieste di I/O, invece di essere elaborate localmente sull'host, possono essere instradate alla rete per l'esecuzione.

Il VFS determina che la richiesta che riceve è NFS e la passa al gestore NFS nel kernel. Il gestore NFS elabora la richiesta di I/O e la traduce in una procedura NFS (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE, ecc.). Queste procedure, descritte in una specifica RFC separata, definiscono il comportamento del protocollo NFS. La procedura richiesta viene selezionata in base alla richiesta ed eseguita utilizzando la tecnologia RPC (Remote Procedure Call). Come suggerisce il nome, RPC consente di effettuare chiamate di procedura tra sistemi diversi. Il servizio RPC connette la richiesta NFS con i suoi argomenti e invia il risultato all'host remoto appropriato, quindi monitora la ricezione e l'elaborazione della risposta per restituirla al richiedente.

RPC include anche un importante livello XDR ( rappresentazione di dati esterni- presentazione indipendente dei dati), che garantisce che tutti gli utenti NFS utilizzino lo stesso formato per gli stessi tipi di dati. Quando una piattaforma effettua una richiesta, il tipo di dati che utilizza può essere diverso dal tipo di dati utilizzato sull'host che elabora la richiesta. XDR si occupa del lavoro di conversione del tipo in rappresentazione standard (XDR) in modo che le piattaforme che utilizzano architetture diverse possano interagire e condividere i file system. XDR definisce un formato bit per tipi come float e l'ordinamento dei byte per tipi come array a lunghezza fissa e variabile. Sebbene XDR sia noto principalmente per il suo utilizzo in NFS, questa specifica può essere utile ogni volta che devi lavorare nello stesso ambiente con architetture diverse.

Dopo che XDR ha convertito i dati in una rappresentazione standard, la richiesta viene inviata sulla rete utilizzando uno specifico protocollo di trasporto. Le prime implementazioni di NFS utilizzavano UDP, ma oggi viene utilizzato TCP per una maggiore robustezza.

Sul lato server NFS, viene utilizzato un algoritmo simile. La richiesta risale lo stack di rete attraverso il livello RPC/XDR (per convertire i tipi di dati in base all'architettura del server) e va al server NFS, che è responsabile dell'elaborazione della richiesta. Lì, la richiesta viene passata al daemon NFS per determinare il file system di destinazione a cui è indirizzata, quindi entra di nuovo nel VFS per accedere a questo file system sul disco locale. Un diagramma completo di questo processo è mostrato nella Figura 3. Il file system locale del server è un file system Linux standard, ad esempio ext4fs. Infatti, NFS non è un file system nel senso tradizionale del termine, ma un protocollo per l'accesso remoto ai file system.

Per le reti con latenza lunga, NFSv4 offre una procedura composta speciale ( procedura composta). Questa procedura consente di racchiudere più chiamate RPC all'interno di una singola richiesta per ridurre al minimo il sovraccarico di invio di richieste sulla rete. Inoltre, questa procedura implementa il meccanismo delle funzioni di callback per la ricezione delle risposte.

protocollo NFS

Quando un client si avvia con NFS, il primo passo è l'operazione di montaggio, che consiste nel montare il filesystem remoto nello spazio del filesystem locale. Questo processo inizia con una chiamata alla procedura di montaggio (una delle funzioni del sistema Linux), che viene reindirizzata attraverso il VFS al componente NFS. Quindi, utilizzando una chiamata RPC alla funzione get_port sul server remoto, viene determinato il numero di porta che verrà utilizzato per il montaggio e il client invia una richiesta di montaggio tramite RPC. Questa richiesta lato server è gestita da uno speciale demone rpc.mountd responsabile del protocollo di montaggio ( protocollo di montaggio). Il demone verifica che il file system richiesto dal client sia nell'elenco dei sistemi disponibili sul server specificato. Se il sistema richiesto esiste e il client ha accesso ad esso, il descrittore del file system viene specificato nella risposta della procedura di montaggio RPC. Il client conserva le informazioni sui punti di montaggio locali e remoti ed è in grado di effettuare richieste di I/O. Il protocollo di montaggio non è impeccabile dal punto di vista della sicurezza, quindi NFSv4 utilizza invece chiamate RPC interne, che possono anche manipolare i punti di montaggio.

Per leggere un file, devi prima aprirlo. Non esiste una procedura OPEN in RPC; invece, il client verifica semplicemente che il file e la directory specificati esistano sul filesystem montato. Il client inizia effettuando una richiesta RPC GETATTR per la directory, che restituisce gli attributi della directory o un indicatore che la directory non esiste. Successivamente, per verificare l'esistenza del file, il client effettua una richiesta RPC LOOKUP. Se il file esiste, viene effettuata una richiesta RPC GETATTR per scoprire gli attributi del file. Utilizzando le informazioni ottenute dalle chiamate LOOKUP e GETATTR riuscite, il client crea un descrittore di file che viene presentato all'utente per richieste future.

Dopo che il file è stato identificato nel file system remoto, il client può inviare richieste RPC READ. Questa richiesta consiste in un descrittore di file, stato, offset e numero di byte da leggere. Il client utilizza lo stato ( stato) per determinare se l'operazione può essere eseguita al momento, ad es. se il file è bloccato. Compensare ( compensare) indica da dove iniziare la lettura e il contatore di byte ( contare) determina quanti byte leggere. Come risultato di una chiamata RPC READ, il server non restituisce sempre tutti i byte richiesti, ma trasmette sempre insieme ai dati restituiti quanti byte sono stati inviati al client.

Innovazione in NFS

Di grande interesse sono le due ultime versioni di NFS - 4 e 4.1, che possono essere utilizzate per studiare gli aspetti più importanti dell'evoluzione della tecnologia NFS.

Prima dell'avvento di NFSv4, per eseguire attività di gestione dei file come montaggio, blocco, ecc. c'erano speciali protocolli aggiuntivi. In NFSv4, il processo di gestione dei file è stato semplificato in un unico protocollo; inoltre, da questa versione UDP non è più utilizzato come protocollo di trasporto. NFSv4 include il supporto per la semantica di accesso ai file UNIX e Windows®, che consente a NFS di integrarsi naturalmente in altri sistemi operativi.

NFSv4.1 ha introdotto il concetto di NFS parallelo(parallelo NFS - pNFS). Per fornire una maggiore scalabilità, NFSv4.1 implementa un'architettura in cui dati e metadati ( markup) sono distribuiti tra i dispositivi in ​​modo simile ai file system in cluster. Come illustrato, pNFS divide l'ecosistema in tre pilastri: client, server e storage. In questo caso compaiono due canali: uno per la trasmissione dei dati e l'altro per la trasmissione dei comandi di controllo. pNFS separa i dati dai metadati che li descrivono, fornendo un'architettura a due canali. Quando un client vuole accedere a un file, il server gli invia i metadati "markup". I metadati contengono informazioni sulla posizione del file sui dispositivi di archiviazione. Con queste informazioni, il client può accedere direttamente allo storage senza dover interagire con il server, il che migliora la scalabilità e le prestazioni. Quando il cliente finisce di lavorare sul file, conferma le modifiche apportate al file e il suo "markup". Se necessario, il server può richiedere i metadati di markup dal client.

Con l'introduzione di pNFS, sono state aggiunte diverse nuove operazioni al protocollo NFS per supportare questo meccanismo. Il metodo LayoutGet viene utilizzato per recuperare i metadati dal server, il metodo LayoutReturn "libera" i metadati "catturati" dal client e il metodo LayoutCommit carica il "markup" ricevuto dal client nel repository in modo che sia disponibile ad altri utenti. Il server può revocare i metadati dal client utilizzando il metodo LayoutRecall. I metadati "contrassegnati" vengono distribuiti su più dispositivi di archiviazione per fornire accesso simultaneo e prestazioni elevate.

Dati e metadati sono archiviati in dispositivi di archiviazione. I client possono effettuare richieste di I/O dirette in base al markup risultante e il server NFSv4.1 archivia e gestisce i metadati. Questa funzionalità in sé non è nuova, ma a pNFS è stato aggiunto il supporto per vari metodi di accesso ai dispositivi di archiviazione. Oggi pNFS supporta l'uso di protocolli a blocchi (Fiber Channel), protocolli oggetto e NFS stesso (nemmeno in forma pNFS).

NFS continua ad evolversi e i requisiti NFSv4.2 sono stati pubblicati nel settembre 2010. Alcune delle innovazioni sono legate alla migrazione osservata delle tecnologie di storage verso la virtualizzazione. Ad esempio, in ambienti virtuali con un hypervisor, la duplicazione dei dati è altamente probabile (più sistemi operativi leggono / scrivono e memorizzano nella cache gli stessi dati). Pertanto, è auspicabile che il sistema di archiviazione nel suo insieme comprenda dove si verifica la duplicazione. Questo approccio può aiutare a conservare lo spazio della cache del client e la capacità di archiviazione complessiva. NFSv4.2 suggerisce di utilizzare una "mappa a blocchi di blocchi condivisi" per risolvere questo problema. Poiché i moderni sistemi di archiviazione sono sempre più dotati di una propria potenza di elaborazione interna, viene introdotta la copia lato server per ridurre l'onere della copia dei dati sulla rete interna quando può essere eseguita in modo efficiente sul dispositivo di archiviazione stesso. Altre innovazioni includono la memorizzazione nella cache dei file secondari per flash e consigli per la personalizzazione dell'I/O lato client (ad esempio, utilizzando mapadvise).

Alternative NFS

Sebbene NFS sia il file system di rete più popolare su UNIX e Linux, esistono altri file system di rete oltre ad esso. La piattaforma Windows® utilizza più comunemente SMB, noto anche come CIFS; tuttavia, Windows supporta anche NFS, così come Linux supporta SMB.

Uno dei più recenti file system distribuiti supportati da Linux, Ceph, è stato progettato da zero per essere un file system conforme a POSIX a tolleranza d'errore. Maggiori informazioni su Ceph possono essere trovate nella sezione.

Degni di menzione sono anche i file system OpenAFS (la versione Open Source dell'Andrew Distributed File System sviluppato presso la Carnegie Mellon University e IBM), GlusterFS (un file system distribuito generico per organizzare l'archiviazione scalabile dei dati) e Lustre (un file di rete massicciamente parallelo sistema per soluzioni cluster). Tutti questi sistemi open source possono essere utilizzati per creare storage distribuito.

Conclusione

Lo sviluppo del file system NFS continua. Simile a Linux, adatto a supportare soluzioni economiche, integrate e ad alte prestazioni, NFS fornisce un'architettura di soluzioni di storage scalabili adatte sia a individui che a organizzazioni. Osservando il percorso che NFS ha percorso e il suo sviluppo futuro, diventa chiaro che questo file system continuerà a cambiare il modo in cui pensiamo al modo in cui le tecnologie di archiviazione dei file vengono implementate e utilizzate.

Network File System NFS, o Network File System, è un popolare protocollo di file system di rete che consente agli utenti di montare directory di rete remote sulla propria macchina e trasferire file tra server. Puoi utilizzare lo spazio su disco su un'altra macchina per i tuoi file e lavorare con file che si trovano su altri server. In realtà, questa è un'alternativa alla condivisione di Windows per Linux, a differenza di Samba, è implementata a livello di kernel e funziona in modo più stabile.

Questo articolo ti guiderà attraverso l'installazione di nfs su Ubuntu 16.04. Illustreremo l'installazione di tutti i componenti necessari, la configurazione di una cartella condivisa e la connessione delle cartelle di rete.

Come già accennato, NFS è un filesystem di rete. Per funzionare, è necessario un server che ospiterà la cartella condivisa e client in grado di montare la cartella di rete come un normale disco nel sistema. A differenza di altri protocolli, NFS fornisce un accesso trasparente ai file remoti. I programmi vedranno i file come in un normale file system e lavoreranno con loro come con i file locali, nfs restituisce solo la parte richiesta del file, invece dell'intero file, quindi questo file system funzionerà bene su sistemi con Internet veloce o rete locale .

Installazione dei componenti NFS

Prima di poter lavorare con NFS, dobbiamo installare alcuni programmi. Sulla macchina che sarà il server, è necessario installare il pacchetto nfs-kernel-server, che aprirà le condivisioni nfs in Ubuntu 16.04. Per fare ciò, esegui:

sudo apt install nfs-kernel-server

Ora controlliamo se il server è stato installato correttamente. Il servizio NFS ascolta le connessioni sia per TCP che per UDP sulla porta 2049. Puoi vedere se queste porte vengono effettivamente utilizzate con il comando:

rpcinfo -p | grep nfs

È anche importante verificare se NFS è supportato a livello di kernel:

cat / proc / filesystem | grep nfs

Vediamo cosa funziona, ma in caso contrario, è necessario caricare manualmente il modulo del kernel nfs:

Aggiungiamo anche nfs all'avvio:

sudo systemctl abilita nfs

Sul computer client, è necessario installare il pacchetto nfs-common per poter lavorare con questo file system. Non è necessario installare i componenti del server, sarà sufficiente questo pacchetto:

sudo apt install nfs-common

Configurare un server NFS su Ubuntu

Possiamo aprire l'accesso NFS a qualsiasi cartella, ma creiamone una nuova per questo scopo:

cartella_indirizzo client (opzioni)

L'indirizzo della cartella è la cartella che si desidera rendere disponibile in rete. Client - indirizzo IP o indirizzo di rete da cui è possibile accedere a questa cartella. Ma le opzioni sono un po' più complicate. Consideriamone alcuni:

• rw- consentire la lettura e la scrittura in questa cartella
• ro- consenti la sola lettura
• sincronizzare- rispondere alle seguenti richieste solo quando i dati vengono salvati su disco (impostazione predefinita)
• asincrono- non bloccare le connessioni durante la scrittura dei dati su disco
• sicuro- utilizzare solo le porte inferiori a 1024 per la connessione
• insicuro- usa qualsiasi porta
• nohide- non nascondere le sottodirectory quando si apre l'accesso a più directory
• root_squash- sostituire le richieste da root con quelle anonime
• all_squash- rendere anonime tutte le richieste
• anonuido e anongid- specifica l'uid e il gid per l'utente anonimo.

Ad esempio, per la nostra cartella, questa riga potrebbe assomigliare a questa:

/var/nfs 127.0.0.1 (rw, sync, no_subtree_check)

Quando tutto è stato impostato, resta da aggiornare la tabella di esportazione NFS:

sudo exportfs -a

Ecco fatto, l'apertura delle palle nfs in Ubuntu 16.04 è completa. Ora proviamo a configurare il client e proviamo a montarlo.

Connessione NFS

Non ci soffermeremo su questo problema in dettaglio nell'articolo di oggi. Questo è un argomento abbastanza ampio che merita un articolo a parte. Ma dirò poche parole.

Per montare una cartella di rete non è necessario alcun client ubuntu nfs, basta usare il comando mount:

sudo mount 127.0.0.1:/var/nfs/ / mnt /

Ora puoi provare a creare un file nella directory connessa:

Vedremo anche i filesystem montati con df:

127.0.0.1:/var/nfs 30G 6,7G 22G 24% / mnt

Per disabilitare questo file system, usa semplicemente l'umount standard:

sudo umount / mnt /

conclusioni

Questo articolo ha esaminato la configurazione di nfs ubuntu 16.04, come puoi vedere, tutto è fatto in modo molto semplice e trasparente. La connessione delle condivisioni NFS viene eseguita in pochi clic utilizzando i comandi standard e l'apertura delle condivisioni nfs in Ubuntu 16.04 non è molto più difficile della connessione. Se hai domande, scrivi nei commenti!

Voci correlate: