В настоящее время у нас работает сеть из 800+ ПК и 20+ серверов, сетевая инфраструктура соответствует линиям Core Switch 10Gb-> Area Switch 2GB-> Local Switch 1GB-> Desktop. Все работает на оборудовании 3Com (1).
У нас есть 3 коммутатора областей для четырех областей (A, B, C, D объединены с ядром), к каждому коммутатору области будет подключено от 10 до 20 локальных коммутаторов. Также имеется резервный базовый коммутатор, меньший по мощности, но подключенный, как и основной базовый коммутатор.
У нас также есть система IP-телефонии. Компьютеры / серверы и коммутаторы находятся в диапазоне IP 10.x, телефоны - в диапазоне 192.168.x. Обычно компьютерам не нужно общаться друг с другом, кроме как в компьютерных лабораториях, но они должны иметь возможность общаться с большинством наших серверов (AD, DNS, Exchange, хранилище файлов и т. Д.)
Когда мы настраивались, было решено, что у нас должно быть 3 VLAN: одна для коммутаторов и компьютеров, одна для телефонов и одна для репликации серверов (это противоречило советам инженеров 3Com). С этого момента (2) сеть была стабильной и работала, но теперь мы начали переходить на среду SAN и виртуализации. Теперь разделение этой новой инфраструктуры на отдельные VLAN имеет смысл, и кажется разумным повторить, как настроены наши VLANS.
В настоящее время предлагается создавать виртуальные локальные сети в каждой комнате, т.е. компьютерная лаборатория с 5+ ПК должна быть собственной виртуальной локальной сетью, но если мы будем следовать этой модели, мы будем рассматривать по крайней мере 25 «новых» виртуальных локальных сетей. , плюс VLANS для SAN / виртуальных серверов. Что, как мне кажется, добавит чрезмерного количества администрирования, хотя, к счастью, я ошибаюсь.
Что может предложить лучшая практика? Есть ли определенное количество компьютеров, которые не рекомендуется переходить ниже / ниже в VLAN.
(1) Коммутаторы 3Com (3870 и 8800) маршрутизируют между VLAN иначе, чем это делают некоторые другие, для этого не требуется отдельный маршрутизатор, поскольку они являются уровнями 3.
(2) Иногда мы получаем высокие показатели отбрасывания или изменения STP, и иногда директор 3Com Network сообщает, что коммутаторы недогружены и медленно реагируют на эхо-запросы, или что коммутатор отказал, чтобы отключить сеть (все телефонные и компьютерные VLANS! , однажды, не знаю почему)
Похоже, кто-то в вашей организации хочет создать сети VLAN, не понимая причин, по которым вы это делаете, и связанных с этим плюсов и минусов. Похоже, вам нужно провести некоторые измерения и придумать некоторые реальные причины для этого, прежде чем двигаться вперед, по крайней мере, с безумной глупостью «VLAN для комнаты».
Вам не следует начинать разбивать локальную сеть Ethernet на сети VLAN, если у вас нет веских причин для этого. Две лучшие причины:
Устранение проблем с производительностью. Локальные сети Ethernet не могут масштабироваться бесконечно. Чрезмерные широковещательные рассылки или поток кадров в неизвестные места назначения ограничат их масштаб. Любое из этих условий может быть вызвано слишком большим размером одного широковещательного домена в локальной сети Ethernet. Широковещательный трафик легко понять, но лавинная рассылка кадров в неизвестные места назначения немного неясна (настолько, что ни один из других плакатов здесь даже не упоминает об этом!). Если у вас так много устройств, что таблицы MAC-адресов вашего коммутатора переполняются, коммутаторы будут вынуждены лавинно рассылать нешироковещательные кадры из всех портов, если место назначения кадра не соответствует ни одной записи в таблице MAC-адресов. Если у вас достаточно большой одиночный широковещательный домен в локальной сети Ethernet с профилем трафика, при котором хосты разговаривают нечасто (то есть достаточно редко, чтобы их записи устарели в таблицах MAC-адресов на ваших коммутаторах), вы также можете получить чрезмерную лавинную рассылку кадров. .
Желание ограничить / контролировать трафик, перемещающийся между хостами на уровне 3 или выше. Вы можете взломать трафик на уровне 2 (ala Linux ebtables), но с этим трудно справиться (потому что правила привязаны к MAC-адресам, а изменение сетевых адаптеров требует изменения правил) может вызвать то, что кажется действительно очень странным (выполнение прозрачное проксирование HTTP на уровне 2, например, причудливо и весело, но совершенно неестественно и может быть очень не интуитивно понятным для устранения неполадок) и, как правило, сложно выполнить на более низких уровнях (потому что инструменты уровня 2 похожи на палки и помогает справиться с проблемами уровня 3+). Если вы хотите управлять трафиком IP (или TCP, или UDP и т. Д.) Между хостами, а не решать проблему на уровне 2, вам следует подсеть и прикрепить брандмауэры / маршрутизаторы с ACL между подсетями.
Проблемы нехватки полосы пропускания (если они не вызваны широковещательными пакетами или лавинной рассылкой кадров) обычно не решаются с помощью VLAN. Они возникают из-за отсутствия физического подключения (слишком мало сетевых адаптеров на сервере, слишком мало портов в группе агрегации, необходимость перехода на более высокую скорость порта) и не могут быть решены путем разделения на подсети или развертывания виртуальных локальных сетей, поскольку это победило. Не увеличивайте доступную пропускную способность.
Если у вас нет даже чего-то простого, например, MRTG, отображающего статистику трафика по портам на ваших коммутаторах, это действительно ваш первый бизнес, прежде чем вы начнете потенциально введение узкие места с преднамеренной, но неинформированной сегментацией VLAN. Необработанный подсчет байтов - хорошее начало, но вы должны продолжить его целевым анализом, чтобы получить более подробную информацию о профилях трафика.
Когда вы узнаете, как движется трафик в вашей локальной сети, вы можете начать думать о сегментировании локальной сети по соображениям производительности.
Если вы действительно собираетесь попытаться ограничить пакетный и потоковый доступ между VLAN, будьте готовы много работать с прикладным программным обеспечением и изучать / перепроектировать, как он общается по сети. Ограничение доступа хостов к серверам часто может быть выполнено с помощью функции фильтрации на серверах. Ограничение доступа по сети может вызвать ложное чувство безопасности и убаюкать администраторов, когда они думают: «Ну, мне не нужно настраивать приложение. Безопасно, потому что хосты, которые могут общаться с приложением. Ограничены« сеть '. " Я рекомендую вам проверить безопасность конфигурации вашего сервера, прежде чем я начну ограничивать связь между хостами по сети.
Обычно вы создаете сети VLAN в Ethernet и назначаете им IP-подсети 1 к 1. Вам понадобится МНОГО IP-подсетей для того, что вы описываете, и, возможно, много записей в таблице маршрутизации. Лучше спланировать эти подсети с помощью VLSM, чтобы суммировать записи в таблице маршрутизации, а?
(Да, да - есть способы не использовать отдельную подсеть для каждой VLAN, но придерживаясь строго «простого ванильного» мира, вы должны создать VLAN, придумать IP-подсеть для использования в VLAN, назначить некоторый маршрутизатор IP-адрес в этой VLAN, подключите этот маршрутизатор к VLAN с помощью физического интерфейса или виртуального подинтерфейса на маршрутизаторе, подключите некоторые хосты к VLAN и назначьте им IP-адреса в указанной вами подсети и направьте их трафик в вне VLAN.)
VLAN хороши как дополнительный уровень безопасности. Я не знаю, как 3Com справляется с этим, но обычно вы можете разделить разные функциональные группы на разные VLAN (например, учет, WLAN и т. Д.). Затем вы можете контролировать, кто имеет доступ к определенной VLAN.
Я не верю, что есть какая-то значительная потеря производительности, если в одной VLAN находится много компьютеров. Я считаю непрактичным сегментировать LAN в каждой комнате, но опять же, я не знаю, как 3Com с этим справляется. Обычно ориентиром является не размер, а безопасность или эксплуатация.
По сути, я не вижу смысла даже сегментировать LAN на разные VLAN, если это не дает никаких преимуществ в плане безопасности или эксплуатации.
VLAN действительно полезны только для ограничения широковещательного трафика. Если что-то будет транслировать много, то выделите это в отдельную VLAN, иначе я бы не стал беспокоиться. Возможно, вы захотите иметь виртуализированное дублирование действующей системы в той же сети и захотите использовать тот же диапазон адресов, но опять же, это может стоить отдельной VLAN.
Если у вас нет 25 групп тестирования и разработки, которые регулярно уничтожают сеть широковещательными наводнениями, 25 виртуальных локальных сетей для каждой комнаты - это 24 слишком много.
Очевидно, что ваша сеть SAN нуждается в собственной VLAN, а не в той же VLAN, что и LAN виртуальных систем и доступ в Интернет! Все это можно сделать через один порт Ethernet в хост-системе, поэтому не беспокойтесь о разделении этих функций.
Если у вас проблемы с производительностью, подумайте о размещении вашего телефона и SAN на отдельном сетевом оборудовании, а не только на VLAN.
Всегда будет широковещательный трафик, будь то широковещательные рассылки с разрешением имен, широковещательные рассылки ARP и т. Д. Важно контролировать объем широковещательного трафика. Если он превышает 3-5% от общего трафика, то это проблема.
VLAN хороши для уменьшения размера широковещательных доменов (как заявил Дэвид), или для безопасности, или для создания выделенных резервных сетей. На самом деле они не предназначены для использования в качестве доменов «управления». Кроме того, вы усложните маршрутизацию и увеличите накладные расходы в своей сети, внедрив VLAN.
Как правило, вы хотите использовать VLAN только тогда, когда вам нужно поместить устройства в карантин (например, место, куда пользователи могут принести свои собственные ноутбуки, или когда у вас есть критически важная серверная инфраструктура, которая должна быть защищена) или если ваш широковещательный домен слишком высоко.
Широковещательные домены обычно могут иметь размер около 1000 устройств, прежде чем вы начнете замечать проблемы в 100-мегабитных сетях, хотя я бы снизил их до 250 устройств, если вы имеете дело с относительно шумными областями Windows.
По большей части современные сети не нуждаются в виртуальных локальных сетях, если только вы не выполняете этот карантин (конечно, с соответствующим брандмауэром с использованием списков контроля доступа) или ограничением широковещания.
Они также полезны для предотвращения широковещательной рассылки DHCP для доступа к нежелательным сетевым устройствам.