OpenAFS – úvod (diskuse)

[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).