Geograficky redundantní NAS

[MarekG]

Neriešil by Váš problém lsyncd alebo glusterfs?

[Reklama]

[czechsys]

Asi nepouzivam spravna slova, protoze nektere otazky jsou jako kdybych neco neuvedl "v popisu". Uz to, kdyz zminuji dedikovane optiky, 10Gbps, SAN apod by napovedelo, ze to uplne garazovka neni, ale bohata firma taky ne. Rozhodne ale nez se neco koupi, tak se planuje/vyhodnocuje, proc se to koupi. Ale budiz.

glusterfs apod. rovnou skrtam, to nebylo pouzitelne ani pred 8 lety, kdy jsem nas aktualni nfs cluter, dnes to je prekonane kontejnery popr. ceph.

Zadani od vedeni je klasicky manazerske, tedy v pripade primarniho datacentra chteji provozovat (aspon nektere sluzby, samozrejme tim mysli skoro vse, co je dobre placene) z druhe lokality. Takze se postupne delaji jednotlive kroky - k aktualnimu nfs clusteru se poridil SAN s georedundanci, tim jsme vyresili (blokove) uloziste pro VM.

Chce se tedy neco obdobneho pro soubory, protoze jedeme hlavne linux, tak nfs je prvni volba. Cestu mit zdrojaky primo ve VM jsme tehdy zamitli, to se muze zmenit. Ale zbytek souborovych dat je orisek, mozna by na to bylo vhodnejsi neco typu S3, ale s tim jsem zatim nemel cest. Porad ale reseni nejdrive on-premise.

Webove sluzby ktere poskytujeme, maji jiz zabudovanou redundanci. Tedy vice kopii web/compute serveru, ktere si tahaji zdrojaky, obrazky, dokumenty, videa a dalsi a dalsi z nfs. Bavime se i v nekterych pripadech i o milionech souboru podle velikosti jednotlivych projektu, zatim celkove pod 1TB ciste kapacity. Takze nastesti zadna SAP HANA nebo tak. Kdybych mel k dispozici rozumne admistratovatelny kontejnerizacni system obdoby proxmoxu (vmware is dead), tak bych ty zdrojaky nacpal do kontejneru a mam to o neco jednodussi.

NAS replikace staci async. Jedine misto, kde pouzivam sync, je pripojeni klientu k nfs.

Rozpocet stanovit nemuzu, muzu jen predlozit vedeni cisla, ale vetsinu obchodni jednani vede primo vedeni.

Protoze tu nikdo nema zkusenosti z cloudovych poskytovatelu apod., tak me moc jinych technologii jak resit tyhle veci nenapada. Proto se poptavam, co se pouziva pripadne u koho se daji nechat nacenit reseni, nez se to pripadne bude resit DIY.

[jjrsk]

Jenze to je prave o tom, ze ty prakticky neuvadis zadne relevantni udaje.

Treba 10Gbit je strasne malo. 10G mam doma na svuj domaci NAS. U mensich zakazniku maji ciste storage, ktery se nikam nereplikujou, 8x 10G. Kdyz odbocim trebas k virtualizaci a vmware, tak by ti 10G hrokotezko stacilo na bezvypadkovy provoz JEDNOHO virtualu.

To co vyplyva z tvyho popisu je, ze chces master-master realtime replikaci. A to je slozity a tudiz drahy a proto to skoro nikdo nepouziva. Protoze presne v okamzeni kdy se podivas na cenu, tak zjistis, ze to neportebujes.

Dell/EMC:

"Carefully consider the write profile of workloads that will run on replicated volumes; additional network capacity will be needed to accommodate the additional write overhead. In replicating systems, therefore, we recommend using 4x 25GbE or 2x 100GbE networks to accommodate the back-end storage traffic."

To jen aby sis udelal predstavu, jak smesnych je 10G.

[RDa]

Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.

Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).

1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).


Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?

(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)

Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.

[jjrsk]

... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)

Mno prave. Proto si to dodavatele nechaji velmi dobre zaplatit.

To co popisujes dal vpodstate meni to reseni na master-slave. To je easy, protoze ti nevadi ze se to na druhou stranu zapise "az nekdy". A presne proto ti taky staci vyrazne nizsi konektivita, protoze ti proste staci, kdyz se ty data nejak zvladaj prenaset + navic vlastne nemusis prenaset ani vsechno, muzes zacit resit jen rozdily, komprimovat to atd atd, cimz pochopitelne razantne snizis naroky.

[Reklama]

[RDa]

Ona ta konektivita (sirka pasma) je potreba v zavisloti na pomeru RO:RW operaci. Pokud je veskera aktivita RO, tak nepotrebujete konektivitu zadnou ,)

Pro master-master (vs master-slave) je pak dulezitejsi latence na konektivite - aby slo vykomunikovat zamky v nejakem rozumnem case. A na to nema vliv objem zaplacenych prostredku - vice penez do storage technologie vam nezlepsi experience.

Zpet k tomu memu - pokud fakt neni rozpocet na 3rd party proprietarni reseni, tak nezbyva nic jineho nez si zkulturnit sve aplikace, aby si do zeli nelezli.. a pak muzete nasadit nejakou jednodussi formu reseni i ve vlastni rezii.

PS: ale zalohovat (a obnovovat) bych tenhle bastl pak nechtel :D

[Exceptions]

no a jako vždy u podobného nápadu skončíme u toho, že se budou dělat dumpy databází, jednou za čas snapshoty virtuálů a ty budou čekat v druhé lokalitě. Když to holt bude kritické, bude se realtime replikovat transakční log u databáze. Řešení za pár desítek tisíc na konzultace a půl roku vývoje/úpravy doma.

Tohle řeší všichni, ale také všichni skončí s tím, že si prostě vyberou těch pár kritických dat/aplikací, ty replikují rovnou a zbytek pomalu snapshotují a odlévají. Ztráta pár desítek minut dat je přijatelná skoro všude, hlavně se ušetří miliony na implementaci a provoz.

Nezapomeň, že tohle děláš, abys zvýšil spolehlivost, jakákoliv komplexnost ti naopak tu spolehlivost zase posouvá dolů. Testovat stabilitu musíš v nejhorším scénáři a ne v tom nejlepším a pak tvrdit, že synology je vlastně super, není. Oni i ty enterprise systémy trvá dlouho vyladit a náklady na pravidelné testy jdou také do dost vysokých čísel. Někdy je prostě lepší se znovu snést na zem.

[Zopper]

Možná jsem to tu přehlédl, ale co přístup "zápis jen na masteru, čtení na replikách?" Když bude aplikace v regionu s replikou chtít zapisovat, a následně se to z masteru může rychle zkopírovat do repliky. V případě výpadku masteru se replika prohlásí za master a jede se dál. Akorát to dost zpomalí zápisy (data musí udělat roundtrip z read-only regionu do masteru a zpět), ale ze zadání mi není jasné, zda je to přijatelné, nebo ne. A člověk se tím vyhne celé té složitosti s master-master.

PS: za zvážení stojí otázka, jak moc je pravděpodobné, že časem přibude třetí region, a vybrat vhodný přístup hned na začátku. Master-master je jedna věc, N-uzlový mesh je ještě další úroveň.

[jjrsk]

... N-uzlový mesh je ještě další úroveň.

To uz mas jedno. To co vyrabis je defakto zrcadlo, a nehraje zasadni roli (technologicky) jestli mas v tom zrcadle ty "disky" dva nebo jich mas deset. Jen ty naklady nerostou linearne, ale spis exponencelne. Potrebujes treba zajistit propoje vseho se vsim (pokud to teda opravdu ma zvladat vypadek cehokoli)

Jenze tady je podstatny to, ze tazatel zatim vubec nedokazal zduvodnit, nac neco takovyho chce. Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.

Ja treba u nekterych zakazniku umim (a to u tech vetsich) v ramci rekneme 10ti minut nahodit provoz ze sekundarniho storage, a ani to neni nijak automaticke a je to zcela vyhovujici (za poslednich 20 let sem to delal 1x). Defakto nejhorsi scenar kterej muze nastat je nutnost obnovovat zalohy (tzn chciply by obe storage zaroven), coz narazi na limity HW a konektivity. Jenze v takovym pripade si nejak nedovedu predstavit, ze by toho nepochcipalo mnohem vic (treba pozar budovy) a tudiz by nejaka obnova zaloh bylo stejne az to posledni, co by bylo k reseni.

[czechsys]

Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.

Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).

1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).


Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?

(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)

Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.

Tak databaze resit nemusim, u nich mam k dispozici replikaci zabudovanou v db.
Ano, vetsina workloadu nad soubory je RO, takze nam 10G redundantni propoje staci, zatim jsme to nebyly schopni zatizit trvale vic nez par desitek %.

Taky me napadlo dva nezavisle nfs clustery. Zdrojaky by nahraval gitlab do obou clusteru. Oddeleni od "media,office dat apod." by samozrejme museli resit vyvojari, aby se to dalo dat na nejake "replikovane" reseni. Coz uz pak muzu "replikovat" vse, vzhledem k celkove velikosti zdrojaku/dat.

[czechsys]

... N-uzlový mesh je ještě další úroveň.

To uz mas jedno. To co vyrabis je defakto zrcadlo, a nehraje zasadni roli (technologicky) jestli mas v tom zrcadle ty "disky" dva nebo jich mas deset. Jen ty naklady nerostou linearne, ale spis exponencelne. Potrebujes treba zajistit propoje vseho se vsim (pokud to teda opravdu ma zvladat vypadek cehokoli)

Jenze tady je podstatny to, ze tazatel zatim vubec nedokazal zduvodnit, nac neco takovyho chce. Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.

Ja treba u nekterych zakazniku umim (a to u tech vetsich) v ramci rekneme 10ti minut nahodit provoz ze sekundarniho storage, a ani to neni nijak automaticke a je to zcela vyhovujici (za poslednich 20 let sem to delal 1x). Defakto nejhorsi scenar kterej muze nastat je nutnost obnovovat zalohy (tzn chciply by obe storage zaroven), coz narazi na limity HW a konektivity. Jenze v takovym pripade si nejak nedovedu predstavit, ze by toho nepochcipalo mnohem vic (treba pozar budovy) a tudiz by nejaka obnova zaloh bylo stejne az to posledni, co by bylo k reseni.

Zakaznici to chteji. Jde o jejich business.

Do 10 minut, to jsi frajer. Ja jsem zazil vypadek primarniho storage 2x, kdy nedoslo k automatickemu prepnuti, protoze se to zaseklo. Nebyt u ntb, tak to do tech 10 minut nevyresim.

[RDa]

PS: za zvážení stojí otázka, jak moc je pravděpodobné, že časem přibude třetí region, a vybrat vhodný přístup hned na začátku. Master-master je jedna věc, N-uzlový mesh je ještě další úroveň.

Pokud by naopak mel 3 lokace (klidne tu treti jako pasivni/zalozni), tak by bylo nejvhodnejsi vzit CEPH.
(pripadne to resit jako 2+2 (+2) pro klasicky setup kde si muzete po jednom updatovat nody a nic nevypadne)

[František Ryšánek]

Neriešil by Váš problém lsyncd alebo glusterfs?

Přimlouvám se za keep it simple. Třeba rsync v cronu udělá taky spoustu práce, ale lsyncd je o krok dál. Glusterfs by tomu dal křídla, jenom už to souvrství začíná být maličko složitější :-)

Nezapomeň, že tohle děláš, abys zvýšil spolehlivost, jakákoliv komplexnost ti naopak tu spolehlivost zase posouvá dolů. Testovat stabilitu musíš v nejhorším scénáři a ne v tom nejlepším a pak tvrdit, že synology je vlastně super, není. Oni i ty enterprise systémy trvá dlouho vyladit a náklady na pravidelné testy jdou také do dost vysokých čísel. Někdy je prostě lepší se znovu snést na zem.

Taky mám radši věci, do kterých je vidět dovnitř. Snáz se v tom dá vyznat v případě nějakého katastrofického kolapsu (disaster recovery). Věci automagické, složité a uzavřené jsou mi spíše z principu podezřelé :-(

Jakýkoli systém na bázi geografického clusteru, kde se na každé lokalitě do té věci konkurenčně zapisuje, smrdí problémem pokud nastane split-brain. Jak se z něho vrátit do spojitého stavu. Principielně je potřeba se snažit, aby lokality nemusely "sdílet stav s právem zápisu". Každá lokalita ať si zapisuje do svého lokálního písečku, a na jiné lokality se jenom "letmo zálohuje" s možností "lokálního read-only přístupu k datům vzniklým v jiné lokalitě". Na jaké vrstvě se povedou hranice mezi "parcelami lokalit" je vcelku na uvážení integrátora. Může se jednat o oddělené foldery ve filesystémech, nebo o atribut "location of origin" v SQL databázi (nebo mě napadá, přidělit každé lokalitě její vlastní řadu generovaných unikátních klíčů v rámci sdíleného sloupce, ale to je moje lidová tvořivost :-)  Což samozřejmě komplikuje vývoj aplikace, pokud má být "jenom jedna, společná, homogenní napříč lokalitami", datový model má hodně entit apod.
Hmm šimrá mě správně v šedé hmotě keyword Mumps ?

Tuším jsem taky zaslechl termín "eventual consistency", jako že "časem se to rozkopíruje a začne to v globále dávat smysl". Vývojově to tuším pochází z modernější doby, no-SQL v masivních cloudových systémech, microservices apod., než klasické poučky o distribuovaných systémech z minulého století...

Distribuovaný systém se simultánním RW provozem bez explicitního rozparcelování lokalit lze postavit, ale pak řešíte vzájemnou synchronizaci, zamykání, konkrétně two-phase commit (2PC) a podobné radosti, což je právě závislé na přenosových latencích (jak už psali ostatní). Co máte v rámci jednoho stroje (hypervizoru) v desítkách nanosekund, na LANce je v řádu desítek mikrosekund, napříč městem či krajinou jdou další řády nahoru... Čím větší ethernetový switch nebo router, tím větší hrubá průchodnost, ale obecně taky store-and-forward latence jdou nahoru... a pak je problémem potenciální split-brain. Jak se při něm chovat (zastavit provoz? zastavit zápisy?) a jak se případně zotavit, pokud provoz nezastavíte... mít jednu "centrální" lokalitu, jejíž "spojitý přeživší shluk" může zapisovat dál, a kdo se odpojí od centrálního shluku, smí lokálně pouze číst?

[jjrsk]

Zakaznici to chteji. Jde o jejich business.

Do 10 minut, to jsi frajer. Ja jsem zazil vypadek primarniho storage 2x, kdy nedoslo k automatickemu prepnuti, protoze se to zaseklo. Nebyt u ntb, tak to do tech 10 minut nevyresim.

Zakaznici chteji ledacos, a kdyz chteji tak at si to zaplati. Ale je mimo jiny ukolem ITka jim vysvetlit, ze to co chteji je pitomost.

Setkal sem se s pozadavkem na garantovani bezvypadkoveho provozu 24/7 ... to neumej ani banky. Doticni to nechteli pochopit, tak sme jim nacenili jen HW. Pak uz to nepotrebovali. SW by ve skutecnosti stal jeste tak 10x vic nez ten HW. Drtiva vetsina SW neco takovyho vubec neumi a nepredpoklada a dodavatele/jejich vyvojari typicky nemaji ani paru ze by neco takovyho mohlo vubec existovat.

BTW: virtualy se replikujou na sekundarni storage, ze ktery je mozny je rovnou nastartovat. Neni to automaticky a to z dobryho duvodu. Bylo by treba osetrovat spoustu "co kdyz", ktery ITk vyhodnoti pohledem za minutu a stejne kdyz osetris 150 variant, nastane ta 151.

[Jose D]

nejsem dealer netappu ale přijde mi, že pro orientaci bys mohl managementu nechat nacenit tohle: https://www.netapp.com/snapmirror-data-replication/. Dělá to to, co si myslím, že ty zhruba popisuješ.