Pull to refresh

Пошаговое описание живой миграции OpenVZ

Reading time 2 min
Views 4.7K
У нас есть 2 HN: node1.srv.my и node2.srv.my. На node1.srv.my у нас крутится некий контейнер (service.srv.my), который перерос старую ноду и хочет дальнейшего роста.

Нам желательно снизить максимально время простоя контейнера. Насколько это можно осуществить?
Ответ: в зависимости от задач VE, может и не будет вообще простоя.
OpenVZ_logo

Например, у меня на service.srv.my находится веб-сервис (LNAMP) с высокопосещаемым сайтом и группой редакторов-наполнителей. Они имеют доступ к сайту “на запись”. В общем это единственная категория пользователей сервиса, которая заметит переезд. Ладно. Приступим.

Мы будем пользоваться утилитой vzmigrate.
1. Временно включаем доступ для пользователя root на сервере node2.srv.my в конфиге sshd:
PermitRootLogin yes — выполняется на node2.srv.my

2. Создаем ключи на node1.srv.my:
ssh-keygen -t rsa -b 4096 — выполняется на node1.srv.my

Выбираем пустой пароль, чтобы не спрашивали нас ещё и пароль при входе по ключу.
3. Кладём ключ в node2.srv.my:
ssh-copy-id -i ~/.ssh/id_rsa.pub root@node2.srv.my — выполняется на node1.srv.my

Попросят ввести пароль root node2.srv.my для валидации.
4. Обновляем DNS для зоны service.srv.my, если поменяется IP-адрес. (В этом случае лучше уменьшить TTL – минут до 15.)

5. Теперь смело запускаем миграцию:
vzmigrate -v --remove-area no --online --rsync="-v" host_target_ip veid_service.srv.my — выполняется на node1.srv.my

В зависимости от размеров и скорости сети между нодами может понадобиться много времени. Может стоит использовать screen, если вероятны разрывы соединения.
--online позволит осуществлять переезд не переставая оказывать услуги service.srv.my
--rsync="-v" — параметры rsync, тут можно настраивать показывать ли файлы, которые будут переноситься, показывать ли прогресс файлов.
--remove-area no позволяет сохранить файлы вне зависимости от успешности переноса. К моему удивлению это всё-равно не предотвратило остановку VE. Наверно что-то не дочитал Если надо иметь возможность быстро отменить миграцию выбираем –remove-area no и переименовываем конфиг veid.conf.migrated в veid.conf. Если надо удалить файлы ставим yes.
host_target_ip — IP адрес node2.srv.my
veid_service.srv.my — VEID сервиса, например, 301 у меня.

Иногда возникают проблемы из-за разных настроек iptables (http://phpsuxx.blogspot.com/2010/08/openvz-error-most-probably-some.html)

6. vzlist на node2.srv.my показывает, что контейнер 301 теперь здесь работает, на node1.srv.me vzlist покажет, что контейнера уже нет (но файлы мы сохранили на всякий случай )

7. Нам может понадобиться поменять IP service.srv.my. В этом случае меняем в конфиге IP и рестартуем VE (vzctl restart 301). Либо же, выполнив изменение IP-адреса путем использования --ipdel и --ipdel.

Переезд закончен
Люди пишут, что при переезде сеть не теряется: например бэкап данных из VE мог сливаться на backup-сервер при переезде, плавно переходя с одной ноды, на другою. Но не проверял.
migration

Давно не писал на хабре. Теперь исправлю это положение.
Tags:
Hubs:
+4
Comments 7
Comments Comments 7

Articles