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. На каждом узле запускаются домены, которые объединяются в кластер собственными силами.

Такой подход имеет следующие преимущества:

  1. Распределение нагрузки между узлами;
  2. Сокращение времени восстановления в случае сбоя;
  3. Сохранение частичной функциональности у второго (запасного) узла, потерявшего связь с первым (основным).

Первое преимущество особенно существенно в том случае, если домен достаточно ресурсоёмок, и его не получается уравновесить другими доменами, перенесёнными на противоположную сторону связки.

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

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

Рассмотрим подробнее поведение доменов в том случае, когда домены работают только в одном экземпляре, и в случае, когда они дублируются.

Без использования предлагаемой возможности (все домены в одном экземпляре):

Xen-drbd-clustered-domains1.png

С использованием предлагаемой возможности (некоторые домены дублируются):

Xen-drbd-clustered-domains2.png

Домены 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 (или другого аналогичного). Если второй узел внезапно выключается, работу продолжает один маршрутизатор, и он забирает на себя всех клиентов. Если разрывается связь между узлами, то все домены выключаются, за исключением маршрутизатора. Каждый маршрутизатор продолжает обслуживать своих пользователей, оставшихся в развалившейся сети.

В обычном случае, то есть, без дублирования домена, в развалившейся сети одна половина осталась бы без маршрутизатора.


Ещё немного необработанных черновиков здесь: