Это старая версия документа.
Содержание
Задача
Есть ОС с корнем на разделе диска, и нужно перенести корень на программный RAID, при этом процесс переноса нужно сократить максимально во времени. Допустим это у нас сервер и его даже перегрузить - сложность. В наличии один диск на котором раздел с корнем, и второй диск эквивалентного(или большего) объема - пустой.
Условия
На оригинальном диске расположен корень и своп, новый диск чист. Мы будем делать программный RAID1. Используется Ubuntu Server 11.10
Порядок действий
Порядок действий достаточно важен, и выработан в процессе нескольких попыток решить эту задачу с использованием виртуальной машины.
1. Подключаем второй диск к компьютеру. 1)
2. Форматируем новый диск 2) -
# fdisk /dev/sdb n p 1 <enter> <enter> w
3. Создаем на нем массив:
# mdadm --create /dev/md0 --level=2 --raid-devices=2 missing /dev/sdb1
4. Далее создаем на массиве разделы под будущую систему. Создаем такие же разделы под корень и своп как на оригинальном диске3).
# fdisk /dev/md0 ....
5. Создаем файловые системы на разделах зеркала
# mkfs.ext4 /dev/md0p1 # mkswap /dev/md0p2
6. Монтируем будущий корень и копируем в него текущий корень
# mount /dev/md0p1 /mnt # cp -dpRx
7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно - зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень.
# mount --bind /proc /mnt/proc # mount --bind /dev /mnt/dev # mount --bind /sys /mnt/sys # chroot /mnt
8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab 4)
#/ls -l /dev/disk/by-uuid |grep md >> /etc/fstab #/nano /etc/fstab (там комментируем старые корень и своп и используя скопированные туда uuid-ы прописываем новый корень и своп по образу и подобию старых, но с uuid-ами раидных разделов)
9. Создаем новую конфигурацию GRUB и проверяем, что в его конфиг прописан раидный uuid для корня.
#/update-grub #/cat /boot/grub/grub.cfg
10. Ставим первую стадию GRUB на второй диск (который несет на себе часть зеркала).
#/grub-install /dev/sdb
11. Очень важный шаг! Нужно прописать (хотя бы на время) конфигурацию mdadm, которая позволит загрузится с деградированного массива (а у нас пока он именно такой)
#/dpkg-reconfigure mdadm (там со всем соглашаемся, включаяя последний шаг, где спрашивают - позволять ли грузится системе на деградированном массиве)
12. Можно перегружаться и выбрать в BIOS загрузочным второй диск5), или можно вернутся в реальную систему и обновить GRUB - он найдет вторую систему установленную на раиде и включит ее свое меню.
#/exit --- выходим из chroot # update-grub # reboot
Если при перезагрузке что-то пошло не так и новая система на раиде не поднимается, то откат назад делается перегрузкой с первого диска - там у нас сохранилось все как было до начала процедуры.
13. Перегрузившись в новую систему остается только навесить в RAID первый диск и обновить на нем первую стадию груба.
# fdisk /dev/sda (там убиваем старые разделы и создаем один новый - на весь объем) # mdadm --manage /dev/md0 --add /dev/sda1 # grub-install /dev/sda1
После чего сморим через cat /proc/mdstat как перестраивается наш деградированный массив в полноценно рабочий.
Результат: Система на раиде.
Проверка
Т.к. в процессе написания этой инструкции использовалась виртуалка то можно поиграть с потерей дисков.
Гасим виртуалку, отсоединяем первый диск, грузимся - норма (массив деградированный на втором диске, груб стартанул со второго диска). Снова гасим - подцепляем обнуленный второй диск, создаем на нем MBR, раздел, и добавляем его в массив (как выше добавлялся sda1) - система перестраивает массив и переходит в нормальный режим.
Повторяем то-же, но отключая и обнуляя второй диск - все работает.
ПРОФИТ!!
Комментарии:
№1: Если вы создадите массив на весь диск - то на диске может быть занят первый трек - и грубу некуда будет поставить свою первую стадию. А кроме того GRUB вообще не понимает? что на диске творится когда на нем расположен раидный раздел без MBR и не может встать туда. Другой (не совсем правильный) вариант - создавать на каждый раздел - свой массив. Идеологически - массив это диск, а не раздел, и если вы, имея массив, запустите fdisk -l то он вам на каждый RAID массив выдаст информацию именно как о диске и будет на каждом массиве искать таблицу разделов.
№2: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске), что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться, если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой.
ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне «уйдут» по времени от данных на раидном, и перезагрузка «отбросит» сервисы на сервере в момент времени, когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами 6)