HTPC – Odbudowa macierzy Raid 1 po awarii dysku

Nasz domowy serwer zainstalowaliśmy na macierzy Raid 1. Całe szczęście, bo dzięki temu nie trzeba reinstalować systemu i przegrywać wszystkich danych. Jeśli ktoś miał wątpliwości co do sensu poświęcenia dodatkowego dysku, to w takiej sytuacji z całą pewnością doceni zalety redundancji. Obejrzyj nagranie wideo demonstrujące odbudowę macierzy RAID 1 http://video.ezrodlo.pl/media/odbudowa-macierzy-raid1-po-awarii-dysku

Po akcjach z ciągle szwankującym dyskiem ( Seagate Barracuda 7200.11 family, Model: ST3500320AS ) powiedziałem „dość” i zainstalowałem system na dwóch dyskach połączonych w  RAID 1. Nie ma sensu za każdym „padem” dysku  reinstalować wszystkiego od nowa – jest to bardzo czasochłonne. Mam jeszcze jedną uwago-przestrogę  dla posiadaczy dysków „Seagate Certified Repaired HDD”. Jak dla mnie taki dysk NIE NADAJE się do przechowywania ważnych danych ze względu na większą podatność na awarie. Jako dysk systemowy również nie polecam, chyba że ktoś ma dużo czasu i lubi częste reinstalacje. Tak czy inaczej zalecam ostrożność. Do Raid’a 1 idealny – niech pada do woli, będziemy tracić tylko czas i pieniądze na wysyłkę do serwisu. Oczywiście do momentu gdy skończy nam się gwarancja. Na wymienione dyski jest już tylko rok gwarancji.

Wracając do ostatniej awarii. Tym razem otrzymałem dysk z innej serii: Seagate Barracuda 7200.12 family, Model: ST3500418AS. Mam nadzieję, że będzie działał jak należy i to bardzo długo. Dodam jeszcze, że poprzedni model osiągał odczyty na poziomie 85 MB/s. Taki sam dysk, który nigdy nie miał okazji odwiedzić serwisu osiągał 105 MB/s. Model, który teraz otrzymałem(ST3500418AS) wyciąga 117.98 MB/s. No wreszcie!!!

Aktualną specyfikację serwera można zobaczyć po wejściu na stronę http://blog.ezrodlo.pl/serwer/

Wracamy do tematu głównego. Jeśli któryś z hdd ulegnie uszkodzeniu na konto root’a otrzymamy wiadomość email o zdegradowanej macierzy. Dobrze, ale nie każdy przecież wisi cały czas na konsoli ssh. Do monitorowania macierzy można wykorzystać narzędzie z pakietu smartmontools. Dodatkowo monitoring z systemu Nagios + powiadomienie SMS(może opiszę kiedyś jak to zrobić).  Jeśli podejrzewamy, że dzieje się coś nie tak, sprawdźmy stan:

root@htpc1:~# cat /proc/mdstat

Poprawnie funkcjonująca macierz:

md2 : active raid1 sda3[0] sdb3[1]
      4917236 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
      684020 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      4880372 blocks super 1.2 [2/2] [UU]

UU – wszystko OK

_U – dysk wypadł z macierzy
U_ – j.w.

md0 – macierz RAID 1 składająca się z dwóch urządzeń – sda1 i sdb1.
Jeśli potrzebujemy więcej informacji, to wykonujemy polecenie:

root@htpc1:~# mdadm --detail /dev/md0


/dev/md0:
Version : 1.2
Creation Time : Mon Aug 29 16:38:17 2011
Raid Level : raid1
Array Size : 4880372 (4.65 GiB 5.00 GB)
Used Dev Size : 4880372 (4.65 GiB 5.00 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon Oct 29 11:32:02 2012
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Name : htpc1:0 (local to host htpc1)
UUID : f694c08b:33590837:ac417079:497510e4
Events : 176

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

Jeśli któryś z dysków ulegnie uszkodzeniu, zostanie usunięty z macierzy. Jeśli wykryjemy to wcześniej(np. pojawią się błędne sektory) i mamy dysk na podmianę, możemy usunąć uszkodzone urządzenie ręcznie. Najpierw zaznaczamy je jako wadliwe:

root@htpc1:~# mdadm /dev/md0 --fail /dev/sda1
raid1: Disk failure on sda1, disabling device.
raid1: Operation continuing on 1 devices.
mdadm: set /dev/sda1 faulty in /dev/md0
root@htpc1:~# mdadm /dev/md1 --fail /dev/sda2
root@htpc1:~# mdadm /dev/md2 --fail /dev/sda3

Po tych operacjach status macierzy wygląda następująco:

Personalities : [raid1] 
md2 : active raid1 sda3[0](F) sdb3[1]
      4917236 blocks super 1.2 [2/1] [_U]

md1 : active raid1 sda2[0](F) sdb2[1]
      684020 blocks super 1.2 [2/1] [_U]

md0 : active raid1 sda1[0](F) sdb1[1]
      4880372 blocks super 1.2 [2/1] [_U]

Następnie usuwamy dysk z macierzy:

root@htpc1:~# mdadm /dev/md0 --remove /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md0
root@htpc1:~# mdadm /dev/md1 --remove /dev/sda2
root@htpc1:~# mdadm /dev/md2 --remove /dev/sda3

Status macierzy po usunięciu dysku:

Personalities : [raid1] 
md2 : active raid1 sdb3[1]
      4917236 blocks super 1.2 [2/1] [_U]

md1 : active raid1 sdb2[1]
      684020 blocks super 1.2 [2/1] [_U]

md0 : active raid1 sdb1[1]
      4880372 blocks super 1.2 [2/1] [_U]

1. Wyłączamy serwer,
2. Usuwamy uszkodzony dysk i montujemy w jego miejsce sprawne urządzenie,
3. Włączamy serwer.

Podczas uruchamiania zaobserwujemy, że macierz została uruchomiona z jednym dyskiem:

mdadm: /dev/md/0 has been started with 1 drive (out of 2).
mdadm: /dev/md/1 has been started with 1 drive (out of 2).
mdadm: /dev/md/2 has been started with 1 drive (out of 2).


Na nowym dysku tworzymy partycje identyczne jak na aktualnie działającym w macierzy.
1. Zrzucamy układ partycji ze sprawnego dysku:

root@htpc1:~# sfdisk -d /dev/sdb > sdb.part

2. Pobieramy ustawienia z pliku dla nowego dysku:

root@htpc1:~# sfdisk /dev/sda < sdb.part

3. Informujemy jądro linuksa o zmianach:

root@htpc1:~# partprobe

Program partprobe znajduje się w pakiecie parted(apt-get install parted)
Jeśli z jakiegoś powodu nie posiadasz tego pakietu lub nie możesz go doinstalować, uruchom serwer ponownie.

Powyższe ma sens jeśli dodawany dysk jest o takiej samej pojemności. W przypadku dysków większych, utwórz partycje ręcznie.
Pozostałe miejsce możesz przeznaczyć na przechowywanie mniej wrażliwych danych.

Po utworzeniu partycji dodajemy dysk do macierzy:

root@htpc1:~# mdadm /dev/md0 --add /dev/sda1

mdadm: re-added /dev/sda1

root@htpc1:~# mdadm /dev/md1 --add /dev/sda2
root@htpc1:~# mdadm /dev/md2 --add /dev /sda3

W tym momencie dyski są synchronizowane. Czas odbudowy macierzy zależny jest od pojemności, logiczne.

Personalities : [raid1] 
md2 : active raid1 sdb3[1]
      4917236 blocks super 1.2 [2/1] [_U]

md1 : active (auto-read-only) raid1 sdb2[1]
      684020 blocks super 1.2 [2/1] [_U]

md0 : active raid1 sda1[0] sdb1[1]
      4880372 blocks super 1.2 [2/1] [_U]
      [=>...................]  recovery =  6.3% (312256/4880372) finish=4.6min speed=16434K/sec

Pozostaje tylko poczekać na ukończenie procesu. W międzyczasie doinstaluj bootloader Grub na nowym dysku:

root@htpc1:~# grub-install /dev/sda

Tym samym przywróciliśmy sobie spokój ducha :)
Obejrzyj proces odbudowy macierzy „na żywo” http://video.ezrodlo.pl/media/odbudowa-macierzy-raid1-po-awarii-dysku


Powiązane wpisy:

Asus AT3IonT-I Deluxe + Debian = wszystko w jednym
Xbmc - krótkie demo
Measy U1A/U2A - alternatywa dla Raspberry Pi?
Wysłany 29.10.2012 w 13:00 · przez blog.ezrodlo.pl · Stały link
W: HTPC · Opisany jako: , , , , , ,

2 Odpowiedzi

Subskrybuj komentarze przez RSS

  1. Napisany przez Andrzej
    na 24 lipca, 2013 w 10:11
    Stały link

    Witam.

    Opierając się na artykule : http://blog.ezrodlo.pl/htpc/htpc-czesc-1-instalacja-debiana/ instalacja przebiegła sprawnie. RAID 1 działa. Jeśli można mam kilka pytań o raid , mianowicie: po dołączeniu jednego z dysków system startuje, ale od razu Debian informuje o awarii. Jak podłącze odłączony dysk , to według mnie powinien się sam odbudować, ale tego nie robi. Trzeba to robić ręcznie? Po przeczytaniu http://blog.ezrodlo.pl/htpc/htpc-odbudowa-macierzy-raid-1-po-awarii-dysku/ dochodzę do wniosku , że tak ale od momentu dodania dysków do macierzy i synchronizacji. Przecież dysk tylko został odłączony.

    Jeszcze mam jeden problem z raid’em. Po instalacji debiana zauważyłem, że rozjeżdża sie zbudowany RAID w biosie. O co może chodzić ?

  2. Napisany przez blog.ezrodlo.pl
    na 24 lipca, 2013 w 12:17
    Stały link

    Witaj,
    Jeśli jeden dysk zostanie odłączony(nieważne czy ręcznie czy automatycznie, bo przykładowo padła elektronika, lub pojawiły się bad sector’y) to macierz przechodzi w tryb zdegradowany – brakujący/uszkodzony dysk jest automatycznie usuwany z macierzy(w końcu wystąpił jakiś problem). Powrotne dodanie dysku do macierzy, jak zauważyłeś, wymaga ręcznej interwencji – mdadm nie robi tego z automatu. Układ partycji dodawanego dysku musi być taki sam. Co w przypadku jeśli przez przypadek włożyłbyś identyczny dysk, z identycznym układem partycji ale z zupełnie innym systemem/danymi i dysk ten zostałby automatycznie dodany do macierzy ? Straciłbyś dane. Odłączanie dysku w sposób jaki przeprowadziłeś nie ma sensu, bo dysk zawsze usuwany jest z jakiegoś powodu.

Subskrybuj komentarze przez RSS