Network Lock Manager
Network Lock Manager (NLM) è un protocollo che funziona in collaborazione con Network File System (NFS) per fornire una semantica di blocco dei file di avviso POSIX di stile simile per NFS versione 2 e 3.
Ha un'architettura che include funzioni client, essendo il client responsabile dell'elaborazione delle richieste delle applicazioni e dell'invio delle stesse al gestore di blocco di rete sul server. E il server sarà responsabile dell'accettazione delle richieste di blocco dai client e della generazione delle chiamate di blocco appropriate sul server.
Questo protocollo è costituito da due demoni che funzionano continuamente sia sul server NFS che sui client NFS per sapere quali processi sono bloccati e quali hanno i blocchi. Uno di questi demoni è il network lock manager (rpc.lockd) e l'altro è il network status monitor (rpc.statd), quindi diamo un'occhiata più da vicino.
Storia
Questo protocollo è nato dopo il rilascio di NFS con l'aggiunta del supporto per il blocco dell'intervallo di byte in SunOS, poiché il blocco dell'intervallo di byte richiede un protocollo con stato.
Ci sono state 4 diverse versioni del protocollo NLM, le versioni da 1 a 3 sono praticamente identiche ad eccezione delle funzionalità aggiuntive che sono state aggiunte alla versione 2 e 3 per ospitare client non UNIX (leggi PC-NFS per DOS e Windows). Queste versioni sono tutte per NFS versione 2.
Con il rilascio della versione 3 di NFS, la struttura dell'handle di file per il protocollo NFS ha dovuto modificare il formato wire. Condividendo questa struttura con il protocollo NFS, ciò significava che veniva specificata una nuova versione di NLM. NLM versione 4 viene utilizzato insieme a NFS versione 3.
Con la versione 4 di NFS, il protocollo NLM è stato rimosso e le funzionalità di blocco sono implementate nel protocollo NFS stesso.
Demoni
rpc.lockd
Questo demone è implementato come un pool di thread del kernel (simile al server NFS). Riceverà messaggi dal client NFS quando viene richiesto un blocco e invierà richieste NLM al server NLM sulla macchina del server NFS e riceverà richieste NLM dai client NFS della macchina su cui è in esecuzione, e effettuerà chiamate di blocco locali sui nomi di quei client.
rpc.statd
Questo demone è un processo a livello di utente che viene eseguito su ciascun nodo del cluster nel caso in cui il nodo si guasta mentre si mantiene un blocco sul server NFS. Quando ciò si verifica, il programma rpc.statd sul nodo del cluster avviserà il server NFS quando il nodo del cluster viene riavviato e ora è di nuovo operativo. Rpc.statd sul client NFS sa farlo, perché scrive il nome di ciascun server NFS su un'unità locale la prima volta che un processo in esecuzione sul nodo del cluster tenta di bloccare un file sul server NFS.
Processo di blocco
Quando un'applicazione vuole ottenere un blocco su un file locale, invia la sua richiesta al kernel usando le subroutine lockf , fcntl o flock .
Il kernel elabora la richiesta di blocco. Tuttavia, se un'applicazione su un client NFS effettua una richiesta di blocco per un file remoto, il client NLM invia una chiamata di procedura remota (RPC) al server per gestire la richiesta.
Quando il client riceve una richiesta iniziale di blocco remoto, registra l'interesse per il server con il demone rpc.statd del client. Lo stesso vale per il gestore del blocco di rete sul server. Alla richiesta iniziale di un client, registra l'interesse per il client con il monitoraggio dello stato della rete locale.
Dipendenze
Ci sono quattro dipendenze:
- ONC-RPC: i protocolli NLM sono implementati su ONC-RPC come programma numero 100021. NLM è generalmente implementato su UDP ma ci sono client che usano TCP.
- Portmap: un client in genere necessita del servizio Portmap per scoprire su quale porta è disponibile il servizio NSM.
- NSM: i peer di gestione dei blocchi si affidano al protocollo NSM per notificarsi reciprocamente i riavvii/riavvii del servizio in modo che i blocchi possano essere risincronizzati dopo un riavvio.
- KLM: su alcune piattaforme, l'interfaccia sull'interfaccia di loopback in cui il codice client NFS nel kernel comunica con il gestore del blocco dello spazio utente.
Sincrono vs asincrono
Esistono due tipi di NLM che forniscono la stessa funzionalità; Sincrono e asincrono . Quasi tutte le implementazioni utilizzano la versione sincrona, sebbene alcune, come HP-UX, utilizzino la versione asincrona. La differenza principale è che la versione sincrona NLM è un normale protocollo di richiesta/risposta ONC-RPC, mentre la versione asincrona è un protocollo di messaggio/messaggio.
Nella versione asincrona di NLM non ci sarà alcuna risposta del livello ONC-RPC, invece le risposte NLM vengono inviate come messaggi di richiesta ONC-RPC. Ciò significa che l'ID transazione (XID) ONC-RPC non può essere utilizzato per abbinare le richieste alle risposte, né l'XID può essere utilizzato per rilevare potenziali ritrasmissioni. Al contrario, il campo cookie all'inizio di ogni PDU NLM viene utilizzato per abbinare richieste e risposte. Questo campo cookie è presente anche nella versione sincrona di NLM ma non ha alcun significato semantico lì.
Intervallo di porte
La variabile di ambiente NFS_PORT_RANGE può essere utilizzata per limitare la porta di origine delle chiamate di rete che il client effettua al server.
Per utilizzare questa variabile deve essere aggiunta al file /etc/environment con il seguente formato:
NFS_PORT_RANGE=udp[4000-5000]:tcp[7000-8000]
Qui possiamo vedere che i pacchetti UDP inviati dal client hanno una porta di origine nell'intervallo 4000 - 5000 e le connessioni TCP hanno una porta di origine nell'intervallo 7000 - 8000. Per evitare problemi di riutilizzo delle porte, la porta numera le porte specificate in questo intervallo non dovrebbe essere utilizzato come numero di porta fisso per nessuno dei daemon NFS nel file /etc/services .
