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]