Dotaz: Síťové zálohování / RAID1 over network - co vybrat?

[Eregon]

Ahoj všem, stavím malou síť (v zásadě pro domácí potřeby), jejímž středobodem bude síťové úložiště dat. Většina HW je předem daná (zadáním je pokud možno maximálně využít stávající neslavné vybavení), takže ono centrální úložiště má být vytvořeno z počítače - staré šunky s jedním diskem (víc se do toho stroje dát nedá), to vše zapojené ve 100 Mbit síti (tady se možná podaří protlačit upgrade na 1Gbit, ale zatím počítám se 100M).

Jelikož se jedná o starý jetý disk, který se kdykoli může odebrat do věčných lovišť i se všemi centrálně uloženými daty, chci tato data někde zálohovat. Mám k dispozici pár dalších disků (některé jsou i typově totožné), které můžu připojit do desktopů umístěných v téže síti. Desktopy ale - narozdíl od šunkoserveru - budou zapnuté jen občas.

Pokud se ale data v rámci sítě mají duplikovat na více strojů, rád bych dosáhl stavu, kdy každý stroj držící zálohu mohl pracovat s lokálními daty (s tím, že změny se odzrcadlí na centrálu).

Věci jako high availability nebo nějaké drobné rozdíly ve výkonnosti nejsou podstatné - když se starý disk odporoučí, tak to holt nepojede, dokud se to nepřepojí/nepřekonfiguruje. Na prvním místě je nepřijít o všechna data, na druhém místě je nestrávit mládí stavbou takového řešení, všechno ostatní jsou jen třešničky na dortu.

Dosavadní zkoumání a hledání mě přivedlo na několik možných řešení:

1. První a nejjednodušší volba - na desktopech po spuštění a/nebo pravidelně cronem spouštět rsync, případně nějaký sofistikovanější backup tool
2. DRBD
3. ChironFS, SeznamFS
4. GlusterFS, Lustre apod.

Každý ale má nějaké nevýhody:

1. veškerá data se budou tahat přes síť, i když bude existovat jejich lokální kopie, protože replikace nebude instantní; rsync po větším objemu změn na větším počtu souborů může trvat fakt dlouho
2. jednak je to docela kanón na vrabce stavěný pro HA potřeby, jednak náročnost na kapacitu sítě je podle diskusí obrovská a na 100M síti je to recept na bolehlav
3. ChironFS neumí zajistit počáteční sync úložišť, řeší jen průběžné změny, takže při startu desktopu bych stejně musel dělat rsync (který může trvat dlouho), během kterého by se asi nesmělo na centrále zapisovat; SeznamFS je zřejmě nemlich to samé v bledě modrém; ChironFS i SeznamFS
4. zase kanón na vrabce - pro síť s vysokou zátěží by bylo zbytečné přemýšlet o čemkoli jiném, ale když tu jde (zjednodušeně) o to, aby rodina nepřišla o fotky z dovolených, nechce se mi věnovat čas konfiguraci toho celého

Takže otázka zní, co byste radili, jako cestou se vydat? Řešil někdo něco podobného? Aktuálně mi s mými požadavky vychází jako nejmenší zlo varianta č. 1. (tzn. dělat prostě jen backupy a mít v síti větší provoz).

Předem díky za každý tip.

---

---

Odpovědi

[Carth_Onasi]

Proč do toho starého serveru nedáš disky (ať už nové nebo použité, i za cenu, že budou viset jen na drátech a case bude otevřený (třeba i přilepit)) a tam dáš SW nebo HW RAID 1, nějaký Debian a CRON?

[Eregon]

Momentálně mám něco podobného a řeším to zatím přes unison.

[Eregon]

Unison je pro obousměrnou replikaci výborný.

Nicméně i tam samozřejmě hrozí konflikty, obzvláště pokud je těch strojů ještě více, než jen dva (tj. 1 centrální, oproti kterému se ostatní postupně dokola synchronizují).

[Eregon]

Tak po hlubším průzkumu Unison asi nejvíc odpovídá požadavkům. Úplně dokonalé řešení to v dané situaci není, ale je zřejmě nejlepší dosažitlené se zdroji, které jsou k dispozici (mám teď na mysli hlavně nároky na implementaci a správu). Takže ještě jednou díky za tip!

[lertimir]

Podle mne se na to díváte chybně. Primárně je třeba mít jasný workflow, jak se pracuje s daty, kdy a kde se se modifikují a kde se skladují. Unison je fajn na bezproblémovou sychnonizaci třeba notebooku a desktopu pro jednoho uživatele, kdy mám v podstatě jasno, které soubory jsem kde upravoval, s tím že na něčem jsem pracoval na desktopu a na něčem na notebooku a občas to srovnám. Pokud je to situace, kdy do souborů může zasahovat více lidí, tak bych naprosto jasně preferoval řešení, které zaručí, že aktuální data jsou na jednom základním místě a na další se duplikují, automatickými skripty do nichž nezasahuji interaktivně.

[dustin]

Určitě, nicméně někdy to prostě jinak nejde. Kolem roku 2005 jsme realizovali a provozovali pro jednu nadnárodní firmu low-costovou synchronizaci síťových disků pro jejich marketingová oddělení v několika evropských zemích. Videa, velké prezentace, tehdy linky nic moc, bylo potřeba to otevírat lokálně a mít to předem natahané. Takže to kolečko s unisony, sshčkové tunely (vpnky tehdy neměli). Překvapivě těch konfliktů nebylo mnoho. Ale je pravda, že se postupně zavedlo pravidlo, že každý stát měl vlastní read/write adresář a ty ostatní byly pro ně jen pro čtení. Pak už to samozřejmě byla úplná pohoda.

Všechny státy jely na win fileserverech (tedy naše řešení bylo spuštěné v cygwinu), jen v rakousku měli sambu se redhatem. O té zemi jsme ani nevěděli, nikdy s tím nebyl problém. Když měli admini na win serverech nastaven pravidelný restart, tak to šlo, ale myslím v itálii jim IT spravovala externí firma, která tomu moc nedávala a to byl docela boj.

[lertimir]

Samozřejmě. Ale když je to server na "domáci fotky, videa a pár dokumentů" tak bych primárně šel na ten workflow. Třeba tak, že při importu přejmenovat fotku na unikátní identifikátor, zahrnující značku, kdo fotil, roztřídit do adresářů s tím, že to jsou jasné primární adresáře s nimiž se nepracuje (nemodifikují se v nich data), když by někdo s fotkami něco dělal, tak v definovaných podstromech, které má každý vlastní a do nich si fotky zkopíruje. Stejně i s jinými typy dat. Pak kolize nebudou. A jednoduché synchronizace typu při startu na klienta, při ukončení práce na server stačí, a synchronní to bude až na nějaké poslední modifikace.

[Eregon]

Souhlasím, že nakonec je důležité mít vyřešený i workflow, ale to, jak zařídit, že si uživatelé nebudou hrabat pod ruce, je úplně jiná otázka do značné míry nezávislá na otázce, jak řešit samotné uložení dat (což je podstata mého původního dotazu). Workflow je třeba řešit i v rámci jediného počítače bez záloh, má-li více uživatelů write přístup ke stejným souborům. A je potřeba ho řešit i v případě, že data budou na clusterovaném filesystému.

Jelikož potřeba centrálního úložiště v tomto případě neplyne z potřeby sdílet data mezi uživateli v síti, ale z mobility některých uživatelů, je workflow otázka vyřešená. Stejně tak je vyřešená otázka, jakými službami budou ta data zpřístupněna dál, ale to je v rámci debaty o síťové synchronizaci souborů už úplně offtopic.

Hlavním smyslem mého dotazu bylo, jaké jsou možnosti replikace dat v síti v režimu master-master (o což se zajímám kvůli snížení síťové zátěže). Režim master-master zdůrazňuju proto, že právě to je ta podstata dotazu (prostá pravidelná replikace dat je s rsyncem nebo rdiff-backupem vcelku triviální, takže se na ni neptám). Workflow omezení z toho jistě plynou a pak je otázka, jestli jsou ta omezení přijatelnější, než nároky na vytvoření a údržbu robustnějšího systému. V mém konkrétním případě to skutečně přijatelné je, jinde a s jinými požadavky to může být jinak.

[Eregon]

Díky za tip, prozkoumám to.

[Eregon]

Dobrá otázka, díky za ni. Zapomněl jsem zmínit důležitý fakt - disky, které mám k dispozici, jsou SATA, ale šunkoserver má k dispozici jen jeden SATA port.

[pepe_]

http://www.zbozi.cz/vyrobek/axago-rsi-x1/?q=%20AXAGO%20RSI-X1

[lertimir]

Vyhodil bych desku. Jednoduchým výpočtem lze zjistit, že jeden jediný Watt stále spotřeby 24/7 se projeví 8,76 kWh celkové spotřeby za rok a to je tak cca 30Kč. Pokud je tam nějaké staré Pentium bez úsporných režimů se spotřebou někde kolem 50W, tak výměna za moderní desku, jako tohle může ušetřit až 90% spotřeby procesoru (Maximální spotřeba Zacate je 18W, ale většinu času systém pojede v úsporných režimech) A nějakých 40-45W úspory zaplatí desku za rok, 4 SATA porty + jeden eSATAx, a ještě jedna pozice PCIe na přídavný sata řadič.

Pokud živit tu mrtvolu tak asi konvertor umožní SATA disk připojit na IDE rozhraní, nebo ta stará deska bude mi PCI sběrnici tak řadič do ní. A při nejhorším multiplexer na sata.

[Eregon]

Díky za tip, nicméně spotřeba není problém. Já jsem to v původním dotazu napsal blbě, šunkoserver není ani tak starý, jako spíš výpočetně nevýkonný stroj. Naopak má nízkou spotřebu a hlavně není hlučný, což jsou další zásadní požadavky na mé řešení (akorát to nepatří do diskuse o tom, jak dosáhnout replikace přes síť). Ale ten ASRock taky vypadá zajímavě, možná se bude hodit zase v jiné síti, takže díky za doporučení.

[\/]

Změřil bych, kolik žere šunkoserver a přepočítal bych to do korun za rok.

Koupil bych levný nový počítač a na něj bych nainstaloval linux a vytvořil bych raidové pole.

Nebo bych do šunkoserveru koupil sata řadič a nainstaloval bych na šunkoserver linux a vytvořil raidové pole.

Nebo bych koupil NAS server a udělal totéž. Výrobce NAS serverů k tomu dodávají různý software na zálohování dat z desktopů, ten bych uživatelům nainstaloval.

[NoXO]

bohužel človíček co tady potřebuje poradit, svým řešním myslí i na totál selhání celého raid pole... prostě data má rozložené v síti - což je chválihodné....

Škoda, že jde o peníze, nejlepší je na takové záležitosti NASko + USB DISK jako železná pojistka ve skříni, toto by bylo ideální na domácí využití + kupa přidané hodnoty navíc: DLNA, SMBFS, Backup client OS, aj.

iSCSI je teké kanon na vrabce..., ale možná nejpoužitelnější, otázkou je co tam běží za klientský OS.

[Eregon]

Spotřeba problém není, právě naopak je jedním z důvodů pro volbu toho HW, kterej se chystám použít (viz #11).

Koupit řadič nebo SATA multiplexer bych sice teoreticky mohl, ale proč kupovat další hardware, pokud to jde řešit s tím, co už mám (= síť a další disk v jiném stroji), žejo. Prakticky to v šunkoserveru není kam zapojit, ale to už je na úplně jinou debatu.

NAS server je prima v typické domácí síti s běžnými uživateli (už jsem taky někomu nasazoval), ale moji konkrétní situaci neřeší, na šunkoserveru poběží i jiné služby, než jen úložiště, a dostat je na NAS server by v konečném důsledku dalo i víc práce, než se sám patlat s tou synchronizací souborů. Holt, problémy ajťáků, zvlášť když si navymejšlej moc blbinek :D

Každopádně ale děkuju za rady a za snahu pomoct.

[Pavel]

Něco podobného řeším doma také. Cca 4 PC se společnými daty. NEjvíc asi záleží co to je za data, a jak je velká hrozba možnosti konfliktu. Na serveru mám uloženou hudbu, filmy, obrázky - to jsou pro mě stálé a stabilní věci. Velikost toho je cca 500GB. Pak různé dokumenty a pracovní složky, cca 10GB. Stanice jsou mix linuxu a widlí. Na linuxu používám rsync, na widlích goodsync. Analýza změn, mezi serverem a stanicí trvá maximálně 5minut na 100MBit síti. Rychlejší síť by se stejně projevila až při přenosu větších souborů. Pokud je uživatel rozumný, při spuštění PC si počká na synchronizaci, mezitím může brouzdat třeba na netu. Pokud obsluhou bude netrpělivý uživatel, prostě zablokuju na tu chvíli jeho PC. Řešit se to dá i zprovozněním ActiveDirectory na win. Řešení je spousta, ale nesmí si uživatelé lést do zelí.

Jinak co se týče serveru, také jsem měl na to staré železo s příkonem cca 70W. Nakonec jsem zakoupil HP MicroServer N54L s příkonem 40W, šoupnul do něj dva WD RED 2TB disky s raid 1 a nevím o něm. Investice cca 8000Kč se Vám po čase vrátí, byť už jen v podobě času, kdy nemusíte řešit prkotiny. A hlučný taktéž není, mám jej ve skříni vedle postele na gumové podložce a víc slyším tikat hodiny na zdi.