OpenAFS – úvod

21. 4. 2011 | Michal Švamberg | Návody | 11054×

Globální distribuovaný síťový souborový systém AFS existuje již řadu let, avšak mnoho lidí jej nezná. V tomto seriálu představím jeho implementaci v podobě projektu OpenAFS. První díl se věnuje vzniku, výhodám i nevýhodám jeho použití a architektuře.

Obsah

• Historie
• Architektura
• Základní pojmy
• Pro a proti
  • Výhody
  • Nevýhody
  • Proč mít AFS?
• Závěr
  • Poděkování

Historie

Plným názvem Andrew File System vznikl na známé americké univerzitě Carnegie Mellone jako součást projektu Andrew. Tento projekt měl za úkol vybudovat IT infrastrukturu univerzity (typicky správa softwaru, konfigurace serverů, jednotné prostředí uživatelům, správa účtů, ...). Pro potřeby projektu byl navržen nový souborový systém – AFS.

Původně se používala implementace od firmy Transarc Corporation (založena roku 1989 lidmi z CMU za účelem komercializace AFS), kterou roku 1994 koupila IBM a vytvořila z ní IBM Pittsburgh Lab. IBM se dále pokoušela prodávat AFS jako součást DCE/DFS (Distributed Computing Environment / Distributed File System), avšak v roce 2000 uvolnila zdrojové kódy v podobě projektu OpenAFS. Dále udržovala komerční variantu DCE/DFS, která se ale od roku 2005 již nevyvíjí. Mezitím se okolo OpenAFS vytvořila velmi silná komunita, která převážně vzešla z uživatelů Transarc AFS. Nyní se velmi intenzivně pracuje na rozšíření standardů, vylepšuje se kód a přidávají nové funkce.

OpenAFS je jednou z implementací AFS standardu, přesto se dnes často tyto pojmy zaměňují, protože v produkčních prostředích se používá výhradně OpenAFS. Existují další síťové souborové systémy, které jsou blízké AFS, jsou jimi Coda, InterMezzo, jehož vývoj přešel do projektu Lustre, nebo Arla. Žádný z nich ale nemá tak silnou vývojářskou základnu a širokou podporu operačních systémů jako OpenAFS.

Architektura

AFS je postaveno na komunikaci protokolem UDP a má rezervovány porty 7000-7009, další porty pro nové služby přibývají. AFS podporuje prozatím pouze protokol IPv4. Na obrázku je uvedena ukázková buňka foo.bar a základní zjednodušené schéma komunikace mezi jednotlivými komponentami infrastruktury pro AFS.

Strana klienta je relativně jednoduchá. Klient má lokální cache, nejčastěji na disku a komunikuje s AFS servery. K AFS je možné přistupovat bez ověření, ale vhodnější je autentizovat a vytvořit si tzv. AFS token. V Linuxu se vytvoří na základě ověření vůči KDC, které je uloženo v tzv. KRB tiketu. Pro uživatele lze nastavit tyto operace automaticky přes PAM moduly. Je zde jedno omezení, disková cache si neumí poradit s každým souborovým systémem, nejčastěji je doporučováno použít ext2/ext3 na samostatné partition nebo přepnout cache mechanismus do paměti.

Servery se skládají z několika samostatných procesů, které komunikují jak mezi sebou tak s klientem. To umožňuje vysokou škálovatelnost AFS. Základní schéma je však typické pro všechny – vždy na ně dohlíží BosServer, který je také ovládá. Servery lze rozdělit do několika skupin: databázové, jež se starají o některou z databází, souborové, které spravují data a na ostatní jako jsou zálohovací.

Každý ze serverů (DB Server, FS Server, ale i KDC Server) může být provozován na různém fyzickém stroji i různém operačním systému. Databázové servery se provozují nejčastěji ve trojici, vždy ale v lichém počtu. Počty ostatních serverů rostou s vaší potřebou.

Základní pojmy

V úvodním dílu nelze popsat a vysvětlit úplně vše do detailu. Přesto se pokusím stručně popsat základní pojmy, které se budou používat nejčastěji a objevují se také v obrázku.

Volume

je nejmenší entita, kterou lze v AFS spravovat. Je to část adresářového stromu AFS. Tento výřez adresářového stromu je konečný, tj. nejsou v něm smyčky (nepočítají se symbolické linky). Lze si to připodobnit k logickému volumu (oddílu) v LVM, který můžete do svého adresářového stromu kamkoliv připojit. Takových volumů můžete vytvářet tisíce a vzájemně propojovat. Tak jako s logickým oddílem v LVM můžete provádět různé operace, aniž by se to dozvěděl uživatel, lze to samé dělat i s volumem, například přejmenování, přesunutí, změnu velikosti (řešeno formou kvóty) či vytvoření snapshotu. Volumy jsou spravovány file serverem a jsou fyzicky ukládány na určené storage systémy (HDD, diskové pole, SAN infrastruktura) připojené jako /vicepX. Pro opravy volumů se používá proces Salvager, což lze chápat jako obdobu fsck. Pokud je potřeba provést nějakou administrativní operaci s volumem, postará se o to proces VolServer. Informace o volumech jsou uchovávány v databázi o kterou se stará proces VlServer na DB serverech.

AFS buňka (AFS Cell)

je administrátorsky nezávislá část AFS, která je složená z volumů, jež je ve vaší správě. Je to tedy celý adresářový strom, který je ve vašem vlastnictví. Ale nejen to, spadá pod ni celá vaše AFS infrastruktura s návazností na autentizační mechanismus protokolu Kerberos. Její název (Cell Name) vychází nejčastěji z DNS jména a lze ji k tomu také přirovnat – tentokrát tímto jménem neidentifikujete počítače ve vaší doméně, ale jednoznačně pojmenováváte vaši AFS buňku a její infrastrukturu mezi  ostatními. Pro náš seriál budeme používat doménu foo.bar s názvem buňky foo.bar.

Kerberos realm

je administrátorsky nezávislé prostředí pro  autentizaci. Jde o obdobný význam jako je pojem doména ve Windows. Zpravidla se vychází z DNS jména a zapisuje se velkými písmeny. Pro doménu foo.bar tak bude Kerberos realm FOO.BAR. Tak jako u AFS buňky si tímto jménem jednoznačně identifikujete prostředí pro autentizaci.

Principal

je unikátní identita, složená z uživatelského jména a Kerberos realmu, např.: afsadmin@FOO.BAR. Ve skutečnosti je daleko univerzálnější a lze do něj schovat identitu služby na stroji. O detailech principalu a autentizaci protokolem Kerberos si můžete přečíst v článku Kerberos: přihlašování snadno a rychle

Lístek (Ticket)

je časově omezené pověření od Kerbera, nejčastěji vydané proti kombinaci uživatelského jména (principalu) a hesla příkazem kinit.

Token

je časově omezené pověření pro AFS vygenerované na základě ticketu. Tokenem se budeme prokazovat AFS serverům při požadavcích o data či administrátorských operacích. Při tvorbě tokenu příkazem aklog se propojí identita ve vašem Kerberos realmu a AFS buňce. Uživatelé a skupiny v AFS jsou spravovány procesem PtServer.

AFS klient

náleží ke své domovské buňce, ale má přístup k  ostatním buňkám, kde se nejčastěji tváří jako anonymní uživatel.

Pro a proti

V úvodním článku o AFS nebudeme zabíhat do podrobností. A tak jen přehledově ty nejzásadnější rysy tohoto zajímavého, ale málo známého síťového souborového systému.

Výhody

Nejmarkantnější výhodou oproti jiným souborovým systémům je rozsah administrátorských možností a správa celého systému.

AFS umožňuje mít data na několika serverech s několika úložnými zařízeními, dnes nejčastěji ve formě diskových polí. To umožňuje nejen velkou škálovatelnost, ale i ochranu proti výpadkům. Můžete mít více replik na různých serverech, v případě výpadku vámi používaného serveru se AFS klient automaticky obrátí na další nejbližší kopii dat, která požadujete. Co se týká škálovatelnosti, není problém do systému kdykoliv přidat další server nebo další úložné zařízení. Existuje také možnost, propojení jednotlivých buněk a realmů (tzv. cross realm), že můžete vzájemně mezi sebou spolupracovat a nepotřebujete k tomu další účet, použije se pověření z vaší buňky.

Adresářová struktura používá jednotný jmenný prostor odvozený od DNS domén, to mu umožňuje být nezávislý na umístění serverů i klienta. AFS je postavené tak, aby jste mohli svým klientem nejen přistupovat ke svým datům ve své buňce, ale k datům všech buňek na celém světě, pokud vám to nezakáží oprávněními. Váš klient může být kdekoliv, přesto se dokáže připojit ke svému domovskému prostoru, ale i k ostatním AFS buňkám a jejich datům. Jakmile nastartujete klienta, bude vám celý AFS svět ležet v adresáři /afs a nemusíte provádět žádné jiné administrátorské zásahy, jako je například mount.

Cache u klienta umožňuje překlenout krátké výpadky a výrazně zlepšit odezvy při práci se souborovým systémem. AFS je velmi dobře škálovatelné a je odolné vůči výpadkům konektivity mezi lokalitami. To je zajištěno možností násobné redundance databázových serverů a replikací dat. K dispozici jsou vícenásobné read-only repliky (kopie). Samozřejmostí je široká podpora různých platforem (Linux, MacOS X, Windows, IRIX, AIX, Sun, ...) pro klientskou i serverovou část AFS.

Nevýhody

Ne vše, co je v této kapitole uvedeno, je přímo nevýhoda. AFS je poměrně rozsáhlý souborový systém a podle toho vyžaduje i některé věci, které by mohly odrazovat od jejího nasazení. A z tohoto důvodu jsou zde uvedeny.

Na odstranění většiny níže uvedených nevýhod se pracuje, avšak my se budeme orientovat na stabilní vydání v Debianu, kterou je v době psaní článku verze 1.4.12 pro Lenny nebo 1.4.14 pro Squeeze. Důvod je prostý, tyto verze používám a mohu tak ověřit to, co zde publikuji. Rozdíly v ovládání celého systému OpenAFS jsou minimální a neměly by být ani s příchodem verze 1.6, což by mělo nastat ještě letos (do poloviny roku 2011).

V době, kdy po mnoha letech čekání došly IPv4 adresy, je třeba konstatovat, že OpenAFS podporu pro IPv6 nemá. Pro provoz je nutné mít Kerberos a DNS server pro vlastní doménu, a to i v případě, že si chcete OpenAFS vyzkoušet třeba na notebooku. AFS používá vlastní UID, GID a ACL čemuž se nelze divit, když má mít jednotný jmenný systém. Tato vlastnost je zařazena mezi nevýhody, protože ji musíte vysvětlovat uživatelům. OpenAFS není dle normy POSIX, protože například nemá zařízení v /dev/, které by se dalo připojit. Nepodporuje hardlinky tak, jak jsou známy z běžných souborových systémů. Používá šifrování DES a fcrypt, jež jsou dnes překonané. Zatím nemá RW replikaci, která by se často velmi hodila. Na straně linuxového klienta je potřeba provést kompilaci kernelového modulu, ale oproti dřívějšku se podpora v distribucích znatelně zlepšila. Pro Windows existují předkompilovaní klienti včetně části podpory autentizace vůči Kerberu.

Proč mít AFS?

Pokud pomineme důvod mít něco extra, tak je to zvláště důraz na zabezpečení přístupu a ochraně dat uložených na AFS. Dále tu máme velkou odolnost proti výpadkům konektivity i samotných serverů což s možností škálovatelnosti (přidávání dalších serveru či diskových prostorů) což jej dělá opravdu silným. A jako správci oceníte výbornou dokumentaci a hlavně celou správu souborového systému, jíž se budeme věnovat ve většině dílů tohoto seriálu.

Když jsem s AFS začínal jako uživatel, přirovnával jsem jej k NFS, pro uživatele opravdu vypadá podobně a dělá to co by očekával – poskytuje diskový prostor přes síť. Toto srovnání, ale okamžitě padlo po tom, co jsem pronikl do AFS jako jeho správce. Při porovnání s NFS nebo CIFS vám dává AFS možnosti (přesun dat, zálohování, nastavení práv, rozložení zátěže, replikace dat, ...), které lze aplikovat za běhu systému bez toho, abyste ovlivnili přístup uživatelů k datům.

Závěr

Pokud o AFS uvažujete, měli byste si pomalu připravit svoji infrastrukturu. Rozhodně budete potřebovat Kerbera (na implementaci nezáleží). Pro svoji doménu musíte mít také DNS server, pouhý /etc/hosts nestačí. Všechny servery i klienti musí mít synchronizovaný čas, ten se nesmí rozejít o více než 5 min. Ideální je použít nějaký NTP server.

Instalace OpenAFS včetně Kerberos serveru není zcela jednoduchá. Každá distribuce na to má svůj návod nebo skript, který vám rozchození usnadní. Na základě znalosti základních pojmů a návodu z distribuce by se vám mělo podařit nainstalovat Kerberos server i OpenAFS servery. Případná kompilace OpenAFS klient se proti tomu bude jevit jako hračka.

Proto příští díl bude čistě praktický a pouze o instalaci celé infrastruktury OpenAFS. Ačkoliv z výše uvedeného popisu se může zdát, že zprovoznit cukrovar*) oproti AFS je legrace, zvládneme v příštím díle základní instalaci AFS během jedné hodiny. Nainstalované OpenAFS využijeme v dalších dílech, kde se jej budeme učit spravovat, provozovat a používat.

*) Pojem cukrovar se na ZČU vžil při  oživování a seznamování se s portálovými technologiemi jako přirovnání složitosti výroby tak jednoduché a běžné komodity.

Poděkování

Velmi děkuji Radoslavu Bodó (známý též jako Bodík), který mi poskytl k seriálu cenné rady, provedl technickou recenzi dílů, nakreslil úžasné obrázky a donutil mě zlidštit text.

Centrum informatizace a výpočetní techniky pro Západočeskou univerzitu v Plzni buduje a provozuje od roku 1996 prostředí Orion založené na autentizačním systému Kerberos a distribuovaném síťovém souborovém systému AFS s více než 22 tisíci aktivních uživatelů.

       

Komentáře

[Marv-CZ]

Výborný článek. Kdysi jsem chtěl v jedné firmě AFS použít, ale složitost mě nakonec odradila a použil jsem Gluster. Až se do toho zase někde budu chtít pustit, tak to určitě díky těmto článkům půjde.

[ch-in-A]

pekny uvod, velmi me navnadil na budouci dily :)

[cuba]

Díky Liste, kolik máš připraveno pokračování? Č++

[List]

Zdar, původně to mělo být jen pár dílů, ale trochu se mi to trochu vymklo kontrole, takže ještě budeš mít co číst. List.

[stativ]

Na AFS mě neskutečně štve jedna věc – modul do jádra. Vrtat se ve zdrojácích AFS po každém upgradu jádra stojí za prd (už jsem to vzdal).

[Ferš]

Dobrý den,

u nás ve firmě (WinStrom s.r.o. a SoftEU s.r.o.) OpenAFS používáme. Jsme poměrně malá firma (cca 20 lidí). Je pro nás důležité mít technologie o které se nikdo nemusí starat. Prostě se to nainstaluje a pak běží a musí to být maximálně spolehlivé. Pro instalaci jsme si najali odborníka, který s OpenAFS měl zkušenosti.

Zde jsou důvody, proč jsme na OpenAFS přešli: http://blog.softeu.cz/afs/

Ale nyní ho opouštíme. Vede nás k tomu několik důvodů.

- špatná podpora Windows. Na Linuxu všechno šlape poměrně dobře. Na Windows s tím máme potíže. Pořád se to na některém počítači přestává fungovat. - na windows je poměrně složité nastavení (cca 10 až 15 kroků, které se musí nastavit). - občas se to zblázní a musí se opravovat Volume (VolSalvage) - balíček není součástí standardního jádra a tak musíme kompilovat balíček. To nám dělá problémy na různých virtuálních serverech (Xen). Ale to je řešitelné - i když pracné.

Nejvíce se mi na tom líbila: - vysoká bezpečnost - možnost replikace (ro)

Takže to teď opouštíme a přecházíme zpět na sambu. Pokud je pro vás důležitá bezobslužnost, OpenAFS pro vás není.

Petr Ferschmann

[List]

Zdar Petře,

na straně klientů jsou potíže, ale poslední verze pro windows (1.5 a 1.6) jsou hodně přepracované a mělo by to být snažší. Kompilace na linuxu je trochu opruz, ale dkms v debianu to řeší docela hezky. Taky existuje FUSE klient, nemám s ním žádnou zkušenost.

Zkusím se v nějakém díle otřít i o klienta na windowsech, snad to nevyvola flame war.

Díky za podnět. List.

[kralyk z abclinuxu]

Je stále ještě SMB/Samba tak pomalá?
Onehdá jsem něco přenášel mezi Win7 a Linuxem pomocí SMB a přišlo mi to nějaké pomalé. Tak jsem nasadil FTP a byl 4x rychlejší...

[VSi]

Rychlost záleží na hodně věcech, zkušenosti jsou různé. Bez nějakého zvláštního ladění je limit linuxové implementace (jak server tak klient) kolem 30-40 MB/s na GbE (klidně napřímo bez switche) - což by i odpovídalo cca tomu 4× rozdílu. Tohle by měl snad řešit SMB2 protokol, a viděl jsem komentáře o plně vytíženém GbE mezi dvěma Win2008; vyzkoušené nemám.

Co jsem naopak zkoušel je dostat ze Samba serveru víc jak 30 MB/s v jednom streamu, a nic moc nepomohlo, tak jsem toho nechal. NFS v tom samém případě nemá problém se 110 MB/s oběma směry. Zajímavé je, že při kopírování více souborů najednou z jednoho adresáře připojeného přes mount.cifs, se ten limit neprojeví, resp. při 3 souborech najendou jsem se dostal k 80 MB/s. Viděl jsem i zkušenosti, že propustnost nebyl problém - s Intel Eth kartami - ale pokud to s běžným (Broadcom Eth, HP ewitche) HW chodí blbě, a NFS nebo FTP dobře, tak to beru jako směrodatné.

[Bilbo]

U mně (klient WinXP, server Samba) to dalo na GbE asi 65 Mb/sec (i když je možné, že u těch XP to brzdil disk :). Síťovky na obou počítačích nějaký integrovaný shitový REaltek ...

[Heron]

Na normálním síťovém HW není. 95MB/s na GigaLAN. Není žádný problém tu síť saturovat.

[Luboš Doležel (Doli)]

Mně Samba dává tak 11 MB/s, NFS dává maximum, co zvládnou disky (takže až k 100 MB/s). Různé "tunění" parametrů socketu jsem v Sambě už zkoušel a nic z toho

[Heron]

Já už fakt nevím, co bych poradil :-/

Parametry samby ani síťovek nijak neladím. Samba je v základním nastavení CentOS 5 (exportuje home adresáře).

Síťovka na serveru (CentOS 5.6): RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

Na klientovi Windows 7 Ultimate 64b (desktop): Intel(R) PRO/1000 PT Desktop Adapter

Klient Windows 7 Professional 64b (notebook): Intel(R) 82567LF Gigabit Network Connection

Rychlosti: pokud to má klient v cache v paměti, jsou kolem 100MB/s. Jinak to pochopitelně brzdí disk.

Síťový switch mám udělaný v Mikrotik RouterBoard 450G ze 4 portů. S některými horšími přepínači jsem sice zaznamenal problémy, ale nikdy ne propad na 10% výkonu.

Jediný problém jsem zaznamenal do blogu Pomalá síť po výměně základní desky. K tomu jen dodán tolik, že teď ten stroj má 12GB RAM a rychlost je stále OK. S 4GB RAM to jelo nevysvětlitelně pomalu, po přidání paměti je to ok.

[eax]

Zaujimali by ma nejake benchmarky network filesystemov. Planujete nieco take spravit v buducnosti ?

Ako je na tom s vykonom povedzme nfs/afs/samba.....

Benchmark by mohol byt v style klasickych diskovych FS.

[List]

Benchmarky přeskočím, protože je to hodně časově náročné, sambě ani nfs příliš nerozumím a hlavně už takové srovnání existují, doporučují přečíst například tuto diplomovou práci.

[Roman]

Testování je opravdu časově hodně náročné, minulý rok jsem na toto téma zpracovával bakalářskou práci, testováno bylo pouze v domácích podmínkách a ne úplně nejideálněji, ale alespoň pro představu. Případnou kritiku vítám i když na té práci už moc nezáleží.

[Jiri]

Benchmarks jsou uplne na nic, protoze kazdy z techto sitovych systemu ma uplne jiny ucel. NFS je uplne na houby, protoze nema zabezpeceni. AFS ho ma, ale komplikace s nasazenim. SAMBA snad jenina funguje vsude, ale je to proste CIFS a urcene hlavne pro windows.

Suma sumarum Linux proste nemam poradny (dodelany) sitovy souborovy filesystem. A pak nekdo chce, aby se Linux rozsiril.

[Luboš Doležel (Doli)]

Jaké zabezpečení vám u NFS schází?

[Jiri]

NFS3 - nevim o jakem zabezpeceni mluvite, zadne tam neni. NFS4 - Ten samy problem jako AFS - snad jeste horsi.

[Luboš Doležel (Doli)]

Já o NFS3 nemluvím, to je prostě stará verze... Je fakt, že nasazení NFS4 není zrovna pětiminutovka, ale prostě to není nástroj určený k tomu, aby se dva kamarádi sešli a vyměnili si filmy.

[stativ]

Dovolil bych si nesouhlasit. Nastavení potřebné pro sdílení dat mezi kamarády (tj. neřešení zabezpečení a dalších „zbytečností“) se s NFSv4 dá, za pomoci ArchWiki, nastavit za deset minut.

[stativ]

Možná by se dalo zvládnout i za těch 5, když už člověk ví, jak na to.

[CEST]

IMHO mel na mysli chybejici zabezpeceni podobne jako u HTTP, SMTP, IMAP, POP3, FTP, Telnetu, VNC a dalsich, ktere proste nemaji za cil resit bezpecnost. U nekterych protokolu se pridaly bezpecnostni mechanizmy (HTTPS, SMTP TLS/SSL, IMAP TLS/SSL...), u nekterych proste nechteji vymyslet znovu kolo a tak zabezpeceni nechali na tech systemech, ktere zabezpeceni poskytuji - VPN (IPsec, OpenVPN), stunnel ...

Samozrejme, pokud budu chtit pouzivat NFS, zajistim si bezpecne spojeni mezi klientem a serverem a budu mit pod spravou zabezpecene stanice a cizi stanice nepustim.

[Max]

Docela si protiřečíte. Nejdříve říkáte, že AFS vše má, ale je komplikované nasazení a poté tvrdíte, že linux nic dodělaného nemá. Já si myslím, že vše je složité podle toho, jaké máte vědomosti.
Zdar Max

[Jiri]

Komplikovane nasazeni muze byt take to, ze jsou tam bagy, ze to nefunguje tak jak ma, a ze je tezke neco opravit, ci to cele spravovat.

Asi jsem to rekl spatne. Spise jsem me rici, ze AFS by mohlo byt ultimatni reseni, kdyby to opravdu vse fungovalo (jak ve windows tak v linuxu) a dalo se to spravovat jednuduseji.

Vite oni vedomosti nejsou vsechno. Clovek muze mit spoustu vedomosti, ale zdroje nejsou nekonecne. To znamena, ze kdyz nad necim clovek stravi 3 dny, tak od toho firmy daji ruce pryc, protoze je to neunosne drahe.

I kdyz Linux doma pouzivam, do firmy bych ho nedal (hlavne do malych firem). Prinasi to neunosne drahou implementaci, a pak take zpravu. Do male firmy se opravdu vyplati windows server. Je to levnejsi. Chapu, ze se mnou nemusite souhlasit, ale mam to nezcetne vyzkousene. Doplnim, ze Linux desktop ve firemnim prostredni muze vyuzivat malokdo, jelikoz nejsou programy. A kdyz uz ma clovek Windows stanice, tak je proste desetkrat jednodussi pouzivat Windows server.

[VSi]

Druhou část komentáře o celkové výhodnosti Win Server nebudu rozebírat. Něco na tom je, ale takto formulované a napsané to na linuxovém portálu trochu vede na flame.

S první částí v zásadě souhlasím. Můžeme srovnat složitost nasazení a správy NFSv3 nebo Samby vs NFSv4 vs AFS. Pro NFSv4 a AFS potřebujeme funkční Kerberos infrastrukturu. AFS je pro nasazení v méně rozsáhlém prostředí (1 fileserver) "zatíženo" tím, že umožňuje mít vše odděleno, více db serverů, více lokalit atd. A tohle všechno musí člověk nastudovat a pochopit. Sice to lze nastavit podle howto za 2 hodiny, ale stejně je třeba tomu rozumět. Horší je, když to pak z nějakého důvodu přestane fungovat, nebo co hůř - funguje to občas špatně a není jasné proč. Pak čím komplexnější je technologie a čím víc je tam různých spolupracujících částí, tím déle se obvykle hledá chyba. A nemusí to být ani bug. Další faktor je, že by to nemělo stát na znalosti jednoho člověka, takže potřebujete někoho dalšího, kdo se v tom plně orientuje, a ten bude zase stát víc peněz.

[rADOn]

Pro anglické slovo „volume“ se vžil krásný český termín „svazek“.

[Sten]

Nebo také „oddíl“, stejně jako máme „adresář“ a „složku“.

Na druhou stranu ve Windows XP (a možná to zůstalo) to bylo přeložené jako „hlasitost“

[the.max]

jasne. oddil je super. Pak clovek premejsli jestli je myslen oddil (volume) nebo ten druhy oddil (partisna na disku). Fakt uzasny. Pokud nekde vidim volume, tak mam na vyber 2 moznosti. bud a hlasitost (coz obvykle v kontextu byva nesmysl) a pak tedy zbyva ten spravny vyznam.

[Kvakor]

U oddíl versus svazek jsem spíš po svazek, minimálně u LVM to dělá menší zmatek kvůli problému zmíněnému výše. Je dobré respektovat Princip nejmenšího překvapení

PS: Složku versu adresář jsem tu už kdysi řešil ...

[Michal Vyskočil]

Všechny servery i klienti musí mít synchronizovaný čas, ten se nesmí rozejít o více než 5 min. Ideální je použít nějaký NTP server.

Není to spíš požadavek Kerbera, než samotného OpenAFS?

OpenAFS není dle normy POSIX, protože například nemá zařízení v /dev/, které by se dalo připojit.

Nejsem si jistý, že by souborové systémy musely mít vlastní zařízení v /dev, i když takové dd if=/dev/ext3 of=/dev/sda1 namísto mkfs má jistou eleganci .

[List]

Ano, je to ve skutečnosti požadavek kerbera, je to zkrátka úvodní díl. Upřesnění i dalších věcí bude v dalších dílech.

Ohledně POSIXu bylo myšleno tak, že ovladač AFS (kernelový modul) by měl vytvořit /dev zařízení (stejně jako to dělají ovladače pro disky) a nad tímto zařízením by měl fungovat afsd cache manager (klient). Stejně jako je nad /dev/sdaX souborový systém ext3. Samozřejmě je to to nejmenší, co by někoho mohlo trápit. Přiznám se, že normu jsem nečetl a vytáhl jsem tuto informaci z nějakých přehledů o vlastnostech AFS.

[Käyttäjä 11133]

NFS taky není posix compliant a nikoho to netrápí. :)

[Michal Vyskočil]

Ohledně POSIXu bylo myšleno tak, že ovladač AFS (kernelový modul) by měl vytvořit /dev zařízení (stejně jako to dělají ovladače pro disky).

Jasně, chyba byla na mé straně přijímače - děkuji za vysvětlení.

[Pavel Semerád]

To, že není POSIX, se týká chování toho filesystému a ne toho, že nemá zařízení v /dev. Jsou to třeba ty zmiňované hardlinky ale také třeba to, že při zapisování do souboru budou data na ostatních počítačích vidět až po zavolání close().

[frEon]

lamerska otazka: a jak je to rychle?

[List]

To hodně záleží na infrastruktuře, obecně lze říct, že je pomalejší než NFS nebo Samba, ale s rostoucím počtem klientů se poměr obrací. V případě klientů na 100Mb síti dosahují okolo 7MB (pozor na 'b' a 'B') u klientů s gigovým připojením je to o něco více, ale zde se naráží už na problém samotných serverů. Přestože servery v obou případech jsou připojeni na gigu, většinou to brzdí načítání z dat z disků. Velkou výhodou je, že rychlost je relativně konstantní i přes rostoucí počet klientů a jimi generovanou zátěž.

Další nárust propustnosti se očekává od přechodu na TCP/IP s podporou jumbo paketů/rámců a také rozšíření AFS o OSD (kód je hotový, teď se pracuje na integraci), které dokáže rozprostřít data přes více serverů a tím obejít "pomalost" diskových zařízení.

[Heron]

Zeptám se možná blbě, protože AFS neznám. Ale nedala by se rychlost zvýšit prostě jen doplněním další serverů? Tj, že by data byla rozložena (klidně i duplicitně, což předpokládám, že stejně jsou) na větším počtu HW a tedy by tato síť zvládala větší zátěž.

A další otázka, předpokládám, že ona rychlost 7MB/s je rychlost výměny informací po síti a nikoliv přístup k datům, které má klient nacachované u sebe. Tedy, typická rychlost přístupu k datům bude (bude?) spíše odpovídat rychlosti klientské cache.

[List]

Další servery zlepšují zvláště robustnost řešení a škálovatelnost formou rokladu zátěže. Pokud začne klient tahat velký soubor, bude jej tahat pouze z jednoho serveru, který si vybere (detaily v dalších dílech). Jiný klient může použít jiný server nebo ten samý, záleží na jeho preferencích. Rozšíření OSD (object storage data) tuto situaci řeší, kdy dělí soubory na menší části a rozhazuje je mezi jednotlivé stroje. Klient pak má možnost soubor číst nebo ukládat paralelně. Zkusím tuto záležitost popsat v některém z dalších dílů.

[List]

Zapoměl jsem odpovědět ještě na druhou část. Těch 7MB/s jsem před chvílí orientačně naměřil příkazem cat soubor | pv > /dev/null, pokusil jsem se vzít velký soubor (1GB) o kterém jsem věděl, že není v cache. Záleží samozřejmě na chování uživatele a s jakými daty pracuje, takže generálně to říct nelze, je to zkrátka cache.

[Heron]

Děkuji za odpovědi a těším se na další díly. Shodou okolností teď také řešíme nějaké distribuované uložiště dat (ovšem nikoliv přes lan, ale obecně přes internet), tak do úvahy zahrnu i OpenAFS, článek přišel v pravou chvíli.

[jara]

s/by jste/byste/g

Jinak hezky clanek.

[List]

Na tohle vždycky zapomenu, v příštích dílech by se tato obludnost neměla zjevovat.

[Max]

Pěkně, výborně, musím si to zkusit někde rozjet a podívat se, co to umí. O tomto jsem moc nevěděl, ale vypadá to velmi zajímavě.
Budu se těšit na další díly.
Zdar Max

[Max]

Dívám se na klienta pro windows a vypadá to tedy stejně jako Netware klient, tj. podporuje login script, mapování disků, přidává možnosti nastavování práv do pravého tl. myši na složce atd. a navíc bezpečnost je asi trochu někde jinde + serverové možnosti také. Moc se mi to líbí, hmmm :)
Že by zajímavá věc, která by nás spasila před nasazením AD a hlavně od licenčního pekla MS a samozřejmě tím i ceny.
Když jsem to totiž teď počítal, tak pokud cluster od MS, tak jedině s MS Serverem 2008 R2 a to navíc s Enterprise verzí, jejíž OEM verze stojí 59000,- bez DPH. Jsou potřeba min. dva servery, takže 2x 59000,-. Dále máme 250 CAL 2003, které se nedají upgradovat (jedině pokud bychom měli zakoupený SA, což nemáme), takže koupě 250CAL pro 2008, což je 50x2600,- cca 130 000,-. Ve finále tedy jen za licence cca 250000,-Kč a to jsme u OEM verze, která by nás ovšem u clusteru nemusela trápit. Nicméně za 250 000,- se dá pořídit slušný server, nebo začátek pro lepší diskové pole.
Další bonus, že člověk nemusí řešit USER CAL vs DEVICE CAL a hlídat jejich dodržování.
Hmm, uvidíme časem.
Zdar Max

[VSi]

Záleží asi na využití, ale AFS bych viděl spíš jako komplementární technologii k MS AD. AFS řeší jen síťový souborový systém, i když ten klient je z uživatelského hlediska hodně dobrý a podobný Novellu. Autentizace je plně závislá na Kerberosu, který lze ve Windows nastavit nezávisle na AFS (byl článek i tady na abclinuxu). Z pohledu klienta dává AFS stejný typ funkcionality jako CIFS. AD řeší mnohem víc, hlavně management funkce - Group Policy, přihlašování do Windows po různými systémovými účty - tohle AFS pokud vím neřeší vůbec. AFS je hodně zajímavá technologie, ale zároveň dost složitá na zvládnutí a asi i správu, takže z mého pohledu musí být pro její nasazení dost dobré důvody - ve srovnání se Samba/CISF pro Windows klienty.

Nakonec i na ZČU je AFS v provozu v kombinaci s AD (pro Windows klienty), a minimálně z pohledu uživatele to funguje dobře. Jenže hlavně ceny CAL jsou pro akademické zákazníky úplně jinde.

Jinak jsem moc rád, že se tu objevil tento článek, i pokračování vypadá slibně.

[Max]

Tak GPO je rozhodně dobrá věc, ale současné řešení je Netware a využíváme u něj jen file share a jako náhradu za GPO jsem implementoval logon script v podobě exáče, co zapisuje pár desítek / stovek hodnot do registru a tím nastavím vše potřebné. Tudíž přemýšlím zatím jen o náhradě Netware. Máme také exchange 2007, kvůli tomu ty CALy. O propojení s AD samozřejmě přemýšlím, ale zatím jen v nezbytné míře. Zatím mám jen nápady, třeba se vše změní, až to dám na papír a vše sesumíruji :). A pak to třeba dopadne úplně jinak, když to předhodím šéfovi :D.
Zdar Max

[VSi]

Pak stojí za to uvážit jako variantu i obyčejnou Sambu jako NT doménu. I pro 300 desktopů mě zatím výhody AD nepřesvědčily. Používáme také kombinaci logon skriptu + skriptu spouštěného při startu počítače pod systémovým účtem, který řeší nastavení, instalace a aktualizace sw. Výhodou Samby je pro mě možnost unixového stylu skriptování a jistota větší spolehlivosti, když klíčová část infrastruktury je na Linuxu. Ale pokud máte kvalitní lidi se znalostmi Win Server, je to asi z tohoto pohledu srovnatelné. V komerčním prostředí pak nezanedbatelnou roli má i cena těch licencí. U AFS je rozhodně plus v možnostech přístupu z Linux/UNIX prostředí, kde se Samba/CIFS zrovna moc nehodí.

[Max]

O tom také přemýšlím, ale AFS se mi zdá více jako vylepšený Novell Netware, na který jsou tu všichni zvyklý. Aspoň mám tedy takovou představu, že nastavování ACL funguje obdobně jako u Netware, tj. přes pravé tl. myši na složku (ve windows), což by mělo ulehčit správu (hlavně třeba kolegům), aspoň tak jsem to vypozoroval z obrázků win klienta.
Také si myslím, že mi toho nabídne mnohem více, jak samba a NT doména (výkonnost, kešování, možnosti klienta atd.).
Mno, uvidíme, bude to aktuální téma až za delší dobu, mezi tím se podívám na AFS, abych zjistil, co to všechno skutečně umí :).
Zdar Max

[online]

Ahoj Liste,

díky, za krásnej článek

online

[Věroš]

Jak je na tom AFS s limity? Mohu autora poprosit o zmínku v nějakém dalším dílu?

Zejména by mne zajímaly limity na velikost jednoho souboru, počet souborů v jednom adresáři a velikost celého filesystému.

Viz též: starý dotaz v mailing listu

[List]

Do prvního dílu se mi vešly pouze obecná omezení. Příští díl bude o základní instalaci AFS, tak aby jste si s ním mohli hrát sami na jednom počítači. Technické limity (velikost /vicepX, max. velikost souboru, atd.) budou pak zmíněny v dalších dílech. Od roku 2005, ze kdy je výše zmíněný dotaz, už se různé věci změnily. Pak je tu ještě druhá věc, a to jsou doporučené limity, tedy hranice, u které by neměly vznikat neočekávané problémy, vše od třetího dílu dále. Obecně mohu doporučit držet se limitů dle dokumentace (web nebo man), kde jsou uvedeny i případné potíže při jejich překročení (pokud je lze překročit).