Data publikacji: Nov 24, 2012 9:34:41 AM
Na jednym z serwerów konieczna była zmiana dysku (/dev/sda padł zostawiając działajacy /dev/sdb). Serwer posiada dwa wolumeny RAID1 (/dev/md1 i /dev/md2). Na drugim wolumenie jest założony LVM. Po wymianie dysku przystąpiłem do odbudowy RAID. Odbudowę prowadziłem w czasie gdy system normalnie działał.
Najpierw tablica partycji:
# sfdisk -d /dev/sdb | sfdisk /dev/sda
Następnie odbudowa poszczególnych RAIDów:
# mdadm --add /dev/md1 /dev/sda1
A po jego synchronizacji drugiego:
# mdadm --add /dev/md2 /dev/sda2
I teraz zaczyna się thiller. Podczas odbudowy, w okolicach 9% (partycja /dev/sda2 i /dev/sdb2 mają po 700+GB) w logach pojawiają się niepokojące błedy:
# cat /var/log/kern.log
Nov 23 22:59:09 rescue kernel: ata2.00: error: { ICRC ABRT }
Nov 23 22:59:09 rescue kernel: ata2: soft resetting link
Nov 23 22:59:09 rescue kernel: ata2.00: configured for UDMA/33
Nov 23 22:59:09 rescue kernel: ata2: EH complete
Nov 23 22:59:09 rescue kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Nov 23 22:59:09 rescue kernel: ata2.00: BMDMA stat 0x26
Nov 23 22:59:09 rescue kernel: ata2.00: failed command: READ DMA
Nov 23 22:59:09 rescue kernel: ata2.00: cmd c8/00:00:01:15:ac/00:00:00:00:00/e0 tag 0 dma 131072 in
Nov 23 22:59:09 rescue kernel: res 51/84:f0:11:15:ac/84:00:57:00:00/e0 Emask 0x30 (host bus error)
Nov 23 22:59:09 rescue kernel: ata2.00: status: { DRDY ERR }
Nov 23 22:59:09 rescue kernel: ata2.00: error: { ICRC ABRT }
Nov 23 22:59:09 rescue kernel: ata2: soft resetting link
Nov 23 22:59:10 rescue kernel: ata2.00: configured for UDMA/33
Nov 23 22:59:10 rescue kernel: ata2: EH complete
Nov 23 22:59:11 rescue kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Nov 23 22:59:11 rescue kernel: ata2.00: BMDMA stat 0x26
Nov 23 22:59:11 rescue kernel: ata2.00: failed command: READ DMA
Nov 23 22:59:11 rescue kernel: ata2.00: cmd c8/00:00:01:b9:b1/00:00:00:00:00/e0 tag 0 dma 131072 in
Nov 23 22:59:11 rescue kernel: res 51/84:d0:31:b9:b1/84:00:57:00:00/e0 Emask 0x30 (host bus error)
Nov 23 22:59:11 rescue kernel: ata2.00: status: { DRDY ERR }
Nov 23 22:59:11 rescue kernel: ata2.00: error: { ICRC ABRT }
Nov 23 22:59:11 rescue kernel: ata2: soft resetting link
Nov 23 22:59:11 rescue kernel: ata2.00: configured for UDMA/33
Nov 23 22:59:11 rescue kernel: ata2: EH complete
...
Finalnie sprzęt stwierdził, że /dev/sdb (czyli dysk, który nie został wymieniony) jest błedny i go odpiął. Wylądowałem w niesprawnym RAIDem. Tj. /dev/md1 był OK, lecz ten /dev/md2 zawierał ułamek wszystkich danych.
Natychmiast zrobiłem twardy reset i wszedłem w tryb rescue. Zauważyłem, że dysk /dev/sdb wrócił, /dev/md1 również lecz /dev/md2 nie.
Sprawdziłem przy pomocy:
# smartctl -a /dev/sdb
czy wszystko jest OK z dyskiem - zero zgłoszonych błędów.
Spróbowałem ponownie utworzyć /dev/md2:
# mdadm --create --verbose /dev/md2 --level=1 --raid-devices=2 missing /dev/sdb2
Dostałem komunikat o tym, że partycja już istnieje. Potwierdziłem. I tu zauważyłem jaki popełniłem bład. Przeglądając dla weryfikacji /proc/mdstat zobaczyłem, że nowy /dev/md2 ma metadane w wersji 1.2 a ten stary miał 0.90. Natychmiast usunąłem partycję /dev/md2 i utworzyłem ją ponownie, poprawnie:
# mdadm --stop /dev/md2
# mdadm --remove /dev/md2
# mdadm --create --verbose /dev/md2 --level=1 --metadata=0.90 --raid-devices=2 missing /dev/sdb2
Wg. /proc/mdstat wszystko wyglądało OK. Lecz nie było. Komendy:
# pvdisplay
# vgdisplay
stwierdziła, że nie ma żadnych volumenów
Jak było starsznie - to teraz jest tragicznie. Na szczęscie istnieje coś takiego jak backup konfiguracji LVM, które komendy modyfikujące tą partycję wykonują automatycznie. Partycja /dev/md1 to partycja głowna, na której znajduje się właśnie katalog /etc/lvm/backup z tymi danymi. Na szczęscie te dane miałem poza LVM (i na backupie). Plik z backupem nazywa się tak jak wolumen LVM (u mnie vol). Zawiera on następujące dane (podmontowałem wcześniej /dev/md1 pod /mnt):
# cat /mnt/etc/lvm/backup/vol
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing ..."
creation_host = "..." # Linux ...
creation_time = 1336125817 # Fri May 4 12:03:37 2012
vol {
id = "QVdhGS-1yNm-GVFe-PEUI-CKcK-ZcIM-xmSUI8"
seqno = 66
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "0dOdTp-8CKi-kGjD-LT4K-qxmY-XOWQ-hE9iNW"
device = "/dev/md2" # Hint only
status = ["ALLOCATABLE"]
dev_size = 1453606784 # 693,134 Gigabytes
pe_start = 384
pe_count = 177442 # 693,133 Gigabytes
}
}
logical_volumes {
vservers {
id = "Sn151s-dDh7-CqJo-xF32-eZiM-0e3i-9YA9JC"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1
segment1 {
start_extent = 0
extent_count = 12800 # 50 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
vservers_... {
id = "fuE8UC-28MI-AGEu-ljAl-mNl2-gOWo-srFHy1"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1
segment1 {
start_extent = 0
extent_count = 25600 # 100 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 12800
]
}
}
...
}
}
czyli dane dość kluczowe. Przystąpiłem do odbudowy PV i VG:
# pvcreate --uuid "0dOdTp-8CKi-kGjD-LT4K-qxmY-XOWQ-hE9iNW" --restorefile /mnt/etc/lvm/backup/vol /dev/md2
# vgcfgrestore -f /mnt/etc/lvm/backup/vol vol
(wg. http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/mdatarecover.html)
Później było sprawdzenie czy wszystko jest na miejscu:
# pvdisplay
# vgdisplay
# lvdisplay
I właczenie volumenu:
# vgchange -a y
# mount ...
Dane były. Uff.
Ponieważ synchronizacja /dev/md2 nie zakończyła się poprawnie zacząłem się zastanawiać dlaczego. Użyłem narzędzia dd_rescue aby odczytać /dev/sdb2 do /dev/null:
# dd_rescue -y 0 /dev/sdb2 /dev/null
Efekt. Kolejne błedy w logu. Zatrzymałem dd_rescue. Zleciłem test dysku SMART:
# smartctl --test=long /dev/sdb
Test zakończył się bez stwierdzenia błedów. Czyli co? Kable? Ponieważ serwer jest zdalny nie byłem w stanie tego stwiedzić. Możliwe, że technicy coś zepsuli w tej kwesti. Wykonałem jeszcze raz jeden restart. Macierz /dev/md2 podjęła odbudowę w trybie rescue - która o dziwo zakończyła się bez żadnych problemów. Jupi.
Niestety serwer po restarcie nie wstawał, jedynie w trybie rescue. Ponieważ godzina 5.00 to nie dobra pora na myślenie stwierdziłem ze czas się wyspać. I faktycznie pomogło. Skojarzyłem fakt, że wymieniłem /dev/sda więc pewnie BIOS bootuje z tego dysku a tam przecież nie ma bootloadera! Mam go w MBR a nie w bootsektorze. Uruchomiłem więc lilo, co w trybie rescue wygąda tak:
# mount /dev/md1 /mnt
# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# chroot /mnt
# lilo -v
# exit
# umount /mnt/dev
# umount /mnt/proc
# umount /mnt/sys
# reboot
i system wstał.
Pozostaje jeszcze nierozwiązana kwestia tych błędów sprzętowych. Na razie nie występują, więc wstrzymałem się z interwencją techników celem sprawdzenia okablowania na później - jeszcze coś zepsują.
nawet jak operacja jest tak prosta jak utwórz partycję, dodaj partycje do partycji md, poczekaj aż się zsynchronizuje - zastanów się czy jesteś ewentualnie zerwać nockę
zawsze, jeżeli jest to możliwe zrób backup przed przebudową macierzy, upewnij się że masz wszystkie informacje o wolumenach RAID i LVM (pliki z /etc/mdadm, /etc/lvm)
odtwarzając macierz RAID zawsze pamiętaj o wersji metadanych
po wymianie /dev/sda zawsze pamiętaj o uruchomieniu lilo