Централизация сетевого управления как новая парадигма построения корпоративных сетей передачи данных

На текущем этапе развития корпоративных сетей передачи данных (КСПД) возникают серьезные основания для пересмотра устоявшихся методов управления и построения сетей. Такие основания могут быть вызваны различными причинами, например, внедрением концепции BYOD и большей корпоративной мобильности; ростом потребности на расширение КСПД и построение распределенных сегментов; требованиями на уменьшение совокупной стоимости владения КСПД и снижение издержек на эксплуатацию и обслуживание с одновременным упрощением процессов конфигурирования и управления; наблюдаемым трендом роста конвергентных проводных и беспроводных сетей, то есть сетей, объединенных на базе одной физической инфраструктуры с унифицированным управлением.

Использование традиционного подхода для конфигурирования и управления корпоративными сетями при таких условиях является весьма трудоемким, сложным и подверженным ошибкам процессом, т.к. сетевые устройства управляются по-отдельности. Разные производители телекоммуникационного оборудования предлагают свои подходы для решения этих задач. В настоящей статье хотелось бы обратить внимание на появившиеся в последнее время технологии компании Huawei, которые помогают значительно упростить управление и настройку устройств распределенных и крупномасштабных сетей: виртуальная фабрика SVF (Super Virtual Fabric), облачное управление (Cloud-based Management). Рассмотрим каждую из двух технологий немного более подробно.

Технология SVF (Super Virtual Fabric) представляет собой построение виртуализированной распределенной фабрики коммутации на основе большого количества сетевых устройств и в сравнении с обычными методами настройки и управления имеет следуюшие преимущества:

• Унифицированное управление устройствами. SVF виртулизирует устройства уровней агрегации и доступа в одно логическое устройство, что уменьшает общее количество устройств, которыми требуется управлять. Вся конфигурация выполняется на родительских устройствах (SVF Parent), при этом клиентские устройства (SVF Client) подключаются к системе автоматически и могут загружать с родительского устройства конфигурацию, операционную систему и патчи

• Унифицированное конфигурирование. SVF реализует пакетное конфигурирование устройств доступа на основе профилей, избавляя от необходимости настройки устройств доступа по одному

• Унифицированное управление пользователями. SVF управляет пользователями проводного и беспроводного доступа единым образом, так как родительское устройство поддерживает встроенный контроллер беспроводной сети, а точки доступа Wi-Fi интегрируются в SVF фабрику

• Высокая надежность. Обеспечивается за счет возможностей резервирования устройств (на основе кластеризации/ стекирования – CSS/CSS2, iStack) и резервирования каналов (агрегация). При этом вся SVF система требует использования древовидной топологии подключений, поэтому фабрика генерирует аларм в систему управления и блокирует порт в случае его неправильного подключения для предотвращения какого-либо влияния на сервисы

• Уменьшение совокупной стоимости владения (TCO). SVF уменьшает стоимость сетевых внедрений, увеличивает доступную емкость сети доступа, является легко расширяемой технологией. SVF позволяет объединять родительские и клиентские устройства посредством устройств Huawei или третьих производителей, которые не поддерживают SVF

Топология сети при использовании SVF системы выглядит следующим образом:

В версии ПО V2R10 (стабильный релиз появился 22 дек. 2016) масштаб SVF cистемы значительно повышен в сравнении с версиями ПО V2R8, V2R9 за счет увеличения количества подключаемых коммутаторов доступа 1-го и 2-го уровней, а также за счет увеличения размерности логической единицы iStack на доступе (с 3-x до 5-и устройств). iStack для клиентских коммутаторов может быть настроен на основе сервисных портов, либо специальных стековых карт (модулей). Если используется iStack на основе сервисных портов, то стек коммутаторов должен быть настроен перед подключением портов фабрик клиентских коммутаторов; если используется iStack на основе стековых карт (модулей), то стек может быть настроен как до так и после подключения портов фабрик клиентских коммутаторов.

Родительские и клиентские коммутаторы SVF могут быть связаны при помощи портов 1 Гбит/с или 10 Гбит/с, оконечными (пользовательскими) портами SVF системы могут быть порты с производительностью 100 Мбит/с, 1 Гбит/с или 10 Гбит/с. Каждый порт подключения фабрики может содержать от 1 до 8 физических интерфейсов. Если в SVF требуются беспроводные сервисы, то точки доступа должны использовать в качестве родительских устройств модульные коммутаторы S7700/S9700/S12700 с имеющимися интерфейсными картами серии X1E (на основе сетевого процессора ENP, при этом точки доступа могут быть подключены через интерфейсные карты не только серии X1E, но и прочих серий), либо использовать в качестве родительских коммутаторы S5720-HI. Если родительские коммутаторы подключаются к клиентским через устройства уровня 2 прочих производителей, то порты подключения фабрик (fabric-ports) между родительскими и клиентскими коммутаторами отображаются в топологии как виртуальные соединения и настраиваются вручную.

Таким образом, использование многоуровневой схемы построения SVF системы (Родительский коммутатор à Коммутатор доступа 1-го уровня à Коммутатор доступа 2-го уровня) и стекирования iStack для коммутаторов доступа позволяет масштабировать всю SVF систему до нескольких тысяч устройств на одну SVF фабрику.

В SVF системе используются собственные протоколы компании Huawei – AS Discovery Protocol (ASDP) и LLDP-Based Network Topology (LBNT) – с целью обнаружения клиентских коммутаторов и сбора топологической информации. Протокол ASDP используется родительскими коммутаторами для обнаpужения клиентских устройств и доставки на них сетевых параметров настройки, в то время как клиентские коммутаторы используют ASDP для установления соединений с агрегированными портами фабрик на родительских коммутаторах. Протокол LBNT используется родительскими коммутаторами для сбора информации о соседях каждого клиентского коммутатора и вычисления топологии всей сети. Кроме того, все коммутаторы используют управляющие каналы на основе протокола Control and Provisioning of Wireless Access Points (CAPWAP). Через управляющие каналы клиентские коммутаторы (AS) и точки доступа (AP) регистрируются на родительских коммутаторах и через них же управляются. Используя протоколы ASDP, LBNT, CAPWAP, родительские коммутаторы централизованно управляют всеми AS, AP, а сеть виртуализируется в одно логическое устройство. Возможно использование DTLS шифрования на управляющих каналах CAPWAP, но при этом масштаб системы значительно уменьшается.

Для настройки SVF фабрики часть параметров (в частности, управляющая VLAN, пул IP адресов для присвоения клиентским коммутаторам, порты фабрики со стороны родительского коммутатора в сторону AS 1-го уровня или со стороны AS 1-го уровня в сторону AS 2-го уровня, режимы работы и некоторые другие) необходимо задать вручную на родительском устройстве, всё остальное (включая автоматическое обнаружение клиентских устройств и построение топологии, обновление софта при необходимости, применение настроек сервисных профилей) будет выполнено автоматически.

SVF система поддерживает два режима пакетной пересылки – централизованный (centralized) и распределенный (distributed). В централизованном режиме трафик, пересылаемый локально внутри одного коммутатора, и трафик между коммутаторами отправляется на родительский коммутатор. В таком режиме порты клиентского коммутатора изолированы и не могут взаимодействовать на уровне 2, поэтому используется функция ARP прокси в соответствующем VLAN для того, чтобы организовать коммутацию (та же функция реализуется командой arp-proxy inner-sub-vlan-proxy enable).

В распределенном режиме клиентский коммутатор непосредственно пересылает локальный трафик (в пределах одного коммутатора), а родительский коммутатор используется только для пересылки трафика между разными AS. По умолчанию SVF система работает в распределенном режиме пересылки пакетов.

Поддерживаются несколько способов настройки виртуализированной фабрики SVF. Для SVF системы доступно два режима конфигурирования – централизованный (centralized) и независимый режим (independent). Оба режима можно использовать одновременно в одной фабрике.

В централизованном режиме конфигурация всех сервисов выполняется на родительском устройстве. Такой режим удобен в том случае, если конфигурация большинства устройств уровня доступа является достаточно однотипной. Список сервисов, которые могут быть настроены на AS, целиком формируется родительским устройством и не определяется тем, что поддерживает отдельный коммутатор (вне SVF фабрики). В централизованном режиме сервисная конфигурация может быть доставлена на множество AS, используя профили (profile-based configuration) или глобальное конфигурирование в пакетном режиме (global configuration). Глобальное конфигурирование в пакетном режиме поддерживает только ограниченный набор параметров и функций. Кроме того, с родительского устройства можно выполнить настройку сервисной конфигурации для отдельного коммутатора AS (direct configuration), не используя профили (команда direct-command).

Часть устройств SVF фабрики может иметь более расширенные конфигурации. В этом случае для них необходимо использовать независимый режим конфигурирования (доступен с версии ПО V2R10). В независимом режиме настройка производится командами при подключении к каждому устройству AS, доставка сервисов с родительского устройства не выполняется. После настройки AS конфигурационный файл может быть сохранен на самом устройстве и загружен на родительское устройство (команда upload config). Независимый режим конфигурирования поддерживает более расширенную настройку сервисов, чем при использовании централизованного режима. После переключения клиентского коммутатора из централизованного режима в независимый режим вся сервисная конфигурация, выполненная до переключения с помощью профилей или непосредственным конфигурированием с родительского коммутатора, будет сохранена. После переключения клиентского коммутатора из независимого режима в централизованный режим конфигурационный файл коммутатора будет удален, а само устройство перезагружено для подключения к фабрике. В текущей версии независимый режим не поддерживается в случае подключения AS через промежуточную сеть уровня 2.

Cистема сетевого управления (Huawei eSight) обеспечивает визуализацию управления SVF фабрики, включая просмотр топологии, отслеживание состояния устройств и каналов в режиме реального времени, отображение лицевых панелей устройств, а также проверки состояния клиентских устройств, подключенных к конкретным портам фабрик SVF системы.

Возможно множество сценариев применения SVF в корпоративных сетях разного масштаба с организацией унифицированного управления пользователями проводного и беспроводного доступа с учетом обеспечения надежности подключений, управляемости, снижения совокупной стоимости владения и операционных затрат. Один из вариантов построения топологии на основе SVF показан на рисунке.

Технология облачного управления (Cloud-based Management) представляет собой другое решение, при котором сетевые устройства конфигурируются и обслуживаются единообразно с помощью платформы облачного управления (Сloud Management Platform). Основное назначение этой технологии – предоставление возможности централизованного управления и делегирование управления КСПД сервисным партнерам (провайдерам), снижение затрат на эксплуатацию и обслуживание, быстрое разворачивание и внедрение сервисов в распределенной IT- инфраструктуре. Сетевые устройства не виртуализируются в одно логическое устройство (в отличии от технологии SVF), а управляются по-отдельности облачной платформой. Должен быть обеспечен доступ к управляемым сетевым сегментам по IP (Internet) и, следовательно, платформа управления может быть значительно разнесена географически с сегментами корпоративной сети.

Облачная платформа Huawei (naas.huawei.com) – публичная платформа, поддерживающая различные бизнес-модели и представляющая собой разделяемую многопользовательскую или многоарендуемую (multi-tenant) инфраструктуру. После приобретения заказчиком соответствующей лицензии у Huawei или сервисного провайдера заказчик может выполнять операции по управлению и техническому обслуживанию своей сети используя облачную платформу Huawei.

Основными компонентами облачной платформы Huawei являются:

• Контроллер облачного управления. Ключевая компонента решения для унифицированного управления точками доступа Wi-Fi (AP), маршрутизаторами доступа (AR), коммутаторами, межсетевыми экранами. Контроллер ориентирован на поддержку многопользовательского управления, «Plug-and-play», сетевых сервисов на основе пакетного конфигурирования, API интерфейсов для взаимодействия с платформами третьих производителей с целью расширения списка предоставляемых сервисов;

• NETCONF. Сетевой протокол на основе XML для конфигурирования и управления сетевыми устройствами (RFC 4741, RFC 6241). Сети с поддержкой NETCONF обеспечивают стандартные API для прикладных разработчиков с целью внедрения ПО сетевого управления. Также необходимыми протоколами для управления являются HTTP 2.0 (RFC 7540) и SSH (RFC 4253);

• Устройства КСПД, которые поддерживают технологию облачного управления. В настоящий момент технология облачного управления поддерживается для кампусных коммутаторов Huawei серии S5720-SI (начиная c ПО версии V2R10), межсетевых экранов серии USG 63xx (начиная с ПО версии V5R1C30), точек доступа беспроводной сети (начиная с ПО версии V2R7C10, включая центральные точки доступа AD9430DN-12/ AD9430DN-24 и выносные радиомодули R230D/ R240D/ R250D для построения распределенного решения Agile Distributed Wi-Fi[1]). Список будет расширяться, например, с новой версии ПО коммутаторов V2R11 (июль 2017) будет добавлена поддержка коммутаторов серии S5720-LI, также будет добавлена поддержка маршрутизаторов доступа корпоративного уровня (серии AR). Переход в режим управления облачной платформой может быть осуществлен автоматически для нового устройства, также сетевое устройство можно перевести в этот режим вручную. Например, переключение коммутаторов на платформу облачного управления может быть выполнено одним из следующих способов: посредством DHCP протокола (с опцией 148), посредством команды CLI, посредством Web-интерфейса.

Все узлы и составные части контроллера работают в отказоусточивой конфигурации (кластер). Масштабирование производительности кластера облачной платформы может быть выполнено добавлением дополнительных узлов в кластер. При оценке производительности системы облачного управления предъявляются определенные требования к узлам контроллера и минимальной полосе пропускания между контроллером и облачной сетью.

Ключевой компонентой платформы облачного управления является контроллер (Agile Controller Campus, AC Campus, текущая версия V200R002C00), имеющий распределенную кластерную архитектуру с высокой доступностью и состоящий из несколько модулей: модуль балансировки (Load Balancing Module), модуль управления (ACM, Agile Controller Manager), модуль аутентификации (ACA, Agile Controller Authentication), модуль сбора информации (ACC, Agile Controller Collector), модуль FusionInsight HD (Huawei Big Data), а также распределенные база данных и кеш кластера. Модули выполняют следующие функции:

• Модуль балансировки выполняет распределение нагрузки внутри кластера, таким образом кластер может использовать единый виртуальный IP адрес для управления. Модуль реализован на базе сервера LVS для Linux, а также сервера nginx. Работа интерфейсов NBI (Northbound Interface, северный интерфейс) и SBI (Southbound Interface, южный интерфейс) для остальных модулей кластера также обеспечивается модулем балансировки;

• Модуль управления ACM реализует функции управления администраторами  контроллера, администраторами сервисных провайдеров (MSP, Managed Service Provider) и администраторами арендаторов облачных услуг. Модуль позволяет администраторам выполнять управление устройствами, пользователями, сетевыми сервисами (функциями), политиками сетевой безопасности, мониторингом сети, системными сообщениями и логами

• Модуль аутентификации ACA обеспечивает мехнизмы аутентификации пользователей облачных услуг, включая портальную (веб) аутентификацию и функцию контроля доступа конечных пользователей;

• Модуль сбора информации ACC собирает алармы и статистику производительности для передачи этих данных в платформу Big Data для хранения и обработки;

• Модуль FusionInsight HD обеспечивает аналитику Big Data для полученной информации от модуля ACC. При отказе одного устройства в кластере FusionInsight другие устройства могут сохранять и анализировать данные, предотвращая потери информации.

Сервисная архитектура контроллера облачного управления показана на рисунке.

Опишем один из возможных сценариев применения облачной платформы. Организации требуется запустить множество небольших беспроводных сетей, например, для магазинов, торговых точек или офисов (филиалов). Следовательно, организация должна закупить большое количество сетевых устройств, систему управления сетью и пользователями сети. Это повлечет увеличение TCO, а геграфическое разнесение беспроводных сетей между собой означает, что развертывание сетей и внедрение сервисов могут занять продолжительное время. Для решения этих проблем компания Huawei предлагает использование корпоративного публичного облака. Провайдер услуг или заказчик могут запустить беспроводные сервисы в какой-либо области, выполнив следующую последовательность действий (точка запуска сервисов должна быть подключена к Интернет):

• Импорт приобретенного активационного кода (лицензия) в контроллер облачного управления AC Campus. Лицензия может быть приобретена на устройство конкретного типа и на определенной количество лет. Если лицензия истекает, то устройство не сможет подключиться к облачной платформе, а новая конфигурация сервисов не сможет быть доставлена на устройство с контроллера;

• Импорт серийных номеров ESN сетевых устройств в контроллер AC Campus. Каждое устройство характеризуется уникальным серийным номером, к которому и привязывается активационный код лицензии;

• Конфигурирование сетевых сервисов, включая SSID и политик управления пользователями на контроллере. Функции аутентификации (включая портальную аутентификацию) и контроля доступа беспроводных пользователей также могут быть выполнены на контроллере в различных режимах. Поддерживается аутентификация WeChat, аутентификация посредством первого доступа в Интернет через браузер, с помощью логина и пароля пользователя, с помощью SMS. Контроль сетевого доступа может быть выполнен посредством времени сетевого доступа или используемых идентификаторов точек доступа AP или SSID;

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

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

Контроллером публичного облака Huawei поддерживается строгое разделение ролей системных администраторов  контроллера, администраторов сервисных провайдеров MSP и администраторов арендаторов облачных услуг. Системные администраторы выполняют текущее обслуживание контроллера (сервисная конфигурация, управление заказчиками и сервисными провайдерами), но не имеют прав на настройку сервисных функций, а также не имеют прав на просмотр текущего состояния сетевых услуг. Администраторы MSP могут управлять сетями и обслуживать сети множества заказчиков после того, как будут авторизованы заказчиками на контроллере; по умолчанию администраторы MSP не имеют прав на просмотр информации по сетям заказчиков. Администраторы заказчиков (арендаторов облачных услуг) управляют своими собственными сетями посредством контроллера. Хотя AC Campus использует единое доменное имя (naas.huawei.com) для обеспечения облачных сервисов в сетях заказчиков, в настоящий момент кластеры контроллеров облачного управления физически располагаются в различных дата-центрах и в разных регионах мира.

Таким образом, современные технологии, предлагаемые поставщиками телекоммуникационных решений (в частности, компанией Huawei) для управления, конфигурирования, мониторинга сетевой инфраструктуры предприятий, предлагают ряд механизмов, позволяющих делать это абсолютно другим способом, чем это ранее обеспечивали традиционные методы управления КСПД. Для этой цели могут быть использованы виртуализация, облачные сервисы, технологии программно-конфигурируемых сетей. Разумеется, новые подходы имеют как преимущества, так и недостатки, которые должны быть приняты во внимание.

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

    Об авторе:

    Андрей Новитский, 

    менеджер по продуктам и решениям Huawei Enterprise Business Group