xen-drbd/todo
Материал из Xgu.ru
< xen/drbd
< xen-drbd
< xen-drbd-install
Что можно было бы улучшить в скриптах xen-drbd и xen-drbd-install.
Содержание |
[править] xen-drbd-install
До релиза 0.1:
- реконфигурирование системы с помощью xen-drbd-install, грубо говоря, чтобы использовать её не только на этапе развёртывания, но и на этапе сопровождения, например, когда нужно расширить размер тома или добавить новую виртуальную машину
Операция remake принимает два аргумента:
- топология до и после
На основе разницы этих топологий выполняется изменение конфигурации.
Топология-до описывает текущее состояние системы. Предполагается, что ручных изменений в системе не было, а если они были, то соответствующие сделали и в топологии.
[править] xen-drbd
- поправить немножко синтаксис команд
- убрать название топологии из кода или сделать дефолтное название топологии и опционально его перекрывать аргументом -- сделано код, дока, дока
- возможность задавать любые параметры доменов в едином конфигурационном файле (как в Xentaur) -- сделано код, дока (и ещё теперь конфигурационные файлы называются без .py)
- проверка состояния drbd-устройств перед миграцией или после миграции домена (функция wait_for_sync)
- xen-drbd: автоматическая инсталляция пакетов для каждого домена, список задаётся в конфигурационном файле -- сделано код, дока
- xen-drbd: копирование модулей ядра во все домены на этапе разворачивания
- Графопостроитель схемы сети
- Кластеризация служб (об этом ниже)
- Агрегирование каналов
- Присмотреться, нужно ли делать mount /dev, /sys, /proc во время подготовки доменов
[править] Интересные идеи на будущее
[править] Несколько копий одного домена
Существуют службы, которые по своей природе готовы к кластеризации с целью распределения нагрузки или повышения отказоустойчивости. Сюда можно отнести службы без состояния (stateless), не требующие записи на диск, например, такие как маршрутизатор, VPN-сервер или фильтр пакетов, или службы, которые обладают средствами для организации работы с общей кластерной файловой системой.
В этом случае можно сделать так, чтобы соответствующий домен запускался в двух (или другом) количестве экземпляров. DRBD-устройства тогда переводятся в режим master-master. На каждом узле запускаются домены, которые объединяются в кластер собственными силами.
Такой подход имеет следующие преимущества:
- Распределение нагрузки между узлами;
- Сокращение времени восстановления в случае сбоя;
- Сохранение частичной функциональности у второго (запасного) узла, потерявшего связь с первым (основным).
Первое преимущество особенно существенно в том случае, если домен достаточно ресурсоёмок, и его не получается уравновесить другими доменами, перенесёнными на противоположную сторону связки.
Время восстановления после сбоев сокращается благодаря тому, что, в случае пропадения, домены, которые работали на уцелевшем сервере, не должны загружаться с нуля, а продолжают работать, как и работали.
В случае, если связь между серверами разорвалась, но оба сервера продолжают работать, можно сделать так, что продублированные домены будут работать независимо.
Рассмотрим подробнее поведение доменов в том случае, когда домены работают только в одном экземпляре, и в случае, когда они дублируются.
Без использования предлагаемой возможности (все домены в одном экземпляре):
С использованием предлагаемой возможности (некоторые домены дублируются):
Домены 2 и 5 запущены в двух экземплярах. Экземпляры домена 2 объединены в кластер (осуществляют запись на собственную файловую систему, но она кластерная); экземпляры домена 5 работают независимо (не осуществляют запись на файловую систему).
- a -- Нормальная работа. Домены распределены по хостам и работают. Хосты постоянно видят друг друга.
- b -- Хост host2 внезапно выключается. В первом случае должны запускаться с нуля домены 1, 2 и 5. А во втором случае только домен 1, а домены 2 и 5 продолжают работать, как и работали.
- c -- Потеряна связь между хостами host1 и host2. В первом случае на хосте host2 все домены гасятся, а на хосте host домены 1, 2 и 5 должны запускаться с нуля. Во втором случае на хосте host1 запускается только домен 1, и на хосте host2 продолжает работать домен 5.
Рассмотрим пример. Пусть у нас сервера виртуализации расположены один в центральном, а один в резервном офисе. В каждом офисе помимо самих серверов есть клиентские сети. В качестве примера домена 5 рассмотрим маршрутизатор.
В нормальном режиме маршрутизаторы работают в паре, объединённые с помощью протокола CARP (или другого аналогичного). Если второй узел внезапно выключается, работу продолжает один маршрутизатор, и он забирает на себя всех клиентов. Если разрывается связь между узлами, то все домены выключаются, за исключением маршрутизатора. Каждый маршрутизатор продолжает обслуживать своих пользователей, оставшихся в развалившейся сети.
В обычном случае, то есть, без дублирования домена, в развалившейся сети одна половина осталась бы без маршрутизатора.
Ещё немного необработанных черновиков
здесь:
