none
Очень большой трафик между контроллерами домена. RRS feed

  • Общие обсуждения

  • Здравствуйте.
    Имеется головной офис, имеются филиалы, связаны через MPLS местного провайдера по 2Мбит/с.
    Имеется корневой контроллер домена cd.local, имеется дочерний контроллер домена ab.cd.local, в каждом филиале установлены дополнительные контроллеры домена ab.cd.local.
    Все сети сегментированы, настроены подсети и сайты, по которым соответственно распределены контроллеры домена ab.cd.local. Везде настроен транспорт DEFAULTIPSITELINK.

    Подключили снифер на зеркальный порт от пограниченого маршрутизатора и анализировали трафик.
    Так вот:
    1. постоянные запросы DCERPC, RPCNETL, EPM, DRSUAPI от контроллеров домена в филиалах на контроллер в головном офисе.
    2. запросы на подключения принтеров от комьпютеров в филиалах на контроллер в головном офисе.

    Вопросы:
    1. Зачем контроллеры домена постоянно общаются между собой (репликация настроена на 1 раз в час)?
    2. Какой трафик они гоняют по вышеприведенным протоколам?
    3. Что не так настроено (или какую дополнительную информацию предоставить чтобы это выяснить)?

    Очень хочется разобраться в ситуации и разгрузить каналы, помогите пожалуйста.
    17 января 2009 г. 12:47

Все ответы

  • Потому что у вас еще связь сайтов друг с другом настроена. Скорее всего. При этом, вместо того, чтобы все репликации шли только между филиалом и основной конторой, у вас каждый филиал еще и друг с другом реплицируется. Плюс обычным трейсертом посмотрите узкие места по MPLS каналам. У нас тоже подобное было. Ну и может помогут где искать вот эти темы
    http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=4291098&SiteID=40
    http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=3950588&SiteID=40
    И настройте репликации лучше на ночьSmile
    19 января 2009 г. 4:09
  •  Сергей Иванов написано:
    Потому что у вас еще связь сайтов друг с другом настроена. Скорее всего. При этом, вместо того, чтобы все репликации шли только между филиалом и основной конторой, у вас каждый филиал еще и друг с другом реплицируется.


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

     Сергей Иванов написано:

    Плюс обычным трейсертом посмотрите узкие места по MPLS каналам. У нас тоже подобное было. Ну и может помогут где искать вот эти темы
    http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=4291098&SiteID=40
    http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=3950588&SiteID=40
    И настройте репликации лучше на ночь

    Ok, попробуем.

    Спасибо. Может еще какие рекомендации имеются?
    19 января 2009 г. 6:21
  • Например они могут общаться между собой если это требуется для аутентификации.

     

    Еще вопрос - дочерние контроллеры домена являются серверами глобального каталога?

     

    Отдельный сайтлинк рекомендуется делать для каждого соединения между сайтами, потому что это позволяет более гибко настраивать репликацию. В вашем случае это ни на что не повлияет.

     

    http://sambaxp.org/uploads/media/06-Jean-Baptiste_Marchand_-_Active_Directory_network_protocols_and_traffic.pdf

     

    19 января 2009 г. 6:22
  • Если нужно, чтобы филиалы видели друг друга. Или не нужно.
    Дочерние контроллеры домена скорее всего сервера глобального каталога. У нас когда-то так было. Правда узость каналов 128-512 кбит все портила. Потому мы и пришли к выводу все перенастроить в изолированные домены с доверительными отношениями между филиалом и головной конторой.
    19 января 2009 г. 10:46
  •  Сергей Иванов написано:
    Если нужно, чтобы филиалы видели друг друга. Или не нужно.
    Дочерние контроллеры домена скорее всего сервера глобального каталога. У нас когда-то так было. Правда узость каналов 128-512 кбит все портила. Потому мы и пришли к выводу все перенастроить в изолированные домены с доверительными отношениями между филиалом и головной конторой.

    Да, так и есть, дочерние контроллеры сервера глобального каталога.

    Подскажите, где можно более подробно почитать про тонкую настройку сайтов и служб Acive Directory?

    19 января 2009 г. 12:18
  • Давайте так. Сколько процентов канала занимает у вас трафик?

     

    И почему вы решили что у вас что-то не так?

    19 января 2009 г. 14:49
  • Утилитой replmon пользовались?..

    19 января 2009 г. 17:17
    Отвечающий
  •  RuForce написано:

    Утилитой replmon пользовались?..

     

    А причем тут он? КД могут и другим трафиком обмениваться. Я бы порекомендовал воспользоваться утилитой типа PRTG

    20 января 2009 г. 3:26
  •  Yaroslav Turbin написано:
    Давайте так. Сколько процентов канала занимает у вас трафик?

     

    И почему вы решили что у вас что-то не так?

    Если у человека летят ошибки типа тех, которые я по ссылкам приводил, то ясно что, что-то не такSmile
    А так хотелось бы посмотреть на пинг от филиала до головной конторы и назад. Ну и трейсерт тоже. При стандартной работе филиала с конторой. Возможная проблема и на последней миле.
    К примеру, у нас вышестоящая контора висит на порту с 512 кбит. 22 филиала с каналами от 128 до 256. Стандарт на интервал проверки электронной почты - 30 минут. С письмами до 15 мегабайт размером. Плюс иногда RDP сверху. Плюс системы типа "Гарант" на вышестоящем конторском сервере. Плюс другие ресурсы на вышестоящем сервере. Иногда передача данных банальным копированием по сети в расшаренные папки от 50 мб до 4 гб.
    В один из моментов все было совсем жутко.  Потеря четверти пакетов (по результатам пинга) а то и более. Трейсерт показал что основной косяк на последней миле вышестоящей конторы. Ну и т.д.
    Так что не всегда нужны навороченные методы анализа.
    20 января 2009 г. 4:28
  • А кто тут писал про ошибки? Изначально писалось про непонятный трафик между КД.

     

    Основное преимущество "навороченных" утилит типа PRTG - ясная картина по полосе пропускания, какой тип трафика и в каком объеме идет, в какое время. Такой информации вам не даст никакой tracert. И такая информация вам позволит принять оптимальное решение. Может быть достаточно QoS, может быть необходимо расширение канала. Ну не сможете вы понять это сделав ping или tracert.

     

    Что же касается потерь пакетов при передаче, то гораздо более информативной утилитой является pathping

     

    P.S. Интересовался у специалистов MCS как они собираются информацию по сетевому трафику. Ответ "порадовал": запрашиваем информацию у заказчика. Ну как тут не вспомнить поговорку: консультанты странные люди, они задают вопросы, а потом вставляют ответы в свои отчеты.

    20 января 2009 г. 4:48
  • А вот кстати. Провайдер по MPLS у вас случаем не Уралсвязьинформ?
    Есть такая фича у УСИ, да и насколько знаю у многих подобных организаций - тех, что с советских времен существуют - телекомы там всякие. Они гонят MPLS канал как часть общего инетовского. В результате, при наличии многих пользователей - канал фактически снижается (официально вам говорят, что канал фиксированный, но в тарифе есть хорошая надпись - скорость до 2048кбит). Для интереса файлики по гигабайту туда-сюда погоняйте - посмотрите на фактическую скорость.
    20 января 2009 г. 5:56
  •  Yaroslav Turbin написано:

    Давайте так. Сколько процентов канала занимает у вас трафик? 
    И почему вы решили что у вас что-то не так?

    Давайте.

    1.Сказать конкретно сколько процентов невозможно, да это и не важно. Основная идея была ПОНЯТЬ зачем контроллеры домена постоянно обмениваются между собой "каким-то" трафиком по вышеназванным протоколам, когда репликации настроены на определенное время?

    2. Я привык понимать, что если я поднял, к примеру, DNS-сервер, то в сети появляется трафик по его протоколу только тогда, когда это нужно (запрос - ответ). В случае же с распределенной инфраструктурой AD трафик идет в любой момент времени. Вот с этим мне и хотелось бы разобраться.

    Пожалуйста, все участники дискуссии, еще раз прочитайте мой первый пост.

     RuForce написано:
    Утилитой replmon пользовались?..

    Да, пользовались. В логах - репликации один раз в час.

     Yaroslav Turbin написано:

    А причем тут он? КД могут и другим трафиком обмениваться. Я бы порекомендовал воспользоваться утилитой типа PRTG.

    Отлично, расскажите подробнее - каким и для чего? Или дайте пожалуйста ссылку на хорошую статью.

     Сергей Иванов написано:
    Если у человека летят ошибки типа тех, которые я по ссылкам приводил, то ясно что, что-то не так

    К счастью, об ошибках речь не шла.


     Сергей Иванов написано:
    А так хотелось бы посмотреть на пинг от филиала до головной конторы и назад. Ну и трейсерт тоже. При стандартной работе филиала с конторой. Возможная проблема и на последней миле.

    Раз так хочется, то пожалуйста:

    C:\>ping x.x.x.x

    Обмен пакетами с x.x.x.x по 32 байт:

    Ответ от x.x.x.x: число байт=32 время=27мс TTL=251
    Ответ от x.x.x.x: число байт=32 время=24мс TTL=251
    Ответ от x.x.x.x: число байт=32 время=21мс TTL=251
    Ответ от x.x.x.x: число байт=32 время=22мс TTL=251

    Статистика Ping для x.x.x.x:
      Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
    Приблизительное время приема-передачи в мс:
      Минимальное = 21мсек, Максимальное = 27 мсек, Среднее = 23 мсек

    При минимальной загрузке канала пинг около 1-2мс в близлежащих филиалах и около 5-6мс в сильно удаленных.

    Как Вы видите проблем на последней миле нет, ввиду того, что каналы по 2Мбит/с и почти все филиалы подключены к местному провайдеру по оптике.


     Сергей Иванов написано:
    К примеру, у нас вышестоящая контора висит на порту с 512 кбит. 22 филиала с каналами от 128 до 256. Стандарт на интервал проверки электронной почты - 30 минут. С письмами до 15 мегабайт размером. Плюс иногда RDP сверху. Плюс системы типа "Гарант" на вышестоящем конторском сервере. Плюс другие ресурсы на вышестоящем сервере. Иногда передача данных банальным копированием по сети в расшаренные папки от 50 мб до 4 гб.
    В один из моментов все было совсем жутко. Потеря четверти пакетов (по результатам пинга) а то и более. Трейсерт показал что основной косяк на последней миле вышестоящей конторы. Ну и т.д.
    Так что не всегда нужны навороченные методы анализа.

    Ну, в вашем случае другого и не могло быть: 22 филиала, со скоростью каналов до 256Кбит/с, ломятся в вышестоящую контору, где канал всего 512Кбит/с на всех. Как минимум нужно расширяться до 4Мбит/с (ну, конечно, в зависимости от используемых Вами сетевых информационных ресурсов). ИМХО.

     Yaroslav Turbin написано:
    А кто тут писал про ошибки? Изначально писалось про непонятный трафик между КД.

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


     Yaroslav Turbin написано:
    Основное преимущество "навороченных" утилит типа PRTG - ясная картина по полосе пропускания, какой тип трафика и в каком объеме идет, в какое время. Такой информации вам не даст никакой tracert. И такая информация вам позволит принять оптимальное решение.

    Обязательно попробуем эту программу, спасибо.

     Yaroslav Turbin написано:

    Может быть достаточно QoS, может быть необходимо расширение канала. Ну не сможете вы понять это сделав ping или tracert.

    Конечно нет. А QoS имеется, приоритет - IP телефония, видеоконференцсвязь и RDP.

     Yaroslav Turbin написано:
    А вот кстати. Провайдер по MPLS у вас случаем не Уралсвязьинформ?
    Есть такая фича у УСИ, да и насколько знаю у многих подобных организаций - тех, что с советских времен существуют - телекомы там всякие. Они гонят MPLS канал как часть общего инетовского. В результате, при наличии многих пользователей - канал фактически снижается (официально вам говорят, что канал фиксированный, но в тарифе есть хорошая надпись - скорость до 2048кбит). Для интереса файлики по гигабайту туда-сюда погоняйте - посмотрите на фактическую скорость.

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

    Еще раз повторю, дело не в загрузке каналов этим трафиком! Хочется понять: 1. Почему он есть. 2. Что там внутри? 3. Как от него избавиться? :-)

    20 января 2009 г. 7:22