Dotaz: Zalohovani - co pouzit ?

[Softik]

Zdravim, chtel bych se zeptat co pouzit na prakticky funkcni zalohovani malych souboru. Potrebuji zalohovat 8 serveru ve kterych je 240 GB SSD na kterych bezi mnozina stejnych aplikaci a potrebuji je zalohovat na nejake uloziste. Idealne 12x zaloha / 24 hodin. Zkousel jsem zalohovani pres SUN Solaris 100 GB ramka jako cache, SAS vystup do saska s diskama a propagace pres 8 Gbps FC sit. Bohuzel to v linuxu nefunguje. Pouzite karty, ktere mam jsou Qlogic, nebo Emulex. Ani jedna podle vseho nema dostatecnou podporu v opensource linuxu a proste to padalo, kazdou chvilku do read only rezimu ( resenim by MOZNA bylo enterprise reseni - nevim ). Potom a aktualne mame isci a to jede silene pomalu, mozna proto ze to zatim je jen pres 1 Gbps sit. Pouzite disky byli bud SATA 7.2k nebo SAS 7.2k ( bylo to mixnuty a vzdy 2x 2 TB do raid 1 ).

Dodam, ze na kazdem fyzickem serveru je treba zalohovat 100-240 GB dat a kazdy server v teto velikosti ma kolem 1-3M souboru. Ma nekdo nejakou radu, jak toto vyresit ? Napadlo me pouzit SSD pole, ale to bych musel koupit k tomu vhodne disky a to je palka.

PS: Pouzivame Debian 7 64 bit a radic u vsech serveru je vzdy p410i

Odpovědi

[Josef Kufner]

Jak se ta data mění?

Pro automatické denní zálohování notebooku používám rsnapshot. Odzálohovat 1.3 milionu souborů o celkové velikosti 200GB po 100Mbps síti z SSD na magnetický disk zabere cca 30 až 50 minut.

Každá záloha je úplná do samostatného adresáře a k deduplikaci to používá hardlinky. Takže pokud se soubory moc nemění, je to vcelku efektivní. Navíc není potřeba žádný nástroj pro přístup ke starším datům – prostě tam leží vedle.

[Softik]

Meni se za 2 hodiny strasne. Jsou to herni servery, takze to kazdy hrac co se pripoji = zmena na disku. Tezko rict, kazdopadne tohle notebook nikdy neudela za 2 hodiny jakehokoliv provozu.

Delame rdiff-backup a to je zoufale neefektivni a jede to strasne pomalu.

[dustin]

Jakou potřebuješ hloubku historie záloh?

Co to je za soubory? Bude záloha konzistentní, když se neprovede ve snapshotu/nesyncnuté databázové keše atd.?

[Softik]

14 dni, zasadni problem nebude, neni tam ted zadna cache.

[dustin]

takže jestli jsem to pochopil, na těch serverech neběží žádná DB, jejíž konzistentní záloha by se musela řešit. A nevadí, když v jednom "snapshotu" budou soubory z různých časů, než zálohovací soft projde celou strukturu. Tak jako by to nevadilo např. na souborovém serveru, kde jsou soubory vzájemně nezávislé. Nebo to musí být snapshot filesystému v daném čase, tedy mezi soubory jsou nějaké vazby a ty musí být konzistentní?

Ptám se proto, zda vůbec rsync dostačuje, či zda by to spíš nebylo pro nějaký btrfs snapshot...

[Josef Kufner]

Rozdíl mezi rsnapshot a rdiff-backup je hlavně ve způsobu uložení dat, kde rspanshot je nesrovnatelně rychlejší a pohodlnější při přístupu ke starším zálohám. Jinak to vychází dost podobně, možná je rsnapshot trošku rychlejší neboť jen zavolá rsync napsaný v C namísto scriptu v Pythonu, který volá librsync. Těžko ale říct, jak velký to má vliv, úzké hrdlo asi vždy bude IO a nikoliv CPU.

[Josef Kufner]

Kdyby jsi to měl v SQL databázi, poradím ti, ať si nastavíš replikaci na druhý server. Když jeden umře, jen to přesměruješ na druhý a je to v pohodě. Navíc ten druhý nebude zatížen, takže se z něj bude lépe zálohovat.

[nyan]

Delame rdiff-backup a to je zoufale neefektivni a jede to strasne pomalu.

rdiff-backup je desna sr**ka. Jsem to kdysi zkousel, pak sem jednou zjistoval proc trva zaloha hodiny i pri zmene par souboru, a ten idiotskej soft vola fsync na *kazdem* souboru... naprosto uzasnej design, zvlast kdyz clovek zalohuje statisice/miliony souboru...

[PanZvedavy]

jaky je rozpocet?

[Softik]

Zatim zkousime predelat to zalohovani tak aby se to nejdriv natarovalo a pak jeste zazipovalo. Musime ale predelat ovladaci system, ktery k tem zaloham pristupuje. Koncovy zakaznik si totiz muze pres administraci vybirat vzdy libovolnou zalohu, ktera je krok po kroku. Ten soft jsme nevytvareli my, koupili jsme firmu a predelavame to k obrazu svemu, proto to musime zkusit. Pokud to nedopadne, ozvu se, vysledek bych mel znat do konce pracovniho tydne tj. do patku.

[Josef Kufner]

A co upravit tu aplikaci tak, aby místo zápisu do souboru používala nějaké key-value databáze? Bude to výrazně rychlejší a i s nástroji na správu. Pokud ta aplikace je napsaná slušně, tak by neměl být problém nahradit fopen za něco jiného podobného.

[dustin]

Vidím to úplně stejně. Mám pocit, že nový majitel chce nabízet funkcionalitu, se kterou původní produkt nepočítal a asi to nebude tak snadné vyřešit zvenku. Úprava aplikace by byla nejlepší a možná i dlouhodobě nejlevnější, stejně do ní budou muset zasahovat, rozvíjet, rozšiřovat, aby mohla žít do budoucna.

[PanZvedavy]

V prve rade bych se soustredil na funkcnost fc karet. Qlogic i emulex jsou zabehnuti vyrobci a na linuxu by to nemel byt problem...pokud to nejsou nejake horke novinky. Mam tu ted par Qlogic a bezi jak namazany s defaultnim kernelem(redhat 2.6.32-..).

Nevim jestli jsem ten popis pochopil spravne, ale zalohovat 8x 1-3 milionu?!? souboru kazde 2 hodiny...to asi nebude ukol pro 7.2k disky a co io? 2TB disky v raid1? Nejak mi to nejde dohromady....

[Max]

Je zde otázka konzistence dat. Když spustíš cokoli, rsync, tar apod., tak jim vždy nějakou dobu trvá celá záloha. První soubor začne zálohovat třeba ve 12:00, poslední soubor zazálohuje (dokončí zálohu) třeba ve 12:15. Během těch 15minut se může změnit cokoli, záloha je prostě nekonzistentní. To by u file serveru vadit nemuselo, tam jsou většinou jen dokumenty, obrázky apod. Nekonzistence dat ale může vadit aplikacím, hrám apod. věcem. U databáze třeba takový způsob záloh nepřipadá v úvahu.
Windows na toto mají stínovou kopii svazku (Volume Shadow Copy - VSS).
Linux na toto má LVM, nebo pak přímo FS, které umí snapshoty.
Je však třeba počítat i s tím, že app mají i nějaká data v ramce, takže to není 100% nejlepší řešení pro všechno.

Jinak my v jobu jedeme mj. Oracle RAC (dva servery HP DL380 + jedno společné uložiště HP MSA P2000G3), vše propojené přes FC a v serverech máme Brocade HBA karty. Oracle beží na Oracle Linuxu (RedHat / CentOS).

Některé věci mají přímo binární drivery od HP a hlavně, spousta věcí je podporována na RHEL/Suse, debian je vynecháván. Je tedy dobré zvolit nejen vhodný hardware, ale i vhodný systém.

Zdar Max

[pavele]

Nezkoušeli jste někdo R1Soft Hot Copy (hcp)? Mělo by to dělat VSS jako ve Windows.

[Max]

Jedna věc je VSS, druhá věc je, že při vytváření VSS serverové aplikace flushnou data (Exchange apod.). Nevím, jak přesně to funguje, na jaké úrovni, zda se přecijen nenajdou app., které takové věci neřeší apod. Z toho by pak plynulo, že to také není všespásné řešení.
Zdar Max

[Softik]

Maxi, to my meli do doby kdy jsme proto meli FC sit taky servery HP DL 370 G6 a BL460G6 + HP MSA P2000, vse propojene pres 8 Gbps FC a v serverech byl bud Emulex, nebo Qlogic. Ale podle nas je chyba v tom, ze pro tu FC sit jsme pouzili nevhodny opensource system ( Debian ), protoze treba ta FC sit pod WMvare beha uz dlouho bez potizi, ale jak to bylo primo na linux tak smula. Meli jsme na tech FC diskach i zavadec, protoze 6 z 8 serveru jsou blady a maji jen 2 pozice na hdd. Potom jsme zkouseli prave udelat vlastni storage a tj taky to HP DL 370 G6 s 96 GB ramkou pouzitou pro cachovani z toho vystup pres SAS do saska s diskama a propagovany pres Emulex kartu ( potom zkouseno pres qLogic ) a stejnej problem... Do 24 hodin to vzdy spadlo cele do read only rezimu...

[chsajarsa]

Zalohovat takovehle mnozstvi souboru kazde dve hodiny souborove je cesta do pekel. Jedna se o vcelku casty problem, ktery se resi uz spoustu let. NASky k tomu pouzivaji NDMP a i v tomto pripade bych pouzil nejaky blokovy zpusob, ktery budu nasobne rychlejsi. Pokud to chapu spravne, tak na tom solarisu sis vytvoril target a chces ho pouzit jako disk pro zalohu? Jinak nad iSCSI bych ani neuvazoval pokud to nesypes do nejake knihovny, ktera nic jineho neumi.

[Ivan]

Jo. to mas pravdu. Jde to i na urovni filesystemu, dneska malokdo pouziva veci jako dump/restore.

[Ivan]

Opravdu se meni svechny soubory? TSM to resi tak, ze pouziva neco jako inotify (ale na AIXu anebo na Woknech) a uklada si jmena zmenenych souboru do zurnalu. Diky tomu jsou inkrementalni zalohy rychle.