Kemari
Материал из Xgu.ru
Технология Kemari позволяет синхронизировать состояние памяти и устройств для исполняющегося домена Xen. В результате домен работает медленнее, но достигается истинная отказоустойчивость. Если один из узлов выходит из строя, виртуальная машина продолжает работать на втором как ни в чём не бывало.
Kemari для своей работы не требует ни специального оборудования, ни модификации гостевых операционных систем и прикладного программного обеспечения.
Релиз Kemari 1.0 состоялся в 25 ноября 2008 [1].
Технология пока не доступна в коде Xen. Предполагается, что она появится в Xen 3.4.
Содержание |
[править] Идея
Система виртуализации Xen часто используется при построении отказоустойчивых систем. Наиболее часто это делается так: создаётся кластер виртуализации, имеющий или внешнее хранилище, отказоустойчивость которого обеспечивается другими средствами, или каждым узлом используется локальное хранилище, задублированное с локальными хранилищами других узлов (подробнее, например, здесь: Xen поверх DRBD). Виртуальные машины распределяются по узлам кластера; при выходе любого узла из строя, работавшие на нём виртуальные машины автоматически распределяются по уцелевшим узлам, и запускаются на них. Состояние оперативной памяти всех виртуальных машин, находившихся на узле вышедшем из строя, теряется. Для пользователей это выглядит как перезагрузка. При планомерном выводе узла из эксплуатации такого не происходит, машины мигрируют прозрачно для пользователей.
Узлы в кластере виртуализации выходят из строя не часто, однако нельзя говорить об истинной отказоустойчивости, если есть вероятность, что могут потеряться данные пользователей, пусть даже они находятся только в оперативной памяти.
Добиться истинной отказоустойчивости можно, если иметь по две копии любого домена в памяти, расположенные на разных узлах, так чтобы в случае отказа одного из них продолжить работу на втором. Домен активно выполняется на одном из узлов, а на втором только поддерживается его актуальная копия.
Есть несколько подходов к решению вопроса синхронизации состояний доменов. Первый, так называемый lock-stepping, заключается в том, что внешние события запоминаются в одном из доменов, а потом воспроизводятся во втором. Этот подход позволяет добиться очень хорошей синхронизации, но он достаточно сложно реализуем на практике, в особенности при расхождении в оборудовании (подробнее: Thomas C. Bressoud et al. Hyperfisor-based fault tolerance. ACM Transactions on Computer Systems, 4(1):80-107, February 1996).
Второй подход, continuous checkpointing, заключается в том, что машины постоянно синхронизируются путём копирования состояние первой машины на вторую. Этот подход намного проще в реализации, но он очень неэффективен с точки зрения производительности (подробнее: Brendan Cully et al. Remus: High availability via asynchronous virtual machine replication. In NSDI'08).
В Kemari предложен промежуточный подход: синхронизация выполняется только в моменты наступления внешних событий. Синхронизация машин выполняется только тогда, когда домен хочет выполнить обмен данными с диском или по сети.
Например, когда виртуальная машина обращается к хранилищу, Kemari приостанавливает её, синхронизирует состояние машин, а потом обрабатывает обращение к хранилищу.
В случае когда сбоит первая машина, система переключается на вторую и продолжает с последнего синхронизированного состояния. Это состояние соответствует последнему моменту обращения к сети или к диску. То есть, для пользователя это происходит абсолютно прозрачно.
[править] Использование
Для использования Kemari необходимо выполнять сборку Xen из исходников.
Kemari доступна в виде патчей для гипервизора Xen и ксенифицированного ядра Linux. Требуется получить исходный код Linux и Xen, наложить соответствующие патчи и выполнить сборку.
Патчи накладываются на определённую ревизию Xen и ядра.
С Kemari могут работать только HVM-домены, поскольку она использует механизм Shadow Page Tables. При этом в домене должны быть проинсталлированы паравиртуальные драйверы, модифицированные специальным образом (патч доступен в составе Kemari). Для Windows можно использовать паравиртуальные драйверы Джеймса Харпера.
[править] Инсталляция
Установить Linux.
Скачать исходный код Xen:
$ hg clone -r 18430 http://xenbits.xensource.com/xen-3.3-testing.hg
Скачать исходный код ядра Linux, подготовленного для работы внутри домена 0 Xen:
$ hg clone -r 707 http://xenbits.xensource.com/linux-2.6.18-xen.hg
Скачать патчи Kemari:
$ wget http://www.osrg.net/kemari/download/kemari-v1-xen-20081120.patch $ wget http://www.osrg.net/kemari/download/kemari-v1-linux-20081120.patch
Наложить патчи Kemari:
$ cd xen-3.3-testing.hg
$ patch -p1 < /where/you/put/patch/kemari-v1-xen-20081120.patch
$ cd ..
$ cd linux-2.6.18-xen.hg
$ patch -p1 < /where/you/put/patch/kemari-v1-linux-20081120.patch
$ cd ..
Собрать Xen и ядро:
$ cd xen-3.3-testing.hg
$ make dist
# sudo make install
Настроить загрузчик GRUB, точно также как и для обычного Xen.
Создать гостевой HVM-домен. Домен должен располагаться на внешнем хранилище (на AoE или iSCSI).
Установить паравиртуальные драйверы внутрь гостевого домена (обязательно нужно использовать драйверы из Xen-3.3-testing. Более ранние работать не будут).
[править] Запуск и проверка
Выполните миграцию HVM-домена, используя опцию --kemari. Команда выглядит точно также как обычная команда миграции, только с дополнительной опцией:
# xm migrate <domid> <destination hostname> --kemari &
Например так:
# xm migrate 1 host01.example.jp --kemari &
Поскольку команда не завершится до тех пор, пока не завершится домен, её лучше запускать через nohup или с использованием GNU Screen.
Ждать, пока домен не разморозится. Проверять разморозился домен или нет лучше всего внутри программы xentop:
# xentop
Вы увидите как состояние меняет с ----p- на --b--- или -----r.
Определите PID процесса xc_kemari_restore на втором хосте:
destination# ps ax| grep xc_kemari_restore
Можно выключать.
Нажимаете клавишу reset на первой машине, а на второй машине после этого отправляете сигнал HUP процессу xc_kemari_restore:
# kill_source_machine.sh
destination# kill -HUP <PID of xc_kemari_restore>
После этого домен должен продолжить работу на втором получателе.
[править] Производительность
Производительность доменов из-за необходимости синхронизации падает приблизительно в несколько раз в зависимости от спектра выполняющихся операций и типа соединения между узлами.
На рисунке представлены нормированные результаты замера производительности для кластера из двух двухпроцессорных (Xeon 3GHz) серверов DL360G5, соединённых при помощи Infiniband или Gigabit Ethernet. Измерения производились при помощи iozone и netperf. Результаты представлены в [2].
[править] Название
Вообще, Kemari (蹴鞠) — хитрая разновидность футбола, в которой нужно продержать мяч как можно дольше в воздухе, так чтобы он не коснулся земли. Игра была популярна в стародавние времена (в период Хейан, на рубеже первого и второго тысячелетий) и сейчас становится популярной снова (якобы в неё даже играл Дж. Буш старший, в ходе одного из своих визитов в Японию).
В системах виртуализации роль мяча играет виртуальная машина, которую нужно продержать как можно дольше в рабочем состоянии, чтобы она не упала.
[править] Дополнительная информация
- [3] Remus Fault Tolerance - аналогичный проект, впоследствии включенный в код XEN (начиная с версии 4.0).
- Kemari Project (англ.) — домашняя страница проекта
- Kemari Architecture (англ.)
- Kemari on XenSummit (англ.) — презентация Kemari
- Kemari - High Availability 2.0 (англ.) — несколько слов о Kemari и похожих проектах в блоге Xen.org
- Shadow page table question (англ.) и An enlightenment about shadow page table (англ.) — некоторая информация о Shadow Page Tables, механизме управления адресацией памяти, который лежит в основе Kemari
 |
|
|---|
