Как стать автором
Обновить
1862.01

Вопросы построения сети. Проприетарное рабство, отказоустойчивость и модульность (часть 1)

Время на прочтение 5 мин
Количество просмотров 8.6K

Введение

Сегодня расскажем как построить максимально отказоустойчивую сетевую инфраструктуру предприятия, с минимальной привязкой к конкретному вендору, преимущественно на открытых протоколах и стандартах.

Условно говоря, сетевую инфраструктуру можно разделить на ряд компонентов:

  1. ЛВС (локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.3.

  2. БЛВС (беспроводная локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.11, так или иначе интегрированная с ЛВС.

  3. Вспомогательные системы (система управления IP пространством, инвентарная система, система описания сетевых сервисов, системы мониторинга).

Сегодня начнем с ЛВС.

Долой проприетарное рабство!

Каждый производитель активного сетевого оборудования предлагает свои проприетарные решения для упрощения настройки администрирования сети, для построения высоко надежных и отказоустойчивых систем. И эти решения могут быть вполне себе эффективными и полезными. Но у проприетарных решений есть недостатки:

  1. Появляется зависимость от конкретного производителя, в случае необходимости замены оборудования или масштабирования сети не так просто перейти на другого производителя;

  2. Повышаются и сужаются требования к персоналу (инженер должен знать конкретные решения конкретного производителя);

  3. Усложняется процесс поиска и устранения неисправностей и усиливается необходимость контракта на техническую поддержку производителя.

Поэтому мы строим вендор-независимую отказоустойчивую сеть, для этого необходимо минимизировать использование проприетарных протоколов — отдаем предпочтение открытым стандартам. Плюсы отказа от объединения физических коммутаторов в кластер или стек:

  • Минимизация масштабов простоя сервиса в случае сбоя в ПО на одном из физических коммутаторов — это не приведет к сбою всего виртуального коммутатора или стека, и, как следствие, простою сервиса;

  • Унификация настроек коммутаторов (первый порт это всегда Gi1/0/1, а не Gi3/0/1);

  • Минимизация использования проприетарных технологий и минимизации зависимости от вендора;

  • Минимизация масштабов простоя сервиса в случае обновления ПО и перезагрузки. Несомненно, производители предлагают механизмы обновления ПО без простоя, но это на данный момент не все производители умеют, и не все инженеры будут изучать мануал, а если и будут, то все равно попросят maintenance window у бизнеса для перестраховки;

  • Минимизация простоя сервиса в случае ошибки по причине человеческого фактора. Например, если администратор случайно перезагрузит коммутатор доступа, то перезагрузится только 1 устройство, а не стек из Х коммутаторов. А если инженер случайно перезагрузит коммутатор распределения или ядра, то простой сервисов ограничится только временем сходимости сети;

  • Простота замены оборудования: достаточно скопировать бэкапный конфиг и подключить устройство в сеть, без сложных и рискованных процедур по объединению оборудования в стек или кластер; никогда не знаешь наверняка, все ли пройдет без сбоев и перезагрузок.

Минусы отказа от объединения физических коммутаторов в кластер или стек:

  • Потребуется увеличение количества физических линков (удорожание СКС). Отказоустойчивость или дешевизна, нужно выбрать одно;

  • Усложнится (сделается не loop free) L2 домен (этим пугают производители, предлагая проприетарные решения). Решается грамотной настройкой выбранного протокола группы STP;

  • Усложнится процесс администрирования, так как будет больше логических устройств. Решается применением автоматизации, которая не предусматривает подключение к оборудованию инженерами “руками” для решения рутинных задач;

  • Замедлится сходимость сети — это явный минус. Если стоит задача максимально ускорить сходимость сети и если сходимость сети в 1 минуту уже очень долго для бизнеса, лучше присмотреться к проприетарным решениям, так как любой протокол группы STP в этом случае будет проигрывать.

Отказоустойчивость (больше линков, больше железа, меньше технологий)

Active-passive vs active-active

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

Пример построения сети на L2:

Три кита отказоустойчивости:

  1. Резервирование линков. Каждый логический канал между активным сетевым оборудованием должен состоять как минимум из двух физических каналов;

  2. Резервирование оборудования. Каждый логический модуль уровня ядра и распределения должен состоять из двух физических устройств;

  3. Грамотная настройка оборудования.

Резервирование линков и оборудования

  1. Потребуются две серверные для построения территориально-распределенных компонентов ЛВС, чтобы минимизировать влияние аварии в одной из серверных на работу всей сети. Под авариями подразумеваются такие события, как продолжительное отключение электропитания, физическое повреждение каналов связи, пожар, поломки оборудования и пр;

  2. Потребуется два провайдера Интернета (или других сервисов) до каждой серверной (оптика). Оптические трассы могут быть перекопаны техникой, поэтому важно еще иметь дополнительный линк провайдера по радио.

Три источника проблем

  1. Неправильная настройка оборудования. Все может отлично работать, и даже продолжительное время, но какой-то внешний фактор может нарушить работу сети;

  2. Человеческий фактор. Настройка и администрирование оборудования человеком рано или поздно приведет к ошибкам. Человек не может выдавать одинаковый результат втечение продолжительного времени. Например, если администратор вот уже Х лет не делал ни одной ошибки, не факт что завтра он не спутает консоль коммутатора доступа с консолью коммутатора ядра;

  3. Поломки оборудования.

Модульность (занудно, но важно)

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связанных между собой модулей (Wi-Ki).

В зависимости от требований бизнеса, сетевую инфраструктуру удобно разделить на несколько логических компонентов (модулей), например:

  • Модуль ядра сети (коммутаторы ядра сети) предназначен для быстрой коммутации и маршрутизации, объединения других модулей в единую систему. Чаще всего это будут два коммутатора, которые производители позиционируют как “Core Switch”. Лучше территориально разнести по разным серверным;

  • Модуль кампусной сети (коммутаторы уровней распределения и доступа). Каждый логический коммутатор уровня распределения должен состоять из двух физических коммутаторов, лучше территориально разнести по разным серверным. Коммутаторы уровня доступа должны состоять из одного физического коммутатора. В случае надобности подключения оконечных сетевых устройств, требующих питание по active PoE, необходимо предусмотреть коммутаторы доступа с поддержкой active PoE. При этом должен быть отражен расчет бюджета PoE;

  • Модуль подключения серверного оборудования. Как правило, модуль представляет собой набор из межсетевых экранов, высокопроизводительных коммутаторов и модулей расширения фабрики с поддержкой IEEE 802.1BR, предназначенных для центров обработки данных. Тут все сильно зависит от масштабов бизнеса;

  • Модуль подключения к сети Интернет. Представляет собой набор коммутаторов, межсетевых экранов, с поддержкой подключения к удаленным объектам (IPSec VPN) и подключения удаленных рабочих мест (SSL/IPsec VPN) в случае надобности;

  • Модуль вспомогательных систем управления может включать в себя следующие компоненты: система управления IP-пространством IPAM (IP Address Management), инвентарная система, система описания сетевых сервисов или управления конфигурацией, системы мониторинга, система контроля доступа NAC (Network Admission Control), NTP, FTP, TFTP и пр.

Любой выбор — это всегда баланс между плюсами и минусами того или иного решения. Предлагаемый вариант подхода к построению сети призван удовлетворить трем главным для нас критериям: отказоустойчивость, простота, независимость от модели и производителя.

Продолжение следует во второй части

Теги:
Хабы:
+1
Комментарии 40
Комментарии Комментарии 40

Публикации

Информация

Сайт
timeweb.cloud
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия
Представитель
Timeweb Cloud