NetworkLockManager
Network Lock Manager (NLM) är ett protokoll som fungerar i samarbete med Network File System (NFS) för att tillhandahålla liknande POSIX-meddelandefillåsningssemantik för NFS version 2 och 3.
Den har en arkitektur som inkluderar klientfunktioner, som är klienten som är ansvarig för att bearbeta applikationsförfrågningar och skicka dem till nätverkslåshanteraren på servern. Och servern kommer att ansvara för att acceptera låsförfrågningar från klienter och generera lämpliga låsanrop på servern.
Detta protokoll består av två demoner som körs kontinuerligt på både NFS-servern och NFS-klienterna för att veta vilka processer som är blockerade och vilka som har blocken. En av dessa demoner är nätverkslåshanteraren (rpc.lockd) och den andra är nätverksstatusövervakaren (rpc.statd), så låt oss titta närmare på dem.
Historik
Det här protokollet uppstod efter lanseringen av NFS med tillägget av byteintervalllåsningsstöd i SunOS, eftersom byteintervalllåsning kräver ett tillståndsprotokoll.
Det har funnits 4 olika versioner av NLM-protokollet, version 1 till 3 är praktiskt taget identiska med undantag för ytterligare funktioner som har lagts till i version 2 och 3 för att rymma icke-UNIX-klienter (läs PC-NFS för DOS och Windows ). Dessa versioner är alla för NFS version 2.
Med lanseringen av NFS version 3 var filhanteringsstrukturen för NFS-protokollet tvungen att ändra sitt trådformat. Genom att dela denna struktur med NFS-protokollet innebar detta att en ny version av NLM specificerades. NLM version 4 används tillsammans med NFS version 3.
Med version 4 av NFS har NLM-protokollet tagits bort och låsfunktionerna implementeras i själva NFS-protokollet.
Demoner
rpc.lockd
Denna demon är implementerad som en pool av kärntrådar (liknande NFS-servern). Den kommer att ta emot meddelanden från NFS-klienten när ett lås begärs, och den kommer att skicka NLM-förfrågningar till NLM-servern på NFS-servermaskinen, och den kommer att ta emot NLM-förfrågningar från NFS-klienterna på maskinen den körs på, och den kommer att göra lokala blockeringssamtal på namnen på dessa klienter.
rpc.statd
Den här demonen är en process på användarnivå som körs på varje klusternod ifall noden misslyckas medan den håller ett lås på NFS-servern. När detta inträffar kommer rpc.statd-programmet på klusternoden att meddela NFS-servern när klusternoden startas om och nu är i drift igen. Rpc.statd på NFS-klienten vet att göra detta, eftersom den skriver namnet på varje NFS-server till en lokal enhet första gången en process som körs på klusternoden försöker låsa en fil på NFS-servern.
Lockdown process
När ett program vill erhålla ett lås på en lokal fil, skickar det sin begäran till kärnan med hjälp av lockf , fcntl , eller flock -subrutinerna .
Kärnan bearbetar låsbegäran. Men om ett program på en NFS-klient gör en låsbegäran för en fjärrfil, utfärdar NLM-klienten ett fjärrproceduranrop (RPC) till servern för att hantera begäran.
När klienten tar emot en första begäran om fjärrlåsning, registrerar den intresse för servern med klientens rpc.statd-demon. Detsamma gäller nätverkslåshanteraren på servern. På den första begäran från en klient registrerar den intresse för klienten med den lokala nätverkshälsoövervakaren.
Beroenden
Det finns fyra beroenden:
- ONC-RPC: NLM-protokollen implementeras över ONC-RPC som programnummer 100021. NLM implementeras vanligtvis över UDP men det finns klienter som använder TCP.
- Portmap: En klient behöver vanligtvis Portmap-tjänsten för att upptäcka på vilken port NSM-tjänsten är tillgänglig.
- NSM: Låshanterare förlitar sig på NSM-protokollet för att meddela varandra om tjänstestarter/-omstarter så att lås kan synkroniseras om efter en omstart.
- KLM: På vissa plattformar, gränssnittet över loopback-gränssnittet där NFS-klientkoden i kärnan talar med användarutrymmeslåshanteraren.
Synkron vs asynkron
Det finns två typer av NLM som tillhandahåller samma funktionalitet; Synkron och asynkron . Nästan alla implementeringar använder den synkrona versionen, även om vissa, som HP-UX, använder den asynkrona versionen. Den största skillnaden är att den synkrona versionen NLM är ett normalt ONC-RPC begäran/svarsprotokoll, medan den asynkrona versionen är ett meddelande/meddelandeprotokoll.
I den asynkrona versionen av NLM kommer det inte att finnas något ONC-RPC-lagersvar, istället skickas NLM-svaren som ONC-RPC-begäranmeddelanden. Detta innebär att ONC-RPC Transaction ID (XID) inte kan användas för att matcha förfrågningar med svar, och inte heller kan XID användas för att upptäcka potentiella återsändningar. Istället används cookiefältet i början av varje NLM PDU för att matcha förfrågningar och svar. Detta cookiefält finns också i den synkrona versionen av NLM men har ingen semantisk betydelse där.
Portintervall
Miljövariabeln NFS_PORT_RANGE kan användas för att begränsa källporten för nätverksanrop som klienten gör till servern.
För att använda denna variabel måste den läggas till i filen /etc/environment med följande format:
NFS_PORT_RANGE=udp[4000-5000]:tcp[7000-8000]
Här kan vi se att UDP-paket som skickas av klienten har en källport i intervallet 4000 - 5000, och TCP-anslutningar har en källport i intervallet 7000 - 8000. För att undvika problem med portåteranvändning numrerar portarna portar som anges i detta intervall ska inte användas som fasta portnummer för någon av NFS-demonerna i filen /etc/services .
