Перенос mdadm raid1 на другую систему.
Приветствую.
Если перенести жесткие диски с raid1 с одного пк с linux на другой пк с linux, система корректно распознает массив и будет достаточно просто смонтировать его? Несовместимости м-ду разными версиями mdadm нету? Имя устройства, например было /dev/md1, останется прежним? Что будет если на новом ПК устройство с таким именем уже существует?
достаточно одной части
вы похоже ответили не в той теме.
Несовместимости м-ду разными версиями mdadm нету?
В случае зеркала (RAID1) проблем быть не должно.
Имя устройства, например было /dev/md1, останется прежним?
Зависит от конфигурации системы. В общем случае сохранение нумерации не гарантируется.
Что будет если на новом ПК устройство с таким именем уже существует?
Кто-то из массивов изменит нумерацию. Кто именно, зависит от порядка инициализации дисков при загрузке. Чтобы избежать подобных проблем, лучше в fstab указывать UUID дисков, а не конкретные устройства.
вы похоже ответили не в той теме.
Ответ был по теме. Речь о том, что в случае зеркала для доступа к информации достаточно смонтировать один диск, переносить массив целиком необязательно.
перенести жесткие диски с raid1 с одного пк с linux на другой пк с linux
неплохо бы добавить его /etc/mdadm/mdadm.conf, но ЕМНИП это уже не обязательно
система корректно распознает массив
если mdadm установлен и автообнаружение включено ( по умолчанию включено )
Несовместимости м-ду разными версиями mdadm нету?
тебя интересует версия метаданных ( mdadm metadata version )
на актуальных версиях ОС несовместимости нет. Если новый комп спёр из музея и не стал обновлять ОСь, теоретически может не взлететь. Но на моей памяти такого ещё не было
Имя устройства, например было /dev/md1, останется прежним? Что будет если на новом ПК устройство с таким именем уже существует?
На имена устройств глубоко пофиг, они динамические, уже лет пятнадцать всё работает по uuid
Если тебе зачем-то нужно постоянное имя, добавить в /etc/mdadm/mdadm.conf
Если ты вручную доабавил два рейда с одним именем, это уже точно твои проблемы. Скорее всего, первый обнаруженный получит имя, а конкурент станет чем-то вроде md127. Никогда не интересовался, что будет, если выстрелить себе в ногу. Просто не стрелял — по мне так отличное решение 😉
Спасибо всем за ответы. Последний вопрос, имя устройства задаваемое при создании массива, например md1, хранится на диске в спец. области или только в конфигах системы на которой был создан массив?
Последний вопрос, имя устройства задаваемое при создании массива, например md1, хранится на диске в спец. области или только в конфигах системы на которой был создан массив?
В общем случае — нигде. Получает рандомное при загрузке, как например диски именуются sda, sdb и т.д.
Источник
Перенос работающего сервера на RAID
Жил-был LAMP-сервер на Ubuntu 12.04, который работал на одном диске. Соответственно, возникла задача обеспечить перенос сервера на более отказоустойчивую конфигурацию – RAID1. Товарищи, в ведении которых был данный сервер установили второй диск, а дальнейшее было возложено на меня, причём доступ к серверу был только по ssh, что осложняло задачу.
После поисков была найдено руководство и начались тренировки на виртуальной машине. Когда я добился на ней нужного результата, то с некоторым волнением, но всё же успешно осуществил перенос вышеупомянутого сервера на RAID1 и вчерне набросал порядок необходимых действий. Статью, в которой более подробно описан процесс переноса, я решил разместить на «Хабре».
Разбивка диска была такова:
Поскольку второй диск был новым, то никаких операций по удалению предыдущей разметки не потребовалось.
Первым делом были внесены правки в /etc/default/grub :
GRUB_TIMEOUT=5 (делаем таймаут покороче);
GRUB_RECORDFAIL_TIMEOUT=10 (добавляем, чтобы система могла загрузиться и в случае ошибки, не требуя интерактивного вмешательства; таймаут по вкусу);
GRUB_CMDLINE_LINUX_DEFAULT=«bootdegraded» (обязательно добавляем «bootdegraded», чтобы система могла загрузиться с неполноценного массива);
#GRUB_HIDDEN_TIMEOUT_QUIET=true (необходимо закомментировать, чтобы меню GRUB всегда отображалось).
Временно отключаем swap, разделу /dev/sda1 с помощью fdisk устанавливаем тип fd (Linux raid autodetect), после чего делаем разбивку второго диска такой же, как и у первого (все операции выполняются с правами суперпользователя):
Затем начинаем шаг за шагом собирать наш RAID:
Создаём раздел под swap :
Правим /etc/fstab , заменяя разделы первого диска разделами RAID и меняя цифры, стоящие в шестом столбце (необходимость проверки fsck), на нули:
Активируем swap :
Поскольку на первом диске сейчас работает наш сервер, то RAID создаём, используя пока лишь только второй диск:
Обновляем конфигурацию mdadm.conf :
Обновляем initramfs , чтобы он сохранил информацию о нашем RAID:
Далее начинается наиболее длительный процесс – синхронизация данных. Поскольку наш сервер выполняет какие-то задачи, то может получиться так, что после завершения синхронизации часть информации на разделах массива будет отличаться от данных на соответствующих разделах рабочего диска. Тут есть несколько вариантов действий: можно выбрать время наименьшей нагрузки, можно остановить часть сервисов на время синхронизации, а можно и пренебречь расхождениями. В общем, монтируем и синхронизируем:
Чтобы синхронизация не оборвалась из-за неожиданного прерывания ssh-подключения, не помешает использование терминального мультиплексора.
Дождавшись окончания синхронизации, монтируем системные каталоги к новому корню:
Переходим в новую систему и устанавливаем загрузчик на оба диска
Обновляем загрузочную конфигурацию, чтобы подгрузились необходимые для RAID модули ( mdraid1x ):
Возвращаемся в исходную систему и, если есть такая необходимость, повторно синхронизируем разделы:
Так как у нас нет физического доступа ни к консоли, ни к серверу и мы не можем выбрать диск, с которого будет грузиться RAID, то применяем такой трюк: на диск, с которого стартует система и который находится не в RAID, переносим подготовленную конфигурацию загрузчика, «знающую» о RAID. Копируем grub.cfg c диска, находящегося в RAID на наш текущий загрузочный диск. Это позволит системе стартовать с /dev/sda, но при этом смонтировать массивы и далее продолжить загрузку с раздела, уже находящегося в RAID. Сначала сохраняем старый файл, который может понадобиться при восстановлении системы в случае невозможности загрузиться с RAID, а затем копируем файл «боевой» конфигурации:
Дополнительно можно сравнить эти файлы и убедиться, что в новом файле конфигурации загрузчика раздел root указан как находящийся на RAID.
Теперь переходим к самому важному этапу проделанной работы и перезагружаемся. Можно запустить в консоли ping до сервера, чтобы стало ясно, когда сервер вновь станет доступен. Логинимся и смотрим, что у нас всё получилось так, как мы хотели: lsblk показывает, что директории / и /home находятся на разделах RAID.
На закуску остаётся лёгкая и приятная работа – добавить в массив два раздела первого диска, предварительно установив им с помощью fdisk тип fd:
а затем периодически поглядывать, как идёт синхронизация зеркал:
На этом позвольте закончить, спасибо за внимание!
Источник
HOW-TO: Перевод системного раздела на RAID.
Содержание
Задача
Условия
На оригинальном диске расположен корень и своп, новый диск чист. Мы будем делать программный RAID1. Используется Ubuntu Server 11.10
Порядок действий
Порядок действий достаточно важен, и выработан в процессе нескольких попыток решить эту задачу с использованием виртуальной машины.
1. Подключаем второй диск к компьютеру. 1)
2. Форматируем новый диск 2) —
3. Создаем на нем массив:
4. Далее создаем на массиве разделы под будущую систему. Создаем такие же разделы под корень и своп как на оригинальном диске 3) .
5. Создаем файловые системы на разделах зеркала
6. Монтируем будущий корень и копируем в него текущий корень
7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно — зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень.
8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab. 4) По редактированию fstab лучше сверится с этой статьей.
9. Создаем новую конфигурацию GRUB и проверяем, что в его конфиг прописан раидный uuid для корня.
10. Ставим первую стадию GRUB на второй диск (который несет на себе часть зеркала).
11. Очень важный шаг! Нужно прописать (хотя бы на время) конфигурацию mdadm, которая позволит загрузится с деградированного массива (а у нас пока он именно такой)
12. Можно перегружаться и выбрать в BIOS загрузочным второй диск 5) , или можно вернутся в реальную систему и обновить GRUB — он найдет вторую систему установленную на раиде и включит ее свое меню.
Тут полезно еще раз запустить rsync, что бы он обновил данные на раиде тем, что успело изменится на реальном корне за время настройки раида 6) . Но сделать это стоит перед перестройкой конфига GRUB, что бы его новый конфиг не был записан на раид.
13. Перегрузившись в новую систему остается только навесить в RAID первый диск и обновить на нем первую стадию груба.
После чего сморим через cat /proc/mdstat как перестраивается наш деградированный массив в полноценно рабочий.
Результат: Система на раиде.
Проверка
Т.к. в процессе написания этой инструкции использовалась виртуалка то можно поиграть с потерей дисков. Гасим виртуалку, отсоединяем первый диск, грузимся — норма (массив деградированный на втором диске, груб стартанул со второго диска). Снова гасим — подцепляем обнуленный второй диск, создаем на нем MBR, раздел, и добавляем его в массив (как выше добавлялся sda1) — система перестраивает массив и переходит в нормальный режим.
Повторяем то-же, но отключая и обнуляя второй диск — все работает.
ПРОФИТ!!
Комментарии:
№1: Если вы создадите массив на весь диск — то на диске может быть занят первый трек — и грубу некуда будет поставить свою первую стадию. А кроме того GRUB вообще не понимает? что на диске творится когда на нем расположен раидный раздел без MBR и не может встать туда. Другой (не совсем правильный) вариант — создавать на каждый раздел — свой массив. Идеологически — массив это диск, а не раздел, и если вы, имея массив, запустите fdisk -l то он вам на каждый RAID массив выдаст информацию именно как о диске и будет на каждом массиве искать таблицу разделов.
ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы — ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой — т.к. данные в реальном корне «уйдут» по времени от данных на раидном, и перезагрузка «отбросит» сервисы на сервере в момент времени, когда была сделана копия. А кроме того — такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время — тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами 7)
Чуть улучшает состояние дел вызов rsync повторно перед пеезагрузкой (шаг 12). Но и он не может ничего гарантирововать.
Источник
Перенос работающей Linux системы на программный RAID1
Данная статья детально описывает, как перенести Linux систему на RAID1 без переустановки, добавив схожий по характеристикам жесткий диск к тому, на котором установлена система. Все операции будут проводиться на системе с двумя IDE-HDD, операционная система CentOS 5.1.
Просмотрим таблицу разделов:
По полученным данным видно, что установлены два идентичных жестких диска объемом 80 Гб. На первом диске создано 2 раздела: корневая файловая система и SWAP-раздел. Второй жесткий диск абсолютно пуст. Диски определены системой как hda и hdb.
Первым делом нам необходимо создать таблицу разделов на втором диске, идентичной первому.
Опция -d делает дамп таблицы разделов.
Если Вы получите сообщение об ошибке используйте опцию —force.
Посмотрим теперь, что представляют диски, установленные в системе:
Видно, что таблица разделов на втором диске полностью соответствует таблице разделов на первом диске.
Теперь изменим тип таблицы разделов на втором диске на Linux raid autodetect:
На запрос введем t. Пункт t — это изменение id системы раздела.
Выбираем номер раздела (напомню в нашем случае их 2).
Вводим шестнадцатеричный id код. Т.к. нам нужно Linux raid autodetect, то выбираем fd.
То же самое повторяем и для второго раздела:
Теперь записываем таблицу разделов на диск и выходим, выбрав опцию w.
Теперь загоним разделы нашего второго диска в массивы. Статус RAID намеренно выбран degraded.
]# mdadm —create /dev/md0 —level=1 —raid-disks=2 missing /dev/hdb1
Если все успешно, то получаем сообщение:
mdadm: array /dev/md0 started.
При попытке повторить то же самое для второго раздела:
]# mdadm —create /dev/md1 —level=1 —raid-disks=2 missing /dev/hdb2
Получаем сообщение об ошибке:
mdadm: error opening /dev/md1: No such file or directory
Мы воспользуемся опцией —auto:
]# mdadm —create /dev/md1 —level=1 —raid-disks=2 missing /dev/hdb2 —auto=yes
И получим сообщение, что операция прошла успешно:
mdadm: array /dev/md1 started.
Теперь выполним команду cat /proc/mdstat и убедимся, что наш деградировавший рейд работает:
md1 : active raid1 hdb2[1]
522048 blocks [2/1] [_U]
md0 : active raid1 hdb1[1]
77617920 blocks [2/1] [_U]
По статусу _U видим, что с первым диском у нас проблемы, что естественно, ведь его в массиве нет, а вот со вторым все ОК.
Теперь создадим файловые системы в наших массивах: ext3 в первом массиве и swap по втором:
Теперь создадим директорию для монтирования первого массива и смонтируем его туда:
]# mount /dev/md0 /mnt/md0/
Создаем файл конфигурации mdadm — /etc/mdadm.conf:
]# nano -w /etc/mdadm.conf
И вносим в него такую строку: DEVICE partitions
Теперь заносим информацию о RAID массивах в файл конфигурации mdadm:
]# mdadm —detail —scan >> /etc/mdadm.conf
Теперь правим файл /etc/fstab:
]# nano -w /etc/fstab
И приводим в соответствие с подчеркнутыми значениями:
Теперь необходимо отредактировать конфигурационный файл загрузчика GRUB:
]# nano -w /boot/grub/grub.conf
Делаем две копии конфигурации текущего раздела.
Значения которые подлежат изменению подчеркнуты красным.
Создаем новый образ initrd командой:
]# mkinitrd /boot/initrd-`uname -r`-raid1.img `uname -r`
Теперь переносим данные нашей системы на массив:
]# cp -dpRx / /mnt/md0/
Теперь настроим загрузчик на второй диск, введя команду grub:
Работать будем с меню GRUB:
Теперь перезагружаемся и выбираем для загрузки второй ядро:
Теперь изменим тип таблицы разделов на перовом диске на Linux raid autodetect:
На запрос введем t. Пункт t — это изменение id системы раздела.
Выбираем номер раздела (напомню в нашем случае их 2).
Вводим шестнадцатеричный id код. Т.к. нам нужно Linux raid autodetect, то выбираем fd.
То же самое повторяем и для второго раздела:
Теперь записываем таблицу разделов на диск и выходим, выбрав опцию w.
Теперь добавляем первый раздел на первом диске в наш первый массив (извините за тавтологию):
]# mdadm —add /dev/md0 /dev/hda1
]# mdadm —add /dev/md1 /dev/hda2
Сейчас начался ребилдинг массива. Процесс достаточно длительный и зависит от емкости диска. За процессом можно наблюдать:
]# watch cat /proc/mdstat
Теперь выполним команду cat /proc/mdstat и убедимся, что наш первый диск добавлен в массив:
Следующим шагом нам необходимо изменить файл конфигурации mdadm:
]# nano -w /etc/mdadm.conf
Нам необходимо либо удалить, либо закомментировать строки с параметрами дисков:
Сохраняем изменения и выходим.
Теперь соберем новые данные о массивах:
]# mdadm —detail —scan >> /etc/mdadm.conf
И пересоберем образ ядра. Обратите внимание на опцию -f, она позволит перезаписать существующие данные.
]# mkinitrd -f /boot/initrd-`uname -r`-raid1.img `uname -r`
Перезагружаемся и выбираем первое ядро при загрузке.
Если система загрузилась, то продолжаем работать
Источник
