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
- 1676 megtekintés
Hozzászólások
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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."
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
// 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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Értem. Azért köszönöm, hogy foglalkoztál a kérdésemmel :)
- A hozzászóláshoz be kell jelentkezni
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!"
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!"
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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ó.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni