Dotaz: Prenos velkeho mnozstvi souboru

[methuz]

Zdravim, mam tu pomerne zapeklite zadani ukolu:

1) mejme dva servery spojene gigabitovou linkou

2) kazdy ze serveru je pripojen ke svemu vlastnimu SANu pomoci HBAcek

3) prvni ze serveru ma ze sveho SANu namountovanych 5 filesystemu (vsechno je ext3) ktere dohromady obsahuji cca 100 000 souboru o celkove velikosti 150GB

4) druhy ze serveru ma namountovany velky LUN ze SANu - mista je tedy dost

a otazka zni: jak dostat data z prvniho SANu na druhy pokud je na transfer dat vymezena 1 hodina? ;) (cela akce ma za ukol pouze zabackupovat data z prvniho storage, tudiz zachovani adresarove struktury, prav atd je podminkou)

Moznosti je relativne hooodne. Jde jen o to najit tu nejjednodussi a hlavne nejrychlejsi. Za kazdy napad predem diky!

---

---

Odpovědi

[Carth_Onasi]

Otazka: O jake soubory jde -> pomer a moznost komprimace. Smis komprimovat a jestli to pomuze?

[methuz]

male binarni soubory. komprimovat lze ale je to vcelku zbytecny - misto ani rychlost site neni problem. problem je tahani velkyho mnozstvi souboru vs. tahani jednoho velkyho. prijde mi ze nejlepsi varianta je asi tar+nfs ale mozna nekoho napadne neco lepsiho

[karlw]

tar rulez

[Michal Kubeček]

Problém je, že tar nezachovává (přinejmenším) ACL.

[karlw]

ale ale:

--acls

[Michal Kubeček]

A jaká verze? U mne (OpenSuSE 11.2) to dopadne takto:

mike@lion:~/work/foto/canon> tar -cf out.tar --acls out
tar: neznámý přepínač `--acls'
Try `tar --help' or `tar --usage' for more information.
mike@lion:~/work/foto/canon> tar --version
tar (GNU tar) 1.21
...

[karlw]

$  tar --acls --selinux -cf cosi.tgz blahblah.txt
$  tar --version
tar (GNU tar) 1.22
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
$ cat /etc/issue
Fedora release 11 (Leonidas)

[michich]

Podporu pro archivování rozšířených atributů (včetně ACL a SELinux kontextů) přidává do taru ve Fedoře patch. Nevím, proč to pořád ještě není přímo v GNU tar.

[Michal Kubeček]

Mám podezření, že vývoj (nebo aspoň údržba) GNU tar je poněkud problematický(á). Matně si např. vzpomínám na překvapivě dlouho přetrvávající bug v parsování parametru -L, který měly snad všechny distribuce opravený, ale v mainstreamu pořád zůstávával.

Nemůže tam být nějaký problém s kompatibilitou? Zvládne neopatchovaný tar správně rozbalit archiv, ve kterém jsou ACL a EA?

[karlw]

Příloha:

• test.tgz (277 bytů)

Jelikož jsem RH-centristický, tak mne to nepálí, ale můžeme vyzkoušet. Přikládám soubor test.tgz, který obsahuje test.txt uživatele 500:500, a má přes ACL povolený -w- pro uživatele nobody.

Pokud ho roztaruju na fs s mount option (rw,acl), tak se atribut pro nobody ukáže. Pokud ho roztaruju příkazem "tar --no-xattrs -xzf test.tgz" nebo pokud nemám acl povoleny na fs, pak tam ten atribut pro noname není.

$  tar -xzf test.tgz 
$  getfacl test.txt 
# file: test.txt
# owner: karlw
# group: karlw
user::rw-
user:nobody:-w-
group::rw-
mask::rw-
other::r--

Napište, jak jste s tím pochodili

[marbu]

Zdá se, že neopatchovaný tar prostě acl atributy ignoruje:

$ tar -xzf test.tgz
tar: Ignoruje se neznámé klíčové slovo „SCHILY.acl.access“ rozšířené hlavičky
$ getfacl test.txt 
# file: test.txt
# owner: martin
# group: users
user::rw-
group::r--
other::r--

[Michal Kubeček]

Chová se to rozumně, ignoruje to a vypíše hlášku

  tar: Ignoring unknown extended header keyword `SCHILY.acl.access'

[EE]

Podporu pro archivování rozšířených atributů (včetně ACL a SELinux kontextů) přidává do taru ve Fedoře patch. Nevím, proč to pořád ještě není přímo v GNU tar

Zaujala me ta otazka, tak jsem se po tom podival. Nove verze GNU taru vychazi v poslednich 4 letech zhruba jednou za rok.

Podle poslednich zprav jsou ty patche soucasti distribuovaneho tarballu, ale nelinkuji se, protoze ani po 4 letech (!) jeste nemaji produkcni kvalitu. O tom ostatne svedci ty uvedene priklady tady (#31 a #32), kde se klicove slovo rozsirene hlavicky vypisuje jako SCHILY.acl.access, pojmenovane podle autora (Jörga Schillinga) predchoziho formatu rozsirene hlavicky ([1], {2]). Tedy nepouziva to hlavicku ve formatu POSIX.1-2001, ale starsi 'star'.

Stejne by ale podle POSIXu snad uz nemel byt tar pouzivan ([1]). Misto toho je v POSIXu obsazen program a predepsan format pax. GNU tar se prave snazi implementovat ten tvar paxovych hlavicek, jak ho predepisuje POSIX.

Podle Jorga Schillinga ([1]) ale POSIX zadny standard ACL neobsahuje (Unix ACL != POSIX ACL ??). Predpokladam pak tedy, ze obsahuje alespon zpusob, jak je zaznamenat do archivu.

Priznam se, ze neni jednoduche se v tom zorientovat. Nez jsem se zacetl do vsech tech podrobnosti o tar-u, tak jsem nemel ani poneti, kolik je za tim vedy.

Abych to ale nejak shrnul:

• Linux pouziva nejakou nestandardni (a udajne dost jednoduchou) implementaci ACL
• zatim existuje jen navrh POSIXoveho standardu pro ACL (pouziva ho napriklad NFS4 a uz ho maji implementovane in Windows ve NTFS). Snad to pochazi ze Solarisu??
• archivni program star (slovni hratka na s-tar, chapete?), ktery take vytvari soubory .tar, implementoval jakysi prechodny format pro zaznam Linuxovych ACL. Ten format je ten "Schily.xattr..." a je to rozsireni starsiho typu hlavicky.
• GNU tar zatim neumi v produkcni kvalite nejnovejsi rozsiritelne hlavicky ve formatu pax, jak predepisuje POSIX pro archivy a proto obsahuje (rovnez neaktivovanou) implementaci toho 'star' formatu pro ukladani Linuxovych ACL

To je teda zmatek, co? Snad jsem to pochopil vsechno vice mene spravne. Jestli jsem siril nejake vyrazne bludy, tak se omlouvam.

[Michal Kubeček]

Linux pouziva nejakou nestandardni (a udajne dost jednoduchou) implementaci ACL

Nebyl by k tomuto tvrzení nějaký zdroj?

[EE]

Po opetovnem nekolikerem precteni odkazu, co jsem uvedl vyse, odvolavam svoje tvrzeni, ze Linux pouziva jednoduchou implementaci ACL. I kdyz je ta implementace technicky vzato nestandardni, tak stejny format pouzivaji vsechny rozumne OS, protoze zadny standard pro ACL proste zatim neexistuje.

Asi nejlepsi povidani o tom ma Wikipedie (aktualni ceska verze ma trosku vice informaci o neprijatem standardu).

[VSi]

Z praktického pohledu bych to shrnul následovně, běžně se používají:

- tzv. POSIX.1e ACL, která ovšem už nejsou součástí POSIX. To je implementace, kterou má např. ext3 nebo xfs připojené s volbou acl.

- tzv. NFSv4 ACL, které mají řekl bych největší budoucnost. Specifikace je součástí NFS verze 4. Hlavně jsou plně kompatibilní s NTFS ACL, používá je i Sun/Oracle ZFS a další. V Linuxu podopora zatím experimentální.

- lze se setkat třeba ještě s AFS (Andrew File System), který používá vlastní úplně speciální systém ACL v podstatě s ničím jiným nekompatibilní.

- zajímavý systém ACL měl Novell NetWare, tzv. Trustee Rights, které považuji za uživatelsky nejpřehlednější implementaci ACL, co jsem zatím viděl. Použitelnost NetWare ACL editoru se s tím, co je součástí Windows absolutně nedá srovnávat.

Hlavní výhodna NFSv4 ACL je jejich kompatibilita s "Microsoft" ACL, které se používají u NTFS a hlavně CIFS (Sdílení souborů). POSIX ACL nemají všechny vlastnosti (třeba dědění), takže např. Samba musí dělat různá kouzla, aby zobrazení a editace ACL ve Windows editoru alespoň trochu rozumně fungovalo.

[EE]

Pekny prehled informaci okolo ACL.

Snad bych jen vyslovne zduraznil, ze:

1. ten "standard" POSIX.1e nikdy nebyl prijat, takze technicky vzato to zadny stardard neni. Presto tu jeho cast popisujici ACL hodne OS a FS pouziva.
2. ani ten NFSv4 "standard" jeste nebyl prijat a odsouhlasen, ale prakticky se na nem obor shodl, takze to bude v nejhorsim pripade moderni obdoba situace s "POSIX.1e"

POSIX Access Control Lists on Linux (detailni popis)

[Sten]

rsync

[dustin]

Souhlasím. Pokud stačí vždy jen aktuální záloha a změn od minulé není zase tolik, musí rsync zvládnout zesynchronizovat 100k souborů do hodiny v pohodě. Obzvlášť pokud se spustí napřímo klient/server, bez režie ssh. Samozřejmě první kopírování bude trvat déle, ale i to by se do hodiny po gigabitu dalo stihnout.

Pokud by souborů bylo mnoho miliónů, žere rsync spoustu paměti, někdy nám ani nestačil limit paměti 3GB na 32-bitovém systému. Ale 100k souborů nic není, to jsou dva maildirové účty.

[Zdeněk Burda]

Zkoušel jsi změřit jak dlouho trvá lokálně soubory zabalit tarem? Zkus změřit jak dlouho trvá dump souborového systému. Abys to stihl odzálohovat za hodinu, musel bys zálohovat rychlostí přes 42MiB/s.

[Lithius]

Tar do roury netcatu a na druhem serveru z netcatu do taru. Otazka je, jak to asi muze byt rychle.

[Miklik]

Jako ostatní doporučuji tar a co nejlepší komprimaci (bzip2,lzma,...) aby se maximálně zmenšil objem přenášených dat. Na druhý server bych to asi přenášel přes nfs nebo ten netcat. Je třeba zkusit kolik co dá po síti. Je třeba asi najít správný poměr pro zatížení CPU kompresí a využití sítě.

Pokud by se to nedalo stihnou, tak by řešením mohlo být i vytvoření snapshotu. Nevím co přesně omezuje to 1h okno.

[marek]

Dobry den. Moje zkusenost: Malokdo ma dostatecne silne zelezo, aby si mohl dovolit komprimovat normalni soubory tak rychle, aby na vstupu byl tok alespon 1Gb/s. Takze komprimovat se nevyplati. Ale usifrovat to dost casto je mozne. Takze i nejjednodussi stokrat overeny prikaz:

tar -cf - /co_chci_kopirovat | ssh uzivatel@server "cat | tar -C kam_chci_kopirovat -xf -"

Ma jako uzke hrdlo rychlost disku. Je jenom otazka, zda to nedelat po celych diskovych obrazech - podle toho jaky ma vykon FS.

Marek

[AraxoN]

Ten cat tam je nadbytočný... ako aj parameter -f -. Malo by to ísť aj takto:

tar -c /co_chci_kopirovat | ssh uzivatel@server "tar -x -C kam_chci_kopirovat"

Taky by to mohlo jít takhle:

cd /kam_chci_kopirovat ; ssh uzivatel@server "tar -cf - /co_chci_kopirovat" | tar -x

[EE]

cd /kam_chci_kopirovat

Jak se jde "cd" do adresare na stroji, na ktery clovek jeste neni ani prihlaseny :)

Nemelo by to byt:

ssh uzivatel@server "cd /kam_chci_kopirovat ; tar -cf - /co_chci_kopirovat" | tar -x

[Michal Kubeček]

Ne, bylo to správně. Adresář, kam chcete kopírovat, musíte nastavit na tom stroji, na který kopírujete, tj. na tom, kde tar extrahuje.

[EE]

Aha, nejak jsem si popletl smery zalohovani a odkud se kam pripojuji. Uznavam, ze ten muj "opraveny" prikaz byl nesmysl, protoze to odkazuje na stejny stroj.

Z tohohle popisu

tar -c /co_chci_kopirovat | ssh uzivatel@server "tar -x -C kam_chci_kopirovat"

jsem si myslel, ze pomoci ssh se pripojuji na stroj, KAM CHCI UKLADAT TU ZALOHU ??

Misto toho se tedy pomoci ssh pripojuji na stroj, odkud budu zalohovat?

---

Aktualizace: Aaaaha, myslim, ze uz to chapu. Ty priklady vyse (prispevek 18 a 19) jsou svoje vzajemne opaky! V jednom pripade je sshd na stroji se zalohou ("18"), v tom druhem na stroji s originaly ("19").

Zatracene. Stydim se, jak mi to mysli pomalu :(

[dustin]

Je úplně jedno, ve kterém směru jde ssh připojení, jenom to pak ovlivňuje, zda se na vzdáleném stroji spustí tar v režimu vytváření archivu (-c) nebo rozbalení (-x).

[EE]

Jo, to je jasne. Jenze v tech prikladech vyse se popisuji rozdilne situace: v prispevku 18 je na stroji server (kde bezi sshd) zaloha, kdezto v prispevku 19 jsou tam originaly.

Snad jsem to nezvoral, protoze jestli ano, tak uz tomu vazne nerozumim. :(

Jde mi o to, ze na jednom z tech stroju (bud na originalu nebo na zaloze) nemusi bezet sshd, coz muze mit sve vyhody. Pokud na obou bezi sshd, tak tady vazne ztracime cas zbytecnostma.

[dustin]

Jasně.

Nicméně stejně pokud by mi záleželo na celkové době kopírování, jako tazateli, a stroje by byly rozumně přístupné, tak bych to určitě netahal přes ssh, ale rovnou netcatem.

[Heron]

Pokud jsou ty lokality daleko od sebe, tak bych naopak doporučoval ssh pro ochranu dat.

[EE]

Neni to snem kazdeho admina mit 2 stroje daleko od sebe a presto propojene gigabitem jako autor prispevku?

Osobne myslim, ze ma oba stroje v jedne mistnosti, ale nedalo mi to, abych si nerypnul.

[methuz]

;) v jedne mistnosti nejsou (jsou to nody HA clusteru a tam je stejna poloha krajne nezadouci) nicmene vzdalenost je "pouze" ve stovkach metru.

[Michal Kubeček]

nadbytočný... ako aj parameter -f -

U aktuálních verzí GNU taru ano. Obecně ne.

[marek]

Dobry den. Ten cat je tam skutecne nadbytecny, nicmene prida jeste jeden buffer. Za urcitych okolnosti to melo kdysi lepsi vysledky a ja uz se toho neumim zbavit.

Marek

[methuz]

mno vyzkousel sem nekolik variant a nejlepe zatim vychazi tar v kombinaci s nfs. zkousel sem vzorek cca 2000 souboru (4,2GB) prohnat tarem ze SANu na lokani disk druheho serveru pres nfs. rychlost byla lehce pres 170MB/s. da se rict ze sem vcelku spokojen. nicmene prave zkousim i dalsi varianty ;)

[Heron]

100 000 za hodinu to je 36ms na soubor o průměrné velikosti 1.5MB. Pro celek HW, OS, FS s latenci i kdyby jen 10ms to znamená přenést 1.5MB za 26ms tj 62MB/s. Tohle 7200 rpm (nenapsal jste HW, pokud tam máte 15krpm v raid10, tak se nemáme o čem bavit) disk, zvládne jen za předpokladu, že to tam poběží jako jediná úloha a ty soubory nebudou fragmentované. Ten úkol je hodně zapeklitý.

Pokud se ta data se nemění celá (celých 150 GB) a jen přirůstají, tak bych preferoval rsync. Na počátku to poběží hodně dlouho, ale pak už to bude jen zlomek té požadované hodiny. Tímto bych začal.

Pokud se ta data mění výrazně, tak bych se úplně vykašlal na soubory a přenášel bych přímo obraz těch FS. Což znamená ho na ten okamžik zálohy odpojit, nebo alespoň přepnout do režimu jen pro čtení. To pak poběží rychlostí toho gigabitu, kontinuální čtení nad 100MB/s dnes zvládne kde co.

[dustin]

Kopírování celého obrazu je samozřejmě nejrychlejší (za předpokladu, že je aspoň trochu zaplněn, takže nárůst přenášených dat není tak velký). Ale mám zkušenost, že se obě strany nesmí ničím jiným vyrušovat, pak jde samozřejmě rychlost do kytek. Ale to platí pro běžná disková pole mdadm, HW SANy neznám. Je také otázkou, zda je zamčení fs pro zápis po tu dobu akceptovatelné.

Na našem zálohovacím serveru kopírujeme raid1 mirrorováním, je to velice flexibilní, při zátěži rychlost synchronizace spadne, v klidu se zase rozjede, co dají disky. Po sesynchronizování se záloha udržuje aktuální, dokud ručně skriptem backup stranu neodpojíme (včetně umount/mount fs na primární straně, aby byl konzistentní). Ale tam jsou desítky miliónů souborů a rsync nepřichází v úvahu.

Zde mi ten rsync vychází stále nejlépe.

[EE]

Pokud se ta data mění výrazně, tak bych se úplně vykašlal na soubory a přenášel bych přímo obraz těch FS

Me by zajimalo, co byste doporucil delat s tim 150GB obrazem na druhe strane, tedy na tom stroji se zalohou. Ulozit to jako soubor? Flaknout to na vyhrazene misto na disku jako dalsi oddil (partition)? Ulozit to za vsechny dalsi oddily na disku jako dalsi extended partition?

[dustin]

Samozřejmě nejrychlejší je to uložit do nějaké další partišny, která by pak šla normálně namontovat. Ukládání do souboru na filesystému je pomalejší o režii FS, namontovat pak lze taky snadno přes loopback.

Tazatel bohužel za celou dobu neřekl, jak jsou vlastně ty oddíly velké, ale lze předpokládat asi výrazně více, než těch 150GB zaplněného prostoru.

[EE]

Ukládání do souboru na filesystému je pomalejší o režii FS

Jasne. Navic pokud clovek nema ta existujici data na oddilu, kam zapisuje tu zalohu, "sklepana", tak jeste hlava disku leta sem a tam jak zaplnuje diry ve FS. V kazdem pripade vykon jde brutalne dolu.

Taky bych daval prednost zapisu cele partition, kdyby ta data byla na jedne 150GB, coz zrejme nebude pripad tazatele, jak spravne uvadite.

[Heron]

Já bych ho dal do LV. Soubor na disku má jisté nevýhody jak správně píše dustin.

[EE]

Myslite udelat z nej dalsi virtualni partition na Logical Volumes?

Hmmm, to ma neco do sebe. Odpadaji starosti s problemy udrzet si poradek ve fyzickych oddilech na disku/discich.

Navic kdyz je to posazene nad mdadm, tak je to i chranene proti problemum s disky.

[Heron]

Ano, takto jsem to přesně myslel.

[l4m4]

Jak píší ostatní, pokud jde o udržování kopie, je nejlepší řešení rsync, především může-li věřit mtime, a v tom případě by to měl zvládnout i podstatně rychleji. Jinak ovšem musí těch 150 GB stejně přečíst (na obou stranách), tudíž platí pro něj platí stejné výpočty + komplikace dané složitejším algoritmem.

Ideální scénář, je-li možný, je vytvořit prvotní kopii pomalu, bez zátěže primárního serveru -- třeba za den. To se provede pouze jednou na začátku a tato kopie nemusí být konzistetní snapshot, stačí, aby byla dostatečně podobná a ušetřilo se při následném rsyncování. Pro vlastní zálohování se pak použije rsync.

[methuz]

To jsem ponekud zapomnel zminit. Potrebuji ty souboru pretahnout pouze jednou - denni zalohovani a vubec zalohovani je reseno uplne jinak ale bohuzel pomalu na to abych ho mohl vyzit i tady. rsync mi prijde na tenhle one-time job zbytecny. momentalne spis premyslim mezi tarem a dumpem filesystemu.

[dustin]

To je dost podstatná informace :) Stejně jako velikost těch fs (tj. míra jejich zaplnění - viz příkaz df), zda je lze po tu hodinu odmontovat, zda po tu dobu bude k diskovému zařízení přistupovat i něco jiného atd. Pak se lze rozhodnout, zda dd + netcat nebo tar + netcat.

[Käyttäjä 11133]

Vzít vlákno, propojit ty 2 SAN Fabric a udělat sync na úrovni těch polí? :)

[methuz]

ano, normalni clovek v idealnim svete by to udelal takto. ale nezijeme v idealnim svete (a zmineny SANy jsou na druhym konci naseho neidealniho sveta nez ja ;) )

[Käyttäjä 11133]

Tak pořád tam bude nějaký on-site, facility management, nebo někdo kdo umí zapojit kabel z jednoho portu SAN switche do jinýho, ne?

[methuz]

ne. je tam jen clovek co je schopen restartovat server. tlacitkem. (nastesti mame RSA karty...)

[EE]

RSA? Remote Secure Access? Neco jako tohle od Intelu nebo tohle od Dellu?

[Ash]

IMHO se tomu říká spíš Remote Supervisor Adapter, odkaz máte z té druhé vámi odkazované stránky IBM RSA.

[methuz]

ano, mel jsem namysli Remote Supervisor Adapter. Vcelku slusny popis je i na wiki. (http://en.wikipedia.org/wiki/IBM_Remote_Supervisor_Adapter) Snad jen doplnim ze do novejsich IBM masinek uz se dava nastupce RSAcka - IMM. Integrated Management Module (http://www.scribd.com/doc/13780646/IMM-Users-Guide - wiki jsem nenasel)