Существует множество статей, в которых описывается, как построить топологию репликации, и все причины этого, и все они сводятся к сохранению полосы пропускания и достижению приемлемого для вашей организации времени конвергенции.
На мой взгляд, репликация AD - это крошечный объем данных, и я думаю, что хотел бы настроить частоту репликации до абсолютной максимальной скорости. (Что составляет 4 раза в час внутри сайта и каждые 15 минут между сайтами, тогда как по умолчанию 1 раз в час внутри сайта и один раз каждые 180 минут между сайтами.)
Я просмотрел и нашел список портов и протоколов, используемых в репликации AD, и их очень много. LDAP, Kerberos, Ping (ICMP Echo), RPC и т. Д. Конечно, я жестяная банка создайте захват Wirehark для просмотра этого трафика, но это будет огромный массивный фильтр захвата, очень сложный.
Итак, мой вопрос:
Кто-нибудь знает способ измерить полосу пропускания, используемую репликацией AD? Я хочу проверить свое предположение о том, что это крошечный объем трафика, в основном не имеющий отношения к современной эпохе, когда самое медленное соединение составляет 3 Мбит.
Нет единого счетчика производительности, который представляет «общую» полосу пропускания, используемую Active Directory. Active Directory состоит из множества отдельных служб. И хотя существует множество комбинаций счетчиков производительности, измеряющих сетевой трафик, имеющих отношение к AD, эти счетчики можно комбинировать множеством различных способов, чтобы получить множество различных представлений о том, «какую полосу пропускания использует AD?» Например, вы хотите включать DNS-запросы и ответы или нет? Репликация DNS-зон? Вы хотите включить DFS репликацию sysvol или нет?
Однако ты прав. Я работал в производственной сфере, где график межсайтовой репликации был сокращен до 15 минут, и все работало нормально. Пока у вас есть пропускная способность для его поддержки, в этом нет ничего технически неправильного. (Для справки, это был домен из 3 сайтов с выделенными WAN-ссылками, в результате чего 3 сайта были объединены в конфигурацию с полной сеткой, примерно 50-100 компьютеров на сайт и всего 250 пользователей. Итак, небольшой домен.) И да, я думаю ваше предположение верно в том, что пропускная способность была намного меньше, когда AD была впервые разработана, а в наши дни у нас обычно гораздо более быстрые каналы, поэтому AD обычно не является бременем для наших сетей - даже через WAN или VPN-соединение .
В дополнение к perfmon вы также можете использовать Resource Monitor (resmon) и получить довольно хорошее представление о том, какие сетевые байты передаются различными важными процессами на контроллере домена, такими как lsass.exe, dns.exe, dfsrs.exe. , и т.д.
Или, если ваш контроллер домена является просто контроллером домена и не обслуживает кучу служб, не связанных с AD, просто посмотрите на общее количество байтов, переданных через сетевой адаптер, и вы получите довольно хорошее представление о том, какую пропускную способность использует ваш DC.
Изменить: Чтобы продолжить эту тему, еще одна вещь, которая усложняет задачу, состоит в том, что многие из этих счетчиков perfmon приходят и уходят, например \ DFS Replication Connections \ Bytes Received Per Second. "Экземпляры этого объекта появляются и исчезают как новые объекты подключения создаются, часто динамически.
Редактировать №2: Вот довольно приличная статья о пропускной способности AD и даже о некоторых хороших счетчиках производительности. Обратите внимание, что он довольно старый, однако проблемы с пропускной способностью тогда были важнее, чем сейчас, поэтому он все еще актуален для этого вопроса: http://technet.microsoft.com/en-us/library/bb742457.aspx
Имейте в виду, что после выхода Windows 2000 репликация стала более эффективной благодаря таким усовершенствованиям, как репликация связанных значений.