A Distributed File System rejtelmei
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, amiben több tucat szerver több telephelyen tárolja felhasználók százainak, vagy akár ezreinek adatait.
Eddig 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 is 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, amiben 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, ami az adatközponttal csak egy jóféle 512kbit/sec-es kapcsolattal bír. Míg egy-egy 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.
A DFS replikációjának időzítése
Itt kap szerepet az a szolgáltatás, amit névről ismerhetünk már a Windows NT-s 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 ezen írás nem a múltba igyekszik tekinteni, nézzük meg, hogy milyen környezetet alakíthattunk ki DFS-el 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. A felhasználóknak, akiknek nem megfelelő a jelenlegi adatszervezés, mutassunk egy olyan adatstruktúrát, ami ugyan nem valós, de mutatókat, pointereket tartalmaz a valós adathelyekre. Ideális megoldás, hiszen az adatot a jelenlegi helyéről elmozdítani nem kell (sokaknak pont úgy jó, ahogy van), de láttathatjuk úgy, mintha átcsoportosítottuk volna azokat.
Hogyan is néz ki ez a gyakorlatban? Legyen szerver A és B a két tényleges fájlszerver. Mindkettőnek számtalan megosztása van, köztük A-nak Dokumentumok1 és B-nek Doukumentumok2. Egy adott felhasználó kénytelen tudatosan csatlakozni mindkét szerverhez, sőt annak konkrét share-jeihez és az általa használt dokumentumokat erről a két helyről megnyitni. Ha szeretnénk számára leegyszerűsíteni az elérést, vegyük elő szerver Z-t és jelöljük ki DFS root-nak! A DFS root nem lesz más mint egy olyan "megosztott könyvtár", melynek tartalmát képző alkönyvtárak nem (feltétlenül) valósak, csak pointerek, jelen esetben szerver A Dokumentumok1 és szerver B Dokumentumok2 megosztásaira mutatnak.
A Standalone DFS architektúrája
Tetszőleges mennyiségű pointert helyezhetünk el a DFS root alatt, melyek 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 alternatívákat is a cél tekintetében, azaz ha szerver C Dokumentumok1 megosztása ugyanazzal az adattartalommal bír, mint szerver A Dokumentumok1, akkor a hibatűrés és a terhelésmegosztás jegyében a DFS root alatti "könyvtár" mindkét helyre egyaránt mutat. Ezt a DFS a kliens gép számára listaként, mintegy folyamatosan változó sorrendiséggel közvetíti, tehát nagy szá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 kliens gép DFS ügyfélkomponensének üzen, aki 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 dokumentumokkal az azonos tartalmú célhelyeken? Ha szerver A Dokumentumok1-ben módosítunk, az eljut valahogy szerver C Dokumentumok1-be? Sajnos nem. Stand Alone DFS esetén ( hangsúlyozom, hogy nem a Windows szerver 2008-ban található DFS-ről van szó!), a célhelyek csak olvasható dokumentumokkal 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 a Windows 2000 és az Active Directory megjelent, 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 root-unk 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 root-ot akartuk elérni. Az AD felkínált nekünk egy olyan belépési pontot, amely egy igen furcsa UNC path: \domainnévdfsrootné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 root-hoz, ami a klienssel azonos Site-on van. Azonos tartalmú DFS root-ok különböző telephelyeken? Bizony, de ha az adott telephelyen lévő root nem elérhető, 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 lehetett tartani a különböző fizikai szerverek azonos adattartalmú területeinek konzisztenciáját. Hogy ez mennyire volt szoros, 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.
Az Active Directory integrált DFS architektúrája
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, az 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ő, melyekre 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 estleg 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?"
[oldal:Distributed File System 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 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ön-külön is kiválaszthatóak. Számomra ez a klasszikus 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 Management-ben azután szemmel láthatóan külön kategóriát képviselnek a Névterek és a Replikáció.
A DFS a Fájlkiszolgáló szerepkör egy szolgáltatása
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.
| Windows 2000 / Windows Server 2003 | Windows Server 2008 |
| DFS Root | Namespace, Névtér |
| DFS Root szerver | Namespace szerver |
| DFS Root szerver replika | Namespace szerver |
| DFS Link | Folder target |
| DFS Link replika | Folder target |
Az első lépés a névtér létrehozása, melyben annak neve és legalább egy namespace szerver meagadása kötelező. Ez után következik a DFS tipusa, tehát előttünk a döntéshelyzet. Lehet hagyományos stand-alone, 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, melynek neve Access Based Enumeration. Mit is jelent ez? Segítségével elérhetjük, hogy a felhasználóink a megosztáson belül csak azokat a könyvtárakat lássák, amiknek az eléréséhez valamilyen szintű jogosultságuk van. Végre! Egy rendszergazda nap, mint nap kénytelen magyarázkodni azon 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 namespace szerveren és gépeljük be a "dfsutil property abde enable \domainnévnamespacenév" utasítást és a probléma egycsapásra megszűnik! Ugyan ott van 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-unk 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 domain-bő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 kialaikítása a névtér alatt! Az új folder 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, melyek 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 a dolgoknak elébe. Ha Domain-based Namespace alatt készítjük a foldert és a hozzá tartozó folder tartgeteket, 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, bitosí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él gép DFS kliens komponensét távirányítjuk, aki 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 namespace 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? Ő 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ó.
DFS Replikáció, DFS-R
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. Hogy ez a jövőben is így marad-e, az csak rajtunk múlik – 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 ezen írás terjedelembeni 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 adatterületek.
- A replikációs topológiák több séma és akár az egyéni elgondolások alapján is kialakíthatóak.
- 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 "ConflictAndDeleted" folder nyújtaja a megoldást.
- A változások replikációja akár bit-szintű lehet, a replikációs forgalom automatikusan tömörített.
- Nagy mértékben leegyszerűsített a recovery mechanizmus és van Standalone DFS tá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-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 DFS Replikáció, mint a DFS-R a Windows Server 2003 R2-ben?
- 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.
- 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ázisa szempontjából viszont a változás már a diszkre írás előtt bekövetkezik. A köztes időben bekövetkező bármilyen katasztrófa, legyen az váratlan szerverleállás, vagy szabálytalan volume-dismount, az 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.
- 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. Egy táblázatba foglalva a sebességnövekedésért felelős változtatásokat:
Windows Server 2003 R2 Windows Server 2008 Több RPC hívás Aszinkron RPC csövek Szinkrton I/O Aszinkron I/O Pufferelt I/O Nem pufferelt I/O Normál prioritású I/O Alacsony prioritású I/O (terheléscsökkentés) 4 párhuzamos fájlletöltés 16 párhuzamos fájlletöltés
- 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.
- 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)
- Read Only Domain Controller (RODC) támogatás: 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 Directory-ban 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 neki 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!
[oldal: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 könyvtárainak egyezőségéről alapértelmezés szerint az FRS szolgáltatás gondoskodik, már 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 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-R-re 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, amit 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 SYSVOL replikációt az FRS végzi. Milyen státuszok lehetségesek?
Migrációs státuszok
| 0 | START |
| 1 | PREPARED |
| 2 | REDIRECTED |
| 3 | ELIMINATED |
A cél természetesen az "Eliminated" állapot elérése, de csak ésszel, óvatosan. Következhet a "dfsrmig /setglobalstate 1" utasítás, minek 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 egy másik DC DFS-R szervizével megpróbál egy úgynevezett iniciális repliká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ánnyvezé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é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 /getmigrationstate") kedvező, belevághatunk. Forszírozzuk a 3-as szintet, és lekérdezzük az állapotot: minden OK!
A régi és az új egymás mellett: migráció közben
Mi is történt? A DFS-R letörölte az eredeti SYSVOL-t és annak másolatával, a SYSVOL_DFSR könyvrá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énynaplóban járunk, pillantsunk csak rá az FRS naplójára! A helyzet ijesztő, legalábbis az FRS nagyon meg van ijedve: nem leli a replikálandó SYSVOL mappát! Ugyan mi tudjuk, hogy ez nem igazán baj, de hogy lehetne ezt az FRS-nek is elmondani? Két lehetőség van, egyik sem túl elegáns: vagy leállítjuk és "manual" indítási módba tesszük az ntfrs szervizt, vagy (gondolva arra, hogy talán valamikor valamiért még szükségünk lesz rá -- ugyan nem tudnám megmondani miért is lenne) a szervíz ideiglenes leállítása mellett kitöröljük a Jet adatbázisát a %systemroot%ntfrsjet alól. Ebben az esetben az újrainduló NTFRS létrehoz magának egy teljesen új adatbázist -- persze üres, a SYSVOL replikációs kényszerét nem tartalmazó változatot.
A megijedt FRS szolgáltatás kiabál
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ő. Az általunk létrehozott replikációs csoport, ami akár független is lehet bármelyik névtértől, azaz nem publikált, jellemzőit akár készítéskor, akár utólag beállíthatjuk.
Van egy probléma, amin azért gondolkodjunk el: 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” scenario-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áljunk? Letiltsuk a replikáció megfelelő irányát? Le lehet, fizikailag nagyon könnyen elkövethető, de nem várt problémákat okozhat. Tegyük fel, hogy a Branch office-ban a helyi adminisztrátor letörli X könyvtárat. Másnap a Main office-ban módosítanak egy fájlt X-ben. Mi lesz? A branch office szerverének DFS-R adatbázisa szétesik, ilyen esetekre nincs még felkészítve. Javaslat: a Branch office szerverén gondoskodjunk megosztási és NTFS permissziókkal az írás és módosítás tiltásáról. A replikációt pedig hagyjuk inkább úgy, ahogy létrejön -- kétirányúnak.
Székács András
MCSE, MCTS, MCT, Számalk