Это приводит (опять же речь про бесплатное ПО) к безальтернативности DRBD. Но вся его проблема для меня заключается в том, что в условиях работы с бескластерными ОС, заточен он под Primary-Secondary, и это объяснимо
Ну в общем и целом нет. Есть же GlusterFS,Ceph,Moose итд.
Все зависит от потребностей и что надо в итоге.
Допустим, существует нода1 и нода2, на них каталог1 и каталог2, естественно, на каждой. То есть если примари выбирается нода1, то оба каталога в работе пишутся на неё и реплицируются на ноду2. Как я понял, реализации возможности, чтобы ноад 1 была примари только для каталога1, а нода2 для катлога - нет?
Я или не понимаю или вы хотите странного.
У вас есть те кто пишут читают и есть место которое они читают и пишут. Вот то самое место будет реплицироватся между собой, не важно кто туда записал . Если есть права и доступ то вперед.
Другой момент, что если вам надо, что бы на некое блочное устройство могли писать несколько систем, вам надо там поднять будет кластерную файловую систему. Например OCFS2.
Взять гипервизор1 и гипервизор2, поставить на них, соотвественно, виртуалку1 и виртуалку2, каждой из которых выдать в виде виртуального диска всё оставшееся дисковое пространство на локальном диске каждого из гипервизоров. После, объединив виртулалки в некое подобие кластера хранения данных, было бы всё равно удобнее и правильнее, если бы виртуальные машины, иницирующие доступ с гипервизора1 обращались к виртуалке1, как к праймори, а вм с гипервизора2 к виртуалке2, соответственно. Несмотря на то, что данные всё равно погоняться "в сеть", согласитесь, потерь при такой реализации будет меньше.
Во первых 2 машины из кластера не образует кворум. Поэтому при выходи одной ноды, все встанет и будет ожидать вашего действия. Далее, вы должны разделять гипервизоры и хранилище для них. Хранилизе с точки зрения гипервизора должно быть неким едином местом . Те должна быть одна точка входа и не важно , сколько там нод у вас в storage. Иначе при падение гипервизора1, как образы виртуальных машин переползут на гипервизор2 ? Поэтому мы ставим кластер из гипервизоров, и кластер из storage. У гипервизоров насители должны быть только для запуска системы, а все образа хранятся на storage (так называемый СХД).
Остаётся повесить какой-то контроллирующий сервак с хертбитами, который, в случае отказа одного из гипервизор вместе со своей нодой хранилища, будет через консольные команды (например, на HyperV через powershell) отправлять команды на запуск виртуальных машин, ну или оставить настройки отказоустойчивого кластера HyperV в стоке.
Не надо изобретать велосипед, там где он не нужен.
Для начало, что вы все же используете. Если из условно открытых и бесплатных - то я бы смотрел в сторону proxmox как гипервизоров + у них же допиленный storage из ceph.
Если у вас Windows Server и Hyper-V, то все еще проще. Вы можете построить СХД используя StorageSpace + jbod.
Можно будет настроить отдельный сервер репликации hyperV, поднять ClasterFileSystem для hyper-v итд итп.
Вот тут уже есть некий вопрос про это:
Как спланировать отказоустойчивую СХД для Hyper-V Cluster?
Ну можно и из ceph для win настроить , через iscsi в качестве интерфейса входа.
