Если появится третий, через некоторое время возникнет split-btain

Дадада, эт я в курсе.

Чтобы обезопасить себя можно попробовать заюзать кворум, но опять же активных реплик должно быть не больше двух

Мне вообще писать надо только в 1 месте, в других читать

Может я вообще не так делаю и мне brbd нафиг не надо

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

Например в твоём случае я посоветовал бы high available nfs сервер, вместо ocfs и drbd с allow-two-primaries

Не хочу я nfs, было уже.

И работало мягко скажем не оч

Сомневаюсь что такая схема сильно лучше работать будет

Не попробуешь не узнаешь

Точно

Сделал кластер NFS HA на кластере Proxmox на DRBD9 по статье уважаемого @kvaps - всё работает! Сейчас народ тестирует. Единственно что я поменял - мне больше понравилось делать NFS-контейнер на основе Ubuntu 18.04, потому что у неё таймауты NFS-сервера настраиваются в отличие от 16.04, соответственно можно сделать более быстрый failover.

Думаю на тему обновления большого хранилища (оно тоже NFS HA), сейчас там 2 ноды на DRBD8 + pacemaker/corosync - соответственно периодически имеем проблемы со split brain.
Варианты:
1. делать по только что опробованной схеме (3 ноды NFS HA - proxmox - DRBD9)
2. железячная двухконтроллерная хранилка, подключенная к 2 (или 3) нодам на которых NFS HA.

В связи с этим вопросы:
1. Какой вариант лучше в плане надёжности и сложности поддержки?
2. Если вариант номер 2 (к чему я склоняюсь) то надо ли там 3 ноды или достаточно 2? Я не вижу большого преимущества от наличия кворума в данном случае если я обеспечу блокировку от монтирования ресурсов с хранилища более чем на одном сервере.
3. Какую операционку и какой софт для кластеризации лучше выбирать для нод?

А вариант linstor рассматривали?

Я видимо не очень хорошо понимаю, как он тут может помочь.

В железячной хранилке есть большое премущество что кеши двух контроллеров синхронизируются, что понижает вероятность сбоев в случае failover - в отличие от DRBD9 нод в случае неожиданного отказа мастера

В подходе по отдельному drbd-устройству на каждую виртуалку, так можно и пространство утилизировать лучше, и локализовать возможные проблемы со стораджем на уровень конкретной виртуалки, а не всего стораджа

а, понял

К тому же cluster manager ему не требуется

Ну разве что для контроллера ток, но linstor и без контроллера может работать какое то время, так что не критично