Kir Kolyshkin Голосов: 1 Адрес блога: http://k001.livejournal.com/ Добавлен: 2008-02-19 12:45:30 блограйдером Lurk

Эффективная живая миграция с ploop write tracker

2012-05-31 02:03:00 (читать в оригинале)

(Обычно я пишу по-английски, а потом, если есть время и желание, на русский перевожу. Тут решил в качестве смелого эксперимента сделать наоборот. В тексте встречаются английские слова, извините, как смог. Этот текст должен скоро появиться в ru_openvz)

Я тут недавно отдыхал на солнечном побережье гостеприимной Турции, и по ночам, вместо того, чтобы дегустировать спиртные напитки или отдыхать после утомительного дня на пляже, в холле отеля, где работал вайфай, доделывал (и доделал) миграцию контейнеров на пилупе. Для любознательных, это почти все коммиты в ploop вот отсюда и ещё верхние 14 коммитов в vzctl вот отсюда. Хочу рассказать про весь этот функционал.

Начну издалека, а именно с того, как вообще реализована миграция, то есть перенос контейнера с одного OpenVZ сервера на другой. Команда vzmigrate -- это скрипт на шелле, он обычно делает следующее (упрощённо):
1. Проверяет, что можно попасть на другой сервер по ssh без пароля, и что там нет контейнера с таким CTID, и что-то ещё в том же духе.
2. Делает rsync /vz/private/$CTID на другой сервер
3. Останавливает контейнер
4. Делает второй rsync /vz/private/$CTID на другой сервер
5. Запускает контейнер на другом сервере
6. Удаляет его локально.

Два запуска rsync нужны для того, чтобы первый перенёс большинство данных, пока контейнер всё ещё работает, а второй -- перенёс то, что изменилось за время между работой первого и стопом контейнера.

Теперь, если нам нужна живая миграция (это опция --online для vzmigrate), то (опять слегка упрощённо) вместо стопа делается vzctl chkpnt, а вместо старта -- vzctl restore. Результат -- ваш контейнер переехал, а пользователи ничего не заметили (процессы не останавливаются, а всего лишь "замирают" на несколько секунд, TCP-соединения тоже переезжают, IP не меняется и т.п., в общем, немножко магии и никакого мошенничества).

Таким примерно образом всё это работало, и все были довольны. А потом появился ploop, и выяснилось, что миграция с ploop не работает. Нашлось даже несколько причин, почему (например, для копирования образов ploop нельзя использовать --sparse, потому что ploop не умеет работать с файлами, в которых есть "дырки"). Но главное, что в процессе разбора выяснилось, как правильно мигрировать ploop: не через rsync, а с помощью ploop copy.

ploop copy -- это механизм эффективного копирования образа ploop с использованием встроенного в ploop механизма слежения за записью (write tracker). Один процесс ploop copy вычитывает с диска блоки данных образа и пишет их в stdout (предваряя каждый блок маленьким заголовочком из метки, позиции блока на диске и его размером), то есть в "трубу", а второй процесс читает их из stdin и скидывает на диск. Добавляем между ними ssh $DEST, и вуаля.

Скажете, что почти то же самое и cat умеет делать. Разница в том, что перед тем, как начать передавать данные, ploop copy просит у ядра включить write tracker, и ядро начинает запоминать блоки данных, в которые пишут. После того, как все блоки переданы, ploop copy вежливо интересуется у ядра списком модифицированных блоков, и передаёт их снова, а ядро в это время составляет новый список. Процесс повторяется несколько раз, и список блоков становится всё меньше и меньше. Через какое-то количество итераций (или этот список становится пустым, или перестаёт уменьшаться, или просто мы решаем, что уже случилось слишком много итераций) ploop copy запускает некую внешнюю команду, которая должна вызвать прекращение всякой дисковой активности контейнера. Команда эта vzctl stop для миграции обычной, или vzctl chkpnt для "живой"; действительно, остановленный или замороженный контейнер на диск писать уже ничего не может. После этого мы ещё раз спрашиваем у ядра список модифицированных блоков и передаём их в трубу, потом ещё раз спрашиваем и убеждаемся, что список пуст (а иначе "прекращающая" команда не сработала и всё пропало), и посылаем в трубу признак конца передачи. Вот так устроен передающий процесс.

Принимающий процесс ploop copy устроен просто -- он вычитывает блоки из трубы и пишет их в заданное место файла. Желающие посмотреть на код и той, и другой стороны могут пройти вот сюда.

Так вот, в вышеприведённой схеме миграции ploop copy используется вместо второго rsync (пункты 3 и 4). Замечу, что это гораздо эффективнее, потому как rsync пытается понять, какие файлы изменились и в чём, а ploop copy просто спрашивает про это у ядра, причём поскольку процесс "спросили-скопировали" итеративный, контейнер останавливается или замораживается как можно позже и, даже если контейнер активно пишет на диск, период времени, когда он остановлен, минимален.

Я ради интереса сделал простой и ненаучный тест, запустив od -x /dev/urandom > file в контейнере и помигрировав его туда-сюда. Получил время ploop copy после запуска стоп-команды чуть больше секунды, а общее время, пока контейнер был заморожен -- чуть меньше трёх секунд. Примерно такие же цифры получается для simfs с rsync, но только если контейнер ничего не делает. А если такой же мигрировать, с "писателем" внутри, то время сразу увеличивается до 13-16 секунд. Не претендую на точность измерений, мерял как попало, OpenVZ стояла внутри параллельских VMок, на ноде что-то ещё делали...

И последнее. Всё это доступно сейчас только из гита (клонируйте, собирайте, пробуйте) и будет включено в релиз ploop-1.3 и vzctl-3.3.