HOW-TO: Перевод системного раздела на RAID. Сравнение версий

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
wiki:migrate-to-raid [2012/02/14 11:52]
Sly_tom_catSly_tom_catSly_tom_catXubuntu 18.04 (64bit)Don't worry, be happy! [Ссылки]
wiki:migrate-to-raid [2012/03/23 14:26] (текущий)
Sly_tom_catSly_tom_catSly_tom_catXubuntu 18.04 (64bit)Don't worry, be happy! [Ссылки]
Строка 1: Строка 1:
-====== HOW-TO:​Перевод системного раздела на RAID. ====== +====== HOW-TO: Перевод системного раздела на RAID. ====== 
 +<note warning>​ВНИМАНИЕ!!!! Предложенное вашему вниманию руководство - все-го лишь инструкция как решить одну конкретную задачу (описанную в начале документа). Если ваша задача хоть чуточку отличается от постановки,​ то пользуйтесь этой инструкцией не бездумно копируя команды,​ а адаптируя их под свои реалии. </​note>​ 
 +<note warning>​Будьте осторожны,​ в этой инструкции вы работаете с системным разделом и ошибки могут привести к полному краху системы. Обязательно сделайте бекап системы прежде чем приступать к подобным действиям. А кроме того, крайне рекомендуется протестировать ваши манипуляции сначала на виртуальной машине,​ а уже выработав свой вариант точных инструкций и команд,​ приступать к конвертации системного раздела вашей реальной системы.</​note>​
 ====== Задача ====== ====== Задача ======
 Есть ОС с корнем на разделе диска, и нужно перенести корень на программный RAID, при этом процесс переноса нужно сократить максимально во времени. Допустим это у нас сервер и его даже перегрузить - сложность. В наличии один диск на котором раздел с корнем,​ и второй диск эквивалентного(или большего) объема - пустой. ​ Есть ОС с корнем на разделе диска, и нужно перенести корень на программный RAID, при этом процесс переноса нужно сократить максимально во времени. Допустим это у нас сервер и его даже перегрузить - сложность. В наличии один диск на котором раздел с корнем,​ и второй диск эквивалентного(или большего) объема - пустой. ​
Строка 22: Строка 23:
 3. Создаем на нем массив:​ 3. Создаем на нем массив:​
 <​code>​ <​code>​
-# mdadm --create /dev/md0 --level=--raid-devices=2 missing /​dev/​sdb1 ​+# mdadm --create /dev/md0 --level=--raid-devices=2 missing /​dev/​sdb1 ​
 </​code>​ </​code>​
 <note tip> <note tip>
Строка 39: Строка 40:
 <​code>​ <​code>​
 # mount /dev/md0p1 /mnt # mount /dev/md0p1 /mnt
-cp -dpRx +rsync -axu / /mnt/
 </​code>​ </​code>​
 7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно - зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень. 7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно - зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень.
Строка 46: Строка 47:
 # mount --bind /dev /mnt/dev # mount --bind /dev /mnt/dev
 # mount --bind /sys /mnt/sys # mount --bind /sys /mnt/sys
 +# mount --bind /run /mnt/run
 # chroot /mnt # chroot /mnt
 </​code>​ </​code>​
Строка 51: Строка 53:
 <note tip>​Вот мы  в будущем окружении (с корнем на раиде),​ но пока в нем только копия оригинального корня. Приступим...</​note>​ <note tip>​Вот мы  в будущем окружении (с корнем на раиде),​ но пока в нем только копия оригинального корня. Приступим...</​note>​
  
-8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab ((автору было лень мудрить с оснасткой на виртуальном сервере и он просто дописал вывод ls в fstab, а потом отредактировал его.))+8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab((Автору было лень мудрить с оснасткой на виртуальном сервере и он просто дописал вывод ls в fstab, а потом отредактировал его.)) ​По редактированию fstab лучше сверится с этой [[wiki:​fstab|статьей]].
 <​code>​ <​code>​
 #/ls -l /​dev/​disk/​by-uuid |grep md >> /etc/fstab #/ls -l /​dev/​disk/​by-uuid |grep md >> /etc/fstab
Строка 74: Строка 76:
 <note tip>Ну собственно и все - система на раиде готова.</​note>​ <note tip>Ну собственно и все - система на раиде готова.</​note>​
  
-12. Можно перегружаться и выбрать в BIOS загрузочным второй диск((Если на время настройки второй диск стоял в USB коробке,​ то во время единственной перегрузки его можно перевесить на нормальный интерфейс нашего сервера)),​ или можно вернутся в реальную систему и обновить GRUB - он найдет вторую систему установленную на раиде и включит ее свое меню.+12. Можно перегружаться и выбрать в BIOS загрузочным второй диск((Если на время настройки второй диск стоял в USB коробке,​ то во время единственной перегрузки его можно перевесить на нормальный интерфейс нашего сервера)),​ или можно вернутся в реальную систему и обновить GRUB - он найдет вторую систему установленную на раиде и включит ее свое меню. \\ 
 +Тут полезно еще раз запустить rsync, что бы он обновил данные на раиде тем, что успело изменится на реальном корне за время настройки раида ((опция u не даст затереть более новые конфиги mdadm и initrd на раиде)). Но сделать это стоит перед перестройкой конфига GRUB, что бы его новый конфиг не был записан на раид.
 <​code>​ <​code>​
 #/​exit ​ --- выходим из chroot #/​exit ​ --- выходим из chroot
 +# rsync -axu / /mnt/
 # update-grub # update-grub
 # reboot # reboot
Строка 88: Строка 92:
 (там убиваем старые разделы и создаем один новый - на весь объем) (там убиваем старые разделы и создаем один новый - на весь объем)
 # mdadm --manage /dev/md0 --add /dev/sda1 # mdadm --manage /dev/md0 --add /dev/sda1
-# grub-install /dev/sda1+# grub-install /dev/sda
 </​code>​ </​code>​
 После чего сморим через cat /​proc/​mdstat как перестраивается наш деградированный массив в полноценно рабочий. После чего сморим через cat /​proc/​mdstat как перестраивается наш деградированный массив в полноценно рабочий.
Строка 107: Строка 111:
 **№2**: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске),​ что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться,​ если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой. **№2**: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске),​ что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться,​ если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой.
  
-**ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ**:​ Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло,​ ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне "​уйдут"​ по времени от данных на раидном,​ и перезагрузка "​отбросит"​ сервисы на сервере в момент времени,​ когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты?​ Либо корень системы копировать,​ а данные приложений переносить другими средствами ((Например для базы данных можно сделать реплику на раидном диске, и тогда сервис будет недоступен только на время перезагрузки,​ но важно настроить реплику так, что бы она нормально поднялась на новом корне, при недоступной той части, которая останется на оригинальном разделе,​ который при перезагрузке в "​раидную систему"​ просто не будет смонтирован... Хотя и это можно предусмотреть,​ если старый раздел с данными монтировать на место где во время настройки был смонтирован раидный раздел с данными во время настройки))+**ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ**:​ Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло,​ ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне "​уйдут"​ по времени от данных на раидном,​ и перезагрузка "​отбросит"​ сервисы на сервере в момент времени,​ когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты?​ Либо корень системы копировать,​ а данные приложений переносить другими средствами ((Например для базы данных можно сделать реплику на раидном диске, и тогда сервис будет недоступен только на время перезагрузки,​ но важно настроить реплику так, что бы она нормально поднялась на новом корне, при недоступной той части, которая останется на оригинальном разделе,​ который при перезагрузке в "​раидную систему"​ просто не будет смонтирован... Хотя и это можно предусмотреть,​ если старый раздел с данными монтировать на место где во время настройки был смонтирован раидный раздел с данными во время настройки))\\ 
 +Чуть улучшает состояние дел вызов rsync повторно перед пеезагрузкой (шаг 12). Но и он не может ничего гарантирововать.
 ====== Важные примечания ====== ====== Важные примечания ======
  
 <note important>​update-grub берет данные о корне (откуда грузить ядро и initrd) из fstab и совершенно замечателно составляет конфиг для загрузки с раидного кроня (или /​boot).</​note>​ <note important>​update-grub берет данные о корне (откуда грузить ядро и initrd) из fstab и совершенно замечателно составляет конфиг для загрузки с раидного кроня (или /​boot).</​note>​
-<note important>​mdadm совсем не критичен к типам разделов которые он подцепляет в RAID. Но, для красоты решения, можно ​поменять их тип на тип FD (Linux raid auto), что бы они корректно показывались в дисковых утилитах.</​note>​+<note important>​mdadm совсем не критичен к типам разделов которые он подцепляет в RAID. Но, правильным будет поменять их тип на тип FD (Linux raid auto), что бы они корректно показывались в дисковых утилитах.</​note>​
 <note important>​По этой процедуре можно сделать и другие версии RAID, важно только что бы загрузчик умел грузится с такого типа RAID что вы делаете.</​note>​ <note important>​По этой процедуре можно сделать и другие версии RAID, важно только что бы загрузчик умел грузится с такого типа RAID что вы делаете.</​note>​
 <note important>​При наличии полного комплекта новых дисков для RAID массива помимо существующего в системе,​ процедуру можно проделать с созданием полноценного массива (не деградированного),​ а оставшийся после переноса диск повесить в массив как горячий резерв.</​note>​ <note important>​При наличии полного комплекта новых дисков для RAID массива помимо существующего в системе,​ процедуру можно проделать с созданием полноценного массива (не деградированного),​ а оставшийся после переноса диск повесить в массив как горячий резерв.</​note>​
Строка 119: Строка 124:
 [[http://​www.howtoforge.com/​software-raid1-grub-boot-debian-etch|Дебаиновская инструкция для GRUB Legacy]] [[http://​www.howtoforge.com/​software-raid1-grub-boot-debian-etch|Дебаиновская инструкция для GRUB Legacy]]
  
-{{tag> HOWTO Администрирование Server }}+{{tag> HOWTO Администрирование Server ​RAID}}