LINUX.ORG.RU
Новости — Open Source  

Xen поверх DRBD: теория и скрипты

 ,


0

0
Система виртуализации Xen и система репликации блочных устройств DRBD позволяют сделать из двух обычных серверов отказоустойчивую систему виртуализации, внутри которой смогут работать виртуальные сети, имеющие произвольные топологии и состоящие из самых разнообразных систем.

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

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

>>> Архив скриптов

>>> Репозиторий скриптов

>>> Подробности

★

Проверено: Shaman007 ()
← Закончена русификация ГИС GRASS
Названы победители NetBeans Innovators Grant contest! →
Как всегда респект и спасибо Игорю за проделаную работу!
Deleted
()

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

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

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

Camel ★★★★★
()
xgu.ru
хороший ресурс
anonymous
()
Ответ на: Отказонеустойчивость. от Camel
> для пользователей виртуальных систем незапланированный выход из строя одного из физических узлов будет выглядеть не более чем перезагрузка

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

anonymous
()
Ответ на: комментарий от anonymous
Если бы её не было, выход из строя обозначал бы выход из строя, а не перезагрузку
anonymous
()
Для меня статья полезна, спасибо автору(ам).

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

ximeric ★
()
Обмен опытом:
Неасколько серверов, транками соединенные с коммутатором, 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' ]
...
eda ★
()
> незапланированный выход из строя одного из физических узлов будет выглядеть не более чем перезагрузка, а запланированный — будет вообще не заметен.

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

vadiml ★★★★★
()
Ответ на: комментарий от vadiml
Ну а что? Работает, значит в строю; нет -- значит не в строю :)
devigor ★
() автор топика
Ответ на: комментарий от ximeric
это паллиатив для "простых случаев". те для сиюминутных задач("песочница" итп) в иднастриал продакшне - ессно, не Ъ. не только из-за производительности.

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

anonymous
()
Ответ на: комментарий от ximeric
Для доменов, где интенсивный обмен с диском это можно не использовать. Для остальных получается очень удобно
devigor ★
() автор топика
Ответ на: комментарий от anonymous
aoe можно было и там использовать.

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

Это не подходит всё для суперинтенсивных нагрузко в любом случае,
хотя бы из-за DRBD
devigor ★
() автор топика
Ответ на: комментарий от anonymous
> это паллиатив для "простых случаев". те для сиюминутных задач("песочница" итп) в иднастриал продакшне - ессно, не Ъ. не только из-за производительности.

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

ximeric ★
()
Ответ на: комментарий от ximeric
Если уж на то пошло, то есть идея сделать на разных физических target'ах одинаковые IQN. Или софт target'а не даст?
ximeric ★
()
Ответ на: комментарий от ximeric
Для чего?

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

Здесь это так и сделано, IQN один, просто он внутри мигрирующего домена
devigor ★
() автор топика
Ответ на: комментарий от devigor
> Здесь это так и сделано, IQN один, просто он внутри мигрирующего домена

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

ximeric ★
()
Ответ на: комментарий от ximeric
Я имел в виду: решается та же задача.

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

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

devigor ★
() автор топика
Ответ на: комментарий от jackill
Дистрибутив Debian, версия Xen 3.2.1, последнее, что есть в репозитории. 3.3 пока, к сожалению, нет
devigor ★
() автор топика
Ответ на: комментарий от devigor
Хорошая статейка!

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

hse ★
()
DRBD тормоз. Использовали его как раз для связки с xen. В итоге выкинули, ибо работать с ним под нагрузкой не реально.
anonymous
()
Ответ на: комментарий от hse
В принципе, это мысль интересная.

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

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

Другой, более простой способ добиться
того чтобы домены не перезагружались,
просто запускать две копии их
и кластеризовать их внутренними силами.
devigor ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Закончена русификация ГИС GRASS
Open Source
Названы победители NetBeans Innovators Grant contest! →