PulseMaximum и PulseTimeout
PulseMaximum используется для управления частотой, с которой PDC будет посылать сообщения pulse своим BDC, даже если базы данных являются актуальными. По умолчанию используется 7200 секунд (два часа), а максимальное значение PulseMaximum равно 172800 секундам (два дня). Это значение можно задавать для гарантии, что PDC не всегда контактирует с BDC при изменениях. Если PulseMaximum задан как максимум в два дня, возникает риск истечения срока действия пароля учетной записи. Задание его как один день выглядит достаточно безопасным для сети с большим числом BDC в удаленных WAN.
PulseTimeoutl контролирует время ожидания PDC ответа от BDC, когда было послано сообщение "announce change to UAS or SAM". Если BDC не отвечает в течение этого периода, то он считается не реагирующим. Не реагирующий BDC не учитывается числом PulseConcurrency, что позволит соединиться дополнительному BDC. Он сможет затем обновить изменения в базе данных, если кто-то превысит предел PulseTimeoutl. Если, однако, значение PulseConcurrency было увеличено, чтобы включить все BDC, то это не будет иметь никакого значения. По умолчанию на ответ на сообщение pulse дается 10 секунд.
В WAN с медленными каналами связи значение по умолчанию PulseTimeoutl может вызвать проблему, поэтому оно должно быть увеличено до максимума в 120 секунд. Прежде чем делать это, необходимо рассмотреть следующие вопросы. Если имеется большое число BDC, которые необходимо синхронизировать, и PDC должен ждать по две минуты, чтобы объявить каждый из них не реагирующим, то потребуется очень много времени, чтобы закончить частичную синхронизацию. Если число задано слишком маленьким (минимум равен одной секунде), то PDC может считать BDC не реагирующим, когда фактически это не так. Это приведет к возрастанию нагрузки на PDC, когда BDC, наконец, ответит и начнет процесс частичной синхронизации.
PulseTimeout2 определяет время, в течение которого PDC будет ожидать, пока BDC завершит частичную репликацию после ответа на сообщение "announce change to UAS or SAM" от PDC. Если число изменений возрастает (например, в связи с изменениями ChangeLogSize), то BDC будет считаться не реагирующим, пока не продолжит контактировать с PDC для получения дополнительных изменений. По умолчанию используется 300 секунд. Это означает, что когда BDC контактирует с PDC, ему дается дополнительно пять минут, чтобы снова вступить в контакт, иначе он считается не реагирующим.
Если значение PulseTimeout2 задано слишком большим (максимум 3600 секунд), то медленный BDC будет занимать один из слотов PulseConcurrency в течение длительного времени (два часа), увеличивая тем самым время выполнения частичной синхронизации. Если это значение слишком маленькое (минимум равен 60 секундам), то нагрузка на PDC будет увеличиваться в связи с большим числом BDC, выполняющих частичные синхронизации.
ReplicationGoverner применяется для управления долей полосы пропускания, которую может использовать служба NetLogon, при выполнении проверки базы данных. По умолчанию используется значение 100 процентов сетевой полосы пропускания при использовании буфера размером 128 Кбайт данных. Это легко может поглотить весь канал на медленной линии связи между удаленными сайтами WAN. Задавая этот ключ как 50 процентов, тем самым изменяют две вещи. Теперь служба NetLogon будет обладать буфером в 64 Кбайта данных и иметь для сообщений синхронизации 50 процентов полосы пропускания.
Это значение не должно задаваться меньше 25, иначе синхронизация может никогда не закончиться. Однако можно использовать команду AT планировщика команд, чтобы задавать для этого параметра различные значения в течение дня. Например, можно задавать ReplicationGaverner равным 25 днем и равным 100 ночью. Конечно, это следует делать на каждом BDC, но проблема невелика.
