A Distributed File System

infrastruktúra

A Distributed File System

Az adatok elhelyezésének és szervezésének számtalan módja van. Tárolhatjuk őket adatbázisban, floppylemezen, pendrive‑on, publikálhatjuk webes tartalomként, vagy elmenthetjük szalagra. Most mégis maradjunk az irodai környezetben talán leghagyományosabbnak mondható módszernél: helyezzük el adatainkat a fájlszerveren, és tegyük ott elérhetővé a felhasználók számára.

V

oltaképpen persze nem túl izgalmas a történet. A hálózati felhasználó kitallózza magának a megfelelő kiszolgálót, rálel a szerencsés esetben beszédes nevű megosztásra, ott a mögöttes könyvtárstruktúrában biztos kézzel kattintgatva eljut a tizenhatodik alkönyvtárba – és a kívánt fájl már meg is van. Nincs itt semmi hiba, a rendszer gazdája időről időre elmagyarázza az újonnan belépő alkalmazottaknak, hogy mit hol találnak. Igen ám! De a cég növekszik, egyre több a felhasználó, egyre több a napi használatú adat, és ha lehunyjuk a szemünket egy-két évre, egy olyan infrastruktúrát látunk ébredéskor, amelyben több tucat szerver több telephelyen tárolja felhasználók százainak vagy akár ezreinek adatait. Ebbe a környezetbe képzeljük bele Béla bácsit és Juliska nénit mint a rendszerrel épp most ismerkedő felhasználókat. Rendszergazda jön, nagy levegőt vesz, és elkezdi hosszasan sorolni, hogy az adott munkakörhöz tartozó állományok mely szerverEK melyik megosztásAIBAN, mely alkönyvtárAKban találhatók. Míg Béla bácsi pislogva memorizál, és csak három perc múlva adja fel, addig Juliska néni már az első perc után könnyes szemmel papírzsebkendő után kutat… Nem beszélve arról, hogy egy olyan telephelyen fognak dolgozni, amelyik az adatközponttal csak egy jóféle 512 kbit/másodperces kapcsolattal bír. Míg egyegy fájl megnyitása közben Béla bácsi átfuthatja a teljes sportrovatot, addig Juliska néni a társkeresőt olvashatja el. Főleg, ha megtalálják a szükséges fájlt. Feltéve, hogy akarnak ilyen környezetben dolgozni egyáltalán. Itt kap szerepet az a szolgáltatás, amelyet névről ismerhetünk már a Windows NT-s 1. ábra. A DFS replikációjának időzítése 46

korszak óta, bár ott addendumként illeszthettük a rendszerhez, a Windows 2000-ben már a telepítőcsomag része: a DFS, azaz a Distributed File System. Ezt a DFS-t újították meg, egészítették ki és tették nagyon sok meglévő problémára megoldásként felhasználhatóvá a Windows Server 2008-ban. Mit tudott és mit tud most a DFS?

DFS az előző Windows-verziókban Standalone DFS. Noha ez az írás nem a múltba igyekszik tekinteni, nézzük meg, hogy milyen környezetet alakíthattunk ki DFS-sel régebben. A probléma adott: sok szerveren, sok megosztásban, bonyolult könyvtárstruktúrában sokak adatai laknak, valószínűleg a legjobban csoportosítva. A legjobban, de nem biztos, hogy mindenki számára megfelelően. Ebben az esetben a DFS – mondhatni tradicionálisan – segítségünkre lehet. Azoknak a felhasználóknak, akiknek nem megfelelő a jelenlegi adatszervezés, mutassunk egy olyan adatstruktúrát, ami nem valós ugyan, de mutatókat, pointereket tartalmaz a valós adathelyekre. Ideális megoldás, hiszen az adatot nem kell elmozdítani a je-

infrastruktúra lenlegi helyéről (sokaknak pont úgy jó, ahogy van), de láttathatjuk úgy, mint ha átcsoportosítottuk volna azokat. Hogyan is néz ki ez a gyakorlatban? Legyen A és B a két tényleges fájlszerver. Mindkettőnek számtalan megosztása van, köztük A-nak Do­ku­men­tu­mok1 és B-nek Do­ ku­men­tu­mok2. Egy adott felhasználó kénytelen tudatosan csatlakozni mindkét szer-

pointerek, jelen esetben az A szerver Do­ku­ men­tu­mok1 és a B szerver Do­ku­men­tu­mok2 megosztásaira mutatnak. Tetszőleges mennyiségű pointert helyezhetünk el a DFS root alatt, amelyek a valós célhelyekre mutatnak. Ennyi lenne a DFS? Nos, tulajdonképpen ennyi a Standalone DFS-változat, annyi kiegészítéssel, hogy a pointerek kialakításakor megadhatunk alter-

2. ábra. A Standalone DFS architektúrája verhez, sőt annak konkrét share-jeihez és az általa használt Do­ku­men­tu­mokat erről a két helyről megnyitni. Ha szeretnénk számára leegyszerűsíteni az elérést, vegyük elő a Z szer-

natívákat is a cél tekintetében, azaz ha a C szerver Do­ku­men­tu­mok1 megosztása ugyanazzal az adattartalommal bír, mint az A szerver Do­ku­men­tu­mok1-e, akkor a hibatűrés és

3. ábra. Az Active Directory integrált DFS architektúrája vert, és jelöljük ki DFS rootnak! A DFS root egy olyan „megosztott könyvtár”, amelynek alkönyvtárai nem (feltétlenül) valósak, csak március

-április

a terhelésmegosztás jegyében a DFS root alatti „könyvtár” mindkét helyre egyaránt mutat. Ezt a DFS a kliensgép számára listaként,

mintegy folyamatosan változó sorrendiséggel közvetíti, tehát nagyszámú kliens esetén azok kb. egyenlő arányban oszlanak meg a tényleges célhelyek között. Itt jegyzendő meg, hogy a DFS root által felkínált „virtuális” könyvtárstruktúrára kattintva nem a DFS-kiszolgáló keresi fel a valós célt, hogy leplezze a csalást! A kliensgép DFSügyfélkomponensének üzen, amelyik felkeresi a tényleges adathelyet. Telepítettünk mi ilyet? Nem, de ez bizony szerényen megbújó része a Windowsnak ősidők óta. Igen ám, de mi a helyzet a módosított Do­ ku­men­tu­mokkal az azonos tartalmú célhelyeken? Ha az A szerver Do­ku­men­tu­mok1-ében módosítunk, az eljut valahogy a C szerver Do­ ku­men­tu­mok1-ébe? Sajnos nem. Standalone DFS esetén (hangsúlyozom, hogy nem a Windows szerver 2008-ban található DFSről van szó!), a célhelyek csak olvasható Do­ ku­men­tu­mokkal legyenek tele, vagy változások, módosítások esetén gondoskodjunk mi a konzisztenciáról. Jó, de hogyan? Akárhogyan – mondja a régi DFS – ez már nem rám tartozik. Hát… köszi. Igazán kedves… Domain-Based, azaz Active Directory-integrált DFS. Amikor megjelent a Windows 2000 és az Active Directory, a DFS sokat változott – előnyére. Bár a Standalone-változat megmaradt, a Domain-Based sokat ígért, és azt be is váltotta. Root-replikát alakíthattunk ki, azaz ha a DFS rootunk valamiért kiesett, fordulhattunk egy másikhoz, ahol ugyanaz a „virtuális” struktúra fogadott minket a valós célhelyekre mutató pointerekkel. Nagy előrelépés! Főleg ha azt is számításba vettük, hogy nem is konkrétan a DFS-szerverre kellett hivatkozni, ha a rootot akartuk elérni. Az AD felkínált nekünk egy olyan belépési pontot, amely egy igen furcsa UNC path: \\domainnév\dfsrootnév. Az erre tett hivatkozáskor az AD szerepe nem ért véget, hiszen a kliens IP-címéből és a belépési pont mögötti root-replikák IP-címeiből a DNS-sel karöltve könnyen irányíthatta a felhasználót egy olyan DFS roothoz, ami a klienssel azonos Site-on van. Azonos tartalmú DFS rootok különböző telephelyeken? Bizony, de ha az adott telephelyen lévő root nem érhető el, akkor még mindig ott a távoli – igaz, sokkal lassabban. Komoly változást hozott a Domain-Based DFS a célhelyek alternatíváinak kezelésében is: a File Replication Service, azaz FRS (NTFRS) segítségével meg 47

infrastruktúra lehetett tartani a különböző fizikai szerverek azonos adattartalmú területeinek konzisztenciáját. Hogy ez mennyire volt szoros,

4. ábra. A DFS a Fájlkiszolgáló-szerepkör egy szolgáltatása az már az FRS-en múlt, mindenesetre tette a dolgát. Mit tett a DFS, ha ezek az azonos tartalmú célhelyek különböző telephelyen voltak? Akárcsak a root kiválasztásakor, itt is az AD-ban definiált Site-struktúra döntött: a klienst – lehetőség szerint – a vele azonos telephelyen lévő cél felé irányította. Hát ez már egész jó, nem? Kell ennél több? Dehogy! Elkezdtük használni, és… és elég sokat bajlódtunk vele. No nem a DFS-sel magával, az rendben működött, hanem az a fránya FRS elég sok borsot tört az orrunk alá! Akár a root-replikáknál, de főleg a célhelyek közti replikációnál misztikus hibák fordulhattak elő, amelyekre sok esetben a „net stop ntfrs – net start ntfrs” volt a megoldás. Gond volt a teljesítménnyel és a kommunikáció megbízhatóságával is, az FRS nem különösebben modern módszerekkel dolgozik. És az időzíthetőség? Ha nem szeretném, hogy hétköznap napközben az FRS foglalja a telephelyeket összekötő vonal amúgy is szűkös áteresztőképességét? Vagy esetleg pont azt szeretném, hogy napközben biztosítsa a legszorosabb konzisztenciát? Igényként merült fel gyakran az is, hogy „de jó lenne DFS nélkül jól összereplikálni két szerveren adatterületeket, no és ha már úgyis itt van az FRS, nem lehetne esetleg vele?”

DFS a Windows Server 2008-ban A fent említett problémákra és igényekre mind van megoldás, itt, a Windows Server 2008-ban. Vegyük át a legfontosabb újításokat szépen sorjában! A DFS a Windows Server 2008 egy szerepköre (role), ami ennek 48

megfelelően telepítendő, bár első ránézésre nem is látszik, hiszen a File kiszolgáló-szerepkör része. Amit már a telepítés fázisában észrevehetünk, az az, hogy a klasszikus DFS-funkcionalitás és a Replikáció különkülön is kiválaszthatók. Számomra ez a klas�szikus DFS-konfiguráció nélküli fájlreplikáció lehetőségét jelenti, bár ez a Windows Server 2003 R2-ben volt újdonság. A DFS Managementben azután szemmel láthatóan külön kategóriát képviselnek a Névterek és a Replikáció. Névterek, namespaces. Lássuk, milyen lehetőségeink vannak, ha DFS-t szeretnénk kialakítani! Az első lépés talán egy kis fogalom-újraértelmezés, hiszen az új DFS-ben sok dolgot nem úgy hívnak, mint régen (lásd a táblázatot). Windows 2000; Windows 2003 DFS Root DFS Root Szerver DFS Root Szerver replika DFS Link DFS Link Replika

Windows Server 2008 = Namespace, azaz névtér = Namespace-szerver = Namespace-szerver = Folder Target = Folder Target

1. táblázat. Minek mi a neve? Az első lépés a névtér létrehozása, amelyben annak neve és legalább egy namespaceszerver megadása kötelező. Ezután következik a DFS típusa, tehát előttünk a döntéshelyzet. Lehet hagyományos Standalone, amely nem sokban különbözik a „ősi” DFS-változattól, a varázsló a failover clusterrel való integrálhatóságra felhívja ugyan a figyelmet, de ennek lehetősége – igaz, nem látszott a DFS konzoljából, csak a Cluster adminisztrációs felületéből – régebben is adott volt. Persze a Clusterre ebben az esetben szükség lehet, elsősorban akkor, ha a Root szerverünket – elnézést, a Standalone Namespace szerverünket szeretnénk hibatűrővé tenni. A másik lehetőség a Domain-Based névtér kialakítása, ami lehet „hagyományos” vagy Windows Server 2008 módú. Ez utóbbi egy jelentős újdonságot rejt, amelynek neve Access Based Enumeration. Mit is jelent ez? Segítségével elérhetjük, hogy felhasználóink a megosztáson belül csak azokat a könyvtárakat lássák, amelyeknek az eléréséhez valamilyen szintű jogosultsá-

guk van. Végre! Egy rendszergazda nap mint nap kénytelen magyarázkodni azoknak a felhasználóknak, akiknek nincs megfelelő joguk egy egyébként csábító nevű és feltehetőleg „roppant érdekes” tartalmú könyvtárhoz. Képzeljünk csak el egy, a publikus adatterületen, kizárólag a HR-csoport számára fenntartott „Tervezett Béremelések 2008-ban” nevű mappát! Hány sikertelen megnyitási kísérletet naplózhatnánk itt naponta? Ha ezt a mappát mindenképpen a közös elérésű területen kell tartani, hát nyissunk parancssort a name­ space-szer­ve­ren, és gépeljük be a „dfsutil property abde enable \\domainnév\name­ spacenév” utasítást, és a probléma egy csapásra megszűnik! Ott van ugyan a könyvtár, de a DFS felől közelítő felhasználók nem látják. Amiről nem tudunk, az nem fáj… – tartja a bölcs mondás. Windows Server 2008 módú Domain-Based DFS-t akkor készíthetünk, ha a Namespace-szervereink Windows Server 2008-at futtatnak, és az Active Directory domainünk funkcionalitási szintjét is átkapcsoltuk Windows Server 2008-ra. Ez természetesen kizár minden régebbi operációs rendszert futtató tartományvezérlőt a domainből, a lépést éles környezetben jól gondoljuk meg! Ott tartottunk, hogy megvan a Namespace és legalább egy Namespace-szerver is, jöhet a folderek kialakítása a névtér alatt! Az új fold­ er nevének megadásával a felhasználó által látható könyvtárnevet, míg a Folder Target definiálásával a célterületet határozzuk meg. Már most megadhatunk több Folder Targetet, amelyek a Domain-Based DFS esetén replikációs kapcsolatba kerülnek. Standalone DFS alatt a Folder Targetek hagyományosan nem replikálhatók? Dehogynem, most már bármikor beállíthatunk ebben az esetben is replikációt, de ne vágjunk elébe a dolgoknak. Ha Domain-Based Namespace alatt készítjük a foldert és a hozzá tartozó Folder Targeteket, a DFS itt is figyelembe veszi az AD és a DNS segítségével a kliens fizikai helyét, sőt ezt lehetőségünk van úgy finomítani, hogy a ­kliens számára esetleg nem is engedélyezzük a távoli site-on való célterület elérését. Új lehetőség továbbá a failback beállítása: ha a ­kliensünk a közeli Folder Target elérhetetlensége miatt egy távoli telephelyen lévő cél elérésére kényszerült, biztosíthatjuk számára az automatikus visszatérést, amennyiben a helyi, azaz preferált Folder Target ismét munkába állt. Ne felejtsük el, hogy az ügyfélgép DFS-kliens

infrastruktúra komponensét távirányítjuk, és ez cache-ben őrzi a tényleges célhelyeket. Lehetőségünk van a hivatkozások tárolási idejének módosítására is, amit akár a Namespace-en, akár az alá szervezett folder szintjén is megtehetünk. Hol is tartja a DFS a konfigurációt? Természetesen az Active Directory adatbázisban. A névtér-szerver ebből időről időre másolatot készít, amit helyben, XML formátumban tárol. Alapértelmezés szerint a DFS metadata publikációja is a PDC Emulátor szerepkörű DC-re hárul, ezen azonban módosíthatunk, elérhetjük, hogy a DFS name­ space-szerverünk ne az esetlegesen igen távoli PDC-t, hanem a legközelebbi DC-t faggassa a konfiguráció esetleges változásairól. Előbbit a konzisztenciára, utóbbit a skálázhatóságra optimalizált állapotnak hívjuk. Végül még egy apróság: a keresés lehetősége. Akármennyire is magától értetődő a funkció, eddig nem volt. Most, íme, rendelkezésre áll. Abba azért belegondolhatunk, hogy a fájlrendszerbe irányuló kereséseink általában egy adott gép adataiban kutatnak. És a DFS beépített keresése? Az bizony végrehajtja több gépen is, ahogy a folderek és a folder targetek megkívánják. Viszont az is igaz, hogy „csak” a keresett könyvtár megtalálására való.

A replikációs topológiák több séma és akár az egyéni elgondolások alapján is kialakíthatók. Időzíthetőség és sávszélességre való optimalizálhatóság jellemzi. „Staging folder” a változott állományok átmeneti tárolására, a „last writer wins” szabály, amiből adódó konfliktusokra egy „Conflict­And­Deleted” folder nyújtja a megoldást. A változások replikációja akár bitszintű lehet, a replikációs forgalom automatikusan tömörített. Nagymértékben leegyszerűsített a recov­ ery-mechanizmus, és van Standalone DFStámogatás. A valós lista ennél sokkal hosszabb, de így is belátható, hogy nem véletlenül került bele a DFS-R már a Windows Server 2003 R2-

DFS-replikáció, DFS-R

2. táblázat. A sebességnövekedésért felelős változtatások

Külön bekezdést kapott a DFS-replikáció és talán nem érdemtelenül. Eddig a Windows 2000-ben vagy a Windows Server 2003-ban egy legyintéssel elintézhettük volna: mi más intézhetné a replikációt, mint az FRS?! És most? Mi is? Hát a DFS! A Windows Server 2003 R2-ben és a Windows Server 2008-ban a DFS új szolgáltatással bővült, ez a DFS-replikáció. Mi lesz akkor az FRS-sel? Lassacskán felejtsük el, a DFS környezetében mindenképp. Egy fontos dolga az FRS-nek azért megmaradt, ez pedig az Active Directory Domain kontrollerek „SYSVOL” megosztásainak replikációja. Windows Server 2008-ban akár ezt a feladatot is átruházhatjuk a DFS-replikációra, bár nem kötelező. Mitől jobb a DFS-replikáció, mint az FRS? Ide egy olyan hosszú felsorolás kívánkozik, ami túlmutat az írás terjedelembeli lehetőségein, de a teljesség igénye nélkül: A DFS-R a DFS Management MMC konzolból konfigurálható. Replikációs csoportokba szervezhetők a közreműködők és az adatterületek. március

-április

Windows Server 2003 R2

Windows Server 2008

Multiple RPC calls

RPC Async Pipes

Synchronous inputs/outputs

Asynchronous I/Os

Buffered I/Os

Unbuffered I/Os

Normal Priority I/Os

Low Priority I/Os (terheléscsökkentés)

4 concurrent file downloads

16 concurrent file downloads

be is. Amiknek azonban igazán örülhetünk, azok a következő kérdésre adható válaszok: Mitől jobb a Windows Server 2008 DFSreplikáció, mint a DFS-R a Windows Server 2003 R2-ben? 1. Tartalomfrissesség-vizsgálat (Content Freshness). Szükség lehet erre az új tulajdonságra akkor, ha a replikációban részt vevő szerverek egyike nagyon hosszú ideig van „távol”, majd mikor ismét replikál, akkor már esetleg nem derül ki, hogy a rajta lévő adatok régen elavultak. Ha a Content Freshness nem lenne, a régi, elavult adatok a többi tagra visszaíródnának, illetve felülírhatnák az újabb változatokat. 2. A váratlan leállások kezelése. Az NTFS fájlrendszerben bekövetkező változások az esetek többségében először memóriában, átmeneti tárban helyezkednek el, és csak egy kis idő után íródnak le a fizikai lemezre. A DFS-R replikáció adatbázisának szempontjából viszont a változás már a diszkre írás előtt

megtörténik. A köztes időben bekövetkező bármilyen katasztrófa – legyen az váratlan szerverleállás, vagy szabálytalan volume-dismount – a DFS-R adatbázis inkonzisztenciájához vezethet. Míg a Windows Server 2003 R2 esetén ez a komplett DFS-R adatbázis újraépítésével és így rengeteg idővel járt, az új változat ezt az adatbázis újraépítése nélkül, azaz sokkal gyorsabban intézi el. 3. Sokkal gyorsabb replikáció. A Windows Server 2008 DFS-R elsősorban ebben jeleskedik. Mérhetően gyorsabban szinkronizál mind kisebb, mind nagyobb fájlok esetén, köszönhető ez a tömörítés mellett a hatékonyabb sávszélesség-kihasználásnak. 4. Report-képzés tesztállomány replikációjával (Propagation Report). A Windows Server 2003 R2-ben is meglévő reportok mellé diagnosztikai célból bekerült report, ami nem a valós adatállományok, hanem egy tesztállomány replikációjával kapcsolatos értékeket mutatja meg. 5. Az azonnali replikáció forszírozásának lehetősége (Replicate Now). Egy replikációs csoportban kijelölt célterületek közti replikációt indítja el, függetlenül annak időzítésétől. (SYSVOL replikációnál nem működik.) 6. A Read Only Domain Controller (RODC) támogatása. Miután a DFS-replikációba a tartományvezérlők SYSVOL-megosztása is belekeverhető, ebből az RODC sem maradhat ki. Itt viszont meg kell felelni az Active Directoryban definiált szabálynak, miszerint az RODC-ről nem származhat semmiféle változás vissza a többi, írható-olvasható adatbázisú DC-re. Ez alól a SYSVOL sem kivétel. Amennyiben a SYSVOL replikációját az FRS helyett a DFS-R végzi, ezt annak is figyelembe kell vennie! Meg is teszi, viszont ez nem érinti az RODC esetleges, a SYSVOL-tól különböző DFS-replikációs feladatait. Ezekre az adatterületekre kimenő és bejövő replikációs kapcsolatokat egyaránt beállíthatunk. Egy pillanat! Mi is hangzott el már többször? A SYSVOL replikációjának lehetősége? Igen, ez az a téma, ami talán egy kicsit összetettebb annál, semmint hogy egy mondatban elintézzük. Nézzünk a körmére ennek az új lehetőségnek!

A SYSVOL és a DFS-replikáció kapcsolata Mint ahogy már ebben a cikkben is többször szó volt róla, a tartományvezérlők SYSVOL 49

infrastruktúra könyvtárainak egyezőségéről alapértelmezés szerint az FRS szolgáltatás gondoskodik, már a Windows 2000 óta. Nincs ez másként a Windows Server 2008-ban sem, viszont az FRS fölött sok szempontból eljárt az idő. Miért nem a DFS-R az alapértelmezés? Talán azért, mert a Windows Server 2008-as tartományvezérlőkből kialakított domain egyéb rendelkezés híján nem zárja ki az esetleges régebbi (2000; 2003) Domain Controllereket sem. Ezek viszont eléggé meglepődnének, ha a SYSVOL ettől kezdve DFS-R módszerrel érkezne… Ha a SYSVOL replikációját a DFS-Rre szeretnénk bízni, első lépésként emeljük a tartomány funkcionalitási szintjét Windows Server 2008-ra! Igen ám, de ettől még mindig marad az FRS, ez csupán a lehetőséget teremti meg az átállásra. Akkor telepítsünk a tartományvezérlőkre DFS-replikációt! Megvan? Így már majdnem kész vagyunk, de még mindig a régi módon replikálunk. Hogyan tovább? Az FRS-ről DFS-R-re való áttérés egy migrációs folyamat, amelyet kellő körültekintéssel – és ami a legfontosabb – fokozatosan végezzünk! Megjelent a Windows Server 2008-ban egy parancssori segédeszköz, a dfsrmig.exe. A neve beszédes, két fő funkciója a migráció állapotának lekérdezése és változtatása. Vigyázzunk vele, mert használata minden tekintetben globális eredménnyel jár: bármelyik DC-n kiadjuk a megfelelő jogosultsággal, az egész tartományt érintő változtatást jelent. Tehát, amennyiben a fenti feltételeknek megfeleltünk, elkezdhetjük a migrációt. Gépeljük be a parancssorba a „dfsrmig /getglobalstate” utasítást, és láthatjuk, hogy a migráció státusza „start”. Ez még igazából semmit nem jelent, a SYSVOLreplikációt az FRS végzi. Milyen státuszok lehetségesek (lásd a táblázatot)? 0

START

1

PREPARED

2

REDIRECTED

3

ELIMINATED

3. táblázat. Migrációs állapotok A cél természetesen az „Eliminated” állapot elérése, de csak ésszel, óvatosan. Következhet a „dfsrmig /setglobalstate 1” utasítás, amelynek hatására a migráció állapota mostantól „prepared”. Most a DFS-R készít magának egy másolatot a SYSVOL mappáról, majd 50

egy másik DC DFS-R szervizével megpróbál egy úgynevezett iniciális rep­li­ká­ciót végrehajtani. Sikerült az összes tartományvezérlőn? Kérdezzük le a „dfsrmig /getmigrationstate” paranccsal! Tegyük fel, hogy a visszajelzés pozitív. Álljunk át a fent említett módszerrel a 2-es, azaz a „redirected” szintre! Mi is történik éppen? A tartományvezérlőkön futó DFS-R szervizek magukhoz ragadták a SYSVOL replikációjának feladatát, de az FRS még ugyanúgy teszi a dolgát, ahogy ré-

5. ábra. A régi és az új egymás mellett: migráció közben

adatbázist – persze üres, a SYSVOL-rep­li­ká­ ciós kényszerét nem tartalmazó változatot.

A replikáció beállításai Ha a replikációs csoportokat megvizsgáljuk a DFS Management konzolban, láthatjuk, hogy azok kialakítása roppant egyszerű – már ha nekünk kell egyáltalán kialakítani azokat. A Domain-Based DFS replikációs feladatai és a SYSVOL-replikáció, amennyiben migráltunk rá, automatikusan bekerülnek a konzolba. Igény szerint ezeknek a paramétereit, azaz topológiáját és időzítését, sőt a szereplőket és a replikálandó adatterületeket is megváltoztathatjuk. Kikényszeríthetjük az azonnali replikációt is, az időzítéstől függetlenül. Nem igaz ez a SYSVOL replikációjára, amit bár látunk a replikációs csoportok között, különösebben konfigurálni nem tudunk, de ez érthető. Van egy probléma, amin azért el kell gondolkodni: az egyirányú replikáció. Ha két adatterületet replikációs kapcsolatba hozunk, azok automatikusan oda-vissza továbbítják a változásokat. Az esetek többségében ez pont megfelelő, de vegyünk elő gondolatban egy „Main office-Branch office” scenariót! A Branch office, tegyük fel, csak olvasható változatot kaphat egy, a Main office telephelyén elhelyezett könyvtárstruktúrából. Mit csinál-

gen. Párhuzamosan működik mindkét rendszer! Gyors állapotlekérdezés, megnyugodhatunk, ha tényleg így van. Most következik a legfontosabb döntés: a harmadik szint, azaz az „eliminated” forszírozása. 1-es vagy 2-es szintről bármikor vissza lehet lépni, bűnbánóan az FRS elé állni és megkérni, hogy folytassa mégis csak ő a SYSVOL-repliká­ciót – „eliminated” szintről nincs visszatérés! Ha az állapotjelzés („dfsrmig /getmigration­state”) kedvező, belevághatunk. Forszírozzuk a 3-as szintet, és lekérdezzük az állapotot: minden OK! Mi is történt? A DFS-R letörölte az eredeti SYSVOL-t és annak másolatával, a SYSVOL_DFSR könyvtárral operál a továbbiakban. Eseménynapló, a DFS log biztató bejegyzésekkel tele, hátradőlhetünk. Viszont, ha már az esemény6. ábra. A megijedt FRS-szolgáltatás kiabál naplóban járunk, pillantsunk csak rá az FRS naplójára! A helyzet ijesztő, legjunk? Fizikailag nagyon könnyen letiltható, alábbis az FRS nagyon meg van ijedve: nem de ez nem várt problémákat okozhat. Tegyük leli a replikálandó SYSVOL mappát! Bár mi fel, hogy a Branch office-ban a helyi admitudjuk, hogy ez nem igazán baj, de hogy lenisztrátor letörli X könyvtárat. Másnap a hetne ezt az FRS-nek is elmondani? Két leMain office-ban módosítanak egy fájlt X-ben. hetőség van, egyik sem túl elegáns: vagy leálMi lesz? A Branch office szerverének DFS-R lítjuk és „manual” indítási módba tesszük az adatbázisa szétesik, ilyen esetekre nincs még ntfrs-szervizt, vagy (gondolva arra, hogy tafelkészítve. Javaslat: a Branch office szervelán valamikor valamiért még szükségünk lesz rén gondoskodjunk megosztási lehetőségről rá –nem tudnám ugyan megmondani, miért és NTFS-permissziókkal az írás és módosítás is lenne) a szerviz ideiglenes leállítása mellett tiltásáról. A replikációt pedig hagyjuk inkább kitöröljük a Jet adatbázisát a %systemroot%\ úgy, ahogy létrejön – kétirányúnak. ntfrs\jet alól. Ebben az esetben az újrainduSzékács András ló NTFRS létrehoz magának egy teljesen új ([email protected]) MCSE, MCTS, MCT, Számalk