Как Exchange "борется" с задержками при репликации
Практически все настройки Exchange хранятся в Active Directory. Благодаря этому администрирование сервера можно производить с любого компьютера, где тоже имеется Exchange. Но это удобство имеет и обратную сторону: если Exchange читает данные с одного контроллера домена, а изменения производились на другом, то неизвестно, когда эти изменения реально начнут действовать.
Например, если администратор создает новую базу данных (Mailbox database), он наверняка захочет тут же ее использовать - но как это сделать, если сервер еще не знает об этом?
Вот какие механизмы существуют в Exchange 2000/2003 для смягчения негативных последствий репликации. (В Exchange 2007 по большому счету все работает примерно так же):
1. Общий Конфигурационный контроллер домена. В любой момент времени все без исключения службы Exchange читают и сохраняют свои конфигурационые данные с одного и того же сервера, называемого Конфигурационным контроллером домена (Config DC, или ККД). Под конфигурацией здесь понимается все, что хранится в разделе CN=Configuration,DC=<rootDomain>,DC=com.
Поскольку абсолютно все контроллеры домена имеют реплику (копию) этого раздела, компонент DSAccess всегда выбирает ККД из контроллеров домена, находяшихся поближе к Exchange вне зависимости от домена. Результат выбора сообщается регулярно в событии 2080, о котором я говорил ранее.
Если ККД по какой-то причине становится недоступным, то DSAccess выбирает другой DC, и все службы одновременно переключаются на него.
Наличие одного ККД для всех служб позволяет всем компонентам Exchange иметь целостное видение конфигурации. При необходимости в реестре можно "насильно" установить ККД, но это рекомендуется делать лишь кратковременно, поскольку если этот сервер вдруг станет недоступен, то DSAccess не сможет нарушить "приказ" и найти другой ККД.
2. Администрирование с помощью ККД. Exchange System Manager может удаленно администрировать любой Exchange сервер, так как в большинстве случаев администрирование - это просто работа с данными в Active Directory. Но чтобу изменения моментально начинали действовать, ESM выясняет у удаленного сервера, какой ККД тот использует, и шлет все изменения туда. А поскольку большинство служб Exchange отслеживает изменения конфигурации (именно на ККД), то создается эффект мнговенности данной операции.
3. ККД и установка Exchange. Установка - экстремальный случай администрирования :) Очевидно, когда службы стартуют в первый раз, им очень важно прочитать настройки с правильного DC. Для этого программа установки Exchange "говорит" DSAccess какой ККД нужно использовать сразу после старта службы System Attendant. Это значение сохраняется в течение 8 часов, что более чем достаточно для репликации. Но если остановить службы (или рестартовать сервер) сразу после установки, что это значение будет утеряно и придется ждать, пока репликация завершится.
Кстати, ККД и в обычном режиме меняется каждые 8 часов, чтобы распреедлить нагрузку между контроллерами доменов более равномерно.
4. Конфигурация пользователей и почтовых ящиков. (Тут я не могу подобрать правильные термины, я имею в виду Mail Recipients/Mailboxes. Кто знает - подскажите!) Эти данные не хранятся на ККД, и считываются с глобальных каталогов. Exchange одновременно использует до 10 глобальных каталогов, поэтому точно сказать, откуда будут считаны данные, нельзя. Кроме того, данные о пользователях кэшируются на двух уровнях - Information Store и DSAccess, и уведомлений об изменениях для этих данных тоже нет. Поэтому "мгновенные" изменения пользовательских данных практически невозможны.
Exchange System Manager на вкладке DSAccess содержит полные списки серверов, использующихся в настояще время.
