Существуют ли бесплатные решения VirtualSAN с двухсторонней репликацией?

Question

[realvava]

Создание отказоустойчивого кластера подразумевает наличие общей системы хранения данных. В случаях бюджетных решений это безальтернативно iSCSI (AoE не предлагать :-) ). Это приводит (опять же речь про бесплатное ПО) к безальтернативности DRBD. Но вся его проблема для меня заключается в том, что в условиях работы с бескластерными ОС, заточен он под Primary-Secondary, и это объяснимо. Мне бы, в свою очередь, хотелось бы, чтобы разные каталоги реплицировались в обратных относительно друг друга направлениях.
Допустим, существует нода1 и нода2, на них каталог1 и каталог2, естественно, на каждой. То есть если примари выбирается нода1, то оба каталога в работе пишутся на неё и реплицируются на ноду2. Как я понял, реализации возможности, чтобы ноад 1 была примари только для каталога1, а нода2 для катлога - нет?
Это было бы удобно в реализации подобной StarWind VirtualSAN, когда двум виртуалкам на разных хостах отдаётся всё доступное локальное пространство серверов, а они им же обеспечивают доступ как к единому реплицируемому хранилищу. Только если репликация будет двусторонней, то можно распределить нагрузку.
Взять гипервизор1 и гипервизор2, поставить на них, соотвественно, виртуалку1 и виртуалку2, каждой из которых выдать в виде виртуального диска всё оставшееся дисковое пространство на локальном диске каждого из гипервизоров. После, объединив виртулалки в некое подобие кластера хранения данных, было бы всё равно удобнее и правильнее, если бы виртуальные машины, иницирующие доступ с гипервизора1 обращались к виртуалке1, как к праймори, а вм с гипервизора2 к виртуалке2, соответственно. Несмотря на то, что данные всё равно погоняться "в сеть", согласитесь, потерь при такой реализации будет меньше.
Остаётся повесить какой-то контроллирующий сервак с хертбитами, который, в случае отказа одного из гипервизор вместе со своей нодой хранилища, будет через консольные команды (например, на HyperV через powershell) отправлять команды на запуск виртуальных машин, ну или оставить настройки отказоустойчивого кластера HyperV в стоке.

Answer 1

[realvava]

Новое направление мыcли - ClusterOS на ZFS.

Answer 2

[Армянское Радио]

Ceph, например

Comments

[realvava]

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

[Армянское Радио]

realvava: Если у вас серверы в одной стойке, соедините из 10G сетью и все.

[Армянское Радио]

realvava: Репликация в ceph происходит сама. Все, что туда пишется, автоматом клонируется столько раз, сколько задан размер пула(size).

Писателю передается сигнал об успешной записи после того, как количество копий достигнет заданной величины (min_size)

кроме этого механизма, есть еще rbd_mirror

[realvava]

Армянское Радио: получается, если сделать rbd_mirror, то на каждой отдельной ноде можно будет поднять свой iSCSI-таргет для своего гипервизора.
Надо попробовать.

[Армянское Радио]

realvava: Зачем таргет, когда можно просто rbd подсунуть системе вместо диска? KVM такое поддерживает.

[realvava]

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

[Армянское Радио]

realvava: это не обязательно. rbd подключается к osd по сети

Answer 3

[Vladimir Zhurkin]

Это приводит (опять же речь про бесплатное ПО) к безальтернативности 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 в качестве интерфейса входа.