Масштабирование для крупных Enterprise-сред

При росте количества рабочих станций (свыше 1000 АРМ) или наличии распределенной географической структуры (головной офис + филиалы), топологию необходимо масштабировать.

  1. Выделение роли управления конфигурациями:

Агенты Puppet (на АРМ) создают высокую нагрузку на CPU и память при компиляции каталогов политик. В крупных средах роль Puppet Server (вместе со шлюзами интеграции) должна быть вынесена на выделенные серверы.

  • Преимущество: Ограничение влияния "тяжелых" операций компиляции политик на скорость ответа службы каталогов (LDAP/Kerberos), обеспечивающей быстрый вход (Login) пользователей.
  1. Мультисайтовая топология (Филиалы):

Если филиал связан с центральным офисом медленным или нестабильным WAN-каналом, в нем рекомендуется развернуть локальный сервер-реплику DD (Контроллер домена).

  • Преимущество: Пользователи филиала будут авторизоваться локально, не нагружая WAN-канал, а вход в систему останется доступен даже при обрыве связи с головным офисом.
  1. Топология репликации (Ring / Mesh):

При наличии более 4-х контроллеров домена не рекомендуется использовать топологию репликации "каждый с каждым" (Full Mesh) из-за избыточного служебного трафика. Рекомендуется проектировать топологию по принципу "Кольцо" (Ring) со связями в виде звезды (Hub-and-Spoke) для филиалов, где каждый КД имеет не более 2-3 прямых соглашений репликации с соседними серверами (Рисунок 3).

Рисунок 3 – Пример комбинации топологий Ring и Hub-and-Spoke для сложных систем