Comments 19
Чтобы не было проблем с /dev/md127 обновите initrd
По теме статьи стал интересен такой вопрос: как в madadm можно оперировать схемой расположения raid10? Т.е. как будут выбраны пары уровня raid1? Этой схемы не видно в том числе в /proc/mdstat к сожалению.
Неоднократно проводил подобные операции на серверах без LVM.
Суть в следующем:
Собираем из двух новых дисков деградированный RAID10
на него rsync-аем данные, ставим граб, глубокой ночью еще один rsync, стопим все службы и финальный rsync после чего нужно поправить fstab и перезагрузить сервер.
Загружаемся с нового массива, старый ломаем и освободившиеся диски вставляем в RAID10.
Суть в следующем:
Собираем из двух новых дисков деградированный RAID10
mdadm -v --create /dev/md1 --level=raid10 --raid-devices=4 /dev/sda1 /dev/sdb1 missing missingна него rsync-аем данные, ставим граб, глубокой ночью еще один rsync, стопим все службы и финальный rsync после чего нужно поправить fstab и перезагрузить сервер.
Загружаемся с нового массива, старый ломаем и освободившиеся диски вставляем в RAID10.
Еще одно важное замечание, прежде чем это делать, отключите обязательно dmraid (nodmraid опция к initrd), иначе результат не предсказуем.
При чем тут rsync? o_O
А данные с одного массива на другой каким образом переползут?
На сколько я знаю утилита rsync работает на уровне файлов, а mdadm оперирует блоками.
Вот смотрите, есть raid1 на нем лежат файлы, мы собираем RAID10 из двух дисков на нем файлов нужных нам нет. Я эти файлы переношу rsync-ом, а Вы?
Т.е. вы мигрируете абсолютно на другую физику в режиме offline?
Просто есть процедура миграции практически on-line (с одно перезагрузкой) на raid1 с чистой физики. Т.е. создается метаустройство на работающей системе, mdadm устройство не блокирует, хотя это и не бехзопасно для данных. Думаю это сработает и для raid10. Это же минимизирует время простоя, не так ли?
Просто есть процедура миграции практически on-line (с одно перезагрузкой) на raid1 с чистой физики. Т.е. создается метаустройство на работающей системе, mdadm устройство не блокирует, хотя это и не бехзопасно для данных. Думаю это сработает и для raid10. Это же минимизирует время простоя, не так ли?
Готовы рискнуть данными на нагруженном сервере? По моей схема даунтайм в пределах 5-ти минут, стоит ли искать от добра добра?
Ну время от объемов зависит и количества файлов — это очевидно.
По моему мнению консистентность данных при синхронизации на блочном уровне более гарантирована, нежели синхронизация на файловом уровне. Собственно скорость синхронизации поблочно выше, чем файловая. Хотя выигрыш по времени думаю будет при достаточно высокой заполеннности файловой системе. Ну т.е. очевидно что блочная синхронизация пройдет по всему устройству, а если ФС пустая, то синхронизировать практически нечего.
Собственно говоря рисков в блочной синхронизации я не вижу. А вы где их увидели?
По моему мнению консистентность данных при синхронизации на блочном уровне более гарантирована, нежели синхронизация на файловом уровне. Собственно скорость синхронизации поблочно выше, чем файловая. Хотя выигрыш по времени думаю будет при достаточно высокой заполеннности файловой системе. Ну т.е. очевидно что блочная синхронизация пройдет по всему устройству, а если ФС пустая, то синхронизировать практически нечего.
Собственно говоря рисков в блочной синхронизации я не вижу. А вы где их увидели?
Перечитайте пожалуйста, делается несколько рсинков и финальный занимает пару минут от силы. Проверено на двух десятках хостинговых серверов, я думаю вы понимаете сколько там файлов и какой объем.
Ну на самом деле могу только гадать :) Не так давно решал задачу синхронизации двух хранилищ данных.
Объем данных на тот момент был около 700 гигабайт
Объем одного файла около 300kB
Количество файлов было окло двух милионов таким образом.
rsync пыхтел над этим объемом более суток, пока я его просто не прервал.
Инкриментальный блочный snapshot создается и передается несравнимо быстрее.
Вот тут описал подробно, если интересно. Не стоит обращать внимание на используемые технологии, просто я это привел как пример сравнения блочного и файлового уровня в плане скорости как частный пример.
Так же есть погуглить, то большинство обзоров говрит о блочной миграции. А об использовании rsync я слышу в первый раз преминительно к этой задаче. Мне кажется, что это не уместно в данном случае.
Объем данных на тот момент был около 700 гигабайт
Объем одного файла около 300kB
Количество файлов было окло двух милионов таким образом.
rsync пыхтел над этим объемом более суток, пока я его просто не прервал.
Инкриментальный блочный snapshot создается и передается несравнимо быстрее.
Вот тут описал подробно, если интересно. Не стоит обращать внимание на используемые технологии, просто я это привел как пример сравнения блочного и файлового уровня в плане скорости как частный пример.
Так же есть погуглить, то большинство обзоров говрит о блочной миграции. А об использовании rsync я слышу в первый раз преминительно к этой задаче. Мне кажется, что это не уместно в данном случае.
В случае отсутствия lvm и zfs, я так думаю о снапшотах речи быть не может.
Можно ваш вариант блочной миграции? В несколько команд, чтобы идею понять.
Можно ваш вариант блочной миграции? В несколько команд, чтобы идею понять.
>> В случае отсутствия lvm и zfs, я так думаю о снапшотах речи быть не может.
>>> Не стоит обращать внимание на используемые технологии…
>> Можно ваш вариант блочной миграции?
Я сейчас с ходу не нагуглил адекватной статьи, и у меня нет системы, чтобы в горячую накокипастить, но могу объяснить на пальцах.
Допустим у нас есть 2 одинаковых диска sda и sdb
Система стоит на sda (ну или у вас там нечто крутится, короче offline надо минимизировать).
Меняем тип разделов на auto-raid (как-то так он там называется)
Копируем таблицу разделов на sdb
Создаем метаутройство md1 из sda1 и sdb1 (допустим у нас только один раздел).
Наблюдаем в /proc/mdstat процесс синхронизации, при этом у нас система продолжает работать и диски в итоге получаются полностью синхронизированы. Т.е. тут эксплуатируется особеннсть, что физические устройства не блокируются при использовании метаустрйством.
Добавляем наш рейд в /etc/mdadm.conf
Далее варианты. Если мы мигрировали рут, то надо поправит grub.conf и fstab и перезагрузиться. Если же мигрировали другой data-storage, то надо остановить приложения, которые его используют, перемонтировать (если это файловая сисема) эту точку монтирования как метаустройство и запустить приложение.
В итоге простой заключается в перезагрузке или перезапуске приложения.
>>> Не стоит обращать внимание на используемые технологии…
>> Можно ваш вариант блочной миграции?
Я сейчас с ходу не нагуглил адекватной статьи, и у меня нет системы, чтобы в горячую накокипастить, но могу объяснить на пальцах.
Допустим у нас есть 2 одинаковых диска sda и sdb
Система стоит на sda (ну или у вас там нечто крутится, короче offline надо минимизировать).
Меняем тип разделов на auto-raid (как-то так он там называется)
Копируем таблицу разделов на sdb
Создаем метаутройство md1 из sda1 и sdb1 (допустим у нас только один раздел).
Наблюдаем в /proc/mdstat процесс синхронизации, при этом у нас система продолжает работать и диски в итоге получаются полностью синхронизированы. Т.е. тут эксплуатируется особеннсть, что физические устройства не блокируются при использовании метаустрйством.
Добавляем наш рейд в /etc/mdadm.conf
Далее варианты. Если мы мигрировали рут, то надо поправит grub.conf и fstab и перезагрузиться. Если же мигрировали другой data-storage, то надо остановить приложения, которые его используют, перемонтировать (если это файловая сисема) эту точку монтирования как метаустройство и запустить приложение.
В итоге простой заключается в перезагрузке или перезапуске приложения.
Sign up to leave a comment.
Миграция CentOS6 с raid1 на raid10