NDS eDirectory™ Design 2000 Justin J. Taylor cikke alapján Az alábbi dokumentum az NDS eDirectory™ tervezésével kapcsolatos szempontokat járja körül, mind a vállalati hálózatok, mind az internetes, személyazonosság-kezelésre épülő e-business tekintetében.
Mi az NDS eDirectory™? Az NDS eDirectory™ az NDS legfrissebb változata. Az 1999. májusában megjelent NDS v8-ra épülő NDS eDirectory™ egy ún. „teljes szolgáltatáskörű címtárat” valósít meg, rugalmas és bővíthető felderítési, bőséges biztonsági, kiválóan méretezhető tárolási, valamint a belső és külső kapcsolatok nyilvántartását segítő funkciókkal. A Novell NDS eDirectory™ a Novell címtáralapú megoldásainak „lelke”. Rá épülnek a Novell új felügyeleti megoldásai, például a ZENworks és a ZEN for Servers. Az internetes e-business terén a Novell szintén számos megoldást kínál a cégek közötti (B2B-) és a fogyasztói (B2C-) e-kereskedelmi igények kiszolgálásához.
Az NDS eDirectory™ tervezése Az NDS-környezet helyes kialakításához számos tényezőt kell figyelembe venni. Egyesek műszaki, mások üzletpolitikai vagy kulturális jellegűek. Az alábbiakban ezekre kívánunk választ keresni. A címtárfák száma Az NDS megjelenése óta azon az állásponton van a Novell, hogy a legtöbb szervezet számára egyetlen címtárfa használata az ideális. Végül is, a címtárszolgáltatás lényege, hogy a szervezetet reprezentálja, szervezetből pedig egy van. A Novell maga is egy globális szervezet, egyetlen címtárfával. Az egyetlen fa használata számos előnnyel jár: egyetlen felhasználói személyazonosság a teljes hálózaton, átláthatóbb biztonság és egyetlen pontból elvégezhető felügyelet. MEGJEGYZÉS: Az egyetlen fa preferálása nem jelenti azt, hogy a tesztkörnyezetben sem szabad más fákat használni. Ettől még persze dönthetnek úgy szervezetek, hogy több címtárfát használnak, legyen erre bármilyen okuk is (mondjuk mert egy olyan nagy szervezet, amely több autonóm szervezetből épül fel vagy mert a szervezeten belüli hatásköröket el kívánják különíteni). Ezen szervezetek számára a Novell jelenleg számos különféle integrációs eszközt készít: DirXML™: A DirXML™ a Novell által kínált megoldás a teljes vállalatra kiterjedő címtárintegrációhoz. Több NDS-címtárfa vagy más címtár is használható, és az adatok szinkronizálhatók közöttük. A rendszergazdák maguk írhatják meg XML-ben az üzletet, illetve a címtárak közötti információcserét leíró szabályokat. A 2. ábrán egy John nevű felhasználó látható, amelynek adatai szinkronizálódnak az NDS eDirectory™ fák között. Az új John az ACME_HQ fában most már kaphat jogokat az új fa erőforrásaihoz. A DirXML™ „NDS–NDS”-meghajtóprogramja még a jelszavak biztonságos szinkronizációját is lehetővé teszi a fák között.
1. ábra: A DirXML™ két fa között szinkronizálja az adatokat
A DirXML™ nemcsak két NDS eDirectory™ címtárfát tud szinkronizálni, hanem más címtárakat is, így a Microsoft Active Directoryját, a Netscape iPlanet Directory Service-ét, a Microsoft Exchange és a Lotus Notes címtárait. Egyedi meghajtóprogramok is készíthetők a Novell DirXML™ Driver Toolkit segítségével. NDS-egyesítés (federation): Azok számára is van megoldás, akik nem akarnak két fát szinkronizálni, de elérést kívánnak biztosítani egy másik fa erőforrásaihoz. A Novell NDS-egyesítési megoldása pontosan ezt teszi lehetővé.
2. ábra: Az NDS egyesítési funkciójával az egyik fa objektumai jogokat kaphatnak egy másik fa objektumaihoz
Az NDS-fa mérete Az NDS v8-tól kezdődően az NDS-címtárfa méretkorlátai a múlté. Az NDS eDirectory™-t a gyakorlatban is kipróbálta a Novell egy egymilliárd objektumot tartalmazó NDS-címtárfával – ez azt jelenti, hogy az NDS a világ legjobban méretezhető címtárszolgáltatása. A fa egyetlen korlátját a lemezterület és a lemez I/O korlátai jelentik. A szükséges lemez- és memóriaméret meghatározásához használjuk az alábbi becslést. Az NDS eDirectory™ egy tipikus objektuma 3-5 kilobájt közötti méretű. Ez alapján gyorsan kiszámolható, hogy mennyi helyet foglal el a kívánt számú objektum. Természetesen a 3-5 kilobájtos méret változhat annak függvényében, hogy pontosan milyen adatokat is tárolunk a címtárban. Ha az objektumok BLOB-
adatokat, például képeket, hangokat vagy biometrikai tartalmaznak, az objektumméret lényegesen nagyobb is lehet.
jellemzőket
is
Műszaki megjegyzés: Az NDS eDirectory™ adatbázisának mérete a következőképpen határozható meg. NetWare esetében töltse le a TOOLBOX.NLM-et a Novell webhelyéről. Ezzel megtekintheti a SYS: _NETWARE könyvtárat. Windows NT esetében a címtáradatok a \NOVELL\NDS\DIBFiles könyvtárban található. Sun Solarison ez a hely a telepítés során megadott helytől függ.
Partícióhatárok Az NDS egyik igen fontos jellemzője az, hogy kisebb szegmensekre, ún. partíciókra osztható, ugyanakkor továbbra is egységes névteret használ. Az évek során két fő ok miatt ajánlotta a Novell a particionálást: WAN-kapcsolatok: Egy szokásos NDS-címtárfa legteteje tipikusan a különböző földrajzi területeket reprezentálja, amelyeken a szervezet működik. E felépítés révén a névtér a földrajzi eloszlásnak megfelelően osztható partíciókra. Fontos megjegyezni, hogy nem kötelező így tervezni az NDS-címtárfát – viszont érdemes, mert messze ez a felépítés terheli legkevésbé a drága WAN-vonalakat. Partícióméret: Az NDS korábbi változataiban fontos tényező volt a partíciók mérete. Mivel a címtár alapjául szolgáló adatbázist nem extrém nagy (több mint 10 ezer objektumot tartalmazó) partíciók kezeléséhez tervezték, így további partíciókat kellett létrehozni. Az NDS eDirectory™ adatbázisa sokkal méretezhetőbb, úgyhogy a Novell jelenleg ajánlott korlátai a partíció méretezésével kapcsolatban: Partícióméret
korlátlan számú objektum
A fában lévő partíciók száma
korlátlan
Szülőnkénti gyermekpartíciók száma:
150
Partíciónkénti replikák száma
50
Replikaszerverenkénti replikák száma
250
Ezek a szabályok általában az elosztott környezetekre, például a vállalati hálózatokra igazak. Nem feltétlenül igazak azonban az e-business esetében, ahol sokkal jellemzőbb követelmény, hogy az összes adat egyetlen szerveren legyen. Tipikus ez például a telefonkönyv jellegű megoldások, illetve az NDS alapú internetes hitelesítés és személyazonosság-felügyelet esetében. Az e-business rendszerek jellemzően egyetlen partícióban tartalmazzák az összes adatot. A NDS eDirectory™ legújabb 8.5-ös változata, már képes ún. szűrt replikákat használni, amelyek a címtárfa csak meghatározott objektumait és attribútumait fogják tartalmazni. Ez megfelel az e-business igényeknek, ugyanakkor mégsem kell az összes adatot egyetlen szerveren tárolni. A faterv előnyösen és hátrányosan is befolyásolhatja a particionálási stratégiát. Célszerű az alábbi szabályokat állandóan betartani:
3. ábra: Példa egy vállalati NDS eDirectory™ fatervre
• • • •
A fa teteje a WAN-infrastruktúrát tükrözze A fa alja a hálózati erőforrások szerkezetét tükrözze Ne készüljön olyan partíció, amelyik átlóg egy WAN-kapcsolaton Az egyes telephelyeken a helyi szerverek szerint particionáljunk.
E-business használat esetén e szabályok legtöbbjére nincs szükség, hiszen általában nem sokat törődünk azzal, hogy az adott felhasználó honnan is érkezett az Internetről. E-business esetén általában sekély, lapos címtárfát készítünk. MEGJEGYZÉS: Habár az e-business számára előnyös, ha az összes adat egy szerveren van, attól még érdemes replikálni a hibatűrés és a terheléselosztás érdekében más szerverekre. A replikák elhelyezése A replikák elhelyezése két okból igen fontos: a hozzáférhetőség és a hibatűrés szempontjából. Ahogy egyre több adatot tárolunk az NDS-ben, annál nagyobb értéket képvisel a címtár. Az alábbiakban röviden felsoroljuk a replikaelhelyezés alapvető szabályait:
4. ábra: Az NDS eDirectory alapvető replikaelhelyezési módja
•
•
•
Replikáljunk helyileg. Tartsunk két-három replikát a telephelyen belül. Háromnál többet nem érdemes, kivéve, ha valamilyen oknál fogva elérhetővé kell tenni az adatokat egy távoli telephelyen is, vagy e-business esetekben, ahol a címtárszolgáltatást rengeteg felhasználó éri el, és a terheléselosztás miatt muszáj több replikát használni. Tartsuk a master replikákat központi helyen. Mivel a master replikák szükségesek a partícióműveletekhez (pl. új partíció létrehozásához), célszerű őket ott tárolni, ahol a partícióműveletet végrehajtjuk. A Novell azt javasolja, hogy a particionálást egy ember végezze, vagy legalábbis ugyanarról a központi helyről. Ugyanez áll a master replikák központi biztonsági mentésére. A fenti példában az összes master replika PRV-DSMSTR nevű szerveren van. Ez – az ún. replikaszerver használata – nagy környezetekben bevett gyakorlat. Csak akkor tegyük a replikákat nem helyi gépre, ha a) muszáj hibatűrést biztosítani, és helyileg nem lehetséges két-három replikát elhelyezni, b) ha
biztosítani kell az adatok helyi elérhetőségét és c) ha központilag akarjuk felügyelni és tárolni a master replikákat. Alkalmazás-specifikus kérdések Egyes esetekben az alkalmazások is befolyásolhatják az NDS eDirectory™ címtárfa kialakítását. Ez általában csak a particionálás és a replikálás áttervezését jelenti. Az alkalmazások jobban működnek, ha a szükséges adatok gyorsan rendelkezésre állnak. MEGJEGYZÉS: Az NDS eDirectory™ számos alkalmazás számára szolgál adatforrásként. E probléma megoldása érdekében fejlesztett ki a Novell egy újfajta replikatípust, az ún. szűrt replikát (filtered replica). Ez a fajta replika egyszerre „ritka” (abban az értelemben, hogy csak a megadott objektumosztályokat tartalmazza), és „töredékes” (csak a meghatározott attribútumokat tartalmazza). Így megoldható, hogy az alkalmazások, amelyek az NDS eDirectoryban tárolt adatok globális képét kell, hogy lássák, gyors válaszhoz jussanak anélkül, hogy más szerverekkel kellene kommunikálniuk.
5. ábra: Szűrt NDS-replikák
A DirXML™ és a Novell eGuide™ (egy LDAP alapú telefonkönyv-alkalmazás) például sokat profitál a szűrt replikák használatából.
Az NDS eDirectory™ implementációja A hatékony terv kialakítását megfelelő implementáció kell, hogy kövesse. Alább áttekintjük a hardverkövetelményeket, a terheléselosztás biztosításának új módjait és az NDS eDirectory™-val kapcsolatos paraméterek beállításait és hangolását. Hardverkövetelmények A hardverkövetelmények meghatározása nehéz kérdés, mivel minden egyes implementáció eltérő. A szokásos séma használata esetén az NDS eDirectory™ 50 ezer felhasználónként mintegy 74 megabájt lemezterületet igényel. Természetesen, ha új attribútumokat veszünk fel, vagy teljesen kitöltjük az összes meglévő attribútumot, az objektumok mérete megnövekszik. Ez befolyásolni fogja a szükséges lemezterület, processzor és memória méretét. JAVASLAT: A legjobb eredmény érdekében próbáljuk a címtáradatok mennél nagyobb részét cache-ben tartani. Ha lehetséges, az összeset. Ami a processzor méretezését illeti, az NDS igen jól méretezhető egyetlen processzoron is. Az NDS maga nem processzor-, hanem I/O-igényes folyamat. A DSREPAIR nem hálózati I/O-igényes, hanem lemez- és processzor I/O-igényes alkalmazás. További processzorokat felvéve egy Intel alapú NetWare-es rendszerbe, nagymértékben megnövelhető az NDS eDirectory™ teljesítménye. Tipikus Intel alapú megvalósítások (NetWare, Windows NT és Linux): Objektum
Processzor
Memória
Merevlemez
100 ezer
Pentium III 450-700 MHz (egy)
384 MB
144 MB
1 millió
Pentium III 450-700 MHz (kettő)
2 GB
1,5 GB
10 millió
Pentium III 450-700 MHz (2-4)
több mint 2 GB
15 GB
Tipikus Sparc alapú megvalósítások (Solaris): Objektum
Processzor
Memória
Merevlemez
100 ezer
Sun Enterprise 4500
384 MB
144 MB
1 millió
Sun Enterprise 5500
2 GB
1,5 GB
10 millió
Sun Enterprise 6500 több processzorral
több mint 2 GB
15 GB
Ne feledjük, hogy a fent megadott processzorteljesítménynél nagyobbra lehet szükség, ha további szolgáltatásokat is futtatunk a rendszeren. Függ ezenkívül a kiszolgált hitelesítések, olvasások és írások számától is. A titkosítás és az indexelés igen processzorigényes tevékenységek. A memória a jelzettnél nagyobb mennyisége mindig segít, ugyanis az NDS így több címtáradatot képes a memóriában (cache-ben) tartani. A merevlemez-mennyiségeket a 74 megabájt/50 ezer felhasználó becslés alapján adtuk meg. Amint már említettük, ha új attribútumokkal bővítjük a címtárat, akkor lényegesen nagyobb területre lehet szükség. Terheléselosztás Az NDS terhelésének elosztása vállalati környezetekben általában nem szokott komoly problémákat okozni. Az NDS kiválóan működik ezekben a környezetekben és még a régebbi NDS-verziók is megfelelőek egészen nagy, akár globális, nagymértékben elosztott címtárfák kezelésére. Ezt a címtár particionálásával és több szerverre való replikációjával lehet megvalósítani. Az Internet és az e-kereskedelmi alkalmazások – például internetes telefonkönyvek, portálok, személyazonosság- és profilfelügyelet stb. – esetében számos új módszert is használhatunk az e-kereskedelmi alkalmazások nagyobb teljesítményre serkentéséhez. DNS Round Robin: Olyan e-business megoldások esetében, amikor a felhasználók és az alkalmazások az Interneten keresztül kérnek szolgáltatásokat, jól működhet egy DNS Round Robin konfiguráció. Ez azt jelenti, hogy egy adott hosthoz a DNS-ben több IP-címet adunk meg (pl. a www.acme.com címhez hozzárendeljük a 10.0.0.1, a 10.0.0.2 és a 10.0.0.3 címeket). A legtöbb DNS-szerver ilyenkor szépen sorban, körben (round robin) adogatja vissza az IP-címeket a lekérdezések kiszolgálása során. Az NDS eDirectory™-t használó alkalmazások ezek után a DNS által visszaadott IP-cím alapján fognak hozzáférni az NDS eDirectory™-hoz, a megfelelő szerveren. Ez a módszer lehetővé teszi a dinamikus változtatásokat is és az esetek többségében remekül működik. Statikus konfiguráció: A DNS Round Robin egyetlen problémája a DNSválasz extra késleltetése. Ha ez problémát jelent, akkor az egyes szolgáltatásokat statikusan, kézzel külön-külön NDS-szerverekhez rendelhetjük, vagy olyan folyamatot alakítunk ki, amely ezt helyileg, DNSszerver közreműködése nélkül oldja meg.
Az NDS eDirectory™ hangolása Az NDS hangolása fontos tevékenység. Még a legdrágább hardver esetében is érdemes foglalkozni vele, hogy maximálisan kihasználhassuk a funkcionalitását.
Az alábbi táblázat olyan beállításokat tartalmaz, amelyek számos feladat esetében optimalizálják az NDS eDirectory™ működését.
Ezek a paraméterek a NetWare-implementációkra vonatkoznak. A NDS eDirectory™ teljesítményét leginkább befolyásoló tényező a cache. Amennyiben lehetséges, az NDS méretével megegyező mennyiségű memóriát kell biztosítani a cache számára. Ha extrém teljesítményt kívánunk, akkor ezen arány (1:1) fölé kell mennünk. A cache mennyiségének beállításához az alábbi feladatokat kell elvégezni az NDSszervereken: Platform NetWare NT
Hely
Lépések
Konzolképernyő
SET DSTRACE=!MB
_NDSDB.INI
Hozzunk létre egy _NDSDB.INI nevű fájlt a \NOVELL\NDS könyvtárban Írjuk bele az alábbi parancsot: CACHE=< a kívánt mennyiségű RAM MB-ban>
Solaris
ndstrace képernyő
Indítsuk el az ndstrace-t a Sun Solaris szerveren SET DSTRACE=!MB
Az NDS eDirectory™ karbantartása A tervezési és az implementációs fázis után már csak üzemeltetni és karbantartani kell a címtárat. Az alábbiakban a helyreállást, az NDS eDirectory™ épen tartását és figyelését tekintjük át. Helyreállás katasztrófából Számos tényezőt kell figyelembe venni a mentési és visszaállítási stratégia kidolgozásakor. A mentések elsődleges célja, hogy az adatok visszaállíthatók legyenek, amikor a szerver meghibásodik. Ez a szokásos hozzáállás fájlok vagy adatbázisok esetében. Az NDS egyik komoly előnye, hogy – a replikáció révén – igen hibatűrő szerkezetű. A legtöbb szervezetnél a címtár replikációja szolgál a hibatűrés elsődleges védelmi vonalául. Azoknak, akik ennél is magasabb szintű védelemre vágynak, érdemes megfontolniuk a Novell Clustering Services for NetWare használatát. A Novell azt ajánlja vásárlóinak, hogy a replikáció és a mentések kombinációjával védjék címtáradataikat. A rendszeres biztonsági mentések a helyreállítás zálogai katasztrófák esetén is, amikor az összes szerver tönkremegy. Ne feledjük, hogy
bár a replikáció automatikus és igen megbízható, korántsem bolondbiztos. A fa komoly meghibásodásai adott esetben továbbreplikálódhatnak máshová. Ezenfelül egy felhasználó a megfelelő jogok birtokában óriási mennyiségű adatot képes kitörölni a fából, amelyet megfelelő mentés nélkül nem lehet visszaállítani. Fontos tehát, hogy megfelelő stratégiát, valamint megfelelő szoftvert és hardvert válasszunk a biztonsági mentésekhez. A mentések három típusa – teljes, növekményes és különbségi – jól ismert mindenki számára, a kérdés nem is az, hogy melyiket használjuk, hanem az, hogy milyen lépéseket is tartalmazzon a stratégia a mentések gondos végrehajtását illetően. A stratégia erősen függeni fog attól, hogy a szervezet elosztott, centralizált vagy mindkettő. Szintén figyelembe kell venni, hogy az egyes telephelyek maguk fogják végezni a mentéseket, vagy központilag történik a mentés. A CNN egy úgynevezett „karbantartási” replikát használ, és ezen végzi a mentési és karbantartási munkákat. Ezt a replikát le lehet választani a gyors javításokhoz és ez a replika szolgál a NetWare-en Legatoval végzett mentések alapjául (a mentés egy solarisos lemezfarmra történik). TECH. MEGJEGYZÉS: A DSREPAIR a Novell többplatformos címtárkarbantartó segédprogramja. NetWare-en a DSREPAIR.NLM-et kell betölteni, Windows NTn a DSRepair-t elindítani a Vezérlőpanel NDS Services ikonjából. Solaris és Linux esetében az ndsrepair programot kell lefuttatni. Az NDS eDirectory™ működő állapotának megőrzése A címtárszolgáltatás működő állapotának ellenőrzésére és megőrzésére szolgáló eszközöket és technológiákat a Novell új CDE (Certified Directory Engineer, vizsgázott címtármérnök) 991-es számú kurzusa (Advanced NDS Tools and Diagnostics) tartalmazza. A működés figyelemmel kísérése A címtárfa helyes működését tipikusan gondos rendszerfigyeléssel lehet biztosítani. A figyelés kétféle módon történhet, reaktív (a hibákra reagáló) és proaktív (megelőző) jelleggel. Reaktív: A Novell nem ajánlja az NDS üzemszerű, reaktív jellegű figyelését. Ez csupán a hibákra reagálást jelent (pl. egy felhasználó nem fér hozzá a fa egy részéhez, mire egy mérnök a DSTRACE segédprogrammal nekiáll kideríteni a hibát). Proaktív: A megelőző jellegű rendszerfigyelés lényege, hogy hosszabb időn keresztül tudatosan figyeljük az NDS-műveleteket és megállapítunk alapértékeket, amelyekkel össze tudjuk hasonlítani az aktuális értékeket és döntéseket tudunk hozni a rendszerrel, például a további bővítésekkel kapcsolatban. A Novell DSTRACE segédprogram most már NetWare-en, Windows NT-n, Solarison és Linuxon egyaránt használható. Ez az eszköz segít az NDS eDirectory™ erőforrásainak figyelésében, bár kicsit fapados. Érdemes lehet külső cégek termékeire áldozni. Ilyen eszköz például a: • BindView: http://www.bindview.com • Blue Lance: http://www.bluelance.com/ • NetPro: http://www.netpro.com
