@realvava

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

Создание отказоустойчивого кластера подразумевает наличие общей системы хранения данных. В случаях бюджетных решений это безальтернативно 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 в стоке.
  • Вопрос задан
  • 1194 просмотра
Пригласить эксперта
Ответы на вопрос 3
@realvava Автор вопроса
Новое направление мыcли - ClusterOS на ZFS.
Ответ написан
gbg
@gbg
Баянист. Тамада. Услуги.
Ceph, например
Ответ написан
icCE
@icCE
youtube.com/channel/UC66N_jRyZiotlmV95QPBZfA
Это приводит (опять же речь про бесплатное ПО) к безальтернативности 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 в качестве интерфейса входа.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы