Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon

Tudományos Diákköri Dolgozat

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon

Petróczi Attila V. évfolyam Mûszaki Informatika szak

Papp Krisztián V. évfolyam Villamosmérnöki szak

Konzulens: Gaál Balázs Ericsson Traffic Lab

1997 október

2


Tartalomjegyék

0. ÖSSZEFOGLALÁS ........................................................................................................................3 1. ELMÉLETI ALAPOK ......................................................................................................................4 1.1 AZ ETHERNET HÁLÓZATOK ..........................................................................................................4 1.2 AZ ATM HÁLÓZAT .......................................................................................................................5 2. A HÁLÓZATI RÉTEGEK................................................................................................................7 2.1 AZ ATM RÉTEG...........................................................................................................................8 2.2 AAL RÉTEG .................................................................................................................................8 2.2.1 AAL0 ..................................................................................................................................9 2.2.2 AAL1 ..................................................................................................................................9 2.2.3 AAL2 ................................................................................................................................10 2.2.4 AAL3/4.............................................................................................................................10 2.2.5 AAL5 ................................................................................................................................10 2.3 A LAN EMULÁCIÓ .....................................................................................................................12 2.4 AZ INTERNET PROTOKOLL .........................................................................................................14 2.5 A TCP ÉS UDP PROTOKOLL.....................................................................................................15 2.6 A REMOTE PROCEDURE CALL - TÁVOLI ELJÁRÁSHÍVÁS ..............................................................16 2.7 A NETWORK FILE SYSTEM ........................................................................................................16 3. FORGALOM MÉRÕ ESZKÖZÖK ...............................................................................................19 3.1 LADDIS....................................................................................................................................19 4. A MÉRÉSI KÖRNYEZET ELKÉSZÍTÉSE..................................................................................21 4.1 A STATISZTIKAI PROGRAMOK ÁTÍRÁSA .......................................................................................21 4.2 A PROGRAMOK MÛKÖDÉSÉNEK BEMUTATÁSA ............................................................................22 4.3 A TESZTELÕ PROGRAM ..............................................................................................................23 4.4 A TESZTELÕ FILE SZERKEZET ....................................................................................................24 5. FORGALOM MÉRÉSEK NFS KÖRNYEZETBEN.....................................................................26 5.1 KAPCSOLT ETHERNET HÁLÓZATI MÉRÉS ....................................................................................28 5.2 MEGOSZTOTT ETHERNET HÁLÓZATI MÉRÉS ...............................................................................29 5.3 ATM HÁLÓZATI MÉRÉS ..............................................................................................................30 5.4 A HÁROM MÉRÉS ÉRTÉKELÉSE...................................................................................................31 5.5 A TÖBB GÉPES ETHERNET MÉRÉS .............................................................................................36 5.6 A TÖBB GÉPES ATM MÉRÉS......................................................................................................38 5.7 A TÖBBGÉPES MÉRÉSEK ÉRTÉKELÉSE .......................................................................................40 5.8 ÖSSZEGZÉS ...............................................................................................................................45 6. A TANULMÁNYOZOTT IRODALMAK JEGYZÉKE..................................................................46

Elméleti alapok

0. Összefoglalás Témánk a lokális hálózatokban domináns hálózati file szolgáltatás (NFS Network File System) teljesítõképességének vizsgálata különbözõ hálózati konfigurációk esetén, ahol az ATM (Asyncronous Transfer Mode) eszközökön LAN emuláció fut. Az NFS egy olyan szolgáltatás, amely lehetõvé teszi, hogy különbözõ architektúrákon mûködõ eltérõ operációs rendszerek (Novell Netware, Microsoft Windows) hálózaton keresztül megosszák file rendszerüket. A LAN hálózatok manapság a világon nagyon elterjedtek. Sok alkalmazás épül rájuk az élet különbözõ területein. Ez a nagy elterjedtség olcsóságuknak és viszonylag egyszerû felépítettségüknek köszönhetõ. A többszörös hozzáférésû csatornát feltételezõ protokollok miatt a késleltetési idõk a LAN-oknál nagyok, s az átviteli távolságuk igen korlátozott. Az ATM hálózat elemei nagy sebességgel, minimális késleltetési idõvel mûködnek. Az ATM architektúra lehetõvé teszi, hogy nagy távolságra és nagy sávszélességen lehessen adatokat továbbítani. Az ATM alapú LAN hálózatok igen fontosak, mert a LAN hálózatokra költött hatalmas beruházásokat a felhasználók nem szeretik egy új technológia miatt megtérülésük elõtt lecserélni. ATM hálózaton megvalósított LAN emulációval nagy távolságú összeköttetések hozhatók létre két távoli LAN között, melyeken a hálózati operációs rendszerek minden változtatás nélkül használhatók maradnak. Mivel a LAN hálózatok többsége NFS protokollt használ, ezért igen fontosak az NFS forgalmi paraméterei, mivel így lehet eldönteni, hogy az ATM alapú hálózat hogyan befolyásolja a LAN teljesítõképességét. Vizsgálatunk célja különféle hálózati konfigurációk az NFS forgalomra gyakorolt hatásának elemzése. A konfigurációk között szerepel Ethernet és kapcsolt Ethernet hálózat; ATM LAN emulációval összekötött Ethernet hálózatok; ATM hálózat, melyen LAN emuláció biztosítja a LAN felületet.

3

4


1. Elméleti alapok A következõ fejezetben szeretnénk részletesen bemutatni a manapság leginkább használatos helyi hálózat (Local Area Network - LAN) fajtát az Ethernet-et. Ezután az Ethernet sebesség és távolságáthidaló képességét jóval túlszárnyaló ATM hálózatot fogjuk ismertetni, mivel a témánk is ehhez a két hálózattípushoz kapcsolódik. 1.1 Az Ethernet hálózatok

A Ethernet hálózatok manapság a világon nagyon elterjedtek. Sok alkalmazás épül rájuk az élet különbözõ területein. Ez a nagy elterjedtség olcsóságuknak és viszonylag egyszerû felépítettségüknek köszönhetõ. Elég arra gondolnunk, hogy egy koaxiális kábellel és egy olcsó hálózati kártya segítségével máris képessé tettük gépünket egy Ethernet hálózatra való csatlakozáshoz. Ethernet (IEEE 802.3) egy CSMA/CD (Carrier Sense Multiple Access-Collosion Detection) LAN hálózat. Ez a következõket jelenti: mielõtt egy állomás adni akar, belehallgat a csatornába. Ha a kábel üres, akkor azonnal adni kezd, ha foglalt akkor addig vár amíg szabaddá nem válik. Ha idõben egyszerre két állomás kezd el adni (hiszen mindketten üresnek érzékelték a kábelt), akkor ütközés következik be. Mindkét ütközést szenvedett állomásnak abba kell hagynia az adást és véletlen idõ kivárása után újra ismételni az egész eljárást. Az ütközés az elküldés alatt álló keret utolsó bitjéig elõfordulhat, ebben az esetben a teljes keretet feleslegesen adta az állomás és kezdheti elölrõl a keret újra adását. Normál esetben a teljes hálózatra eljut minden kliens forgalma, még akkor is ha az nem is érint mindenkit. A switched (kapcsolt) Ethernet hálózat esetén ki lehet alakítani hálózati csoportokat, melyeknek forgalmát a switch-nek (kapcsolónak) nevezett eszköz leválasztja egymásról, így minden csoportnak (akár egy gépnek vagy szervernek) saját, más néven dedikált 10Mbit/s sávszélesség áll rendelkezésére. A csoportok között csak akkor lesz forgalom, ha egy számítógép egy másik csoport tagját szólítja meg. Ez a forgalom általában sokkal kisebb, mintha a teljes hálózat forgalma terhelné a közös sávszélességet.

Elméleti alapok

5

1.2 Az ATM hálózat

Az ATM (Asyncronous Transfer Mode - aszinkron átviteli módú) hálózat alapszolgáltatása ATM cellák szállítása és kapcsolása (úgymint multiplexálás, átvitel és kapcsolás). Ezt az ATM hordozószolgálatot nevezik cell relay-nek, azaz cella továbbításnak. A hálózatnak nem szükséges bármit is tudnia a két végpont között az ATM kapcsolaton futó applikációról. Az ATM-ben az információt csomagokra osztva fix méretû, cellának nevezett idõrésekben viszik át. Ezek a cellák 48 byte hosszú információmezõt és 5 byte fejrészt tartalmaznak, ahol az információs mezõ teljes egészében a felhasználó rendelkezésére áll, míg a fejrészt az ATM réteg használja, fõként a cellák azonosítására. Az egyes cellák fejlécében levõ címkék azonosítják az adott linken a kapcsolatot. Ebbõl a szempontból az ATM

hasonlít

a

hagyományos

csomagátviteli

módokhoz.

Mint

a

csomagkapcsolási technikák, az ATM képes az aktuális igényekhez szabott bitsebesség biztosítására, beleértve az idõben változó igényekhez való igazodást is. Az asynchronous - aszinkron szó egy új átviteli módra utal, melyben az egyes cellák egy-egy kapcsolathoz vannak rendelve, de a kapcsolatoknak nincs meghatározott idõrésük. A cellák tehát folyamatosan mennek és az adott ú.n. csatorna igénye szerint hordoznak üzenetet, vagy üresek. Ezen utóbbiakat nevezzük idle celláknak. Az STM (Synchronous Transfer Mode - szinkron átviteli mód) átvitel esetén az adott csatornához tartozó adategységek a kapcsolathoz rendelt megadott idõrésben kerülnek adásra az átviteli keretben. Ez azt jelenti, hogy az adategységeknek nem kell információt tartalmazniuk a kapcsolatról. Így tehát az STM esetében az adott kapcsolathoz tartozó adategység csak meghatározott idõközönként kerül átvitelre (minden átviteli keretben egy egység továbbítódik), míg ATM esetében a cellák bármikor tartalmazzák a kapcsolatazonosítójukat. A két sémát mutatja a következõ ábra:

továbbíthatók, mert

6

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon Synchronous Transfer Mode Time-slot

Channel Channel 1 2

Channel

Channel Channel 1 2

n

Channel

n

Periodic frame

Asynchronous Transfer Mode Cell

Channel 1

Channel 5

User information

Channel 1

Channel Unused

Channel 7

Header (contains routing identifier)

Channel 5

Channel 1

Framing signal

A bitsebesség igény szerinti változtatása az STM hálózatban korlátozott, mivel elõre definiált csatornasebességeket használ és a hagyományos adat kereteknek merev struktúrájuk van. Ez általában nem engedi meg a terhelés egyéni kialakítását, vagy csak meglehetõsen szûkös keretek között. Ezzel szemben az ATM alapú hálózatban a cellák kapcsolása és multiplexálása független az aktuális applikációtól. Így ugyanaz az eszköz képes alacsony és magas bitsebességû kapcsolat kiszolgálására, legyen ez akár állandó, vagy változó sebességû átvitel[3]. Ezen kapcsolatok az ATM hálózatban összeköttetés alapúak, azaz az adó és vevõ között kiépül egy kapcsolat végtõl-végig. Ebbõl kétféle kapcsolat lehetséges, az állandó virtuális csatorna (Permanent Virtual Circuit PVC) és a kapcsolt virtuális csatorna (Switched Virtual Circuit - SVC). A PVCket manuálisan kell konfigurálni, az SVC-ket ezzel szemben az ATM kapcsoló szoftvere dinamikusan hozza létre. A kapcsolathoz felépülésekor az adott átviteli linket azonosító bejegyezés kerül az ATM cella fejlécébe. Az ATM kapcsoló ezek alapján határozza meg, hogy a beérkezett cellát mely kimenetére kell továbbítania. Az ATM hálózat azért tud gyorsan kapcsolni, mert csak ezt a bejegyzést kell figyelnie.

Hálózati rétegek

2. A Hálózati rétegek Az NFS vizsgálata elõtt ismerkedjünk meg a hálózati protokollok felépítésével és tulajdonságaival, különös tekintettel az ATM alapú LAN Emuláció kialakításáról. Ennek felépítése vázlatosan az alábbi ábrán látható.

Mint látható a fizikai közeg felett az ATM két rétege, az ATM réteg és az AAL5 (ATM Adaptation Layer) réteg látható. Erre épül a LAN Emuláció, mely felett mûködik - az OSI szabvány szerint pontosan behatárolhatóan - hálózati réteg szinten az Internet Protocol (IP), szállítási réteg szinten a User Datagram Protocol (UDP) és Transmission Control Protocol (TCP). A távoli eljárás hívás protokoll (Remote Procedure Call - RPC) nem illeszkedik az OSI modell rétegeihez, hanem viszonyréteg és az alkalmazási réteg szinten helyezkedik el. A Network File System (NFS) az alkalmazási réteg szintjén foglal helyet. Ezekrõl a protokollokról a késõbbiekben több szó esik majd, most csak a könnyebb áttekinthetõség kedvéért soroltuk fel õket.

7

8

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 2.1 Az ATM réteg

Az ATM réteg feladata az adó oldalon az, hogy a felette elhelyezkedõ AAL rétegtõl kapott információs mezõt fejrésszel lássa el. Így jön létre az ATM 53 byte hosszú cellája. Ezen cellákat, melyek

különbözõ kapcsolatokhoz

tartoznak egy cella folyammá multiplexálja és továbbítja azokat a fizikai réteg felé. Vevõ oldalon a fizikai rétegtõl érkezõ cella folyamot szét választja kapcsolatonkénti cellákra és az ATM cella fejrészt eltávolítja. A visszaállított információt továbbítja az AAL réteg felé. 2.2 AAL réteg

Ez a réteg az ATM és a föntebbi rétegek között teremti meg a kapcsolatot. A felsõbb rétegek PDU-jának (Physical Data Unit), fizikai adat egységének információs mezõjét hozzárendeli az ATM cellákhoz. Az AAL funkciók támogatásának érdekében az adó oldali AAL processz kommunikál a vevõ oldali AAL processzel. Az AAL réteg funkcióit két alréteg között osztották fel. Ez a két alréteg a SAR (Segmentation And Reassembly) és a CS (Convergence Sublayer). Az SAR feladata, hogy az adó oldalon a fentebbi rétegektõl érkezõ adatokat darabolja bele az ATM cellák információs mezejébe, vevõ oldalon pedig állítsa össze a fentebbi réteg eredeti adatait. A CS szolgáltatás függõ és feladata, hogy biztosítsa a fentebbi rétegek számára az AAL szolgáltatásokat az AAL-SAP-n (AAL Service Access Point), azaz a szolgáltatás hozzáférési ponton. Az SAR és a CS között nincs definiált SAP. Különbözõ szolgáltatás hozzáférési ponttal rendelkezõ felsõ rétegekkel tud együttmûködni az AAL réteg, ha különféle SAR és CS kombinációkat használnak. Van olyan eset ahol gyakorlatilag nincs is CS és SAR alréteg. Annak érdekében, hogy ne legyen túl sok AAL protokoll, az ITUT (International Telecommunication Union - Telecommunication Standardization Sector) szolgáltatási osztályokat definiált, melyek AAL réteg specifikusak. Három paraméter figyelembevételével osztották fel az osztályokat, ezek a bit sebesség, a kapcsolati mód és az idõzítési kapcsolat[3]. A következõ ábra ezt a felosztást tartalmazza:

Hálózati rétegek

Osztály, Típus Idõzítés Bit sebesség

9

A

C

Szükséges (valós idejû átv.)

Állandó

Kapcsolati típus AAL típus

B

Nem szükséges Változó

Kapcsolat orientált AAL1

D

AAL2

AAL3/4 AAL5

Kapcsolat mentes

AAL3/4 AAL5

2.2.1 AAL0

Ez az osztály nem tartalmaz sem SAR, sem CS alréteget. Úgy lett definiálva, hogy az ATM réteg felõl érkezõ kereteket mindenféle változtatás nélkül továbbítja a felsõbb rétegek felé és viszont. Ezért nincs a táblázatban felsorolva. 2.2.2 AAL1

Ezt a réteg típust a konstans bit sebességû szolgáltatások használják (video, hang átvitel, bérelt vonalas szolgáltatás, áramkör emuláció). Idõzítései információk is továbbításra kerülnek az adó és vevõ között. Szükség esetén adatstruktúrákra utaló információkat is át lehet küldeni. Az elveszett és hibás adatokat jelzi a felette lévõ rétegek felé, ha az AAL rétegen belül nem tudja megoldani a problémát. Az AAL1-es réteg az 53 byte-os ATM cella 48 byte hosszú információs mezejébõl 1 byte-ot használ protokoll vezérlõ információkra (PCI Protocol Control Information). Ez az 1 byte több részre tagolódik, így lehetõség van az elveszett és hibásan beékelõdött cellák detektálására, idõbélyegek továbbítására és ezen információk védelmére 3 bit CRC-vel és 1 bit páros paritással.

10

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 2.2.3 AAL2

Ezt a réteget változó bit sebességû szolgáltatások használják. Idõzítései információk, mint az AAL1-nél is továbbításra kerülnek az adó és vevõ között. Ezt a típust nem dolgozták ki teljesen, de mobil kommunikációs kutatások folynak az AAL2 típus kihasználására. 2.2.4 AAL3/4

Ebben az esetben egy igen érdekes réteggel állunk szembe, mert két AAL típus összeolvadásából jött létre. Mindkét típust változó bit sebességû és idõzítési információkat nem igénylõ szolgáltatások használták. A különbség a kapcsolat alapú és kapcsolatmentesség között volt, de idõvel mindkettõ támogatta a másikat. Ebben a típusban lehetõség van több magasabb szintû kapcsolat multiplexálására, úgy hogy az ATM rétegben azok csak egy kapcsolatnak tûnjenek. Ehhez szükség van különféle azonosító és hibavédõ információkra, amik 4 byte-ot lefoglalnak a hasznos információs területbõl. Így az AAL3/4 esetén csak 44 byte a tényleges hasznos információ, ami a felsõbb rétegek felé látszik.

2.2.5 AAL5

Ez a réteg az olyan adatátviteli rendszerek miatt alakult ki, melyeknél nem fontos, hogy az adat fix idõzítés szerint haladjon a hálózaton, hanem sokkal fontosabb az adat biztonságos átvitele még újraadás árán is. Az ATM réteg nem

Hálózati rétegek biztosít ilyen ellenõrzési lehetõséget, ezért ehhez AAL réteg szinten kell beépíteni ezeket funkciókat. Az AAL5 ezt úgy oldja meg, hogy az ATM cella 48 byte-os információs mezejét teljes mértékben a felsõbb rétegektõl kapott adatok átvitelére használja. A felsõbb rétegek hosszabb adat blokkjait úgy helyezi el az ATM cellákban, hogy elõször kiegészíti azt ellenõrzõ információkkal, majd 48 byte-os blokkokra vágja szét. A feldarabolást viszont jelezni kell a vevõ oldali összeállításhoz. Ezt úgy teszi, hogy az ATM cella fejlécének PT (Payload Type) mezejét használja az adatblokk kezdetének, folytatásának (PT=1) és végének (PT=0) jelölésére. Ennek az egyszerûsítésnek az az ára, hogy az ALL rétegnek elveszik az ATM rétegtõl való függetlensége, mivel az ATM cella fejlécet az ATM réteg generálja. Ezt a típust TCP/IP, LAN emuláció, a signalling (az ATM eszközök jelzésrendszere), a Frame Relay protokollok használják.

(Az AAL rétegeket bemutató ábrák az ATM Forum: Intermediate ATM Rel. 1.0 nevû oktatóanyagából származnak). [9] Itt eljutottunk a rétegek között a számunkra igen fontos LAN Emulációs réteghez, ami a magasabb rétegeknek lehetõvé teszi, hogy az ATM hálózatot úgy tudják használni, mint egy Ethernet hálózatot.

11

12

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 2.3 A LAN Emuláció

Az Ethernet hálózatokon a többszörös hozzáférésû csatornán alkalmazott protokollok miatt, jelentõs késleltetési idõk lépnek fel, emiatt az átviteli távolsága igen korlátozott. Néhány száz méternyi távolságon túli átvitel már jelismétlést kíván. Az ismétlõk száma viszont korlátozott, mert a késleltetési idõk jelentõsebb növekedése már felborítja a rendszer mûködését. Az ATM hálózaton nagy távolságú összeköttetések hozhatók létre fix késleltetési feltételek betartásával. Az ATM hálózati eszközökön futó LAN emuláció lehetõvé teszi, hogy ATM hálózattal összekapcsolt végpontok MAC (Media Access Control) réteg szinten kapcsolatot teremthessenek. Ez pedig azt eredményezi, hogy LAN protokollokat használó programok (például a Novell Netware, Microsoft Windows) és protokollok (DECnet, TCP/IP) minden változtatás nélkül használhatók az ATM hálózaton.

Nagy távolságú ATM és LAN Emuláció által összekötött LAN hálózatok

A LAN emulációs szolgáltató futhat akár egy ATM végponton, akár egy ATM kapcsolón. A szolgáltató három fõ részbõl áll, ezek a LAN emulációs szerver (LAN Emulation Server - LES), a LAN emuláció konfiguráló szerver (LAN Emulation Configuration Server - LECS), és az üzenetszóró szerver (Broadcast und Unknown Server - BUS). A LAN emulációban résztvevõ végpontokat angolul LEC-nek nevezzük. (LAN Emulation Client)[1].

Hálózati rétegek Alább látható a LAN emuláció résztvevõinek összekapcsolódása:

A LECS felelõs a kliensek indítási konfigurálásáért, információkat nyújt a létezõ virtuális LAN-okról, és hozzárendeli a klienseket a megfelelõ szerverekhez. A LES ennek alapján engedélyezi a klienseknek a kapcsolat felépítést. Az ATM hálózatnak nincs beépített mechanizmusa az Ethernet hálózatokon használatos üzenetszórásra (közös hozzáférésû átviteli közeget használó Ethernet-en ezt könnyû megvalósítani, hisz mindenkihez eljut minden üzenet). Az Ethernet alapú hálózatokban ez a szolgáltatás fontos. Ezért a LAN emulációban az üzenetszórást meg kell valósítani, amit a BUS hivatott kiszolgálni, mégpedig úgy, hogy a hozzá beérkezett csomagot minden címzetthez point-to-multipoint kapcsolaton keresztül elküldi. Ezt oly módon teszi, hogy LES és BUS szerverek felépítenek egy-egy pont-pont és pont-multipont kapcsolatot minden klienssel. Itt érkeztünk el ahhoz a ponthoz, amikor a LAN emulációhoz használt kommunikációt kell górcsõ alá vennünk. Az ATM hálózatban a címek 20 byte hosszúak, míg a Ethernet-ben 6 byte-os MAC címek vannak. A LES feladata

13

14

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon az ATM címek MAC címekhez való hozzárendelése és megtanulása. Ha egy végpont kommunikálni akar egy másikkal, akkor tudnia kell a másik végpont ATM címét. Ha ez megvan, akkor közvetlenül felépít egy SVC-t a partner felé, és ezen folyik a kommunikáció. Ha a LEC nem tudja megszerezni a másik LEC címét, akkor kérésére a BUS segít kideríteni a címfeloldó protokoll (LEARP LAN Emulation Address Resolution Protocol) segítségével[1],[2]. A következõ ábra egy tipikus ATM és Ethernet együttmûködést mutat be protokoll szinten, ahol a LAN emuláció az egyik fele ATM végponton fut, míg a másik fele egy LAN switch-en.

ATM és Ethernet hálózat LAN Emuláció segítségével kapcsolódik össze

2.4 Az Internet Protokoll

A LAN emuláció felett manapság a TCP/IP protokoll helyezkedik el. Ennek hálózati szintû protokollja az Internet Protocol (IP), ez végzi a csomagoknak a forráshosttól célhostig irányítását. Minden egyes hostnak (pontosabban minden egyes Ethernet csatlakozónak) van egy ún. Internet címe (IP címe), ami lényegében egy 4 byte-os. Ez a cím teljesen független az Ethernet címektõl, és úgy lett kialakítva, hogy az útvonal kijelölõ algoritmust a lehetõ

Hálózati rétegek legegyszerûbben lehessen megoldani. A két cím közti különbség az ARP protokoll oldja fel. Az ARP protokoll a következõ: kíváncsiak vagyunk egy adott IP címû gép Ethernet címére. Ehhez úgy kell egy ARP csomagot kiküldeni, hogy azt miden egyes gép megkapja (broadcast segítségével). Egy host, amely egy ARP csomagot beolvas a hálózatról, ellenõrzi, hogy a saját IP címe van-e benne. Ez azt jelenti, hogy az õ címére kíváncsi az ARP csomag küldõje. Ekkor kiküld egy válasz-csomagot a kérdezõnek, amely tartalmazza a saját Ethernet címét. 2.5 A TCP és UDP protokoll

A TCP és UDP szállítási réteg (OSI) biztosítja, hogy a csomagok sorrendhelyesen és hiba nélkül kerüljenek átvitelre. Ennek megvalósítása az adatvétel visszaigazolásával és az elveszett csomagok újraadással történik. Ezt a fajta kommunikációt ”end-to-end”, azaz végponttól végpontig néven ismerik. A szállítási réteg két fajta protokollt tartalmaz, a Transmission Control Protocol-t (TCP) és a User Datagram Protocol-t (UDP). A TCP protokoll lehetõvé teszi az applikációknak, hogy fizikai csatornával összekötve kommunikáljanak egymással. A TCP egymásután folyamatosan várja az adatokat, nem pedig diszkrét csomagonként. A TCP fejlécet (header-t), csatol az átviendõ adatokhoz és ennek segítségével a küldõ gépen futó processz kapcsolatot tud teremteni a vevõ gépen futó párjával. A TCP tehát azúton éri el a csomag biztonságos eljutását a célállomáshoz, hogy kiépít egy végponttólvégpontig menõ kapcsolatot a küldõ és fogadó állomás között. Ezért a TCP egy megbízható, összeköttetés-orientált protokoll. Az UDP, a másik szállítási rétegbeli protokoll úgynevezett „datagram” típusú szállítást valósít meg. Így az UDP nem biztosít semmiféle ellenõrzési lehetõséget arra nézve, hogy az adó és vevõ között létrejött-e a kapcsolat, hanem egyszerûen elküldi a csomagokat a rendeltetési helyükre. Mivel az UDP kiküszöböli a kapcsolat felépítését és ellenõrzését, ezért a kis mennyiségû adatot küldõ applikációk elõnyben részesítik a TCP-vel szemben. [6]

15

16

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 2.6 A Remote Procedure Call - távoli eljáráshívás

A távoli eljáráshívást (RPC) úgy fejlesztették ki, hogy az gép, operációs rendszer, hálózati struktúra és szállítási réteg független legyen. Lényege, hogy a rendszer egy vagy több szerverbõl és sok kliensbõl áll. A szerver szolgáltatásait (mint például diszk területén tárolja a klieansek file-jait), míg a kliensek RPC kéréseken keresztül elérik azokat. Egy RPC kérésre a szerver egy nyugtával válaszol, ami már tartalmazza a kért információkat is. Az RPC-t használja a felette elhelyezkedõ NFS protokoll, mely témánk egyik fontos eleme. 2.7 A Network File System

Az NFS egy olyan szolgáltatás, amely lehetõvé teszi, hogy különbözõ architektúrákon mûködõ eltérõ operációs rendszerek hálózaton keresztül megosszák file rendszerüket. Az NFS egy általános file rendszer modellt használ, nem pedig egy architektúrához kötöttet. A legtöbb hálózati operációs rendszer ezt a modellt alkalmazza a saját file rendszerére. Az NFS a távoli eljáráshívási protokollra épül, amelyet az elõzõ fejezetben mutattunk be. Az RPC-re támaszkodva az NFS a távoli gépeken levõ állományokat is eléri, mégpedig úgy, mintha helyben dolgoznánk rajtuk. Ez azt jelenti, hogy a távoli file-okon végzett mûveletek (pl. az írás és olvasás) látszólag egy helyi file-on történek. Ebbõl következõen több elõnye is van az NFS alapú rendszereknek: • Lehetõvé teszi, hogy több számítógép ugyanazon file-t használja, így a hálózaton azonos adatot tud mindenki elérni. • A számítógépek között megosztott file rendszer révén, csökkenti a tárterület igényeket, mert így az alkalmazások nem igényelnek helyi diszk területet. • Adat konzisztenciát biztosít, mivel minden felhasználó ugyanazokat a fileokat használja. • A felhasználó nem lát különbséget a helyi és távoli könyvtárak ill. file-ok között [5]

Hálózati rétegek

17

Az NFS rendszerben a felhasználó szemszögébõl lényegtelen a file rendszer fizikai helye. Lehetõsége nyílik arra, hogy a számára szükséges valamennyi file-t elérje, tekintet nélkül azok helyére. A kliens úgy éri el a szerver file rendszerét, hogy saját file rendszerébe kötetként beilleszti azt. Nem csinál belõle másolatot, hanem a mount processz RPC hívásokat használ a szerver file rendszeréhez való hozzáféréshez. Minden egyes NFS kérési típust nem tudunk ebben a dolgozatban felsorolni, ezért csak a mérési eredmények értelmezéséhez szükségesekrõl adunk egy táblázatot: NFS kérés NULL GETATTR SETATTR LOOKUP ACCESS READLINK READ WRITE CREATE MKDIR REMOVE RMDIR RENAME LINK READDIR READIRPLUS COMMIT

Funkciója Nem csináj semmit File attributumokat kér le File attributumokat állít be File neveket kérdez le Hozzáférési jogokat ellenõrzi Linket olvas File-ból olvas File-ba ír File-t létre hoz Könyvtárat hoz létre File-t töröl Könyvtárat töröl File-t vagy könyvtárat nevez át Linket készít az adott objektumra (file, könyvtár) Könyvtár olvasása Könyvtár kibõvített olvasása A szerver CACHE-ében lévõ adatokat diszkre írja.

Az NFS rendszernek kétféle verziója használatos az NFS Version 2 és az NFS Version 3. Azért említettük meg mindkét szállítási réteg protokollt, mert az NFS Version 2 szállítási réteg szinten még UDP protokollt követelt. Az ATM LAN emuláció számára ez a tulajdonsága elõnytelen, mert diszkrét csomagok haladnak a hálózaton és így a felépített ATM kapcsolat rossz esetben minden csomag után felbomlik. Az NFS újabb verziója (NFS Version 3) már képes TCP protokoll használatára is, ahol folyamatos adatforgalom zajlik két végpont között. Így a felépített ATM kapcsolatot nem kell megszakítani, e tulajdonsága miatt használják inkább a TCP protokollt szállítási réteg szinten, ha ATM hálózaton LAN emuláció mûködik.

18

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon Mielõtt a konkrét mérési eljárásokra és mérésekre térnénk szeretnénk bemutatni egy részletesebb protokoll felépítést. Egyetlen részét nem említettük meg, ez a NDIS-t, ami több protokoll (IP, IPX) közös hálózaton futását engedi meg. A többi réteget ismertettük a megelõzõ fejezetekben és ezzel az ábrával foglaljuk össze az eddigi elméleti információkat:

Existing Applications

Existing Applications

NFS Version 3

NFS Version 3

RPC

RPC

TCP

UDP

TCP

UDP

IP, IPX, etc. Layer 3 prot.

IP, IPX, etc. Layer 3 prot.

NDIS, ODI driver Interface

NDIS, ODI driver Interface

Bridging LAN Emulation

LAN Emulation RFC 1483 Encapsulation g.2931 g.2110 AAL5 (CS & SAR) ATM Layer Physical Layer

ATM LAN device

RFC 1483 Encaps. g.2931 g.2110

g.2931 g.2110

AAL5 (CS & SAR) ATM Layer

ATM Layer

Physical Physical Layer Layer

ATM switch

g.2931 g.2110

Media Acces Control Layer

Media Acces Control Layer

Physical Layer

Physical Layer

AAL5 CS & SAR

ATM Layer Physical Layer

ATM LAN Emulator

Legacy LAN (CSMA/ CD, TRN)

Legacy LAN device

Forgalom mérõ eszközök

19

3. Forgalom mérõ eszközök 3.1 LADDIS

A SPEC-SFS (Standard Performance Evaluation Corporation - System File Server) ipari szabvány (más néven LADDIS), amit az NFS szerverek teljesítõképességének mérésére használnak. A LADDIS kétféle jellemzõt mér az átvitelt (NFS mûveletek másodpercenkénti számát) és az átlagos késleltetést (NFS mûveletenkénti késleltetés). Ezt oly módon teszi, hogy a tesztelõ program egy terhelés generátoron (hálózati kliens) fut, de nem használja a kliens saját NFS implementációját. Ellenkezõleg, a LADDIS szintetizálja az NFS kliens kéréseket, megkönnyítve ezzel a idõbélyegek és a teszt futásának pontos állíthatóságát és a teszt megismételhetõséget. A szerver ebben az esetben egyszerûen válaszol minden beérkezõ kérésre, úgy mintha azok egy hálózati környezet több NFS kliensének összesített terhelésébõl adódnának. Mindenegyes LADDIS forgalomgenerátor nagyszámú valódi NFS kliens összesített terhelését szeretné elõállítani. Több terhelés generátorra van szükséges ahhoz, hogy az SPEC Run and Reportnak (futtatás és riport) megfeleljen. A terhelés generátor kliensek a teszt inicializálása

alatt

elkészített

file-okon

végeznek

véletlenszerûen

NFS

mûveleteket, a következõ táblázatnak megfelelõ eloszlásban.

lookup

read

write

getattr

readlink

readdir

34%

22%

15%

13%

8%

3%

create

remove

fsstat

rename

setattr

link

2%

2%

1%

1%

1%

0%

mkdir

null

rmdir

root

symlink

wrcache

0%

0%

0%

0%

0%

0%

Az olvasási kérések gyakran a cache-bõl kerülnek kiszolgálásra, mivel a keresett adat a memóriában van az elõre beolvasási stratégiának köszönhetõen. Ez a stratégia beolvassa a memóriába a kérésben megjelölt és az azt követõ esetleg


20

több file-t a arra alapozva, hogyha egy alkalmazás legtöbbször szekvenciálisan olvas, ír [7]. A legtöbb alkalmazás a file fejlécétõl kezdve olvassa a file nagy részét, így jól érvényesül az elõre olvasási (read-ahead) stratégia. Sajnos a

LADDIS

másképp viselkedik, mint egy NFS kliens a valós életben, tipikusan csak keveset olvasva a file-okból és nem a fejléccel kezdve. A LADDIS futásakor, az elõre olvasás egy hibás feltevés, így az elõny helyett hátrány lesz. A LADDIS teszt a tipikus hálózati hozzáférési mintákhoz képest viszonylag kevésszer használ újra file-okat. A LADDIS-tól eltérõen, ha egy adott idõpillanatban egy felhasználó olvasott egy file-t, akkor feltehetõleg ugyanez a felhasználó újra igényelni fogja azt vagy egy másik felhasználó is használni fogja a file megosztás (file sharing) révén. (Futtatható applikációk bináris file-jai jó példák a nagyszámú ismételt hozzáférésre). Bár LADDIS ipari szabványa az NFS szerverek teljesítõképességének vizsgálatára, mégse képez egy átfogó teszt gyûjteményt. Különösen a file-ok elérésénél jelentkezik ez a probléma, mert a LADDIS viszonylag kis file-okat (135 kbyte) ráadásul véletlenszerûen ér el, ez nem tartalmaz szekvenciális olvasást és nagy file-ok írását.Megfigyelték, hogy a felhasználók mind véletlenszerûen, mind szekvenciálisan érik el adataikat a file szervereken. A LADDIS felsorolt hibái miatt és a $1.200-os ára miatt úgy döntöttünk, hogy inkább tesztelõkörnyezetünket saját magunk által írt programokkal alakítjuk ki.

A mérési környezet elkészítése

4. A mérési környezet elkészítése A mérés során rendelkezésünkre állt egy Tcl/Tk-ban íródott program, amely különbözõ hálózati protokollok forgalmi statisztikáit volt képes kirajzolni. Az ehhez szükséges adatokat a UNIX beépített hálózati forgalmat megfigyelõ parancsa, a snoop szolgáltatta. A snoop képes a hálózati forgalom csomagjait megfigyelni és megszûrni. Az általa nyújtott adatok formátuma nem felelt meg a statisztika rajzoló program számára, így egy már szintén meglevõ Tcl script átalakítja azokat. A snoop elkapja a hálózaton érkezett csomagokat, majd file-ba menti, vagy UNIX pipe-on keresztül rögtön az átalakító scriptnek továbbítja az adatokat. Az adatfolyamot az átalakító program soronként feldolgozza, azaz összegyûjti és szortírozza a csomagokat a hálózati protokoll és a méret szerint. Ezt a protokoll szerint szétválogatott, és érkezési idõ szerint összegzett adathalmazt file-ba menti. Ezt a file-t a statisztika rajzoló forrásfile-ként betölti, majd a felhasználó kívánsága szerint protokollonként csoportosítva a gépek közötti forgalmat lehetõvé teszi az idõ-összforgalom (összcsomagméret) statisztikák kirajzolását. 4.1 A statisztikai programok átírása

Elõször átírtuk a statisztikai programot, hogy az NFS protokollokat ismerje fel. Kijavítottuk a programban levõ hibákat, és alkalmassá tettük a programot arra, hogy az NFS protokollok felismerésén túl megkülönböztesse a protokollokon belül a hívásokat és a válaszokat (Call, Reply funkciók). Miután a program elkészült, át kellett írni az átalakító programot is, hogy a hívás-válasz szétválasztó funkcióknak megfelelõ többletinformációt képes legyen kezelni. Miután elkezdtük a programok tesztelését, kiderült, hogy nem minden NFS forgalmat ismernek fel. Az okot abban a körülményben találtuk meg, hogy a snoop hálózatfigyelõ program nem képes kiszûrni az összes NFS csomagot. Gondos utánajárás után felfedeztük, hogy az NFS version 3 már TCP szállítási protokollt is használ, nem csak UDP-t, és a TCP-n érkezõ csomagokat a snoop nem ismeri fel NFS csomagnak. A TCP csomagként érkezõ NFS adategységek

21


22

felismerésére az egyetlen lehetõséget az adta, hogy ezeknek a TCP-n menõ NFS csomagoknak a forrás-, vagy célportjuk egyike mindig a 2049-es port volt. Így egy egyszerû awk scripttel ki tudtuk szûrni az ilyen portszámú TCP csomagokat. A nehézséget az jelentette, hogy az ily módon kiszûrt csomagokról hogyan döntsük el, hogy milyen NFS protokollhoz tartoznak, és hogy hívás, avagy válasz típusúak-e. Az elõzõ, ugyanazon gépek közötti NFS csomagokat figyelve meg tudtuk állapítani a protokoll szerinti hovatartozást, sõt a hívás-válasz kérdés is eldönthetõnek bizonyult. Ennek megfelelõen újra átírtuk az átalakító programot. A késõbbiekben végzett mérések során felmerült az igény, hogy a forgalmi paraméterekrõl bõvebb információval rendelkezzünk. Szükség volt az átvitt forgalom méretének és az NFS szolgáltatás kérések számának statisztikáira is. Ezért a statisztikarajzoló programot tovább bõvitettük. 4.2 A programok mûködésének bemutatása

A hálózati forgalom csomagjainak befogását tehát a snoop beépített UNIX utasítás végezi. Bár a snoop rendelkezik az NFS forgalom szûrésére alkalmas paraméterrel, de sajnos csak az NFS 2.0-ás verziójára alkalmas, mert a TCP-n érkezõ csomagokat nem ismeri fel. Az általunk készített szûrõprogram átveszi ezt a

feladatot, azonban meghatározott formátumú kimenetet igényel a

hálózatfigyelõ programtól. A snoop-ot ezért a -S -t a paraméterezéssel kell indítani. A -S paraméter az éppen elkapott Ethernet keret méretét helyezi el az összegzõ sorban, a -t paraméter pedig egy idõbélyeget helyez el ugyanitt. Az a paraméter az idõbélyeget formázza. Az így kapott adatfolyamot UNIX pipe-pal az általunk írt awk szûrõprogram bemenetére kell átirányítani. A szûrõ kiválogatja a folyamból azokat a sorokat, amelyeknek protokolloszlopában NFS felirat található, valamint az ugyanitt TCP feliratúak közül azokat, melyeknek source, vagy destination portja 2049-es. A szûrõ kimeneti formátuma sorrendben tartalmazza a csomag érkezési idejét, a server és a kliens gép nevét, a csomag méretét, a szolgáltatás jellegét (hívás, vagy válasz - C, R), végül az NFS szolgáltatás azonosítóját. A

A mérési környezet elkészítése TCP protokollú sorok a csomagméret után a szolgáltatás cél és a forrásportját tartalmazzák. A

60, illetve 54 byte-os csomagméretû TCP sorok nyugtákat

jelentenek. A TCP csomagok és nyugták az elõzõ, ugyanazon gépek közötti NFS szolgáltatáshoz tartoznak, így a szolgáltatás, csomagméret és idõ szerinti összegzésnél ennek megfelelõen vettük õket figyelembe. A szûrõprogram kimenetének összegzését az átalakító Tcl script végzi. Szétválogatja a csomagokat a szolgáltatások szerint, majd az egy percen belül érkezett, azonos szolgáltatású és azonos gépek közötti csomagok méreteit összegzi. Ezzel jelentõsen meggyorsul a statisztika rajzoló program számára az adatok betöltése, méghozzá idõveszteség nélkül, mert az egész feldolgozás a snoop futásideje alatt megtörténik. Az alábbiakban bemutatom az átalakítóprogram kimeneti formátumát:

4.3 A tesztelõ program

A tesztelésnél a célunk az volt, hogy a való élethez hasonló NFS forgalmat generáljunk az NFS kliens és a szerver között. A tesztprogram készítésénél úgy jártunk el, hogy a hívási statisztikák nagyjából megfeleljenek a LADDIS teljesítmény tesztelõ program által használt statisztikának, amit a LADDIS-ról szóló részben be is mutattunk. Ettõl abban tértünk el, hogy az olvasási és írási tulajdonságot helyeztük elõtérbe, mint a leginkább kritikus szolgáltatásokat. Tehát, mint az a késõbbi statisztikákból látszani fog, a READ3 és a WRITE3 NFS szolgáltatás-t teszteli a programunk. A tesztelõ program az NFS szerveren létrehozott file-rendszerben olvas szekvenciálisan és (ál) random módon, másol, szintén szekvenciálisan és

23

24

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon véletlenszerûen is, valamint egy scriptet indítva létre is hoz file-okat. Mindezen mûveletek közben néhány könyvtárbeolvasást is végez, valamint a másolt fileokat le is törli maga után. Egy periódus lefutása után a szerveren levõ filerendszer eredeti állapotba kerül. Az egyes mûveleteket a terhelésmegoszlás miatt idõnként késleltetve hajtja végre, azaz szüneteket is beépítettünk. A jobb vizsgálhatóság kedvéért ezt a mûveletsort a program négyszer megismétli egymás után. Eredményképpen egy többször futtatható és konzisztens tesztert kaptunk, amelynek

futásideje

méréseink

szerint

45-69

perc

között

ingadozik

hálózattípustól függõen. A LADDIS-tól eltérõen a program valós NFS kliens-t testesít meg, változó méretû file-okat használ a tesztelésre, valamint szekvenciális mûveleteket is végez. 4.4 A tesztelõ file szerkezet

A mérések során egy általunk generált file szerkezetet használtunk, mely az NFS szerveren lett létrehozva. Tesztelõ programunkkal az itt lévõ file-okat egy vagy több kliens géprõl értük el, az NFS szolgáltatásain keresztül. A könyvtár szerkezet 3 mélységû volt, ahol valamennyi könyvtárban min.: 20 és max.: 100 darab file volt. A file-ok mérete változó volt az 1 kbyte-ostól a több Mbyte-osig. A saját file statisztikáinkat figyelembe véve a nagyobb file-okból kevesebbet generáltunk, mint a kisebbekbõl. A file-ok mérete a következõ eloszlást mutatja: Méret

darabszám

1-10 kbyte

45%

10-100 kbyte

30%

100-500 kbyte

15%

500 kbyte -1 Mbyte

7%

1 Mbyte felett

3%

A mérési környezet elkészítése A többgépes tesztelésnél az írási mûveletekhez gépenként más-más ideiglenes könyvtárat használtunk, hogy az egymásra várakozást és az ütközést elkerüljük. Ebbõl adódott a tesztelési könyvtár szerkezete:

Az ismételhetõség érdekében a file szerkezetet egy külön erre a célra írt script-tel generáltattuk le. Ez a program véletlenszám generátor scriptet felhasználva a megadott eloszlás szerint véletlen méretû file-okat generál az adott könyvtárba. Ebbõl adódóan, bár a file-ok mérete és sorrendje eltérõ lesz, a valószínûség törvényei szerint az eloszlásuk és össztömegük hasonló, azaz a mérés esetleges ismétlésénél az eltérés kicsi lesz.

25


26

5.

Forgalom mérések NFS környezetben A munkához kapcsolódó méréseket az Ericsson Traffic Lab-ban üzemelõ

ATM hálózaton mûködõ emulált LAN hálózaton, valamint az ugyanitt található Ethernet hálózatokon végeztük. Az Ericsson Traffic Lab-ban kétféle Ethernet állt rendelkezésünkre, a shared (megosztott) és a switched (kapcsolt) Ethernet. A megosztott Ethernet a hagyományos IEEE 802.3 szabványos hálózat, ahol a kliensek egy közös 10 Mbit/s-os sávszélességû vonalon osztoznak. Az ATM hálózat 155 Mbit/s sebességgel mûködik. Elõször is szeretnénk bemutatni a Traffic Lab-ban üzemelõ ATM és Ethernet hálózatok felépítését.

Forgalom mérések NFS környezetben

A méréseket úgy állítottuk össze, hogy kiderüljön számunkra a különféle hálózati konfigurációk hatása az NFS forgalomra. Ezt úgy lehetett elérni, hogy a Traffic Lab-ban található hálózaton különbözõ gépeken futtattuk a tesztelõ és a statisztikát gyûjtõ programot.

27

28

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 5.1 Kapcsolt Ethernet hálózati mérés

A tesztprogramot elõször a socrates nevû gép Ethernet hálózati portját felhasználva futtattuk, úgy hogy a spinoza-n (NFS szerver) voltak a tesztelésre használt file-ok és azokat a spinoza Ethernet portján keresztül értük el. Így az általunk generált forgalom az Ethernet hálózaton keresztül zajlott. Ennek a mérésnek (és a következõnek is) az volt a célja, hogy összehasonlítási alapunk legyen arról, hogy az Ethernet illetve ATM hálózatra kapcsolódó számítógép számára mennyire különbözõ a rendelkezésre álló sávszélesség. A socrates egy Ethernet switch portjára kapcsolódik, azaz switched Ethernet hálózat része, így a 10 Mbit/s-os sávszélességen nem osztozik másokkal. Az program 52 percig futott. Az átvitt forgalom rajzát itt mutatom be, a többi adat az értékelésnél található.

Forgalom mérések NFS környezetben 5.2 Megosztott Ethernet hálózati mérés

A tesztprogramot most egy hobbes nevû gép Ethernet hálózati portját felhasználva futtattuk, úgy hogy a spinoza-n (NFS szerver) voltak a tesztelésre használt file-ok és azokat a spinoza Ethernet portján keresztül értük el. Így az általunk generált forgalom az Ethernet hálózaton keresztül zajlott. A hobbes a 10 Mbit/s-os sávszélességen másokkal osztozik. A program ebben az esetben 48 percig futott.

Az átvitt forgalom rajzát itt mutatom be, a többi adat az értékelésnél található. A forgalom rajzát nézve is szembeötlõ az eltérés a kapcsolt Ethernethez képest.

29

30

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 5.3 ATM hálózati mérés

A tesztprogramot futattuk a hobbes nevû gépen, de most a gép ATM hálózati portját használtuk, úgy hogy továbbra is a spinoza-n (NFS szerver) voltak a tesztelésre használt file-ok és azokat most a spinoza ATM portján keresztül értük el. Így az általunk generált forgalom az ATM hálózaton keresztül zajlott. A program 45 percig futott.

Azaz eddig ez volt a legjobb idõ, de itt kell megjegyeznünk, hogy ez egyáltalán nem általános eredmény, mert a legtöbb ATM mérésünk 45-48 perc közé esett. Persze Ethernet mérésbõl is több volt, s ott is legalább ekkora volt a szórás, de jellemzõek ezek a kiválasztott mérési eredmények. A forgalmi rajz:

Ez is jelentõsen más. Jól látszik az írási mûvelet alacsony volta az olvasásihoz képest!


31

5.4 A három mérés értékelése

A könnyebb áttekinthetõség végett a legfontosabb adatokat táblázatba foglaltuk, és grafikonokat is készítettünk. Az elsõ táblázatban a tesztprogramok futási ideje (time), a mért átlagos átvitele (mean Byte/Sec) és az átviteli csúcs értéke (peak Byte) látható kerekítve a két legfontosabb NFS szolgáltatásra vonatkozóan. time

Switched Ethernet Shared Ethernet ATM

mean READ3 WRITE3

peak READ3 WRITE3

00:52:05 1,89E+06 8,45E+05 4,02E+06 1,84E+06 00:48:05 1,83E+06 1,13E+06 9,68E+06 4,18E+06 00:45:01 2,54E+06 6,22E+05 8,13E+06 1,70E+06

Jól látszik, hogy a tesztprogram leggyorsabban az ATM alapú hálózaton futott le, a leglassabban pedig a kapcsolt Etherneten. Az átviteli középértékek és a csúcsok értékeléséhez már érdemes grafikonokat készíteni. Mean 3,00E+06 2,50E+06 2,00E+06

mean READ3

1,50E+06

mean WRITE3

1,00E+06 5,00E+05 0,00E+00 Switced Ethernet

Shared Ethernet

ATM

Az átviteli középértékek, azaz az idõegység alatt átvitt byte-ok átlagos számának vizsgálata azt mutatja, hogy az ATM hálózat esetében a legnagyobb az átvitel olvasási szolgáltatás esetében. Ez várható is volt, hiszen az ATM hálózat áteresztõképessége jóval nagyobb az Ethernet hálózaténál. Az osztott Ethernet esetében egy kicsit kisebb az átlagos áteresztõképesség, mint a kapcsolt Ethernetnél. Ez könnyen magyarázható azzal, hogy a megosztott Etherneten kisebb sávszélesség jut az egyes felhasználókra, mint a kapcsoltnál. A írási szolgáltatás esetében pont fordított a sorrend az átlagos áteresztõképességet illetõen. Ennek magyarázata most még rejtélyesnek tûnhet, de miután az átvitt byte-ok tömegét is megvizsgáljuk, már világossá fog válni a

32

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon jelenség. Elöljáróban csak annyit, hogy az Ethernet esetében a csomagvesztések miatt megnövekedõ újraadási forgalom lehet a fõok. Most pedig nézzük a forgalmi csúcsok ábrázolását mutató grafikont. Peak 1,00E+07 9,00E+06 8,00E+06 7,00E+06 6,00E+06 5,00E+06 4,00E+06 3,00E+06 2,00E+06 1,00E+06 0,00E+00

peak READ3 peak WRITE3

Switced Ethernet

Shared Ethernet

ATM

Érdekes a olvasásnál tapasztalható helyzet. Az ATM-nél mért viszonylag magas csúcsérték könnyen magyarázható a rendelkezésre álló hatalmas sávszélességgel. A kapcsolt Ethernet esetében a ez a sávszélesség kisebb, így a csúcsérték is. Az igazán meglepõ a megosztott Ethernetnél tapasztalható kimagasló csúcsérték. Véleményünk szerint ez az érték egy hálózati torlódás folyamán jöhetett létre. A TCP protokoll csomagjai torlódás miatt elvesztek a hálózatban, és ezzel újraadásra kényszerült az adó. Amikor a torlódás megszûnt, akkor az általa feltartott csomagok hullámszerûen elöntötték a fogadó állomást, ahol mi a forgalmat mértük. A következõ táblázat az átvitt forgalom összméretét (size byte-ban), illetve az NFS szolgáltatások hívásának számát (count) mutatja. READ3


size WRITE3

SUM

1,06E+08 4,73E+07 1,57E+08 1,47E+08 9,00E+07 2,41E+08 1,17E+08 2,86E+07 1,49E+08

READ3

count WRITE3

SUM

4290 4630 3262

2799 2778 1524

15863 14244 11388

Vizsgálatunkat célszerû grafikonnal segíteni. Az elsõ grafikon az átvitt forgalom összméretét ábrázolja. Error! Not a valid embedded object.

A grafikon készítésénél az egymásra állított oszlopos megoldást alkalmaztuk, a könnyebb áttekinthetõség miatt. Mint az a táblázatból is jól

Forgalom mérések NFS környezetben látszik, a teljes forgalom szinte megegyezik az olvasási és az írási forgalom összegével. Így látható, hogy az ATM hálózaton ment át a legkevesebb forgalom, míg a megosztott Etherneten jóval nagyobb a forgalom, mint a többi esetben. Itt utalnék a írási szolgáltatás átlagos átvitelénél tapasztalt jelenségre, hogy az ATMnél volt a legkisebb, majd a kapcsolt Ethernet következett, végül pedig a megosztott Ethernetnél volt a legnagyobb. Mivel pedig a programok futási ideje nagyjából megegyezett, ezért az átlagos átvitt forgalom is hasonló tendenciát kellett, hogy mutasson. Maga a jelenség a TCP protokoll mûködésével, és az Ethernet, illetve ATM hálózat az elméleti részben már kifejtett különbségébõl adódik. Eszerint az ATM hálózatban a hálózati architektúrából adódóan igen biztonságos átvitel valósul meg, mert túlterhelés nem léphet fel a hálózatban. Ebbõl következõleg TCP szinten szinte alig léphet fel csomagvesztés, s emiatt az átvitt forgalom a lehetõ legkevesebb. Az Ethernet hálózat esetében a csomagvesztés esélye jelentõs, és ilyenkor újraadás szükséges. A mérési eredmények szerint ez a csomagvesztési esély jóval nagyobb a megosztott Ethernet esetében, ahol a felhasználók osztoznak a sávszélességen. Ez természetesen egyezik az elméleti megfontolásokkal, hiszen a közös sávszélesség miatt a 10Mbit-bõl csak kevés jut az egyes felhasználónak. Az újraadás öngerjesztõ folyamat, mert az elveszett csomagok helyetti újraadások még inkább növelik az amúgy is túlterhelt hálózat terhelését. Ez még több csomagelveszéshez és így még több újraadáshoz vezet. Tisztán látszik, hogy a írási szolgáltatás esetében is ugyanez a tendencia érvényesül. Az olvasásnál az ATM kicsit nagyobb mennyiséget visz át, mint a kapcsolt Ethernet. Ezek után vizsgáljuk meg az NFS szolgáltatás hívásainak számáról készített statisztikát.

33

34

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon Count 16000 14000 12000 10000

count READ3

8000

count WRITE3

6000

count SUM

4000 2000 0 Switced Ethernet

Shared Ethernet

ATM

Ez a grafikon is az elõzõ fejtegetésünk helyességét támasztja alá. Az írási, az olvasási szolgáltatások hívási statisztikái szépen igazodnak a megosztott Ethernet, kapcsolt Ethernet, ATM sorrendhez. Egyedül az szorul magyarázatra, hogy a hívások összes száma miért a kapcsolt Ethernetnél a legnagyobb. A következõ táblázat az átvitt összforgalom, illetve az NFS szolgáltatás hívások számának százalékos megoszlását mutatja az olvasás és az írás között. READ3


67% 60% 78%

size in % WRITE3 EGYÉB

30% 37% 19%

3% 3% 3%

READ3

27% 32% 28%

count in % WRITE3 EGYÉB

14% 19% 13%

59% 49% 59%


35

A táblázat adatait kördiagramon ábrázoltuk. Bal oldalon az átvitt forgalom megoszlását mutatjuk be, míg jobb oldalon a hívások számának megoszlása látható. Switched Ethernet (átvitt forgalom) EGYÉB 3%

WRITE3 30%

Switched Ethernet (hívások száma) EGYÉB 59%

READ3 67%

Shared Ethernet (átvitt forgalom)

READ3 27%

Shared Ethernet (hívások száma) EGYÉB 49%

EGYÉB 3% WRITE3 37%

READ3 60%

ATM (átvitt forgalom) WRITE3 19%

WRITE3 14%

EGYÉB 3%

WRITE3 19%

READ3 32%

ATM (hívások száma) EGYÉB 59%

READ3 78%

WRITE3 13%

READ3 28%

A forgalom méretének megoszlásánál szembetûnõ, hogy az ATM-nél a olvasás aránya jóval nagyobb az írás hoz képest, mint az Ethernetek esetében. Ennek oka valószínûleg az ATM már említett „átvitelbiztos” architektúrájának, illetve az Ethernet csomagvesztéses tulajdonságának tudható be, ugyanis az írási mûvelet „nyugtázást” von maga után. Ez a furcsa megoszlás egyébként visszalapozva az ATM forgalmi rajzán is jól megfigyelhetõ. A hívási számok tekintetében az osztott Ethernet mutat eltérést. Itt nem az egymáshoz képesti arány változott, hanem a hívások száma növekedett meg az összes híváson belül. Ez világosan utal a torlódásos, sok újraadást igénylõ átvitelre.

36

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 5.5 A több gépes Ethernet mérés

Mivel három gép állt rendelkezésünkre, kézenfekvõ volt, hogy a tesztprogramot egyszerre több gépen futtatva, az NFS szervert jobban leterhelve is végezzük el a méréseket. Ezért három gépet, a demokritos-t, hobbes-t és a nietzsche-t kiválasztottuk az együttes mérésre. Az írási és másolási részét a tesztprogramoknak úgy alakítottuk ki, hogy a három gépnek ne kelljen egymásra várnia, és csak az olvasásnál használhattak azonos file-okat. Mivel rögtön egymás után indítottuk õket, ezért ugyanazokat a file-okat olvasták egymás után, s így a cache mûködés szerepe nagyon megerõsödött. Ennek mi inkább örültünk, mert a LADDIS tesztelések szerint az egymás utáni többszöri beolvasás gyakran elõfordul a valóságban. A futási idõeredményeket csak gépenként bontva tudjuk bemutatni. Nagyság szerint a sorrend nietzsche, hobbes és demokritos.

A következõkben négy forgalmi rajzot láthatunk.. Ezek a rajzok bemutatják a teljes forgalom, az olvasási, az írási forgalom összetevõinek alakulását, valamint az olvasási és írási forgalom összehasonlítását..


37

38

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 5.6 A több gépes ATM mérés

A három gépes Ethernet mérés után természetesen a három gépes ATM mérést is elvégeztük ugyanazokkal a gépekkel. A futási idõeredmények sorrendben itt is nietzsche, hobbes és demokritos.

A következõkben szintén négy forgalmi rajzot mutatunk be.


Ezeken a rajzokon szintén a teljes forgalom, az olvasási és írási forgalom összetevõinek alakulása figyelhetõ meg.

39

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon 5.7 A többgépes mérések értékelése

Az elsõ táblázat a tesztprogram futási idejeit rendszerezi. Nietzsche

Ethernet ATM

time Hobbes

Demokritos

00:51:10 00:52:23 00:42:08 00:43:28

00:53:22 00:45:14

Látható, hogy az ATM alapú hálózaton futó programok gyorsabban befejezték a futásukat, valamint az is, hogy azonos sorrendben nõ az idõ. Ennek az az oka, hogy szántszándékkal azonos sorrendben indítottuk a különbözõ gépeken a programokat. Bár az egyes programok elõnye mindössze csak pár másodperc volt, a fellépett egymásra várakozás miatt a különbség megnõtt. A következõ táblázatban az idõegység alatti átvitel és az átviteli csúcsok értékei találhatók. mean READ3 WRITE3

peak READ3 WRITE3

Ethernet 4,86E+06 3,52E+06 1,35E+07 7,41E+06 ATM 3,87E+06 1,31E+06 6,65E+06 2,79E+06

Természetesen itt is grafikonon folytatjuk a vizsgálódást. Az elsõ grafikon az átvitt forgalom átlagát mutatja (Byte/Sec). Mean

Byte/s

40

5000000 4500000 4000000 3500000 3000000 2500000 2000000 1500000 1000000 500000 0

READ3 WRITE3

Ethernet

ATM

Itt már három gép dolgozott egyszerre, terhelte az NFS szervert, s egyaránt a hálózatot is. Mivel az osztott Ethernet már az egy gépes mérésnél is komoly gondokkal küszködött, nem csoda, hogy ez itt fokozottabban jelentkezik. A sok csomagvesztés és újraadás begyûrûzõ hatása miatt, mint a késõbbiekben is látni fogjuk, olyan hatalmas plusz mennyiségû adatátvitel történik, amely az átlagos forgalmat is az ATM fölé emeli.


41

Az átviteli csúcsok a következõ grafikonon kerültek ábrázolásra.

Byte

Peak 1,40E+07 1,20E+07 1,00E+07 8,00E+06 6,00E+06 4,00E+06 2,00E+06 0,00E+00

READ3 WRITE3

Etherne t

ATM

A megosztott Ethernet átviteli csúcsa megdöbbentõ módon több, mint az ATM csúcsának duplája. Véleményünk szerint, az Ethernet nagyon túl lett terhelve, állandó a csomagvesztés és az újraadás, a kialakuló torlódások lökésszerûen oldódnak fel a hálózatban. Most pedig nézzük az átvitt forgalom adatait, és az NFS szolgálatok hívásszámait tartalmazó táblázatot. READ3

size WRITE3

SUM

Ethernet 2,96E+08 2,15E+08 5,30E+08 ATM 1,78E+08 6,03E+07 2,50E+08

READ3

14133 7243

count WRITE3

SUM

9670 49265 4379 32908

Az ebbõl származtatott, az átvitt forgalmat ábrázoló grafikon szintén azzal a feltételezéssel készült, hogy az olvasás és az írás forgalma összegezve megközelíti a teljes átvitelt.


Size 6,00E+08 5,00E+08 4,00E+08 Byte

42

size WRITE3 3,00E+08

size READ3

2,00E+08 1,00E+08 0,00E+00 Ethernet

ATM

Ezt a grafikont vizsgálva igazolni látjuk az egygépes értékelési részben kifejtetteket, hiszen az ábra magáért beszél. Az osztott Ethernet esetében mind az írási, mind az olvasási, mind az összesített forgalom is 1,5-2 szerese az ATM-es forgalomnak. Ennek magyarázata szerintünk a következõ. A TCP protokoll biztonságos átvitelt követel meg. Az Ethernet hálózat elvébõl következõen összeütközések léphetnek fel, míg az ATM architektúra eleve biztonságos átvitelt valósít meg. Így a TCP újraadást követel meg az Ethernet-tõl. A következõ grafikon az NFS hívások számát mutatja be. Count 50000 45000 40000 35000 30000

count READ3

25000

count WRITE3

20000

count SUM

15000 10000 5000 0 Ethernet

ATM

Az ábra szintén a várakozásoknak megfelelõen alakult. Az Ethernet esetében több olvasási és írási hívás, az elveszett forgalom pótlására, valamint a


43

másfajta hívások, nyugták, száma is megnövekedett, hiszen a rossz „forgalmi viszonyok” a többi NFS szolgáltatást ugyanúgy érintik. Az utolsó táblázat az átvitt forgalom, valamint az NFS hívások számának százalékos megoszlását mutatja. READ3

Ethernet ATM

55% 71%

size in % count in % WRITE3 EGYÉB READ3 WRITE3 EGYÉB

40% 24%

5% 5%

28% 22%

19% 13%

53% 65%

Az átvitt forgalom méret szerinti megoszlási kördiagramjai alább láthatók. Ethernet

ATM

EGYÉB 5% WRITE3 40%

EGYÉB 5% READ3 55%

WRITE3 24% READ3 71%

Itt is jól megfigyelhetõ az a jelenség, hogy az ATM-nél az olvasás aránya sokkal nagyobb az íráshoz képest. Véleményünk szerint ez az írási mûvelet „nyugtázásával” lehet összefüggésben, mégpedig oly módon, hogy az írást megerõsítõ kis méretû nyugták az ATM-nél nem vesznek el, míg az Ethernetnél ez könnyen elõfordulhat. Egy ilyen nyugta elvesztése pedig az írási mûvelet megismétlését vonja maga után. Az NFS hívások számának százalékos megoszlását a következõ grafikon mutatja.

44

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon Ethernet EGYÉB 53%

READ3 28%

WRITE3 19%

ATM EGYÉB 65% READ3 22% WRITE3 13%

A vártnak megfelelõen az Ethernetnél a hívások olvasás és írás aránya együttesen nagyobb a többi híváshoz viszonyítva.

Forgalom mérések NFS környezetben 5.8 Összegzés

Méréseink során bebizonyítottnak látjuk, hogy a Network File System alkalmazásához az ATM hálózaton megvalósított LAN emulációs felület optimálisabb, mint az Ethernet felületek. A forgalmi vizsgálataink alátámasztották, hogy az ATM biztonságos, az átviteli igényekhez alkalmazkodó, nagy áteresztõképességû lehetõséget nyújt. Ezzel szemben az Ethernet hálózat a TCP csomagok elvesztésével, késleltetésével nagyon sok felesleges forgalmat generálnak, leterhelik a hálózatot, s a plusz terheléssel az amúgy is súlyos helyzetet csak tovább rontják. A megfigyelések szerint az elvesztett csomagok miatti újraadások növekedése a rendszer teljesítõképességét hamar erõsen lerontják. Ezzel szemben az ATM alapú hálózatban ilyen jellegû túlterhelések a struktúrából adódóan nem jöhetnek létre, hiszen a túl sokat adó végpontot erõs terheltség esetén be sem engedi a rendszer, így védve a már létrejött kapcsolatokat. A Taffic Lab-ban jelenleg próbálkozások folynak az NFS jellemzõinek matematikai modellezésére. E mérésekkel és programokkal az NFS forgalmi tulajdonságainak feltárása és a matematikai modellek kipróbálása, szimulálása válhat valóra.

45

46


6. A tanulmányozott irodalmak jegyzéke

1. ATM White Paper LAN Emulation, virtual LANs, and the ATM Internetwork Version 1.0

ForeSystems

2. ATM White Paper ForeThought and the ATM Internetwork, An Implementation Overwiew Version 1.0

ForeSystems

3. Händel, M. N. Huber, S. Schröder ATM Networks, Concepts, Protocols, Applications Second Edition June, 1991

Siemens AG.

June, 1995

Sun Microsystem

November, 1995

Sun Microsystem

4. Callaghan, B. Pawlowski, P. Staubach NFS Version 3. Protocol Specification

5. SunSoft NFS Administration Guide

6. SunSoft TCP/IP and Data Communications Administration Guide November, 1995

Sun Microsystem

7. Andy Watson NFS Performance with NetApp Filers http://www.netapp.com/technology/level3/3008.html

Network Appliance

Irodalomjegyzék

47

8. Andrew S. Tannenbaum Számítógép-hálózatok Prentice Hall Ltd. - NOVOTRADE Kiadó Kft.

9. ATM Forum Intermediate ATM August, 1994

ATM Forum.

Az NFS teljesítõképesség vizsgálata Ethernet és ATM alapú LAN hálózatokon

Recommend Documents