Аудит архитектуры сети, выявление слабых мест существующей ЛВС и построение отказоустойчивой системы

После согласования всех деталей с клиентом мы приступили к проведению аудита. Была проделана объемная работа — для исследования всей сети большого склада потребовалось несколько дней. Специалисты проверили всё оборудование, проанализировали конфигурации ядра сети, провели осмотр линков кабельных трасс и составили схему имеющейся на тот момент ЛВС.

Описание сети

ЛВС состояла из следующего активного оборудования:

• Центральный маршрутизатор Mikrotik CCR1009-7G-1C-1S+ — в серверной, использовался так же как контроллер точек доступа CAPsMan;
• Коммутатор с POE для точек доступа WiFi Mikrotik CRS328-24P-4S+RM — 1шт;
• Коммутаторы с POE для точек доступа WiFi Mikrotik CRS112-8P-4S-IN — 5шт;
• Стек из двух коммутаторов Eltex MES2348B, в серверной;
• Точки доступа WiFi Mikrotik секторные SXT2, всенаправленные WAP, секторные QRT2 в общем количестве 33 штуки — запитаны по POE.

По результату аудита ЛВС была составлена следующая схема сети.

В результате аудита локальной вычислительной сети были выявлены следующие слабые места:

1. Основной проблемой построения архитектуры по такому типу является большое количество возможных точек отказа. Так, при сбоях в работе коммутатора SW8-2 возникнут проблемы в соединении с несколькими точками доступа, в том числе связанными с коммутатором SW8-1. А отказ центрального коммутатора SW8-4 является крайне критичным — при выходе его из строя произойдет отказ работы всей беспроводной сети склада.
2. Также было обнаружено, что часть коммутаторов SW8-1, SW8-2, SW24-1. SW-K связаны с коммутатором SW8-4 оптическим патч-кордом. Данный тип кабеля не предназначен для длинных кабельных трасс и имеет слабую защиту от механических повреждений (заломов, порезов и прочее), что может привести к обрыву кабеля.
3. В качестве контроллера точек доступа CAPsMan используется маршрутизатор CCR1009, одновременно являющийся основным маршрутизатором сети. При выходе из строя данного устройства, перестает функционировать вся сеть.
4. На части коммутаторов отсутствует защита от неавторизованного доступа;
5. На оборудовании установлены отличающиеся версии операционной системы RouterOS;
6. Коммутаторы SW8-1 и SW8-2 установлены в 10” шкафах, чего недостаточно для грамотного размещения оборудования с учетом доступа для обслуживания. Также отсутствие свободного места плохо влияет на охлаждение оборудования, что может привести к его преждевременному выходу из строя.
7. Неоптимальное размещение оптических модулей в коммутаторах «друг над другом», при возможности их разнесенного размещения «по диагонали», что влияет на охлаждение модуля.

Для клиента был сформирован подробный отчет о проверке и описано текущее состояние системы. Мы предложили несколько возможных решений оптимизации сети.

Построение отказоустойчивой системы

Для построения стабильной сети требовалось добавить еще один коммутатор, который выполнял бы роль резервного, в случае выхода из строя основного. Помимо этого мы добавили дополнительные линки СКС. Новая архитектура сети строилась по топологии «Кольцо», схема представлена ниже:

На всех коммутаторах был включен протокол RSTP.
Приоритеты коммутаторов:
gw1 =0 (Главный маршрутизатор)
gw2=1 (Резервный маршрутизатор)
Остальные меняются с шагом в 100 от SW24-1 (100) до SW8-1

Таким образом корневым коммутатором сети (root bridge) будет выбран главный маршрутизатор, а в случае его неисправности — резервный.

На схеме также обозначены назначенные стоимости коммутации на линках. Большая стоимость в 10000 между коммутаторами SW-K и SW8-2 приведет к разрыву кольца на данном линке. Однако при любом обрыве текущих связей, этот линк будет использован для передачи данных. Перестроение STP займет 1-2 секунды и не скажется существенным образом на функционировании сети.

На резервном маршрутизаторе CCR1009 сделана настройка резервного контроллера точек доступа (CAPsMan), на которых, в свою очередь, настроено подключение к резервному контроллеру в случае недоступности основного (опция CAPsMAN Names).

Для определения неисправности одного из маршрутизаторов и переключения адресов на другой, был настроен протокол VRRP.

На резервном маршрутизаторе также настроен резервный DHCP-сервер с задержкой выдачи аренды на 10 секунд. Все статические записи аренды также соответствуют основному серверу.