Содержание
Задача
Есть ОС с корнем на разделе диска, и нужно перенести корень на программный 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=1 --raid-devices=2 missing /dev/sdb1
4. Далее создаем на массиве разделы под будущую систему. Создаем такие же разделы под корень и своп как на оригинальном диске3).
# fdisk /dev/md0 ....
5. Создаем файловые системы на разделах зеркала
# mkfs.ext4 /dev/md0p1 # mkswap /dev/md0p2
6. Монтируем будущий корень и копируем в него текущий корень
# mount /dev/md0p1 /mnt # rsync -axu / /mnt/
7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно - зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень.
# mount --bind /proc /mnt/proc # mount --bind /dev /mnt/dev # mount --bind /sys /mnt/sys # mount --bind /run /mnt/run # chroot /mnt
8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab. 4) По редактированию fstab лучше сверится с этой статьей.
#/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 - он найдет вторую систему установленную на раиде и включит ее свое меню.
Тут полезно еще раз запустить rsync, что бы он обновил данные на раиде тем, что успело изменится на реальном корне за время настройки раида 6). Но сделать это стоит перед перестройкой конфига GRUB, что бы его новый конфиг не был записан на раид.
#/exit --- выходим из chroot # rsync -axu / /mnt/ # update-grub # reboot
Если при перезагрузке что-то пошло не так и новая система на раиде не поднимается, то откат назад делается перегрузкой с первого диска - там у нас сохранилось все как было до начала процедуры.
13. Перегрузившись в новую систему остается только навесить в RAID первый диск и обновить на нем первую стадию груба.
# fdisk /dev/sda (там убиваем старые разделы и создаем один новый - на весь объем) # mdadm --manage /dev/md0 --add /dev/sda1 # grub-install /dev/sda
После чего сморим через cat /proc/mdstat как перестраивается наш деградированный массив в полноценно рабочий.
Результат: Система на раиде.
Проверка
Т.к. в процессе написания этой инструкции использовалась виртуалка то можно поиграть с потерей дисков.
Гасим виртуалку, отсоединяем первый диск, грузимся - норма (массив деградированный на втором диске, груб стартанул со второго диска). Снова гасим - подцепляем обнуленный второй диск, создаем на нем MBR, раздел, и добавляем его в массив (как выше добавлялся sda1) - система перестраивает массив и переходит в нормальный режим.
Повторяем то-же, но отключая и обнуляя второй диск - все работает.
ПРОФИТ!!
Комментарии:
№1: Если вы создадите массив на весь диск - то на диске может быть занят первый трек - и грубу некуда будет поставить свою первую стадию. А кроме того GRUB вообще не понимает? что на диске творится когда на нем расположен раидный раздел без MBR и не может встать туда. Другой (не совсем правильный) вариант - создавать на каждый раздел - свой массив. Идеологически - массив это диск, а не раздел, и если вы, имея массив, запустите fdisk -l то он вам на каждый RAID массив выдаст информацию именно как о диске и будет на каждом массиве искать таблицу разделов.
№2: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске), что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться, если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой.
ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне «уйдут» по времени от данных на раидном, и перезагрузка «отбросит» сервисы на сервере в момент времени, когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами 7)
Чуть улучшает состояние дел вызов rsync повторно перед пеезагрузкой (шаг 12). Но и он не может ничего гарантирововать.
