Различия

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

--- wiki:migrate-to-raid [2012/02/15 19:30]
[HOW-TO:Перевод системного раздела на RAID.]
+++ wiki:migrate-to-raid [2012/03/23 14:26] (текущий)
[Ссылки]
@@ Строка 1: / Строка 1: @@
-====== HOW-TO:Перевод системного раздела на RAID. ======
+====== HOW-TO: Перевод системного раздела на RAID. ======
 <note warning>ВНИМАНИЕ!!!! Предложенное вашему вниманию руководство - все-го лишь инструкция как решить одну конкретную задачу (описанную в начале документа). Если ваша задача хоть чуточку отличается от постановки, то пользуйтесь этой инструкцией не бездумно копируя команды, а адаптируя их под свои реалии. </note>
 <note warning>Будьте осторожны, в этой инструкции вы работаете с системным разделом и ошибки могут привести к полному краху системы. Обязательно сделайте бекап системы прежде чем приступать к подобным действиям. А кроме того, крайне рекомендуется протестировать ваши манипуляции сначала на виртуальной машине, а уже выработав свой вариант точных инструкций и команд, приступать к конвертации системного раздела вашей реальной системы.</note>
@@ Строка 53: / Строка 53: @@
 <note tip>Вот мы  в будущем окружении (с корнем на раиде), но пока в нем только копия оригинального корня. Приступим...</note>
-. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab ((автору было лень мудрить с оснасткой на виртуальном сервере и он просто дописал вывод ls в fstab, а потом отредактировал его.))
+. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab. ((Автору было лень мудрить с оснасткой на виртуальном сервере и он просто дописал вывод ls в fstab, а потом отредактировал его.)) По редактированию fstab лучше сверится с этой [[wiki:fstab|статьей]].
 <code>
 #/ls -l /dev/disk/by-uuid |grep md >> /etc/fstab
@@ Строка 111: / Строка 111: @@
 **№2**: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске), что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться, если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой.
-**ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ**: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне "уйдут" по времени от данных на раидном, и перезагрузка "отбросит" сервисы на сервере в момент времени, когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами ((Например для базы данных можно сделать реплику на раидном диске, и тогда сервис будет недоступен только на время перезагрузки, но важно настроить реплику так, что бы она нормально поднялась на новом корне, при недоступной той части, которая останется на оригинальном разделе, который при перезагрузке в "раидную систему" просто не будет смонтирован... Хотя и это можно предусмотреть, если старый раздел с данными монтировать на место где во время настройки был смонтирован раидный раздел с данными во время настройки))
+**ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ**: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне "уйдут" по времени от данных на раидном, и перезагрузка "отбросит" сервисы на сервере в момент времени, когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами ((Например для базы данных можно сделать реплику на раидном диске, и тогда сервис будет недоступен только на время перезагрузки, но важно настроить реплику так, что бы она нормально поднялась на новом корне, при недоступной той части, которая останется на оригинальном разделе, который при перезагрузке в "раидную систему" просто не будет смонтирован... Хотя и это можно предусмотреть, если старый раздел с данными монтировать на место где во время настройки был смонтирован раидный раздел с данными во время настройки))\\
+Чуть улучшает состояние дел вызов rsync повторно перед пеезагрузкой (шаг 12). Но и он не может ничего гарантирововать.
 ====== Важные примечания ======
 <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 массива помимо существующего в системе, процедуру можно проделать с созданием полноценного массива (не деградированного), а оставшийся после переноса диск повесить в массив как горячий резерв.</note>
@@ Строка 123: / Строка 124: @@
 [[http://www.howtoforge.com/software-raid1-grub-boot-debian-etch|Дебаиновская инструкция для GRUB Legacy]]
-{{tag> HOWTO Администрирование Server }}
+{{tag> HOWTO Администрирование Server RAID}}

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

Различия