Distribuovaný systém souborů v systému Windows 7. Distribuované systémy souborů. Zabezpečení souborů a složek
Klíčovou součástí každého distribuovaného systému je souborový systém. Stejně jako v centralizovaných systémech je v distribuovaném systému funkcí souborového systému ukládat programy a data a poskytovat k nim přístup podle potřeby. Souborový systém je udržován jedním nebo více počítači nazývanými souborové servery. Souborové servery zachycují požadavky na čtení nebo zápis souborů z jiných počítačů (nikoli ze serverů). Tyto další stroje se nazývají klienti. Každý odeslaný požadavek se ověří a provede a odešle se zpět odpověď. Souborové servery obvykle obsahují hierarchické systémy souborů, z nichž každý má kořenový adresář a více adresářů. nízké úrovně. Pracovní stanice může připojit a připojit tyto systémy souborů ke svým lokálním systémům souborů. V tomto případě zůstávají připojené souborové systémy na serverech.
Je důležité pochopit rozdíl mezi souborovou službou a souborovým serverem. Souborová služba je popis funkcí, které souborový systém nabízí svým uživatelům. Tento popis zahrnuje dostupná primitiva, jejich parametry a funkce, které provádějí. Z pohledu uživatele souborová služba definuje, s čím mohou uživatelé pracovat, ale neříká nic o tom, jak je implementována. Souborová služba v podstatě definuje rozhraní souborového systému s klienty.
Souborový server je proces, který běží na samostatném počítači a pomáhá implementovat souborovou službu. Systém může mít jeden nebo více souborových serverů, ale v dobře organizovaném distribuovaném systému uživatelé nevědí, jak je systém souborů implementován. Zejména neznají počet souborových serverů, jejich umístění a funkce. Vědí pouze, že pokud je ve spisové službě definován postup, tak se požadovaná práce nějak vykoná a požadované výsledky se jim vrátí. Uživatelé navíc ani nemusí vědět, že je souborová služba distribuována. V ideálním případě by měl vypadat stejně jako v centralizovaném systému souborů.
Protože souborový server je obvykle pouze uživatelský proces (nebo někdy proces jádra) běžící na nějakém počítači, může v systému existovat více souborových serverů, z nichž každý nabízí jinou souborovou službu. Například v distribuovaném systému mohou existovat dva servery, které poskytují souborové služby UNIXové systémy a MS-DOS a jakýkoli uživatelský proces používá příslušnou službu.
Souborová služba v distribuovaných souborových systémech (stejně jako v centralizovaných) má dvě funkčně odlišné části: samotnou souborovou službu a adresářovou službu. První se zabývá operacemi na samostatné soubory, jako je čtení, zápis nebo přidávání, a druhý - s vytvářením a správou adresářů, přidáváním a odebíráním souborů z adresářů atd.
Pro každého spisová služba ať už centralizovaný nebo distribuovaný, nejdůležitější otázkou je, co je soubor? Na mnoha systémech, jako jsou UNIX a MS DOS, je soubor neinterpretovaná sekvence bajtů. Význam a struktura informací v souboru je záležitostí aplikačních programů, operační systém to nezajímá.
Podporováno na mainframe OS odlišné typy logické uspořádání souborů, z nichž každý má jiné vlastnosti. Soubor může být organizován jako sekvence záznamů a operační systém má volání, která mu umožňují pracovat na úrovni těchto záznamů. Většina moderních distribuovaných systémů souborů podporuje definování souboru jako sekvence bajtů spíše než sekvence záznamů. Soubor je charakterizován atributy: název, velikost, datum vytvoření, ID vlastníka, adresa a další.
Důležitý aspekt Model souboru je schopnost upravit soubor po jeho vytvoření. Soubory lze obvykle upravovat, ale v některých distribuovaných systémech jsou jedinými operacemi se soubory CREATE a READ. Takové soubory se nazývají neměnné. U neměnných souborů je mnohem snazší uložit soubor do mezipaměti a replikovat jej, protože jsou odstraněny všechny problémy spojené s aktualizací všech kopií souboru, když se změní.
Souborovou službu lze rozdělit na dva typy podle toho, zda podporuje model upload-upload nebo model vzdálený přístup. V modelu upload-download je uživateli nabídnut prostředek ke čtení nebo zápisu celého souboru. Tento model předpokládá následující schéma zpracování souborů: čtení souboru ze serveru do počítače klienta, zpracování souboru na počítači klienta a zápis aktualizovaného souboru na server. Výhodou tohoto modelu je jeho koncepční jednoduchost. Přenos celého souboru je navíc velmi efektivní. Hlavní nevýhodou tohoto modelu jsou vysoké nároky na klientské disky. Navíc je neefektivní přesunout celý soubor, pokud je potřeba pouze jeho malá část.
Jiný typ souborové služby odpovídá modelu vzdáleného přístupu, který zahrnuje podporu velké množství operace se soubory: otevírání a zavírání souborů, čtení a zápis částí souboru, umístění v souboru, kontrola a změna atributů souboru a tak dále. Zatímco v modelu upload-download souborový server poskytoval pouze ukládání a přesun souborů, v v tomto případě celý souborový systém běží na serverech, ne na klientské stroje. Výhodou tohoto přístupu jsou nízké nároky na místo na disku na klientských počítačích a také odstranění nutnosti přenášet celý soubor, když je potřeba pouze jeho část.
Povaha adresářové služby je nezávislá na typu použitého modelu souborové služby. Distribuované systémy používají stejné principy organizace adresářů jako centralizované systémy, včetně víceúrovňové organizace adresářů.
Základním problémem metod pojmenovávání souborů je transparentnost. V této souvislosti je transparentnost chápána ve dvou špatně rozlišitelných významech. První, transparentnost umístění, znamená, že názvy neumožňují určit umístění souboru. Například jméno /server1/dir1/dir2/xříká, že soubor x je umístěn na serveru 1, ale neuvádí, kde se tento server nachází. Server se může pohybovat po síti a celé jméno soubor se nemění. V důsledku toho má takový systém transparentnost umístění.
V systémech skládajících se z klientů a serverů existují potenciálně čtyři různá místa pro ukládání souborů a jejich částí: disk serveru, paměť serveru, disk klienta (pokud je k dispozici) a paměť klienta. Nejvhodnějším místem pro uložení všech souborů je disk serveru. Obvykle má velká kapacita a soubory budou dostupné všem klientům. Navíc, protože v tomto případě existuje pouze jedna kopie každého souboru, není problém uvést stav kopií do souladu.
Výzvou při použití disku serveru je výkon. Než si klient může soubor přečíst, musí být soubor zapsán z disku serveru na jeho RAM a poté přeneseny přes síť do paměti klienta. Oba převody nějakou dobu trvají.
Významného zlepšení výkonu lze dosáhnout ukládáním souborů do paměti serveru. Algoritmy jsou nutné k určení, které soubory nebo jejich části by měly být uloženy v mezipaměti.
Při výběru algoritmu je třeba vyřešit dva problémy. Za prvé, na jakých jednotkách mezipaměť funguje? Tyto jednotky mohou být buď bloky disku nebo celé soubory. Pokud se jedná o celé soubory, pak je lze ukládat na disk v souvislých oblastech (alespoň ve formě velkých sekcí), čímž se sníží počet výměn mezi pamětí a diskem a zajistí se vysoký výkon. Ukládání diskových bloků do mezipaměti umožňuje efektivnější využití mezipaměti a místa na disku.
Za druhé je nutné definovat pravidlo pro výměnu dat při zaplnění vyrovnávací paměti. Zde můžete použít jakýkoli standardní algoritmus ukládání do mezipaměti, například algoritmus LRU (nejméně nedávno používaný), podle kterého je vyřazen blok, ke kterému se nejdéle nepřistupovalo.
Mezipaměť na serveru se snadno implementuje a je pro klienta zcela transparentní. Protože server umí synchronizovat paměť a disk, z pohledu klientů existuje pouze jedna kopie každého souboru, takže není problém s konzistencí.
Dnes je těžké někoho překvapit rozsáhlými sítěmi s komplexními
topologie, dostupnost vzdálených a mobilních kanceláří. Pro správce
organizování jakékoli služby v takových podmínkách není snadný úkol. Ale není potřeba
zapomeňte na naše uživatele – v tomto případě budou muset pracovat s více
počet různých zařízení a zdrojů umístěných na různých
počítače a síťové servery, respektive vyhledávání potřebných informací může
být extrémně obtížné. nám to umožňuje vyřešit
problém. Podívejme se přesně jak.
Účel a možnosti DFS
Distribuovaný systém souborů DFS (Distribuováno Souborový systém
) se objevil jako
standardní komponenta zpět ve Win2k. Jeho účelem je usnadnit správu, přístup a
vyhledávání dat na webu. Pro tohle souborové prostředky, který se nachází na různých
počítače jsou sloučeny do jednoho logického jmenného prostoru. Uživatel,
místo toho, abychom si pamatovali jména všech běžných síťové zdroje(Univerzální pojmenování
Konvence, UNC), jako \\Server\Folder, bude mít přístup k jedinému prostoru
Názvy UNC, které kombinují všechny servery a sdílené prostředky v síti. Který
je to v počítači, kde je požadovaný soubor umístěn, to je problém DFS, uživatel
není třeba se starat o skutečné umístění souboru. Když ho klient kontaktuje
jednoduše se přenese do adresáře, který potřebuje. V místě zdroje, ke kterému
označuje odkaz, může to být jakýkoli operační systém, jehož prostředky jsou přístupné
lze přistupovat pomocí UNC (Windows, Linux, xBSD, NetWare). Fyzický
objekty propojené odkazy DFS, se nazývají cíl objektů(cíle) popř
repliky(repliky).
Pohodlí pro uživatele a správce je však daleko není to nejdůležitější
hlavní výhody DFS. Jde o to, že s jedním logickým jménem může být
Existuje několik sdílených zdrojů, které ukládají identické informace.
Taková kolekce alternativních sdílených prostředků spojených s jedním logickým názvem
DFS, se nazývá sada replik. A pokud jsou sdílené zdroje v jednom
kořenový prostor domény DFS a jsou umístěny na serverech Win2k nebo Win2k3,
je možné přizpůsobit automatická synchronizace informace mezi nimi.
Uživatel, který kontaktoval DFS, obvykle přesměruje na nejbližší repliku a
pokud není k dispozici, bude přesměrován na alternativní zdroj. Pro
snížení zátěže serveru DFS na straně klienta jsou data ukládána do mezipaměti, takže
při častém přístupu ke stejnému zdroji každý požadavek na DFS Ne
se vyrábí. Tedy automaticky zálohování důležitých informací,
uvědomil v DFS, také zvyšuje odolnost proti chybám celého systému (výstup
jeden server nebo diskové zařízení neovlivní uživatelskou zkušenost).
I když je třeba si to připomenout DFS nebyl navržen tak, aby často pracoval s aktualizovanými
dat, a to zejména pro ty případy, kdy lze soubor současně aktualizovat v
na několika místech (v DFS zůstane zachována verze souboru, kde byly provedeny poslední změny
Změny).
V realizaci DFS ve Win2k bylo možné pojmout pouze jeden jmenný prostor,
ve Win2k3 jich už může být několik. Ve Win2k3 R2 se objevil novou verzi tento
systémy - Jmenné prostory DFS, ve kterém je již mnoho problémů vyřešeno. Pro replikaci
data ve Win2k3 SP1 a SP2 odpovídají FRS (Server replikace souborů), ve Win2k3 R2 -
Replikace DFS n. Jejich hlavní rozdíl je v tom, že v FRS nejmenší
objekt, který má být replikován, je soubor, in Replikace DFS použitý
pokročilejší technologie RDC (Dálková diferenciální komprese), které mohou
kopírovat pouze změněné části souboru a funkci cross-file RDC méně
načte kanál při kopírování nových souborů. Takže pomocí DFS
Snižuje také zatížení sítě, což je zvláště důležité pro vzdálené kanceláře S
nedostatečná propustnost. Ve službě DFS k ničemu
další bezpečnostní prvky. Při přístupu k cílům
Kontrolují se pouze oprávnění systému souborů a oprávnění pro ně nastavená.
objekty oprávnění v adresáři Aktivní adresář.
Tyto různé kořeny
Výchozí bod pro všechny názvy stromů DFS slouží jako kořen distribuovaného
souborový systém. Ve skutečnosti je kořenový adresář nějaký sdílený prostředek umístěný na
server, všichni ostatní Logické názvy systému DFS se připojí jako
další hierarchická úroveň. Kořeny v DFS může být dvou typů, každý z nich
se liší metodami a možnostmi ukládání dat. Izolovaný (autonomní)
kořen ( Samostatný DFS) není spojen se službou Active Directory a všechny odkazy směřují do sítě
zdroje jsou uloženy v registru samotného serveru DFS. Tento kořen nepoužívá
DFS
Replikace, to znamená, že to neznamená duplikaci informací o jiných zdrojích,
a proto neposkytuje odolnost proti chybám. V případě neúspěchu servery DFS
celá hierarchie se stane nepřístupnou, i když uživatelé přístup mohou
zdroje přímo. Mimochodem, několik samostatných serverů DFS schopen pracovat
v clusteru, takže tento problém lze vyřešit. Pokud server DFS je
člen domény, používá se kořen domény ( DFS založený na doméně). S tím
možnost, můžete připojit několik replik a používat Replikace DFS Pro
replikace jak samotného kořene, tak odkazů DFS. Pokud v DFS založený na doméně kořeny
jsou na počítačích se systémem Win2k a Win2k3, pak takový root
volal " Doména DFS se smíšeným režimem".
S doménou DFS všechny informace o jmenném prostoru jsou na řadiči
doména, ke které server pravidelně přistupuje DFS. S ohledem na synchronizaci
mezi DFS v doméně, která se s každou změnou stává složitější
struktur, mohou tyto požadavky představovat úzké hrdlo v systému, takže v tomto případě
existují také určitá omezení. Takže ve Win2k byl limit 16
kořeny pro jeden jmenný prostor. Ve Win2k3 je toto omezení odstraněno, protože
server DFS nyní může přistupovat k libovolnému DC, nejen k emulátoru PDC.
Druhé omezení doménových kořenů je způsobeno skutečností, že celá struktura je uložena v
speciální objekt, který je také třeba duplikovat na všech DC pro libovolný
sebemenší změna ve struktuře DFS. Dokumentace doporučuje omezení
maximální velikost objektu je 5 MB, což přibližně odpovídá 5000
odkazy (adresáře). Tato hodnota závisí na mnoha parametrech, délce jména
odkazy, přítomnost a velikost komentářů, které jsou také uloženy v tomto objektu.
Ale v průměru DFS zřídka přesahuje 50-100 odkazů a po počátečním
nastavení zůstává většinou statické, což znamená, že se často neduplikuje
dojde a těchto omezení jednoduše nelze dosáhnout. Mimochodem, v budoucnu
Windows 2008 limit 5000 odkazů již byl zrušen, ale všechny servery jsou pro to
musí běžet pod Longhornem. Pro Doporučeno samostatné DFS
limit odkazuřádově vyšší a činí 50 000 odkazů.
Nastavení DFS
Pojďme například nakonfigurovat DFS na počítači s Win2k3 s SP2 všechno
Nastavení v SP1 je podobné. V nastavení DFS některé jsou v R2 a Win2k
rozdíly, ale ne tak globální, abyste na to nemohli přijít sami. Všechno
Distribuovaný souborový systém je spravován centrálně pomocí
pomocí modulu snap-in MMC Distribuovaný systém souborů DFS“, což můžete
zavolejte na kartě "Správa" ovládacího panelu Windows. S její pomocí
můžete vytvářet a mazat kořeny, připojit se k jakýmkoli kořenům DFS. Je pohodlné, že v
Jedna karta může zobrazit více kořenů DFS. V případě, že root pracuje v " Smíšený
režim domény DFS“, tedy když repliky a kořeny DFS umístěné na počítačích
řízeno různé verze Ovládání Windows DFS musí být vyrobeno s
počítač s Win2k3. Případně můžete balíček nainstalovat Administrace Win2k3 Sada nástrojů
(adminpak.msi), který se nachází v volný přístup na
webové stránky společnosti. V tomto případě počítače s
WinXP. Informace o tomto balíčku naleznete na
support.microsoft.com/kb/304718. Navíc pracovat s DFS můžete také
použijte nástroje příkazového řádku dfscmd.exe a dfsutil.exe. Ten druhý má
více funkcí, které však ve výchozím nastavení nejsou součástí operačního systému,
Chcete-li jej používat, musíte nainstalovat balíček nástrojů podpory Win2k3. Zvrátit
Upozorňujeme, že pro úspěšnou instalaci nástrojů podpory je třeba stáhnout dva soubory:
suptools.msi a support.cab.
Chcete-li vytvořit nový kořenový adresář, zavolejte modul snap-in, klikněte na název a
kontextová nabídka vyberte "Vytvořit kořen" (Nový kořen), jako možnost můžete
vyberte podobnou položku v nabídce "Akce". Zobrazí se Průvodce vytvořením nového
root (New Root Wizard), postupujte podle jeho pokynů. Ve druhém kroku vyberte typ
root, který má být vytvořen (doména nebo izolovaná), zadejte doménu operátora a
server. Po kontrole připojení k vybranému serveru zadejte název root. Zvrátit
Věnujte pozornost tomu, jak bude vypadat cesta UNC k novému kořenovému adresáři, ve výchozím nastavení \\server\nameshare.
Od té doby tento moment obecný katalog neexistuje, v dalším kroku potřebujete
vyberte místní adresář, který chcete použít jako sdílený adresář. Tento
adresář neobsahuje skutečná data, bude obsahovat odkazy naznačující
na fyzické umístění dat. Průvodce vytvoří prostředky pouze pro čtení a
provedení pro členy skupiny Users. V případě potřeby by měl být upraven
oprávnění. Nyní klikněte na tlačítko Dokončit, nový kořenový adresář se objeví v okně konzoly.
Pokud na serveru běží Win2k3, vytvořte podobně
jiné kořeny. Pomocí příkazu Check Status, volaného z
konzole nebo kontextové nabídce, můžete zkontrolovat stav repliky. Stát
bude uvedeno ve stejnojmenném sloupci a u jména se objeví kroužek se značkou.
Pokud je zelená, je vše v pořádku. Chcete-li zkontrolovat, můžete jít na
zadané UNC nebo použijte příkaz „net share“ na místním počítači nebo
"net view computer_name" ze vzdáleného. Příkaz "dfsutil /Root:\\server\share /View"
ukáže informace o DFS.
>dfsutil /Root:\\server.com\first /View
DFS Utility verze 5.2 (postaveno na 5.2.3790.3959)
Kořen domény s 0 odkazy
Jméno kořene="\\SERVER\first" Comment="první kořen" State="1" Timeout="300"
Cílový server="GRINDERS" Folder="first" State="2"
Jakmile je kořen vytvořen, můžete jej publikovat ve službě Active Directory. Chcete-li to provést v
z kontextové nabídky vyberte Vlastnosti, přejděte na kartu Publikování a
Zaškrtněte políčko „Publikovat tento kořenový adresář ve službě Active Directory“. Doména
kořeny jsou publikovány automaticky a bez problémů.
Vytvoření odkazu
Jakmile je kořenový adresář vytvořen, můžete začít připojovat sdílené prostředky. Proč v tom
Ve stejné kontextové nabídce vyberte Nový odkaz. V okně, které se objeví
"Nový odkaz", do pole "Název odkazu" zadejte název odkazu, pod kterým bude
dostupné v DFS, pak těsně pod cestou UNC do cílového adresáře (mělo by již
existovat). Chcete-li vyhledat sdílené zdroje, můžete použít tlačítko Procházet
Níže můžete změnit dobu ukládání tohoto odkazu do mezipaměti pro klienty DFS(výchozí
1800 sekund). Po dokončení klepněte na tlačítko OK. Příkaz "dfsutil /view" by měl
zobrazit stav všech připojených odkazů a jejich vlastnosti. Pokud síť funguje
několik serverů, je možné přidat repliku ukazující na
alternativní odkaz. Vytvoří se replika kořenového nebo samostatného objektu
obdobně pouze v prvním případě vyberte v kontextové nabídce položku „Vytvořit
vykořenit cílová složka", a ve druhém - "Vytvořit složku".
Sdílené prostředky, které budou replikovány, musí
umístěné v oddílech se souborem systém NTFS na běžících počítačích
správa serveru Verze Windows od roku 2000 (lépe 2003). V poli "Cesta k".
cílová sdílená složka“ v okně, které se objeví, zadejte nebo použijte tlačítko Procházet
Označujeme sdílený prostředek umístěný na jiném počítači. V případě, že
k synchronizaci informací mezi těmito zdroji, které se plánuje používat
alternativní programy (nebo synchronizace bude provedena ručně),
Měli byste zrušit zaškrtnutí políčka "Přidat tuto cílovou složku do replikační sady".
cíl do replikační sady). Klepněte na tlačítko OK a zobrazí se Průvodce nastavením
replikace (Configure Replication Wizard), která vám pomůže s výběrem
hlavní replika a topologie replikace. V prvním kroku určíme adresář, který
budou použity jako hlavní cíl, všechny informace z tohoto
adresář bude poté zkopírován do jiné složky. Poslední by měl být prázdný
pokud jsou v něm soubory, budou zkopírovány do dočasného adresáře a poté
smazáno. Pokud sdílený prostředek z nějakého důvodu není vhodný pro replikaci
(například není umístěn na oddílu NTFS), bude označen červeným křížkem,
Když se pokusíte přejít k dalšímu kroku, průvodce vás vyzve k zadání jiného odkazu nebo
dokončit práci.
Stisknutím tlačítka " Mezisklad" (Pracovní složka) může změnit
umístění adresáře, který bude použit pro dočasné úložiště
replikovaná data. Ve výchozím nastavení je tento adresář umístěn v jiném oddílu
od toho, ke kterému je sdílený prostředek přidružen DFS. Další mistr
vás vyzve k výběru topologie replikace. Budete muset zadat jednu z
následující možnosti:
- Prsten- všechny repliky si vyměňují informace se dvěma sousedními;
- Hvězda (Hub and speak)- označuje hlavní odkaz, ze kterého budou
vyměňovat si informace se všemi ostatními replikami; - Plná síťovina (Mesh)- všechny repliky se navzájem vyměňují;
- Speciální (vlastní)- později administrátor nezávisle nakonfiguruje replikaci
pro každou dvojici serverů.
Kruhová topologie je výchozí a je vhodná pro většinu
případy. V ideálním případě by vybraná topologie replikace měla odpovídat návrhu
sítí. Například pokud existuje Hlavní kancelář kde se nacházejí hlavní zdroje,
a podle potřeby se k nim připojují četné větve, pak v tomto
V tomto případě je vhodnější schéma Hvězda. Pokud žádná z předvoleb nevyhovuje,
podívejte se prosím do speciální sekce.
Po vytvoření repliky odkazu se v okně modulu snap-in zobrazí jeho odpovídající ikona
změní se. V kontextové nabídce se také objeví dvě nové položky: Zobrazit/Skrýt
stav replikace a Zastavit replikaci. Pole stavu replikace může mít
jeden ze tří výsledků. Pokud je proces replikace dokončen normálně, ikony
budou zelené vlajky. Červený křížek na ikoně repliky bude indikovat, že právě je
moment nedostupný, štítek v poli Stav se změní na Offline. Pokud v
pouze některé repliky nejsou pro kontrolovaný odkaz dostupné, objeví se žlutá ikona
Vykřičník.
Před odstraněním jedné z alternativních replik musíte nejprve zakázat
replikace. Když se replikace obnoví, uvítá vás stejný hlavní server. Li
server je společně řadičem domény se všemi daty DFS vůle
replikovat obsah svazku SYSVOL. Proto je třeba připomenout, že až
dokud nedojde k úplné replikaci všech replik, začněte provádět jakékoli změny
konfigurace DFS velmi riskantní, může narušit funkčnost všeho
doména.
Pokud vybraná možnost topologie replikace z nějakého důvodu není
Když se přiblížíte, lze replikační topologii později snadno změnit výběrem okna
vlastnosti odpovídajícího odkazu a přejděte na kartu Replikace. Tady jsou
Několik ještě užitečná nastavení. Ve výchozím nastavení replikace běží nepřetržitě,
Kliknutím na tlačítko Plán můžete změnit plán replikace pro všechny
spojení. Níže jsou filtry pro soubory a podsložky, které nejsou
budou replikovány. Chcete-li to provést, klikněte na Upravit a zadejte šablony souborů nebo
podadresáře.
Chcete-li vynutit replikaci informací uložených na konkrétním serveru,
můžete použít nástroj NtfrsUtl.exe, který je součástí balení
Nástroje podpory. Příkaz je jednoduchý: „ntfrsutl poll /now server.com“. Vidět
stanovené časové intervaly, ve kterých dochází k replikaci,
měli byste zadat "ntfrsutl poll". Všechna nastavení jsou dostupná pomocí příkazu „ntfrsutl sets“.
server.com".
V okně vlastností sdílený zdroj prezentovány ve službě DFS, objeví se další
jedna záložka – DFS. Jeho otevřením si uživatel může prohlédnout, se kterým sdíleným
složky spojené s tímto odkazem, zkontrolujte stav repliky, vyberte aktivní
replika, na kterou bude přesměrována jako první.
Správce by měl protokol kontrolovat častěji.
"Administrace - Prohlížeč událostí - Služba replikace souborů", kde můžete
najít informace o všech událostech, ke kterým dochází se službou FRS.
Distribuovaný systém souborů (DFS) poskytuje možnost snadno a transparentně spravovat síťové jednotky. Namísto použití fyzického umístění síťového prostředku (podle názvu serveru) se uživatelé mohou jednoduše připojit ke kořenovému adresáři distribuovaného systému souborů.
Kořen distribuovaného systému souborů funguje jako logický distribuční bod pro síťové jednotky. To znamená, že uživatelé mohou jednoduše přejít do kořenového adresáře distribuovaného systému souborů a zobrazit seznam složek připojených k tomuto kořenovému adresáři. Kliknutím na složku může uživatel zobrazit její obsah. Uživatel však nemusí ani tušit, že obsah složky je na jiném serveru.
To vše znamená, že distribuovaný souborový systém poskytuje další úroveň transparentnost při přístupu k obsahu síťových zdrojů. Mnoho lidí tento koncept nazývá virtualizace úložiště. Při použití distribuovaného systému souborů uživatel nemusí vědět, kde se data fyzicky nacházejí. Místo toho si stačí zapamatovat umístění kořenového adresáře souborového systému.
Logickou správou umístění síťových jednotek můžete uživatelům transparentně přesouvat data mezi servery v síti. Z pohledu uživatelů budou data i nadále umístěna v kořenovém adresáři distribuovaného systému souborů. Vše, co je potřeba, je zkopírovat data do jiného umístění a aktualizovat odkaz distribuovaného systému souborů na sdílený objekt tak, aby odpovídal novému umístění.
Kromě poskytování transparentního přístupu k úložištím dat lze sdílené složky spravované distribuovaným systémem souborů konfigurovat jako partnery pro replikaci. To vám umožňuje poskytovat úroveň tolerance chyb a vyvažování zátěže (automaticky prováděné pomocí distribuovaného systému souborů).
Probíhá replikace dat Služba replikace souborů (FRS), který také replikuje složku SYSVOL s objekty skupinová politika Aktivní adresář.
Když poprvé nastavujete distribuovaný systém souborů, musíte určit počáteční bod pro strom distribuovaného systému souborů. Je známý jako kořen distribuovaného systému souborů. Existují dva typy kořenového adresáře distribuovaného systému souborů:
- Izolovaný kořen (samostatný)- Konfigurace a architektura jmenného prostoru distribuovaného systému souborů jsou uloženy lokálně na kořenovém serveru. Přístupová cesta ( Cesta UNC) do kořenového adresáře začíná názvem serveru. Izolovaný kořenový adresář umožňuje existenci pouze jednoho kořenového adresáře distribuovaného systému souborů na jmenný prostor distribuovaného systému souborů. To znamená, že kořenový adresář neposkytuje toleranci chyb a představuje jediný bod selhání při přístupu k datům.
- Doména- jmenný prostor distribuovaného systému souborů je uložen v Active Directory. Použitím domény distribuovaného systému souborů lze vytvořit více kořenů distribuovaného systému souborů odolných proti chybám a klienti budou k distribuovanému systému souborů přistupovat podle názvu domény. Použití integrace Active Directory umožňuje klientům, aby byli automaticky přesměrováni do kořenového adresáře distribuovaného souborového systému v místní lokalitě Active Directory, což má určité výhody velké sítě, kde se infrastruktura distribuovaného systému souborů může rozšiřovat na více míst.
Další termín, který potřebujete znát, je Odkaz na distribuovaný systém souborů (odkaz DFS). Kořeny jsou výchozími body distribuovaného systému souborů. Když přidáte odkazy, určí se názvy síťových jednotek a umístění síťových dat. Když uživatel přistoupí ke kořenovému adresáři distribuovaného systému souborů, vztahy se zobrazí jako logické podsložky kořenového adresáře.
V současné době s nárůstem informací vznikají problémy s ukládáním a zpracováním velmi velkého množství dat. Proto jsou tato data zpracovávána na několika serverech současně, které tvoří clustery. Pro zjednodušení práce s daty na clusterech jsou vyvíjeny distribuované souborové systémy. Blíže se podíváme na příklad distribuovaného souborového systému Systém souborů Google používá společnost Google. (Článek je ve skutečnosti volným a zkráceným překladem původního článku).
GFS je pravděpodobně nejznámější distribuovaný souborový systém. Spolehlivé, škálovatelné úložiště dat je nezbytné pro každou aplikaci, která pracuje s tak velkými daty, jako jsou všechny dokumenty na internetu. GFS je hlavní platformou pro ukládání informací Google. GFS- velký distribuovaný souborový systém schopný ukládat a zpracovávat obrovské množství informací.
GFS byl postaven na základě následujících kritérií:
- Systém je postaven z velkého množství běžného levného vybavení, které často selhává. Musí existovat monitorování poruch a schopnost obnovit fungování systému v případě poruchy jakéhokoli zařízení.
- Systém musí ukládat mnoho velkých souborů. Zpravidla několik milionů souborů, každý 100 MB nebo více. Často se také musíte potýkat s mnohagigabajtovými soubory, které je také potřeba efektivně ukládat. Měly by se ukládat i malé soubory, ale systém pro ně není optimalizován.
- Obvykle existují dva typy čtení: čtení velké sekvenční části dat a čtení malého množství náhodných dat. Při čtení velkého toku dat je běžné požadovat fragment o velikosti 1 MB nebo větší. Takové sekvenční operace ze stejného klienta často čtou po sobě jdoucí bloky stejného souboru. Čtení není velká velikost data mají zpravidla objem několika kilobajtů. Časově kritické aplikace se musí hromadit určité množství takové dotazy a seřadit je podle offsetu od začátku souboru. Vyhnete se tak bloudění tam a zpět při čtení.
- Často dochází k operacím zápisu velkého sekvenčního kusu dat, který je třeba připojit k souboru. Obvykle je množství dat pro zápis ve stejném pořadí jako pro čtení. Zápisy malých svazků, ale na libovolná místa v souboru, se obvykle neprovádějí efektivně.
- Systém musí implementovat přesně definovanou sémantiku paralelní práce několik klientů, pokud se současně pokusí přidat data do stejného souboru. V tomto případě se může stát, že současně dorazí stovky požadavků na zápis do jednoho souboru. Aby se s tím vyrovnalo, používá se atomičnost operací přidávání dat do souboru s určitou synchronizací. To znamená, že pokud přijde operace čtení, bude provedena buď před další operací zápisu, nebo po ní.
- Vysoká propustnost je výhodnější než nízká latence. Většina aplikací na Googlu tedy dává přednost práci s velké objemy data, na vysoká rychlost a provádění jedné operace čtení a zápisu, obecně řečeno, může být rozšířeno.
Navíc podporuje GFS zálohy nebo snímky. Takové zálohy souborů nebo adresářových stromů můžete vytvořit s nízkými náklady.
Architektura GFS
Obrázek je převzat z původního článku.
V systému jsou hlavní servery a blokové servery, které ve skutečnosti ukládají data. Obvykle, GFS cluster se skládá z jednoho hlavního hlavního stroje (master) a mnoha strojů ukládajících fragmenty souborů – chunk serverů (chunkservers). Zákazníci mají přístup ke všem těmto strojům. Soubory v GFS jsou rozděleny na části - chunks (chunk, dá se říct fragment). Chunk má pevná velikost, které lze přizpůsobit. Každý takový blok má jedinečný a globální 64bitový klíč, který vydává hlavní server při vytváření bloku. Blokové servery ukládají bloky jako běžné Linuxové soubory, na místním pevném disku. Z důvodu spolehlivosti lze každý blok replikovat na jiné servery bloků. Obvykle se používají tři repliky.
Master je zodpovědný za práci s metadaty celého souborového systému. Metadata zahrnují jmenné prostory, informace o řízení přístupu k datům, mapování souborů na bloky a Aktuální pozice kousky. Hlavní server také řídí všechny globální systémové aktivity, jako je správa volných bloků, shromažďování odpadků (shromažďování bloků, které již nejsou potřeba) a přesouvání bloků mezi servery bloků. Master si neustále vyměňuje zprávy (HeartBeat zprávy) s blokovými servery, aby vydal instrukce a určil jejich stav (zjistil, zda jsou stále naživu).
Klient komunikuje s hlavním serverem pouze za účelem provádění operací souvisejících s metadaty. Všechny operace se samotnými daty se provádějí přímo s blokovými servery. GFS- systém nepodporuje POSIX API, takže se vývojáři nemuseli potýkat s vrstvou VNode Linuxu.
Vývojáři nepoužívají ukládání dat do mezipaměti, ačkoli klienti mezipaměť metadata používají. Na blokových serverech operační systém Linuxový systém a tak ukládá nejpoužívanější bloky do paměti. Obecně platí, že odmítnutí ukládání do mezipaměti umožňuje nemyslet na problém platnosti mezipaměti (koherence mezipaměti).
Mistr
Použití jednoho průvodce výrazně zjednodušuje architekturu systému. Umožňuje vyrábět složité pohyby chunks, organizovat replikace pomocí globálních dat. Zdálo by se, že mít pouze jednoho mastera by mělo být úzkým hrdlem systému, ale není tomu tak. Klienti nikdy nečtou ani nezapisují data přes master. Místo toho se zeptají hlavního serveru, který server bloků by měli kontaktovat, a pak mluví přímo se servery bloků.Podívejme se, jak data čte klient. Za prvé, když znáte velikost kusu,
jméno souboru a offset vzhledem k začátku souboru, klient určí číslo bloku uvnitř souboru. Poté odešle požadavek na master obsahující název souboru a číslo bloku v tomto souboru. Master vydává blokové servery, jeden v každé replice, které ukládají blok, který potřebujeme. Hlavní server také vydá identifikátor bloku klientovi.
Klient se poté rozhodne, která replika se mu nejvíce líbí (obvykle nejbližší) a odešle požadavek skládající se z chunku a offsetu vzhledem k začátku chunku. Další čtení dat nevyžaduje zásah průvodce. V praxi je pravidlem, že klient zahrne několik bloků do jednoho požadavku na čtení a hlavní server udává souřadnice každého bloku v jedné odpovědi.
Velikost kousku je důležitá vlastnost systémy. Obvykle je nastavena na 64 megabajtů, což je mnohem více než velikost bloku v běžném souborovém systému. Je jasné, že pokud je nutné uložit mnoho souborů, jejichž velikosti jsou menší než velikost bloku, bude spotřebováno mnoho paměti navíc. Ale výběr tak velkého kusu je způsoben úkoly, které musí být Google rozhodnout o svých shlucích. Zpravidla se pro všechny dokumenty na internetu musí něco počítat, a proto jsou soubory v těchto úlohách velmi velké.
Metadata
Hlavní ukládá tři důležité typy metadat: jmenné prostory souborů a bloků, mapování mezi soubory a pozice replik bloků. Všechna metadata jsou uložena v paměti mastera. Protože jsou metadata uložena v paměti, operace průvodce jsou rychlé. Mistr může jednoduše a efektivně zjistit stav věcí v systému. Skenuje blokové servery Pozadí. Tyto periodické skenování používá se pro garbage collection, dodatečné replikace, v případě detekce nedostupného chunk serveru a pohybu chunků, k vyvážení zátěže a volného místa na pevných discích chunk serverů.Master sleduje polohu kusů. Když se server bloků spustí, hlavní server si pamatuje jeho bloky. Během provozu master řídí všechny pohyby bloků a stavy serverů bloků. Má tedy všechny informace o poloze každého chunku.
Důležitou součástí metadat je transakční protokol. Hlavní ukládá sekvenci operací pro přerušení změn metadat. Na základě těchto značek v provozním deníku je určen logický čas systému. Je to tento logický čas, který určuje verze souborů a bloků.
Protože protokol transakcí je důležitou součástí, musí být bezpečně uložen a všechny změny v něm by měly být viditelné pro klienty pouze tehdy, když se změní metadata. Operační protokol je replikován na několik vzdálených počítačů a systém reaguje na operaci klienta pouze po uložení tohoto protokolu na hlavní disk a disky vzdálených počítačů.
Průvodce obnoví stav systému spuštěním protokolu operací. Provozní protokol je uložen relativně k malá velikost, pouze uchovávání nedávné transakce. V procesu práce mistr tvoří kontrolní body, když velikost protokolu překročí určitou hodnotu a systém lze obnovit pouze k nejbližšímu kontrolnímu bodu. Dále pomocí protokolu můžete přehrát některé operace, takže se systém může vrátit zpět do bodu, který je mezi posledním kontrolním bodem a aktuálním časem.
Interakce v rámci systému
Výše byla popsána architektura systému, která minimalizuje zásahy mastera do provádění operací. Nyní se podívejme na to, jak klientský, hlavní a blokový server spolupracují při přesunu dat, provádění atomických zápisů a vytváření záložní kopie (snímku).Každá změna bloku musí být duplikována ve všech replikách a změnit metadata. V GFS mistr dává kus v majetek(pronajmout) jednomu ze serverů, na kterých je tento blok uložen. Takový server se nazývá primární replika. Zbývající repliky jsou prohlášeny za sekundární. Primární replika se shromažďuje postupné změny chunk a všechny repliky se při výskytu těchto změn řídí touto posloupností.
Mechanismus majetek Chunk je navržen tak, aby minimalizoval zatížení masteru. Při přidělování paměti nejprve počkejte 60 sekundy A pak, je-li to nutné, může primární replika požádat master o prodloužení tohoto intervalu a zpravidla obdrží kladnou odpověď. Během této čekací doby může průvodce změny vrátit zpět.
Podívejme se podrobně na proces zaznamenávání dat. Na obrázku je znázorněn krok za krokem, přičemž tenké čáry představují řídicí toky a tučné čáry představují toky dat.
Tento údaj je také převzat z původního článku.
- Klient se zeptá hlavního serveru, který ze serverů bloků vlastní blok a kde se tento blok nachází v jiných replikách. Je-li to nutné, master předá kus do vlastnictví někomu jinému.
- Hlavní server odpoví primární replikou a zbývajícími (sekundárními) replikami. Klient tato data uchovává pro další akce. Nyní může klient potřebovat komunikovat s hlavním serverem pouze v případě, že primární replika přestane být dostupná.
- Dále klient odešle data do všech replik. Může to udělat v libovolném pořadí. Každý blokový server je bude ukládat do speciální vyrovnávací paměti, dokud nebudou potřeba nebo nebudou zastaralé.
- Když všechny repliky přijmou tato data, klient odešle požadavek na zápis do primární repliky. Tento požadavek obsahuje identifikaci dat, která byla odeslána v kroku 3. Primární replika nyní nastavuje pořadí, ve kterém mají být provedeny všechny změny, které obdrží, případně od více klientů paralelně. A pak provede tyto změny lokálně v tomto konkrétním pořadí.
- Primární replika předá požadavek na zápis všem sekundárním replikám. Každá sekundární replika provádí tyto změny v pořadí určeném primární replikou.
- Sekundární repliky hlásí úspěšné dokončení těchto operací.
- Primární replika odešle odpověď klientovi. Všechny chyby zjištěné v jakékoli replice jsou také odeslány klientovi. Pokud dojde k chybě při zápisu do primární repliky, pak k zápisu do sekundárních replik nedojde, jinak k zápisu došlo v primární replice a podmnožině sekundárních replik. V takovém případě klient chybu zpracuje a rozhodne se, co s ní dál dělat.
Zpoždění je také minimalizováno použitím zřetězení paketů přenášených dat přes TCP. To znamená, že jakmile blokový server obdrží nějakou část dat, okamžitě je začne odesílat. Žádné přetížení sítě, perfektní čas objemové datové zásilky B byte za R budou repliky B/T + RL, Kde Tšířku pásma sítě a L- zpoždění při odesílání jednoho bajtu mezi dvěma stroji.
GFS podporuje operace, jako je atomické připojení dat k souboru. Obvykle při zápisu některých dat do souboru uvádíme tato data a offset. Pokud podobnou operaci provádí několik klientů, nelze tyto operace zaměňovat (může to vést k nesprávné operaci). Pokud chceme pouze přidat data do souboru, pak v tomto případě označujeme pouze data samotná. GFS přidá je atomovou operací. Obecně řečeno, pokud operace selže na jedné ze sekundárních replik, pak GFS, vrátí chybu a data se budou v různých replikách lišit.
Další zajímavost o GFS- jedná se o záložní kopie (lze říci i snapshot) stromu souborů nebo adresářů, které se vytvářejí téměř okamžitě, přičemž téměř bez přerušení probíhajících operací v systému. Toho je dosaženo pomocí technologie podobné kopírovat na zápis. Uživatelé tuto funkci používají k vytváření datových větví nebo jako přechodný bod pro zahájení některých experimentů.
Operace provedené průvodcem
Master je důležitým článkem v systému. Spravuje replikace bloků: rozhoduje o umístění, vytváří nové bloky a koordinuje různé aktivity v rámci systému, aby byly bloky plně replikovány, vyrovnává zatížení mezi servery bloků a shromažďuje nevyužité zdroje.Na rozdíl od většiny souborových systémů GFS neukládá složení souborů do adresáře. GFS logicky představuje jmenný prostor jako tabulku, která mapuje každou cestu na metadata. Takovou tabulku lze efektivně uložit do paměti ve formě frézy (slovník stejných cest). Každý uzel v tomto stromu (odpovídající buď absolutní cestě k souboru nebo adresáři) má odpovídající zámek pro čtení a zápis. Každá operace průvodce vyžaduje vytvoření některých zámků. Zde systém používá zámky pro čtení a zápis. Obvykle, pokud operace běží s /d1/d2/.../dn/list, pak nastaví zámky čtení /d1, /d1/d2, ..., d1/d2/.../dn a zamykání, buď pro čtení nebo psaní d1/d2/.../dn/list. V čem list může být buď adresář nebo soubor.
Ukažme si na příkladu, jak může zamykací mechanismus zabránit vytvoření souboru /home/user/foo během Rezervovat kopii /home/user PROTI /uložit/uživatel. Operace zálohování zapíná zámky čtení /Domov A /Uložit, stejně jako zápis zámků na /home/user A /uložit/uživatel. Operace vytvoření souboru vyžaduje zámek čtení /Domov A /home/user, stejně jako zápis zámků na /home/user/foo. Druhá operace se tedy nezačne provádět, dokud nedokončí provádění první, protože existuje konfliktní zámek /home/user. Při vytváření souboru není vyžadován zámek pro zápis v nadřazeném adresáři, postačí zámek pro čtení, který zabraňuje smazání adresáře.
Shluky GFS jsou vysoce distribuované a vícevrstvé. Obvykle má takový cluster stovky blokových serverů umístěných v různých stojanech. Tyto servery jsou obecně dostupné velkému počtu klientů umístěných ve stejném nebo jiném racku. Spojení mezi dvěma stroji z různých stojanů může procházet jedním nebo více přepínači. Vícevrstvé uspořádání představuje velmi obtížnou výzvu při spolehlivé, škálovatelné a cenově dostupné distribuci dat.
Zásady umístění replik se snaží uspokojit následující vlastnosti: maximalizace spolehlivosti a dostupnosti dat a maximalizace využití šířky pásma sítě. Repliky musí být umístěny nejen na různých discích resp různá auta, ale i na různých stojanech. Tím je zajištěno, že blok je k dispozici, i když je celý stojan poškozen nebo odpojen od sítě. Při tomto uspořádání trvá čtení přibližně stejnou dobu jako šířka pásma sítě, ale datový tok při zápisu musí procházet různými stojany.
Když master vytvoří blok, vybere, kam umístí repliku. Vychází z několika faktorů:
- Je vhodné umístit novou repliku na blokový server s nejnižším průměrným zatížením disku. To nakonec vyrovná zatížení disku na různých serverech.
- Je vhodné omezit počet nových bloků vytvořených na každém serveru bloků. Ačkoli je vytvoření bloku samo o sobě rychlou operací, zahrnuje následné zapisování dat do tohoto bloku, což je již náročná operace a může vést k nerovnováze v množství datového provozu do různých částí systému.
- Jak je uvedeno výše, je vhodné rozdělit kusy mezi různé stojany.
Hlavní server vybere blok s nejvyšší prioritou a zkopíruje jej, přičemž dá jednomu ze serverů bloků pokyn, aby jej zkopíroval z dostupné repliky. Nová replika je umístěna ze stejných důvodů, jako když byla vytvořena.
Při práci mistr neustále vyvažuje repliky. V závislosti na rozložení replik v systému posouvá repliku, aby vyrovnala zátěž na discích a vyrovnala zátěž. Hlavní musí také rozhodnout, které z replik by měly být odstraněny. Zpravidla replika, která se nachází na serveru chunk s nejmenším volný prostor na pevných discích.
Další důležitou funkci, ležící na pánovi - to je sběr odpadu. Při mazání souboru, GFS nevyžaduje okamžité vrácení uvolněného místa na disku. Dělá to během pravidelného úklidu, ke kterému dochází na úrovni bloků i souborů. Autoři se domnívají, že tento přístup činí systém jednodušším a spolehlivějším.
Když je soubor odstraněn aplikací, průvodce si tuto skutečnost pamatuje, stejně jako mnoho dalších, v protokolech. Namísto okamžité obnovy uvolněných zdrojů se však soubor jednoduše přejmenuje s časem odstranění přidaným k názvu souboru a pro uživatele se stane neviditelným. A průvodce při pravidelném skenování jmenného prostoru souborového systému skutečně smaže všechny takové skryté soubory, které uživatel smazal před více než třemi dny (tento interval je konfigurovatelný). Do tohoto okamžiku je soubor nadále v systému jako skrytý a lze jej číst nebo přejmenovat zpět pro obnovení. Když skrytý soubor Pokud je hlavní soubor smazán, informace o něm jsou také odstraněny z metadat a všechny části tohoto souboru jsou od něj odpojeny.
Kromě pravidelného skenování jmenného prostoru souborů průvodce provádí podobnou kontrolu jmenného prostoru bloků. Hlavní server identifikuje bloky, které jsou odpojeny od souboru, odstraní je z metadat a během běžné komunikace se servery bloků jim signalizuje, že všechny repliky obsahující daný blok lze odstranit. Tento přístup ke shromažďování odpadků má mnoho výhod s jednou nevýhodou: pokud systému dojde místo, a zpožděné odstranění zvětší nevyužitý prostor až do samotného fyzického odstranění. Je tu ale možnost obnovy smazaných dat, možnost flexibilního vyvažování zátěže při mazání a možnost obnovení systému v případě jakýchkoliv poruch.
Tolerance poruch a diagnostika chyb
Autoři systému jej považují za jeden z nejvíce komplexní problémyčasté poruchy součástí systému. Množství a kvalita komponentů činí tyto poruchy nejen výjimkou, ale spíše normou. Selhání komponenty může být způsobeno tím, že komponenta není k dispozici, nebo v horším případě přítomností poškozených dat. GFS udržuje systém v provozuschopném stavu pomocí dvou jednoduché strategie: Rychlé zotavení a replikace.Rychlé obnovení je v podstatě restartování stroje. Současně je doba spuštění velmi krátká, což vede k mírnému zádrhelu, a pak práce pokračuje normálně. Replikace bloků již byla diskutována výše. Master replikuje blok, pokud se jedna z replik stane nedostupnou nebo jsou data obsahující repliku bloku poškozena. Poškozené bloky jsou určeny výpočtem kontrolních součtů.
Dalším typem replikace v systému, o kterém bylo málo řečeno, je hlavní replikace. Operační protokol a kontrolní body jsou replikovány. Ke každé změně souborů v systému dojde až po zapsání provozního protokolu na disky masterem a disky počítačů, na které je protokol replikován. V případě menších problémů se může průvodce restartovat. V případě problémů s pevný disk nebo jiné životně důležité infrastruktury hlavního serveru, GFS spustí nový hlavní server na jednom ze strojů, na který byla data hlavního serveru replikována. Klienti kontaktují hlavního DNS serveru, kterého lze znovu přiřadit nové auto. Nový mistr je stínem starého, ne přesnou kopii. Má tedy k souborům přístup pouze pro čtení. To znamená, že se nestane plnohodnotným masterem, ale pouze udržuje provozní deník a další struktury mastera.
Důležitou součástí systému je schopnost udržovat integritu dat. Obyčejný GFS cluster se skládá ze stovek strojů, na kterých jsou tisíce pevné disky a tyto disky při práci se záviděníhodnou konzistencí selhávají, což vede k poškození dat. Systém může obnovit data pomocí replikace, ale k tomu je nutné pochopit, zda nedošlo k poškození dat. Pouhé porovnávání různých replik na různých blokových serverech je neúčinné. Kromě toho může mezi různými replikami nastat nekonzistence dat, což vede k rozdílům v datech. Proto musí každý blokový server nezávisle určit integritu dat.
Každý kus je rozdělen na bloky délky 64 kB. Každý takový blok odpovídá 32 -bitový kontrolní součet. Stejně jako ostatní metadata jsou tyto částky uloženy v paměti, pravidelně ukládány do protokolu, odděleně od uživatelských dat.
Před čtením dat server bloků zkontroluje kontrolní součty bloků bloků, které se překrývají s požadovanými daty uživatelem nebo jiným serverem bloků. To znamená, že blokový server nedistribuuje poškozená data. Pokud se kontrolní součty neshodují, server bloků vrátí chybu do počítače, který požadavek odeslal, a oznámí to hlavnímu serveru. Uživatel může číst data z jiné repliky a master vytvoří další kopii z dat z jiné repliky. Poté hlavní server instruuje tento blokový server, aby odstranil tuto poškozenou repliku.
Při přidávání nových dat nedochází k ověření kontrolního součtu a pro bloky se zapisují nové kontrolní součty. Pokud je disk poškozen, zjistí se to při pokusu o načtení těchto dat. Při nahrávání porovnává server bloků pouze první a poslední bloky, protínající se s hranicemi, do kterých dochází k zápisu, protože některá data na těchto blocích nejsou přepsána a je nutné zkontrolovat jejich integritu.
Co jsou distribuované souborové systémy?
Schopnost sdílet disky, adresáře a soubory po síti je jedním z nejvýznamnějších úspěchů moderní informační technologie. Tato schopnost může výrazně snížit požadavky na diskový prostor počítačů a usnadnit uživatelům spolupráci. Počítače se systémem Microsoft Windows a MacOS Apple/MacOS X k tomu používají mechanismus sdílení disků a adresářů. Na systémech Linux / Unix se tradičně používá pro stejné úkoly NFS síť souborový systém.
NFS je nejslavnější mechanismus sdílení souborů pro Linux a další unixové systémy, protože je přítomen na mnoha unixových systémech a je velmi snadno konfigurovatelný. NFS je podporován jádrem Linuxu a nástroje související s NFS jsou přítomny v každé distribuci. V linuxovém světě ale existují modernější mechanismy pro sdílení souborů a adresářů. Každý má určité výhody pro nastavení nebo použití.
OpenAFS distribuovaný souborový systém ( http://www.openafs.org/) je open source obdoba známého komerčního distribuovaného souborového systému AFS. Podpora pro distribuované souborové systémy InterMezzo (http://www.inter-mezzo.org/) a Coda (http://coda.cs.cmu.edu/) je již přítomna v nových linuxových jádrech řady 2.4. Jako systémy souborů lze také použít nové mechanismy sdílení souborů na webu (např. WebDAV (http://www.webdav.org/)).
Tento článek poskytuje stručný přehled výhod distribuovaných souborových systémů, rozebírá nejčastější problémy a jejich řešení a popisuje nejzajímavější distribuované souborové systémy, které jsou dnes pro Linux k dispozici.
Úvod do distribuovaných souborových systémů.
Nyní se nazývají síťové systémy souborů<<распределенными>>. Tento termín odráží skutečnost, že mnoho z těchto souborových systémů dělá mnohem více než jen přenos dat po síti. Úložná média spojená s těmito systémy souborů nemusí být nutně umístěna na jednom počítači, mohou být distribuována mezi mnoha počítači.
Distribuované souborové systémy OpenAFS a Coda mají své vlastní mechanismy správy oddílů, které zjednodušují možnosti ukládání veřejně dostupné informace. Podporují také duplikaci, možnost vytvářet kopie diskových oddílů a ukládat je ostatním souborové servery. Pokud se jeden souborový server stane nedostupným, k datům uloženým na jeho oddílech lze stále přistupovat pomocí existujících záloh těchto oddílů.
Nejdůležitější rozdíl mezi přístupem Windows/MacOS (sdílení adresářů a disků) a přístupem Linuxu, MacOS X a dalších víceuživatelských operačních systémů podobných Unixu je v tom, jak tyto operační systémy používají a organizují oddíly. Windows/MacOS exportují oddíly jako samostatné adresáře nebo jednotky a vzdálené systémy, které chtějí mít přístup ke sdíleným zařízením, si musí být jisti, že je k sobě připojí.
Pokud je nejvyšší úrovní organizace v systému souborů diskový oddíl (například jako v souborových systémech Windows), klientské pracovní stanice se musí k oddílu připojit a přiřadit mu samostatné písmeno ve svém místním rozložení (například jednotka E, F , G atd.). Písmena lze přiřadit síťovým oddílům v uživatelských a skupinových profilech Windows (pro standardizaci). Bohužel ale uspořádání písmen nemusí být na všech počítačích stejné. Například na počítači s velkým počtem pevných disků a oddílů mohou být potřebná písmena obsazena, a proto budete muset síťovým oddílům přidělit různá označení.
Naproti tomu souborový systém Unix je hierarchický souborový systém, do kterého se přidávají další oddíly jejich připojením do existujícího adresáře. To vám umožní efektivně přidat jakýkoli zdroj dat k jakémukoli existujícímu souborový systém. Pokud připojíte nový zdroj obsahu do adresáře, který je součástí distribuovaného systému souborů, je okamžitě dostupný všem klientům tohoto distribuovaného systému souborů.
Moderní distribuované souborové systémy jako OpenAFS nebo Coda obsahují speciální služby pro správu oddílů. To vám umožňuje připojit oddíly z různých souborových serverů do centrální hierarchie adresářů podporované systémy souborů. OpenAFS používá centrální adresář nazvaný<> a Coda používá<>. Tyto hierarchie adresářů jsou dostupné všem klientům distribuovaného systému souborů a vypadají stejně na všech klientských pracovních stanicích. To umožňuje uživatelům pracovat se svými soubory stejným způsobem na jakémkoli počítači. Pokud váš stolní počítač nefunguje, můžete použít jakýkoli jiný, všechny vaše soubory jsou na serveru v bezpečí.
Distribuované systémy souborů, které poskytují stejná data mnoha různým počítačovým systémům, dávají uživatelům možnost používat jakýkoli operační systém, který nejlépe vyhovuje jejich potřebám. Uživatelé počítačů Macintosh mohou plně využívat grafické nástroje dostupné v systému Mac OS a ukládat svá data na centralizované souborové servery. Uživatelé Windows mohou mít také přístup k trvalému globálnímu systému souborů. Distribuované souborové systémy jsou obzvláště atraktivní, když se snažíte koordinovat práci mezi skupinami umístěnými v různých městech, státech nebo dokonce v různých zemích. Výhodou je, že sdílená data jsou vždy dostupná online bez ohledu na to, kde se nacházíte.
Problémy administrace distribuovaných souborových systémů.
Použití distribuovaných souborových systémů dává správcům systému nejen nové příležitosti, ale také nové problémy. Ale distribuované systémy může zjednodušit mnoho standardních administrativních úkolů. V síťovém prostředí by uživatelé měli mít možnost přihlásit se do sítě pod svým vlastním jménem z libovolného počítače. To znamená, že mechanismus síťového přihlášení (nebo autentizace) musí být také založen na síti. V prostředí distribuovaného systému souborů jsou proto soubory skupin a hesel umístěné na jednotlivých počítačích sekundární k mechanismům síťové autentizace (jako je Kerberos nebo NIS, které uživatelům umožňují pracovat na jakémkoli počítači). Musí však stále existovat standardní místní mechanismy kontroly hesel, aby je mohli správci provádět lokální počítače potřebné úkoly. Ukládání sdílených dat na centralizovaných souborových serverech (spíše než na jednotlivých počítačích) zjednodušuje administrativní úlohy, jako je zálohování a obnova souborů a adresářů. Také centralizuje standardní administrativní úlohy, jako je monitorování využití souborového systému, a zavádí nové možnosti správy úložiště, jako je vyrovnávání zátěže.
Vestavěné jsou distribuované souborové systémy jako OpenAFS a Coda logické systémy správa oddílů, která správcům umožňuje přesouvat velmi využívaná data do výkonnějších nebo méně využívaných počítačů. Pokud distribuovaný systém souborů podporuje duplikaci, mohou být kopie silně využívaných dat distribuovány na mnoha souborových serverech. To může snížit zatížení sítě a usnadnit práci serverů. Použití distribuovaných souborových systémů logické oddíly místo fyzických diskových oddílů, což usnadňuje přidávání nové volné paměti do sítě, když pracujete. (Přidání nového disku do místního počítače by nějakou dobu trvalo.)
Použití distribuovaných souborových systémů také usnadňuje sdílení softwaru a hardwaru. Předtím se však musíte ujistit, že licence pro programy, které používáte, umožňují instalaci softwaru do distribuovaného systému souborů. Tiskové servery jsou jedním z původních důvodů pro vznik prostředí<<клиент-сервер>>. Distribuované systémy souborů také usnadňují sdílení specializovaného hardwaru tím, že se přes síť připojují k počítači, který má nainstalovaný hardware, a přitom má stále přístup k vašim datům.
Použití centralizovaného, distribuovaného systému souborů může klientským systémům poskytnout významné výhody z hlediska nákladů a výkonu. Distribuované systémy souborů výrazně snižují náklady na hardware tím, že minimalizují množství paměti na jakémkoli stolním počítači nebo notebooku. Použití distribuovaného systému souborů jako archivu pro uživatelská data obvykle znamená rychlejší spouštění pro klientské počítače, protože velké množství dat již není uloženo lokálně, a proto není nutné je ověřovat po restartu klienta. Kombinace distribuovaného systému souborů a použití žurnálovaných systémů souborů na klientských počítačích může poskytnout významné zvýšení rychlosti spouštění systému.
Podpora offline zpracování dat.
Použití distribuovaného systému souborů zvyšuje závislost počítačových systémů na síti. Tato závislost na datech, ke kterým mají lidé přístup pouze přes síť, vyvolává některé zajímavé problémy pro uživatele notebooků/mobilních počítačů, kteří potřebují mít přístup ke svým datům, i když přístup k síti není možný. To se nazývá<<автономная работа>> systém musí fungovat, pokud zdroje, které jsou obvykle přítomny v síti (například uživatelská data), nejsou z nějakého důvodu dostupné. Dokonce i Windows poskytuje GUI, které vám umožní označit soubory, se kterými chcete pracovat, když jste offline, a synchronizovat tyto soubory, když se znovu připojíte.
Distribuované souborové systémy Coda a InterMezzo, které jsou v současné době dostupné pro Linux, také poskytují integrovanou podporu životnost baterie. V současné době se také pracuje na poskytnutí této schopnosti pro souborové systémy NFS. Coda a InterMezzo jsou již podporovány linuxovým jádrem Podpora Intermezzo byla zabudována do jádra od verze 2.4.5 a Coda byla obecně integrována do jádra 2.4 od samého začátku.
Coda je distribuovaný souborový systém s původem v OpenAFS, který je vyvíjen na Carnegie Mellon University od roku 1987. InterMezzo je relativně nový distribuovaný souborový systém, který se zaměřuje na vysokou dostupnost, flexibilní duplikaci adresářů, podporu offline operací a trvalé ukládání do mezipaměti. Tvůrci InterMezzo se inspirovali CMU Coda, ale tento projekt není založen na zdrojový text Coda. Původní tvůrce InterMezzo, Peter Braam, byl několik let vedoucím projektu Coda na CMU a poté začal sám vyvíjet InterMezzo a několik dalších projektů.
Rozšíření souborových systémů pomocí webu.
Před distribuovanými systémy souborů bylo sdílení souborů po síti omezeno na jednoduché přenosy souborů pomocí přenosového protokolu FTP soubory(Protokol přenosu souborů). Příchod World Wide Web značně zjednodušil proces práce s FTP, nyní nepotřebujete znát příkazy, protože protokol FTP je integrován do většiny prohlížečů. Schopnost snadno přenášet soubory přes web také vedla k rozšíření webu a významným vylepšením základního protokolu pro přenos hypertextu.
HTTP (HyperText Transfer Protocol), který je nyní základem mnoha distribuovaných systémů pro sdílení souborů.
Nejznámější z nich je WebDAV, což je zkratka pro<
Podpora WebDAV je zabudována do mnoha oblíbených webových serverů, jako je Apache, kde se spoléhá na autentizační mechanismy serveru. (Od jednoduchých souborů .htaccess po integrovaný mechanismus ověřování NIS, LDAP nebo dokonce Windows). Použití WebDAV pro přístup a úpravu souborů přes web je zabudováno do operačních systémů Mac OS X, v nových verzích Internet společnosti Microsoft Explorer a je k dispozici také v systému Linux pomocí aplikací, jako je správce souborů Nautilus. I když to není souborový systém v tradičním slova smyslu, můžete dokonce připojit WebDAV v Linuxu pomocí zaváděcího modulu jádra zvaného davfs.
WebDAV poskytuje funkce standardní pro distribuované systémy, jako je zamykání souborů, vytváření, přejmenování, kopírování, mazání souborů a podporuje také pokročilé funkce, jako jsou metadata souboru (podrobnější informace o souboru, názvu, předmětu, tvůrci atd.) d ). V blízké budoucnosti bude WebDAV zahrnovat integrovanou podporu verzování, která mnoha uživatelům usnadní práci na sdílených souborech sledováním změn, autorů těchto změn a dalších aspektů celkového použití dokumentu. Tyto možnosti verzování jsou poskytovány prostřednictvím protokolu DeltaV, který se aktivně vyvíjí Pracovní skupina DeltaV (http://www.webdav.org/deltav) divizí Internet Engineering Task Force (IETF). Některé projekty, jako je Subversion (http://subversion.tigris.org/) (nahrazení standardu CVS založené na WebDAV a DeltaV), jsou již dostupné v alfa verzi. Subversion poskytuje správu verzí a archivaci souborů na základě databáze, která má Jazyk API C a modeluje verzovaný souborový systém, který je snadno dostupný přes web.
