Asynchronní replikace SSD na HDD

[𝑾𝑰𝑭𝑻]

Potřeboval bych vědět, jestli jde na linuxu udělat následující věc: Mějme NVMe SSD, k němuž potřebujeme mít zálohu na nějakém pevném disku pro případ, že by SSD odešlo. Dejme tomu, že SSD je /dev/nvme0n1 a zálohu potřebujeme mít na /HDD/zalohaSSD.img (velikost souboru stejný jako ten NVMe block device). Mělo by se to chovat tak, jako by šlo o RAID typu mirror, ale bez čekání na zápis na HDD. Tedy zápis by měl být potvrzen v momentě, kdy je na SSD (jako by byl svazek pouze na SSD), ale na HDD by se zapisovalo asynchronně na pozadí tak, aby to nezpomalovalo SSD. Je mi jedno, jestli se to bude replikovat přímo z SSD v momentě, kdy SSD nemá co dělat, nebo se to bude cachovat do RAM, mám jí dostatek. V případě, že by odešlo SSD, se bude pracovat pouze s tím, co je na HDD. Technicky vzato by ta replika mohla být i na vzdáleném souboru, třeba na svazku mountnutém na NFS, prostě kdekoli.
„Umělka“ něco napověděla, ale potřebuji odpověď přímo od lidí, co s tím mají zkušenost. Snad jsem to napsal srozumitelně.
Díky.

[Reklama]

[redustin]

Např. drbd v asynchronním režimu, aby vzdálený nezdržoval potvrzení zápisu.

[RDa]

Tak zakladni koncept je mdraid s hdd na --write-mostly (tj. cteni pujde z nvme, zapis na oba synchronne), resp. pak co chces, aby se dovolila desynchronizace se jmenuje --write-behind (ale nevim v jakych jednotkach ten parametr je - zda iop, device block, bitmap block):

Kód: [Vybrat]

       --write-behind=
              Specify that write-behind mode should be enabled (valid for
              RAID1 only).  If an argument is specified, it will set the
              maximum number of outstanding writes allowed.  The default
              value is 256.  A write-intent bitmap is required in order
              to use write-behind mode, and write-behind is only
              attempted on drives marked as write-mostly.
Jinou RAM cache pro lag neznam nez ten --write-behind. Druhej disk nemusi byt hdd, ale muzes pouzit iSCSI block device (radeji nez losetup nad nfs souborem). A s bitmapama se to pak chytne i kdybys ho pripojil do mirroru pozdejic.

Pokud na tom disku nemas veliky denni obrat a muzes si dovolit prijit o den prace jednou za X let, tak bych to spis resil na urovni FS.. tj btrfs, denni snapshot, synchronizace na remote backup server.

Zrovna tvuj polovicaty pozadavek je trocha antipattern - bud chces mit bezvypadkovy provoz (skutecny mirror), anebo chces mit zalohy (a pak je dobre mit historicky vicero snapshotu).

Např. drbd v asynchronním režimu, aby vzdálený nezdržoval potvrzení zápisu.

To DRBD jsem pouzil jednou a mirror nebyl identicky, tak jsem toho zas nechal. Nevim zda si to neporadilo s udp nebo tam slo o tu asynchronicitu, ale nebyl jsem s tim spokojenej a rychle to skrtnul a beru to jako pozirac dat.

[redustin]

Nám drbd slouží už přes 20 let, funguje nám skvěle. Jen používáme synchronní, async jsem nezkoušel/nepotřeboval.

[Michal Šmucr]

Já v podstatě souhlasím s tím, co napsal RDa.
Asynchronní bloková replikace je principiálně problematická, protože při jakémkoliv selhání a nedokončené synchronizaci to typicky nechá tu repliku v nekonzistentním stavu (data vs metadata na fs).
Na druhou stranu pokud budu mít mirroring v RAIDu nebo synchronní replikaci, tak budou nutně všechny zápisy čekat, až se to zapíše do všech zařízení/replik. Což třeba náhodné zápisy do SSD, které pak bude čekat na klasický točivý disk, opravdu násobně zpomalí.

Takže pro valnou většinu použití mi přijde, že se s tím buď musí člověk v dané situaci smířit (a použít např. už zmíněné write-mostly), nebo to řešit klasicky pomocí zálohování, resp. replikace snapshotů v nějakém vyhovujícím intervalu.
Většinou je při nějakém fatálním selhání lepší mít funkční starší snaphot než nekonzistentní repliku.

Byť to jde do jisté míry dělat s většinou linuxových filesystémů na úrovni device mapperu (třeba s thin snapshoty), tak zdaleka nejefektivnější a nejpohodnlnější je to s CoW filesystémy jako Btrfs nebo ZFS.
Tím, že jsou snapshoty přímo jejich součástí a jsou atomické (z pohledu fs, ne aplikací), není např. potřeba používat fsfreeze. Další výhoda je, že pokud je cílový fs stejný (např. také Btrfs), přenáší se při operacích send a receive jen rozdíly a je to velice rychlé. Navíc tam jde snadno udělat nějaká retence, což vám pomuže když dojde k nějakém smazání nebo logické chybě.
Pokud byste potřeboval skutečně jen tu image na nějakém jiném fs, tak se to dá zařídit také. Např. uděláte sparse file (fallocate) s nějakou maximální délkou. Vytvoříte na něm Btrfs a pak s ním budete pracovat přes loop zařízení standardním způsobem. Bude to samozřejmě o něco pomalejší než u zařízení napřímo, ale to by pro tenhle typ záloh nemuselo nutně vadit.
Jinak tu jsou samozřejmě i nevýhody, RAID s redundancí vám zajistí dostupnost v případě závady, byť vás to v tomhle hybridním režimu bude stát výkon při běžném provozu. Záloha tohle nezajistí a i když případně vyměníte odešlé zařízení, budete tam muset ručně vytvořit nový filesystém a přes receive ze snapshotu v záloze přenést zpátky data, donastavit subvolumy, bootování, pokud pokud jde o systémový disk atp.

[Reklama]

[Hornik]

zfs snapshot & zfs send

[a12]

zfs snapshot & zfs send

- btrfs snapshot + send
- mdadm --add + --remove  (s bitmapama)

[Michal Šmucr]

- mdadm --add + --remove  (s bitmapama)

Asi spíš: --fail, pak --remove a nakonec --re-add (jinak to ingnoruje tu existující bitmapu).

Podle mě tohle fakt není dobrý nápad, speciálně pro pravidelné používání (třeba jednou za den).
Přesně v duchu toho, co jsem zmiňoval. Když se neplánovaně zastaví synchronizace bloků, např. při vyšším vytížení se může odporoučet zdrojové zařízení, tak to skončí nakopnutou zálohou. Část filesystému z přechozího dne, část z času aktuální synchronizace.
Navíc pokud to má nějak rozumně doběhnout s jistotou, že tam nebude nic chybět, tak by se muselo před failováním a odpojením zajistit, že je to kompletně sychronní a na filesystému nebudou žádné zápisy (třeba přes fsfreeze).
Ty přenosy snapshotů s  Btrfs nebo ZFS jsou mnohlem lepší řešení. Uklízení těch starších na cílové straně se udělá až po úspěšném přenesení aktuálního. Takže i pokud bude nějaký problém při přenosu, jsou tam vždy kompletní starší snapshoty.

[a12]

- mdadm --add + --remove  (s bitmapama)

Ty přenosy snapshotů s  Btrfs nebo ZFS jsou mnohlem lepší řešení. Uklízení těch starších na cílové straně se udělá až po úspěšném přenesení aktuálního. Takže i pokud bude nějaký problém při přenosu, jsou tam vždy kompletní starší snapshoty.

ano,  ale nekdy proste neni jina moznost (ale souhlasim u tohodle musis presne vedet co delas)

[Michal Šmucr]

ano,  ale nekdy proste neni jina moznost (ale souhlasim u tohodle musis presne vedet co delas)

No stejně mi tohle řešení přijde trochu riskantní divočina Ale možná to opravdu nějaký reálný use-case má.

Třeba to tu ještě někdy WIFT okomentuje, když už to téma vykopl.
Nevíme jaké filesystémy tam teď používá nebo může používat.
Nevíme jak dlouhé zpoždění repliky/mirroru za primárním diskem si může dovolit.
Nevíme co tam má typově za data a jestli je potřeba zachovat kontinuální běh aplikací nad tím, případně minimalizovat dobu, kdy se můžou zmrazit zápisy. Např. pokud tam jsou databáze nebo image od běžících virtuálů je to úplně jiná situace než hromada statických dat a je potřeba to dobře promyslet, aby ty zálohy resp. repliky k něčemu byly.

[𝑾𝑰𝑭𝑻]

Třeba to tu ještě někdy WIFT okomentuje, když už to téma vykopl.…

Přiznávám, občas vykopávám proto, abych otevřel dveře a podíval se dovnitř. Některé dveře v podstatě zavřít nejdou, ale to už je mi jedno. Rozjetá diskuze mi slouží jako inspirace, neříkám, že něco z toho (a co) použiju, člověk může dojít i k závěru typu „jo, dobrý, to se někdy může hodit, ale teď to asi v klidu odložím k ledu“, nebo „tohle je přeci jen příliš mnoho vynaložených prostředků pro nejistý výsledek“.
Nemám momentálně v úmyslu to nějak dál komentovat . Pokud jsem vás tímto přístupem zklamal, omlouvám se, nebyl to záměr. Už jsem si zvykl na to, jaký typ diskuzí se zde vede a proto se snažím své dotazy pokládat i s ohledem na tuto specifiku (a vím, že některé dotazy sem nemá smysl kvůli tomu pokládat vůbec).

[Michal Šmucr]

Chápu a občas taky takhle někdy spíš "sonduju".
Nezklamal jste Můj koment byl primárně o tom, že v tuhle chvíli už víceméně nemá smysl moc spekulovat dál (coby, kdyby a jestli něco jde, nebo ne). Možná by mě třeba napadly nějaké další věci nebo zkušenosti ohledně konkrétního použití, ale jsou tam proměnné, co si nedovedu dosadit.

[𝑾𝑰𝑭𝑻]

OK, ukecal jste mě.
Cílem bylo zajistit, aby data byla někde k mání v případě odchodu SSD a zároveň to řešení (potenciálně možná s výjimkou nějaké klidové doby) nebylo samo sebou bržděné. Zároveň si skutečně dokážu představit situaci, že mohu přijít o den dat, přičemž historická data netřeba uchovávat. A zároveň - SSD má třeba 4 TB a to už je docela dost dat na to, aby se to jednou za čas zazálohovalo jako celek.
Proto jsem jako výstřel sondoval možnost, kterou jsem uvedl, protože mi připadala principielně elegantní.

Zároveň zde nerad pokládám dotazy, na něž mají tendenci lidi odpovídat dotazy, typicky ve smyslu "a k čemu je to dobré".

[Michal Šmucr]

Cílem bylo zajistit, aby data byla někde k mání v případě odchodu SSD a zároveň to řešení (potenciálně možná s výjimkou nějaké klidové doby) nebylo samo sebou bržděné. Zároveň si skutečně dokážu představit situaci, že mohu přijít o den dat, přičemž historická data netřeba uchovávat. A zároveň - SSD má třeba 4 TB a to už je docela dost dat na to, aby se to jednou za čas zazálohovalo jako celek.
Proto jsem jako výstřel sondoval možnost, kterou jsem uvedl, protože mi připadala principielně elegantní.

Ano, ten základ jsem pochopil včetně toho, že nechcete, aby to bylo permanentně bržděné tím pomalejším diskem (nebo nějakým image souborem) při synchronních zápisech.
Jen prostě pokud to má být ochrana proti selhání toho primárního zařízení, tak by to mělo zaručit, že částečná provedená synchronizace nebude znamenat také nepoužitelnou zálohu.

Kvůli těm snapshotům jsem se ptal, co tam teď máte za filesystém a distribuci. Možná už je to na nějakém domácím serveru, kde máte třeba Proxmox, který má rovnou ZFS modul, takže by to případně nebyl problém rozběhnout tenhle filesystém. A i v ZFS se dá pracovat s image soubory místo disků, pokud byste to chtěl otestovat nebo takhle nastavit cílovém zařízení, kde už je jiný existující filesystém a další data. ZFS snapshoty, send a receive, jsou vcelku přímočaré operace včetně toho inkermentálního posílání.
Viz např. https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.html
Jen kdybyste pak používal ty image, tak to má nějaké konsekvence podle toho, jestli byste pak chtěl, aby se to připojovalo automaticky po startu systému (a bude třeba říct systemd nějaké pořadí, aby se nejdřív připojil ten filesystém pod tím), nebo jen pomocí třeba nějakého zálohovacího skriptu.. kdyžtak rozepíšu víc, co nastavit za optiony, když byste importoval pool s image souborem.
U Btrfs je to pak analogické.

Co je tam typově za data jsem zas sondoval i kvůli případnému souborovému zálohování.. např. pokud byste nemohl, nechtěl používat Btrfs ani ZFS.
Souborové zálohování může být bezpečnější volba než ta bloková synchronizace, protože např. klasický rsync nebo rclone (rychlejší porovnávání souborů k přenesní, paralelní operace) pracují ve výchozím nastavení tak, že to do cílového umístění přenesou nejdřív jako dočasný soubor a pak následně atomicky přejmenují.
Což je třeba v pohodě pro drtivou většinu typů užvatelských souborů, co se moc nemění, nějaký sync task na noc nemusí být prakticky problematický (funkčně, časově).
Na stranu druhou právě třeba u image disků virtuálů nebo databází tohle problematické je.. ať už kvůli konzistenci přenášeného souboru nebo neefektivnímu přenášení všech dat (ve virtuálu se změní 100 MB, v cíli se zapisuje celá 100 GB image).
Pokud se tam vyskytují oba typy dat, je samozřjemě lepší to nějak zkombinovat v rámci zálohovacího skritpu (úlohy). Používat standardní synchronizaci, ale vyloučit pár kritických adresářů, na které je pak vhodné aplikovat speciální zálohovací nástroje, co umí pracovat a přenáší jen přírůstky a také pořeší konzistenci.

Ale to už jsem se možná rozkecal o tom, na co jste se neptal (původní idea za mě není dobře realizovatelná) a odpovídal jsem spíš na to jak obecně pořešit zálohu dat z toho SSD..