Kemari - Об ОС *Nix - Системное администрирование - Каталог статей - Архив документации и мануалов для админов

Четверг, 08.12.2016, 13:53
Приветствую Вас Гость | RSS
Мой сайт
Главная
Регистрация
Вход
Форма входа

Меню сайта

Категории раздела
Об ОС Windows [137]
В категории размещаются статьи, касающщиеся операционных систем от Microsoft.
Об ОС *Nix [198]
В данной категории собраны статьи об ОС семейства Unix/Linux/FreeBSD/...
Справочные материалы [351]
Справка по всему разделу.
Виртуализация и Облака [46]
Networks & Routing [86]
DataBases [22]

Наш опрос
Оцените мой сайт
Всего ответов: 193

Статистика

Онлайн всего: 2
Гостей: 2
Пользователей: 0

Главная » Статьи » Системное администрирование » Об ОС *Nix

Kemari

Kemari


Kemari failover.png

Технология 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).

Синхронизация состояния доменов при помощи Kemari

Второй подход, 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>

После этого домен должен продолжить работу на втором получателе.

[править] Производительность

Производительность дисковых и сетевых операций при использовании Ethernet и Inifiniband, с Kemari и без

Производительность доменов из-за необходимости синхронизации падает приблизительно в несколько раз в зависимости от спектра выполняющихся операций и типа соединения между узлами.

На рисунке представлены нормированные результаты замера производительности для кластера из двух двухпроцессорных (Xeon 3GHz) серверов DL360G5, соединённых при помощи Infiniband или Gigabit Ethernet. Измерения производились при помощи iozone и netperf. Результаты представлены в [2].

[править] Название

Вообще, Kemari (蹴鞠) — хитрая разновидность футбола, в которой нужно продержать мяч как можно дольше в воздухе, так чтобы он не коснулся земли. Игра была популярна в стародавние времена (в период Хейан, на рубеже первого и второго тысячелетий) и сейчас становится популярной снова (якобы в неё даже играл Дж. Буш старший, в ходе одного из своих визитов в Японию).

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

[править] Дополнительная информация

  • [3] Remus Fault Tolerance - аналогичный проект, впоследствии включенный в код XEN (начиная с версии 4.0).


Xen
Xen


Виртуализация и паравиртуализация
Эмуляция | Виртуализация | Паравиртуализация | Рекурсивная виртуализация
Паравиртуальные драйверы | Виртуализация ввода/вывода

Общие вопросы по Xen
Аппаратные требования Xen | Поддержка Xen операционными системами | Поддерживаемые аппаратные архитектуры |
Примеры использования Xen | Сравнение виртуальных машин |
Хостинг на Xen
Альтернативы Xen

свободные: KVM | OpenVZ | VServer | QEMU | VirtualBox
проприетарные: Hyper-V | VMware ESX Server

Технические вопросы
Инсталляция Xen | Конфигурационный файл домена
ОС в Xen: Linux small icon.png Linux | Solaris small icon.png OpenSolaris | Freebsd small icon.png FreeBSD | Openbsd small icon.png OpenBSD | Netbsd small icon.png NetBSD | Windows xp small icon.png Windows XP | Windows vista small icon.png Windows Vista
Устройства: Блочные | USB | SCSI | Сеть | PV-драйверы для Linux | PV-драйверы для Windows | Консоль

Распределение ресурсов между доменами | Перенос системы внутрь Xen | HVM -> PV

Управление и кластеризация | Enomalism | Xen+DRBD | Ganeti | Convirt 2.0


Источник: http://xgu.ru/wiki/Kemari
Категория: Об ОС *Nix | Добавил: admin (07.08.2011)
Просмотров: 978 | Комментарии: 1 | Теги: lvm, Cluster, xen, config, Linux, gfs | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2016