После очередного выхода из строя очередного винта назрела таки
необходимость внедрения raid-ов. Так как на что-то вроде raid5 или
raid10 винтов надо "много" (ну хотя бы 4), а обьемов существующих для
моих нужд вполне достаточно решил для начала поэкспериментировать с
raid1. Хотя на материнке и присутствует raid контроллер, но фраза в
мануале "если вы хотите установить ОС используя raid - скопируйте
драйвер на флопи диск..." напрочь отбивает охоту оный использовать.
После поиска возможных вариантов миграции на софтовый raid для linux и
анализа был выбран (помоемому) самый простой способ, правда требующий
физического доступа к серверу, установочного/восстановительного диска и
парочки перезагрузок сервера.
Большинство "рецептов" (например http://www.howtoforge.com/software-raid1-grub-boot-fedora-8)
описывает переход на raid "пораздельно" - т.е. Второй диск разбивается точно также
как и первый, затем одинаковые разделы обьединяются в raid массив.
Но, как оказалось, mdadm начиная с 2.6 поддерживает обьединение в raid
уже целяком всего устройства! Без необходимости предварительного
разбиения, переносов и т.д.
Был обнаружен довольно короткий документ http://wiki.centos.org/HowTos/Install_On_Partitionable_RAID1
Дальнейшее изложение полностью основывается на этом документе.
Изменена последовательность действий и добавлено пару-тройку замечаний.
Процесс переноса:
Подготовка:
Нам потребуется установочный диск, т.к. переносилась CentOS5.3 - её диск
и был взят.
Для размещения служебной информации mdadm требуется немножко
неразмеченого места на диске, а диск при установке был задействован
полностью. По старой привычке /home, /var/log и /tmp были созданы
отдельными разделами причем /tmp - последний; посему сильно не
заморачиваясь раздел /tmp был попросту ликвидирован (позже на raid-е
создан заново).
Проверяем, что установлены mdadm версии не ниже 2.6
rpm -q mdadm
mdadm-2.6.4-1.el5
Теперь выясняем что собственно у нас куда примонтировано:
в /etc/fstab лично у меня было:
LABEL=/1 / ext3 defaults 1 1
и т.д.
Какое устройство соответствует этой метке обнаружилось в файлике /etc/blkid/blkid.tab
LABEL=/1 это оказалось /dev/sda2
Это надо для дальнейшей правки /etc/fstab - разделы у нас поменяются.
затем нам потребуется патч для mkinitrd качаем его
(зачем он нужен желающие могут выяснить здесь) и сохраняем
где-нибудь, например в /root (т.к. /root у меня расположен в корневом
разделе - он будет легко доступен)
Впринципе ничто не мешает сразу пропатчить mkinitrd
cd /sbin
cp mkinitrd mkinitrd.dist
patch -p0 < /root/mkinitrd-md_d0.patch
Если пакет mkinitrd будет обновлен (например через yum update) то
патчить придется заново, а если про это забыть - то при обновлении ядра
новый mkinitrd создаст неправильный initrd и наш сервер попросту не
загрузиться.
Соответственно правим /etc/yum.conf - добавляем строку
exclude=mkinitrd*
Основная фаза:
Выключаем сервер, добавляем второй жесткий диск, загружеамся с
устновочного CD (DVD, Flash) диска в варианте Rescue (Восстановление),
на вопрос примонтировать ли найднные разделы на жестком диске отвечаем "нет".
Создаем raid используя mdadm:
Теперь необходимо изменить параметры загрузки, для чего монтируем
вручную наш жесткий диск, который собственно уже является частью raid
массива:
mkdir /mnt/sysimage
mount /dev/md_d0p2 /mnt/sysimage
mount -o bind /dev /mnt/sysimage/dev
mount -o bind /selinux /mnt/sysimage/selinux
mount -t proc none /mnt/sysimage/proc
mount -t sysfs none /mnt/sysimage/sys
chroot /mnt/sysimage
Замечание: "mount /dev/md_d0p2 /mnt/sysimage" т.к. у меня корень был в
/dev/sda2 !!! позже при переносе на другом серваке обнаружилось, что по
каким-то причинам корень [/] был в /dev/hda6, так вот - устройство
/dev/md_d0p6 небыло создано при создании raid-а, т.к. железка старая и
всеравно скоро будет меняться - оставили ее пока впокое.
Создаем /etc/mdadm.conf
mdadm --examine --scan > /etc/mdadm.conf
И редактируем его (/etc/mdadm.conf): необходимо заменить /dev/md0 на /dev/md_d0.
Правим /etc/fstab - меняем параметры типа LABEL=.... на
root=/dev/md_d0pN где N - соответствует /dev/sdaN на котором был этот раздел.
И создаем новый образ initrd
cd /boot
mv initrd-2.6.18-128.el5.img initrd-2.6.18-128.el5.img.bak
mkinitrd /boot/initrd-2.6.18-128.el5.img 2.6.18-128.el5
Перезагружаемся уже в нормальном режиме.
Если все прошло успешно - последний штрих, синхронизация дисков, хотя
сервер уже выполняет свои функции.
Добавляем второй диск в массив
mdadm --add /dev/md_d0 /dev/sdb
Можем последить за процессом синхронизации
watch cat /proc/mdstat
Синхронизация - процесс довольно долгий и сильно тормозящий весь
сервер. Что логично - винчестеры оба задействованы "на полную".
Весь процесс от остановки сервера для перезагрузки до запуска занял
примерно 15 минут (не считая времени на подготовку и синхронизацию, т.к.
в это время сервер хоть и тормозил, но всетаки работал).
Раздел /tmp позже был создан уже сразу на /dev/md_d0 и неиспользуемого
места на массиве больше не осталось :)
При эмуляции отказа - удалили диск sda, бывший sdb обнаружился как sda и
все нормально загрузилось и работало, НО когда sda (отформатированый
ради чистоты эксперимента) вернули наместо - сервак не завелся!
Все оказалось банально просто - в рейде остался один диск - sda который
стал sdb после возвращения sda наместо, проблема решилась просто -
переткнули диски наоборот, вроде мелочь, но нервы попортить может :)
Преимущества:
1.Нет необходимости при замене жесткого диска разбивать его на разделы,
и колдовать с загрузчиком.
2.Процесс восстановления состоит из одной единственной команды -
добавления нового диска взамен вышедшего из строя.
Недостатки:
1. swap тоже получается на raid-е, хотя если бы делали на нормальном raid
контроллере помоемому получили бы тотже эффект.
2. Надо патчить mkinitrd, вроде как патч будет включен и необходимость в
этом отпадет.
3. Пока неясно как это все проделать на удаленной машине, но впринципе это возможно.
Vova
