Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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



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

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

Ну, примерно так и предполагал (только про ACL-и в dir-ах забыл). 50 реплик, и в каждой - от руки правленный ACL

У меня (в реальной жизни Бум меряться?) порядка 100 серверов, 30 доменов (многоуровневая звезда. Одним hub-сервером не обойдешься). Ваша схема требует непосредственного администрирования их ВСЕХ, в то время как с многими дальними серверами у меня и коннекта-то нет, не то, что админских прав. Тем не менее - все работает. Consistment ACL + READERS-поля. Рулю из одной реплики. Размер баз - до 3 000 000 документов.
Примерял вариант с программно управляемыми формулами селективной репликации: получается красиво, но - не работает! Нет возможности выкрутить руки каждому удаленному админу, что-б при развертывании приложения взводили крыжик "реплицировать формулы репликации".

Не.. Схема, которая для фунЦИклирования требует само/едино-личного администрирования..

ACL может быть одинаков во всех репликах, если даётся через группы. От руки только правленный ACL на фолдер линки. Но это единоразовая правка при создании фолдер линка.



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




Тоже консистент тоже данные раскиданны через Readers. И удалённые сервера все тянут по читательским правам, никаких селективных формул на ихней стороне, так как уровень после них всё тянет уже без промежуточных реплик, а только по ридерс. Но так как информация рамномерно распределена по объёму между N серверами, то репликаци с третьего уровня не требует такого разделения как у нас на уровне.




Никаких формул репликаций за пределами моей площадки. Админам никакие крыжики ставить не надо




Ну я думаю вы поняли, что так и есть. Т.е. моя схема аналогично вашей за исключением того, что реплиатор удалённого сервер видит физически не 100 процентов данных, а 100/N процентов, так как в реплике на серевере B, который админится исключительно на нашем уровне, лежит его кусочек информации, который тем не менее тоже внутри разделен по ридерсам.
Просто в вашем случае репикатор подготавливает сначала список изменений по 100% информации, потом по ридерсам отбрасывает 98% инфы, а всё это немалое время и трафик, проверено, так как сначала у меня тож так было. Попробуйте смоделировать хотя бы 3 удалённых сервера по такой технологии и вы заметите разницу при репликации сервера 3, если еще два сервера заапдейтили скажем 2/3 информации. Прошу заметить, что схема оправдывает себя при интенсивно правленных бд. При такой схеме, если по 3-ему серверу не было изменений, то репликация пройдёт моментально, так как все чужие апдейты остануться за пределами селективной репликации на нашей площадке, по локальному трафику. При схеме же обычной, она прилично призадумается, так как список удаленным зменениям будет подготовлен весь, хоть потом и отфильтрован полностью.

Тут у Вас противоречие. Дир-линк через реплику не настроишь.

В общем, работоспособная схема, для устаканившейся инфраструктуры и одного админа.
У меня-ж ЕЖЕМЕСЯЧНО подключается новый сервер и ежегодно обновляется коллектив админов

Да, но этот дир-линк создаётся единожды при создании нового сервера и по времени это секунд 5. Т.е. в моём случае цель оправдывает средства. А потом это фактически текстовый файл и благодаря этому с ними можно работать массово, если это нужно.




Да подключения новых серверов нет часто происходит, но процедура весьма безболезненная. На удалённый серверах такая текучка админом, что далеко не со всеми знаком :-).

P.S. Собственно давно был сделан переход на такую схему, так как однажды одни умельци попытались сделать самостоятельно импорт в нашу базу агентом из другой базы. Так как автора они, то мусор накидать получилось. Потом весь этот мусор прилетел на центральную реплику, так как мусор не был виден в видах и локализован не сразу, то можете себе представить какого было когда 50 остальный серверов начали коннектиться к реплике и забирать это всё к себе. Сейчас так вариант исключается, что экономит много времени и сил.

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

dobozy

Очень интересное решение. У меня есть пара вопросов:
1. Хотелось бы узнать - есть ли подтверждение работоспособности данной архитектуры непосредственно от IBM?
2. Какие версии серверов используются?

а агента не пробовали создать, который бы прописывал формулу в бд ?

Вы неУнимательно читаете

Агент у меня формулы и прописывает (в реплике головной конторы), но они на целевые сервера НЕ ПОПАДАЮТ, т.к. админам в-лом выставить крыжик "реплицировать формулы" (а по умолчанию он не взведен).
Или ты предлагаешь, что-б формула рожалась агентом прямо на месте? Гм.. Это надо что-б мне прописали права на выполнение агентов на всех серверах всех доменов. Не пропишут..

1) если Вас интересует такое подтверждение, то спросите об этом IBM, пока то, что это работает подтверждено лишь практикой;
2) в данный момент сервера 5.0.13а

да, я это имел ввиду