Существует множество типовых инфраструктурных схем предприятия с количеством сотрудников до 300 человек. Объединят их одно, — разделение на уровни доступа, ядра и распределения. Показанная здесь схема является на мой взгляд наиболее оптимальной и при необходимости – масштабируемой и резервируемой для предприятия. По терминологии Cisco, сеть, где уровень распределения объединен с уровнем ядра — называется Collapsed core.
При построении инфраструктуры, мы должны учитывать следующие условия:
— быстрота работы сети
— удобство администрирования
Для обеспечения этих условия, мы обязательно должны установить в так называемый «уровень распределения» быстрый коммутатор 3 уровня, основная задача которого, перекидывать массивы данных из одних подсетей в другие. Ведь не секрет, что основной поток данных происходит внутри сети. И только незначительная часть уходит в Интернет или в филиальные сети. В связи с этим очевидно и второе условие правильной организации сети – разбивка на так называемые Виланы.
При этом я настоятельно рекомендую отделять рабочие подсети от серверных, гостевых и прочих подсетей. Если этого не делать, то мы со временем получим типовую ошибку роста, когда в одной подсети у нас находятся и сервера, и адреса коммутаторов, и рабочие станции, что неизбежно приведет к неравномерному пулу DHCP адресов и в конце концов к банальной нехватке адресного пространства и анархии. Кроме того, не забываем и о негативном влиянии подсетей с серьезным трафиком на рабочие станции. Это могут быть, например, десятки IP камер, которые генерируют немалый объем данных каждую секунду.
Таким образом даже для небольшого предприятия, мы должны разбить инфраструктуру на как минимум 4-5 подсетей, при этом необходимо заранее продумать развитие.
Уровень доступа в этом случае мы строим на коммутаторах 2 уровня, задача которых обеспечить подключение рабочих мест в тот или иной Вилан.
Любое предприятие на сегодняшний день, немыслимо без беспроводных сетей. Как минимум, необходимо развернуть 2 беспроводные сети, одна из которых – гостевая, и вторая – для небольшого количества сотрудников, которые по тем или иным причинам не могут воспользоваться кабелем. Делать всю инфраструктуру на беспроводных сетях – крайне не рекомендую. Ничто не заменит старого доброго медного кабеля, ни 5Ггц сети, ни новые стандарты. Не верьте маркетологам. Их задача работать языком, а не руками. При этом разгребать негатив пользователей придется именно Вам. Беспроводная сеть — только приятное дополнение к правильно построенной медной инфраструктуре. Наиболее оптимально использовать для построения сети – «аксесс поинты», каждый из которых одновременно раздает гостевой и рабочий SSID. Стандарт «де-факто» — это некоторое количество «аксесс поинтов» плюс контроллер управления, для бесшовного роуминга и балансировки нагрузки. Рекомендую использовать для этого оборудование Ubiquity™ с его бесплатным контролером, который можно поставить на гостевую виртуальную машину. Все аксесс поинты лучше всего приобретать с поддержкой PoE и подключать к отдельному коммутатору, умеющему подавать как данные, так и питание на беспроводные точки.
Следующее необходимое условие – использование Гипервизоров, с обязательным подключение SAN storage. Использование NAS можно оправдать только в том случаем, если компания совсем небольшая и используется его для файловых архивов, при этом гостевые машины расположены на непосредственно дисках сервера гипервизора. В любом случае нужно сразу закладывать в бюджет дисковую полку, подключенную по оптике. На серверах экономить не стоит. Минимально необходимым на сегодняшний день является 2 процессорный сервер с количеством памяти не менее 128Гб. Количество гипервизоров подбирается исходя из количества гостевых серверов + резерв на случай выхода одного из них из строя. При этом должно соблюдаться правило достаточности ресурсов при переносе гостевых машин с вышедшего из строя гипервизора на рабочие.
Каждый системный администратор отдает предпочтение тому или иному гипервизору, но я рискну посоветовать VMWARE ESXi, как наиболее приятное и стабильное на мой взгляд решение.
Предприятие обычно имеет филиалы, соответственно необходимо объединение сетей. В данной схеме такую функцию выполняет SRX 100 (ну и заодно как DHCP сервер для гостевой сети, чтоб не скучно ему было).
Делать на данном или ином другом маршрутизаторе выход в Интернет рабочей сети, я бы не стал советовать. Наиболее правильно организовать шлюз на любом ПО (Kerio, TMG и прочее подобное). Дело в том, что зачастую необходимо держать десятки правил для пользователей и кроме того мониторить активность пользователей. На мой взгляд, на софтверных решениях это сделать намного проще. То, что делается двумя кликами мышки в оснастке того же Керио, будет составлять десяток строк кода в «железном» маршрутизаторе.
Теперь рассмотрим сеть более детально.
Distribution level / Core
На коммутатор 3 уровня мы подаем провайдеров. В простейшем случае он может быть единственным поставщиком Интернет. Но стандартом является подача по меньшей мере двух. При этом сегодня тяжело представить, чтобы провайдер предоставлял Вам один единственный публичный IP. Нормальной является ситуация, когда Вы получаете пул адресов, которым назначаете какой-нибудь Vlan ID. На схеме это 100й и 200й Vlan. В дальнейшем мы их прокидываем на наш Гипервизор, чтобы опубликовывать на интерфейсах гостевых серверов нужные нам внешние адреса.
Перво-наперво, мы создаем Вилан управления, в котором будут адреса всех коммутаторов и вспомогательных устройств, например точки доступа WiFi. Крайне не рекомендуется использовать default vlan (распространённая ошибка). Например, у оборудования Juniper, default vlan=0, а у Cisco он равен 1. Нам ведь не нужны проблемы? Поэтому для управления создадим допустим 11 Вилан в котором раздадим адреса на все оборудование.
Теперь в соответствии с нашим планом, начинаем на данном коммутаторе создавать все задуманные Vlans. В данном примере это 2,3,4,5,10,50,55, 100, 200 и конечно 11, на часть из которых «повесим» IP адреса, которые будут являться шлюзом по умолчанию соответствующих подсетей.
Следует помнить, что, опубликовав Vlans, мы автоматически разрешаем маршрутизацию между ними. Поэтому нет необходимости отдельно описывать маршруты. Все автоматически работает на уровне ядра коммутатора L3.
Транспортный вилан необходим для простоты маршрутизации в филиалы. Допустим у нас на маршрутизаторе SRX работает несколько туннелей. Когда мы посылаем пакет в филиальную сеть, наш ex4200, который ничего о ней не знает, но у него расписаны статические маршруты, перекидывает пакеты на SRX, который уже сам знает что с ними делать 🙂 .
Обратные маршруты работают так же. SRX ничего не знает о внутренних сетях 10.1.2.0/24 и прочих, но для этого надо перебросить пакет на ex4200, который уже разберется с ними по свойски.
К коммутатору подключаем все наши L2 коммутаторы с помощью транков, на которых разрешаем хождение тех или иных подсетей.
Access level
Здесь все проще. Коммутаторы второго уровня должны обеспечивать подключение пользователей к той или иной подсети. Описываем на портах нужный вилан и подключаем пользователей.
В качестве коммутатора доступа для IP видеокамер и точек доступа wifi, я рекомендую использовать Cisco SG300 серию. При небольшой цене у него есть одно достоинство – PoE, что позволяет весьма красиво подключать эти устройства. Устройство несмотря на примитивный вебинтерфейс (консоль отсутствует) обладает неплохой производительностью и надежностью.
WAN Level
В данном примере указан SRX100, который обладает достаточной производительностью. Он в состоянии разобраться с шифрованным трафиком на скоростях до 65Мбит. Если сумма туннелей, которые он «держит», требует бОльшей полосы пропускания, то нужно поставить более мощное железо. Скажем SRX 210 или 240. Заранее продумать требуемую производительность достаточно тяжело. Допустим в аналогичной схеме на 15 филиалов, с каналами по 5-10Мб каждый, суммарный трафик через SRX100 редко превышал 20 Мбит. На данном маршрутизаторе можно вполне развернуть и DHCP сервер для гостевого WiFi и «пробросить» его на точки доступа.
Гипервизор
Здесь выбор «железа» обширен. Хотя мне больше нравиться железо от HP 🙂 . Комплектуем его FO картами и подключаем SAN от одноименной фирмы, на котором уже будут жить все наши гостевые сервера. Единственное исключение, где нам стоит воздержаться от виртуализации – это сервер под 1с. Эта шайтан-программа однозначно требует физического сервера с SSD дисками. Но обсуждение данного решения выходит за рамки этой заметки.
Данный пример конечно же не претендует на слепое копирование. Это скорее повод для обдумывания и развертывания исходя из имеющегося оборудования. Но основной принцип остается неизменным. Быстрая работа уровней доступа и распределения, достигается достаточно серьезным оборудованием.