Jak jednoduše ohrozit data v RAIDu na Ubuntu

23.8.2007 13:52 | Přečteno: 1380× | Ubuntu

Jak jsem psal do dřívějšího příspěvku, tak vytvořit RAID pole není nic těžkého. Bohužel jsem zjistil, že vážně ohrozit jeho integritu také ne. V tomto příspěku si ukážeme, jak na to.

Na starém Debianu Sarge jsem měl disk rozdělený na cca 25 pododdílů. Někde okolo /dev/hda20 už neměly vytvořené udev, tak jsem je dodělával ručně. Widle sice na /dev/hda24 neviděly, to mi ale moc nevadilo, hlavně že Linux jo, že. S novým diskem jsem měl podobné plány a tak jsem vzal cfdisk a vytvořil /dev/sda16 a přidal ho do RAIDu. A to jsem neměl dělat ... Jak on si ten geniální systém (UBUNTU) při startu vytváří /dev/* (to jsem si hned neuvědomil) tak si je čísluje takhle:

brw-rw---- 1 root disk 8, 0 2007-08-23 15:17 /dev/sda
brw-rw---- 1 root disk 8, 16 2007-08-23 15:17 /dev/sdb
brw-rw---- 1 root disk 8, 32 2007-08-23 15:17 /dev/sdc
brw-rw---- 1 root plugdev 8, 48 2007-08-23 13:22 /dev/sdd

a tak dále. Takže major 8, minor po 16. Pozorný čtenář již jistě tuší, co se stane, když dáme mdadm -C /dev/md16 /dev/sda16 /dev/sdb16 .blablabla..

Ano, je to tak. V Ubuntu na Satě to mdadm pochopí jako raid 8,16 s 8,32 a začne dělat mdadm /dev/sdb /dev/sdc . Bylo by to k smíchu, kdyby to nebylo k pláči. Naštěstí jsem md včas stopnul, jenže mezitím mi již RAID stihnul přepsat MBR. Pro spestření mi ještě čas od času BIOS přehazuje číslování disků, takže nebýt toho, že sdc je 80G a ostatní 300ky tak bych už opravdu střílel.

Tak fajn, víme čím to je, tak to jen opravit . Pěkně do záchranné konzole, stopnout RAID. Kopie partition table. Zrušit md16. mdadm -r. NIC. mdadm --fail. NIC. Mám tam jeden RAID0 s nezálohovanýma fotkama. SHIT. apt-get externí_disk, tar czvf ... sakra, RAID0 nejde pustit ... co s tím ... přepíšeme md16 jiným polem .. naštěstí je ještě z čeho vyrobit pseudo-raid. Vytvoříme ... ok RAID0 běží, zbytek píše [U_]. Záloha fotek. Restart. md16 je už zase sdb-sdc. SHIT. mdadm --stop --scan. editace /etc/mdadm/mdadm.conf, připisuji zouvalé ARRAY /dev/md16 level=raid0 num-devices=2 UUID=xxx, které mi vytvořil pseudo raid0 (výpis jsem získal přes mdadm --detail --scan). Teď už sdb-sdc ostrouhá, protože se nemůže vytvořit neboť je md16 již používáno :-P. Znovu promyslet rozdělení disku tak, abych se vešel do 16 oddílů ... nahodit systém. Pole jede v degradovaném režimu. mdadm /dev/mdX --add /dev/sdbX ... pro všechny RAIDy .. UFF, všechno jede, zálohy jsem naštěstí dělal zbytečně. Mnoho hodin v p*, ale vše chodí. Zlatej Debian/Slack.

       

Komentáře

[Michal Kubeček]

U takhle komplikovaného rozdělení by už asi bylo jednodušší udělat si jen jeden RAID z celých disků a nad ním udělat rozdělení pomocí LVM. Případně udělat jednu mirrorovou volume group a jednu normální.

[Sinuhet]

Pri tolika oddilech, nebylo by jednodussi pouzit lvm? Jenom si nejsem jist jak mdadm zkousne vytvareni raidu nad lvm oddily.

[Michal Kubeček]

Obvyklejší je dělat to obráceně, tj. LVM nad RAIDem. Jinak budete mít velmi malou kontrolu nad tím, co s čím v tom poli kombinujete.

[Michal Kubeček]

mdadm by to bylo jedno, jemu stačí, že je to blokové zařízení. Ale bylo by asi potřeba zasáhnout do inicializačních skriptů, protože v distribucích se obvykle nejdřív inicializuje SW RAID a potom LVM.

[Tom.š Ze.le.in]

Neměl by s tím být problém. A neumí lvm stripping a mirroring samo od sebe? Autor stejně podle minulého zápisku používal jen RAID1.

[Michal Kubeček]

Striping ano, mirror AFAIK ne.

[Tom.š Ze.le.in]

V manu lvcreate to je, ale nezkoušel jsem:

-

m, --mirrors Mirrors

Creates a mirrored logical volume with "Mirrors" copies. For example, specifying "-m 1" would result in a mirror with two-sides; that is, a linear volume plus one copy. Specifying the optional argument "--nosync" will cause the creation of the mirror to skip the initial resynchronization. Any data written afterwards will be mirrored, but the original contents will not be copied. This is useful for skipping a potentially long and resource intensive initial sync.

Specifying the optional argument "--corelog" will create a mirror with an in-memory log verses a disk-based (persistent) log. While this removes the need for an extra log device and *may* be slightly faster, it requires that the entire mirror be resynchronized upon each instantiation (e.g. a reboot).

[Michal Kubeček]

Ale není z toho moc jasné, jak (a jestli vůbec) bude zajištěno, že jednotlivé kopie budou na různých fyzických zařízeních. Jednak může být volume group složena jen z jednoho disku, jednak i když ne, bude-li obsahovat např. sda1, sda3, sdb1 a sdb3, striktně vzato by neměla poznat, které dvojice smí použít pro mirror a které ne.

[Tom.š Ze.le.in]

Kopie budou na zařízeních, která se tomu podstrčí, to je pravda. Trochu jsem si s tím kdysi hrál - pokud je disků méně než potřebných zařízení, řvalo to myslím. (bez --corelog minimálně tři zařízení pro -m1). A pokud je jich víc na jednom fyzickém disku, tak to zjištěno není - jiné nástroje to nějak kontrolují?

[Michal Kubeček]

Těžko, obecně asi neexistuje způsob, jak zjistit, jestli jsou dvě bloková zařízení na stejném fyzickém médiu. U SW RAIDu je to jednodušší, tam musíte výslovně říct, z čeho se má ten mirror sestavit.

[Tom.š Ze.le.in]

Mimochodem, je nějaký rozumný důvod (kromě toho, že disk už je rozdělený a nemůžu/nechce se mi to znova dělit) proč dávat do jedné volume group dva oddíly z jednoho disku?

[Michal Kubeček]

Když to dělám na čistém disku a mám čas si to rozmyslet, tak asi ne. Spíš to vzniká tak, že ten druhý byl původně použit pro jiné účely a uvolnil se (třeba když člověk zruší Windows :-) ).

[Michal Kubeček]

P.S.: striping, je to odvozeno od stripe, ne strip

[Tom.š Ze.le.in]

ano, samozřejmě :)

[David Jaša]

Nahlásil jsi to?

[Georgius]

Zatím jsem byl rád, že jsem rozchodil mašinu. Nejsem si ale tak úplně jistý, čí je to bug ... jede v tom udev i mdadm .. Anebo je to fičůra saty, že neumí víc než 15 oddílů ... zatím jsem takový zvěrstva jako 25 oddílů dělal jenom PATě, která ani necekla ...

[Shadow]

IMO všechny SCSI disky (sd*), tedy i SATA disky, mají omezení na 15 oddílů. IDE zařízení (hd*) podobná omezení nemají (maximum je kolem 60 oddílů).

[Ritchie]

Úplně přesně, sd mají omezení na 15 oddílů, hd na 63. Více v seznamu Linux Device List.

[Ritchie]

Co a komu měl nahlásit? Že nečetl dokumentaci? Tohle je vlastnost jádra, nikoliv chyba.

[Michal Kubeček]

No, pokud mu opravdu udev bez nějakého přesvědčování vytvořil /dev/sda16 s major 8 a minor 16, tak to bych za bug bez váhání označil.

[Mortal]

RAID stihnul přepsat MBR

ja myslel, MBR neni soucasti raidu, nebo se mylim?

a dotaz ciste ze zvedavosti:
Jakou ma vyhodu rozdelit disk na tolik oddilu?
Uz pred casem jsem dospel k nazoru, ze nejlepsi ohradky pro data jsou obycejne adresare

[Dalibor Smolík]

ja myslel, MBR neni soucasti raidu, nebo se mylim?
Hm, to by mě také zajímalo. rozdělil jsem oba disky na příslušné oddíly a a přiřadil jsem k sobě v rámci RAID1 jednotlivé oddíly o stejné velikosti a typu - využil jsem tímto celou kapacitu disků.
Myslím, že MBR je v tomto případě součástí raidu.

[Michal Kubeček]

V tomto případě ne. Jeho součástí by byl, kdybyste sestavil pole z celých disků, tj. např.

  mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb

[Michal Kubeček]

Záleží na tom, z čeho máte to pole sestavené. V tomto případě ale došlo k tomu, že program, který měl v úmyslu přepisovat /dev/sda16, přepsal ve skutečnosti /dev/sdb, takže přepsal MBR v místě, kde očekával obyčejný BR oddílu.

Jakou ma vyhodu rozdelit disk na tolik oddilu?

Proč na tolik, to nevím, ale obecně tím můžete zajistit, že můžete používat pro různé účely různé typy filesystému, různé parametry mountu (nosuid, nodev apod.) a že zaplněním jednoho filesystému (třeba /var/log) nepřivedete systém do tak zoufalého stavu, jako kdybyste měl všechno na jednom. Ale při větším počtu filesystémů je vhodnější použít LVM, protože máte téměř jistotu, že u některého z nich neodhadnete správně předem potřebnou velikost.

[Tom.š Ze.le.in]

Lidi jsou různí.

Někdo má rád root partition r/o.

Někdo chce některá data šifrovat na úrovni filesystému.

Někdo chce různé filesystémy pro různé části systému.

Někdo má pocit, že image DVDčka nemusí být soubor, ale může být rovnou samostatný oddíl, když to stejně je k mountování. (a pak to roste rychle).

Někdo nechce aby mu věci přetékaly mezi přihrádkami.

Někdo chce mít odděleny /home a /usr/local kvůli zálohování a/nebo upgradům.

[Georgius]

ja myslel, MBR neni soucasti raidu, nebo se mylim?

Neměl by být. V tom je právě pointa celého příspěvku - že mdadm špatně pobral zařízení a místo sda16-sdb16 mirroroval sdb-sdc. Pak už součástí RAIDu je

Jakou ma vyhodu rozdelit disk na tolik oddilu?
Uz pred casem jsem dospel k nazoru, ze nejlepsi ohradky pro data jsou obycejne adresare

Nejsou všechna vajíčka ve stejném košíku. Příklad: vypnou proud/přepětí/zásah blesku/HW havárie disku+vrcholná smůla: odejdou data na partišně, na kterou se zrovna zapisovalo (já vím, že to není moc pravděpodobné, ale není to dlouho, co jsem řešil TOTÁLNĚ LEHLOU ext3 kdy se mi nepodařilo zrekonstruovat (pořádně) ani z jedné ze záloh FATky). Pokud bude víc partišn tak budu řekněme pracovat s databází a přijdu o databázi (no dobrá, mám RAID1, takže o ni asi nepřijdu, taky už nemám EXT3, ale riziko stále existuje i když je řádově nižší) ale o výsledky statistického hodnocení v jiném adresáři ne. Čili zhruba toto je moje motivace.

[Shadow]

TOTÁLNĚ LEHLOU ext3

Znepokojující. Používám ext3 právě z důvodu spolehlivosti.

takže o ni asi nepřijdu, taky už nemám EXT3

Co tedy používáte? Existuje něco spolehlivějšího než ext3?

[Dalibor Smolík]

Znepokojující. Používám ext3 právě z důvodu spolehlivosti.
Přesně tak, ext3 mám na serveru také. Je nějaký pádný důvod, používat jiný filesystém pro tyto účely? (poučení pro příště)

[Dan Ohnesorg]

Myslim ze o jinych filesystemech se ma smysl bavit, kdyz je potreba vysoky vykon. Stran spolehlivosti nelze dneska ext3 snad nic vytykat.

Nicmene pokus opravit FAT na ext3 musel nutne skoncit tragickym neuspechem

P.S. Preteceni major/minor timto zpusobem povazuji za bug oznacitelny nejvyssi prioritou.

[Michal Kubeček]

Nebo když je ten filesystém využíván nějakým velmi specifickým způsobem, např. velmi vysoký počet velmi krátkých souborů nebo naopak velmi dlouhé soubory.