Windows - Tárolási korlátok az Active Directory-ban

Vajon milyen tárolási korlátokkal kell számolnunk, ha Active Directory-t használunk? Van-e korlát és ha igen, akkor hány objektumig működőképes a rendszer? Van-e különbség a natív és kevert módok között ebből a szempontból? Mennyit számít a széttöredezett adatbázis? Milyen tárolási méret növekedéssel kell számolnunk a felhasználók számának emelkedésekor?
A címtárat alkotó fájlok
Az Active Directory tulajdonképpen egy adatbázis, mely fizikailag a következő fájlokból tevődik össze:
  • Tranzakció műveletek naplóállománya: EDB*.LOG. Ha eléri a 10 MByte-os méretet, mindig keletkezik egy új fájl, a * helyén növekvő sorrendben számokkal jelölve őket.
  • Maga az adatbázis az NTDS.DIT fájlban található.
  • Léteznek úgynevezett tartalék naplófájlok: RES1.LOG, RES2.LOG. Ide akkor történik bejegyzés, ha az EDB*.LOG nem írható, mert megtelt a merevlemez.
  • Ellenőrző naplófájl: EDB.CHK. A végrehajtott tranzakciók mutatóit tartalmazza.
  • Patch fájlok: *.PAT. Biztonsági másolat készítése közben keletkezett címtári változásokat tartja nyílván.
Tárolási különbségek a natív és kevert módok között
Telepítés után az Active Directory kevert (mixed) módban működik a Windows NT 4.0 tartományokkal való kompatibilitás megőrzése céljából. Ekkor - szintén kompatibilitási okok miatt - maximálisan 40 000 biztonsági objektumban (felhasználói- és számítógépfiókok, csoportok, stb.) van korlátozva a címtár kapacitása. Ez egy logikai korlát, ami akkor is érvényes, ha egyébként minden más (pl. merevlemez kapacitás, hardver erőforrások) lehetővé tennék a magasabb objektumszámot.
Rögtön megszűnik a korlát, ha átváltunk natív módba. Nincs szükség a korábbi tartományokkal való kompatibilitásra és immár a biztonsági objektumok maximális számának csupán a rendelkezésre álló merevlemez terület szab határt. A Microsoft hivatalos tesztje 40 millió objektummal történt, ami több mint elégnek mondható.
A teljesítményről...
Nyugodtan állíthatjuk, hogy a legtöbb cégnél a 40 000 objektum is elegendő (pl. 40 000 felhasználói fiók), ezért talán nem is a szám a lényeg, hanem az objektumkezelés sebessége. És itt egy igen érdekes dolog van a háttérben: bizonyítani látszik, hogy az Active Directory úgy van megalkotva, hogy az objektumszám ne befolyásolja jelentősen a teljesítményt. Magyarul 500 000 felhasználói fiókot sem fog érzékelhetően lassabban kezelni, mint 50-et. Ezt egy 10 000, 100 000 és 1 000 000 objektummal elvégzett teljesítményteszt is alátámasztotta, melyeket LDAP protokollokon keresztül mértek. Jótékony hatást gyakorol a teljesítményre, ha több, párhuzamos működésre alkalmas (SCSI, RAID) merevlemezzel dolgozunk és az operációs rendszert az egyikre, a címtár adatbázisát a másikra telepítjük.
Objektum, mint rekord
Eddig objektum számokról írtunk, de vajon mi alkot egy objektumot? Egy objektumot felfoghatunk egy adatbázis egy sorának, az objektum attribútumait, pedig az oszlopoknak. Sorok számában nincs korlátozás (natív módban), de "csak" maximálisan 800 nem linkelt oszlopunk lehet. Linkek (kapcsolatok) kialakításával becsatlakoztathatunk más objektumoknál definiált attribútumokat, mellyel túlléphető a 800-as korlát is.
Garbage collection és töredezettségmentesítés
A teljesítmény és objektumszám szempontjából is figyelembe kell vennünk, ha csak nem törlünk fizikailag egy objektumot az adatbázisból az Active Directory sírkővel (tombstone) jelöli meg. Logikailag hagyja figyelmen kívül: nem vesz róla tudomást, annak ellenére, hogy ott van. Replikáció útján a sírkövek is átadódnak a másik tartományvezérlőkre. Minden sírkőnek van élettartama, melynek lejárta után törlődik fizikailag az objektum. A szemétgyűjtő (garbage collection) szolgáltatás feladata, hogy bizonyos időközönként átfussa az adatbázist (1-12 óránként) és ténylegesen törölje a megjelölt objektumokat (élettartamtól függően 2-60 nap között állítható). Meg kell akadályozni, hogy a keletkezett "lyukak" miatt állandó folytonossági hiány alakuljon ki és széttöredezzen az adatbázis. Ezért minden szemétgyűjtési periódusnak része egy automatikus, online töredezettségmentesítés is. Kézzel, leállított Active Directory mellett az NTDSUTIL segédprogrammal hatékonyabb lehet összefüggővé tenni az adatbázist, de erre csak ritkán van szükség. A szemétgyűjtési folyamat minden tartományvezérlőn fut, beállításai a cn=Directory Service, cn=Windows NT, cn=Services, cn=Configuration, dc=ForestRootDomain objektum attribútumaival módosíthatók. A Windows 2000 telepítő CD \SUPPORT\TOOLS könyvtárában található SETUP.EXE feltelepítése után elérhető ADSI Edit segédprogrammal biztonságosan módosíthatjuk a paramétereket.
Fontos megjegyezni, hogy az online töredezettségmentesítés nem csökkenti az adatbázis fizikai méretét, az offline viszont igen.
Nézzük meg összehasonlításként a következő táblázatot:
Felhasználók száma adatbázisméret (széttöredezett adatbázis) méretnövekedés kilóbájtban (széttöredezett adatbázis) bájt/felhasználó (széttöredezett adatbázis) adatbázisméret (összefüggő adatbázis) méretnövekedés kilóbájtban (összefüggő adatbázis) bájt/felhasználó (összefüggő adatbázis)
0 10,256 - - 10,256 - -
100,000 516,064 505,808 5,179 364,560 354,304 3,628
200,000 899,088 383,024 4,551 720,912 356,352 3,639
300,000 1,294,352 395,264 4,383 1,079,312 358,400 3,649
400,000 1,675,280 380,928 4,262 1,435,664 356,352 3,649
500,000 2,060,328 385,048 4,199 1,792,016 356,352 3,649
Egy objektum méretének számszerűsítése függ a kitöltött attribútumoktól. Például a description mezőkbe megadott magyarázó szövegek növelik a méretet. Ennek ellenére meghatározható az átlagos méret: minden felhasználói objektum 3,7 kB, minden szervezeti egység 1,1 kB, ehhez jönnek hozzá az attribútumok, melyeknél számolhatunk 100 bájtot minden példánynál.