This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>
This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>
На текущем этапе развития корпоративных сетей передачи данных (КСПД) возникают серьезные основания для пересмотра устоявшихся методов управления и построения сетей. Такие основания могут быть вызваны различными причинами, например, внедрением концепции BYOD и большей корпоративной мобильности; ростом потребности на расширение КСПД и построение распределенных сегментов; требованиями на уменьшение совокупной стоимости владения КСПД и снижение издержек на эксплуатацию и обслуживание с одновременным упрощением процессов конфигурирования и управления; наблюдаемым трендом роста конвергентных проводных и беспроводных сетей, то есть сетей, объединенных на базе одной физической инфраструктуры с унифицированным управлением.
Использование традиционного подхода для конфигурирования и управления корпоративными сетями при таких условиях является весьма трудоемким, сложным и подверженным ошибкам процессом, т.к. сетевые устройства управляются по-отдельности. Разные производители телекоммуникационного оборудования предлагают свои подходы для решения этих задач. В настоящей статье хотелось бы обратить внимание на появившиеся в последнее время технологии компании Huawei, которые помогают значительно упростить управление и настройку устройств распределенных и крупномасштабных сетей: виртуальная фабрика SVF (Super Virtual Fabric), облачное управление (Cloud-based Management). Рассмотрим каждую из двух технологий немного более подробно.
Технология SVF (Super Virtual Fabric) представляет собой построение виртуализированной распределенной фабрики коммутации на основе большого количества сетевых устройств и в сравнении с обычными методами настройки и управления имеет следуюшие преимущества:
Топология сети при использовании 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) между родительскими и клиентскими коммутаторами отображаются в топологии как виртуальные соединения и настраиваются вручную.
|
Уровень |
Тип устройства |
Максимальное количество коммутаторов 1-го уровня |
Максимальное количество коммутаторов 2-го уровня |
Количество точек доступа |
Максимальное количество CAPWAP туннелей |
|
SVF-Parent |
S5720-HI |
32 |
31 |
1024 |
1024 |
|
S6720-EI/ S6720S-EI |
32 |
31 |
0 |
32 |
|
|
S7703/ S9703 |
32 |
31 |
512 |
512 |
|
|
S7706/ S7712 (SRUA/B) |
64 |
63 |
1024 |
1024 |
|
|
S7706/ S7712 (SRUE/H) |
256 |
64 |
2048 |
2048 |
|
|
S9706/ S9712 |
64 |
63 |
2048 |
2048 |
|
|
S12700 |
256 |
64 |
6144 |
6144 |
|
|
SVF-Client (Sx7 series) |
S2750-EI |
5 коммутаторов в стеке (одной серии) |
— |
— |
|
|
S57-LI/ S5720-LI/ S5720-EI/ S5720-SI/ S600-E |
5 коммутаторов в стеке (одной серии) |
— |
— |
||
|
S6720-EI |
5 коммутаторов в стеке (одной серии) |
— |
— |
Таким образом, использование многоуровневой схемы построения 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 являются:
Все узлы и составные части контроллера работают в отказоусточивой конфигурации (кластер). Масштабирование производительности кластера облачной платформы может быть выполнено добавлением дополнительных узлов в кластер. При оценке производительности системы облачного управления предъявляются определенные требования к узлам контроллера и минимальной полосе пропускания между контроллером и облачной сетью.
Ключевой компонентой платформы облачного управления является контроллер (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), а также распределенные база данных и кеш кластера. Модули выполняют следующие функции:
Сервисная архитектура контроллера облачного управления показана на рисунке.
Опишем один из возможных сценариев применения облачной платформы. Организации требуется запустить множество небольших беспроводных сетей, например, для магазинов, торговых точек или офисов (филиалов). Следовательно, организация должна закупить большое количество сетевых устройств, систему управления сетью и пользователями сети. Это повлечет увеличение TCO, а геграфическое разнесение беспроводных сетей между собой означает, что развертывание сетей и внедрение сервисов могут занять продолжительное время. Для решения этих проблем компания Huawei предлагает использование корпоративного публичного облака. Провайдер услуг или заказчик могут запустить беспроводные сервисы в какой-либо области, выполнив следующую последовательность действий (точка запуска сервисов должна быть подключена к Интернет):
По завершении основной настройки сервисов WLAN заказчик или провайдер услуги может копировать на контроллере конфигурацию всех сервисов для этой беспроводной сети. Используя такой способ, администратор может быстро выполнить настройку сетевых устройств для множества точек, офисов или филиалов в пакетном режиме, время развертывания сетевых услуг будет существенно сокращено. После регистрации сетевых устройств на контроллере заказчик или провайдер услуг могут выполнять различные операции на контроллере: запрашивать статус устройств, выполнять удаленное управление, отслеживать производительность работы устройств и получать системные уведомления от сетевых устройств.
Контроллером публичного облака Huawei поддерживается строгое разделение ролей системных администраторов контроллера, администраторов сервисных провайдеров MSP и администраторов арендаторов облачных услуг. Системные администраторы выполняют текущее обслуживание контроллера (сервисная конфигурация, управление заказчиками и сервисными провайдерами), но не имеют прав на настройку сервисных функций, а также не имеют прав на просмотр текущего состояния сетевых услуг. Администраторы MSP могут управлять сетями и обслуживать сети множества заказчиков после того, как будут авторизованы заказчиками на контроллере; по умолчанию администраторы MSP не имеют прав на просмотр информации по сетям заказчиков. Администраторы заказчиков (арендаторов облачных услуг) управляют своими собственными сетями посредством контроллера. Хотя AC Campus использует единое доменное имя (naas.huawei.com) для обеспечения облачных сервисов в сетях заказчиков, в настоящий момент кластеры контроллеров облачного управления физически располагаются в различных дата-центрах и в разных регионах мира.
Таким образом, современные технологии, предлагаемые поставщиками телекоммуникационных решений (в частности, компанией Huawei) для управления, конфигурирования, мониторинга сетевой инфраструктуры предприятий, предлагают ряд механизмов, позволяющих делать это абсолютно другим способом, чем это ранее обеспечивали традиционные методы управления КСПД. Для этой цели могут быть использованы виртуализация, облачные сервисы, технологии программно-конфигурируемых сетей. Разумеется, новые подходы имеют как преимущества, так и недостатки, которые должны быть приняты во внимание.
Получат ли описанные подходы свое дальнейшее развитие, будет зависит от нескольких факторов: технологических (поддерживает ли инфраструктура заказчика данные технологии), организационных (согласуются ли бизнес-процессы и бизнес-модели заказчика с предложенными методами управления), финансово-экономических (насколько существенными будут выгоды от внедрения этих методов, учитывая потенциальные плюсы и минусы таких технологий).
Об авторе:
Андрей Новитский,
менеджер по продуктам и решениям Huawei Enterprise Business Group
[1] Более подробно о решении Agile Distributed Wi-Fi можно прочитать по ссылке (блог компании Huawei) https://habrahabr.ru/company/huawei/blog/317684
[2] Инфраструктура облачной сети является многопользовательской или многоарендуемой (mutli-tenant) с разделением полномочий, зон ответственности, политик доступа и т. д. между арендаторами (разными организациями, подразделениями одной или нескольких компаний)
Copyright © 2021 Huawei Technologies Co., Ltd. All rights reserved.
