RTzRa's hive - software:mdadm

mdadm: Добавляем диск в массив

anonymous@undisclosed.example.com (Anonymous) — Sun, 04 Aug 2024 12:12:10 +0000

mdadm: Добавляем диск в массив

Дано: зеркало из 2-х дисков (sdb и sdc), один из которых скоропостижно умер (sdc)

Надо: добавить новый диск в массив, провести ребилд

Решение:

Делаем синк ФС:
```
# sync
```
Помечаем как сбойный, но может быть так что диск уже намертво отвалился и его не будет видно:
```
mdadm --manage /dev/md0 --fail /dev/sdc
```
и удаляем его из массива:
```
mdadm --manage /dev/md0 --remove /dev/sdc
```
Заменяем физический диск
(При необходимости) Удаляем все текущую информацию с нового диска:
```
wipefs -a /dev/sdc
```
Копируем таблицу разделов с текущего диска на новый:
```
sfdisk -d /dev/sdb | sfdisk /dev/sdc
```
Дбавляем новый диск в массив:
```
mdadm --manage /dev/md0 --add /dev/sdc
```
Смотрим статус, должен идти ребилд:
```
cat /proc/mdstat
```

raid, mdadm, add disk, rebuild

Перенос системного раздела на RAID

anonymous@undisclosed.example.com (Anonymous) — Sun, 04 Aug 2024 11:55:38 +0000

Перенос системного раздела на RAID

Ситуация: продакшн-сервер, один диск, что с бэкапами - неизвестно.

Задача: добавить в систему два новых диска, объединить их в RAID-1 (зеркало), перенести на них систему со всеми потрохами с минимальным даунтаймом, старый диск использовать под бэкапы. Железного RAID нет, только fake raid, поэтому выкручиваемся при помощи mdadm.

Система: Ubuntu Server 12.04 LTS

Диски:

Основной, с рабочей системой - sda, один раздел sda1, система ext4
Новый диск №1 - sdb
Новый диск №2 - sdc

До начала операции

Обязательно бэкапим все нужное.

Обновляем систему и устанавливаем необходимые пакеты

$ sudo apt-get update && sudo apt-get upgrade
$ sudo apt-get install mdadm rsync

Добавляем диски в систему

Если сервер поддерживает hot spare - мы на коне. Если нет - можно подключить через USB или иным способом, но в случае большого количества и/или объема данных процесс будет крайне длительным и время простоя будет оочень большим. Не подходит ни один из вариантов? Выключаем сервер и добавляем диски добрым старым способом.

Проверяем все ли диски увиделись:

$ sudo fdisk -l | grep Disk

Убедимся что текущий системный диск это sda:

$ df -h | grep -Po "/dev/..."

Создаем файловые системы

Диск №1:

$ sudo fdisk /dev/sdb
p (убедимся что диск пуст)
n (создаем новый раздел)
p (тип: первичный)
1 (номер партиции)
[Enter]
[Enter] (все пространство под наш новый раздел)
t (тип раздела)
fd (Linux raid auto)
w (записываем изменения и выходим)

Повторяем то же самое для диска №2:

$ sudo fdisk /dev/sdc
p (убедимся что диск пуст)
n (создаем новый раздел)
p (тип: первичный)
1 (номер партиции)
[Enter]
[Enter] (все пространство под наш новый раздел)
t (тип раздела)
fd (Linux raid auto)
w (записываем изменения и выходим)

Создаем RAID-1 (зеркало)

$ sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

Какое-то время будет создаваться рейд, в этом можно убедиться глядя на индикаторы обращения к дискам. Посмотреть текущий статус можно так:

$ sudo mdadm -D /dev/md0

Добавляем информацию о новом массиве в конфигурационный файл:

$ sudo mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Проверяем название массива - оно должно быть прописано правильно! В противном случае мы получим так называемую проблему «md127» (массив виден, но его имя /dev/md127).

Создаем разделы

Смотрим какие разделы были созданы на основном диске:

$ sudo fdisk -l /dev/sda

и создаем такие же на новом RAID-массиве:

$ sudo fdisk /dev/md0

Размер выбираем по желанию.

Не забываем сделать первый раздел загрузочным!

Создаем файловые системы

У меня один общий раздел / и один раздел swap, так что в этом случае все просто:

$ sudo mkfs.ext4 /dev/md0p1
$ sudo mkswap /dev/md0p5

Переносим файловую систему

Примечание: копирование идет пофайлово, поэтому если у вас работают какие-то сервисы и вносятся изменения в данные (СУБД, веб-сервер и т.д.) необходимо в дальнейшем перед перезагрузкой остановить эти сервисы и сделать выборочное копирование информации или решить вопрос при помощи импорта/экспорта. В противном случае есть шансы потерять какие-либо данные.

$ sudo mount /dev/md0p1 /mnt
$ sudo rsync -axu / /mnt/

Если есть желание следить за происходящим, нужно добавить –progress в команду rsync

Подключаем системные каталоги, входим в новую систему

Теперь необходимо сделать настройки в новой системе, при этом не трогая оригинал. Для этого подключаем системные каталоги и переходим в новую систему.

$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /sys /mnt/sys
$ sudo mount --bind /run /mnt/run
$ sudo chroot /mnt

Последняя команда (chroot) переключает нас в новую копию системы, все остальные операции мы будем делать там. Это позволит сохранить рабочий диск нетронутым и при факапе вновь с него загружаться и работать.

Вносим изменения в fstab

Чтобы система смогла загрузиться из нового места ей необходимо объяснить где у нас будут устройства (диски).

/# ls -l /dev/disk/by-uuid | grep md >> /etc/fstab
/# nano -w /etc/fstab

Теперь правим fstab: закомментариваем старые UUID, добавляем вместо них новые. Крайне желательно не ошибаться, иначе система просто не загрузится.

Настраиваем и устанавливаем Grub

Чтобы загружаться с нового массива нам нужно а)установить загрузчик и б)правильно его сконфигурировать.

Сначала обновляем конфигурацию:

/# update-grub
/# cat /boot/grub/grub.cfg | grep UUID_нового_системного_раздела

Необходимо убедиться что новый UUID есть в обновленном конфигурационном файле!

Теперь пора установить загрузчик на наши новые диски:

/# grub-install /dev/sdb

Обновляем конфигурацию модулей ядра

Это нужно сделать для нормальной работы mdadm, иначе получим вышеописанную проблему «md127»

/# update-initramfs -u

Выходим в реальную систему

/# exit

Восстановление рабочих данных

Наступило время восстановления рабочих данных - СУБД и прочее. Но тут каждый все делает самостоятельно.

Перезагрузка в новую систему

$ sudo reboot

Перезагружаем систему, выбираем для загрузки новые диски (через BIOS или любым другим способом), загружаемся. По идее все должно быть хорошо. На всякий случай проверяем с какого же устройства мы загрузились

$ df -h | grep -Po "/dev/..."
/dev/md0

Ага, все хорошо, все заработало.

Заключение

Осталось протестировать работу системы и придумать что сделать с освободившимся диском: пустить его в hot swap, под хранение данных или просто выкинуть.

ubuntu, server, migration, production, raid, mdadm, миграция системы, миграция системного раздела

Почему RAID-6?

anonymous@undisclosed.example.com (Anonymous) — Sun, 04 Aug 2024 11:54:20 +0000

Почему RAID-6?

В качестве вступления

Отсюда: http://habrahabr.ru/post/214707/

Диски имеют параметр, именуемый Unrecoverable Read Error Rate, который на современных бюджетных моделях SATA составляет 1 сектор на каждые сто триллионов битов. Т.е. примерно из каждых записанных 12Тб диск один раз скажет «прости, хозяин, но выдать обратно нужный сектор совершенно никак невозможно; ошибка чтения». Это методическая ошибка, заложенная производителем и потому теоретически гарантирующая невозможность реконструкции массива RAID5 емкостью более 12Тб на дешевых дисках (справедливости ради отметим, что URE на дисках SAS, как минимум, на порядок меньше, а критический объем, соответственно, больше). Эпитафию RAID5 написал Robin Harris в своей статье «Why RAID 5 stops working in 2009» http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162

Почему RAID-6?

Источник: http://habrahabr.ru/blogs/linux/111036/

Как известно, RAID-5 выдерживает смерть одного веника, и после этой самой смерти – до момента когда закончится восстановление рейда с новым винчестером ваши данные под угрозой – восстановление обычно занимало до 70 часов для больших массивов и еще один веник может легко умереть в это время. RAID-6 выдерживает смерть 2-х любых веников. Из минусов – общепризнанное мнение что тормозит, особенно запись, даже по сравнению с RAID-5. Что-ж, проверим.

Почему софтрейд?

Железный рейд нужен только в одном случае – если у него есть батарейка и набортный кеш. Тогда контроллер сразу отвечает ОС что запись на диск завершена на физическом уровне и всякие ACID базы работают очень быстро и безопасно.
В остальных случаях никаких бонусов по сравнению с софт-рейдом нет, одни минусы:

Сгорело железо? Новый сервер? Будьте добры купить тот же контроллер, ну или молитесь о совместимости. Софтрейд из тех-же дисков собирается где угодно.
Цена. Собственно, из-за этого нормальных рейдов с батарейкой я в руках так ниразу и не держал

Ну а те «рейд-контроллеры» которые стоят на обычных материнских платах – вообще никогда не стоит использовать. Они просто дают грузить ОС с рейда за счет набортного биоса (который выполняется центральным процессором, своего процессора нет), на этом их польза заканчивается, и остаются только минусы.

О паре мифов софтрейда

Он жрет много драгоценного процессора. Если мы одним глазком глянем в исходники драйвера RAID в ядре Linux, то увидем, что там давно все оптимизированно под SSE2. А с SSE2 процессор может считать XOR от 16 байт за 1 такт на 1 ядре современного процессора и все упирается в скорость обмена с памятью. Можете прикинуть сколько % загрузки одного ядра сгенерирует поток в 1Гб/сек А ядер то много На практике, с моим Opteron 165 (1.8Ghz 2 ядра) скорость никогда не упиралась в CPU.
Он разваливается и потом хрен соберешь. Если что-то и отваливается – то из-за железа (например обычные винты любят иногда делать всякие фоновые задачи). Добавление вывалившегося веника – простая операция, которая кроме того может проводится автоматически. Впрочем, в среднем это надо делать раз в год.
```
# mdadm /dev/md0 -a /dev/sde1
```
У софтрейда хреновый мониторинг. С мониторингом все отлично и настраиваемо. Достаточно например просто мыло указать в конфиге mdadm и он пришлет вам письмо если что-то случиться с вашим массивом. Очень удобно. Вот например что приходит если один веник отвалился:
```
    This is an automatically generated mail message from mdadm running on XXXXX
    A DegradedArray event had been detected on md device /dev/md0.
    Faithfully yours, etc.
    P.S. The /proc/mdstat file currently contains the following:
    Personalities: [raid6] [raid5] [raid4]
    md0: active raid6 sda1[1] sdc1[4] sdd1[3] sde1[2]
    2929683456 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [5/4] [_UUUU]
    unused devices: none
```
Рекоменую протестировать перед использованием:
```
# mdadm --monitor -1 -m myname@myisp.com /dev/md0 -t
```
У софтрейда очень низкая скорость перестройки массива. В дефолтной конфигурации – да. А если вы дочитаете до конца статьи – узнаете как сделать так, чтобы все перестраивалось со скоростью самого медленного веника.

О роли bitmap

Linux-овый софтрейд поддерживает замечательную фичу: bitmap. Там отмечаются измененные блоки на диске, и если у вас почему-то отвалился один диск из массива, а потом вы его обратно добавили – полная перестройка массива не нужна. Чертовски полезно. Хранить можно на самом рейде – internal, а можно в отдельном файле – но тут есть ограничения (на тип ФС например). Я сделал internal bitmap. И зря. Internal bitmap тормозит безбожно т.к. постоянно дергается головка веников при записи.

Посмотрим на скорость:

Скорость можно тестировать например так:

# time sh -c «dd if=/dev/zero of=ddfile bs=1M count=5000»
# time sh -c «dd if=ddfile of=/dev/null bs=1M count=5000»

Результаты для моего RAID-6 из 5xWD 1Тб получились следующие: чтение 268МБ/сек, запись 37МБ/сек. Все разводят руками и говорят: ну а чего же вы хотели? RAID-6 тормозит при записи, ведь ему надо прочитать то что было записано раньше, чтобы посчитать обновленные контрольные суммы для всех дисков. А еще и этот bitmap…
Скорость перестройки массива – около 25МБ/сек – полная перестройка массива до 15 часов. Вот он, ваш ночной кошмар.

Решаются проблемы просто:

У драйвера рейда в Linux есть такой полезный параметр: stripe_cache_size, значение по умолчанию которого равно 256. Слишком низкое значение – резко снижает скорость записи (как оказалось). Оптимальное значение для многих – 8192. Это — кол-во блоков памяти на 1 диск. 1 блок это обычно 4kb (зависит от платформы), для 5-и дискового массива кеш займет 8192*4кб*5 = 160МБ.
```
# echo 8192 > /sys/block/md0/md/stripe_cache_size
```
Действовать начинает моментально. Теперь в большинстве случаев драйверу не приходится читать диск перед записью (особенно при линейной записи), и производительность резко вырастает. После перезагрузки пропадает, чтобы не пропало — добавляем в какой-нибуть /etc/rc.local например. Скорость перестройки массива теперь – 66МБ/сек (это сразу по всем дискам, около 5 часов на весь массив), скорость чтения осталась той-же, а вот скорость записи – выросла до 130МБ/сек (с 37).
Переносим bitmap на отдельный диск (в моём случае — системный). Если системный веник сдохнет — ничего страшного, массив восстановится и без bitmap-а. Головка больше не дергается при записи лишний раз, и скорость записи вырастает до 165МБ/сек.
```
# mdadm -G /dev/md0 -b /var/md0_intent
```

Итак, за 10 секунд мы подняли скорость записи с удручающих 37 МБ/сек до вполне приличных 165 МБ/сек (более чем в 4 раза!!). Теперь через Samba по сети файлы и пишутся и читаются 95-100 МБ/сек, и планировавшийся из-за низкой скорости рейда апгрейд сервера придется отложить на неопределенное время – производительности дохленького Opteron 165 теперь с лихвой хватает для всех поставленных задач.

linux, ubuntu, raid, raid-6