Xen: конвертировать изображение в lvm с минимальным временем простоя

Мои цели:

  • Конвертируйте все мои DomU из ​​изображений на основе lvm
  • Минимальное время простоя
  • Минимальное влияние на производительность на других DomUs/Dom0

Мой план / настройка:

Все мои изображения находятся в большом lvm-томе, все lvs для новой настройки создаются с файловой системой (ext3/ext4). Так что мой подход - сделать это для каждой машины:

  1. сделать снимок большого изображения-лв
  2. смонтировать этот снимок (например, на /tmp/img_snap/)
  3. шлейф-монтировать сам образ (например, на /tmp/convert_src/)
  4. смонтировать новый lv (например, на /tmp/convert_dest)
  5. Rsync из /tmp/convert_src в /tmp/convert_dest
  6. размонтировать все
  7. удалить lv-снимок
  8. закрытие DomU
  9. повторите шаги 1-7
  10. изменить настройки диска в конфиге DomU
  11. разжечь дом снова

Шаги 1-7 уже записаны в сценарии, поэтому на шаге 9 я просто могу снова запустить этот сценарий. Это означает немного накладных расходов, потому что lv-snapshot не нужен, но я в порядке и знаю об этом.

Из-за того, что исходный компьютер может работать до шага 8 (а шаг 9 должен копировать только дельту), время простоя должно быть минимальным. Я также renice а также ionice процесс (ы) rsync, поэтому влияние на все другие системы должно быть минимальным. Или так я думал...

  • Debian Lenny
  • Xen 3.2 из Debian
  • HP ML350 G5 с контроллером SmartArray (iirc: e220?)
  • диски подключены через SATA

Вопросы / Проблемы:

  • Этот подход приемлем и протестирован с небольшими изображениями, но у меня есть несколько больших изображений 400 ГБ +. Это занимает много лет. Есть ли лучшие подходы?
  • Иногда - я точно не знаю, почему - загрузка Dom0 сильно возрастает, машина зависает, и я получаю сообщения вроде INFO: task loop27:23352 blocked for more than 120 seconds, INFO: task pdflush:7329 blocked for more than 120 seconds.... и их следы вызова и прочее. Почему / когда? Я не могу понять шаблон? Есть слишком много ввода-вывода, слишком процессор? И больше всего: почему не блокируются мои rsync-процессы - я обслужен (renice 20 -p $(pidof rsync)) и ионизированный (ionice -c2 -n7 -p$pid) их - не должны ли эти процессы быть первыми заблокированными?
  • Вообще какие-то намеки и идеи по улучшению?
Источник

1 ответ

Решение

rsync - очень хороший инструмент. Если вы используете его, выберите опцию "-aSH --delete", чтобы вы получили почти одинаковую цель (ctime-штампы софт-ссылок будут иметь текущее время).

Из вашего письма я понимаю, что время, необходимое для rsync, кажется, является вашей главной проблемой, в то время как завершение / запуск DomUs довольно быстр (включая их приложения, я полагаю).

Я вижу еще одну проблему в вашем снимке вашего большого LV, содержащего все ваши работающие DomU. Если у вас много запросов на запись, ваш снимок будет заполняться довольно быстро - и снимок будет замедлять работу DomU во время записи.

В этой ситуации я бы выбрал другой подход: используйте программный рейд 1 для зеркального отображения ваших изображений в новые LV.

Если вы хотите, вы можете объединить это с snapshot/rsync, чтобы уменьшить объем данных, которые необходимо переместить. Но ИМХО, время, необходимое для того, чтобы разобраться и написать сценарий, не стоит усилий.

Итак, вот план - в обоих случаях вам нужны блочные устройства (монтируйте петлевые образы):

A) Использование md (настройка через mdadm). Напишите скрипт для:

  1. Выключи ДомУ
  2. Loopback-монтировать образ DomUs
  3. Создайте ухудшенное устройство md-raid-1-device с этим образом
  4. Загрузите ваш DomU с "phy:mdN" в качестве нового дискового устройства
  5. Увеличьте количество участников raid 1 с 1 до 2
  6. добавить цель LV
  7. Измените настройку вашего DomU, чтобы в будущем он использовал phy:vgX/lvY
  8. Если зеркало завершено, перезапустите DomU с новой настройкой

В соответствии с планом А у вас есть два простоя, продолжающиеся один перезапуск DomU. Зеркальное отображение будет происходить на заднем плане как можно быстрее.

Недостаток: все данные будут синхронизированы (зеркало RAW, не основанное на файловой системе)

Вы можете обойти это, создав md-raid1 с (--assume clean) без ухудшения качества. Но это будет непросто (вам понадобится rsync для передачи ваших данных в LV, а затем для зеркалирования дельты с помощью md-bitmap).

Б) Использование drbd (настраивается через /etc/drbd.conf). Если вы планируете в будущем перейти на drbd, вы должны пойти по этому пути. Я не проверял это, но не вижу причины, по которой drbd не должен отражаться между 127.0.0.1 и 127.0.0.2;-)

Я не проверял это, но это должно работать - и это более сложно, чем план А.

Недостаток: сложный, не проверенный.

Но: Если вы все равно хотите переключиться на drbd, вы можете подготовить свой DomU таким образом. Запустите в отключенном режиме, пока ваш кластер не будет готов, затем подключитесь, синхронизируйте по IP и начните динамическую миграцию...

Источник
Другие вопросы по тегам