Все мои изображения находятся в большом lvm-томе, все lvs для новой установки создаются с помощью файловой системы (ext3 / ext4). Итак, мой подход заключается в том, чтобы сделать это для каждой отдельной машины:
/tmp/img_snap/)/tmp/convert_src/)/tmp/convert_dest)/tmp/convert_src к /tmp/convert_destШаги 1-7 уже написаны, поэтому на шаге 9 я могу снова запустить этот сценарий. Это означает небольшие накладные расходы, потому что снимок lv не нужен, но меня это устраивает и я знаю об этом.
Поскольку исходная машина может работать до шага 8 (а шаг 9 должен копировать только дельту), время простоя должно быть минимальным. Я также renice и ionice процесс (ы) rsync, поэтому влияние на все другие системы должно быть минимальным. Или я так думал ...
INFO: task loop27:23352 blocked for more than 120 seconds, INFO: task pdflush:7329 blocked for more than 120 seconds., ... и их следы звонков и прочее. Почему / когда? Я не могу понять закономерность? Слишком много ввода-вывода, слишком много ЦП? И самое главное: почему не блокируются мои rsync-процессы - я reniced (renice 20 -p $(pidof rsync)) и ионизированный (ionice -c2 -n7 -p$pid) их - разве эти процессы не должны быть заблокированы первыми?rsync - очень хороший инструмент. Если вы его используете, выберите параметры "-aSH --delete", чтобы получить почти идентичную цель (метки времени программных ссылок будут иметь текущее время).
Из вашего письма я понимаю, что время, необходимое для rsync, кажется вашей основной проблемой, в то время как выключение / запуск DomU происходит довольно быстро (включая их приложения, я полагаю).
Я вижу еще одну проблему в вашем снимке большого LV, содержащего все ваши запущенные DomU. Если у вас много запросов на запись, ваш снимок будет заполняться довольно быстро - и снимок будет замедлять работу DomU во время записи.
В этой ситуации я бы выбрал другой подход: используйте программный рейд 1 для зеркалирования ваших изображений на новые LV.
Если вы хотите, вы можете объединить это с snapshot / rsync, чтобы уменьшить объем данных, которые необходимо переместить. Но IMHO время, необходимое для того, чтобы разобраться с этим и написать сценарий, не стоит усилий.
Итак, план такой - в обоих случаях вам понадобятся блочные устройства (подключите образы по петле):
A) Используя md (настраивается через mdadm) Напишите сценарий для:
- Завершить работу DomU
- Закольцовывание образа DomUs
- Создайте деградированное устройство md-raid-1-с этим образом
- Загрузите DomU с "phy: mdN" в качестве нового дискового устройства.
- Увеличить количество участников raid1 с 1 до 2
- добавьте свой целевой LV
- Измените настройку вашего DomU, чтобы в будущем он использовал phy: vgX / lvY
- Если зеркало готово, перезапустите DomU с новой настройкой.
При использовании плана A у вас будет два простоя на один перезапуск 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 и начните динамическую миграцию ...