Как всегда респект и спасибо Игорю за проделаную работу!

Отказонеустойчивость.

>Отказоустойчивость означает здесь то, что для пользователей виртуальных систем незапланированный выход из строя одного из физических узлов будет выглядеть не более чем перезагрузка, а запланированный — будет вообще не заметен.

То есть отказоустойчивости-то не сильно прибавилось? В случае внезапного выключения одной физической ЭВМ виртуальные отправятся в перезагрузку?

xgu.ru
хороший ресурс

Да, отправятся.

Когда выйдет Kemari, то не будут отправляться.

> для пользователей виртуальных систем незапланированный выход из строя одного из физических узлов будет выглядеть не более чем перезагрузка

Мдааа, "отказоустойчивость" на высоты. Что есть, что нету.

Если бы её не было, выход из строя обозначал бы выход из строя, а не перезагрузку

Для меня статья полезна, спасибо автору(ам).

Однако идея экспорта iSCSI из гостевого домена, пусть даже аргументированно - жуть.

Обмен опытом:
Неасколько серверов, транками соединенные с коммутатором, csync2 синхронизирует конфиги. имеджи систем храняться в SAN.

Допилил скрипты Xen поднятия сетевых интерфейсов , позволяющий погружать виртуальные машины в разные виланы. Это позволяет виртуальные машины из разных сетей с разной политикой безопаснсоти держать на одном сервере. Согласование политик безопасности делать привычно на внешнем firewall-е.

Кроме этого сделал автосоздание FS (для свапа или tmp ) - использую локалдьные диски под LVM-ом.

Пример:
...
vif = [ 'mac=00:44:44:12:82:67, bridge=xenVL204', ]
disk = [ ....,'phy:/dev/xenauto/mail-swap-512,xvda2,w' ]
...

> незапланированный выход из строя одного из физических узлов будет выглядеть не более чем перезагрузка, а запланированный — будет вообще не заметен.

т.е. второй -- это запланированный выход из строя

А что жуть-то?

Из-за нагрузки?

Ну а что? Работает, значит в строю; нет -- значит не в строю :)

> Допилил скрипты Xen поднятия сетевых интерфейсов

Обмен опытом: :-)

Можно было и не допиливать: http://renial.net/weblog/2007/02/27/xen-vlan/, скрипты network-bridge-vlan и network-multi-vlan.

> А что жуть-то? Из-за нагрузки?

Конечно, других препятствий (пока) не вижу.

это паллиатив для "простых случаев". те для сиюминутных задач("песочница" итп) в иднастриал продакшне - ессно, не Ъ. не только из-за производительности.

p.s. а потом что ? [S]ATA over IP ? другие, "более raw"-аналоги ? :)

Для доменов, где интенсивный обмен с диском это можно не использовать. Для остальных получается очень удобно

кому интересно посмотрите ganeti

aoe можно было и там использовать.

Короче эта фишка нужна только для того чтобы
третий, четвёртый и прочие узлы переключить
на тот узел, где сейчас drbd в primary,
прозрачно и без участия админа.

Это не подходит всё для суперинтенсивных нагрузко в любом случае,
хотя бы из-за DRBD

И xenfire (для разворачивания)

> это паллиатив для "простых случаев". те для сиюминутных задач("песочница" итп) в иднастриал продакшне - ессно, не Ъ. не только из-за производительности.

Не понял. В статье даётся описание DRBD для песочниц? Где б такую песочницу увидеть...

> Можно было и не допиливать: http://renial.net/weblog/2007/02/27/xen-vlan/

Опс.. но процесс мне тоже нравился ;-)

Если уж на то пошло, то есть идея сделать на разных физических target'ах одинаковые IQN. Или софт target'а не даст?

Для чего?

Для того чтобы в случае выключения одного
узла работа велась со вторым?

Здесь это так и сделано, IQN один, просто он внутри мигрирующего домена

> Здесь это так и сделано, IQN один, просто он внутри мигрирующего домена

Здесь не так - именно, что "внутри мигрирующего домена".

Я имел в виду: решается та же задача.

Мне тоже очень интересно можно ли так сделать,
как вы говорите. Тогда можно было бы обойтись без экспорта
изнутри домена.

И ещё интересно, можно ли так сделать с AoE.

Достаточно привлекательная идея, между прочим..

Какая версия xen использовалась и на каком дистрибутиве?

Дистрибутив Debian, версия Xen 3.2.1, последнее, что есть в репозитории. 3.3 пока, к сожалению, нет

Какая именно идея привлекательная?

Хорошая статейка!

Жаль что при сбое хоста виртуальные машины перезагружаются. А если чекпоинты использовать и их тоже по DRBD мирорить то кажись можно сразу на другом хосте поднять все виртуальные машины, да данные после последнего чекпоинта пропадут. Или на эти чекпоинты уйдет много ресурсов и это не выгодно будет?

DRBD тормоз. Использовали его как раз для связки с xen. В итоге выкинули, ибо работать с ним под нагрузкой не реально.

В принципе, это мысль интересная.

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

А эта идея с чекпоинтами реального времени
реализуется в проекте Kemari.

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