Назад | Перейти на главную страницу

Xen live motion

Я изучаю XenServer от Citrix и (с двумя коллегами) сравниваю его с VMware ESX и Microsoft HyperV.

По нашим тестам, живая миграция Xen использует меньше ресурсов, чем ESX от VMware, и я хотел бы знать, почему это так. Я нашел прошлогоднюю статью, в которой упоминается статья 2005 года, в которой объясняется, что на самом деле происходит со страницами / памятью во время живой миграции.

Это отрывок из того статья о переносе памяти:

Фаза передачи - исходная виртуальная машина продолжает работать, пока определенные страницы передаются по сети в новое место назначения. Для обеспечения согласованности страницы, измененные во время этого процесса, необходимо повторно отправить.

Фаза остановки и копирования Исходная виртуальная машина останавливается, страницы копируются на целевую виртуальную машину, а затем запускается новая виртуальная машина.

Фаза извлечения Новая виртуальная машина выполняется, и, если она обращается к странице, которая еще не была скопирована, эта страница получает ошибку («извлекает») по сети из исходной виртуальной машины.

Мне было интересно, происходит ли передача памяти так же, как 4 года назад.

Я не эксперт по миграции Xen и использую сервер Xen с открытым исходным кодом. По моему опыту, сервер Xen очень эффективен при миграции, пока ваш уровень хранения работает быстро - по нашему опыту, образы дисков в виде файлов на томе ocfs2 или (не дай бог) монтирование NFS были намного медленнее, чем блочные устройства в SAN с разделяемый блокирующий том на монтировании NFS. У нас не было проблем с повреждением диска, но мы, как правило, делаем снимки состояния (как LVM2, так и состояния виртуальной машины), прежде чем мы начнем миграцию на очень активной системе, чтобы быть уверенным.

Согласно «Запуск Xen: Практическое руководство по искусству виртуализации» Мэтьюза, Доу и др., Prentice Hall 2008, стр. 484,

Реализация динамической миграции Xen включает новое использование итеративного многопроходного алгоритма, который последовательно передает гостевую память виртуальной машины. После того, как исходная виртуальная машина и виртуальная машина назначения сначала согласовывают, чтобы убедиться, что ресурсов на принимающей машине достаточно, выполняется первоначальный проход через гостевую память, при этом каждая страница передается в место назначения. На каждой последующей итерации отправляется только гостевая память, которая была загрязнена за это время. Этот процесс выполняется до тех пор, пока либо оставшееся количество грязных страниц не станет достаточно малым (sic), чтобы оставшиеся страницы можно было передать быстро, либо количество грязных страниц, оставшихся для передачи на каждом проходе, не уменьшится. В этот момент система фактически приостанавливается, и окончательное состояние отправляется на новый хост, а передача управления на новую физическую машину завершается.

Похоже, что это похоже на список шагов, который вы описали выше, с добавлением итераций. Обратите внимание, что машина может выполнять ввод-вывод в двух местах с текущим состоянием динамической миграции.

В отличие от VMWare и HyperV, XenServer хорош тем, что множество людей уже использовали его и изо всех сил пытались сломать его десятью способами с воскресенья в очень серьезных производственных средах. Живая миграция - это новость для нас, и мы пока не делаем ее в производственной среде, потому что у нас есть проблемы с избыточностью (на данный момент нетривиально масштабировать до n машин из-за наличия наших общих разделов данных на томах ocfs2), но в нашем тестовые среды, мы повсюду развлекались, гоняя машины.