Большинство из нас знает, что нам нужно создать объекты подсети и связать их с объектами сайта в наших Active Directory. Это позволяет клиентам на сайте A аутентифицироваться на контроллерах домена на сайте A, получать правильные ссылки DFS и т. Д.
Как мне управлять этим в среде с тысячами подсетей? Буквально, тысячи подсетей, которые постоянно развиваются, добавляются и удаляются.
В идеале ответ не должен быть «наймите 50 администраторов».
Вам не нужно создавать новую подсеть для каждой отдельной подсети уровня 3, которую создают сетевые люди.. Вместо этого создайте подсети, соответствующие выделенным IP-адресам для всего сайта.
Вот небольшой пример.
Допустим, у вас есть два сайта. Назовем их «Нью-Йорк» и «Маунтин-Вью». Полный IP-адрес Нью-Йорка - 10.187.128.0/22. В Mountain View есть 10.187.132.0/22, но в 10.244.0.0/16 есть еще кое-что из старого мусора.
Сетевые специалисты разделят все эти адреса на крошечные подсети размером до / 29, их будут тысячи, но все они содержатся в этих блоках суперсети.
В AD, однако, сайту в Нью-Йорке нужна только определенная подсеть, а сайту Маунтин-Вью нужны только две определенные подсети. Они охватывают все возможные IP-адреса в соответствующих блоках.
Предполагая, что вам действительно «нужны» эти подсети и вы не можете сделать, как предлагает @MichaleHampton в своем превосходном ответе ...
Если вам не нравится идея нанять 50 администраторов AD, вы ударяете своих сетевых администраторов ближайшим жестким и грубым предметом, пока они не перестанут принимать такие принципиально ужасные дизайнерские решения.
На самом деле, я не могу придумать никакого земного оправдания тысячам ["настоящих"] подсетей.* См. «Сноску», помимо любопытства посмотреть, насколько большой беспорядок вы можете сделать из чего-то в лаборатории или тестовой среде, и любой, кто даже приблизится к такому количеству [«реальных»] подсетей, является крупной многонациональной корпорацией с рыночной капитализацией больше, чем ВВП большинства стран или является крупным национальным / транснациональным интернет-провайдером / провайдером хостинговых услуг. И в обоих случаях у них буквально есть десятки людей в штате, чтобы держать это в некотором роде.
В противном случае вы просто не сможете справиться с этим. Либо наймите десятки людей, чтобы разобраться с этим, либо измените структуру сети, чтобы ... меньше отстой ... и даже удаленно управлять ею будет меньше взвода системных администраторов.
Честно говоря, даже не пытайтесь. На нем написано «провал», «выгорание» и «ужасная идея». Пытаться - все равно что переставлять шезлонги на «Титанике» после того, как он врезался в айсберг. Любые улучшения, которых вы можете достичь, скоро будут омрачены и отменены, если вы погрузитесь в ледяную воду на несколько тысяч футов, так что вам, вероятно, лучше потратить время, лежа на шезлонгах, захватывая немного спиртного и покурив, и наслаждаясь этими последними моментами. прежде, чем тебя поглотит верная смерть. (И я не могу сказать, метафорически я здесь или нет, FWIW, я знаю 3 парней из ИТ, у которых были сердечные приступы до 35 лет от такого безумия.)
И, конечно, если вы не можете изменить мнение своего начальства или сетевой команды, ну, вы не можете жениться на корпорации в любой стране, о которой я знаю, поэтому лучшим вариантом может быть уехать. Никакая работа не заслуживает сердечного приступа после 30 лет.
*Сноска:
Под «настоящими» подсетями я подразумеваю подсети, которые фактически используются как таковые. Я был в средах размещенных услуг с тысячами клиентов, где каждый клиент получает простую плоскую подсеть, которая на самом деле не управляется и не изменяется поставщиком размещенных услуг, но это определенно не похоже на ваш вариант использования. Если это так, дайте мне знать, и я смогу скорректировать свой ответ, потому что с этим довольно легко справиться с помощью * базы данных AMP (или * AMP-подобного продукта).
«Научитесь писать сценарии» - хороший ответ. Предположительно, кто-то делает эти вещи по заранее составленному плану? Работайте по их плану, чтобы одновременно создавать / изменять / и т. Д. Эти сайты и подсети в AD.
Некоторые дальнейшие мысли - если это «постоянно развивается», включает ли это рабочие столы пользователей в эти подсети? Если этого не произойдет, то вам даже не нужно этого делать. Если да, то кто-то уже занимается постоянным изменением IP-адресов, областей DHCP и т. Д.? Возможно, вы могли бы им делегировать.
Еще одна мысль - если эти подсети не всегда находятся по каналам WAN (т.е. подсети, которые могут быть объединены в суперсети, хорошо связаны с высокоскоростными соединениями LAN), тогда просто сделайте так, чтобы сайты и подсети соответствовали суперсетям и не беспокойтесь об этом. вещи на уровне подсети. (изменить - это то же самое, что Майкл Хэмптон говорит в своем ответе и ссылке.)
В дополнение к ответу Майкла Хэмптона я хотел бы добавить следующее:
Существуют сценарии, в которых вам нужно подумать о том, как вы хотите, чтобы аутентификация и доступ к ресурсам работали, когда вы настраиваете ADS & S, а затем вам нужно соответствующим образом настроить ADS & S. В качестве примера предположим, что у меня есть три географически удаленных места как таковых:
Главный офис: Кливленд - 192.168.1.0/24 - Высокоскоростное Ethernet-соединение со вспомогательным офисом и два DC. Низкоскоростное WAN-соединение с DR-сайтом.
Сайт DR: Akron - 192.168.2.0/24 - низкоскоростное соединение WAN с главным офисом и вспомогательным офисом, имеет два DC. Репликация AD ограничена нерабочее время.
Спутниковый офис: Кантон - 192.168.3.0/24 - Высокоскоростное соединение Ethernet с главным офисом - Нет DC. Низкоскоростное WAN-соединение с DR-сайтом.
Теперь, если я создам сайт для каждого местоположения, в котором есть DC, и свяжу с этими сайтами только эти подсети, то по умолчанию клиенты в вспомогательном офисе будут пытаться установить сходство и аутентифицироваться с DC на сайте DR и получить доступ к ресурсам, которые используют Информация ADS & S (например, DFS) в силу того факта, что сайт DR является ближайшим сайтом AD к этим клиентам (с точки зрения уровня 3), что мне не нужно из-за низкой скорости WAN-соединения и того факта, что репликация AD происходит только в нерабочее время, и AD, вероятно, будет несовместима между главным офисом и сайтом аварийного восстановления (за исключением тех изменений, которые запускают срочную репликацию).
Итак, я бы создал и связал подсеть 192.168.3.0/24 с сайтом главного офиса. Это позволяет клиентам в вспомогательном офисе устанавливать привязку к DC и аутентифицироваться с ними, а также получать доступ к ресурсам на сайте главного офиса через высокоскоростное соединение Ethernet, чего я и хочу.