Ugrás a tartalomhoz

Operációs rendszerek mérnöki megközelítésben

Benyó Balázs, Fék Márk, Kiss István, Kóczy Annamária, Kondorosi Károly, Mészáros Tamás, Román Gyula, Szeberényi Imre, Sziray József

Panem Kiadó

5.4. Hálózati és elosztott szolgáltatások a UNIX-ban

5.4. Hálózati és elosztott szolgáltatások a UNIX-ban

A UNIX történetének egyik legfontosabb állomása volt, amikor az 1984-ben kiadott BSD UNIX-ba bekerült a TCP/IP protokoll támogatása. A TCP/IP támogatást ezután a többi UNIX-verzió is gyorsan átvette. A UNIX egyik nagy erőssége azóta, hogy igen könnyű hálózatba kötni az akár különböző hardveren futó UNIX-rendszereket.

A UNIX-rendszerek fejlesztői azóta is nagy súlyt fektettek a hálózati szolgáltatások fejlesztésére. Az egyik legfontosabb hálózati szolgáltatás az elosztott fájlrendszerek biztosítása. A UNIX-rendszerek több alternatívát is kínálnak hálózaton keresztül történő fájlekérés támogatására (például HA-NFS, Remote File Sharing – RFS, Andrew File System, Unix to Unix Copy). Ezek közül a legsikeresebb a megjelenése óta az elosztott fájlrendszerek szabványává vált SUN Network File System, amit részletesen is bemutatunk. Ennek a rendszernek a bemutatása alkalmat ad számos hálózati protokoll ismertetésére is.

5.4.1. A TCP/IP protokoll család

A TCP/IP családba tartozó protokollok nem a fizikai átviteli közeg elérését szabályozzák, mint például az Ethernet, hanem a fizikai átvitel fölé épülnek. Ezek a protokollok a csomópontok címzési módját, illetve a hálózaton továbbított adatcsomagok méretét és formátumát rögzítik.

A család legalacsonyabb szintű protokollja az IP (Internet Protokoll). Az IP protokoll nem biztosít megbízható átvitelt, az adatcsomagok késhetnek, sérülhetnek, duplikálódhatnak, elveszhetnek, de csak abban az esetben, ha az IP által használt hálózat hibázik. (Ez pontosan azt jelenti, hogy az IP használata nem jelent garanciát az ilyen hibák kiküszöbölésére.) Az IP adatcsomagok formátuma viszonylag bonyolult, méretük maximum 64 kbyte lehet. Mindig egy ún. fejrésszel (header) kezdődnek, ami tartalmazza a küldő és a címzett csomópont IP-címét. Ez az egyetlen része az üzenetnek, mely redundáns, vagyis védett a sérülések ellen, megteremtve a lehetőségét annak, hogy az IP protokollt megvalósító szoftver felismerje az esetleges hibákat (5.35. ábra).

5.35. ábra. ábra - Egy IP-adatcsomag vázlatos felépítése

Egy IP-adatcsomag vázlatos felépítése


Az IP protokollt megvalósító szoftver feladata ezek után az, hogy az IP-címet a helyi hálózatban használatos címmé alakítsa, és az adatcsomagot továbbküldje, elvégezve a használt alacsonyabb szintű protokollnak megfelelő változtatásokat az adatrészben. Az IP protokoll nagyon népszerű a hálózati rendszerekben. Több megvalósítása létezik különböző, alacsony szintű hálózati protokollok fölé, így Ethernet hálózat fölé is.

Az IP protokollra számos más protokoll épül. A TCP (Transport Control Protocol) az IP protokollra épülve megbízható hálózati átvitelt garantál, míg az UDP (User Datagram Protocol) ugyancsak az IP-re épülve csak az üzenetek továbbítását biztosítja. Mindkét protokoll lehetőséget ad a csomóponto­kon futó folyamatok közvetlen elérésére (címzésére) az ún. process port-okon keresztül.

Mind a TCP mind az UDP közvetlenül is elérhető különböző alkalmazások számára. Nagyon sok magasabb szintű szolgáltatást adó protokoll épül a TCP/IP család protokolljaira. A TCP-t használó legismertebb szolgáltatások: fájlok átvitele távoli gépekre (FTP: file transfer), távoli gépekre történő belépés (telnet), továbbá elektronikus mail (e-mail) szolgáltatás alapját adó SMTP protokoll. Az UDP-t használó szolgáltatások: távoli gépeken dolgozó felhasználók azonosítójának lekérdezése (rwho), fájlok hordozása (TFTP).

5.4.2. A SUN Network File System (NFS)

A SUN NFS a SUN cég (USA) által kifejlesztett elosztott állományrendszer, első változata 1985-ben jelent meg. Megjelenésével egyidőben szabadon elérhetővé tették az általa használt protokollt, valamint referencia-implementációkat is közzétettek, melyek nagyban elősegítették a rendszer elterjedését. Ma már, széles körű használata miatt, mintegy szabványnak tekinthető az elosztott állományrendszerek körében.

5.4.2.1. A SUN NFS jellemző tulajdonságai

A SUN NFS a kliens-szerver modellre épül. A kliens és a szerver egymástól független, szétválasztható, azonos vagy távoli gépeken is futhatnak. A szolgáltatás az ún. távoli eljáráshívásra (RPC: Remote Procedure Call) épül, mely módszert a későbbiekben részletesen is ismertetjük. A SUN NFS az RPC szinkron megvalósítását használja, vagyis a kliens folyamatok mindig várakoznak a kérésük teljesítésére.

A SUN NFS felhasználói felületének lehetőségei a következők:

  • Egy vagy több fájlrendszer teljes vagy részleges (részfa) exportálása (láthatóvá tétele a rendszer többi csomópontja számára) lehetséges egy adott csomópontról.

  • Konfigurációs fájl készíthető az exportált fájlrendszert elérő kliensek definiálá­sára, amelynek segítségével például a felhasználói azonosítók alapján szabályoz­hatjuk az egyes fájlrendszerek elérését.

  • Távoli fájlrendszer csatlakoztatásának (mount-olásának) lehetősége a lokális fájlrendszerhez az elérési jogosultságok definiálásával.

  • Szoros (hard), illetve laza (soft) csatlakoztatás: Szoros csatlakoztatás esetén a rendszer addig próbálkozik a kívánt fájl elérésével, míg az sikerrel nem jár. Laza csatlakoztatás esetén néhány sikertelen próbálkozás után a rendszer hibaüzenetet küld.

  • A SUN NFS a távoli fájloknak a lokális fájlokkal azonos módon történő elérését biztosítja.

  • A szerver csak a saját, lokális fájlrendszerét exportálhatja a rekurzió elkerülése érdekében.

A SUN NFS tervezői a következő célokat tűzték a rendszer elé:

  • A protokoll legyen megvalósítható minden operációs rendszer alatt.

  • A protokoll hardverfüggetlen legyen.

  • Létezzen egyszerű újraindítási lehetőség a kliens, illetve a szerver számára.

  • A kliens kezelje az operációs rendszertől függő fájlelérési metodikát.

  • Az NFS teljesítménye a helyi fájlrendszer teljesítményével összemérhető legyen.

  • A hálózati összeköttetéstől független, illetve a forgalomnövekedéssel bővíthető kapacitású implementációt tegyen lehetővé.

Az NFS specifikáció következménye az állapotmentes megvalósítás. Ennek előnye, hogy a kliensek kérései függetlenek egymástól, így önállóan is értelmezhetők. A kliens állapota a szerverben nem tárolt (az csak statisztikai információt gyűjthet), ami biztosítja a szerver egyszerű újraindítható­ságát.

Hátránya az állapotmentes megvalósításnak, hogy a szerver csak stabil állapotában válaszolhat a kliens kéréseire, ami időkésleltetést okozhat a rendszer működésében. Egy egyszerű példával illusztrálható ez a szituáció. Tegyük fel, hogy a szerver, cache memóriát használ a fájlok elérésére. Az NFS szerver egy fájlírási kérés végrehajtása esetén csak a művelet teljes lezárását követően, azaz a cache lemezre történő kiírása után válaszolhat a kliens kérésére. Ellenkező esetben esetleges rendszerhiba (például áramszünet miatti rendszerleállás) esetén a cache tartalma elveszhet, ami a kliens fájlírás kérésének meghiúsulását jelentené. Ha a szerver a cache kiírása előtt nyugtázná a kliens kérését, akkor nem biztosítaná a kért szolgáltatás biztonságos megvalósítását, ami viszont az RPC protokollban előírás.

5.4.2.2. A SUN NFS részei

A SUN NFS működését nem egyetlen protokoll, hanem egymásra épülő protokollok halmaza biztosítja. A protokollok önmagukban is értelmesek, szá­mos, az NFS-től független alkalmazás használja őket.

A SUN NFS által használt protokollok a következők:

  • NFS protokoll: a fájlelérés magas szintű protokollja. Definiálja, hogy a kliens és a szerver hogyan tudnak együttműködni. A kliens a szervertől milyen szolgáltatásokat kérhet, milyen kérései lehetnek, illetve a szerver milyen válaszokat adhat. Például: get/setattrib(fájl), lookup(fájl_név), write(fájl), read(fájl).

  • RPC (Remote Procedure Call) protokoll: a távoli eljáráshívás protokollja. Rögzíti, hogy két folyamat hogyan tud egymással kommunikálni, és ezáltal egyik a másik szolgáltatását elérni. Az NFS kliens és a szerver közötti kommunikáció RPC-csomagokkal (RPC-hívásokkal) történik.

  • XDR (EXtended Data Representation) protokoll: a rendszerfüggetlen adatábrázolást rögzítő protokoll. Szabványos leírás a különböző típusú adatok egységes hardverfüggetlen ábrázolására és kommunikációs csatornán (hálózaton) történő továbbítására.

  • Mount protokoll: távoli fájlrendszerek összekapcsolását leíró protokoll. A csatlakoztatás a távoli fájlrendszer helyi fájlrendszerben történő láthatóvá tétele, bekapcsolása. A csatlakoztatás után a távoli fájlrendszer a lokális fájlrendszer egyik alkönyvtárán keresztül lesz elérhető. A mount protokoll definiálja, hogy hogyan történjen a távoli fájlrendszer bekapcsolása, milyen csatlakoztatással kapcsolatos szolgáltatásokat érhet el a felhasználó.

    A mount protokoll tipikus szolgáltatásai: mount: távoli fájlrendszer helyi fájlrendszerben történő láthatóvá tétele unmount: kapcsolat megszüntetése dump: a fájlrendszerbe „felmountolt” távoli fájlrendszerek kilistázása.

A protokollokat megvalósító, egy működő SUN NFS rendszerben megtalálható szoftver komponensek:

  • NFS-szerver. Az a szoftver egység ami megvalósítja a protokollban definiált szolgáltatásokat, illetve a rendszer működéséhez szükséges egyéb funkciókat (üzenetküldés, fogadás stb.). Tartalmazza – általában függvények formájában – az egyes szolgáltatásokat megvalósító kódot. Például: a szerver oldalon lesz egy lookup() függvény, mely egy elérési út/fájl név paraméterrel meghíva kikeresi a megnevezett fájlt és visszaadja annak fájlleíróját.

  • NFS kliens kód. A kliens oldali funkciókat (üzenetküldés, fogadás, adatkonverzió stb.) megvalósító szoftver. Biztosítja a kliens oldalon futó alkalmazásnak, hogy a helyi fájlok elérésével azonosan tudják kezelni a távoli fájlokat. Például: kliens az NFS-en keresztül távoli fájlt szeretne elérni, akkor a rendszer az NFS klienshez fordul, amely kapcsolódik a szerverhez, és megvalósítja a távoli fájl elérését.

  • Démon (daemon) folyamatok. Az NFS-szerver állandóan elérhető szolgáltatásait megvalósító folyamatok. Ezek az NFS szolgáltatás in­dításakor elindulnak, és figyelik, majd lekezelik a bejövő kéréseket.

    Tipikus démon processzek:

    biod: blokkos adatátvitelt kezelő démon. A kliens felől érkező adattömeget kezeli és továbbítja a szerverhez, illetve a szerver felől érkező adattömeget kezeli és továbbítja a kliensnek.

    mountd: csatlakoztatással kapcsolatos kéréseket elégíti ki.

    nfsd: a fájlok elérésével kapcsolatos kéréseket intézi.

  • NLM (Network Lock Manager). Önálló szoftverkomponense a rendszernek. Az NLM segítségével a kliensek jelezhetik, hogy kizárólagosan szeretnének egy fájlt megnyitni és használni, vagyis szeretnék a fájlt zárolni (lock művelet). Opcionális szoftver komponense az NFS rendszernek, nem minden NFS használja.

  • NSM (Network Status Manager). A fájlok állapotának (lock-olt/nem lock-olt) lekérdezésére szolgáló komponens. Az NSM az NLM-hez hasonlóan opcionális része az NFS-nek.

5.4.2.3. XDR (EXtended Data Representation) protokoll

  • Az XDR protokoll rögzíti különböző típusú adatok hardverfüggetlen ábrázolásának, illetve a hálózaton történő továbbításának módját. Definiálja az adatelemek méretét, azok sorrendjét átvitel esetén, valamint az adatelemek formátumát. Például az egész számokat (integer típus) négy bájton ábrázolja, hálózati transzfer esetén elsőként a legfelső bájtot küldi át. A negatív egészeket kettes komplemens kódolásban ábrázolja. Tömbök átvitele esetén a tömb elé beszúrja a tömb hosszát (5.34. ábra).

5.36. ábra. ábra - Példa az XDR adatábrázolásra

Példa az XDR adatábrázolásra


Az XDR által definiált alap-adattípusok halmazát a felhasználó bővítheti. A protokoll az új adattípusok ábrázolására egy szabályrendszert (adattípus-leíró formális nyelvet) ad, melynek segítségével akár kombinált típusok is definiálhatók.

5.4.2.4. Az RPC protokoll

Számos RPC (távoli eljáráshívás, remote procedure call) protokoll létezik, több szoftverfejlesztő cég definiált egymással párhuzamosan RPC protokollokat. Az RPC protokollt megvalósító szoftverek nem csak az NFS rendszerekben működnek, az RPC szolgáltatást az operációs rendszer számos más komponense, illetve az alkalmazások is használják.

Az RPC protokoll legfontosabb tulajdonsága, hogy megbízható üzenettovábbítást valósít meg a kommunikáló partnerek között. (Meg kell jegyezni, hogy számos más protokoll létezik, ami nem biztosít megbízható üzenettovábbítást.) A megbízható üzenettovábbítás megvalósításának leggyakoribb megoldása, hogy a protokollt megvalósító szoftver addig ismétli a küldendő üzenetet, míg annak vételéről nyugtázás nem érkezik.

Az RPC protokollok előírják üzenetváltás esetére:

  • az üzenetek formátumát (mit tartalmazhatnak az üzenetek),

  • az üzenetközvetítés módját (mely üzenetek milyen sorrendben küldhetők),

  • a partnerazonosítás (címzés) módját.

Fontos kérdés az RPC üzenetküldési módjának definiálásakor, hogy a kliens folyamat várakozik-e az általa kért szolgáltatás végrehajtására, vagyis a szerver válaszának megérkezéséig, avagy nem várakozik. Az első esetben szinkron, míg a második esetben aszinkron RPC protokollról beszélünk. Az RPC protokollok között léteznek mind szinkron, mind aszinkron megvalósítások.

A SUN NFS rendszerben az RPC protokoll a kliens és a szerver kommunikációjának formai definiálására szolgál. A kliens és a szerver között a kérés, illetve a válasz üzenetek RPC csomagok formájában vándorolnak. A SUN NFS a saját fejlesztésű SUN RPC protokollt használja, ami szinkron műveletvégzést és megbízható üzenettovábbítást biztosít. A SUN RPC protokoll az üzenetek formátumának definiálására az XDR protokollt használja.

5.4.2.5. Az RPC protokoll működése

Az RPC protokollt megvalósító rendszerek is a kliens-szerver modellre épülnek. A működés sémáját az 5.37. ábra szemlélteti.

Az RPC-kérés felépítése az 5.38. ábrán látható.

5.37. ábra. ábra - Az RPC működése

Az RPC működése


5.38. ábra. ábra - Az RPC-kérés felépítése

Az RPC-kérés felépítése


Az adatelemek magyarázata a következő:

  • XID – Minden egyes üzenetnek generál az RPC egy egyedi azonosítót, aminek alapján az üzenetet számon tartja, és ismétli, ha nem érkezik rá válasz. Az XID ez az azonosító.

  • IRÁNY – A kliens–szerver kommunikációban minden üzenet lehet kérés vagy válasz.

  • RPC verzió – Az RPC protokollnak több verziója létezik. Az üzenet formája (vagyis hogy milyen részeket tartalmaz) függhet az RPC aktuális verziójától.

  • PRG-azonosító – Az RPC-t, mint kommunikációs eszközt, több, párhuzamosan futó (applikáció) is használhatja. A PRG-azonosító tartalmazza a kért szolgáltatást nyújtó alkalmazás azonosítóját. Az NFS-szolgáltatások azonosítója például 1000003, vagyis minden NFS-csomagban ez az azonosító szerepel. Ebből tudja az RPC-szerver, illetve kliens, hogy az adott üzenetet az NFS-szervernek, illetve kliensnek kell továbbítania.

  • PRG verzió – Az adott szolgáltatás verziója. Az NFS-nek például két verziója létezik: 2-es és 3-as.

  • Azonosítási információ – A küldő folyamat azonosítója. UNIX-rendszer esetén ez például a process_ID (PID).

  • Adat – Az üzenet adatrésze. Ennek tartalma az RPC-t használó alkalmazástól függ.

Az RPC-válasz felépítése az 5.39. ábrán látható.

5.39. ábra. ábra - Az RPC-válasz felépítése

Az RPC-válasz felépítése


Az RPC-válasz adatelemei részben megegyeznek a kérés adat elemeivel. A válaszban szerepel a kért szolgáltatás státusa is, amely megadja, hogy sikeres volt-e a kért szolgáltatás végrehajtása, történt-e hiba a működés során stb.

5.4.2.6. A SUN NFS működése

Az 5.40. ábra az NFS-rendszer működését foglalja össze. Láthatjuk, hogy a fájlok elérését kezdeményező kéréseket, rendszerhívásokat az ún. virtuális fájlrendszer (VFS) kezeli. A virtuális fájlrendszer a hagyományos UNIX-fájlrendszert továbbfejlesztő fájlrendszer, ami lehetővé teszi különböző típusú fájlrendszerek kezelését a UNIX-rendszerben.

5.40. ábra. ábra - Az NFS működésének sémája

Az NFS működésének sémája


A virtuális fájlrendszer, ha lokális fájlt szeretne a kliens folyamat elérni, a kérést a helyi lemezt kezelő UNIX-fájlrendszer (UFS) felé továbbítja, amelyik a fájlt közvetlenül eléri és visszaadja a kért adatokat.

Ha a folyamat távoli fájlt szeretne elérni, a virtuális fájlrendszer a kérést az NFS-klienshez továbbítja. Az NFS-kliens a hálózaton keresztül eléri a kért fájlt tároló csomóponton működő NFS-szervert. A távoli NFS-szerver az ottani VFS-rendszeren keresztül kérést küld a helyi UNIX-fájlrendszernek (UFS). Az UFS visszaadja a kért adatokat az NFS-szervernek, aki továbbítja azokat a kérést kezdeményező kliens folyamat felé az NFS-kliens, illetve a kliens folyamat csomópontján működő virtuális fájlrendszeren (VFS) keresztül.

5.4.2.7. Távoli fájlok elérése NFS használatával

Az NFS-rendszer működését egy példán keresztül foglaljuk össze. Az 5.41. ábrán láthatóan egy kliens folyamat írást (write) hajt végre egy távoli fájlon.

A kliens folyamat a hagyományos interfészt használva kezdeményez egy fájlműveletet, vagyis végrehajt egy rendszerhívást [például write(fájl­le­író_- sor­szám, adat)].

A paraméterként megadott fájlleíró sorszám alapján a rendszer kikeresi a folyamatonkénti, illetve a globális fájltáblából a megfelelő bejegyzést. A v_data megmutatja, hogy milyen fájlrendszerbe tartozik az elérendő fájl, illetve az elérendő fájlrendszerben mik az azonosító adatai. A v_ops megmutatja, hol vannak az adott fájlrendszert kezelő rutin címei. A rendszer tudja, hogy az írás művelete, például a második rutin a fájlkezelő műveletek címeit tartalmazó táblázatban, így elugrik a második címre. A rutinok (távoli fájlról lévén szó) természetesen az NFS klienskódjában vannak implementálva.

5.41. ábra. ábra - Távoli fájl elérése NFS segítségével

Távoli fájl elérése NFS segítségével


Az NFS-kliens készít egy RPC-kérés csomagot, amit elküld a fájlszerver gépén működő RPC-szervernek. Az RPC-szerver észleli, hogy a csomag NFS-csomag, és továbbítja az NFS-szervernek. Az NFS-szerver a helyi VFS-rendszeren keresztül kezdeményezi az adott fájl írását. A távoli gépen (amelyiken a szerver fut) a VFS által használt globális fájl tábla-bejegyzésben természetesen már a lokális fájlok elérésére használt adatelemek lesznek, vagyis

a v_data az adott i-node-ra mutat, illetve a v_ops az UFS-kódjára.

Miután az UFS write művelete befejeződött, az NFS-szerver RPC-válasz formájában nyugtát küld vissza az NFS-kliensnek, amely felébreszti a várakozó kliens folyamatot.