The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: 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. Пока неясно как это все проделать на удаленной машине, но впринципе это возможно.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.2, olex (ok), 11:52, 16/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    для того чтобы сервак грузился и с /dev/sda и с /dev/sdb нужно загрузчик установить на оба диска и в BIOS прописать порядок загрузки HDD0->HDD1->...

    статья рабочая - но без возможности перезагрузки и работи после вихода из строя одного HDD (sda) - в топку

    ситуация на нормально настроенном сервере
    1 вышел из строя sda
    2 с помощью mdadm удаляем его из raid
    3 если успользуется SATA диск (а на большинстве серверов так оно у есть) меняем sda на новый дыск
    4 добавляем новый диск в raid
    5 ждем пока засинхронизируется
    6 reboot

    имеем downtime сервера до 5 минут

    PS я специально не указывал команды mdadm и sfdisk(если у вас в рейде были не диски а разделы) чтобы не усложнять

    PPS для перевода сервака на raid - перегружаться с установочного/восстановительного CD не обязательно.

     
     
  • 2.4, std (?), 12:18, 16/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем "6 reboot"?
     

  • 1.3, olex (ok), 11:57, 16/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    swap все таки лучше делать отдельным разделом на каждом диске - тогда:
    1 размер swap на каждом диске можно сделать вдвое меньше
    2 swap не будет грузить raid
    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 сервер - а несколько серверов работающих совместно и в данном случае важнее быстродействие каждого сервера нежели его отказоустойчивость изза отсутствия одного из свопов.

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

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

     

  • 1.5, fantom (??), 12:50, 16/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "для того чтобы сервак грузился и с /dev/sda и с /dev/sdb нужно загрузчик установить на оба диска и в BIOS прописать порядок загрузки HDD0->HDD1->..."

    Проверено на живой системе, НИКАКИХ телодвижений с BIOS и загрузчиком НЕ ПОТРЕБОВАЛОСЬ, ВООБЧЕ!
    Этот метод и был выбран именно из соображений отсутствия телодвижений в сторону загрузчика.

     
  • 1.7, NicK (?), 09:40, 17/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >"для того чтобы сервак грузился и с /dev/sda и
    >с /dev/sdb нужно загрузчик установить на оба диска

    Подтверждаю. Сам недавно с этим столкнулся. ОС  CentOS 5.3.

     
  • 1.10, Andrey (??), 13:25, 17/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Фигня какая то получается(((
    Вот все это получается:
    И создаем новый образ 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


    Перезагружаемся уже в нормальном режиме.

    Но вот после перезагрузки идет проверка ФС /dev/md0 Все вроде бы проходит...
    Идет проверка /dev/md1 И тут стопориться говориться про суперблоки и ФС ext2???

    Пробовал возвращать систему убивая райд полностью...
    Система грузится. Гружусь в рескуе моде и делаю уже по разделам райд... (/dev/hda1 (md0-/boot) /dev/hda3 (md1-/корень))
    И вот тут я заметил интересную при выполнении
    mdadm --create --level=1 --raid-devices=2 /dev/md_d0 /dev/sda missing
    Меня спрашивают создать ФС ext2fs??? И вот после этого начинаются проблеммы...
    Стоит только fdisk /dev/hda поставить ФС 83. Все ОК!!! Ну и ясень пень грохнут все разделы на /dev/hdb...

     
     
  • 2.11, eugene (??), 17:47, 03/11/2009 [^] [^^] [^^^] [ответить]  
  • +/
    не работает

    1. не создаются разделы больше 4 md_d0p4 будет последний
       причем fdisk -l видит все md разделы
       приходиться создавать через mknod (mknod /dev/md_d0p5 b 254 5)

    2. затем mdadm --examine --scan > /etc/mdadm.conf
       пишет какую то ересь о несуществующих устройсвах

     

  • 1.12, fantom (??), 10:44, 17/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1. не создаются разделы больше 4 md_d0p4 будет последний
    - это я тоже уже обнаружил, но т.к. у меня на момент эксперимента больше и небыло - то не описал.

    2. затем mdadm --examine --scan > /etc/mdadm.conf
       пишет какую то ересь о несуществующих устройсвах

    Создайте сначала 4, а потом добавте все уже руками прямо в fstab.

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

     
  • 1.13, beza2000 (?), 14:49, 14/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    При просмотре/реализации статьи и сравнении с первоисточником обнаружил, что из п.п.8 и 9 получилось "Правим /etc/fstab - меняем параметры типа LABEL=.... на
    root=/dev/md_d0pN где N - соответствует /dev/sdaN на котором был этот раздел." --- что не совсем верно
     

    игнорирование участников | лог модерирования

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру