Репликация. Идеи, мысли, практика...

[Akupaka]

Всем привет!

видать, понедельник день тяжелый - никто не флудит совсем
да и вообще, малова-то в последнее время интересных обсуждений было
решил разбавить атмосферу...

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

- представьте себе, что в Вашей организации используется domino-приложение для сбора определенной информации;
- состав компании, например, есть центральный офис компании и региональные учреждения;
- информация вносится и читается всеми рабочими местами (АРМами), но есть ряд отличий:
к примеру, каждый АРМ вносит свою информацию, видит ее и какой-то набор общей справочной информации.
кроме того, есть АРМы, которые видят все.

нужно организовать приложение таким образом:
- чтобы каждому АРМу была доступна своя правильная порция информации;
- при этом нужно организовать приложение таким образом, чтобы оно имело достаточный уровень быстродействия;
- чтобы каждый АРМ оставался работоспособным независимо от остальных рабочих групп...

ну, можно много конкретизировать, но у нас не стоит задача получить ТЗ :wacko:

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

вот тут я и предлагаю поделиться мыслями на этот счет
чего я хочу достичь!
1) поделимся опытом друг с другом;
2) новичкам эта инфа может помочь не совершать ошибок;
3) просто пообщаемся на интересную для всех тему;
ну и социализьмь, комунизьмь и все такое...

 

[Alexander (Criz)]

А почему обязательно решать репликацией, можно просто через readers-authors поля с ролями... И каждый будет видеть что должен и неважно, есть репликация, или все на одном серваке...

 

[RonTermit]

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

Очень даже важно....если серваков не один а так штук 8 к примеру

 

[Akupaka]

А почему обязательно решать репликацией, можно просто через readers-authors поля с ролями... И каждый будет видеть что должен и неважно, есть репликация, или все на одном серваке...

попытаюсь объяснить так:
серверам обычно дается полный доступ на просмотр доков, т.е. каждый сервер обычно "видит" все...
к примеру, АРМ2 должен видеть только типы документов Док2 и Справка,
АРМ2 смотрит доки на своем сервере - сервер2, больше никого этот сервер не обслуживает...
Центральным сервером служит сервер1, на нем хранятся все данные.
все хорошо, пока данных не много, и когда между серверами хорошее, быстрое соединение...
но вот когда АРМов штук 30-50 и каждый начинает забивать туда в месяц доков 1000-5000, то объемы репликации жутко вырастают...
или, возможно, этих доков не так много, но каждый весит по 500-1000 КБайт...
тогда Вы уже одним доступом через поля можете не разобраться, т.к. сервера будут все видеть... либо придется очень четко и тяжко расписывать доступ для серверов, что часто сложнее, чем управлять потоками репликации с помощью формул репликации...

надеюсь понятно объяснил?

 

[Medevic]

Сделать формулу репликации на основе имени сервера. Каждому документу(кроме общих) прописать на каких серверах он доступен. Ну а на каждом сервере рулим правами доступа.

 

[Akupaka]

Сделать формулу репликации на основе имени сервера. Каждому документу(кроме общих) прописать на каких серверах он доступен. Ну а на каждом сервере рулим правами доступа.

где-то такой вариант я уже встречал )) но не вспомню...

думаю, что этот вариант сложен тем же, что и вариант использования сервера в авторс-ридерс полях... но вполне реализуем...


а вот давайте еще думать об оптимизации, и учитывать наш бесценный опыт, т.е. рассказывать на примерах, давайте попытаемся раскрывать тему, а не просто комментировать

 

[johny]

если я правильно понял, то информация сливается из регионов на центральный сервак (объемы реплицируемых данных на центральный сервер не уменьшить програмно в любом случае)...вопрос - репликация в обе стороны? или только из регионов в центр? если в обе, то по имени сервера писать формулы репликации, если нет, то наверно это и есть решение

 

[Akupaka]

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

 

[alb]

по мне лучше имя сервера, меньше мароки записал в поле реадерс и реплицируй все что надо он получит.
у нас областной документооборот так реализован

 

[Akupaka]

вот не меньше, имхо
представьте ситуацию, что у Вас появился новый сервер, на который нужно собрать все доки, что лежат на сервере5, но не больше того.
Вам придется во всех тех доках прописывать новый сервер...
в принципе, это не сложная задача, но если при этом у Вас используется cutoffdate или подобное, то Вы приведете к большим потокам "документооборота" на всех серверах, где есть эти доки.
при этом, если у Вас используется формула репликации которая указывает, что нужно реплицировать только доки для зоны5, а доступ серверов указан на основании роли, то можно просто создать новую реплику, с указанной формулой... или даже скопировать файл, если это позволительно...

 

[Sandr]

Интересно, а что нового, а главное полезного ты хочешь услышать?

 

[Akupaka]

Интересно, а что нового, а главное полезного ты хочешь услышать?

хм... в мире еще много неизведанного

 

[Constantin A Chervonenko]

...
при этом, если у Вас используется формула репликации которая указывает, что нужно реплицировать только доки для зоны5,

Так тоже можно (у меня одна база так работает)
Но все равно ты свою "зону" должен пересчитать в имя сервера - что-б положить эту проверку в формулу селективной репликации соотв.сервера.
Грабли: усложняется администрирование. При развертывании базы на новые сервера соотв.настройку репликации для каждой реплики - вручную

 

[Akupaka]

пересчитать - да, но я думаю, что это проще чем использовать имя сервера, т.к. в "зоне" может быть несколько серверов, а использование имени сервера в формуле репликации на другом сервере может сбить с толку админа...
администрирование не на много усложняется, ведь формулы можно задавать используя репликацию формул... хотя, пока не уверен, что это не принесет новых глюков
кроме того, почти в любом случае администрирование комплексной системы - не самая простая задача, особенно в части репликации...
еще я считаю, что использование авторс-ридерс полей в качестве разграничения доступа для серверов, для репликации, только лишне усложняет программную часть контроля доступа к документам...

 

[Kee_Keekkenen]

Грабли: усложняется администрирование. При развертывании базы на новые сервера соотв.настройку репликации для каждой реплики - вручную

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

 

[dobozy]

1. Все разделить через ридерсы. Необязательно но желательно, чтобы всё секьюрно было распределено.
2. Поставить промежточный сервер на вашей стороне.
3. Начекрыжить селективных реплик на промежуточном сервере. Критерий отбора, например, поле Область(в которой стоит серевер АРМа).
4. Каждый удалённый сервер видит только свою реплику, например через ACL на папку, на промежутоном сервере.

Плюси.
1. При репликации, репликатор не строит коллекцию всех документов, которые апдейтились и в чужих АРМах. Он работает только на своих данных.
2. Никаких формул репликаций на стороне удалённого сервера.
3. Ну короче трафик значительно меньше и скорость соотвсетсвенно.

Минусы.
1. Менеджент реплик на промежуточном сервере, но решаемо.

P.S. Ридерс нужны, для разделения больше чем на один уровень глубины скажем. На второй уровень можно обойтись и без промежуточного сервера.

 

[Constantin A Chervonenko]

1. Все разделить через ридерсы. Необязательно но желательно, чтобы всё секьюрно было распределено.
2. Поставить промежточный сервер на вашей стороне.
3. Начекрыжить селективных реплик на промежуточном сервере. Критерий отбора, например, поле Область(в которой стоит серевер АРМа).
4. Каждый удалённый сервер видит только свою реплику, например через ACL на папку, на промежутоном сервере.

Плюси.
1. При репликации, репликатор не строит коллекцию всех документов, которые апдейтились и в чужих АРМах. Он работает только на своих данных.
2. Никаких формул репликаций на стороне удалённого сервера.
3. Ну короче трафик значительно меньше и скорость соотвсетсвенно.

Минусы.
1. Менеджент реплик на промежуточном сервере, но решаемо.

НЕ решаемо. Более одной реплики базы на одном сервере = катастрофа

 

[dobozy]

НЕ решаемо. Более одной реплики базы на одном сервере = катастрофа

Это не то что решаемо - это рабочий вариант.
Одно из главный условий заключается в том, чтобы инициирующим репликацию сервером на вашей сторое был всегда промежуточный сервер, на котором лежат селективные реплики. Т.е. схема hub-spoke вырисовывается так
(Server А - Hub) - основной сервер с полной репликой, он сам никого не вызывает, его вызывают

^
(Server B - Spoke) - промежуточный сервер, с селективными репликами. Он иницирует репликацию только с Server A.
^ ^ ^
(Remote Server1) (R Server2) ... (Remote ServerN) - эти сервера инициируют репликацию с Server B.

 

[Constantin A Chervonenko]

Это не то что решаемо - это рабочий вариант.

Это Вы ещё не хл*цензура*и дерьмо половником.
Или путаете что-то в терминологии.

1.В репликации всегда участвуют 2 субъекта (сервера или WS. Об исключениях - отдельный разговор). Поэтому 2 реплики на одном сервере автоматом синхронизироваться не будут
2.При "внешнем" запросе на репликацию к такому серверу в общем случае непредсказуемо, которую из реплик выберет сервер

Вы говорите "внешних запросов не должно быть" вовсе? ОчЧчень сильное ограничение. Запретите всем админам доступ к консоли, иначе получите

 

[dobozy]

Это Вы ещё не хл*цензура*и дерьмо половником.
Или путаете что-то в терминологии.

Не очень понятен Ваш тон. Ничего я не хл*цензура*, так как отлично знаю механизм репликации. И ничего не путаю, так как в моей организации такая топология распределения сущетсвует уже 8 лет. И прошу заметить, весьма успешно работает.

1.В репликации всегда участвуют 2 субъекта (сервера или WS. Об исключениях - отдельный разговор). Поэтому 2 реплики на одном сервере автоматом синхронизироваться не будут

Вы наверное не поняли, что и как нужно делать. Сейчас попытаюсь повторить более доходчиво.
Каждая селективная реплика выкладывается на промежуточный сервер в свою личную папку(folder link), например, bases\RemoteServer4\db_replica.nsf. Каждый фолдер линк имеет свой ACL, в котором прописывается только один удалённый сервер, в данном случае RemoteServer4 и администратор сервера B(Вы).
Если вы запускаете репликацию с сервера В например командой
>replicate ServerA bases
то репликатор будет реплицировать все базы сервера В, которые находятся в папке bases и её подпапках. Причём ему абсолютно неважно сколько баз с одинаковым ReplicaID будет лежать в разных папках.
При этом он находит для каждой базы хотя бы одну реплику на сервере А и реплицируется с ней. На сервер А она одна, общая.

2.При "внешнем" запросе на репликацию к такому серверу в общем случае непредсказуемо, которую из реплик выберет сервер

Теперь поговорим про репликацию сервера В и удалённых серверов.
Каждый удалённый сервер хранить на себе только одну реплику, скажем по пути bases\replica_db.nsf. Инициируя репликацию с сервером B, репликатор, например, RemoteServer4 получает список баз с одинаковым ReplicaID c сервера В. И пытается провести хотя бы одну успешную репликацию с одной из них. Так как каждая реплика на сервере В лежит в своей ограниченной ACL папке, то при попытки реплицироваться с "чужой" репликой получает октаз по доступу и переходит на следующую, пока не дойдёт до "своей реплики".
Т.е. в конечно итоге проходит репликация между репликами
Server B!!bases\RemoteServer4\replica_db.nsf и RemoteServer4!!bases\replica_db.nsf

Вы говорите "внешних запросов не должно быть" вовсе? ОчЧчень сильное ограничение. Запретите всем админам доступ к консоли, иначе получите ohmy.gif

Я такого не говорил вовсе . Если вы внимательно прочитаете описание и поймёте как это работает, то я надеюсь осознаете свою неправоту. Удачи!

P.S. В реальной жизни так распределено около 50 серверов у нас. Вот. А также я думаю вы поняли что репликация с сервера А на B не пройдёт по ACL, что и нужно, а вот обратно запросто.