www.SAMURAJ-cz.com 

16.12.2017 Albína Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Popis DFS a migrace na Windows Server 2008 mode

Středa, 14.09.2011 17:52 | Samuraj - Petr Bouška |
Distributed File System (DFS) je velice užitečná služba, které zařizuje několik funkcí. Principem je zjednodušení přístupu ke sdíleným adresářům a navíc zařizuje rozklad zátěže a vysokou dostupnost. Spolu s Windows Server 2008 došlo k rozšíření a úpravě DFS. Předpokládal jsem, že se tyto nové funkce začnou automaticky používat, když bude DFS na novém serveru, ale bohužel to tak není. Je potřeba převést namespace do nového módu a to dost nepohodlným postupem. Největší problémy jsou s replikacemi.

Distributed File System

DFS zajišťuje konsolidaci různých síťových úložišť pod jednu adresu. Můžeme mít i více serverů, které hostují stejná data a DFS pak řeší load balancing a vysokou dostupnost. Další vlastností jsou replikace, které zajistí synchronizaci dat na více serverů a případně i na více lokalit. U replikací můžeme určovat šířku pásma, která se použije v různé denní době. DFS se stalo součástí Windows Serveru již ve verzi 2000. Na klientovi je také potřebná podpora DFS, která je součástí MS OS již od Windows NT 4.0.

DFS se tedy skládá ze dvou částí DFS Namespaces (DFSN) a DFS Replication (DFSR). Dříve se místo DFSR používalo horší FRS (File Replication Service). Běžně používaná je verze domain-based namespace (druhá možnost je standalone namespace), kdy je konfigurace uložená v Active Directory a k sdíleným složkám se přistupuje pomocí \\jmeno.domeny\dfsroot\folder. Dále budeme mluvit o domain-based DFS na Windows Server 2008 R2. Pro správu se používá snapin DFS Management nebo řádkový příkaz dfsutil.

DFS Management

Konfigurace DFS se ukládá do Active Directory, dále potřebujeme jeden nebo více (pro vysokou dostupnost určitě) Namespace Server, které udržují informace o struktuře (sdílení).  Automaticky se využívá informace o Site a podle toho se klient připojuje k serveru. Poslední částí jsou vlastní souborové servery (Target), kde jsou uložena data.

Struktura je taková, že vytvoříme Namespace (identifikovaný pomocí jména = dfsroot), který se klientům tváří jako standardní sdílená složka, uvnitř vytváříme složky (Folders) a ty můžeme napojit na cílové servery jako Folder Target.

Údaje o DFS se ukládají na několik míst

  • Active Directory - konfigurace namespace (namespace servers, folder targets, konfigurace)
    • DFS Namespaces - CN=Dfs-Configuration,CN=System,DC=domena,DC=local
    • DFS Replication - CN=DFSR-GlobalSettings,CN=System,DC=domena,DC=local
  • registrech na Namespace serveru (členství namespace) - HKEY_LOCAL_MACHINE\Software\Microsoft\Dfs\Roots\domainV2
  • na disku na Namespace serveru (spravuje shares) v defaultní cestě C:\DFSRoots

Převod DFS do nového módu

Abychom mohli používat 2008kový mód, tak musí být splněny následující podmínky:

  • funkční stupeň domény minimálně Windows Server 2008
  • všechny namespace servery musí běžet alespoň na Windows Server 2008

Aktuální typ DFS zjistíme, když klikneme pravým tlačítkem na Namespace a zvolíme Properties, pak na záložce General vidíme položku Type, ta může být:

  • Domain (Windows 2000 Server mode) – tak se dodatečně pojmenovala původní verze
  • Domain (Windows Server 2008 mode) – nová verze
DFS Type

Bohužel nelze změnit pouze nějaké nastavení a dosáhnout tak nového módu (jako například u funkčního stupně domény). Ale musí se provést export, smazání, nové vytvoření (v novém módu) a import. Postup, jak přejít na 2008 mód je pospaný v MS článku Migrate a Domain-based Namespace to Windows Server 2008 Mode. Pro import a export musíme využít řádkový příkaz dfsutil. Ostatní operace můžeme provádět v grafickém DFS Management.

  • z příkazové řádky (pod dostatečnými právy) provedeme export namespacu do soubor
    Dfsutil root export \\domain.local\namespace soubor.xml
  • musíme si zapamatovat či zapsat Namespace Servers a jméno vlastního Namespace (dfsroot)
  • v DFS Management smažeme Namespace, dostaneme dotaz, jestli chceme smazat replikace, to asi nechceme, více dále
  • pomocí průvodce vytvoříme znovu Namespace, zadáváme první Namespace Server a jméno (dfsroot), musí být zatržené Enable Windows Server 2008 mode
  • provedeme import pomocí příkazu
    Dfsutil root import merge soubor.xml \\domain.local\namespace
  • přidáme další Namespace Server

Převod DFS a replikace

Pozn.: Vycházím z toho, že již používáme DFSR a ne FRS.

Když budeme po převodu kontrolovat stav DFS, tak zjistíme nepříjemnou věc. Které jsme si mohli všimnout již při exportu, pokud jsme otevřeli exportovaný XML soubor, ten totiž neobsahuje žádné informace o replikacích. Když se podíváme na nějaký adresář v Namespace, tak na záložce Replication není nic (Not configured). Stejně tak u Replication Group na záložce Replicated Folders je napsáno Not Published.

Replication status
Replicated Folders

Když zkontrolujeme replikace, tak zjistíme, že fungují v pořádku. Ono totiž DFSN a DFSR může fungovat (a funguje) samostatně a nezávisle na sobě. Pokud u Namespace klikneme na Replicate Folder Wizard, tak dostaneme chybu, že replikační skupina již existuje.

Očividně chybí jen informace, že tento namespace patří k této replikační skupině. Prohledal jsem internet a našel jsem informaci, že u Replication GroupActive Directory je atribut, kde je uvedena cesta k namespace. Tam ji můžeme ručně zadat, například pomocí Active Directory Users and Computers se zapnutými Advanced Features (nebo ADSI Edit).

  • proklikáme se skrze doménu, System, DFSR-GlobalSettings, naše replikační skupina, Content
  • tam vidíme objekt naši skupinu, zvolíme Properties a záložku Attribute Editor
  • nalezneme atribut msDFSR-DfsPath, kterému můžeme zadat cestu (\\domena\dfsroot\folder)
Atribut msDFSR-DfsPath

Když se nyní znovu podíváme do DFS Management (a případně dáme Refresh), tak již vidíme správně replikace u namespace i stav Published to namespace u Replication Group.

Zdálo by se tedy, že je vše v pořádku. Ale pokud u nějakého Namespacu zvolíme Delete na jednom Folder Target, tak se zobrazí pouze jeden potvrzující dialog a target je smazaný. Replikace se to přitom nedotkne a ta zůstane stále mezi všemi členy. Pokud chceme odstranit server i z Replication Group, tak to musíme udělat u replikací.

Remove Folder Target

Pokud ale normálně vytvoříme namespace i s replikací, tak se při smazaní jednoho Folder Target zobrazí další dialog s dotazem, jestli chceme smazat i člena replikační skupiny. Očividně tedy chybí ještě nějaká vazba, ale o co jde, se mi nepodařilo nalézt. Vše ale vypadá funkčně, pouze musíme provádět samostatně některé úpravy členů pro DFSR a DFSN. Ale při přidání nového Folder Target se nabídne vytvoření replikací (a korektně provede) nebo při mazání celého Folder se správně nabídne i smazání replikační skupiny.

Remove Folder Target and Replication member

Přemýšlel jsem ještě o tom, když mám na dvou serverech replikovaná data a zruším replikační skupinu a znovu ji vytvořím, co se stane. V praxi to vypadá (podle logů), že se nějakým způsobem nastartuje kompletní replikace (na složce o pár desítkách gigabytů trvala několik hodin). Takže to není vhodné řešení.

Kdy se projeví změny v replikacích

Replikace DFS nezačne hned, členové si nejprve musí stáhnout novou konfiguraci z Active Directory. Prvně musí dojít k replikaci mezi jednotlivými doménovými kontrolery (DC) a pak si musí jednotlivé DFSR servery stáhnout konfiguraci z AD. Pokud provádíme některé změny v replikacích, tak můžeme potřebovat, aby se změny projevili hned, abychom mohli pokračovat dalším krokem (třeba při odstranění replikačního serveru, než na něm smažeme danou složku).

Replikaci AD můžeme vyvolat třeba pomocí Active Directory Sites and Services (na NTDS Settings u jednotlivých serverů v sites) nebo příkazu repadmin (voláme postupně pro všechny DC).

repadmin /syncall <jmeno-dc> /e /d /A /P /q

Stažení konfigurace pro jednotlivé členy můžeme vyvolat příkazem dfsrdiag. Je potřeba spustit postupně pro všechny servery, které replikují data (členové replikační skupiny, tedy ti kdo hostují data).

dfsrdiag PollAD /Member:<jmeno-serveru>

Když mluvíme o replikacích, tak jako další můžeme provést Migrace replikací SYSVOLu z FRS na DFSR.

ID události v logu

Události o DFS replikacích se zapisují do samostatného logu DFS Replication, který můžeme standardně otevřít v Event Viewer. Pár zajímavých událostí, když hledáme začátek a konec úvodní replikace.

Event ID 4104 na členském serveru
The DFS Replication service successfully finished initial replication on the replicated folder at local path <…>.

Event ID 4002 na členském serveru
The DFS Replication service successfully initialized the replicated folder at local path <…>.

Event ID 4112 na primárním serveru
The DFS Replication service initialized the replicated folder at local path <…>. This member is the designated primary member for this replicated folder.

DFS a Access-Based Enumeration

Jednou z novinek DFS ve Windows Server 2008 mode je Access-Based Enumeration pro DFS. Access-Based Enumeration je příjemná vlastnost, kterou můžeme doinstalovat do Windows Server 2003 a je součástí Windows Server 2008, pro sdílené složky (share). Zajišťuje, že uživatel nevidí složky, na které nemá oprávnění. U klasických sdílených složek se prostě zapne na daný share a pak se využívá Security oprávnění na složkách a podle toho se uživatelům zobrazují.

U DFS by Access-Based Enumeration mělo zajistit skrytí složek (Folders) na úrovni DFS. Myšlenka dobrá, ale připadá mi, že je to uděláno dost nepohodlně. Problém je, že v DFS vytváříme strukturu Namespace pomocí Folders, ta se uloží na Namespace serverech. Když zobrazíme DFSroot, tak se zobrazí tato struktura a v tuto chvíli se použijí práva, která jsou nastavena na složky na Namespace serveru (ne na fileserveru) v C:\DFSRoots, což jsou defaultně práva děděná z disku a tam je právo čtení pro Domain Users. Když otevíráme nějakou složku, na které je Folder Target, tak se provede přesměrování a nyní se vyhodnocují práva (security) nastavená již na skutečné složce na fileserveru.

Pokud na DFS Namespace zapneme Access-Based Enumeration, tak se běžně nic nestane, protože pro zobrazení se vyhodnocují práva ze struktury na Namespace serveru. Aby vše začalo fungovat, tak musíme projít jednotlivé Foldery a ručně nastavit práva. Práva, která zde nastavíme, se použijí pouze pro zobrazení, nikoliv pro řízení přístupu (takže i když takto zneviditelníme složku, tak pokud uživatel zná cestu a má tam oprávnění, tak ji otevře). Nastavení práv provedeme následovně:

  • klikneme pravým tlačítkem na Folder, zvolíme Properties
  • přepneme se na záložku Advanced a nastavíme přepínač na Set explicit view permissions on the DFS folder
  • klineme na tlačítko Configure view permissions
  • zde nastavíme práva skupině nebo osobám, které mají složku vidět
DFS - View Permissions

DFSUTIL na klientovi

Řádkový příkaz dfsutil můžeme použít nejen pro konfiguraci namespace či serveru, ale také pro operace na klientovi. Na Windows 7 příkaz doinstalujeme z feature RSAT (Remote Server Administration Tools) pod částí Distributed File System Tools.

Zobrazení informací v keši klienta (namespace, jména serverů, aktivní server):

dfsutil /pktinfo

Smazání lokální keše (odkazy na servery Folder Targets) :

dfsutil /pktflush

Zobrazí informace o doménách a kontrolerech:

dfsutil /spcinfo

Donutí klienta aktualizovat informace o doménách:

dfsutil /spcflush
zobrazeno: 11628krát | Komentáře [8]

Autor:

Související články:

Computer Storage

Ukládání dat je v počítačovém světě rozsáhlá a komplexní problematika. Zde se nachází články, které se věnují sítím Storage Area Network (SAN), technologiím iSCSI, Fibre Channel, diskovým polím (Storage System, Disk Srray) i obecně ukládání dat a úložištím.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

  1. [1] Vladimír Dlesk

    Dobrý den pane Bouška, mám dotaz který se přímo nevztahuje k tématu migrace DFS, ale nasazuji nyní DFS na doméně 2003 a narazil jsem na problém vzájemného přepisování současně otevřeného souboru ve více lokalitách. Kdo poslední soubor uloží ten tam zůstane.. Neřešil jste někdy tento problém a nemáte případně nějaký tip, jak by se to dalo elegantně vyřešit? Konflikt se sice uloží do konfliktního adresáře, ale měl bych představu něco jako zámek nebo tak něco.. Děkuji za Váš čas a případnou odpověď.

    Pondělí, 17.09.2012 09:52 | odpovědět
  2. [2] Samuraj

    odpověď na [1]Vladimír Dlesk: Bohužel DFS neobsahuje žádnou technologii pro File Locking, což může být často problém. Já v praxi používám DFS hlavně jako zálohovací mechanismus. Nevím, jaká je MS idea práce nad stejnými daty. Snad existují nějaké aplikace třetích stran, ale nikdy jsem nezkoušel.

    Pondělí, 17.09.2012 18:47 | odpovědět
  3. [3] Tomas

    Dobrý den,

    máme DFS na 2003, ale naše LAN/WAN síť je momentálně celosvětová. Řeším otázku toho, jak vlastně v základu funguje při přístupu k jednotlivým zdrojům/sdíleným složkám na reálných serverech. Prakticky myslím následující: sedím v Praze, reálný server je také v Praze, ale složka je mapovaná přes DFS server, který je v německém Frankfurtu. Když spustím kopírování od sebe do té složky, potečou data už skutečně přímo mezi mnou a cílovým "reálným" serverem nebo stále prostřednictvím DFS, a tedy přes Frankrurt?

    Středa, 07.11.2012 15:47 | odpovědět
  4. [4] Samuraj

    odpověď na [3]Tomas: Taková malá rada. Najděte si nějaký adresář, který je přístupný přes DFS a klikněte pravým tlačítkem. Potom zvolte Properties a přepněte se na záložku DFS. Tady uvidíte na jaký fyzický server přistupujete.

    Jinak přes DFS se data nekopírují ani nezpracovávají.

    Středa, 07.11.2012 15:56 | odpovědět
  5. [5] Tomas

    odpověď na [4]Samuraj: ... znamená to, že jak můj klient tak server poté naváží komunikaci jen sami se sebou?

    Za radu díky ... obávám se však, že naši outsourcingoví inženýři z Německa využívají nějaký advanced skill. Já samozřejmě vím o této funkci, neb nejsem adminem krátce, ale i zde je uveden zase jen DFS server. Bohužel má práva mi nedovolí otevřít nastavení DFS serveru a zkontrolovat to přímo. Nicméně přiznávám, že zkrátka nevím jak skutečně DFS zajišťuje navázání komunikace mezi přistupujícím klientem a připojeným serverem.

    Jen pro dokreslení, pokud pingnu na ten DFS server, dostanu navíc pokaždé jinou adresu. Jednou Fra, jindy New York, Sankhai ... je to fakt mazec a protože nevěřím tomuhle spatlanému designu, pídím se po tom, jak vlastně DFS funguje a zda není právě tento model tím hlavním, co nám brzdí všechny stroje.

    Středa, 07.11.2012 18:27 | odpovědět
  6. [6] Tomas

    ještě poznámka ... název toho DFS serveru je zároveň názvem domény. Jak je tohle udělaný, si nějak nedokážu představit. V každém případě pokud máte real server SERVER.MOJE.DOMENA.COM\SHARE$, tak náš DFS server, přes kterej máme namapované všechny síťové disky je \\MOJE.DOMENA.COM\jiny_share

    ... chytáte to? Já ne.

    Středa, 07.11.2012 18:36 | odpovědět
  7. [7] Samuraj

    odpověď na [5]Tomas: Když to napíšu zjednodušeně. Informace o DFS jsou uloženy v Active Directory, proto je k nim přístup přes doménu nebo doménový kontroler. DFS obsahuje pouze odkazy na fyzická úložiště, nic víc. Takže já si pouze z ADčka načtu konfiguraci z Namespace serveru (to je ten DFS server) seznam a když otvírám některou z těchto složek, tak již přistupuji na určitý fyzický server. Můžu těch serverů pro jednu složku mít více a pak se použijí určitá pravidla, který server se upřednostní.

    Ale tohle vše jsem popsal v článku.

    A také nevím, jak by se dalo zařídit, aby se na záložce DFS zobrazoval Namespace server místo fyzického Fileserveru.

    Čtvrtek, 08.11.2012 10:06 | odpovědět
  8. [8] Michael

    odpověď na [7]Samuraj: Trosku out-of-date diskuze, ale třeba někomu pomůže...

    by se na záložce DFS zobrazoval Namespace server místo fyzického Fileserveru.

    To lze úplně jednoduše - DFS link může mít v targetu DFSroot share, tzn., že další dfs level leží na jiném DFSN serveru (stanalone v HA).

    Neděle, 28.06.2015 21:11 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách