Как Exchange "борется" с задержками при репликации

re: Как Exchange "борется" с задержками при репликации

msexpert — Tue, 06 Jun 2006 23:25:12 GMT

Есть два вопроса и один комментарий :)

1. По какому в точности критерию Exchange выбирает ККД, и почему DSAccess всегда использует только один ККД (во избежание конфликтов репликации?)? Если используемый ККД становится недоступен, используется ли стандартный механизм DS Discovery, есть ли разница с процессом обнаружения "обычных" GC?

2. Кроме ККД, DSAccess использует также три GC сервера (понятно) и три обычных DC (через LDAP, то есть по порту 389). Вот эти последние, зачем они и как они используются? Для получения тех атрибутов, которые не хостятся на GC? Как Exchange определяет, с GC или с DC нужно брать информацию?

3. Пример с базой данных во втором абзаце, имхо, не слишком удачен. Дело в том, что при создании базы конфигурируется также путь к edb/stm файлам и PF store. Поэтому, если пытаться создать базу или изменить путь к ней из ESM, запущенного на другом компьютере, то получится отлуп в виде сообщения "This option is available only if the Exchange System Manager runs on the server on which the files are located". А остальное все верно, конечно :)

re: Как Exchange "борется" с задержками при репликации

vladg — Sat, 17 Jun 2006 02:16:53 GMT

Отвечаю на вопросы:) Извиняюсь за задержку, изо всех сил готовим публичную бету Exchange 2007.
1. Один ККД используется для того, чтобы все службы имели одинаковое видение конфигурации в любой момент времени. Иначе, к примеру, может получиться, что один процесс "знает" про новый или измененный объект - например, mailbox database, а другой еще нет, и все начнет работать непредсказуемо.
Честно говоря, с репликацией и так трудно добиться каких-то гарантированных результатов, а если еще позволить серверу считывать критически важные данные со случайных контроллеров домена, то вообще наступит полный хаос.
Наша цель - постоянный источник данных. Имея один общий сервер можно заставить все службы отслеживать изменения на нем и тогда любое действие администратора будет имет мгновенный эффект на всем Exchange сервере.

1а. Выбирается ККД по тем же критериям, что и обычный КД - то есть нужные битики в событии 2080 должны быть установлены. Любой КД из списка серверов, прошедших проверку, имеет шанс стать ККД.

2. Маленькая коррекция - серверов в списке DC и GC может быть до 10 (но и этот предел можно увеличить). Действительно, DC, которые не GC, нужны довольно редко. Насколько я помню, один из немногих сценариев это OWA Logon, когда надо проверить, давно ли менялся пароль у пользователя. Ну а еще КД используются для сохранения изменений. Скажем, Information Store иногда обновляет запись пользователя в Active Directory - для этого, естественно глобальный каталог не подойдет.

3. Насчет третьего пункта не согласен:) Exchange 2003 Service Pack 2 при удаленном создании базы данных действительно не может проверить пути к файлам, но при этом выдает лишь предупреждение:
"The Exchange System Manager cannot verify if the database file names are valid.... Are you sure you want to continue and use these values?", которое можно проигнорировать и успешно создать базу данных. А какая версия ругается и не позволяет это сделать?

re: Как Exchange "борется" с задержками при репликации

msexpert — Mon, 26 Jun 2006 21:53:35 GMT

Спасибо, Владимир,

Касательно "третьего пункта" :) а Вы попробуйте не создавать новую базу, а просто нажать кнопку Browse на вкладке Database в свойствах уже существующей базы (как если бы Вы собирались поменять путь к файлам базы). Вы получите вот такое сообщение (от версии и сервис-пака Exchange, насколько я помню, это не зависит):
This option is available only if the Exchange System Manager runs on the server on which the files are located.
Что в принципе естественно, ибо каждый сервер "видит" буквы дисков по-своему, а атрибуты msExchEDBFile и msExchSLVFile в AD используют именно буквы дисков.