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

[Constantin A Chervonenko]

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

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

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

 

[dobozy]

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

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

У меня (в реальной жизни wink.gif Бум меряться?) порядка 100 серверов, 30 доменов (многоуровневая звезда. Одним hub-сервером не обойдешься). Ваша схема требует непосредственного администрирования их ВСЕХ, в то время как с многими дальними серверами у меня и коннекта-то нет, не то, что админских прав.

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

Consistment ACL + READERS-поля. Рулю из одной реплики. Размер баз - до 3 000 000 документов.

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

Примерял вариант с программно управляемыми формулами селективной репликации: получается красиво, но - не работает! Нет возможности выкрутить руки каждому удаленному админу, что-б при развертывании приложения взводили крыжик "реплицировать формулы репликации".

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

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

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

 

[Constantin A Chervonenko]

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

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

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

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

 

[dobozy]

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

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

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

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

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

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

 

[rins]

dobozy

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

 

[Kee_Keekkenen]

Примерял вариант с программно управляемыми формулами селективной репликации: получается красиво, но...

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

 

[Constantin A Chervonenko]

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

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

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

 

[Akupaka]

dobozy

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

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

 

[Kee_Keekkenen]

Или ты предлагаешь, что-б формула рожалась агентом прямо на месте?

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

 

[PaVaP]

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

Можно поподробнее про это?

Например, есть несколько десятков серверов и все они в одном домене.
Нужно чтобы определенного типа док-ты лежали на определенных серверах.
Док-ты создаются на любом сервере. При создании док-та, в зависимости от типа док-та,
в поле Ридерс записывается название некой группы серверов ServersGroup.
Соответственно в names.nsf имеется группа ServersGroup, содержащая определенные сервера.
При репликации, те сервера, которые указаны в ServersGroup, увидят док-т и соответственно на эти сервера док-т среплицируется.
Если в будущем потребуется добавить новый сервер, то просто добавляем его в ServersGroup и на него среплицируется всё что нужно.

Вроде для одного домена схема рабочая, но может возможны подводные камни..., кто что думает?

 

[Akupaka]

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

 

[Alexander (Criz)]

Если в будущем потребуется добавить новый сервер, то просто добавляем его в ServersGroup и на него среплицируется всё что нужно.

Есть один нюанс: он начнёт получать только новые документы, а чтобы получил старые, придётся сбрасывать хистори репликации.

 

[Kee_Keekkenen]

Есть один нюанс: он начнёт получать только новые документы, а чтобы получил старые, придётся сбрасывать хистори репликации.

а если первую репликацию делать со стороны нового тоже также будет?

 

[PaVaP]

... столь пагубно как для локальных реплик.

А в чем пагубность для локальных реплик?

Вы имеете ввиду, что на локале юзер может в локальной names.nsf создать группу с таким же именем и в эту группу добавить себя и как следствие увидеть док-ты, непредназначенные для него? Но если в ACL базы группа серверов прописана как Server group, то наверно (сейчас проверю...) юзер на локале обломится...

Или что-то другое?

 

[Alexander (Criz)]

а если первую репликацию делать со стороны нового тоже также будет?

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

 

[Constantin A Chervonenko]

При репликации, те сервера, которые указаны в ServersGroup, увидят док-т и соответственно на эти сервера док-т среплицируется.
Если в будущем потребуется добавить новый сервер, то просто добавляем его в ServersGroup и на него среплицируется всё что нужно.

А вот Вам фиг! На него (новый сервер) среплицируются только новые документы, созданные ПОСЛЕ добавления сервера. Понятно почему?
Впрочем, иногда именно такое поведение и требуется..

А, уже ответили

 

[Akupaka]

Понятно почему?

нет, объясните, пожалуйста, ибо я такого поведения не встречал ))

А в чем пагубность для локальных реплик?

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

 

[Alexander (Criz)]

доступ на основании групп на локальных репликах не всегда работает как нужно (без подключения к серверу имен)

если не поднята галка Enforce a consistent Access Control List across alll replicas.

 

[Constantin A Chervonenko]

нет, объясните, пожалуйста, ибо я такого поведения не встречал ))

Да?? Или то, что я "замял для ясности" полную формулировку (созданные ИЛИ МОДИФИЦИРОВАННЫЕ после...) смутило?

Так или иначе, но алгоритм репликатора базируется на сравнении временнЫх меток на док-тах с датой в истории репликации.
Док-ты пропущенные репликатором в одном сеансе по причине недоступности (READERS ли, селективная репликация-ли..) в следующих сеансах уже рассматриваться НЕ БУДУТ, т.к. в history осядет более поздняя дата. Вновь включить их в оборот можно либо продвинув временнЫе метки док-тов вперёд (т.е. обновить их), либо отодвинув History назад (очистить историю).
Изменение-же содержимого группы (т.е. док-та в ДРУГОЙ базе) останется незамеченным репликатором

 

[Akupaka]

если не поднята галка Enforce a consistent Access Control List across alll replicas.

ну, подними, и потыкай я с ней и пробовал, проблема не в ней

Constantin A Chervonenko, а почему это должно влиять на пулл-репликацию, причем при первой репликации, когда истории нет?
по-идее, ведь выборка доков будет производится от имени нового сервера, который будет иметь доступ и который документы еще не получал.