LXD 2.0: Живая миграция [9/12].
Девятая статья, в которой пробуем новую возможность Live Migration, выполняемую за счёт проекта CRIU.
Введение
Одной из интересных особенностей LXD 2.0 (пока в статусе экспериментальной) является поддержка контрольных точек (checkpoint) и восстановление (restore).
Проще говоря, checkpoint/restore позволяют состояние контейнера сериализовать на диск и восстановить его на этом хосте (снимок с сохранением состояния) или восстановить на другом, что сродне live migration.
Требования
Для доступа к живой миграции и к снимкам с сохранением состояния (stateful snapshot) вам потребуется:
- Ядро Linux 4.4 или новее
- CRIU 2.0, возможно, с некоторыми патчами для ядра
- LXD запущен непосредственно на хосте. Вложенность контейнеров нельзя использовать.
- Для миграции целевая (target) машина должна исполнить все инструкции исходного сервера (source); ядро на целевом хосте понимать системные вызовы как и на исходном; все файловые системы, примонтированные на source, должны быть доступны и на target.
Всё необходимое есть в Ubuntu 16.04, поэтому нужно поставить лишь: apt install criu
Использование
Снимок с сохранением состояния
Нормальный снимок выглядит так:
lxc snapshot c1 first
lxc info c1 | grep first
first (taken at 2016/04/25 19:35 UTC) (stateless)
Снимок с сохранением состояния (stateful snapshot) выглядит так:
lxc snapshot c1 second --stateful
lxc info c1 | grep second
second (taken at 2016/04/25 19:36 UTC) (stateful)
Состояние контейнера сохранено на диск как часть снимка. Восстановление снимка делается как и ранее:
lxc restore c1 second
Stateful stop/start
Допустим вы хотите перезагрузить ваш сервер из-за обновления ядра. Вместо того, чтобы ждать старта всех контейнеров после перезагрузки хоста, вы можете:
lxc stop c1 --stateful
Состояние контейнера будет сохранено на диск и использовано в следующий раз при его старте.
tree /var/lib/lxd/containers/c1/rootfs/state/
/var/lib/lxd/containers/c1/rootfs/state/ ├── cgroup.img ├── core-101.img ├── core-102.img ├── core-107.img ├── core-108.img ├── core-109.img ├── core-113.img ├── core-114.img ├── core-122.img ├── core-125.img ├── core-126.img ├── core-127.img ├── core-183.img ├── core-1.img ├── core-245.img ├── core-246.img ├── core-50.img ├── core-52.img ├── core-95.img ├── core-96.img ├── core-97.img ├── core-98.img ├── dump.log ├── eventfd.img ├── eventpoll.img ├── fdinfo-10.img ├── fdinfo-11.img ├── fdinfo-12.img ├── fdinfo-13.img ├── fdinfo-14.img ├── fdinfo-2.img ├── fdinfo-3.img ├── fdinfo-4.img ├── fdinfo-5.img ├── fdinfo-6.img ├── fdinfo-7.img ├── fdinfo-8.img ├── fdinfo-9.img ├── fifo-data.img ├── fifo.img ├── filelocks.img ├── fs-101.img ├── fs-113.img ├── fs-122.img ├── fs-183.img ├── fs-1.img ├── fs-245.img ├── fs-246.img ├── fs-50.img ├── fs-52.img ├── fs-95.img ├── fs-96.img ├── fs-97.img ├── fs-98.img ├── ids-101.img ├── ids-113.img ├── ids-122.img ├── ids-183.img ├── ids-1.img ├── ids-245.img ├── ids-246.img ├── ids-50.img ├── ids-52.img ├── ids-95.img ├── ids-96.img ├── ids-97.img ├── ids-98.img ├── ifaddr-9.img ├── inetsk.img ├── inotify.img ├── inventory.img ├── ip6tables-9.img ├── ipcns-var-10.img ├── iptables-9.img ├── mm-101.img ├── mm-113.img ├── mm-122.img ├── mm-183.img ├── mm-1.img ├── mm-245.img ├── mm-246.img ├── mm-50.img ├── mm-52.img ├── mm-95.img ├── mm-96.img ├── mm-97.img ├── mm-98.img ├── mountpoints-12.img ├── netdev-9.img ├── netlinksk.img ├── netns-9.img ├── netns-ct-9.img ├── netns-exp-9.img ├── packetsk.img ├── pagemap-101.img ├── pagemap-113.img ├── pagemap-122.img ├── pagemap-183.img ├── pagemap-1.img ├── pagemap-245.img ├── pagemap-246.img ├── pagemap-50.img ├── pagemap-52.img ├── pagemap-95.img ├── pagemap-96.img ├── pagemap-97.img ├── pagemap-98.img ├── pages-10.img ├── pages-11.img ├── pages-12.img ├── pages-13.img ├── pages-1.img ├── pages-2.img ├── pages-3.img ├── pages-4.img ├── pages-5.img ├── pages-6.img ├── pages-7.img ├── pages-8.img ├── pages-9.img ├── pipes-data.img ├── pipes.img ├── pstree.img ├── reg-files.img ├── remap-fpath.img ├── route6-9.img ├── route-9.img ├── rule-9.img ├── seccomp.img ├── sigacts-101.img ├── sigacts-113.img ├── sigacts-122.img ├── sigacts-183.img ├── sigacts-1.img ├── sigacts-245.img ├── sigacts-246.img ├── sigacts-50.img ├── sigacts-52.img ├── sigacts-95.img ├── sigacts-96.img ├── sigacts-97.img ├── sigacts-98.img ├── signalfd.img ├── stats-dump ├── timerfd.img ├── tmpfs-dev-104.tar.gz.img ├── tmpfs-dev-109.tar.gz.img ├── tmpfs-dev-110.tar.gz.img ├── tmpfs-dev-112.tar.gz.img ├── tmpfs-dev-114.tar.gz.img ├── tty.info ├── unixsk.img ├── userns-13.img └── utsns-11.img 0 directories, 154 files
Восстановление контейнера просто: lxc start c1
Live migration
Живая миграция в своей основе похожа на Stateful stop/start, за исключением того, что каталог контейнера и конфигурация перемещается на другую машину.
lxc list c1
+------+---------+-----------------------+----------------------------------------------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+---------+-----------------------+----------------------------------------------+------------+-----------+ | c1 | RUNNING | 10.178.150.197 (eth0) | 2001:470:b368:4242:216:3eff:fe19:27b0 (eth0) | PERSISTENT | 2 | +------+---------+-----------------------+----------------------------------------------+------------+-----------+
lxc list s-tollana:
+------+-------+------+------+------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+-------+------+------+------+-----------+
lxc move c1 s-tollana:
lxc list c1
+------+-------+------+------+------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+-------+------+------+------+-----------+
lxc list s-tollana:
+------+---------+-----------------------+----------------------------------------------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+---------+-----------------------+----------------------------------------------+------------+-----------+ | c1 | RUNNING | 10.178.150.197 (eth0) | 2001:470:b368:4242:216:3eff:fe19:27b0 (eth0) | PERSISTENT | 2 | +------+---------+-----------------------+----------------------------------------------+------------+-----------+
Ограничения
Как сказано выше, контрольные точки и восстановление контейнера являются новой возможностью, над которой ведётся активная работа. Требуется обратная связь от людей, которые начинают пробовать её, но никто пока не рекомендует использовать этот новый функционал в продакшн.
Базовые возможности CRIU работают исправно в Ubuntu 16.04, но такие сложные вещи как проброс устройств, усложнённые сетевые сервисы или специальные конфигурации для хранилищ могут привести к ошибке в работе CRIU. Но всякий раз, когда возникает ошибка в работе механизма CRIU, она возникает в момент сохранения, а не восстановления. Контейнер продолжает свою работу, а снимок или миграция не выполняется с созданием журнала для будущей отладки. В редких случаях, CRIU не может восстановить контейнер, но исходный контейнер доступен, только остановлен. Вам придётся в ручную перезапустить его.
Отправка отчёта об ошибке
Разработчики LXD отслеживают ошибки, связанные с работой CRIU в Ubuntu, на Launchpad. Бо́льшая часть работы по исправлению ошибок будет проходить в upstream проекта CRIU или в ядре Linux.
Пожалуйста, включите следующую информацию:
- Команду, которую вы вызывали и она выдала ошибку
- Вывод lxc info (*)
- Вывод lxc info container-name
- Вывод lxc config show --expanded container-name
- Вывод dmesg (*)
- Вывод /proc/self/mountinfo (*)
- Вывод lxc exec container-name -- cat /proc/self/mountinfo
- Вывод uname -a (*)
- Содержимое /var/log/lxd.log (*)
- Содержимое /etc/default/lxd-bridge (*)
- Тарбол /var/log/lxd/container-name/ (*)
Если ошибка касается миграции, то вывод команд (отмечено *) нужно дать как из исходного сервера, так и целевого.
Оглавление цикла статей про LXD 2.0.
Предыдущая статья LXD 2.0: LXD в LXD [8/12].
Следующая статья LXD 2.0: LXD и Juju [10/12].
