OpenAFS – prakticky o volumech a replikaci

27. 10. 2011 | Michal Švamberg | Návody | 2357×

Základní znalosti o AFS nám již umožňují, abychom si vyzkoušeli nějaký ucelenější blok příkazů. Dokončíme práci na kořenovém volumu tak, abychom se mohli podívat, jak vypadají ostatní AFS buňky ve světě. Přitom využijeme jednu z nejpoužívanějších vlastností AFS – replikaci volumů. Na závěr si ukážeme jak by měly vypadat konfigurace firewallu a NATu pro AFS.

Obsah

• Replikace volumů
• Připojujeme si svět
• Firewall
• Závěr

Replikace volumů

O replikaci mluvíme, když z RW volumu vytváříme RO volum(y) jako jeho kopie. Operaci vos release, která replikaci provádí, použijeme vždy, když chceme promítnout jakékoliv změny z RW do RO, a to včetně změny ACL nebo úprav mount pointů uvnitř volumu. Původní obsah RO není nijak zachován. K tomuto účelu se používají zálohovací mechanismy o nichž bude samostatný díl.

Již dříve jsem psal, že volumy root.afs a root.cell jsou nejdůležitější a rozhodně by měly být replikovány. To zatím ani jeden z nich není, například root.afs má jen RW kopii (vizte řádek 3 a výpis VLDB na řádkách 11-13):

~$ vos examine root.afs | nl
     1  root.afs                          536870912 RW          3 K  On-line
     2      afssrv.foo.bar /vicepa 
     3      RWrite  536870912 ROnly          0 Backup          0 
     4      MaxQuota       5000 K 
     5      Creation    Tue Feb 22 22:11:22 2011
     6      Copy        Tue Feb 22 22:11:22 2011
     7      Backup      Never
     8      Last Access Mon Mar  7 08:02:42 2011
     9      Last Update Sun Mar  6 18:09:49 2011
    10      1 accesses in the past day (i.e., vnode references)
       
    11      RWrite: 536870912 
    12      number of sites -> 1
    13         server afssrv.foo.bar partition /vicepa RW Site 

Na každém serveru lze vytvořit pouze jednu RO kopii, více jich stejně postrádá smysl, protože RO má sloužit zvláště jako prostředek pro zvýšení dostupnosti dat a rozložení zátěže mezi servery. Na serveru, který vlastní RW kopii, je vhodné vytvořit RO na stejné partition jako je RW, šetří se tak místem, na disk jsou zapisovány pouze rozdíly.

Napřed nadefinujeme (s administrátorským oprávněním, takže nezapomenout na  kinit a aklog), na kterou lokaci (server a partition) umístíme RO kopii. My máme pouze jeden server s jednou partition, ale to pro vytvoření a kontrolu stačí:

~$ vos addsite -server afsfs.foo.bar -partition vicepa -id root.afs
Added replication site afsfs.foo.bar /vicepa for volume root.afs

~$ vos examine root.afs | nl
     1  root.afs                          536870912 RW          3 K  On-line
     2      afssrv.foo.bar /vicepa 
     3      RWrite  536870912 ROnly          0 Backup          0 
     4      MaxQuota       5000 K 
     5      Creation    Tue Feb 22 22:11:22 2011
     6      Copy        Tue Feb 22 22:11:22 2011
     7      Backup      Never
     8      Last Access Mon Mar  7 08:02:42 2011
     9      Last Update Sun Mar  6 18:09:49 2011
    10      1 accesses in the past day (i.e., vnode references)
       
    11      RWrite: 536870912 
    12      number of sites -> 2
    13         server afssrv.foo.bar partition /vicepa RW Site 
    14         server afssrv.foo.bar partition /vicepa RO Site  -- Not released

Oproti minulému výpisu nám přibyl pouze řádek 14, přitom si všimněte, že na řádku 3 je identifikátor RO volumu stále nastaven na nulu. To znamená, že existuje pouze záznam ve VLDB a nemáme žádnou validní RO kopii (přestože číselný identifikátor byl rezervován už při vytvoření RW volumu). Provedeme tedy release a opět zkontrolujeme výpis:

~$ $ vos release root.afs 
Released volume root.afs successfully

~$ vos examine root.afs | nl
     1  root.afs                          536870912 RW          3 K  On-line
     2      afssrv.foo.bar /vicepa 
     3      RWrite  536870912 ROnly  536870913 Backup          0 
     4      MaxQuota       5000 K 
     5      Creation    Tue Feb 22 22:11:22 2011
     6      Copy        Tue Feb 22 22:11:22 2011
     7      Backup      Never
     8      Last Access Mon Mar  7 08:02:42 2011
     9      Last Update Sun Mar  6 18:09:49 2011
    10      1 accesses in the past day (i.e., vnode references)
       
    11      RWrite: 536870912     ROnly: 536870913 
    12      number of sites -> 2
    13         server afssrv.foo.bar partition /vicepa RW Site 
    14         server afssrv.foo.bar partition /vicepa RO Site 

Nyní je vše v pořádku, máme RW i RO kopie sesynchronizované, což nám dokazují řádky 3, 11, 13 a 14. Vidíme přidělený identifikátor RO kopie; ten je vždy lichý a o jedna vyšší než identifikátor RW volumu.

Tím nám ale vznikl trochu problém, protože AFS klient se primárně pokouší o přístup k RO volumu root.afs, což znamená, že bychom měli do /afs/ ztratit zápis. Ve skutečnosti klient používá mapovací tabulku s informacemi o volumech, které si typicky obnovuje jednou za hodinu. Pamatuje si, že k našemu RW volumu neexistuje RO, proto bude nejdéle ještě hodinu nabízet RW. Mechanismus mapování opět urychluje přístup k datům, protože se takto vyhneme opakovaným kontaktováním Volume Location serverů. Proto napřed použijeme příkaz fs checkvolumes, který mapování volumů pročistí. Dále uvolníme z klienta informace o volumech příkazem fs flushvolume. Cílem je, aby adresář (mount point) /afs byl brán z volumu root.afs.readonly což si ověříme příkazem fs examine. Při testech se mi stávalo, že to chvilku klientovi trvalo a to obzvláště, když pracovní adresář flush příkazů byl v dotčeném volumu.

~$ fs checkvolumes
All volumeID/name mappings checked.

~$ fs flushvolume /afs/foo.bar

~$ fs examine /afs
File /afs (536870913.1.1) contained in volume 536870913
Volume status for vid = 536870913 named root.afs.readonly
Current disk quota is 5000
Current blocks used are 3
The partition has 18395132 blocks available out of 19593852

~$ mkdir /afs/test 
mkdir: cannot create directory `/afs/test': Read-only file system

Abychom v kořenovém volumu mohli provádět změny, musíme si připojit jeho RW kopii, ale to můžeme udělat pouze v nějakém RW volumu, naštěstí máme ještě volume root.cell, kterému jsme RO repliku nevytvořili, klientovi tak nezbude nic jiného, než nám nabídnout RW. Pro jistotu si vynutíme mount point odkazující na RW (ale není nutné):

~$ fs mkmount -dir /afs/foo.bar/root -vol root.afs -rw

~$ cd /afs/foo.bar/root

/afs/foo.bar/root$ ls -A
foo.bar

Tím se nám podařilo vytvořit smyčku, kterou nám detekuje také find .. To důležité je, že jsme v RW kopii volumu a můžeme začít provádět změny.

Zvláště aby si administrátoři ušetřili práci a nemuseli pracně hledat RW volume nebo jej někde po kradmu připojovat jako teď, tak si připravují RW větev své buňky, uživatelům jej schovávají jako skrytý tečkový adresář:

/afs/foo.bar/root$ fs mkmount .foo.bar root.cell -rw

/afs/foo.bar/root$ ls -A
.foo.bar  foo.bar

Tuto logicky náročnější operaci se pokusím shrnout. Po vytvoření RO kopie nám ji začal automaticky klient nabízet. Problém nám nastal ve chvíli, kdy jsme chtěli do kořene zapsat. To lze udělat tak, že si vytvoříme nový mount point s vynucenou cestou k RW volumu. Vytvořit mount point lze v libovolném RW volumu a takový máme v podobě volumu root.cell v cestě /afs/foo.bar/. Po připojení RW volumu do /afs/foo.bar/root do něj můžeme zapisovat a to jsme chtěli. V této chvíli tedy máme RO a RW volumy připojeny na různých místech, a to dokonce tak, že nám tvoří smyčku, protože můžeme použít například cestu /afs/foo.bar/root/foo.bar/root/foo.bar/root. Na konci dílu dáme vše do původního stavu, předtím si ještě vytvoříme odkazy na jiné buňky abychom se mohli porozhlédnout po světě.

Připojujeme si svět

AFS klienta máme přednastaveného tak, aby se nesnažil při startu zjistit jak to vypadá ve světě, ale použil přímo volume root.afs ze své domovské buňky. Toto je doporučené řešení, protože nezpomaluje start systému snahou o kontaktování ostatních buněk. Problém je, že se nedostaneme nikam jinam, pokud si nevytvoříme statické mount pointy, obvykle v cestě /afs/world/. Existující buňky ve veřejném prostoru jsou dobrovolně registrovány u grand.central.org. Tento seznam známý jako CellServDB se pak přidává do distribucí a my jej použijeme pro vytvoření mount pointů do světa.

Ze seznamu musíme napřed vypreparovat názvy buněk (označeny prefixem >) a zbavit se všeho ostatního. Pro vytvoření mount pointu použijeme známý fs mkmount s parametry -cell a -fast, jenž nám vypne kontrolu volumu vůči VLDB a významně urychlí tvorbu mount pointů. Celá konstrukce není úplně nejhezčí, ale je funkční:

/afs/foo.bar/root$ mkdir world && cd world

/afs/foo.bar/root/world$ for i in `cat /etc/openafs/CellServDB | sed -rn 's/^>([^ ]*).*/\1/p'` ; do fs mkmount $i root.cell -cell $i -fast ; done

/afs/foo.bar/root/world$ ls grand.central.org
archive  cvs  doc  local  project  service  software  user  www

První přístup do adresáře vždy trvá delší dobu, pak už to docela jde. Vytvářet mount pointy na cizí root.afs volumy je také možné, ale v nich většinou naleznete podobné věci jako máme teď my, tedy odkazy do  ostatních buněk.

Z minula si ještě procvičíme nastavování práv. Přístup do adresáře world dáme pouze našim vlastním uživatelům, ať si každý administrátor své buňky vytváří svůj vlastní rozcestník. Primárně záleží na vaší bezpečnostní politice, zda dáte přístup všem nebo jen vybrané skupině (např. autentizovaným uživatelům v našem případě):

/afs/foo.bar/root/world$ fs listacl .
Access list for . is
Normal rights:
  system:administrators rlidwka
  system:anyuser rl

/afs/foo.bar/root/world$ fs setacl . system:anyuser none system:authuser rl

/afs/foo.bar/root/world$ fs listacl .
Access list for . is
Normal rights:
  system:administrators rlidwka
  system:authuser rl

Zrušili jsme oprávnění pro skupinu system:anyuser a místo něj přidali skupinu system:authuser. Příkaz lze rozdělit na dva samostatné, ale setacl umožňuje serializovat oprávnění, tak proč to nevyužít. Od teď musíte mít platný token pro buňku foo.bar pro přístup do adresáře world.

Nyní volume root.afs musíme releasovat, aby se změny projevily v RO volumu v cestě /afs.

/afs/foo.bar/root/world$ vos release root.afs
Released volume root.afs successfully

/afs/foo.bar/root/world$ cd /afs

/afs$ ls -A
.foo.bar  foo.bar  world

A nyní nezbývá než úklid v podobě zrušení mount pointu na RW kopii volumu root.afs:

/afs$ fs rmmount /afs/foo.bar/root

Firewall

Pokud se hodláte otevřít světu, měli byste upravit pravidla pro firewall. Pro klienty je to relativně jednoduché, stačí povolit port 7001 na UDP z celého světa, protože AFS file servery se nás mohou snažit kontaktovat zpátky, tzv. callback. Větší překážkou bývají konfigurace conntracku u NATu, který uzavře spojení předčasně, proto je vhodné zvýšit na firewallu tyto hodnoty v souboru /etc/sysctl.conf

net.ipv4.netfilter.ip_conntrack_udp_timeout=780
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=900

a zavést do systému příkazem sysctl -p.

Pro přístup klientů k vašemu serveru je třeba nyní povolit UDP porty 7000 (fileserver), 7002 (ptserver), 7003 (vlserver), 7005 (volserver) a 7007 (bosserver). Pokud nechcete být příliš restriktivní, můžete povolit celou skupinu AFS portů v rozmezí od 7000 do 7009 na UDP, a to všem potencionálním klientům. V případě veřejné adresy serveru by to mělo být celému světu.

Tím naprosto vyřazujeme funkčnost firewallu pro AFS porty včetně klienta. Důvodem u klienta nejsou jen zpětná volání (callbacks) jež se dají řešit nastavením firewallu, ale i možnost ladění a sledování. Součástí AFS je několik nástrojů pro vzdálené sledování jak serverů tak klientů. Pokud si někdo stěžuje na potíže, můžete si vzdáleně přečíst informace o klientovi. A z hlediska správce by byla velká škoda se o takovou možnost připravit.

Závěr

Koncept RW a RO volumů se může zdát v této chvíli trochu zmatený, ale berte to z pohledu velké organizace. Potřebujete mít co nejvyšší dostupnost, což vám zajišťují RO kopie rozprostřené přes více serverů, ale jako správci máte potřebu provádět v systému úpravy. Typickým příkladem je například softwarové vybavení, uživatelům nabídnete verzi v RO kopiích volumu, přitom sami můžete připravovat novou verzi v RW volumu. Až to budete mít vyzkoušené, provedete release a všichni uživatelé dostanou připravenou a odzkoušenou verzi programu. Když do toho zapojíte i systém mount pointů můžete mít pro každou verzi samostatné volumy (např. prog1.1, prog1.2) a jen uživatelům vyměňovat mount point. Pokud si někdo bude stěžovat na  problém, můžete jej řešit a ladit v RW části dané verze. Nezřídka se stává, že potřebujete tentýž program provozovat v různých verzích. Nepropadejte panice, v příštích dílech budeme s volumy opět pracovat a časem vám to přijde naprosto samozřejmé.

Nyní můžete zkoumat, jak to mají vyřešené na jiných AFS buňkách, můžete používat všechny informativní příkazy i na cizí buňky (například vos examine root.cell -cell grand.central.org nebo fs listacl). V příštím díle se vrátíme zpátky k oprávněním, uživatelům a skupinám, přitom budeme stále vylepšovat naši buňku.

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

[Max]

Výborný seriál. Měl bych ovšem několik dotazů :-/.
1) Umí klient pro windows spouštět po přihlášení scripty/programy? Ovšem pokud je stanice v doméně, tak je to samozřejmě zbytečné, ale zajímá mně to.
2) Lze nějak obnovit smazaný soubor/adresář? Příklad : Netware má takovou mezipaměť, smazaný soubor se většinou nesmaže a zůstane na FS a lze lehce obnovit. Windows zase mají shadow copy, která se může dělat v určitých intervalech (třeba každou hodinu, takže rollback je max hodinu), těchto stínových kopií může být třeba 30, co jen volné místo umožní, takže to lze použít i jako historii.
3) Přihlásím se na win stanici, všechno ok, disky se namapují atd., ale problém, kromě několika aplikací mi na serveru běží třeba nějaká služba pod nějakým uživatelem (třeba Webserver pod uživatelem ASPNET) a s tou službou potřebuji zapsat soubor na síťový disk. Zápis se většinou volá na UNC cestu. V případě win serveru by se uživatel sám ověřil pomocí NTLM a provedl úspěšně zápis do UNC cesty. Jak by to ovšem vypadalo u OpenAFS?
Díky
Zdar Max

[List]

Děkuji za pochvalu, avšak nevim, jestli vás potěším. S Windows nedělám, tak jsem alespoň požádal kolegu o jeho zkušenosti.

1) AFS klient neumí spustit skript po přihlášení, ponechává se to na systému/administrátorovi, že si nějak poradí

2) obnova není možná, jediná šance je použití backup volumu, jehož frekvenci vytváření můžete nastavit (typicky 1x za 24 hod, nejčastěji o půlnoci), backup volume může být jen jeden. Druhá možnost je vytváření pravidelného dumpu z cronu nebo zálohovacího SW a v případě potíží jej rozbalit. Další způsob je použití 'vos copy' z cronu a vybrané volumy takto klonovat a případně je rovnou připojovat do nějaké adresářové struktury. Zároveň by bylo vhodné napsat i skript, který odpojí a zruší staré volumy. V podstatě záleží na tom, kolik prostoru chcete obětovat a jak moc chcete být user friendly.

3) v linuxu se to řeší tak, že se vytvoří principal, tomu se vygeneruje klíč do keytabu z nejž si pak skript vyrobi listek a z listku token. Podobně by to mohlo jít i u windows, ale budete k tomu potřebovat Active Directory. A asi to nebude tak jednoduché a průhledné. Druhá, trochu bezbolestnější, ale méně bezpečná, cesta je, nastavit do daného adresáře práva zápisu pro IP adresu serveru (nelze to ale udělat přímo, musí se použít skupina). Místo jména uživatele použijte jeho IP, ale musíte ji zařadit do skupiny a právo nastavit až dané skupině, jinak to nefunguje. Ale pak tam bude mít zápis celý stroj!

Michal Švamberg

[Max]

Děkuji za odpověď, opravdu moc nepotěšila :-/. Jde o to, že nyní jedeme na Netware 5.1 a plánujeme se ho zbavit (přeci jen, nějaké mušky má a začíná se u nás šířit nekompatibilita mezi různými službami, co potřebují přistupovat na sdílený disk).
Cílem je větší server, na který se přenesou všemožné odkladiště, které máme všude možně bokem. Začal jsem si pohrávat s myšlenkou, že už by to chtělo nějaký druh HA, což v podobě MS + FS Cluster není zas tak levné a nemusely by na to být finance.

Rozhodně přejdeme na Active Directory a poté jsem si pohrával s myšlenkou OpenAFS jako souborový server s tím, že se ušetří many za licence a zbydou tak na pořádný HW, který umožní HA.
Mno, stejně asi žádná alternativa k MS serveru neprojde a možná je to dobře.
Zdar Max

[List]

Ještě k bodu 3, pokud použijete ověření na základě IP adresy, pak nepotřebujete AD ani token, zkrátka vás tam fileserver pustí na základě IP adresy. Pokud by vás něco zajímalo, klidně se na mě obraťte.