UMGUM.COM (лучше) 

Замена диска ( Замена вышедшего из строя дискового устройства. )

10 октября 2011  (обновлено 29 декабря 2014)

OS: Debian GNU/Linux Lenny.

Рассмотрим практический случай - замену вышедшего из строя диска на одном из серверов хранилища, описываемого в этом разделе.

Припомним схемотехнику:

UDEV, S.M.A.R.T - обеспечение корректного опознания при загрузке системы и мониторинга оборудования;
DRBD - обеспечение целостности данных путём дублирования носителей на уровне блоков;
AoE - представление блочных устройств носителей в единой точке сбора;
MHDDFS - сбор файловых систем блочных носителей в файловую систему с одной точкой монтирования.

По хорошему, при выходе из строя одного из физических носителей, DRBD сохраняет функциональность схемы до выхода из строя последнего (второго, третьего или четвёртого; смотря сколько дубликатов мы предусмотрели) физического носителя DRBD-спарки. В идеальном случае было бы достаточно заменить дисковое устройство, внести изменения в индекс опознания устройств и отдать команду подключения нового диска в целевую DRBD-спарку. Учитывая то, что зеркалирование DRBD абсолютно прозрачно, этого никто даже не заметил-бы.


Всё так, но есть нюанс. В Debian Lenny реализация AoE оказалась кривовата. AoE вообще продукт откровенно сыроватый и выбран мною был по той-же причине, по которой мы вынуждены были собирать хранилище их бюджетного барахла - отсутствие средств и времени. В общем, AoE в Debian Lenny работает не то, чтобы плохо - скорее с особенностями, выражающимися в том, что после исчезновения из видимости представляемого блочного устройства и его последующем появлении драйвер AoE на машине-агрегаторе отказывается его переподключать. В спецификации драйвера есть описания методов мониторинга, отключения и переподключения блочных устройств, только они не работают - их можно только подключать. Выгрузить модуль AoE, для переподключения всех блочных устройств тоже не получается - система вульгарно "виснет". Потому, до выяснения и устранения, лучше представить, что потеря диска всерьёз повлияла на работу схемы и для её восстановления требуется полная остановка и перезапуск после обеспечения корректной работы каждого уровня, снизу вверх.

Потому останавливаем приложения, работающие с хранилищем, демонтируем файловую систему MHDDFS, демонтируем блочные устройства, представленные AoE и, на той машине, где вышло из строя дисковое устройство, останавливаем вещание блочного устройства утилитой vblade.

После остановки всех вышестоящих подсистем займёмся заменой дискового устройства.

Чтобы окончательно удостоверится, какое из устройств вышло из строя - смотрим состояние DRBD:

# cat /proc/drbd

....
  0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:520192 nr:0 dw:0 dr:520192 al:0 bm:72 lo:0 pe:0 ua:0 ap:0
      resync: used:0/61 hits:32476 misses:36 starving:0 dirty:0 changed:36
      act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
....
  4: cs:Connected st:Secondary/Secondary ds:Diskless/UpToDate C r---
    ns:0 nr:192992 dw:192992 dr:0 al:0 bm:45 lo:0 pe:713 ua:0 ap:0
....

Для полного счастья можно остановить DRBD-спарку, хотя это совершенно не обязательно:

# cat /etc/drbd.conf

....
resource drbd4 {
....
  on node2.storage.local {
    device      /dev/drbd4;
    disk        /dev/odsk2.4;
    address     IP:port;
    meta-disk   internal;
  }
....

# drbdadm down drbd4

# cat /proc/drbd

....
  0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:520192 nr:0 dw:0 dr:520192 al:0 bm:72 lo:0 pe:0 ua:0 ap:0
      resync: used:0/61 hits:32476 misses:36 starving:0 dirty:0 changed:36
      act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
....
  4: cs:Unconfigured
....

Выясняем серийный номер заменяемого дискового устройства:

# hdparm -i /dev/odsk2.4 | grep SerialNo | awk '{print $6}'

Удостоверяемся, что этот номер присутствует в индексе нашей самодельной подсистемы автоматического определения оборудования (после замены диска впишем сюда серийный номер нового устройства):

# cat /etc/custom/hdd/dev/list

.... odsk2.4/SN ....

Выясняем, к какому системному блочному устройству ведёт "жёсткая" ссылка, используемая нами в подсистеме DRBD:

# ls -il /dev | grep odsk2.4

2851 brw-r

2 root disk    8,  65 2011-09-15 08:15 odsk2.4

# find /dev -inum 2851

/dev/odsk2.4
/dev/sde1

Перед физическим отключением дискового устройства SATA необходимо его освободить от обращений к нему каких бы то ни было приложений и отдать команду непосредственного удаления из системы:

# echo 1 > /sys/block/sde1/device/delete

....
sd 4:0:0:0: [sde] Synchronizing SCSI cache
sd 4:0:0:0: [sde] Stopping disk
ata5.00: disabled
....

Изымаем дисковое устройство из корзины, устанавливаем и подключаем на то-же место новое:

# dmesg

....
sd 4:0:0:0: [sde] Attached SCSI disk
....

Размечаем новое блочное устройство под размер полностью совпадающий с его DRBD-спаркой (предварительно стерев всю прежнюю разметочную информацию):

# dd if=/dev/zero of=/dev/sde bs=1k count=1
# blockdev --rereadpt /dev/sde

# cfdisk /dev/sde

На выходе получаем диск с одним разделом:

# ls /dev | grep sde

....
sde
sde1
....

Отдаём подсистеме DRBD указание пересоздать "мета-информационные" блоки на соответствующих устройствах:

# drbdadm create-md drbd4

md_offset 1000202235904
al_offset 1000202203136
bm_offset 1000171675648

Found some data
==> This might destroy existing data! <==

Do you want to proceed?
[need to type 'yes' to confirm] yes

Writing meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block sucessfully created.

Перед запуском синхронизации увеличиваем допустимую для этого блока скорость, чтобы не ждать завершения процесса в течении суток:

# drbdsetup /dev/drbd4 syncer -r 120M
# drbdadm adjust drbd4

Запускаем в работу DRBD-спарку:

# drbdadm up drbd4

В случае, если в блочном устройстве DRBD уже есть хоть один из членов с состоянием "UpToDate", синхронизация начнётся в направлении от него без особых на то указаний.

# cat /proc/drbd

....
  4: cs:SyncTarget st:Secondary/Secondary ds:Inconsistent/UpToDate C r---
    ns:0 nr:922080 dw:920736 dr:0 al:0 bm:55 lo:44 pe:1232 ua:42 ap:0
      [>....................] sync'ed:  0.1% (952938/953838)M
      finish: 3:59:52 speed: 67,720 (65,764) K/sec
      resync: used:3/61 hits:58761 misses:59 starving:0 dirty:0 changed:59
      act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
....

Просто любознательным и тем, кому больше нечем заняться, можно запустить автоматическое регулярное обновление отображение процесса синхронизации:

# watch cat /proc/drbd

После завершения синхронизации не помешает вернуть блоку его рабочую скорость:

# drbdsetup /dev/drbd4 syncer -r 20M
# drbdadm adjust drbd4

Если на то будет необходимость, явно задаём приоритет в спарке:

# drbdsetup /dev/drbd4 primary

Серийный номер нового дискового устройства нам известен, разумеется. Вносим его в индекс нашей самодельной подсистемы автоматического определения оборудования вместо серийного номера старого дискового устройства:

# cat /etc/custom/hdd/dev/list

.... odsk2.4/SN ....

На этом процедуру замены и корректировки настроек можно считать завершённой, далее следует запустить все остановленные подсистемы. Завершающих штрих - перезагрузка сервера-агрегатора, собирающего блочные устройства с помощью AoE (как я выше упоминал - это практически единственный способ справится с капризной AoE).

Напоследок замечу: описанный пошаговый сценарий избыточен и рассматривает вариант замены устройства, гарантирующий достижения поставленной цели в рамках самого неблагоприятного случая - выхода из строя не только устройства хранения информации, но и подсистемы управления хранилищем. В общем случае достаточно было бы заменить дисковое устройство, пересоздать блоки "мета-информации" и заменить в индексе серийный номер, не останавливая при этом работу никаких подсистем.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )