Первая часть трилогии о модернизации бекап-сервера. Итак, имеется сервер с системным диском sda и raid5 массивом md0 из 4 дисков sd[b-e] по 2ТБ каждый. ОС Gentoo. Ввиду того, что smartctl стал показывать не совсем удовлетворительное состояние дисков в сервере было принято решение заменить текущие харды на новые, по 4ТБ каждый. При этом задействовать все доступное пространство c сохранением всех данных в процессе перехода
Пост написан по «горячим следам». Информации будет много. Над каждой операцией рекомендуется думать, а не тупо копипастить
Замена дисков
Прежде, чем работать с массивом размонтируем его
df -h | grep md0
/dev/md0p1 5.5T 4.5T 720G 87% /backup
umount /backup
Проверим состояние массива
cat /proc/mdstat
md0 : active raid5 sde1[5] sdd1[4] sdc1[1] sdb1[2]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUUU]
Массив синхронизирован, все харды в работе
И какой диск менять?
Выделяется блок из 4 дисков sd[b-e]. Кто из них кто, непонятно. Справа на черном шлейфе системный sda
Чтобы с этим разобраться попросим smartctl показать серийные номера всех хардов. В качестве примера работаем с диском sde. С остальными все аналогично
smartctl --all /dev/sde | grep -i 'Serial'
Serial Number: Z293SBCG
Этот номер записали. Позже будем искать его на наклейке харда
Перед физической заменой програмно даем понять md0, что диск sde сбойный и его нужно удалить из массива
mdadm --manage /dev/md0 --fail /dev/sde1 --remove /dev/sde1
mdadm: set /dev/sde1 faulty in /dev/md0
mdadm: hot removed /dev/sde1 from /dev/md0
Если не пометить диск сбойным, а удалять сразу, то получим ошибку
mdadm: hot remove failed for /dev/sde: Device or resource busy
Смотрим, что осталось
cat /proc/mdstat
Отлично, sde в массиве нет! Выключаем сервер и ищем диск с серийным номером Z293SBCG и меняем его на новый
После запуска сервера копируем разметку со старого «живого» диска на свежеустановленный
sfdisk -d /dev/sdb | sfdisk /dev/sde
…
The size of this disk is 3.6 TiB (4000787030016 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT)
…
Created a new DOS disklabel with disk identifier 0xf90f6227.
/dev/sde1: Created a new partition 1 of type ‘Linux raid autodetect’ and of size 1.8 TiB.
/dev/sde2: Done.New situation:
Disklabel type: dos
Disk identifier: 0xf90f6227Device Boot Start End Sectors Size Id Type
/dev/sde1 2048 3907029167 3907027120 1.8T fd Linux raid autodetectThe partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Немного ругается на размер, но сейчас это неважно. Добавляем диск в массив
mdadm --manage /dev/md0 --add /dev/sde1
mdadm: added /dev/sde1
Это все. Наблюдаем за синхронизацией онлайн
watch 'cat /proc/mdstat'
Время синхронизации 4+ часов после каждой замены
После окончания синхронизации можно приступать к замене следующего диска
В результате инфа перенесена один-в-один с теми же размерами разделов, что и на старых хардах. Дополнительное пространство еще не доступно
Увеличение размера массива
После замены всех дисков и синхронизации (смотрим, что показывает cat /proc/mdstat) можно приступать к процедуре увеличения размера массива, что возможно если текущий RAID имеет тип 1, 4, 5, 6. Для этого необходимо будет выполнить несколько шагов, а именно:
- Удалить диск из массива, увеличить его размер и снова вернуть в массив. Дождаться окончания синхронизации. Эту операцию нужно проделать с каждым диском
- Увеличить размер md0, который кстати не в курсе, что у него диски с большим размером, ему об этом нужно сообщить
- Изменить размер раздела массива и файловой системы расширив их до максимума
Шаг #1. Удаление диска. Переход с MBR на GPT. Изменение размера диска
В ходе работ было видно, что со старых дисков, объем которых был 2ТБ перекочевала и старая схема разделов MBR. У такой схемы есть ограничения — 2ТБ на раздел. Новые диски по 4ТБ, следовательно нужна GPT
Удаляем диск из массива
mdadm --manage /dev/md0 --fail /dev/sde1 --remove /dev/sde1
Размер меняем при помощи parted. Для начала посмотрим, что он видит
parted /dev/sde print
Ключевое слово msdos
Сразу создаем новую схему разделов GPT
parted /dev/sde mklabel gpt
На вопрос
Warning: The existing disk label on /dev/sde will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No?
отвечаем ‘Y’. И пусть рука не дрогнет 🙂
Создаем раздел с меткой ‘backup’. Размер раздела — все доступное пространство
parted -s /dev/sde mkpart backup 1 100%
Смотрим на схему разделов
parted /dev/sde print
Ключевое слово gpt. Изменился размер раздела
и добавляем диск в массив
mdadm --manage /dev/md0 --add /dev/sde1
mdadm: re-added /dev/sde1
Может начаться синхронизация. Тогда нужно ждать. У меня кажется такого не было. На всякий случай смотрим, что покажет cat /proc/mdstat
С остальными дисками проделываем те же операции. Кому страшно, может сделать бекап. Бекап бекап-сервера звучит прикольно. Хотя я допускаю, что для кого-то это реалии
Шаг #2. Изменение размера md0
Еще раз убеждаемся, что все диски синхронизированы (опять cat /proc/mdstat. Да, эта команда популярна). Если так, то смотрим, что знает md0 о своем размере и размере диска к нему подлюченного
mdadm -D /dev/md0 | grep -e "Array Size" -e "Dev Size"
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Из этого ответа ясно, что для md0 до сего момента ничего не изменилось
Увеличим размер массива до максимума
mdadm --grow /dev/md0 -z max
mdadm: component size of /dev/md0 has been set to 3906885632K
И еще раз смотрим на размер массива и устройства
mdadm -D /dev/md0 | grep -e "Array Size" -e "Dev Size"
Array Size : 11720656896 (11177.69 GiB 12001.95 GB)
Used Dev Size : 3906885632 (3725.90 GiB 4000.65 GB)
Такс, уже другие цифры. Размер md0 увеличен. Проверяем
parted /dev/md0 print
Warning: Not all of the space available to /dev/md0 appears to be used, you can fix the GPT to use all of the space (an extra 11721019392 blocks) or continue with the current setting?
Fix/Ignore? Fix
Model: Linux Software RAID Array (md)
Disk /dev/md0: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:Number Start End Size File system Name Flags
1 1000kB 6001GB 6001GB ext4 backup
Команда попросила разрешения пофиксить, соглашаемся. Размер md0 изменился, размер раздела 1 остался прежний
Шаг #3. Увеличение размера раздела и файловой системы
Увеличиваем размер раздела (Number 1) до максимального
parted -s /dev/md0 resizepart 1 -1
Проверяем, что вышло
parted /dev/md0 print
Model: Linux Software RAID Array (md)
Disk /dev/md0: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:Number Start End Size File system Name Flags
1 1000kB 12.0TB 12.0TB ext4 backup
Размер раздела 1 стал больше, как и ожидалось
Проверяем состояние ФС на разделе. Это обязательно
e2fsck -f /dev/md0p1
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 55181323 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 55181337 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 55181364 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 55181383 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 55181398 extent tree (at level 2) could be narrower. Optimize<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
И последний шаг, увеличение размера ФС
resize2fs /dev/md0p1
Resizing the filesystem on /dev/md0p1 to 2930163735 (4k) blocks.
The filesystem on /dev/md0p1 is now 2930163735 (4k) blocks long.
Проверяем, что видят md0 и ОС
cat /proc/mdstat
md0 : active raid5 sdd1[5] sde1[4] sdb1[7] sdc1[6]
11720656896 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
mount /dev/md0p1 /backup/ df -h /backup
/dev/md0p1 11T 4.5T 5.9T 44% /backup
Отлично! Что и требовалось сделать
На следующем этапе работ предстоит заставить ОС увидеть raid-контроллер 3ware, после чего выполнить миграцию системы без LiveCD
P.S.
Практически на любом этапе была возможность примонтировать md0p1 и убедиться, что данные на месте
Все операции с parted выполнялись в командной строке. Само-собой, что их можно выполнить непосредственно в интерфейсе parted выбрав нужный диск
Вся эта работа выполнялась из чисто спортивного интереса. Можно было пойти тремя путями:
- вытащить старые харды, вставить новые, пересоздать массив и получить максимум пространства. После пересоздать структуру папок, куда складываются бекапы с других серверов и раздать им нужные права. Самый быстрый вариант по времени
- поменять харды последовательно, по-одному, как написано в первой части поста с последующим пересозданием массива, папок и прав. Тут нужно больше времени ибо синхронизация, которая длилась 4+ часов после каждой замены. Не очень отличается от п.1
- вставить дополнительно новый хард, переписать инфу на него (пришлось бы пожертвовать частью бекапов, все не поместилось бы), удалить старые харды, создать raid5 из 3 оставшихся новых, переписать инфу на вновь созданный md0 (у которого уже новый UUID) после чего добавить 4-й хард в массив и пережить синхронизацию
Первых два варианта предполагали потерю бекапов и надежды на то, что «сегодня» ничего не навернется и пользователи не попросят что-то восстановить. Третий вариант показался тривиальным. Кроме того хотелось сделать «все красиво». В результате бекапы не пострадали, админ приобрел опыт и написал полезный, как он думает пост
- Системный администратор с 2000 года
- Участник Хабр Q&A и cyberforum
- Кейсы
