DRBD + LVM = redundáns JBOD?

Linux-haladó

Sziasztok!

A szituáció:

2 CentOS Linux gép, van működő DRBD az alap rendszernek. Ez csak azért írom, hogy nem kell időt tölteni a DRBD beállításával és működésével. Megy.

Az lenne a cél, hogy mindkét gépen legyen meg a biztonsági mentés, ami a gépre kerül ilyen céllal.
További szempont, hogy az adatmentő tárhely később bővíthető legyen, ha kevés.

Kezdetnek beteszek 1-1 azonos méretű HDD-t az 1-1 gépbe, DRBD-n összeszinkronizálja, ez eddig tiszta.
Hogy a legésszerűbb megoldani,hogy ha berakok újra 1-1 azonos, más méretű HDD-t az 1-1 gépbe, hogy egy tárhelynek lássa a 2 HDD-t, közben DRBD-n szinkronizálja?
Később, ha indokolt, akkor újra akár a harmadik pár HDD-t ha berakom, akkor azt a 3 HDD-t egynek lássa?

Ha egy gépen lenne, és nem lenne DRBD, akkor LVM, vgextend, és egybe rakom a HDD-ket. (Ennek vannak hátrányai és előnyei, lásd lentebb.)
Ezt hogy lehet leginkább logikus módon kivitelezni, hogy gépenként 2-3 HDD-t összerakjak 1 logikai HDD-be (mint a JBOD), és ez legyen áttükrözve egy fizikailag másik szerverben lévő, azonos méretű HDD-kre, DRBD-vel?

A_LINUX: DRBD(HDD1a + HDD2a + HDD3a) -- B_LINUX: DRBD(HDD1b + HDD2b + HDD3b)

Előny:
- egyben látom az összes szabad helyet, nem kell foglalkozni azzal, hogy elfér-e ez ide vagy oda az adott mentés, vagy betelik-e az adott tárhely

Hátrány
- ha mind a két gépben elromlik a 3-ból bármelyik HDD pár (HDD1a + HDD1b), tehát mind a két gépen, akkor ha jól sejtem borulni fog az egész logikai tömb és akkor teljes adatmentés elveszett. Vagy mit lehet ilyenkor tenni?

A_LINUX: DRBD_x(HDD1a) + DRBD_y(HDD2a) + DRBD_z(HDD3a) -- B_LINUX: DRBD_x(HDD1b) + DRBD_y(HDD2b) + DRBD_z(HDD3b)

Előny:
- Minden HDD csak simán 1-1 DRBD resource a 2 gépben, akkor hiába száll el a párból mind a 2 HDD (HDD2a+HDD2b), a többi adatot nem befolyásolná (HDD1 és HDD3 elérhető lenne).

Hátrány:
- Nem tudom használni ésszerűen a HDD1 / HDD2 / HDD3 -nál a szabad helyet, ha 500 GB-ra 50 GB-ot akarok menteni és 40 GB hely van, akkor nem tudom oda rakni, ahova való lenne a mentés
- Figyelni kell a tárhelyhasználatra és meg kell tervezni, hogy melyik HDD-re melyik mentés kerül

Ti melyiket javasolnátok, pro/kontra?
Van ennél ésszerűbb megoldás? :)

Köszönöm! :)

  • 1457 megtekintés

( Lacyc3 v | 2015. 11. 23., h – 12:29 )

Tedd LVM-re a DRBD-t. Összevonod a lemezeket egy VG alá, arra mehet a DRBD. Ha A) hoszt kiesik, akkor nyilván róla minden hullik, de csere után visszaszinkronizál a DRBD.

Akkor így fog kinézni:

A_LINUX: LVG (DRBD_x + DRBD_y + DRBD_z) -- B_LINUX: LVG (DRBD_x + DRBD_y + DRBD_z)

Tehát ha írok az LVG-re, akkor a DRBD resource-ok szépen összeszinkronizálják magukat.
Ha meg elromlik valamelyik pár DRBD, a páron belül mind a kettő HDD, akkor elveszett a teljes LVG ugye?

Sakk-matt,
KaTT :)

( joseph | 2015. 11. 23., h – 13:13 )

BTRFS + RSync combo.

btrfs-vel konnyen kialakithatsz tomboket, meg ugy is, hogy a HDD meretek kulonbozoek.
ha szukseges a local backup-on, snapshot keszitese is megoldhato.
quota, defregmentation, rebalancing, etc, sorolatnam a btrfs elonyeit.
a kerdes, mekkora meretu fajlokkal szeretnel dolgozni?

rsync pedig egy egyszeru eszkoz a fajlok szinkronizalasara a halozaton keresztul.
elony lehet, hogy incremental backup-ot tudsz csinalni, ami jol jon, ha a halozat a ket gep kozott nem olyan gyors.

drbd-t akkor javaslom, ha a blokk eszkozre van szukseg a gepek kozott es nem a fajlokra, illeteve fajlrendszer fuggetlen szinkronizaciot szeretnel hasznalni.

Szia!

Köszönöm az infót!
BTRFS-t még nem használtam, utána fogok nézni. Eddig nem valami jókat hallottam erről, bár főként ha ETX4 helyett használták, mint alap op rendszer fájlrendszert, mert lassú és hogy töredezettség mentesíteni kell. Mi a gyakorlatban az előnye a BTRFS-nek, az EXT4 vagy az XFS-sel szemben, ha az utóbbi kettővel LVM-et használok, és úgy oldom meg a tárhely összerakást?

Rsync-et azt rendszeresen.

Főként nagy, több GB-os, vagy pár száz MB-os fájlok lesznek.

Sakk-matt,
KaTT :)

XFS-t nem ismerem, igy csak az ext4-vel tudom osszehasonlitani (ha lehet egyaltalan).

btrfs eseten a blokk eszkozre (legyen a Te osszeallitasod szerint) HDD-re keszitett fajlrendszer-hez adod a masodik HDD-re keszitett fajlrendszert es nem ugy mint az LVM eseten, a HDD-hez adod a masik HDD-t es arra keszited a fajlrendszert. (na ezt jol megfogalmazodott...)

ez abban esetben egy latvanyos elony, ami nem feltetlenul eletszeru pelda, hogy a mukodo fajlrendszert ami pl. tukor uzemmodban mukodik, atalakitod un. osszefuzotte, uzem kozben.

a btrfs copy on write (CoW) fajlrendszer, ami "helytakarekos", csak a megvaltozott blokkokat irja felul nem az egesz fajlt, ha valtozik.

meg egy hasznos elony, hogy on-line tomoritest tudsz alkalmazni ami ext4 eseteben nem elerheto.

ja, es ne feledkezzunk meg a jelenleg divatos SSD-hasznalatrol sem, SSD awarness, ha SSD-n hasznalod, akkor ugyel arra, hogy az egyes irasi blokkok hol helyezkedjenek el az adathordozon.

- mindig egész fájl változik, tehát ez a funkciója nem lesz kihasználva a BTRFS-nek
- eleve tömörített fájlok kerülnek rá, tömöríteni sem kell
- nem SSD, hanem csak HDD lesz használva, ez biztos

az átalakítás az egyetlen előnye, amit LVM is tud, igaz, más szinten, más módon

Sakk-matt,
KaTT :)

( Elbandi v | 2015. 11. 23., h – 16:40 )

a "parban" levo diskekre teszel drbd-t. ekkor lesz dev/drbd0, dev/drbd1, stb device-d, azokat "megformazod" pvdevice-vel majd hozzaadod a volume grouphoz. ezt szepen tudod majd kesobb novelgetni az uj diskek uj drbd345-evel.
ezutan a local volument sima tudod novelni, ahogy a nagykonyvben le van irva (lvextend+resize2fs).

tulkepp raid mirrorokat osszefuzol egy nagy egessze.

az lvm confba nalam be van allitva hogy csak drbd0-an keressen lvm dolgokat, mashol ne:

filter = [ "a|^/dev/drbd.$|", "r/.*/" ]

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Köszönöm!

Ez a filter különösen jó ötlet.

De akkor ez a megoldás is elhasal és adatvesztés lesz, ha a párban lévő diszkekből mindkettő elhasal, ugye?

Szóval ha több diszket összefűzök, akkor létezik olyan megoldás, hogy ha egyik megtelik, a másikon folytatja, de ha bármelyiket kiveszem, akkor a többin az adat sértetlenül rajta marad (persze ha egy fájl fele van csak az aktív diszken, akkor nyilván az nem lesz jó).

Sakk-matt,
KaTT :)