Open-source řešení domácí cold storage

[nocturne.op.15]

Zdravím,
potřeboval bych lehce revidovat domácí storage.

V současnosti používám jeden z enterprise backup/archiving systémů, který při přístupu k archivovaným datům umí pomocí WOL probudit příslušný storage node. Sedí to celé na soustavě HP Microserverů N54 s několika hromadami disků. Výhoda je, že celé to dohromady nic nežere, protože je to většinu času spící. Přichází ale čas na změnu - celé je to staré, komplikované a do budoucna nepříliš perspektivní. Nicméně dost jsem si na to zvykl, nemusím řešit stpořebu ani hluk a jen navyšuju storage kapacitu.

Jak byste dneska řešili podobnou věc, ideálně opensource/free?
K dispozici je dostatek HW i virtualizačního zázemí (hyper-V), vše v síti lze probudit přes WOL, případně iDRAc/iRMC. Cílem je, že uživatel by měl soubory vidět vždy (je tedy nutná přítomnost nějaké formy "proxy", která bude držet metadata a informace o tom, kde soubory reálně jsou. Není potřeba automatický tearing, vystačím si s manuálním. Nepříchází v úvahu nic v cloud/online světě, chybí konektivita, jinak bych šel do Amazon Glacier.

Napadá mě tak jedině auditování přístupu ke složkám a na základě výstupu z audit logů scriptovat události probuzení, ale nebude to moc elegantní věc :-/ Internet je na podobné technologie poměrně skoupý, přestože se každý honí po minimalizaci spotřeby domácího "NAS"

[Reklama]

[redustin]

Když to funguje, lze i nadále rozšiřovat, je spolehlivé, proč to měnit?

[nocturne.op.15]

protože jsem závislý na starobylé NFR licenci, která mí neumožní hnout se z opravdu historického systému. Software bez podpory a bez komunity, bez možnosti upgrade a uzavřený k tomu.
Proto hledám udržitelnější alternativu, tohle pochopitelně ještě nějakou dobu fungovat klidně může.

[MikyM]

......
Jak byste dneska řešili podobnou věc, ideálně opensource/free?
K dispozici je dostatek HW i virtualizačního zázemí (hyper-V), vše v síti lze probudit přes WOL, případně iDRAc/iRMC. Cílem je, že uživatel by měl soubory vidět vždy (je tedy nutná přítomnost nějaké formy "proxy", která bude držet metadata a informace o tom, kde soubory reálně jsou. Není potřeba automatický tearing, vystačím si s manuálním. Nepříchází v úvahu nic v cloud/online světě, chybí konektivita, jinak bych šel do Amazon Glacier.

Napadá mě tak jedině auditování přístupu ke složkám a na základě výstupu z audit logů scriptovat události probuzení, ale nebude to moc elegantní věc :-/ Internet je na podobné technologie poměrně skoupý, přestože se každý honí po minimalizaci spotřeby domácího "NAS"

Ahoj,
kdyby tech nodu nebylo tolik tak bych zvazil postavit jeden velky FreeNAS. Nody premigrovat a udelat z nich pak jednotlive pooly, kde by kazdy pool mel N disku. Spotreba elektriny by se dala snizit kdyby jsi kazdemu z disku nastavil stand-by ackoliv jim to moc nesvedci. Potom by se disky nahodily az pri pozadavku na pristup. Nicmene tohle reseni je  ve Tvem pripade dost kostrbate a pravdepodobne nepouzitelne. Pozadavek na FreeNAS multinode maji vyvojari uz dlouho, casem to pravdepodobne bude implementovano.

Kazdopadne ve Tvem konkretnim pripade se zkus mrknout na GlusterFS. Myslim, ze by to mohlo byt jedno z moznych reseni, ktere pokryje vetsinu Tvych pozadavku.

[nocturne.op.15]

aktuálně je nodů 6, po pěti diskách každý. To se blbe nahrazuje za málo peněz. Microserver ve své době stál 3500,- nový, tomu dodnes žádná NAS nekonkuruje :-(

Na GlusterFS jsem už někde narazil, ale zatím jsem to ignoroval. Začtu se do toho - díky za tip.

[Reklama]

[redustin]

Z pohledu HW - opravdu potřebuješ doma 30 disků? Asi už budou starší, menší, nestačilo by podstatně méně podstatně větších (třeba 12TB Toshiby bez šindelů)?

[nocturne.op.15]

Čistě pragmaticky - nepotřebuju. Dalo by se to nahradit jedním dvanáctidiskovým polem narvaným velkými disky. Kdybych byl svůj zákazník, doporučil bych si to...
Ale:
- technologie microserverů je nakoupená a funguje, tenhle hw byl dar z nebes
- investovat do 12TB při njakých 9000,- kus se mi  moc nechce, momentálně chci investovat do jiných hraček
- je to velmi nezávislé, pokud jeden z nodů chcípne, zbytek funguje dál
- většina kapacity je většinu času offline, nežere proud a disky "nenatáčí" zbytečné hodiny
- nezanedbatelný aspekt téhle hovadiny je, že mě to zajímá a baví, takže vzniká "proč ne" efekt :-)

disky jsou zastoupené zhruba tak, jak se pohyboval ideální poměr cena/výkon - 2,3,4TB většinou WD RED v poměru 10,10, 8,

[redustin]

Ptal ses, jak by se to dalo řešit dneska...

Pokud chceš použít stávající HW řešení, pak je to jen o vhodném softwaru, pokud jsem to dobře pochopil.

[nocturne.op.15]

Je to tak.
Jednou něco přestane fungovat, bude potřeba obměnit to nebo postavit znovu. A já momentálně nevím, jak bych to řešil - metoda popisování serverů jako se to řešilo u archivních DVD se mi zdá poněkud nevhodná a zdlouhavá, chce to automatizovat.

[Ondřej Kolín]

Vubec netusim, jestli Vam to nejak pomuze, ale my v praci pouzivame Baculu (existuje fork Bareos, ale neumim srovnat vyhody), ktera vychazi jeste z doby zalohovani na pasky, takze umi tyhle ruzne zmeny zdroju automatizovat. Otazka je, jak moc komplikovane by to bylo naskriptovat.

Snad Vam to pomuze, pripadne se omlouvam za offtopic.

[czechsys]

No, je fakt, ze bacula/bareos by neco takoveho zvladly. Metadata v db, wol by si dalo rict s prebackup/prerecovery skriptem...

Ja kdyz to cetl poprve, tak jsem nejak nezaregistroval, ze to ma byt pristup k archivum. Kdyby tam nebyl ten pozadavek na ten wol, tak bych klidne rekl ceph apod, ale neustale uspavat/probouzet disky, zvlast WD REDy...

[nocturne.op.15]

czechsys: přesně takhle nějak to funguje dneska.

Doufal jsem, že by to mohlo být řešené trochu elegantněji, bez nutnosti hrabat se v backup SW - ideálně zaintegrované přímo do SMB. Při přístupu na folder se aktivuje WOL script > storage nastartuje a mountne se do tohoto folderu. To je celkem řešitelné samo o sobě, i relativně realtime auditing není zase tak problém.

Problém je tvorba obslužných scriptů pro tuhle obludu - to by bylo ideální svěřit nějakému dedikovanému SW, kerý bude scripty tvořit dynamicky v okamžiku archivace.

<neorganizované myšlenky>
- přimountuje se storage
- SW odarchivuje data, do SQL uloží informace o souborech a složkách
- na původní místo udělá symlink do nové, mount lokace
- storage usne
- demon zaudituje přístup k symlinku, aktivuje trigger - první přístup k symlinku možná failne na straně klienta  (accceptable)
- script nastartuje storage, na kterou uložil původní soubor, info o storage má v DB
- do DB připraví sekvenci příkazů pro danou storage, co kam mountnout
- storage nastartuje, agent si do DB sáhne pro sekvenci mountů a a provede ji (pro případ nutných vícero mountů v průběhu startu), potom už si bude sahat pro příkazy cyklicky nebo uložený příkaz vyvolá push akci na storage agentu pokud sotrage běží
- storage začne počítat po ukončení posledního handlu nastavený timeout a zase se uspí

</neroganizované myšlenky>

Pokud něco takového už neexistuje, asi to není nereálné udělat. Ale toho času...

[nocturne.op.15]

se zkus mrknout na GlusterFS.

Zkoušel jsem se poptat lidí kolem sebe, něco o tom počíst - a v zásadě je to  filesystem s nejvyšším faktorem děsivosti, co znám. Geocluster je snad horší než DFSR. Podle zkušeností ostatních živých i internetových lidí se to v out-of-the-box chová dost jako technologické demo nežli jako odladěná věc pro denní použití. Možná, pokud bych měl prostředky to fakticky napasovat do puntíku k danému scénáři, ale musím i pracovat a tak a chlapa na fulltime k tomu nezaměstnám...Pletu se?

[RDa]

Dokazal bych si to predstavit jako ukol pro FUSE - mit na SSD metadata + nektere soubory nacachovane (typicky OS X napr. dela 4KB meta soubor .neco) a informaci na kterem nodu se tohle najde - pri pokusu o otevreni/cteni se muze node nastartovat.

Sam budu neco podobneho resit, ale HW chci udelat jinak, jelikoz dost jedu v PCIe vecech, tak to bude hierarchicky switchovany fabric + hromada SATA HBA (zrejme asmedia), tj. DAS. Neco jako WOL a 1GbE je dnes jiz pase.. a zbytecny overhead (rychlost, latence, spotreba), nepotrebuji infrastrukturu rozsirovat za chodu, postaci hotswap vymena disku, nebo doplneni na navrzeny cilovy pocet.

A pak bych rad jeste nasel specialni sw raid rezim - disky mit za sebou jako v LVM, ale nad treba tremi az sedmi pak mit jeden checksum disk (temer jako v raid 4). Muj use case je WORM jako archiv, takze pri zapisu se probudi vsechny disky ale pro cteni staci roztocit jen jeden.

[nocturne.op.15]

S OSX mám 0 zkušeností...
Rychlost probuzení mě zase tolik doma netrápí. Pokud se to probere do minuty, je to pro mě pohodové a flexibilní vzhledem k ceně - používaná data budou sejně na fileserveru, který jede nonstop. Navíc je to potom škálovatelné metodou "dovalím nějakou krabici" což doma není k zahození (staré microservery s úsporným AMD Neo na trhu docházejí)

Ad 1Gbit -  taky to pro mě není limit - a jádro sítě je stejně už na 10Gbit switchi, jen nejsou osazení SFP - takže kdyby bylo potřeba, půjde to.

Kazdopádně metoda zapínání HBA není úplně k zahození, to jsem nikdy nikde neviděl. Mám momentálně k dispozici dost vyžazených diskových polí, kde budou solidní řadiče, tak bych je klidně propůjčil (sz)