Назад | Перейти на главную страницу

KVM + DRBD реплицируется между двумя активно-пассивными серверами с ручным переключением

Мне нужно построить 2-узловое кластерное (-подобное?) Решение в активно-пассивном режиме, то есть один сервер активен, а другой пассивен (резервный), который постоянно получает данные, реплицируемые из активного. Виртуальные машины на основе KVM будут работать на активном узле.

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

Я видел этот учебник: https://www.alteeve.com/w/AN!Cluster_Tutorial_2#Technologies_We_Will_Use

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

Мне не удается найти информацию о том, как создать такую ​​конфигурацию. Если вы это сделали, поделитесь информацией / HOWTO в ответе.

Или, может быть, с узлами Linux можно построить высоконадежный автоматический переход на другой ресурс? Проблема с высокой доступностью Linux заключается в том, что, похоже, интерес к этой концепции вырос, как и 8 лет назад, и многие учебники к настоящему времени довольно старые. Это говорит о том, что на практике с HA могли быть серьезные проблемы, и некоторые / многие системные администраторы просто отказались от него.

Если это возможно, поделитесь информацией о том, как его создать, и о своем опыте работы с кластерами. в производстве.

Почему бы не использовать то, что проверено тысячами пользователей и доказало свою надежность? Вы можете просто развернуть бесплатный сервер Hyper-V, например, с помощью StarWind VSAN Free и без проблем получить настоящую высокую доступность. Ознакомьтесь с этим руководством: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-server-2016

У меня очень похожая установка с описанной вами настройкой: KVM-сервер с резервной репликой через активный / пассивный DRBD. Чтобы система была как можно более простой (и чтобы избежать автоматического разделения мозгов, т. Е. Из-за того, что мой клиент возился с сетью кластера), я также отказался от автоматического переключения кластера при отказе.

Системе более 5 лет, и у меня никогда не возникало никаких проблем. Моя настройка громкости следующая:

  • выделенный том RAID для хранения ВМ;
  • маленький объем наложения содержащие файлы конфигурации QEMU / KVM;
  • большие объемы для виртуальных дисков;
  • ресурсы DRBD, управляющие всем выделенным блочным устройством массива.

Я написал несколько сценариев оболочки, чтобы помочь мне в случае отказа. Вы можете их найти Вот

Обратите внимание, что система была спроектирована для максимальной производительности, даже за счет таких функций, как быстрые снимки и виртуальные диски на основе файлов (а не на основе томов).

Теперь, перестраивая аналогичную активную / пассивную настройку, я бы сильно склонился к использованию ZFS и непрерывной асинхронной репликации через send/recv. Это не блочная репликация в реальном времени, но ее более чем достаточно для более чем 90% случаев.

Если репликация в реальном времени действительно необходимо, я бы использовал DRBD поверх ZVOL + XFS; На самом деле, я испытал такую ​​установку + автоматический переключатель кардиостимулятора в своей лаборатории с большим удовлетворением. Если использование модулей 3rdy part (как ZoL) невозможно, я бы использовал ресурсы DRBD поверх lvmthin том + XFS.

Вы можете полностью настроить DRBD и использовать его исключительно вручную. Процесс совсем не должен быть сложным. Вы бы просто делали то, что делает кластер Pacemaker или Rgmanager, но вручную. По сути:

  • Остановить виртуальную машину на активном узле
  • Понизить DRBD на активном узле
  • Продвигайте DRBD на одноранговом узле
  • Запустите виртуальную машину на одноранговом узле

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

Могу заверить, что стек Linux HA (corosync и pacemaker) все еще активно развивается и поддерживается. Многие руководства старые, программное обеспечение существует уже 10 лет. Когда все сделано правильно, нет никаких серьезных проблем или проблем. Он не заброшен, но уже не «новый и увлекательный».

Активные / пассивные кластеры все еще широко используются во многих местах и ​​работают в производственной среде. Пожалуйста, найдите ниже наши производство установки, он работает нормально, и вы можете позволить ему работать в ручном режиме (orchestrate=start) или включить автоматическое переключение при отказе (orchestrate=ha). Мы используем zfs для получения преимуществ от zfs send / receive и zfs snapshots, но также можно использовать drbd, если вы предпочитаете синхронную репликацию.

Предпосылки:

  • 2 узла (в моей установке 2 физических узла на расстоянии 400 километров)
  • внутренние диски
  • 1 пул zfs на каждом узле
  • растянутый vlan (в моей настройке мы используем "vrack" у хостинг-провайдера OVH)

Шаги:

  • установить агент opensvc на обоих узлах (https://repo.opensvc.com)
  • формируют кластер opensvc (необходимо 3 команды, описанные в скринкасте на https://www.opensvc.com)
  • создать корневое доверие ssh между обоими узлами
  • создать 1 службу opensvc для каждого гостя kvm [файл конфигурации службы ниже]

root @ node1: ~ $ svcmgr -s win1 конфигурация печати

[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start

[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs

[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true

[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h

Несколько объяснений:

  • сервис называется "win1" и каждый {svcname} в файле конфигурации службы есть ссылка на фактическое имя службы (win1)
  • запуск службы выполните следующие действия:
    • смонтировать набор данных zfs data/win1 на точке монтирования /srv/win1
    • запустить контейнер kvm win1
  • ресурс sync#1 используется для объявления асинхронной репликации набора данных zfs на подчиненный узел (данные / win1 на node1 отправляются в data / win1 на node2), в этом примере один раз в 12 часов (отправка / получение zfs управляется агентом opensvc)
  • Агент opensvc также имеет дело с репликацией конфигурации kvm qemu и определяет ее, когда служба перемещается на подчиненный узел

Некоторые команды управления:

  • svcmgr -s win1 start запустить службу
  • svcmgr -s win1 stop остановить службу
  • svcmgr -s win1 stop --rid container#0 остановить контейнер, на который ссылается контейнер № 0 в файле конфигурации
  • svcmgr -s win1 switch переместить службу на другой узел
  • svcmgr -s win1 sync update запускать инкрементную копию набора данных zfs
  • svcmgr -s win1 sync full запускать полную копию набора данных zfs

Некоторым службам, которыми я управляю, также требуются моментальные снимки zfs на регулярной основе (ежедневно / еженедельно / ежемесячно) с сохранением, в этом случае я добавляю следующий фрагмент конфигурации в файл конфигурации службы, и агент opensvc выполняет эту работу.

[sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d

[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d

[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d

По запросу я также добавляю одну конфигурацию lvm / drbd / kvm:

конфигурация ресурса drbd /etc/drbd.d/kvmdrbd.res :

resource kvmdrbd {
    device /dev/drbd10;
    disk /dev/drbdvg/drbdlv;
    on node1 {
        address 1.2.3.4:12345;
        meta-disk internal;
    }
    on node2 {
        address 4.3.2.1:12345;
        meta-disk internal;
    }
}

Файл конфигурации службы opensvc /etc/opensvc/kvmdrbd.conf :

root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start

[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true

[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}

[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true

[container#0]
type = kvm
name = {svcname}
shared = true

[sync#i0]
schedule = @1440

[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg

Некоторые пояснения:

  • в моей настройке я реплицирую lvm lv с помощью drbd. Создаю файловую систему на блочном устройстве drbd. В этой файловой системе я создаю 1 плоский файл на диск, который хочу представить гостю kvm.
  • disk#1 : lvm vg, на котором размещен большой логический том. должно быть не менее 5 ГБ.
  • disk#2 : диск drbd, на который указывает имя ресурса drbd. Если служба opensvc называется "foo", у вас должен быть /etc/drbd.d/foo.res. Или измените параметр disk # 2.res в файле конфигурации службы.
  • fs#0 : основная файловая система, в которой размещены все файлы на диске для гостя kvm
  • container#0 : гость kvm, то же имя, что и служба opensvc в примере. агент должен иметь возможность dns разрешить гостя kvm, чтобы выполнить проверку ping, прежде чем разрешить запуск службы (если ответ ping, гость kvm уже где-то запущен, и запускать его не рекомендуется. Обеспечена защита от двойного запуска агент opensvc)
  • standby = true : означает, что этот ресурс должен оставаться включенным, когда служба работает на другом узле. В нашем примере это необходимо, чтобы drbd работал нормально.
  • shared = true : https://docs.opensvc.com/latest/agent.service.provisioning.html#shared-resources

В настоящее время я использую очень похожую систему. 2 сервера, один активный, один резервный, и на обоих работает несколько виртуальных машин. База данных реплицируется, и файловые серверы постоянно синхронизируются с rsync (но только в одном направлении). В экстренных случаях обслуживается вторичный сервер. Была идея использовать Pacemaker и Corosync, но, поскольку это должно быть 100%, у меня не хватило смелости экспериментировать. Моя идея - NginX наблюдает за серверами. Это может быть сделано, потому что я использую веб-приложение, но в вашем случае я не знаю, сможете ли вы его использовать. DRBD для меня беспорядок. Предыдущие серверы использовали его, и хотя он, казалось, работал, мне казалось, что я пытаюсь разрезать человеческое тело.

Проверьте это, это может вам помочь: http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs

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