Fórum Root.cz
Hlavní témata => Server => Téma založeno: pokus 30. 05. 2014, 12:25:40
-
Dobrý den,
máme webový server a máme tam dva 300G disky v RAID1 a potřebovali bychom je přemigrovat na SSD disky. Problém je v tom, že Disky jsou v RAIDU poškozené, tzn system je na jednom disku a domovský adrsář na druhém disku. Nemáme moc odvahu disky synchronizovat, ať nepříjdeme o data nebo se RAID a disky nepoškodí ještě víc.... Dá se nějakým způsobem přemigrovat stávající běžící systém na nové SSD disky? Dá se to udělat za chodu systému? Kdyby byl RAID v pohodě tak by to šlo přímo momoci RAIDU, že by se vytáhl jeden disk místo něj dal SSD a synchronizovalo by se to, ale jak jsem psal výše RAID je nějaký divný v tomto pžípadě. Uvažoval jsem vytvořit na serveru další raid a překopírovat tam všechny data třeba pomocí dd nebo rsync, ale nemám s tím zkušenosti.Poradíte prosím?? Máte s tímněkdo zkušenosti? Děkuji
-
Osobně bych asi rozdělil RAID tak, abych měl funkční systémovou část a funkční datovou část a zbylé oddíly bych vyhodil.
Z mých (téměř nijakých) zkušeností bych to pak kopíroval rsyncem, ale zvážil bych předtím, zda nevypnout služby (minimálně databázi) - já osobně bych je zastavil, dokud by se to nezkopírovalo. Ale to záleží na využití a nutnosti fungovat... Měl by se ale dát naplánovat výpadek služeb a informovat návštěvníky statickou stránkou... Někdy v noci.
Teď maličko techniky - SATA (předpokládám, že máte SATA) je plug-n-play, takže nový disky bych si troufnul připojit za běhu, aby se neriskovalo restartem zboření stávajících disků. Možná jde omezit rychlost kopírování (z důvodu nižší zátěže stávajících nalomených disků), ale nevím kde. Každopádně to tu na foru někde zmíněno je... :-)
Jsou to rady domácího kutila, neprovozuju kritický aplikace a je to prostě jen takovej pohled selskym rozumem...
-
Teď maličko techniky - SATA (předpokládám, že máte SATA) je plug-n-play, takže nový disky bych si troufnul připojit za běhu, aby se neriskovalo restartem zboření stávajících disků. Možná jde omezit rychlost kopírování (z důvodu nižší zátěže stávajících nalomených disků), ale nevím kde. Každopádně to tu na foru někde zmíněno je... :-)
Rsync nemá problém s obmedzením rýchlosti:
rsync --bwlimit=1024
Takto nastavujem ja limit pri synchronizácii so vzdialeným serverom, posieti ide rýchlosťou približne 1MB/s.
-
skoda jen, ze tazatel ma zrejme supertajny projekt o kterem nam nic nerekl - jake zelezo, jaky os, jaka DB...
-
Tak super tajné to není... ale zajímalo by mě co byste o železe chtěl vědět? Jinak OS Debian 6,x musel bych se podívat a je tam apache, php, a mysql weby jsou uložené v home a db taky.
-
Ty obecný věci, jako je vypnutí databáze kvůli celistvosti dat nebo třeba nerestartování/nevypínání PC kvůli tomu, že by se disky už nemusely probrat, to platí asi vždy. Znám případy, kdy po restartu už se disky k ničemu neměly...
Jinak rsync by šel udělat na neproměnlivá data a databázi pak odstavit fakt jen na dobu rsyncu databáze, že...
-
u SATA hotplug musi bejt povolenej na desce, casto byva defaultne (na beznych deskach, nevim, jak serverovky) pravdepodobne z duvodu kompatibility vypnutej (nastavuje se v BIOSu), kazdopadne by nemel bejt problem ty SSD pro tuto operaci pripojit docasne pres USB, pripadne to delat pres sit
-
pridaj ssd disky do stareho RAIDu. po synchronizacii ssd disk odoberies (budes mat z neho degradovany RAID) a potom k nemu pridas dalsi ssd disk. zopakujes pre druhy RAID...
-
Problém je v tom, že Disky jsou v RAIDU poškozené, tzn system je na jednom disku a domovský adrsář na druhém disku. Nemáme moc odvahu disky synchronizovat, ať nepříjdeme o data nebo se RAID a disky nepoškodí ještě víc....
Tomu moc nerozumím. Jak je systém na jednom disku a home na jiném? Když se RAID rozpadne, tak je degraded, jede z něj pořád všechno, akorát to jede z jednoho disku.
Nebo chceš říct, že se vám RAID rozpadl a vy jste nějak ručně namountovali něco z jednoho a něco z druhého? To by byla teda dost hodně divočina...
Tak super tajné to není... ale zajímalo by mě co byste o železe chtěl vědět? Jinak OS Debian 6,x musel bych se podívat a je tam apache, php, a mysql weby jsou uložené v home a db taky.
No nedodal jsi prakticky žádné informace. Už jenom "RAID" je široký pojem - může to být čistě softwarový RAID, fakeraid na nějaké levné desce, solidní hw RAID za osm tisíc... Podle toho, co píšeš, to bude jedna z těch prvních dvou variant, ale jestli chceš pomoct v takhle krizové situaci, bylo by fajn, kdybys dodal co nejvíc relevantních údajů... Pro začátek bys mohl vysvětlit, jak's to myslel s tím, že něco jede z jednoho disku a něco z druhého... Ideální je neplkat, ale dodat výpis relevantních příkazů - mount, mdadm, dmraid, /proc/mdstat, smartctl...
Vykopírování na nový disk není žádná raketová věda, ale musíš dodat informace.
Teď maličko techniky - SATA (předpokládám, že máte SATA) je plug-n-play
S tím hodně opatrně. Pokud to na konkrétní desce není vyzkoušeno, tak bych se do toho nehrnul. Nevím, jak na Linuxu, ale na FreeBSD mi jeden takový pokus skončil totálním umrtvením jádra, což asi není zrovna situace, do které by se OP chtěl dostat :) (nevím, jestli je to vůbec závislé na OS nebo jenom na nastavení BIOSu, jenom vím, že jsem jednou prostě připojil disk s tím, že "SATA je přece hotplug" a totální mrtvo...)
Pokud OP nechce riskovat, řešil bych to nejspíš zhruba touhle cestou: připojit nový disk přes USB, vytvořit nad ním RAID (pokud jde o softraid), nahrát tam data (rsync apod.), zastavit všechny služby, znovu rsync, změnit na tom novém RAIDu konfiguraci bootování, vypnout, přepojit normálně na SATA + přihodit ten druhý disk, zapnout, modlit se, aby ta krávovina jménem GRUB najela a nemusel jsem laděním GRUBu způsobit hodinový výpadek :), druhý disk přidat do RAIDu.
-
samalama: Tak to bych zrovna nedoporučoval. RAID bude chtít synchronizovat maximální rychlostí a nedivil bych se, kdyby pak klekly disky úplně...
Samozřejmě zde vycházím(-e) z informace, že disky jsou nakouslé a očekává se jejich HW selhání. Pokud tomu tak není a jde pouze o rozbořený RAID, tak je naše snažení zbytečné a už to mohlo dávno jet na novém SSD :-)
Mirek (offtopic): Já byl při připojení SATA disku v pohodě. Dokonce i PATA mi šla takhle tupě připojit a začít s tím fungovat (i když to bylo asi spíš o štěstí na konkrétní desku, že to nějak fachalo).
-
Mirek (offtopic): Já byl při připojení SATA disku v pohodě. Dokonce i PATA mi šla takhle tupě připojit a začít s tím fungovat (i když to bylo asi spíš o štěstí na konkrétní desku, že to nějak fachalo).
Jo, jde to - když to mám na konkrétní desce vyzkoušený konkrétní postup s konkrétním OS (např. http://koitsu.wordpress.com/2010/07/22/freebsd-and-zfs-hot-swapping-sata-disks-with-ahci/ ), tak není problém. To ale nebude případ OP - a v kombinaci s už tak krizovou situací bych se do žádnýho dalšího dobrodružství nepouštěl :)
-
Asi hlavní je zvážit co tam vlastně běží a jak je to využívaný. Pokud je to nějaký server kde si můžeš dovolit odstávku tak bych volil čistou instalaci. Bude jistota že to půjde, dáš si tam novější verze sw a určitě tam nezůstane "kostlivec z minulosti" ... předem si vše připravit a za noc je hotovo.
-
Před čase jsem na foru založil toto téma kde jsem chtěl přemigrovat z klasických disků na ssd disky. Rád bych zde napsal problémy kteé při migraci nastaly. Pro připomenutí jednalo se o server, který měl swraid1 přičemž raid se rozpadl tak že na jednom disku byl sunkční systém a na druhém funkční home, a disky byly celkově někjaké divnétak jsme raději ani nesynchronizovali raid... viz výše... Kolega dal do serveru nové ssd disky vytvořil sw raid1 a stajné oddíly na disku se stejným souborovým systémem jako na ostrých discích. Pak jsem oddíl po oddíle zkopírovali pomocí rsync. Poté musel být server vyplut a pomocé live distribuce se udělal poslední rsync z ostrých disků na ssd disky. Pak se disky přehodily a zkoušeli jsem nagotovat, jenže problém grub nenajel.... takže instalace grubu pomoví lice distribuce jenže ani pak grub nenajel... výladek serveru už byl skoro hodinový tako kolega dal původní disky do serveru a ssd disky vzal do kanceláře k průzkumu. V kancelář jsem dal disky do druhého serveru, který by měl být podobný ostrému serveru, pomocé live distra jsem disky namounotval (raid se sestavil) a pomocé chroot jsem nainstaloval grub který byl v původní distribuci. Po restarut serveru se načetlo menu zavaděče s možnosti výběru jádra... jenže po výběru jádra jsem se dostal do stavu kdy mi jádro nenastartovalo (vypsalo to něco jako že disk neexistuje) divné v příkazové řádce grubu jsou disky vidět i raid je sestavený když dám ls (md/0)/ tak mi to vypíše root home je taky funkční, grub je v pořádku jádro systému na disku je... abych to zkrátil všechno co to má mít to má ale nejede to :D Možná je to řadičem řadičem disku, který nemusí být kompatibilní s distribucí systéímu který chci starotvat (bios disk vidí), možná je to tím že distribuce nemá ovladač pro tento disk (v ostrém serveru diskx viditelné byly když na ně kolega kopíroval data), možná se stala někde chyna při přenosu systému.... a možná si debian6 s jádrem 2.6 neporadí s ssd disky intel sšřéé series 240G.... Máte někdo prosím podobné zkušenosti nebo nápad jak toto řešit? Děkuji všem kteří se vyjádří.
-
zeby upravit /etc/fstab...?
btw po precitani tvojich litanii mam pocit, ze ani nevies o com pises :)
-
fstab jsem upravoval pokud myslíš zmenu uuid disku
-
vypíše to tuto chybu viz. obrázek http://postimg.org/image/4r3lso38d/
když dám ls /dev/sd* tak to žádný disk nezobrazí takže jak kdyby to disky nevidělo přičemž grub z disku najede a disky jsou videt v biosu.
-
asi bych zkusil upravit grub, kam bych nedaval uuid disku, ale primo cestu k md.
-
To jsem taky zkoušel ale napíše to tu samou chybu akorát místo uuid bude /dev/md0.... když mi to zkončí tou chybou tak se tam dají psát jednoduché příkazy třeba ls /dev/md* nebo ls /dev/sd* v obou případech to disky nevidí
-
upravit mdadm.conf v initrd
-
posílám konfiguracu grubu nevešlo se mi to na jednu fotku tak je to na dvou http://postimg.org/image/5pkvfqqwl/ http://postimg.org/image/z31i9h2y7/
-
upravit mdadm.conf v initrd
Jak si toto prosím myslel? Nemám s tímto zkušenosti poraď prosím.
-
ak sa dobre pamatam a nemylim (raz som riesil rovnaky problem pri migracii raid1 na nove disky), treba aktualizovat mdam konfig v initrd, kedze sa ti zmenili uuid. skus sa cez live cd chrootnut do systemu na raide (treba mountnu /proc, /dev a /dev/pts) a spust update-initramfs -u -k all. ak nepomoze, tak potom rozbalit initrd a urobit upravu rucne:
mkdir /tmp/initrd
cp /mnt/root/boot/initrd.img-X.Y.Z.img /tmp/initrd.gz
cd /tmp/initrd
gunzip initrd.gz
cpio -id < initrd.img-X.Y.Z
rm initrd.img-X.Y.Z
--- upravit mdadm.conf ---
find . | cpio --create --format='newc' > /tmp/initrd.img-X.Y.Z
gzip /tmp/initrd.img-X.Y.Z
cp /tmp/initrd.img-X.Y.Z.gz /mnt/root/boot/initrd.img-X.Y.Z.img
-
novy mdadm.config vygenerujes takto nejako:
echo "DEVICE partitions" > mdadm.conf
echo "HOMEHOST <system>" >> mdadm.conf
for dev in $(find /dev/ -type b -name 'sd*'); do mdadm --examine --scan $dev; done | sort | uniq >> mdadm.conf
konfig najdes v tom rozbalenom ramdisku na klasickom mieste /etc/mdadm/mdadm.conf
-
Udělal sjem vše dle tvých rad, šlo to fajně akorát mě překvapilo že při přegenerování mdadm.conf zůstaly uuid disku nezměněné oproti původní vezri... samozřejmě původní mdadm jsem zálohoval a tvožil jsem nový mdadm dle návodu..... každopádně vypsalo to teď tut hlášku viz obrázek http://postimg.org/image/d2blyux5r/1b8228b8/
-
Opravil jsem grub a píšt to toto http://postimg.org/image/yuzg8fzrl/
-
urcite mas dobre nastaveny fstab?
-
za chvilku tady dám screen fstabu
-
v grube (ked nabootuje) skontroluj, ci ma root spravny uuid
-
Udělal jsem textový výstup z konfiguramu fstab, uuid, mdadm, a grub
prosím zkontroluj třeba je tam fakt chyba
fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/md0 during installation
UUID=610cce82:7ad1:4cb8:a733:8973d8e246fc / ext3 errors=remount-ro 0 1
# /home was on /dev/md2 during installation
UUID=b91e63e:7571:480c:b21a:0add4ce14ccf /home xfs defaults,nobarrier 0 2
# swap was on /dev/md1 during installation
UUID=f67507f9:5d8e:4941:838a:b9e0963c069f none swap sw 0 0
/dev/sdc1 /media/cdrom0 udf,iso9660 user,noauto 0 0
10.10.10.1:/home/backups/ /mnt/backups/ nfs rsize=32768,wsize=32768,timeo=14,intr
ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jun 20 15:55 00E0-53EE -> ../../sdd1
lrwxrwxrwx 1 root root 11 Jun 20 15:48 610cce82-7ad1-4cb8-a733-8973d8e246fc -> ../../md127
lrwxrwxrwx 1 root root 10 Jun 20 15:48 6225-CE68 -> ../../sda1
lrwxrwxrwx 1 root root 11 Jun 20 15:48 b91e635e-7571-480c-b21a-0add4ce14ccf -> ../../md126
lrwxrwxrwx 1 root root 11 Jun 20 15:48 f67507f9-5d8e-4941-838a-b9e0963c069f -> ../../md125
/etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 UUID=8475ff67:bf743625:a81e3560:6e00630d name=skiservis:0
ARRAY /dev/md1 metadata=1.2 UUID=ba2d154a:0003806d:c2d5600b:21661334 name=skiservis:1
ARRAY /dev/md2 metadata=1.2 UUID=35ffe47b:37ea7a32:1afe0ace:c01a875d name=skiservis:2
/boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
terminal_input console
terminal_output console
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md/0)'
search --no-floppy --fs-uuid --set 610cce82-7ad1-4cb8-a733-8973d8e246fc
echo 'Loading Linux 2.6.32-5-amd64 ...'
linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=610cce82-7ad1-4cb8-a733-8973d8e246fc ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-2.6.32-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md/0)'
search --no-floppy --fs-uuid --set 610cce82-7ad1-4cb8-a733-8973d8e246fc
echo 'Loading Linux 2.6.32-5-amd64 ...'
linux /boot/vmlinuz-2.6.32-5-amd64 root=UUID=610cce82-7ad1-4cb8-a733-8973d8e246fc ro single
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-2.6.32-5-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
-
Ještě jsem zapoměnl na výstup mdadm. Vše je z chrootnutého systému
/dev/md125:
Version : 1.2
Creation Time : Thu Jun 5 17:45:15 2014
Raid Level : raid1
Array Size : 6296024 (6.00 GiB 6.45 GB)
Used Dev Size : 6296024 (6.00 GiB 6.45 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Jun 18 16:55:13 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : skiservis:1
UUID : ba2d154a:0003806d:c2d5600b:21661334
Events : 40
Number Major Minor RaidDevice State
0 8 37 0 active sync /dev/sdc5
1 8 21 1 active sync /dev/sdb5
/dev/md126:
Version : 1.2
Creation Time : Thu Jun 5 17:45:25 2014
Raid Level : raid1
Array Size : 217637212 (207.56 GiB 222.86 GB)
Used Dev Size : 217637212 (207.56 GiB 222.86 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Jun 20 15:32:07 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : skiservis:2
UUID : 35ffe47b:37ea7a32:1afe0ace:c01a875d
Events : 99
Number Major Minor RaidDevice State
0 8 38 0 active sync /dev/sdc6
1 8 22 1 active sync /dev/sdb6
/dev/md127:
Version : 1.2
Creation Time : Thu Jun 5 17:43:31 2014
Raid Level : raid1
Array Size : 10491932 (10.01 GiB 10.74 GB)
Used Dev Size : 10491932 (10.01 GiB 10.74 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Jun 20 16:06:22 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : skiservis:0
UUID : 8475ff67:bf743625:a81e3560:6e00630d
Events : 171
Number Major Minor RaidDevice State
2 8 33 0 active sync /dev/sdc1
1 8 17 1 active sync /dev/sdb1
-
vyzera to ok.
skus este pre istotu urobit fsck a skontroluj, ci v initrd mas modul ext3.
-
fsck uděmám ale nevím jak zkontrolovat ten modul....
-
rozbalit initrd ako som pisal skor a pozriet do /lib/modules/X.Y.Z/kernel/fs
-
Zatím jsem udělal pouze kontrol v chrootnutem systému pomocé cat /proc/modules a ext3 modul tam cyhbí a na ostrém funkčním serveru je ještě kouknu do toho initrd
-
Šichta mi pomalu končí takže disky beru domů a pokračování doma, na to musím přijít čím to jo .-)