Я проектирую компьютерную сеть для средней школы и придумал следующее разделение обязанностей между серверами:
В ЛВС:
Контроллер домена Active Directory. DC будет служить ок. 130 устройств в локальной сети. Здесь работают DNS, DHCP и RADIUS.
Файловый сервер. Профили пользователей, обмен данными, почта.
Сервер приложений. SQL-сервер и несколько других программ, таких как IP-камера, контроль доступа в здание, система заказа обедов и т. Д.
В демилитаризованной зоне:
Интернет-шлюз. Предоставляет доступ в Интернет. Запускает Exchange, IIS и прокси для веб-кэширования.
Веб сервер. Debian GNU / Linux содержит несколько веб-сайтов и веб-почту.
Это пять серверов. Хотя я могу приобрести необходимое оборудование, кажется, много. И мне почему-то не нравится виртуализация серверов.
Если я использую этот дизайн, я бы хотел воспользоваться этим и запустить еще один AD DC на файловом сервере на случай, если что-то пойдет не так с первым сервером. Но профили пользователей хранятся на файловом сервере, поэтому, если файловый сервер выходит из строя, все выходит из строя.
Так что, возможно, я мог бы переместить данные на дисковый массив, подключенный как к AD DC, так и к файловому серверу. Оба они будут служить DC и файловым сервером. Я мог бы даже запустить вторичный DNS, резервный DHCP и резервный RADIUS на втором сервере, тем самым сделав все сервисы избыточными для небольшой дополнительной настройки.
Половина компьютеров в локальной сети может иметь первый сервер, настроенный как основной DC / DHCP / DNS, другая половина может использовать другой сервер в качестве основного для балансировки нагрузки.
Сервер SQL абсолютно важен для сервера приложений. Я мог запустить резервный SQL-сервер на первом DC. Другие приложения на сервере приложений не так важны.
Две машины находятся в демилитаризованной зоне. К сожалению, нам нужен сервер IIS в DMZ. В противном случае подойдет один сервер GNU / Linux. (Я бы использовал postfix вместо Exchange Server.)
У меня нет большого опыта в проектировании компьютерных сетей (за исключением очень маленьких сетей или отдельных серверов), и я хотел бы знать, является ли мой дизайн разумным и есть ли какие-либо врожденные недостатки.
Если есть хорошая книга по этой теме, дайте мне знать.
Вам нужна высокая доступность - возможность бесперебойной работы всего, когда что-то выходит из строя. Виртуализация - ключевая часть этого предложения. Я бы даже не подумал об этом без виртуальных машин.
Очень простая установка - это два физических сервера с большим количеством ОЗУ, запускающие VMware ESXI или HyperV в кластере и некоторое общее хранилище (например, iSCSI SAN). Я большой поклонник HyperV, особенно если вы получаете специальные образовательные цены на Windows Server Datacenter. Задайте системы таким образом, чтобы все могло работать на одном сервере, хотя, возможно, и не так быстро, как вам хотелось бы при нормальных обстоятельствах. В первую очередь это означает наличие достаточного количества оперативной памяти для всего. Если вы сделаете это, при нормальных обстоятельствах нагрузка будет сбалансирована между двумя серверами, но если физический хост выходит из строя, все продолжает работать, и никто не кричит на вас, пока вы это исправляете.
Виртуализация означает, что вы не ограничены количеством имеющихся у вас физических серверов (хотя вы ограничены их памятью и мощностью процессора). Это означает, что вы можете выполнять такие действия, как запуск двух контроллеров домена с DHCP, настроенным как роль отказоустойчивого кластера, или с разделением диапазонов DHCP. Вы также можете использовать новые функции Server 2012 для запуска постоянно доступного файлового сервера. То же самое и с избыточными серверами SQL. В обоих случаях вы говорите платформе виртуализации, что эти пары виртуальных машин должны храниться на отдельных физических серверах, поэтому даже если физический сервер умирает, никто не заметит.
Вам НЕОБХОДИМО иметь два контроллера домена. Все, что меньше, вызовет проблемы в будущем. Активный каталог связан со всем, и если он выйдет из строя, МНОГО вещей сломается. Что еще более важно, восстановить активный каталог намного проще, если в сети все еще есть работающий контроллер домена.
Ваша идея запустить свой файловый сервер в качестве второго контроллера домена не так уж и ужасна. Но запуск SQL на контроллере домена - не лучшая идея. Отдельные серверы для отдельных задач уменьшают вероятность поломки, дают вам больше контроля над временем простоя (мне нужно обновить SQL-сервер ... поэтому мне нужно на некоторое время отключить активный каталог ...) и значительно упрощает восстановление резервных копий, намного проще.
DMZ может обрабатываться сетями VLAN на тех же серверах или может быть отдельным физическим блоком, в зависимости от того, что вам нужно.
Лучший аспект виртуализации, помимо экономии кучи денег на покупке дорогих серверов, которые простаивают весь день, - это то, что она отделяет операционную систему от оборудования. Хотите обновить оборудование до последней и лучшей модели - нет проблем, не нужно переустанавливать Windows, просто установите гипервизор и перенесите виртуальную машину. Во многих случаях это можно сделать даже не выключая виртуальную машину, 0 простоев. ОС не знает, что такое новое оборудование, не требует переустановки драйверов, просто работает.
Работая в школе, вы, вероятно, имеете право на отличные скидки от Microsoft, поэтому я бы порекомендовал купить хорошую книгу по Hyper-V. При подборе оборудования - обращайтесь к продавцу. Dell, HP или кто-либо другой будут более чем счастливы показать вам настройку серверов и хранилищ, которые они уже протестировали на совместимость.
Избегание виртуальных серверов, безусловно, ограничивает ваш выбор. Вам следует пересмотреть это, если возможно.
Нет хорошего способа запустить несколько DHCP в сегменте. Более разумно запускать это как ресурс кластера для обеспечения высокой доступности. Второй DC необходим для того, чтобы такие вещи, как техническое обслуживание, происходили в обычные часы. Вы не указываете причину RADIUS, поэтому я предполагаю, что VPN. Это также должно быть избыточным, чтобы допускать неисправности и обслуживание.
SQL Server также нуждается в высокодоступном кластере для обеспечения гарантированного обслуживания.
Любопытен IIS в DMZ. Если вы собираетесь сохранить там веб-сервер * nux, используйте обратный прокси, чтобы сохранить роль IIS внутри брандмауэра. Таким образом, вы также можете сохранить роль Exchange на внутренних серверах.
Более важно учитывать рабочую нагрузку каждой роли, чем конкретную роль.
Вам также необходимо подумать о том, как вы хотите разрешить резервное копирование на таком большом количестве машин.
Посмотрите на использование кластера в качестве начальной стадии NAS для отказоустойчивого узла SAN - подключение iSCSI для снижения затрат. Вам также нужны резервные коммутаторы.