A NetWare 6 és az NSS 3.0 együttese
biztosan megbirkózik a feladattal

Ha általánosságban meg kellene fogalmaznunk, mire is szolgál a technológia, mit mondanánk? Alighanem sokféle dolog eszünkbe jutna, de amit talán mindenki megemlítene, az, hogy a technológia célja a bonyolult és időrabló feladatok leegyszerűsítése és felgyorsítása.

Ha arra gondolunk, hogy a számítógép-hálózati technológiák mit is egyszerűsítenek le és gyorsítanak fel, megint csak sokminden eszünkbe juthat – szinte bármi elbonyolíthatja az életet, amit kellően nagy számban vagy mennyiségben kell feldolgozni.

Eszünkbe juthatnak azok a technológiák – például az NDS eDirectory – amelyekkel mégiscsak kézben tartható és felügyelhető nagyszámú felhasználó és hálózati erőforrás. A Novell pontosan azért hozta létre az NDS eDirectoryt – a Novell Hálózati Szolgáltatásainak alapkövét – hogy leegyszerűsítse és felgyorsítsa a hálózati erőforrások felügyeletét. Megint csak hasonlóan, a Novell azért fejlesztette ki a Novell Storage Servicest (NSS-t), hogy leegyszerűsítse és felgyorsítsa a nagy mennyiségű adat felügyeletét, tárolását és visszakeresését.

A NetWare 6-tal nem jelent problémát a méret

Az NSS 3.0 – a Novell új fájlrendszerének legfrissebb verziója – a NetWare 6 részeként jelenik meg, 2001. októberében. Korábbi verzióihoz hasonlóan, az NSS 3.0 64 bites felületet használ, vagyis az NSS sokkal nagyobb fájlokat – akár 8 terabájtosakat – és köteteket képes kiszolgálni, mint a hagyományos, 32 bites NetWare-fájlrendszer (A hagyományos NetWare-fájlrendszer maximum 2 gigabájtos fájlokat és maximum 1 terabájtos köteteket képes kezelni.)

Az NSS-kötetek felkapcsolásakor (mountolásakor) az NSS csupán annyi információt tölt be, amennyi feltétlenül szükséges. Fejlett cache-algoritmusok segítségével őrzi az NSS a fájl- és könyvtáradatokat a memóriában a gyorsabb hozzáférés érdekében. Mivel ezek az adatok cache-ben vannak – és nem kell végigolvasni a teljes kötetet a felkapcsoláskor, mint azt a hagyományos NetWare-fájlrendszer teszi – az NSS sokkal gyorsabban képes felkapcsolni a köteteket. Egy problémamentes lekapcsolás után az NSS gyakorlatilag bármekkora kötetet másodpercek alatt képes visszakapcsolni.

S végül, az NSS speciális naplózási (journaling) algoritmusokat használ annak biztosítására, hogy az NSS-fájlrendszer akkor is konzisztens maradjon, ha a szerver összeomlik. &Eeacute;pp ezen algoritmusok miatt nincsen szükség a VREPAIR segédprogramra. (A hagyományos NetWare-fájlrendszer a VREPAIR segédprogramot használja a teljes kötet kijavítására. A program futtatása a kötetek méretétől függően igen sokáig is tarthat.) Mivel nincsen szükség a VREPAIR-re, az NSS-kötetek javítása akkor is gyorsan megtörténik, ha a NetWare-szerver lefagy, még mielőtt a tranzakciók végbementek volna a köteteken – más szavakkal, ha nem problémamentesen sikerült lekapcsolni a köteteket. Szerverlefagyás után is másodpercekben mérhető, amíg az NSS kijavítja és felkapcsolja a kötetet.

Az NSS-sel, „nem kell várnunk a VREPAIR-re a szerver leállása után” – magyarázta Rob Burri, a Canadian International Development Agency (CIDA) hálózati mérnöke. Az NSS azonnal kijavítja és betölti a CIDA NSS-köteteit – amelyek közül egy sem kisebb 80 gigabájtosnál, de akad 208 gigabájtos is.

Méretezhetőség korlátok nélkül

Nem titok: az NSS 3.0 komoly szerepet játszik a Novell terveiben, hogy egyszerűsítse a hálózatkezelés nehézségeit és segítsen az e-businessre történő átállás felgyorsításában. Az NSS 3.0 több processzoron is képes működni – vagyis képes megbirkózni az e-business által igényelt, gyakran nagyságrendekkel több fájlrendszer-tranzakcióval. A többprocesszorosságból értelemszerűen következik a sokkal jobb méretezhetőség – márpedig a méretezhetőség elengedhetetlen funkció minden olyan technológia esetében, amelyet az e-business támogatásához terveztek. Természetesen nem az NSS 3.0 a NetWare 6 egyetlen többprocesszoros modulja: az NetWare 6 az első perctől kezdve a méretezhetőséget szem előtt tartva készült.

Pontosan ezért szolgál a NetWare 6 számos funkciója a hálózat tárolási kapacitásának megnövelésére. A NetWare 6 kezeli az ún. hálózati tárolóeszközöket. Beépítve tartalmazza a NetWare 6 a – megint csak több processzoron futó – Fibre Channel lemezkezelést, valamint a Novell Cluster Services 1.6-ot. E termékek együttese megfelelő alapot kínál az ún. tárolóeszköz-hálózatok (Storage Area Network, SAN) kiépítéséhez.

Mindazonáltal használjunk bármilyen eszközt is a cég tárolási hálózatában, az NSS 3.0 a háttérben biztosítja, hogy az eszközökön tárolt nagy mennyiségű adathoz ténylegesen hozzá is férhessünk és használhassuk. „A NetWare 6 az a komponens, amelyik a csatlakozási felületet biztosítja a tárolóeszköz-hardver – például SAN-hardver – felé” – magyarázza Rob Storey, a Novell termékmenedzsere.

A hírmorzsákból alighanem sokminden kiderült már az NSS 3.0-ról. Szinte biztos, hogy megemlítették a hírek, hogy az NSS 3.0 már kezeli a Novell Transaction-Tracking Systemét (TTS) a tranzakciós adatok védelme érdekében. Ami talán nem kapott megfelelő visszhangot, az, hogy három új technológia – a virtuális partíciók, a tárolóterület-készletek (storage pool) és a logikai kötetek – állt csatasorba, hogy tovább egyszerűsítse az NSS-kötetek létrehozását és felügyeletét.

Virtuális partíciók

Amint az köztudott, egy merevlemezen összesen négy partíció hozható létre. Bár ez a hardverkorlát nem tűnik a hálózatfelügyeletet elbonyolító tényezőnek, azért néha lehet. Tegyük fel például, hogy NSS-kötetet szeretnénk telepíteni egy NetWare 5.1 szerverre, amelyik néha Linux-szerverként is működik. Valamint tegyük fel, hogy a hardvergyártó – mondjuk a Compaq – a szerver merevlemezének egyik partícióját gyártóspecifikus diagnosztikai és beállítási segédprogramtárnak használta el.

A problémát ez esetben az okozza, hogy a NetWare 5.1-nek még egy külön NSS-partícióra van szüksége az NSS-kötetek létrehozására. Viszont mivel a merevlemezen már négy partíció van (egy ugye a Linuxnak, egy a NetWare 5.1-nek, egy a DOS-nak és egy a gyártóspecifikus dolgoknak) nincs hová felvenni az NSS-kötetet, hacsak le nem töröljük a meglévő partíciók valamelyikét.

A NetWare 6 az ún. virtuális partíciók használatával kívánja csökkenteni a fentihez hasonló, a négypartíciós korlátból származó problémákat. A NetWare 6 telepítésekor összesen egyetlen NetWare-partíciót kell telepíteni az összes NetWare-es fájlrendszerhez – beleértve ebbe az NSS-t, a hagyományos fájlrendszert és bármilyen, a Novell által jövőben a NetWare-hez adni kívánt más fájlrendszert. Ezután a valódi partíción belül szabadon hozható létre egy vagy több virtuális partíció.

Ha például azt szeretnénk, hogy a szerver SYS kötete hagyományos típusú kötet legyen, akkor létrehozhatunk neki egy külön virtuális partíciót. (Az NSS korábbi verzióitól eltérően az NSS 3.0-ban lehet SYS kötetet létrehozni, vagyis a SYS kötet többé nem muszáj, hogy hagyományos kötet legyen.) Ha ezek után NSS-köteteket kívánunk létrehozni, akkor megint csak szabadon készíthetünk számukra egy vagy több virtuális partíciót.

NetWare 6 használata esetén nincsen korlátja az egy NetWare-partíción belül létrehozható virtuális partíciók számának. De miért is van értelme több virtuális partíciót létrehozni egyetlen fájlrendszerhez? Nos azért, mert az egyes virtuális partícióknak van egy sor jellemzője, amely meghatározza, hogyan is lehet felhasználni a tartalmát. Az egyik ilyen attribútum például a „Megosztott” (Shared), amelynek beállítása azt jelenti, hogy e partíció kötetei clusterben fog működni.

Egy másik fontos attribútum a „Tükrözés” (Mirroring), amelyikkel az szabályozható, hogy a partíció résztvesz-e egy másik NetWare-szerverre való tükrözésben. Summa summárum, szabadon hozhatók létre olyan partíciók, amelyek clusterben működnek, olyan partíciók, amelyek más szerverre vannak tükrözve, és olyan partíciók, amelyek sem clusterben, sem tükrözve nincsenek.

Virtuális partíciók létrehozása ConsoleOne-nal

A virtuális partíciók létrehozásához a ConsoleOne NSS-modulját kell használnunk:

1. Nyissuk ki a Tools (Eszközök) menüt.
2. Válasszuk ki a Disk Management (lemezfelügyelet) pontot
3. Válasszuk ki a Partitions (partíciók) parancsot, majd kattintsunk a New-ra (Új).

Alternatív megoldásként kattintsunk az egér jobb gombjával a kívánt „Szerver”-objektumra a ConsoleOne NSS-moduljában. Ebben az esetben:

1. Válasszuk ki Properties (Tulajdonságok) pontot.
2. Kattintsunk a megjelenő párbeszédablak Media (média) lapjára.
3. Válasszuk ki a Partitions (partíciók) parancsot, majd kattintsunk a New-ra (Új).

Tárolóterület-készletek (storage pools)

A virtuális partíciók szintén leegyszerűsítik a partíciók létrehozásával kapcsolatos második számú fejfájást – vagyis hogy pontosan mennyi terület is jusson az egyes partícióknak. Egy NSS-kötet létrehozásakor eddig csak a particionálatlan szabad területtel gazdálkodhattunk, és a szoftver a háttérben valósi NSS-partíciókat hozott ilyenkor létre. Egy korábbi típusú NSS-partíció esetében lehet, hogy nem jutott elegendő terület a hagyományos NetWare-kötetek számára – vagy éppen fordítva.

Az NSS 3.0 virtuális partíciói ugyancsak leegyszerűsíti a partícióméret meghatározását, hiszen az NSS 3.0 az összes virtuális partíció összes szabad területét – beleértve a hagyományos partíciókét is – képes NSS-kötetek létrehozására használni. Ez azt jelenti, hogy nem fogjuk „kiéheztetni” az NSS-köteteket amiatt, hogy túl nagy területet adtunk egy hagyományos partíciónak. (Arra ügyeljünk, hogy a fordított eset – a túl nagy NSS-partíciók miatt nem jut elég terület a hagyományos partícióknak – még mindig előfordulhat!)

A virtuális partíciókban szabadon maradt terület úgynevezett tárolóterület-készletekbe (storage pools) szervezhető. A tárolóterület-készletek az egy vagy több médián található egy vagy több virtuális partícióban lévő szabad lemezterület. Létrehozható akár egy olyan tárolóterület-készlet is, amely összefogja a merevlemezek, SAN-ok, magneto-optikai meghajtók, Jaz-lemezek vagy bármilyen más írható/olvasható média szabad területeit – feltéve, hogy ezek a területek nincsenek más tárolóterület-készlethez rendelve.

Tárolóterület-készletek létrehozása ConsoleOne-nal

A tárolóterület-készletek létrehozásához a ConsoleOne NSS-modulját kell használnunk:

1. Nyissuk ki a Tools (Eszközök) menüt.
2. Válasszuk ki a Disk Management (lemezfelügyelet) pontot.
3. Válasszuk ki az NSS Pools (NSS-készletek) parancsot, majd kattintsunk a New-ra.

Alternatív megoldásként kattintsunk az egér jobb gombjával a kívánt „Szerver”-objektumra a ConsoleOne NSS-moduljában. Ebben az esetben:

1. Válasszuk ki Properties (Tulajdonságok) pontot.
2. Kattintsunk a megjelenő párbeszédablak Media (média) lapjára.
3. Válasszuk ki az NSS Pools (NSS-készletek) parancsot, majd kattintsunk a New-ra.

Akármelyik opciót is használjuk, a ConsoleOne NSS-modulja elindít egy varázslót, amelyik kikeresi a szerverhez csatlakozó összes tárolóeszközt. A varázsló ezek után megjeleníti a szabad területek (particionálatlan szabad területek, ill. szabad területek a NetWare-partíciókon belül) listáját, amelyet még nem foglaltak le más tárolóterület-készletek (ld. 1. ábra).

1. ábra: A ConsoleOne NSS-modul része egy varázsló, amely segít a tárolóterület-készletek létrehozásában.
Mindössze ki kell választani egy vagy több tárolóeszközön a szabad területet.

Egy tárolóterület-készlet létrehozásához válasszuk ki egy vagy több tárolóeszközön a szabad területet. A létrejött tárolóterület-készlet akkor lesz használható, ha NSS logikai köteteket hozunk létre rajtuk.

Logikai kötetek

Szemben a hagyományos kötetekkel, amelyek a partíciók szabad területét használják fel, a logikai kötetek a tárolóterület-készletek szabad területével dolgoznak. Egy tárolóterület-készleten korlátlan számú logikai kötet létrehozható. (Egy NetWare-szerveren viszont egyszerre maximum 254 kötetet lehet felkapcsolni.) A tárolóterület-készletek nem foglalkoznak a fájlokkal, könyvtárakkal vagy éppen jogosultságokkal – ez a logikai kötetek dolga. Cserébe viszont a logikai kötetek, amelyek a tárolóterület-készlet területét fogyasztják, nem tudnak semmit az adott terület eredetéről.

A felhasználók a logikai köteteket – illetve ha már itt tartunk, bármilyen NetWare-kötetet, amelyre jogokkal rendelkeznek – a hagyományos NetWare-kliensszoftverrel, vagy a NetWare 6 részeként megjelent Novell Native File Access komponensen keresztül érhetik el. (A Novell Native File Access komponenssel a felhasználók az NSS-kötetekhez kliensszoftver nélkül, a munkaállomás natív fájlkezelő protokollján keresztül érhetik el. További információ a Novell Native File Access komponensről a mellékelt, Saját nyelvén, folyékonyan c. írásban olvasható.)

Szabad méretezés logikai kötetekkel

Még egy igen fontos dologban eltérnek a logikai kötetek a hagyományosaktól: a hagyományos kötetek létrehozásakor (akár a telepítés során, akár az NWCONFIG segédprogrammal) meghatározott területet kell rendelni a kötethez.

Ez a követelmény szintén megnehezíti a felügyeletet: ha a szükségesnél nagyobb területet osztunk ki, lehet, hogy másik, fontosabb kötettől vesszük el a helyet. Tegyük fel például, hogy két hagyományos kötetet kívánunk létrehozni – MAIL és DATA néven – egy 150 gigabájtos partíción. A legjobb becslés alapján a MAIL kötethez 90, a DATA kötethez pedig 60 gigabájt területet rendelünk. Két hónappal később azonban azt találjuk, hogy a DATA kötet gyakorlatilag betelt, a MAIL köteten viszont 40 gigabájt szabad. Mit tehetünk?

Az NWCONFIG segédprogrammal megnövelhető a DATA kötet mérete – már persze ha van még szabad terület a szerveren. Az NWCONFIG segédprogram azonban nem alkalmas arra, hogy csökkentse a MAIL kötet méretét és így felszabadítsa a felesleges területet. A MAIL köteten üresen álló terület tehát sima veszteség. A hagyományos kötetek méretezése tehát bonyolult dologgá válhat, különösen, ha a rendelkezésre álló tárolóterület korlátozott (márpedig ez inkább a szabály, mint a kivétel).

Ezzel szemben egy logikai kötet létrehozásakor csupán egy meghatározott számú megabájtot –kvótát – rendelünk a kötethez, amelyet nem szabad túllépnie. (Megadható az is, hogy egy logikai kötet kvótája a kötet alatt rejlő tárolóterület-készlet méretéig nőjön – ld. 2. ábra.)

2. ábra: A ConsoleOne NSS-moduljában adható meg ill. módosítható a logikai kötetek kvótája.
(A kvóták határozzák meg a logikai kötetek által használható maximális területet.)

Ahelyett, hogy automatikusan lefoglalná a kvótában megadott területet, a logikai kötetek csupán annyi területet foglalnak el, amennyire éppen szükségük van. Amikor a felhasználók és alkalmazások további fájlokat mentenek el egy logikai kötetre, akkor a kötet további területet kér a tárolóterület-készlettől a fájlok tárolásához. Ha a felhasználók törlik a fájlokat, akkor épp ellenkezőleg, a logikai kötet visszaadja a területet a tárolóterület-készletnek.

A logikai kötet kvótája a ConsoleOne NSS-moduljával növelhető vagy csökkenthető. A legtöbb esetben azonban nem sokat kell törődni a kvóta csökkentésével, hiszen a fel nem használt terület a tárolóterület-készlet többi kötetének rendelkezésére áll.

Tegyük fel például, hogy a MAIL és a DATA logikai köteteket kívánjuk létrehozni egy 150 gigabájtos partíción. A MAIL kötethez 90, a DATA kötethez pedig 60 gigabájt kvótát rendelünk. A második hónap végén azt találjuk, hogy a MAIL kötet csupán 50 gigabájtnyi területet használt el, a DATA kötet viszont a teljes kvótát elfogyasztotta. Mit tehetünk?

Mivel a tárolóterület-készlet továbbra is tartalmaz 40 gigabájt kihasználatlan területet, megengedhetjük a DATA kötet számára, hogy ezt a kötetet is elfogyassza: a ConsoleOne NSS-moduljában egész egyszerűen meg kell csak növelni a DATA kötet kvótáját.

A gyakorlatban, attól függően, hogy mennyi területre van szükség a DATA kötethez, valójában a készletnél nagyobb értéket is megadhatunk kvótának. Ebben az esetben azonban a ConsoleOne NSS-moduljában meg kell növelni a készlet méretét, hogy képes legyen kiszolgálni a kötet új kvótáját.

Hogy is készül mindez?

Egy logikai kötet kvótája a ConsoleOne NSS-moduljával az alábbi lépéseken keresztül változtatható meg:

1. Nyissuk ki a Tools (Eszközök) menüt.
2. Válasszuk ki a Disk Management (lemezfelügyelet) pontot.
3. Válasszuk az NSS Logical Volumes (NSS logikai kötetek) pontot. (Új logikai kötetek a lap New gombjára kattintva készíthetők.)
4. Válasszunk ki egy NSS logikai kötetet, majd kattintsunk az Increase Size (méret megnövelése) gombra.

Az Increase Size gombbal csökkenthető is a logikai kötet mérete. Az NSS 3.0-val szabadon csökkenthetjük a kötet kvótáját, akár az alá az érték alá is, amelyet a kötet éppen elfoglal. Ebben az esetben azonban ténylegesen csökkenteni is kell a kötet méretét – fájlokat átmozgatva vagy törölve –, mielőtt érvényre juttatjuk a változást.

Túlkönyvelni tilos! Vagy mégsem?

Aki gyakran utazik, jól ismeri a túlkönyvelés fogalmát – azt, amikor több helyet adnak el egy gépre, mint ahány ténylegesen van rajta. A légitársaságok azért könyvelik túl a járataikat, mert feltételezik, hogy az utasok közül néhány meggondolja magát az utolsó percben. A túlkönyvelés gyakorlatával a légitársaságok azt kívánják biztosítani, hogy a járatok lehetőleg mindig tele induljanak – és ezáltal maximalizálják a cég profitját.

Hasonló módon segíthet a túlkönyvelés abban, hogy a hálózati tárterület maximálisan ki legyen használva: az NSS 3.0 lehetőséget ad arra, hogy túlkönyveljük a területeket a tárolóterület-készletekben.

Tegyük fel például, hogy összesen egy darab 100 gigabájtos tárolóterület-készletből kívánunk kiszolgálni három logikai kötetet, A-t, B-t és C-t. Annak érdekében, hogy mindegyik kötetnek lehetővé tegyük akár a teljes készlet felélését, minden egyes kötet kvótáját 100 gigabájtra – a tárolóterület-készlet maximális méretére – állítjuk.

Mivel a kötetek összkvótája (300 gigabájt) meghaladja a készletben lévő területet (100 gigabájt), ez a készlet világosan láthatóan túl van könyvelve. Ha az A és B kötet jelentéktelen területet foglal el (mondjuk 1-1 gigabájtot), akkor a C kötet – amelyik sok területet igényel – szabadon nőhet a készlet maradék területéig (98 gigabájtig).

Természetesen ugyanúgy, ahogy a repülőn sem ülhetnek ketten egy székre, a tárolóterület-készlet sem képes több területet biztosítani, mint amennyi rendelkezésre áll. Ha az előző példánkban az A kötet 40, a B kötet 50 és a C kötet 10 gigabájt területet foglal el, akkor a három kötetek felélte a tárolóterület-készlet teljes kapacitását. Hiába próbál egy felhasználó felírni egy fájlt a C kötetre, az NSS 3.0 képtelen lesz létrehozni az új fájlt, még akkor is, ha a kötet messze a 100 gigabájtos kvótája alatt marad.

Más szavakkal, ahogy a túlkönyvelés a járatokon néha azzal jár, hogy páran lemaradna, a tárolóterület túlkönyvelése az NSS tárolóterület-készletekben néha azt eredményezi, hogy a felhasználók vagy alkalmazások képtelenek fájlok létrehozására vagy továbbírására.

Ez a helyzet persze elkerülhető - leginkább úgy, hogy nem könyveljük túl a területet. A döntés szabad, az NSS 3.0 nem tiltja a túlkönyvelést.

Az NSS 3.0 információt biztosít arról, hogy a tárolóterület-készlet túl van-e könyvelve és mennyire (ld. 3. ábra). Ez az információ a ConsoleOne NSS-moduljában kérdezhető le, az alábbi lépésekkel:

1. Nyissuk ki a Tools (Eszközök) menüt.
2. Válasszuk ki a Disk Management (lemezfelügyelet) pontot.
3. Válasszuk az NSS Logical Volumes (NSS logikai kötetek) pontot.
4. Válasszunk ki egy NSS logikai kötetet.
5. Kattintsunk a Properties (Tulajdonságok) gombra.
6. Válasszuk ki a Statistics (statisztikák) fület a Properties lapon.

3. ábra: A ConsoleOne NSS-moduljával megállapítható, hogy egy adott tárolóterület-készlet túl van-e könyvelve és ha igen, mennyire.

Még, még, még!

Az NSS 3.0-nak jóval több funkciója van, mint amit egy cikkben – vagy akár háromban – könnyen be tudnánk mutatni. Egy szó sem hangzott el még arról, hogyan is biztosítja az NSS 3.0 a kötet integritását, ha a szerver pont akkor fagy le, amikor egy felhasználó éppen menti a fájlját. Külön (flush on close) nevű funkció szolgál arra, hogy az NSS 3.0 az adatokat és metaadatokat közvetlenül a lemezre írja, amikor a felhasználó elment vagy lezár egy fájlt. A felhasználó alkalmazásai addig nem térnek vissza a Close vagy Save parancsokból, amíg az összes információ biztonságosan nem tárolódik a szerveren.

Ha az alkalmazás nem tér vissza ezekből a parancsokból, akkor a felhasználó tudja, hogy az adatok nem íródtak ki helyesen a szerver merevlemezére. Normális esetben – alapértelmezés szerint – a felhasználói alkalmazások azonnal visszatérnek ezekből a parancsokból, hagyván, hogy a szerver I/O-folyamatai tárolják az elmentett vagy lezárt fájlokat és a hozzájuk kapcsolódó metaadatokat. Vagyis ha a szerver lefagyott is, a felhasználók azt hihetik, hogy a fájlok rendben el lettek mentve - pedig valójában nem. (Az NSS 3.0 további funkcióit röviden a Beszéljünk róla! c. kapcsolódó cikkben soroljuk fel.)

Összefoglalás

Az új NSS technológiák segítenek leegyszerűsíteni az adatok tárolásával és elérésével kapcsolatos feladatokat –különösen az olyan cégek számára, ahol sok adatot kell tárolni és kikeresni. Óvakodnánk attól, hogy a cégeket pusztán méret alapján osztályozzuk: A papírmentes iroda egyre közelibb valósággá válik, és most minden szervezetnél szűkké kezd válni a tárolóterület –függetlenül a cég méretétől.

Legyen az Ön cége akár nagy, akár kicsi, akár a kettő között, ha eszébe jutott már a hálózati tárolás konszolidálása, akkor ahhoz egy megbízható platformra is szükség lesz. A beszerzésnél emlékezzen rá: ha tárolási platformról van szó, az NSS 3.0 és a sok-sok új komponens együttese a NetWare 6-ot igazán vonzó választássá teszi.

További erőforrások

A Novell Connection magyar nyelvű 3. száma szinte teljes egészében a NetWare 6-nak lett szentelve. Kérjük, keresse a lapot a viszonteladóknál és a magyarországi Novell-irodában!

Beszéljünk róla!

A Novell Storage Services (NSS) 3.0-ban annyi újdonság van, hogy két cikkben sem fért el minden. Az alábbiakban csak egy gyorslista arról, ami eddig kimaradt:

• Adatmegsemmisítés (Az USA Zöld Könyv fájlbiztonsági szabályzat szerint)
• Opportunista (OP)-zárások a kliensoldali cache-eléshez
• XML alapú felügyelet (vagyis saját felügyeleti segédprogramok is készíthetők, például Perlben)
• Függetlenség a fájlszolgáltatás-protokolltól az NFS-ben (Network File System)
• A módosított fájlok listája a mentések során elért jobb eredmény érdekében
• Szoftveres RAID 0 kezelés ConsoleOne-felügyelettel

Saját nyelvén, folyékonyan

Tegyük fel, hogy tárolóeszöz-hálózatot (Storage Area Network, SAN) kívánunk építeni, és ehhez a NetWare 6-ot használni az NSS 3.0 már ismertetett számos előnyös tulajdonsága miatt. Tegyük fel továbbá, hogy a SAN számos különböző operációs rendszert kell, hogy kiszolgáljon, és nem akarunk az összes gépre Novell-kliensszoftvert telepíteni. Semmi probléma: a NetWare 6 alábbi szerveroldali komponensei biztosítják, hogy a Windows, Macintosh és UNIX munkaállomások elérjék az NSS-kötetek natívan:

• Novell Native File Access for Windows. Ez a komponens biztosítja, hogy a Windows 2000, NT, 98 és 95 operációs rendszerek felhasználói hozzáférjenek a NetWare-szerveren tárolt fájlokhoz a Common Internet File System (CIFS) protokoll – a Windows natív fájlkezelő protokolljának – segítségével.
• Novell Native File Access for Macintosh. Ez a komponens biztosítja, hogy a Mac OS 8.1 és frissebb operációs rendszereket futtató (a Mac OS X is!) munkaállomások képesek legyenek a NetWare-szerverekkel kommunikálni az AppleTalk Filing Protocol (AFP) segítségével, TCP/IP-n keresztül.
• Novell Native File Access for UNIX. Ez a komponens minden olyan UNIX-os gépet kezel, amelyiken az Network File System (NFS) 3-as vagy 2-es verziója fut, és TCP/IP-n kapcsolódik a hálózathoz.

A Novell Native File Access for Macintosht használó Novell-alkalmazottak azt jelezték, hogy termék ténylegesen javította a hálózati teljesítményt. Dan Lawyer, a Novell termékmenedzsere szerint az új megoldás „lényegesen” gyorsabb, mint a korábbi szoftver, amelyik a NetWare-fájlokat IPX-en vagy AppleTalkon keresztül érte el.

A felhasználói azonosítók felügyelete

A Novell Native File Access komponensekkel a felhasználói azonosítók is az adott operációs rendszer natív eszközeivel kezelhetők. A felhasználók Windows-jelszavai a Windows NT tartományvezérlőjében állíthatók. Hasonlóan, a UNIX-os azonosítók a felügyelhetők a UNIX-os NFS-szerverről. A kérdés persze az, hogy miért is akarná ezt az ember, amikor az egészet egyben, egységesen lehetne felügyelni az NDS eDirectoryval?

őszintén megvallva, nem könnyű elképzelni, miért jó felhasználók külön szigeteit felügyelni. Mindazonáltal Lawyer azt állítja, hogy néhány Novell-vásárló pont ezt akarja, és a Novell „one Net”-stratégiájának része, hogy ezt lehetővé tegye számukra. Ebben az esetben a Novell Native File Access komponensei a Windows, Macintosh vagy UNIX operációs rendszerekhez fordulnak a felhasználó hitelesítése érdekében (egyébként a Novell Modular Authentication Servicest használnák, és afféle proxyként működnének a felhasználók kliensgépei és az NDS eDirectory között).

Tehát ha egy – a Novell Native File Access for Macintosht használó – felhasználó bejelentkezik egy NetWare 6 szerverre, az NMAS elcsípi a felhasználó megadott adatait, amelyet a Macintosh a Message Digest 5 (MD5) algoritmussal titkosít. Az NMAS ezek után proxyként hitelesíti a felhasználót az NDS eDirectoryba (ez momentán RSA-titkosítással történik). Ha a felhasználó valóban az, akinek mondja magát, akkor hozzáférhet minden fájlhoz és kötethez, amelyhez jogokat kapott az NDS eDirectoryban.