raid használatba vétele

 ( pischta | 2018. szeptember 5., szerda - 17:52 )

Sziasztok!

Csináltam egy raid1 tömböt egy gépen, előkészítésképpen, hogy amikor az éles szerverbe teszem a hdd-ket, kevesebb legyen a kiesés. Az éles szerveren jelenleg van 2 degraded raid, ezeket szeretném kiváltani az új tömbbel. Betettem a 2 új lemezt a szerverbe, elindult a rendszer a régi degraded tömbökkel. Most még szeretnék adatot másolni az új tömbre, mielőtt arról bootolok be. Az új lemezeket látja:
/dev/sdb1: UUID="41860217-e159-3052-6f62-154c40ae5fd5" UUID_SUB="2d07fa04-5f8f-79c1-b3c6-cdac76135ba7" LABEL="ds1223:0" TYPE="linux_raid_member" PARTUUID="f99c403d-01"
/dev/sdc1: UUID="41860217-e159-3052-6f62-154c40ae5fd5" UUID_SUB="6b5ea63d-1a3a-d6e9-e515-4d9b6cf88139" LABEL="ds1223:0" TYPE="linux_raid_member" PARTUUID="18446755-01"
De nem tudom használatba venni. Nem csinálok ilyent napi szinten, próbálkoztam néhány dologgal, eddig sikertelenül:
cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdd1[1]
976630336 blocks super 1.2 [2/1] [_U]

md2 : active raid1 sda3[2]
482883392 blocks super 1.2 [2/1] [U_]

md1 : active raid1 sda2[2]
4878272 blocks super 1.2 [2/1] [U_]

md0 : active raid1 sda1[0]
487360 blocks [2/1] [U_]
pvscan
mdadm --detail --scan
ARRAY /dev/md0 metadata=0.90 UUID=0fd34779:41b2dc8b:544cdd3e:4e1b9688
ARRAY /dev/md/1 metadata=1.2 name=xen3:1 UUID=917d82a3:1909b5d9:da51ad50:53480d63
ARRAY /dev/md/2 metadata=1.2 name=xen3:2 UUID=d78880a5:bfda0428:409cfed4:eb4aec80
ARRAY /dev/md3 metadata=1.2 name=xen3:data UUID=976e2a09:f507b181:70c2efa6:0fa7506a
mdadm --auto-detect
mdadm --assemble -u 41860217:e1593052:6f62154c:40ae5fd5

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nemmmm....igazán értem mi a gond. A raid tömbök látszanak. Igaz féllábúak. Erre LVM? Sima particiók? Esetleg mindent kihagysz és egyből fájlrendszer?

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Igen, amik látszanak, degradedek. Ez a két régi hdd.
Valójában az sdb1, és az sdc1 kellene nekem egy tömbben. Ezeken van lvm, és bootolható Debian Xen szerver.

Lvm tutorialt kéne olvasni.
Nagy vonalakban:

- pvcreate az új raid device-okra
- vgextend hozzáadni a meglevő vg-hez az új pv-t
- pvmove átmozgatni az adatokat az új diszkekre (új pv-re, új raidre)
- vgreduce eltávolítani a régi diszkeket

Az egész móka mehet reboot (és kiesés) nélkül.
--
Gábriel Ákos

Ez mind szépen hangzik, de elég veszélyesnek is ahhoz, hogy rögtön egy éles rendszeren próbáljam ki... Jelenleg két volume groupom van, az új raiden egy. Bizonyára ez is megoldható, de nem akarok az éles rendszeren kísérletezgetni, úgyhogy számomra még mindig marad a kérdés, hogyan tudnám elérni az új raidet.

1. Csináld meg ugyanezt vm-ben, működni fog
2. Ugye van mentés?
3. új diszkek elérése, ha nem akarod őket berakni a mostani vg-be:

- pvcreate a raid-eken
- vgcreate az új raid device-okkal
- lvcreate
- mount

és tényleg kéne lvm tutorialt olvasni
--
Gábriel Ákos

"2. Ugye van mentés?"

+1
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

"Ugye van mentés?"
Pontosan ezért nem akarok ilyen műveletet az éles rendszeren eljátszani, akkor sem, ha virtuális gépben már eljátszadoztam vele. Még ha van is mentésem, ha ez keresztbe áll, azt akkor is sok idő helyretenni. Inkább vállalom, hogy lesz egy reboot, miután átmásoltam az adatokat (nagy részét), minthogy mindent vissza kelljen állítanom mentésből.
Nekem ezért nem tűnik járható útnak, amit tanácsolsz. Nekem már létezik a volume group, és a logical volume-ok is.
Nem azért tettem fel itt a kérdésemet, hogy rtfm választ kapjak. Ha konkrét oldalt ajánlasz, ahol a kérdésemre választ kapok, akár egy hosszabb leírásban is, azt köszönettel elfogadom.

// OFF
Én a veszélyesebb "pár perces" munkákat mindig pénteken, munkaidő után végzem el. :)
Mi hétvégén amúgy nem dolgozunk, így a "pár perces" munkára van több, mint 48 órám.

Szerintem válaszoltam a kérdésedre.
A tutorial-t (nem a manual-t!) azért ajánlottam mert szerintem könnyen érthető.
Más megoldást választottál, te dolgod. Ha rám hallgatsz, azt csinálsz amit akarsz. Öreg vagyok én már ahhoz hogy ingyen győzködjek bárkit bármiről. Egyszer elmondom, segítek, de ennyi.

--
Gábriel Ákos

Értem. Azért köszönöm, hogy foglalkoztál a kérdésemmel :)

1., Nem tudom, jól értem-e, de 2 üres disk-et soft-raid-be szerveztél egy _másik_ rendszeren, mint amin használni szeretnéd és így akarod átrakni az újba, mint EGY disk-et?
MIÉRT? Nem mondom, hogy a disk-re írt superblock-ok alapján nem ismerné fel és állna össze, de nyersz vele bármit is a bizonytalanságon kívül?

2., Mért nem a degraded array-eket teszed rendbe (legalább az egyiket)

3., A fentebb már ajánlott pvmove/pvremove tökéletesen működik HA a féllábú raid disk nem döglik ki alóla másolás közben. De ez normál adatmásolás közben is megtörténhet.
LVM volume-ok között nem hiszem, hogy át lehet mozgatni LV-t, azt mindenképp adat szinten kell másolnod.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

1: igen, pontosan :)
Mi a bizonytalanság?
2. Volt ilyen gondolatom is. Mérlegeltem, és az jobb megoldás volt, hogy veszek két nagyobb lemezt, melyekkel egy, az eddiginél nagyobb kapacitású raidem lesz, mint az eddigi raidekkel összesen (az egyik raidhez már nem is kaptam volna lemezt).
3. Mindig van HA. Nem akarok ekkorát kockáztatni. Adat szintjén szeretnék másolgatni, kevésbé látom rizikósnak. Csak ehhez működésre kell bírnom a már egyszer összeállított raidet.

Ez esetben - mivel, ha jól értem, még tök üresek a disk-ek? - hagyd a ..csába az "előkészített" raid-et, fogd az új disk-eket és az éles gépben definiáld újra a tömb-öt! Sokkal hamarabb és fájdalommentesebben megvagy, mintha a kibányászott superblock-ok alapján akarsz feléleszteni egy amúgy üres tömböt. (Ja, na EZ a bizonytalanság! ;) )

Ezután a fő (megtartani kívánt) VG-t én mindenképp pvmove-olnám! Okos megoldás, másolja az adatokat, addig nem írja át az LVM config-ot, amíg az utolsó bittel is nem végzett. Már többször csináltam éles rendszeren, több Tera adattal.
Sajnos, ha gond van az egyetlen disk-el, az ugyanannyi eséllyel jön elő, bármilyen módon "nyekteted" végig az adatolvasással. De reméljük, nem lesz gond! (még akkor is marad a régi LVM eredeti állapotban)
Aztán, ha ez megvan, utána mehet át adat szinten a megszüntetendő VG tartalma. Ez már attól függ, mi van rajta, mennyire tudod leállítani azoknak az adatoknak az I/O-ját.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nem teljesen üres. Beállítottam rajta az lvm-et, előre legyártottam a szükséges köteteket. Telepítettem rá egy Debian Xen-t, hogy bootolható legyen. A Xen rendszert viszont, hogy ne kelljen nulláról telepítenem, felülírtam a működő Xen mentésével. Következő lépés volt, hogy betettem az új hdd-ket a szerverbe, bebootoltam a régi rendszert, és most fogom átmenteni az adatokat. Amikor bebootolok az új raidről, már csak a változásokat kel rsyncelnem.

Én is pont ebben gondolkoztam tegnap. Vannak fontos(abb) adataim (amikről persze van hidegmentés, de az nem up-to-date), van két ugyanolyan disk-em és majd jól raid1-be kötöm őket.

De inkább hagytam a francba az egészet. Hogy miért? Mert egyszer már besz*ptam egyszer nagyon sw raiddel és idebent a cégnél komoly gépekkel hwraidnél is voltak csúnya összeomlások.

Így kövezzetek meg, de maradtam a "paraszt megoldásnál", van belőle egy master diskem és annak a backup párja, rsync pedig óránként szinkronizál. Messze nem a legjobb megoldás, bár a "hoppá, véletlen töröltem valamit amit nem kellett volna" féle user error ellen jobban véd, mert míg nem történt meg a sync addig megvan az előző verzió.

Sok éve használok soft raidet, ilyen gondom nem volt. Volt már, hogy kidőlt lemez, és vettem helyette, be is tudtam tenni, gond nélkül ment.

Nekem csak annyi volt, hogy a teljes kötet pakkot áttettem egy új gépbe. Az új gép bebootolt, majd automata elkezdett az fsck szorgoskodni. Utána a gép ex post facto kijelentette, hogy a vinyók nem tartoznak raid kötetbe.
Idebenn meg annyi történt a hwraid-del, hogy egyszer véletlenül úgy lett elindítva, hogy a raid5 tömbből az egyik disk ki volt véve. Vissza ki lett kapcsolva, vissza lett dugva, de már nem akarta a raid kártya őket újra egyként kezelni. Újra kellett initelni a tömböt.

A megoldás:
mdadm --assemble /dev/md4 /dev/sdb1 /dev/sdc1
Ekkor még auto-read-only-ba tette.
Ez megoldotta ezt is:
mdadm --readwrite /dev/md4

Az mdadm amikor összeállítja a tömböt, akkor auto-readonly-ba teszi. Az első írási művelet ezt az állapotot megszünteti, nem kell külön readwrite opció - de lehet.

Nem teszem külön hozzászólásba, de:
a fentebb írt ok, amiért nem a degraded tömb került gyógyításra, az volt, hogy az új winyók kapacitása nagyobb.
Ha egy nagyobb kapacitású winyó kerül a rendszerbe, akkor az mdadm automatikusan csak annyit használ belőle, amennyit a kisebb kapacitású miatt tud - viszont ha szinkronba jött a tömb, akkor a régi de még jó winyó is kivehető. Ekkor betehető a második új winyó is, majd ha az összeszinkronizált, akkor mehet mdadm resize is.

Ami probléma lehetőséget látok a megvalósított megoldásban:
- a régi típusú raid tömb a raid blokkot a storage végére tette, így az elején rögtön az fs volt - a winyo bootolható volt szimplán (rég mókoltam vele, ha grub már érteni raid, akkor ez nem probléma)
- az auto assemble is van az a rendszer, ahol az /etc/mdadm.conf alapján gurul, ami kikerül az initramfs-be. Az új tömb új uuid, ami itt nem lesz meg az mdadm.conf-ban - ez is okozhat boot problémát
Ezek persze csak lehetőségek, nem feltétlenül következnek is be - de ha mégis, akkor jó tudni ezekről.