конфигурация сети - посоветуйте
 

Ребята подскажите, пожалуйста.
Поставлена задача - реорганизовать сеть нашего предприятия. А именно.
У нас четыре юр.лица и руководство хотело бы, чтобы каждое из них имело свою сеть. Ну да ладно - то, что хочет руководство это пожелания, но они, само собой, не специалисты в этом вопросе - решать доверено это дело мне. Так вот.
Посоветуйте каким образом лучше структурировать сеть. Дано: в каждом этом сегменте будет свой сервер и по 8 рабочих станций (для начала, дальше они будут расти). Основная задача сервера - базы 1С, к ним подключаются в терминальном режиме. Значится какие есть варианты.
Вариант первый (типа: все гениальное просто)
Сделать четыре рабочих группы. Адресация у всех одинаковая, типа: 192.168.0.1/254. Вот, в сущности и все. Все, вроде как, должно работать и, на мой взгляд, никаких подводных камней в себе эта структура не несет. Разве что только - не хотелось бы иметь дело с рабочими группами - домены, все же, лучше. Впрочем - если есть аргументы в обратную сторону с удовольствием к ним прислушаюсь.
Вариант второй (сложнее, но интереснее - склоняюсь к нему)
Сделать четыре доменных дерева в одном лесу. И тут уже возникают вопросы.
1. Будет ли все работать хорошо, если в этой структуре будет один DHCP-сервер? Рабочие станции с других доменов примут динамическую адресацию? Никаких подвохов не будет? А если сделать так: разбиваем диапазон 192.168.0.1/254 на 5 частей (приблизительно по 50 IP) и на каждом контроллере домена делаем свой DHCP который выдает адреса только со своего диапазона? Вроде как отказоустойчивость должна быть отличной? Никаких же конфликтов в этом случае не предвидится? И опять же: была сказана мысль, типа, чтобы все работало так: взяли организацию и отправили ее со своей техникой в далекие края - в этом случае ведь этот домен вообще ничего не связывает с другими, он совершенно автономен и функционален? Я прав? Или есть подводные камни?
2. Насколько сложно настроить, в этой ситуации, доверительные отношения между доменами? Или это просто? Или, опять же - есть подводные камни? Чтобы соответствующие пользователи имели доступ к необходимым ресурсам в других доменах - ведь ничего сложного в этом нет?
3. Как уже говорилось - основная задача серверов - базы данных 1С. Люди работают в терминальном режиме. Вариант когда контроллер домена стоит на отдельном сервере и помимо этого в этом домене есть сервер баз данных - этот вариант пока нецелесообразен, дороговато пока. Отсюда вопрос: контроллер домена работает еще и как сервер баз данных - это нормально, ничего страшного не случится? Что можете сказать по этому поводу?
4. Относительно настройки DNS - на каждом контроллере домена установить планирую DNS. Никаких подвохов в этом не вижу. Что скажете?
Ух!
Вот такие вопросы, дальше еще может появятся.
Уважаемые - будьте добры, посоветуйте - с чем могу сложным столкнутся, что не учел, как можно сделать лучше.

C DHCP проблем точно не будет.
“Сделать четыре доменных дерева в одном лесу” – доверительные отношения установятся автоматом, будут транзитивными и двусторонними.
С DNS тоже проблем никаких, делать интегрированные, если не ошибаюсь, областью "репликации DNS" можно сделать все контроллеры леса со службой DNS.

Только вот ради каждых 8 рабочих станций держать контроллер домена, ещё и с учётом того, что не рекомендуется службы AD и TS держать на одном сервере...

А почему просто не сделать один домен, а остальное, если уж нужно, рулить организационными единицами?

В принципе да, но только если руководить ВСЕЙ структурой будет одна команда. Подвохи могут быть с динамической регистрацией рабочих станций в DNS, но, по идее, это можно обойти.
Лучше взять им разные диапазоны - на будущее. Тебе не жалко, а работы потом будет меньше. Да и чисто психологически удобнее их по разным подсетям раскидать.
Не прав. Мастер схемы и мастер контекста именования один на весь лес. Так что если ты один домен (не корневой) отправишь в далекое автономное плавание, то рано или поздно в нем возникнут проблемы. Например, exchange зачастую поставить или обновить серьезно не сможешь. Или добавить поддомен в это дерево.
Все сказано товарищем gluon
Ну вообще, конечно, рекомендуется разводить такие роли. Но, в принципе, ничего страшного в данном конкретном случае не предвидится, кажется. По этому поводу лучше обратиться к докам на technet по поводу SQL.
Да. Правильно. На каждом DC DNS сервер. С интегрированными зонами.

Теперь дальше - почему действительно не сделать отдельные OU для каждого юр. лица. Слишком уж громоздко получается все на несчастных 30 юзеров 4 домена. То есть, если следовать рекомендациям MS - минимум 8 DC. В принципе вариант имеет право жить, если есть бизнес-требования, заставляющие сделать именно так, но очень уж затратно получится. И с точки зрения единовременных затрат и с точки зрения администрирования.

UPD: Кстати, очень толково вопросы задаете, товарищ =)
Приятно отвечать. Всем бы так.

Смущает именно это пожелание - чтобы все эти подразделения были, типа, автономными. Вроде того - одно юр.лицо снялось и уехало в дальние края. Думаю, что без контроллера домена они далеко не уедут? Или как?

Kravetz
Если их немного, то уедут. Но опять таки при наличии канала до центрального оффиса. Если каналов нет, то в любом случае, уехать они могут только при наличии на каждую контору своего леса. ИМХО.

Вот с этим раньше дело не имел - это если честно. А каким образом будет связь между подсетями? Что необходимо? Типа - маршрутизацию поднимать? А где и как? Добавлять дополнительные сетевые интерфейсы на серверах? Или роутер покупать и настраивать? Вот только на знаю толком как его настраивать. Компы из нашей сети хотят в интернет через роутер - не будет проблем с настройкой если появятся четыре подсети и все они пойдут в этот самый роутер? Я просто туго себе это представляю - подскажите, пожалуйста.

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

Вам спасибо за ответы! Реальное спасибо - ибо я понимаю, что не каждому захочется терять свое время отвечая на различные вопросы.

Ну так и пускай едут с контроллером, в этом смысле ситуация с лесом или одним доменом мало чем отличаются, всё равно придётся их как то связать (через Интернет… VPN). Если же речь идёт о “полной автономии”, т.е. уехали и связи никакой, то (как уже говорил KomatoZo) решение с лесом не подойдёт, только изолированные домены (леса) и трастинг руками. А вообще при уезде 8 рабочих станций на новом месте можно сеть и с нуля сделать.

… ну да, ежели всё же лес… можно с “уезжающими” отправить “клон” первого контроллера первого домена (с нужными ролями) (двоеточие правая скобка)

Ну допустим тогда такой вариант.
Значится так:
делается один домен, у него один контроллер домена с DHCP и DNS.
В этом домене создаю четыре подразделения (по количеству юр.лиц). У них у всех свои 1С базы. А если сделать так - на мой взгляд для каждого подразделения по одному серверу на 1С базы как-то жирно получается - может сделать мощный сервер и все базы разместить там - соответственно дать доступ нужным бухгалтериям только к своим базам. Можно съэкономить на покупке лишних серверов. Я нигде не ошибаюсь - я не специалист в 1С, но, насколько понимаю - каждая бухгалтерия работает со своими базами и никто друг другу не мешает? В этом случае можно было бы обойтись тремя серверами - контроллер домена и два для баз. В принципе - для такого количества рабочих станций (ведь их пока немного) хватило бы и одного хорошего сервера - ведь так?
Если начальство хочет - можно разделить доступ из одного подразделения в другое - чтобы не шастали где не нужно, а кому нужно дать разрешение шастать где хочет.
Допустим возникает ситуация когда нужно уехать юр.лицу - делаем ему сервер - дополнительный контроллер домена, копируем базы 1С - и пусть катит? Или даже, в принципе - просто копируем базы на носитель. Приходим на новое место, берем новый сервер - поднимаем домен, ставим 1С, копируем обратно базы и все будет работать? Ведь так? Я нигде не ошибаюсь?
Ух! Мне кажется, что это оптимальный вариант.
Подкажите уважаемые - что думаете по этому поводу.

Спасибо Вам за участие в моей проблеме!

Можно поднять роутер между ними. Железный или софтварный - дело вкуса, денег и желания научиться. Железный это как правило какая нибудь Cisco (минусы - придется учиться, плюсы - за такое обучение зарплата не понижается а вовсе даже наоборот=) ). Если брать какой нибудь бестолковый роутер а-ля SOHO, то лучше уж поднять отдельный сервачок-маршрутизатор.
Как я поступил бы в конкретной ситуации - сказать сложно. Это уже вопрос дизайна домена AD. Очень много разных параметров. Но MS везде твердит, что основанием для раздела на многие домены могут быть только законодательные требования и/или желание предельно изолировать управление. Ни того ни другого я не вижу. Делать отдельные леса - это вообще в случае если организации с совсем раздельным управлением. Так что лично я вижу только вариант с OU - но это опять-таки на вкус и цвет каждого. Кроме того вы там, а я здесь. Возможно я чего-то не допонимаю. Разделить все юр. лица можно на уровне разрешений и/или полномочий. Только надо заранее продумать структуры OU, сайтов, GPO, политик безопасности и разграничения доступа.
Еще совет: не пожалейте времени... Найдите и пролистайте книжку по AD. Можно хоть учебник по MS для экзамена 70-294. Очень полезное чтение как раз в вашей ситуации. А уже потом решайте.
К сожалению - не совсем правильно. Я уже говорил про ограничения, связанные с наличием канала связи и репликациями. под всем остальным готов подписаться. Разве что в 1С я тоже не секу =)

Всё верно, не понял только точного значения фразы “делаем ему сервер - дополнительный контроллер домена”, судя по следующей фразе “берем новый сервер - поднимаем домен” вроде имеется в виду всё же создание изолированного домена никак не связанного с “первоначальным”, или всё же ещё один контроллер в том же домене, отправляем его на удалённую площадку и налаживаем связь? Тогда действительно придётся слегка попариться… почитать книжки к экзаменам 70-298, 70-299, 70-350…

… по 1С (...необходимому количеству и "качеству" серверов) трудно давать рекомендации ничего не зная о исходных данных и условиях проекта (7.7 или 8.0, SQL или dbf , какие конфигурации, сколько пользователей, скольким нужно работать одновременно, что они делают и насколько интенсивно… может и TS не нужен), теоретически на одном сервере может стоять любое количество баз, и перетащить любую из них на другой сервер – не проблема

=)
Попариться действительно прийдется. Особенно, если не охота потом локти кусать. Начинать все-таки рекомендую с 294. Может быть 293, но я ее еще не читал. 298 как-то не впечатляет, оно скорее для именно проектирования системы безопасности, чем для конкретного внедрения. Скорее 299. 350 - да, если будешь через ISA все делать.
Для удаленной площадки можно поднимать отдельный домен, но я уже говорил - не вижу причины. Можно отдельное OU и, как следствие удаленности площадки, отдельный site. DC там можно не ставить, если количество юзеров меньше 50ти, но тогда нужен надежный канал. Именно надежный, а не толстый. Толщина может быть достаточно небольшой при таком количестве ресурсов. Если канал может падать - лучше поставить там DC и настроить кеширование членства в универсальных группах. Ну и т.д. В общем, даже по-хорошему завидую - самому так и не довелось поднять что-либо подобное с нуля. Обычно приходится либо в пределах одного сайта-домена крутиться, либо перекурочивать сделанное кем-то =)

Да, именно имеется в виду новый домен никак не связанный с изначальным.

По поводу 1С - версия 7.7, базы dbf. Комплексная конфигурация. Все работают в терминале - удаленный рабочий стол. Всего около 28 пользователей - это максимум на текущий день. Какой должен быть сервер, чтобы это потянуть. 2*Intel Xeon 2.6 Ghz + 4 Gb ОЗУ - хватит?
И еще: хотелось бы иметь лицензионное ПО - стандартный вариант Windows 2003 Server Standart Edition + 5 клиентских лицензий. Отсюда очередной вопрос: клиентов-то больше. Но, тем не менее, будет ли работать ОС без глюков? Или ругнется на число подключений? Соответственно придется докупать еще лицензии. Либо все будет работать и так, просто превышение пользователей это нарушение лицензионного соглашения.

Если не связанный, то это отдельный лес. Со всеми вытекающими.

я думаю, с запасом, если, конечно, все не бросятся годовые отчёты строить или что-нибудь в этом роде, в “пиковые” моменты косяки возможны (и дело не столько в железе сколько в архитектуре "1С 7.7 dbf"), но и здесь ситуация облегчается тем, что, насколько я понимаю, все сидят не на одной базе, как уже говорил, не рекомендую использовать этот же сервер в качестве контроллера домена

рад бы что-нибудь сказать про лицензирование, но “не приходилось сталкиваться с подобными проблемами”

2003-й в домен не будет пускать, CALы придётся докупать для каждой станции, стоит ~ 60 у.е. для одной рабочей единицы.