none
Архитектура домена RRS feed

  • Вопрос

  • Добрый день!

    Ребят, задам вопрос общего
    характера.

    Есть 5 зданий, все знания
    соединены 100мб сетью. (топология сети - звезда)

    Есть центральное здание, там
    сидят два сис. админа.

    В остальных знаниях есть по 2
    специалиста тех. поддержки.

    Количество пользователей - 800
    человек.

    Необходимо внедрить доменную
    структуру с нуля.

    Как должна выглядить доменная архитектура:

    Один лес?

    Один домен или несколько?

    Что делать с DNS?

    Если не сложно напишите в общих
    чертах.


    17 января 2013 г. 13:52

Ответы

  • Один лес, один домен, один сайт.

    Пара контроллеров в центре звезды (хотя не критично, смотрите сами где удобнее). Если каналы надежные, дополнительные контроллеры не нужны.

    DNS-серверы на контроллерах домена, зоны AD-интегрированные.

    Если специалисты техподдержки работают только с одним зданием, то разнести учетки соответствующих юзеров и компьютеры в отдельные OU и делегировать техподдержке необходимые права.


    MCITP:SA, MCTS:Exchange Configuring

    • Предложено в качестве ответа osr_MVP, Moderator 17 января 2013 г. 14:57
    • Помечено в качестве ответа WindowsNT.LVEditor 21 января 2013 г. 14:17
    17 января 2013 г. 14:08

Все ответы

  • Один лес, один домен, один сайт.

    Пара контроллеров в центре звезды (хотя не критично, смотрите сами где удобнее). Если каналы надежные, дополнительные контроллеры не нужны.

    DNS-серверы на контроллерах домена, зоны AD-интегрированные.

    Если специалисты техподдержки работают только с одним зданием, то разнести учетки соответствующих юзеров и компьютеры в отдельные OU и делегировать техподдержке необходимые права.


    MCITP:SA, MCTS:Exchange Configuring

    • Предложено в качестве ответа osr_MVP, Moderator 17 января 2013 г. 14:57
    • Помечено в качестве ответа WindowsNT.LVEditor 21 января 2013 г. 14:17
    17 января 2013 г. 14:08
  • Поддерживаю предыдущего оратора.
    только, если есть какие-то ненулевые шансы, что контора разрастется и станет распределенной, я бы сделал два домена: выделенный корневой и для всего остального. Но то я: старый камикадзе.
    DNS делать так, чтобы не было мучительно больно потом. В частности, не делать пространство имен совпадающим с внешними доменами компании. Тут подробнее: http://support.microsoft.com/kb/254680
    Права администратора доменов у минимума персонала: все остальные доступы только через делегирование.
    ну и так далее. Тут можно долго распыляться )


    Best Regards, Alexander Trofimov
    17 января 2013 г. 19:03
  • Лес один, домен один. В самом надёжном (питание, охрана/контроль доступа и т.д.) месте поместите два контроллера домена. Замечу, что если PDC будет не в центре звезды, то некоторая часть служебного траффика AD будет ходить по лучу дважды, но при 100Мбит/с это не составит какой-либо значимой загрузки. В каждом из зданий поместите по одному контроллеру домена: всё же, каналы между зданиями более подвержены падению. Да и с точки зрения безопасности (пожар, теракт, пьянка) лучше иметь работоспособную, реплицируемую  копию AD в другом здании. На каждом DC у Вас роль DNS будет автоматически, желательно на них же повесить и роль DHCP с соответствующей областью. Естественно, нужно делить на сайты по подсетям.

    Сергей Панченко

    18 января 2013 г. 3:18
  • Естественно, нужно делить на сайты по подсетям.


    Это зачем еще? 

    http://www.ereality.ru/reg184541.html

    18 января 2013 г. 7:07
  • Естественно, нужно делить на сайты по подсетям.



    Это зачем еще? 


    затем, чтобы клиентские компьюетры, сидящие в данном здании со всеми вопросами ходили к контроллеру домена, который находится в этом же здании (и, соответственно, в подсети, которая относится к этому зданию). это сделать не сложно, а надёжности и понятности управления добавит.

    Сергей Панченко

    18 января 2013 г. 7:32
  • Напоминаю что сеть 100 мб

    Понятности не добавит это уж точно.  А надежность?  Ну не знаю как часто падает у вас дома линк между пк и модемом или свичем? если все сделано с головой, то  кабель между домами 30 лет провисит\пролежит


    http://www.ereality.ru/reg184541.html


    • Изменено NTFrs 18 января 2013 г. 7:48
    18 января 2013 г. 7:43
  • если все сделано с головой, то  кабель между домами 30 лет провисит\пролежит

    Если всё сделано с умом... Если во дворе не начнут копать коммунальщики... Если, если, если...

    Вы лучше скажите, в чём проблема разбить на сайты по подсетям?!


    Сергей Панченко

    18 января 2013 г. 8:12
  • Понятности не добавит это уж точно
    Послушайте практиков: даже если контроллеры у вас будут только в одном здании и задачи маршрутизировать аутентификацию на данный момент не стоит - сделайте по сайту на каждое здание, ибо нагрузки лишней на администраторов это не создаст (5 подсетей привязать на начальном уровне так сложно?), а прозрачности добавит - в том числе и в логах... а уж если далее КД будут появляться по зданиям - сам ... велел...
    18 января 2013 г. 8:20
    Отвечающий
  • Естественно, нужно делить на сайты по подсетям.



    Это зачем еще? 


    затем, чтобы клиентские компьюетры, сидящие в данном здании со всеми вопросами ходили к контроллеру домена, который находится в этом же здании (и, соответственно, в подсети, которая относится к этому зданию). это сделать не сложно, а надёжности и понятности управления добавит.

    Сергей Панченко


    это потребует 5 лишних серверов, орагнизацию севрерной в каждом здании с скд, кондиционированием, резервным питанием, пожаркой и видеонаблюдением. при наличии надежных каналов в 100 мб все это будет слишком затратным по отношению к эффекту
    18 января 2013 г. 8:33
    Модератор
  • это потребует 5 лишних серверов, орагнизацию севрерной в каждом здании с скд, кондиционированием, резервным питанием, пожаркой и видеонаблюдением. при наличии надежных каналов в 100 мб все это будет слишком затратным по отношению к эффекту
    Зачем 5 лишних серверов???? вы о чём?! речь идёт о логической привязке подсетей к логическим же сайтам!
    18 января 2013 г. 8:42
    Отвечающий
  • это потребует 5 лишних серверов, орагнизацию севрерной в каждом здании с скд, кондиционированием, резервным питанием, пожаркой и видеонаблюдением. при наличии надежных каналов в 100 мб все это будет слишком затратным по отношению к эффекту

    Зачем 5 лишних серверов???? вы о чём?! речь идёт о логической привязке подсетей к логическим же сайтам!
    Вы понимаете о чем пишете? зачем  делать сайты если не делать в них КД?   для логического разделения есть OU

    http://www.ereality.ru/reg184541.html

    18 января 2013 г. 8:53
  • затем, чтобы клиентские компьюетры, сидящие в данном здании со всеми вопросами ходили к контроллеру домена, который находится в этом же здании (и, соответственно, в подсети, которая относится к этому зданию). это сделать не сложно, а надёжности и понятности управления добавит.


    это потребует 5 лишних серверов, орагнизацию севрерной в каждом здании с скд, кондиционированием, резервным питанием, пожаркой и видеонаблюдением. при наличии надежных каналов в 100 мб все это будет слишком затратным по отношению к эффекту

    Ну, допустим, что серверную с кондиционированием, бесперебойным питанием и сигнализацией всё равно придётся делать. Или рутер между сетью здания и каналом в центральное здание будет под столом валяться? Ну и контроллер домена может быть реализован на обычной PC-машине (которой не нужно кондиционирование), да ещё и можно сделать его RODC (тогда и охранять подступы к нему не особо надо). В вырожденном случае, в некоторых сайтах может и вообще не быть никаких контроллеров домена.

    Даже если DC только в центральной серверной будут жить (владельцу пяти зданий жалко денег на пять офисных компьютеров), и то есть смысл изначально разбить сеть на сайты по территориально-сетевому признаку. Уж, как минимум, ЭТО НЕ ПОМЕШАЕТ.

    PS. Не вижу ни одного логичного аргумента на тему "НЕ РАЗБИВАТЬ НА САЙТЫ". Скажите, в чём вред этого подхода. Готов изменить свою точку зрения.


    Сергей Панченко

    18 января 2013 г. 9:00
  • затем, чтобы клиентские компьюетры, сидящие в данном здании со всеми вопросами ходили к контроллеру домена, который находится в этом же здании (и, соответственно, в подсети, которая относится к этому зданию). это сделать не сложно, а надёжности и понятности управления добавит.


    это потребует 5 лишних серверов, орагнизацию севрерной в каждом здании с скд, кондиционированием, резервным питанием, пожаркой и видеонаблюдением. при наличии надежных каналов в 100 мб все это будет слишком затратным по отношению к эффекту

    Ну, допустим, что серверную с кондиционированием, бесперебойным питанием и сигнализацией всё равно придётся делать. Или рутер между сетью здания и каналом в центральное здание будет под столом валяться? Ну и контроллер домена может быть реализован на обычной PC-машине (которой не нужно кондиционирование), да ещё и можно сделать его RODC (тогда и охранять подступы к нему не особо надо). В вырожденном случае, в некоторых сайтах может и вообще не быть никаких контроллеров домена.

    Даже если DC только в центральной серверной будут жить (владельцу пяти зданий жалко денег на пять офисных компьютеров), и то есть смысл изначально разбить сеть на сайты по территориально-сетевому признаку. Уж, как минимум, ЭТО НЕ ПОМЕШАЕТ.

    PS. Не вижу ни одного логичного аргумента на тему "НЕ РАЗБИВАТЬ НА САЙТЫ". Скажите, в чём вред этого подхода. Готов изменить свою точку зрения.


    Сергей Панченко

    Ну я думаю вопрос не о стоимости пяти компов,  а о стоимости пяти серверных операционных систем

    Рутер стоит в обычном  шкафчик с прозрачной дверцей и прорезями под естественную вентиляцию.

    Сайты предназначены для ФИЗИЧЕСКОГО разделения  сетей и для настройки репликаций по медленным каналам связи

    Медленных каналов связи нет, репликации межсайтовой тоже нет, контроллеров в сайта нет.

    Внимание вопрос : Зачем ?

    "Скажите, в чём вред этого подхода." 

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



    http://www.ereality.ru/reg184541.html

    18 января 2013 г. 9:09
  • вреда может и немного, но смысла еще меньше. во всех рекомендация и в самом смысле существования сайтов сказано что сайт это множество хостов и подсетей связанных быстрыми каналами, 100 мбит подходит под то определение "быстрый" чуть более чем полностью. поэтому всю эту сеть из пяти зданий можно считать одним сайтом.

    ставить сервера на обычных писюках это уже не ИТ а кустарное ремесло ) и одно дело организовать одну центральную серверную и коммутационные помещения (или просто шкафы) в других зданиях, а другое 5 серверных.
    с другой стороны если в других зданиях очень много сотрудников, и уже есть серверные и сервера, то можно засунуть и контроллер, виртуальный например, хотя если все ресурсы все равно в центральном то наличие контроллера в других врядли поможет.

    18 января 2013 г. 9:12
    Модератор
  • Вы предлагаете лишних пять компов и лишних 5 лицензий на ос, ну и о кондиционировании. пожарке и тд уже говорили..  это вся требуха для того чтобы просто безцельно разбить на сайты?
    Складывается ощущение, что вы несколько не понимаете матчасти... ни о каких лишних единицах оборудования и экземплярах ОС мы не говорим... они не нужны... нужны лишь два десятка кликов мышью - не более...
    18 января 2013 г. 9:14
    Отвечающий
  • Вы предлагаете лишних пять компов и лишних 5 лицензий на ос, ну и о кондиционировании. пожарке и тд уже говорили..  это вся требуха для того чтобы просто безцельно разбить на сайты?

    Складывается ощущение, что вы несколько не понимаете матчасти... ни о каких лишних единицах оборудования и экземплярах ОС мы не говорим... они не нужны... нужны лишь два десятка кликов мышью - не более...
    вы не ответили ЗАЧЕМ нужны эти два десятка кликов?

    http://www.ereality.ru/reg184541.html

    18 января 2013 г. 9:20
  • вреда может и немного, но смысла еще меньше. во всех рекомендация и в самом смысле существования сайтов сказано что сайт это множество хостов и подсетей связанных быстрыми каналами, 100 мбит подходит под то определение "быстрый" чуть более чем полностью.

    Пропускная способность "100Мбит" - это вовсе не значит, что связь подходит под определение "быстрый канал". В связи вполне могут быть и временнЫе задержки: например, на коммутацию или преобразование сред (или Вы думаете, что между зданиями лежит витая пара?). Так вот, если через этот канал качаются файлы с фильмами со скоростью 10 МБайт/с, но пинг 64-мя байтами идёт секунду или более - это ни разу не "быстрый" канал.

    Да и в целом, учитывая, что сейчас Gigabit Ethernet - стандарт де факто, то 100 Мбит между зданиями - это уже не быстро... Внутри там ещё, поди, будет телефония, а то и видео. ;-)


    Сергей Панченко

    18 января 2013 г. 10:25
  • Домен один, лес один - это факт. Разбивать или не разбивать на сайты при канале в 100 Мбит/с зависит от того, на какой промежуток времени предприятие если что случится, сможет остановить свои бизнес-процессы и насколько сильно они завязаны на связь между филиалами. Ts не говорил ничего о надежности каналов или о том где будут хранится данные, или что нужна/не нужна автономность. Все это решается вместе с политикой компании, а не просто потому что надо или не надо..


    18 января 2013 г. 10:37
  • Ребят, спасибо большое!

    Абсолютно не ожидал такого внимания к данной теме.

    Надежность каналов обеспечивает Ростелеком.

    Это государственная контора, большого развития не ожидается.

    Сейчас все организовано на маршрутизаторах Cisco ("грубоговоря" одна большая сеть).

    Домен отсутствует вообще.

    Админы сидят только в одном здании, а в остальных зданиях находятся только тех поддержка, идея про один лес и домен мне нравится больше всего.

    Хочу уточнить про начальную структуру.

    Я создаю корневой домен contoso.com

    Далее а создаю уже "поддомен" msk.contoso.com и там завожу всех пользователей. так?

    18 января 2013 г. 11:06
  • Я бы оставил все в корневом домене. Выделенный корневой домен позволяет отделить администраторов уровня леса от администраторов служб уровня домена. В вашем случае он не нужен так как домен будет всего один.
    18 января 2013 г. 11:12
  • Надежность каналов обеспечивает Ростелеком.

    У-у-у... Ставьте DC в каждое здание без вопросов. И не потому что РОСТЕЛЕКОМ - плохая контора (а она не из лучших), а потому что каналы не контролируются Вами. А уж если от здания до здания админу нужно будет идти больше 5 минут, то тогда точно в каждом здание по DC. 

    Это государственная контора, большого развития не ожидается.

    ...

    Я создаю корневой домен contoso.com

    Далее а создаю уже "поддомен" msk.contoso.com и там завожу всех пользователей. так?

    Начнём с того, что домен создавать Вы будет contoso.local, а не contoso.com. Так будет лучше.

    Далее, заметьте, что один контроллер домена может быть контроллером домена только в одном домене. То есть, если Вы хотите создавать своих пользователей в домене третьего уровня msk.contoso.local (как рекомендовано гуру), то Вам нужно будет четыре контроллера домена минимум: два для contoso.local и два для msk.contoso.local. При этом, те же гуру рекомендуют хотя бы один КД иметь на физической машине, а не в виртуальной среде. Думаю, Вам вполне достаточно будет создать contoso.local и в нём и жить. О том, что администрировать среду с поддоменами (даже при пустом корне) гораздо сложнее, я уж и не говорю.


    Сергей Панченко


    • Изменено Daemon-GTC 18 января 2013 г. 12:02
    18 января 2013 г. 12:01
  • У меня для автора вопроса один совет: используйте главный принцип проектирования сложных систем - чем проще, тем надежнее и дешевле.

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


    Сазонов Илья http://isazonov.wordpress.com/


    • Изменено osr_MVP, Moderator 21 января 2013 г. 11:37 исправил опечатку в имени автора ответа
    20 января 2013 г. 14:17
    Модератор
  • Ребят, спасибо всем большое!

    Сейчас набросаю архитектуру. Сформулирую вопросы более четко.

    И представлю Вам на комментарии.

    Еще раз спасибо за проявленный интерес.

    21 января 2013 г. 11:30