Dotaz: DRBD (aka zachrana dat z QNAPu)

[Datalooser]

Dobry den,

prosim zkusenejsi o pomoc s DRBD. Doted jsem ho znal jen z doslechu. Snazim se v rychlosti neco nacist, ale zatim je to malo.

Pokousim se vydolovat data z noveho QNAPu, kteremu po par mesicich odesla zakladni deska. Podle recenzi na internetu to potkalo hodne lidi. Servis v NL nestiha a po nejake dobe vraci penize.

Oba disky jsou vporadku. MD raidy se sestavi a na oddilech, kde je rovnou EXT4 pro system, jsou videt data - konfiguracni soubory, logy, atd. Horsi je to s oddilem pro uzivatelova data. Ta jsou na think provisioned LVM, pod kterym bezi DRDB.

Pokus nahodit DRDB dopadne takto:

# drbdadm up r1
strange bm_offset -2112 (expected: -1928)
No valid meta data found

A ted se ptam:

- Muzu prikazem "drbdadm create-md r1" vytvorit znovu metadata, aniz bych poskodil data na disku?

- Da se pomoci nejakeho offsetu dumpnout disk, abych z DRDB oddilu dostal Physical Extends pro PV?

Nerad bych to resil stylem pokus/omyl, protoze vytvorit pracovni kopii disku trva DDckem 10 hodin.

Dekuji

dl

.

----------

Puvodni originalni konfiguraky a info ze stroje, kde to zkousim:

# lsmod | grep drb
drbd                  425984  0
lru_cache              16384  1 drbd
libcrc32c              16384  2 btrfs,drbd

# rpm -qa | grep drb
drbd-utils-9.13.0-lp152.2.3.1.x86_64
drbd-9.0.22~1+git.fe2b5983-lp152.2.2.1.x86_64

# blkid -c /dev/null /dev/md126
/dev/md126: UUID="43c1a77e5b530960" TYPE="drbd"

# cat /etc/drbd.d/global_common.conf
global {
        usage-count no;
}
common {
        handlers {
        }
        startup {
        }
        options {
        }
        disk {
        }
        net {
        }
}

# cat /etc/drbd.d/r1.res
resource r1
{
    syncer
    {
        rate 4G;
    }
    on HomeHost
    {
        device /dev/drbd1;
        disk /dev/md126;
        meta-disk internal;
        address 127.0.0.1:7789;
    }
    on FakeHost
    {
        device /dev/drbd1;
        disk /dev/md126;
        meta-disk internal;
        address 1.0.0.1:7789;
    }
}

# drbdadm up r1
strange bm_offset -2112 (expected: -1928)
No valid meta data found

# cat /proc/drbd
version: 8.4.11 (api:1/proto:86-101)
srcversion: B5223DD0E70DC76DE10377F

 1: cs:Unconfigured

LOG z puvodniho NASu:
# grep drb pstore_2_201907101733.log
[   14.619019] drbd: initialized. Version: 8.4.5 (api:1/proto:86-101)
[   14.625194] drbd: GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @U16BuildServer40, 2019-06-20 06:15:46
[   14.635647] drbd: registered as block device major 147
[   39.414676] drbd r1: Starting worker thread (from drbdsetup-84 [2460])
[   39.421491] block drbd1: disk( Diskless -> Attaching )
[   39.426832] drbd r1: Method to ensure write ordering: flush
[   39.432392] block drbd1: Adjusting my ra_pages to backing device's (32 -> 1024)
[   39.439668] block drbd1: drbd_bm_resize called with capacity == 7794125112
[   39.446521] drbd_realloc_pages use the Default memory
[   39.451747] block drbd1: resync bitmap: bits=7611451 words=118929 pages=233
[   39.458682] block drbd1: size = 3717 GB (3897062556 KB)
[   39.483867] block drbd1: recounting of set bits took additional 0 jiffies
[   39.490650] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[   39.498546] block drbd1: Suspended AL updates
[   39.502897] block drbd1: disk( Attaching -> UpToDate )
[   39.508111] block drbd1: attached to UUIDs 9EBFAD153C603FE5:0000000000000004:0000000000000000:0000000000000000
[   39.556553] drbd r1: conn( StandAlone -> Unconnected )
[   39.561792] drbd r1: Starting receiver thread (from drbd_w_r1 [2461])
[   39.568374] drbd r1: receiver (re)started
[   39.572393] drbd r1: conn( Unconnected -> WFConnection )
[   40.603095] drbd r1: conn( WFConnection -> Disconnecting )
[   40.603103] drbd r1: Discarding network configuration.
[   40.613849] drbd r1: Connection closed
[   40.617616] drbd r1: conn( Disconnecting -> StandAlone )
[   40.622996] drbd r1: receiver terminated
[   40.626915] drbd r1: Terminating drbd_r_r1
[   40.634108] block drbd1: role( Secondary -> Primary )
[851456.448823] block drbd1: role( Primary -> Secondary )
[851456.454085] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.460100] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.501104] block drbd1: disk( UpToDate -> Failed )
[851456.506178] block drbd1: bitmap WRITE of 0 pages took 0 jiffies
[851456.512172] block drbd1: 3717 GB (7611451 bits) marked out-of-sync by on disk bit-map.
[851456.520147] block drbd1: disk( Failed -> Diskless )
[851456.525389] block drbd1: drbd_bm_resize called with capacity == 0
[851456.531594] drbd r1: Terminating drbd_w_r1

Odpovědi

[Aleš Kapica]

Ta jsou na think provisioned LVM, pod kterym bezi DRDB.

Co to je za zběsilost? A v rámci jednoho fyzického stroje? To jako to drbd běželo přes localhost? Tedy…

MD RAID → LVM → DRBD → Btrfs

A s čím se to jako synchronizovalo? A proč je to blokové zařízení rovnou nad MD raidem a ne nad LV oddílem?

[Max]

Viz můj komentář níže. Zdá se, že QNAP nepoužívá klasické drbd, ale jiné forky a ještě si to možná nějak modifikuje. A drbd používá i na standalone QNAPu, který se nikam nesyncuje, asi jako předpříprava, kdyby klient někdy chtěl syncovat.
Každopádně QNAP má aktuálně ve stáji tři systémy (co vím):

• QES (založený na FreeBSD)
• QTS (což je os založený na Linuxu, kde používá ext4)
• QuTS hero (což je QTS se ZFS, takže asi něco jako produkčně používané ZFSonLinux)

Zdar Max

[Aleš Kapica]

Kdybych to měl v ruce, tak bych se tomu už uměl kouknout na zoubek. Už několikrát jsem měl možnost se přesvědčit, že tyhle zkratky jsou většinou jen marketingové buzzwordy. Každopádně Thin LVM je věc, od které jsem rychle utekl. A DRBD u stroje který se nikam po síti nesyncuje, taky nedává smysl, takže bych tipoval že to tam je jen proto aby nějaký ten jejich tool mohl v případě potřeby ten nod pro sync přidat. Takže to vlastně nejspíš jelo jako neúplný RAID1, nad lokálním MD raidem, a jelikož je problém s metadaty, tak bych to viděl na rozjebaný MD raid.

Pokud se těsně před kolapsem desky něco začalo srát, tak se mohly zapsat nějaké nesmysly (Viz jiné nekonečné diskuze o tom jaká sebou nese rizika MD raid), které nabouraly metadata toho DRBD. Tam se (nejspíš) uchovávají informace o blocích které jsou sunchronizované a které se mají zesynchronizovat. Teoreticky by tedy mělo pro vytažení dat stačit použití offsetu. Každopádně data bych dumpnul v prvé řadě a pak bych experimentoval.

[Max]

Pokud si pročteš diskuse a jak to funguje, tak o žádných poškozených metadatech není řeč, je to skutečně nekompatibilitou. Se podívej na ty linky, co jsem dával.
Zdar Max

[Aleš Kapica]

Bezpředmětné. Ty jsou zajímavé leda tak pro tazatele. Každopádně kdyby to bylo ok, tak by se při nahození následující hláška nejspíš nevypsala. Ta nemá s nekompatibilitou nic společného:

strange bm_offset -2112 (expected: -1928)
No valid meta data found

[Max]

Pokud to hledá metadata tam, kde nejsou, nebo jsou v jiném formátu (= nekompatibilita), tak je ta hláška ok.
Zdar Max

[Aleš Kapica]

Hm, já si spíš říkám, jestlipak má na tom stroji kde to zkouší platnou i tu ip adresu 1.0.0.1

Ale teď jsem si všiml že tam nekompatibilita určitě bude, protože používá DRBD 9.x, ale to pole se hlásí jako verze 8.4.11. Už z tím dlouho nedělám, tak jsem si toho hned nevšiml, ale co si pamatuji tak odlišná verze nástrojů mohla dělat problém.

[Aleš Kapica]

A mimochodem, ten link v podstatě uvádí to co už tady padlo. Ta utilita vyhledá počáteční sektor, kde začíná ten diskový oddíl, který lze namoutnovat a vyhodí příslušný offset.

[Max]

Přesně tak.
Zdar Max

[Max]

S drbd jsem do styku nepřišel, ale google občas něco prozradí. Např. cituji "QNAP uses a drbd fork (rqdrbd) to provide the RTRR functionality (even on a standalone NAS)", takže to klasické drbd úplně tak nebude. A to samé s LVM na tom drbd, cituji " the drbd volume contains an LVM PV containing"

Je tu možnost použít nástroj třetí strany, který to dává. Je jím https://www.r-explorer.com/#ourproducts. Tady na foru dole je info, jak obnovit data i s trial licencí : Mount QNAP Drives to Linux (aktuálně je to poslední komentář).
Zdar Max

[Datalooser]

Dekuji vsem za ochotu. Jeste doplnim:

Proc je to tak blbe udelane? - Nevim. Je to nesmyslne, souhlasim. Udelalo se to samo behem instalace. Asi pokrok. Do ted nebyl problem disky z Qnapu precist v linuxu. S tim je ted konec. Pujcil jsem si od znamych 2 ruzne starsi modely, ale ani jeden neobsahuje drbd. Nova doba, nove modely, nova funkcionalita, nove problemy...

Pripojil jsem disk v Centosu 7.1 ale dopadlo to stejne. Zkusim jeste Centos 6, snad tam bude drbd verze 8.

Zkusim nekde pujcit identicky model QNAPu a pripojit to v nem.

Diky moc

[Aleš Kapica]

Jak už jsem psal, musel bych to vidět. Neznám ten systém, ale tipoval bych, že byl připraven na to, aby uživatelská data mohla být sdílená mezi dvěma Qnapy a tím byla zajištěna HA, pro případ, že jeden z nich umře. Ovšem v takové konfiguraci evidentně neběžel. A proč to tedy tak měl? Inu proto, že dodatečně se DRBD dělá dost blbě, pokud nemáte volné pozice na další disky. Takhle mu stačila jenom mírná úprava konfigurace, a voilá data by se syncovala na druhý QNAP.

Bohužel to Thin LVM teď situaci poněkud komplikuje. Bez něj by to bylo jednodušší. Takhle skutečně nezbývá než najít ten správný offset, a s ním pak namountovat to Btrfs.

[dustin]

Souhlas s tím důvodem k drbd. Mám také na pár místech degradovaný mdraid1, kam jsem chtěl připojit druhé SSD, kdyby byla potřeba vyšší dostupnost (nebyla) a až mdraid dostane podporu trimu (už dostal).

[Max]

Řešení tu máš, najít pomocí toho 3rd sw, kde je partition a pak jí připojit.
Každopádně máš smůlu v tom, že používáš QNAP bez ZFS, s ním by drbd a jiné věci nebyly potřeba.
Zdar Max

[trekker.dk]

ZFS umí synchronní replikaci po síti, že by s ním nebylo potřeba DRBD?

[Max]

Ano, ale jen s 3rd rozšířením (je dostupné i pro ZoL), který by ale neměl vliv na mountnutí zfs jako takového.
Zdar Max

[Aleš Kapica]

Nic proti Maxi, ale existují efektivnější řešení, které lze replikovat i přes více než jeden stroj.

Kdybych já řešil něco podobného, tak bych použil Sheepdog.

[Max]

Já jen říkám, že QNAP má 3 druhy OS a dotyčný má podle mně tu nejméně vhodnou variantu.
Dále je tu ta věc, že QNAP asi nebudou lidi používat pro sestavování clusteru o desítkách node. Spíše budou provozovat jeden NAS, nebo max syncovat do jedné nebo dvou lokalit. Tam si myslím, že clusterová řešení jako Scheepdog, Ceph apod. nemají výkonově šanci, protože jsou navrhována na větší nasazení, větší počty nódů atd. Naopak ZFS s jedním placeným doplňkěm, co udělá HA, je podle mně velmi vhodné řešení, které dobře kombinuje výkon a požadavky na HA/failover.
Zdar Max

[Aleš Kapica]

No tak to se pleteš. Sheepdog funguje v podstatě podobně jako Btrfs. V kombinaci s ním to nemá chybu. A na rozdíl od Cephu funguje i z jednoho nodu.

Pokud jde o QNAP, tak jasně, nemáš-li jinou možnost, pak tebou navrhovaná verze asi bude nejlepší.

[R]

Presne kvoli takymto problemom som pri firemnej poziadavke na datove ulozisko dal kupit normalny server - s dvoma zdrojmi, iDRAC a podporou. Na to normalny Debian s LVM.

[Datalooser]

Zjistil jsem, ze DRBD uklada metadata na konec diskoveho oddilu. Minimalni velikost metadat je 128 MB (pro disky < 8 TB). Ve verzich si myslim problem nebude, jak Centos 7.1 tak onen QNAP bezi na verzi DRBD8.

QNAP # cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by @UBuildServer40, 2019-03-28 06:16:13, HA:disabled

CentOS71# cat /proc/drbd
version: 8.4.11 (api:1/proto:86-101)
srcversion: B5223DD0E70DC76DE10377F

Dalsi problem bude v LVM, jsou tam nejake nezname atributy. Asi vlastni rozsireni LVM. Nejde aktivovat na openSUSE Tumbleweed ani na CentOSu 8.2, ktere by podporu THIN LVM2 meli umet.

# pvscan
  WARNING: Unrecognised segment type tier-thin-pool
  WARNING: Unrecognised segment type thick
  WARNING: Unrecognised segment type flashcache
  WARNING: PV /dev/md126 in VG vg1 is using an old PV header, modify the VG to update.
  LV tp1, segment 1 invalid: does not support flag ERROR_WHEN_FULL. for tier-thin-pool segment.
  Internal error: LV segments corrupted in tp1.
  Cannot process volume group vg1
  No matching physical volumes found

Nakonec nezbylo, nez sehnat ten samy model QNAPu, pripojit disky - vsechny filesystemy nabehly se statusem CLEAN, aktivovat jednotlive vrtvy dle videa https://youtu.be/cvuLTgvnTjY a odsypat data po siti.

Protoze nekterym nedosla tragicnost cele situace, tak znovu opakuji. Byla to bezna NASka, pravdepodobne v defaultni konfiguraci, porizena uzivatelem domu za ucelem zalohovani blbosti z mobilu a notebooku. Ne firemni uloziste v HA konfiguraci.

Dekuji vsem za ochotu a brzy na videnou, treba u disku ze Synology

[Max]

Protoze nekterym nedosla tragicnost cele situace, tak znovu opakuji.

Myslím si, že všem to tu bylo jasné a již ti bylo několikrát vysvětleno, proč je to řešení takto postavené. A to, že to má někdo doma na tom nic nemění.
Zdar Max