Кластер и реплики разделов дерева - как сделать правильно?

[Larico]

Есть кластер из двух узлов. Есть дерево, поделенное на реплики.
Некоторые из разделов реплик расположены на некоторых серверах.

Кластер в дереве представлен узлами кластера: node1.org.ou и node2.org.ou. Есть также два объекта сервер node_hdd1.org.ou и node_hdd2.org.ou, представляющие собой файловые ресурсы кластера.
Таким образом часть дерева выглядит так:
OU
-ORG
-- node1
-- node2
-- node_hdd1
-- node_hdd2

Хочется положить на кластер (именно на кластер, а не на один из узлов) реплику раздела ORG. А как это сделать, ведь объект кластер не является объектом сервер - и значит на него нельзя просто положить реплику.

Поможите люди добрые советом толковым.

[Алексей Волков]

Придётся положить две реплики: по одной на каждый из серверов.

[Larico]

Неправильное какое-то решение. При отключении (сбое) одного из узлов реплика на нем будет недоступна, а хочется что бы она перемещалась вместе с кластером с узла на узел вместе с IP-кластера. И таким образом была доступна всегда!

[PavelKHTW]

Неправильное какое-то решение. При отключении (сбое) одного из узлов реплика на нем будет недоступна, а хочется что бы она перемещалась вместе с кластером с узла на узел вместе с IP-кластера. И таким образом была доступна всегда!

Почему не правильное? Как раз правильное, ведь eDir распределенная система, но в то же время вы ведь две реплики на одном сервере поднять не сможете? Так почему им подниматься в кластере?

[Larico]

Неправильное потому что:
eDir распределенная система - абсолютно правильно, но на мой взгляд она должна быть распределена по работающим серверам. Желательно иметь несколько реплик на нескольких кластерах (это в идеале). Тогда можно получить очень высокую надежность и живучесть дерева.

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

Что касается

но в то же время вы ведь две реплики на одном сервере поднять не сможете

именно это меня и интересует: как мне поднять реплику на кластере (на одном сервере), а не на узлах.

[Алексей Волков]

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

Не могу с Вами согласится. Синхронизация между живыми репликами разделов не замирает! Она будет идти до тех пор, пока серверу есть с кем и есть что синхронизировать. А упавшие сервера... ну, так с ними синхронизация выполнится, когда они будут восстановлены!

[Константин Ошмян]

Что-то не совсем понял смысла вопроса уважаемого коллеги Larico.

Хочется положить на кластер (именно на кластер, а не на один из узлов) реплику раздела ORG. А как это сделать, ведь объект кластер не является объектом сервер - и значит на него нельзя просто положить реплику.
[...]
Неправильное какое-то решение. При отключении (сбое) одного из узлов реплика на нем будет недоступна, а хочется что бы она перемещалась вместе с кластером с узла на узел вместе с IP-кластера. И таким образом была доступна всегда!

На кластер (а не на сервер) можно "положить" только какой-то кластерный ресурс, которым, насколько я помню, может быть либо том, либо приложение (application). Этому ресурсу назначается свой IP-адрес, под которым он будет доступен клиентам и который будет мигрировать при переходе ресурса между узлами этого кластера. При этом все узлы кластера, на которых этот ресурс может быть запущен, должны быть в состоянии его обслужить: т.е. для томов - иметь физический доступ к разделяемой тумбе с дисками, на которых эти тома расположены, а для приложений - иметь эти приложения проинсталлированными и сконфигурированными для запуска на этом конкретном узле.

Чего Вы (в данном контексте) хотите от бедных реплик, для того чтобы объявлять их кластерным ресурсом? Какие клиенты и для чего будут к ним обращаться? Алексей Волков уже предложил один вполне логичный вариант: поместить по реплике на каждый узел ("проинсталлировать приложение") и обращаться к ним, например, по IP-адресу кластера (который мигрирует между узлами автоматически), ну - или свои старт/стоп-скрипты написать с командами вроде add secondary ip address...

[Орлов Алексей]

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

[Larico]

Ошибаетесь, Алексей.
nds manager - штука несколько старая и про виртуальные сервера типа "кластер" ничего не знает, точнее отображает его в виде и уж тем более не дает на него реплику положить.
С1 собственно так же не дает этого сделать, сейчас уже и не помню почему именно.

[Орлов Алексей]

Вы знаете я конечно мугу ошибаться, но своим глазам я пока верю При просмотре nds managerom дерева, я вижу там виртуальный сервер klaster-server с репликой мастер.