78

Mdadm RAID1: замена дисков на более емкие

Как-то встала задача увеличить объем зеркального массива на сервере с Debian без потери данных и без простоев. Простых и кратких инструкций в интернете нашел на тот момент не особо много, в основном на английском. Составил для себя на будущее свою, чем с вами и поделюсь сегодня. Может кому пригодится, всякое случается в практике сисадмина.

0. Посмотреть, какие диски каким именам в каталоге /dev соответствуют, и определиться, что будем менять:

lsscsi //простой список (годится, если все диски разных моделей)

lshw -class disk //подробно и с серийниками

1. Пометить каждый раздел RAID на первом заменяемом диске как извлеченный:

mdadm --manage /dev/mdX --fail /dev/sdYZ

mdadm --manage /dev/mdX --remove /dev/sdYZ

где X - номер массива, соответствующего диску

Y - буква заменяемого диска

Z - номер раздела RAID на этом диске, соответствующий массиву X

2. Заменить первый диск на новый.

3. Создать на новом диске разделы RAID, используя все свободное пространство кроме нескольких последних МБ. Пример:

parted -a optimal /dev/sdY

(parted) mklabel gpt //схема разметки GPT

(parted) mkpart primary 2048s 5999GB //создать раздел размером 5999 ГБ (не ГиБ!), начиная с 2048 сектора

(parted) set 1 raid on //пометить его тип как RAID

(parted) print //вывести список разделов диска для проверки

где Y - буква нового диска (внимание, не спутайте с другим, а то потеряете на нем данные!)

4. Добавить разделы нового диска в соответствующие массивы:

mdadm --manage /dev/mdX --add /dev/sdYZ

где X - номер массива

Y - буква нового диска

Z - номер раздела RAID на этом диске, соответствующий массиву X

5. Подождать окончания синхронизации. Проверка статуса:

cat /proc/mdstat

6. Повторить шаги 0-5 для второго заменяемого и второго нового дисков.

7. Увеличить соответствующие замененным дискам массивы:

mdadm --grow /dev/mdX --bitmap none

mdadm --grow /dev/mdX --size=max

{Подождать окончания синхронизации}

mdadm --grow /dev/mdX --bitmap internal

где X - номер массива

8. Увеличить файловые системы соответствующих из шага 7 массивов:

{остановить зависимые от массива сервисы}

umount /dev/mdX

fsck.ext4 -f /dev/mdX //проверка целостности ФС, для примера указан формат ext4

resize2fs /dev/mdX

mount /dev/mdX

{запустить сервисы}

где X - номер массива

Лига Сисадминов

2.7K поста19.2K подписчика

Правила сообщества

Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.

1
Автор поста оценил этот комментарий

работу не ищу я бы поступил так

установим диски

ну и для примера

mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

потом

mkfs.ext4 /dev/md0

потом

rsync -av /путь/к/исходным/данным /путь/к/новой/файловой/системе

rsync -av --delete /путь/к/исходным/данным /путь/к/новой/файловой/системе

sudo update-grub если потом надо грузиться с raid

как то так тапком не бить :)

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

В rsync думаю нужен еще ключ "х". С grub тоже не все просто, делаем отдельные boot разделы на дисках, через chroot ставим несколько экземпляров, чтобы иметь возможность загрузиться при замене харда.

1
Автор поста оценил этот комментарий

Делаешь degraded массив из трех дисков, потом добавляешь диск.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Это-то понятно. Массив сделаем, файлы скопируем. Главное то, что систему останавливать нельзя. Рискну предположить, что после копирования корневую директорию можно "перенести" через pivot_root. Дальше освободившийся диск добавим в массив, починим загрузку. С системой справиться можно, вопрос что делать с сервисами, ну например, если БД там и держит открытыми файл базы и журнала постоянно, соответственно

показать ответы
1
Автор поста оценил этот комментарий

Ну вот тут пишут о куче ssd и отсутствии норм контроллера для них. В конце концов, ребята, используют zfs:


https://habr.com/ru/companies/itsumma/articles/539012/


А лично мне, для моего зоопарка серверов проще иметь унифицированное решение. И да, кэш на запись для ssd, мне не нужен.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Зацепила фраза "эффективного аппаратного RAID для NVMe не существует" из статьи по ссылке

0
Автор поста оценил этот комментарий
исключительно быстр и надёжен… особенно если дисковый кэш не работает, а другого нет))) понятненько… окей) Мега продакшн тут не при чем. Какие у вас коллеги? Вы в какой-то параллельной реальности живете. Не встречал ни одного админа серьезного или руководителя ИТ, который доверяет инфраструктуру mdadm))) просто признайтесь, что вам не дают денег на нормальное серверное железо. Кстати, понятие «серверное железо» неразрывно с наличием аппаратных контроллеров, которые по умолчанию ставятся в 90% брендовых серверов и 60% платформ для самостоятельной сборки вроде intel или supermicro)) он быстр в вашем восприятии реальности до тех пор, пока вы не купите нормальный новый sas-nvme контроллер аппаратный с огромным кэшем в 4-8ГБ, но скорее всего не купите, денег не дадут, поэтому нечего переживать.))
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Беседа куда-то вообще ни туда свелась. Изначально пост был исключительно про программный рейд, в комментах вовсю строчат про преимущества аппаратных и пытаются даже как-то, не побоюсь этого слова, "унизить" mdadm. Выше же вы вообще предлагали на Али закупаться неизвестного качества контроллером, б/у, может даже с перекатанными чипами. Сейчас пишете про серьезных админов-руководителей, с которыми вот на мой взгляд очень плохо сочетается фраза "закупиться на Али". Уж лучше тогда mdadm, тот самый, который без кэша. Особенно в сегодняшнее непростое время, когда закупки стали дороже и сложнее, не всегда есть возможность на полную развернуться, как раньше. Разумеется дорогущий аппаратный с кэшем под 8 ГБ быстрее, как и Bugatti быстрее средней городской иномарки. Тут уже надо каждому для себя лично определиться - "мне этого достаточно под мою задачу" или "производительности впритык", и от этого плясать. Думаю, комментарии на Пикабу на такой выбор вряд ли окажут определяющее значение, если админ толковый сам по себе.

показать ответы
4
Автор поста оценил этот комментарий

Здравствуйте.

У меня в эксплуатации 5000 серверов.

Диски меняем каждый день. Меняем с увеличением объема не часто, но бывает и такое. Сервера от 2 до 72 дисков.

Инструкция глобально хорошая.

Замечания:

1. Отмонтировние избыточно. Не нужно это делать. В этом смысл такой замены - на ходу.

2. Проверки на шаге 0

ls -lah /dev/sd*

lsblk

smartctl -a /dev/sd?

3. Команды можно сократить

mdadm /dev/md? -f sd?

mdadm /dev/md? -r sd?

4. А ещё лучше диск на замену сдетачить перед заменой

echo 1 > /sys/block/sb?/device/delete

5. К шагам с

mdadm --grow /dev/mdX --bitmap none

Тоже вопросы. Непонятно зачем 3 шага, когда одного достаточно:

mdadm --grow /dev/mdX --size=max


Автор, если ты можешь работу в сфере эксплуатации - напиши мне. Тестовое задание: на живую, без остановки сервиса, сделать из однодисковой системы систему на raid10 на 4х дисках.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Спасибо за ценные замечания. Эти команды намеренно приведены несокращенными, так мне показалось читабельнее смотрится. Касательно п.5, включенный битмап иногда не дает увеличить массив, сообщая что-то вроде "Device/resource busy". Поэтому просто добавил три шага, чтобы не расписывать этот момент подробно в стиле "если..то..иначе". Вообще, сам я больше разработчик, серверы не моя основная работа, так совпало просто. Спасибо за предложение о работе, но пока занятость не дает возможности его рассмотреть.

0
Автор поста оценил этот комментарий
Когда это вендорские схд - там может быть что угодно в виде дисков. Задача вендора обеспечить совместимость )
но в целом, когда в одной схд несколько сотен дисков - что-то да отвалится ) возможно даже диск и живой, но контроллер решил, что пора )
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Касательно схд с сотнями дисков. Мне встречались айтишники, которые параметр MTBF у хардов толковали примерно как "о, миллион часов, отлично, на мой век хватит". Но на практике он говорит о том, как часто в среднем придется менять диски при их общей популяции столько-то штук

0
Автор поста оценил этот комментарий
resizefs можно можно на живую делать, не надо отмаунчивать раздел
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Наверно больше перестраховка.. мало ли, всякое бывает)

показать ответы
1
Автор поста оценил этот комментарий

Такой контроллер, имхо,  стоит использовать только если вы хотите raid 5 и выше. Или количество устройств для подключение очень большое.


В остальных же случаях mdraid достаточно быстр и надёжен.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Именно. Mdadm в большинстве случаев хватает за глаза. Имею опыт его использования с 2019 года в продакшене - еще не подводил.

показать ответы
0
Автор поста оценил этот комментарий

А еще лучше покупать на 1-2 резервных контролеров, чтобы в случае сбоя быстро поменять, а потом не спеша перенести на современное жалезо.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

С текущими ценами на серверное железо это стало несколько сложнее)

1
Автор поста оценил этот комментарий

Ну прямо совсем чтобы без прерывания - лучше бы сразу иметь lvm. Оно сразу все упрощает

А так - rsync, потом остановка сервиса, снова rsync и перезагрузка на новую систему, наверное. Интересный вопрос.


@bugdebug, lvm там есть, или совсем прошлый век по условиям задачи?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Если в условиях нет, то наверно и нет. Первым делом тоже про LVM подумал. А перезагрузки по условиям задачи точно нет (нельзя). Вообще, задача сложная так-то. Интересно было бы услышать полное решение в целях общего развития)

0
Автор поста оценил этот комментарий

Да, меня устраивает. Особенно после появления ssd, mdraid исключительно быстр и надёжен (диски всё-таки серверные нужны).


Хотя коллеги все больше на zfs переходят.


Может быть в каком-нибудь мега продакшене контроллеры по-прежнему востребованы, но я склоняюсь к обратному мнению.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Думаю каждой задаче/потребности свое решение. Перешел на mdadm как раз из-за SSD - программный массив оказался быстрее старенького аппаратного контроллера, так оказалось проще и в итоге выигрышнее в моем случае) А так с тем же LSI еще со времен "сказевого" Ultra320 знаком. Хорошая штука, не помню чтоб были какие-то сложности с ним. Пара винтов сего стандарта с 2008 и до сих пор шуршит, разве что задача того сервера сильно поменялась.

показать ответы
Автор поста оценил этот комментарий
Я вам скажу, что программный райд это очень даже продакшн решение. Кучу всего в мире было собрано на веритасе и работает даже сейчас.
Были даже решения, когда пару аппаратных массивов собирали в программные райды.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Тот же mdadm свою историю ведет с 2001 года - за это время программу отполировали до идеала. Так что да. Да и средствами Windows Server бывало приходилось собирать массивы - вполне себе работает. Ничего пока не развалилось)

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества