OpenNET: статья - Перенос существующей CentOS на софтовый RAID1 (linux centos raid)

Ключевые слова: linux, centos, raid, (найти похожие документы)
From: fantom <tolik@dataxp.net.> Newsgroups: email Date: Mon, 15 Jul 2009 14:31:37 +0000 (UTC) Subject: Перенос существующей CentOS на софтовый RAID1 Предистория. После очередного выхода из строя очередного винта назрела таки необходимость внедрения 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: mdadm --create --level=1 --raid-devices=2 /dev/md_d0 /dev/sda missing Теперь необходимо изменить параметры загрузки, для чего монтируем вручную наш жесткий диск, который собственно уже является частью 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. Пока неясно как это все проделать на удаленной машине, но впринципе это возможно.

2.6, fantom (??), 12:53, 16/07/2009 [^] [^^] [^^^] [ответить]	+/–
raid создавался НЕ из разделов, а из девайсов, т.е. дисков как устройств. Кроме того если swap не размещать на raid то при выходе из строя одного из винтов высока вероятность нарушения работы сервака - ось то будет пытаться пользовать оба свапа, а в наличии только один, что потребует дополнительных движений - отключения несуществующего свапа.

2.8, Аноним (-), 00:20, 27/08/2009 [^] [^^] [^^^] [ответить]

+/–

Своп - это память, но вынесенная на диск. В любой момент она может быть с диска подгружена назад в ОЗУ. Что будет с системой, если диск отказал, а нужные страницы памяти оказались именно на этом сбойном диске? Правильно! Часть приложений может непредсказуемо покриветь. Эффект как будто в части ОЗУ кусок памяти засеяли мусором или просто вырезали. В лучшем случае будет kernel-panic с руганью на то, что нет доступа к такой-то странице памяти, в худшем случае будет потеря данных.
При любых раскладах, разместив своп-разделы вне RAID, вы будете сами себе злобный буратина. Ваш третий пункт не выполнится никогда, потому что система не просто "имеет своп", она его использует как для чтения, так и для записи, а не только для записи по принципу "чтобы было". Когда часть свопа пропадет из-за отказа диска, то сервер всенепременно встанет и "иметь" будут известно кого и известно за что.

Если у вас система постоянно лезет в своп и вас беспокоит его размер, то сообщаю, что гиг ОЗУ стоит 1.5 тыс. рублей, а винт на 160 Гиг порядка 2 тыс. рублей. Не бог весть какие деньги, надо сказать.

Используйте RAID для хранения всех данных, хранящихся на диске. Только это гарантирует работу сервера в случае отказа одного из элементов RAID-массива.

3.9, olex (ok), 11:44, 27/08/2009 [^] [^^] [^^^] [ответить]

+/–

Если система успользует своп - значит в системе реально мало RAM или система перегружена или система неправильно настроена.

Если делается нормальный отказоустойчивый сервис - там будет не 1 сервер - а несколько серверов работающих совместно и в данном случае важнее быстродействие каждого сервера нежели его отказоустойчивость изза отсутствия одного из свопов.

Еслы разместить своп на рейде - работа со свопом еще более затормозыт и без того занятый сервер.

Причем будет тормозить весь рейд со всеми разделами и соответственно всеми файловыми системами на сервере.