Сегодня в фокусе нашего внимания не только линейка продуктов Huawei для создания сетей ЦОД, но и то, как строить на их основе продвинутые комплексные решения. Начнём со сценариев, перейдём к конкретным функциям, поддерживаемым оборудованием, а закончим обзором конкретных устройств, которые могут лечь в основу современных ЦОДов с высочайшим уровнем автоматизации сетевых процессов.
Какими бы впечатляющими ни были характеристики сетевого оборудования, возможности прикладных архитектурных решений на его базе определяются тем, насколько эффективной может быть взаимная интеграция сопряжённых с ним аппаратных, программных, виртуальных и иных технологий. Стараясь идти в ногу со временем, мы стараемся оперативно предлагать клиентам современные и многообещающие возможности, которые нередко опережают самые смелые замыслы других вендоров.
В состав решений на основе Cloud Fabric входят сеть центра обработки данных, SDN-контроллер, а также иные необходимые для конкретного проекта компоненты, в том числе от других производителей.
Первый и самый простой сценарий включает в себя использование минимального количества компонентов: сеть строится на аппаратной базе Huawei и сторонних средств для автоматизации процессов управления сетью и её мониторинга. Например, таких как Ansible или Microsoft Azure.
Второй сценарий подразумевает, что заказчик уже использует систему виртуализации и SDN для центров обработки данных, скажем NSX, и хочет задействовать оборудование Huawei в качестве аппаратного VTEP (Vitual Tunnel End Point) в рамках имеющегося решения VMware. На сайте этой компании приведён список оборудования Huawei, которое протестировано и может применяться в качестве VTEP. Ведь ни для кого не секрет, что, как бы ни были удачны программные решения VXLAN (Virtual Extensible LAN) на виртуальных свитчах, аппаратные реализации с точки зрения производительности эффективнее.
Третий сценарий — это строительство систем класса hosting & computing, имеющих в своём составе контроллер, но лишенных какой-либо вышестоящей платформы, с которой было бы нужно интегрироваться. Один из вариантов реализации такого сценария предполагает наличие отдельного SDN-контроллера Agile Controller-DCN. Эту архитектуру системные администраторы могут использовать для выполнения каждодневных операций по управлению сетью. Более развитый вариант третьего сценария строится на взаимодействии Agile Controller-DCN с VMware vCenter, объединённых неким бизнес-процессом, но опять-таки без вышестоящей системы администрирования.
Примечателен четвёртый сценарий — интеграция с вышестоящей платформой на основе OpenStack или нашего продукта виртуализации FusionSphere. Мы регистрируем множество запросов на подобные архитектурные решения, среди которых наибольшей популярностью пользуется OpenStack (CentOS, Red Hat и пр.). Всё зависит от того, какая платформа оркестрации и управления вычислительными ресурсами применяется в ЦОДе.
Пятый же сценарий совершенно новый. Помимо широко известных аппаратных свитчей он включает в себя распределённый виртуальный коммутатор CloudEngine 1800V (CE1800V), который можно эксплуатировать только с KVM (Kernel-based Virtual Machine). Эта архитектура подразумевает объединение Agile Controller-DCN с платформой контейнеризации Kubernetes с помощью плагина CNI. Таким образом, Huawei вместе со всем миром движется от виртуализации хостов к виртуализации операционных систем.
Ранее мы уже упомянули виртуальный коммутатор CE1800V, разворачиваемый с помощью Agile Controller-DCN. В сочетании с аппаратными свитчами Huawei они образуют некий «гибридный оверлей». В ближайшее время контейнерные сценарии от Huawei получат поддержку функций NAT и балансировки нагрузки.
Ограничением архитектуры является невозможность использования CE1800V отдельно от Agile Controller-DCN. Также следует учитывать, что один PoD платформы Kubernetes может содержать не более 4 млн контейнеров.
Подключение к VXLAN-сети ЦОДа происходит посредством VLAN (Virtual Local Area Network), однако есть вариант, при котором CE1800V выступает в роли VTEP с процессом BGP (Border Gateway Protocol). Это позволяет обмениваться BGP-маршрутами с магистральной сетью без привлечения отдельных аппаратных коммутаторов.
Концепцию Intent-Driven Network (IDN) Huawei представила ещё в 2018 году. С тех пор компания не прерывала работу над сетями, позволяющими с помощью технологии облачных вычислений, больших данных и искусственного интеллекта анализировать цели и намерения пользователей.
По сути, мы говорим о движении от автоматизации к автономности. Выраженное пользователем намерение возвращается в виде рекомендаций сетевых продуктов о том, как это намерение воплотить. В основе этой функциональности лежат возможности Agile Controller-DCN, которые будут добавляться в продукт, чтобы обеспечить воплощение идеологии IDN.
В перспективе с внедрением IDN можно будет разворачивать сетевые сервисы в один клик, что подразумевает высочайшую степень автоматизации. Модульная архитектура функций сети и возможность комбинировать эти функции позволят администратору просто указать, какие сервисы необходимо сделать доступными в том или ином сетевом сегменте.
Для достижения подобного уровня управляемости очень важен ZTP-процесс (Zero Touch Provisioning). Huawei добилась в этом серьёзных успехов, благодаря чему предлагает возможность полного развёртывания сети «из коробки».
Дальнейший процесс установки и развёртывания обязательно включает в себя процедуру проверки связанности между ресурсами (network connectivity) и оценку изменений производительности сети в зависимости от режимов её работы. Этот этап подразумевает проведение симуляции перед началом реальной эксплуатации.
Следующий шаг — настройка сервисов под потребности клиента (service provisioning) и их верификация, выполняемые встроенными средствами Huawei. Далее остаётся лишь проконтролировать результат.
Пройти весь описанный путь теперь можно с помощью одного-единственного комплексного механизма на основе платформы iMaster NCE, содержащей Agile Controller-DCN и систему управления элементами сети (EMS) eSight.
На текущий момент Agile Controller-DCN умеет проверять доступность ресурсов и наличие соединений, а также проактивно (после одобрения администратора) реагировать на возникновение проблем в сети. Добавление нужных сервисов сейчас осуществляется вручную, но в будущем Huawei намерена автоматизировать эту и другие операции, такие как развёртывание серверов, конфигурация сетей под СХД и пр.
Agile Controller-DCN способен обрабатывать сервисные заголовки (Net Service Headers, или NSH), содержащиеся в VXLAN-пакетах. Это пригождается для создания цепочек сервисов (service chains). Например, вы намерены отправить определённого вида пакеты по маршруту, отличающемуся от того, который предлагается стандартным протоколом маршрутизации. Прежде чем покинуть сеть, они должны пройти через какое-то устройство (файрволл и т. п.). Для этого достаточно сконфигурировать сервисную цепочку, содержащую нужные правила. За счёт такого механизма можно, например, конфигурировать политики безопасности, но возможны и другие области его применения.
На схеме наглядно представлена работа RFC-совместимых сервисных цепочек, основанных на NSH, а также приведён перечень поддерживающих их аппаратных коммутаторов.
Возможности решений Huawei в области создания сервисных цепочек дополняются инструментами микросегментации — метода сетевой безопасности, подразумевающего изоляцию сегментов безопасности вплоть до отдельных элементов рабочей нагрузки. Обойти «бутылочное горлышко» списков управления доступом (Access Control List или ACL) помогает отсутствие необходимости вручную конфигурировать огромное количество ACL.
Переходя к вопросу эксплуатации сети, нельзя не упомянуть ещё один компонент зонтичного бренда iMaster NCE — интеллектуальный анализатор сети FabricInsight. Он предоставляет широкие возможности для сбора телеметрии и информации о потоках данных в сети. Телеметрия собирается с помощью gRPC и аккумулирует данные о прошедших, задержанных в буфере и потерянных пакетах. Второй большой массив информации агрегируется посредством ERSPAN (Encapsulated Remote Switch Port Analyzer) и даёт представление о потоках данных в ЦОДе. По сути, речь идёт о сборе TCP-заголовков и объёмов информации, передаваемой в ходе каждой TCP-сессии. Делать это можно с использованием различных устройств Huawei — их список представлен на схеме.
Не забыты также SNMP и NetStream, так что Huawei использует и старые, и новые механизмы, для того чтобы перейти от сети как «черного ящика» к сети, о которой мы знаем буквально всё.
Функции AI Fabric, поддерживаемые нашим оборудованием, призваны превратить Ethernet в сеть с высокой производительностью, с низкими задержками, без потерь пакетов. Это необходимо для реализации основных сценариев развёртывания приложений в сети ЦОД.
На схеме выше мы видим проблемы, с которыми есть риск столкнуться при эксплуатации сети:
В оборудовании Huawei реализованы механизмы, позволяющие решать все эти проблемы. Например, на уровне чипа внедрена технология виртуальных входящих очередей, которая заодно не допускает блокировки на входе (HOL blocking).
На уровне протоколов действует механизм Dynamic ECN — динамическое изменение размера буфера, а также Fast CNP — быстрая отправка источнику пакетов сообщений о проблеме в сети.
Уравнять в правах потоки Elephant и Mice помогает поддержка технологии Dynamic Packet Prioritization (DPP), которая заключается в помещении коротких фрагментов данных из разных потоков в отдельную высокоприоритетную очередь. Таким образом короткие пакеты лучше «выживают» в среде длинных, тяжёлых потоков.
Уточним, что для эффективного действия вышеперечисленных механизмов они должны поддерживаться непосредственно оборудованием.
Все эти функции применяются в одном из трёх сценариев использования оборудования Huawei:
Обсудив типовые сценарии использования решений Huawei и перечислив их основные возможности, перейдём непосредственно к оборудованию.
CloudEngine 16800 — платформа, которая предусматривает работу по интерфейсам 400 Гбит/с. Её характерная особенность — наличие наряду с ЦП собственных forwarding chip и процессора искусственного интеллекта, необходимого для реализации возможностей AI Fabric.
Платформа выполнена по классической ортогональной архитектуре с системой обдува front to back и поставляется с одним из трёх типов шасси — на 4 (10U), 8 (16U) или 16 (32U) слотов.
В CloudEngine 16800 могут использоваться несколько типов линейных карт. Среди них как традиционные 10-гигабитные, так и 40-, а также 100-гигабитные, в том числе совсем новые. К выпуску планируются карты с интерфейсами 25 и 400 Гбит/с.
Что касается коммутаторов типа ToR (Top of rack), их текущие модели обозначены на таймлайне выше. Самый большой интерес представляют новые 25-гигабитные модели, 100-гигабитные коммутаторы с 400-гигабитными аплинками, а также высокоплотные 100-гигабитные с 96 портами.
Основной коммутатор Huawei с фиксированной конфигурацией на текущий момент — CloudEngine 8850. На смену ему должна прийти модель 8851 с 32 интерфейсами 100 Гбит/с и восемью интерфейсами 400 Гбит/с, а также с возможностью их сплита на 50, 100 или 200 Гбит/с.
Ещё один коммутатор с фиксированной конфигурацией CloudEngine 6865 пока остаётся в линейке актуальных продуктов Huawei. Это прекрасно зарекомендовавшая себя «рабочая лошадка» с доступом 10 / 25 Гбит/с и восемью 100-гигабитными аплинками. Добавим, он также поддерживает AI Fabric.
На схеме видны характеристики всех новых моделей коммутаторов, появления которых мы ждём в ближайшие месяцы, а то и недели. Некоторая задержка с их выходом связана с ситуацией вокруг коронавируса. Также пока остаются актуальными вопросы санкционного давления на компанию Huawei, однако повлиять все эти события могут исключительно на сроки премьер.
Больше информации о решениях Huawei и вариантах их применения легко получить, подписавшись на наши вебинары или обратившись непосредственно к представителям компании.
Напоминаем о том, что наши эксперты регулярно проводят вебинары по продуктам Huawei и по технологиям, которые в них используются. Список вебинаров на ближайшие недели доступен по ссылке.
Какими бы впечатляющими ни были характеристики сетевого оборудования, возможности прикладных архитектурных решений на его базе определяются тем, насколько эффективной может быть взаимная интеграция сопряжённых с ним аппаратных, программных, виртуальных и иных технологий. Стараясь идти в ногу со временем, мы стараемся оперативно предлагать клиентам современные и многообещающие возможности, которые нередко опережают самые смелые замыслы других вендоров.
В состав решений на основе Cloud Fabric входят сеть центра обработки данных, SDN-контроллер, а также иные необходимые для конкретного проекта компоненты, в том числе от других производителей.
Первый и самый простой сценарий включает в себя использование минимального количества компонентов: сеть строится на аппаратной базе Huawei и сторонних средств для автоматизации процессов управления сетью и её мониторинга. Например, таких как Ansible или Microsoft Azure.
Второй сценарий подразумевает, что заказчик уже использует систему виртуализации и SDN для центров обработки данных, скажем NSX, и хочет задействовать оборудование Huawei в качестве аппаратного VTEP (Vitual Tunnel End Point) в рамках имеющегося решения VMware. На сайте этой компании приведён список оборудования Huawei, которое протестировано и может применяться в качестве VTEP. Ведь ни для кого не секрет, что, как бы ни были удачны программные решения VXLAN (Virtual Extensible LAN) на виртуальных свитчах, аппаратные реализации с точки зрения производительности эффективнее.
Третий сценарий — это строительство систем класса hosting & computing, имеющих в своём составе контроллер, но лишенных какой-либо вышестоящей платформы, с которой было бы нужно интегрироваться. Один из вариантов реализации такого сценария предполагает наличие отдельного SDN-контроллера Agile Controller-DCN. Эту архитектуру системные администраторы могут использовать для выполнения каждодневных операций по управлению сетью. Более развитый вариант третьего сценария строится на взаимодействии Agile Controller-DCN с VMware vCenter, объединённых неким бизнес-процессом, но опять-таки без вышестоящей системы администрирования.
Примечателен четвёртый сценарий — интеграция с вышестоящей платформой на основе OpenStack или нашего продукта виртуализации FusionSphere. Мы регистрируем множество запросов на подобные архитектурные решения, среди которых наибольшей популярностью пользуется OpenStack (CentOS, Red Hat и пр.). Всё зависит от того, какая платформа оркестрации и управления вычислительными ресурсами применяется в ЦОДе.
Пятый же сценарий совершенно новый. Помимо широко известных аппаратных свитчей он включает в себя распределённый виртуальный коммутатор CloudEngine 1800V (CE1800V), который можно эксплуатировать только с KVM (Kernel-based Virtual Machine). Эта архитектура подразумевает объединение Agile Controller-DCN с платформой контейнеризации Kubernetes с помощью плагина CNI. Таким образом, Huawei вместе со всем миром движется от виртуализации хостов к виртуализации операционных систем.
Подробнее о контейнеризации
Ранее мы уже упомянули виртуальный коммутатор CE1800V, разворачиваемый с помощью Agile Controller-DCN. В сочетании с аппаратными свитчами Huawei они образуют некий «гибридный оверлей». В ближайшее время контейнерные сценарии от Huawei получат поддержку функций NAT и балансировки нагрузки.
Ограничением архитектуры является невозможность использования CE1800V отдельно от Agile Controller-DCN. Также следует учитывать, что один PoD платформы Kubernetes может содержать не более 4 млн контейнеров.
Подключение к VXLAN-сети ЦОДа происходит посредством VLAN (Virtual Local Area Network), однако есть вариант, при котором CE1800V выступает в роли VTEP с процессом BGP (Border Gateway Protocol). Это позволяет обмениваться BGP-маршрутами с магистральной сетью без привлечения отдельных аппаратных коммутаторов.
Intent-Driven Networks: сети, анализирующие намерения
Концепцию Intent-Driven Network (IDN) Huawei представила ещё в 2018 году. С тех пор компания не прерывала работу над сетями, позволяющими с помощью технологии облачных вычислений, больших данных и искусственного интеллекта анализировать цели и намерения пользователей.
По сути, мы говорим о движении от автоматизации к автономности. Выраженное пользователем намерение возвращается в виде рекомендаций сетевых продуктов о том, как это намерение воплотить. В основе этой функциональности лежат возможности Agile Controller-DCN, которые будут добавляться в продукт, чтобы обеспечить воплощение идеологии IDN.
В перспективе с внедрением IDN можно будет разворачивать сетевые сервисы в один клик, что подразумевает высочайшую степень автоматизации. Модульная архитектура функций сети и возможность комбинировать эти функции позволят администратору просто указать, какие сервисы необходимо сделать доступными в том или ином сетевом сегменте.
Для достижения подобного уровня управляемости очень важен ZTP-процесс (Zero Touch Provisioning). Huawei добилась в этом серьёзных успехов, благодаря чему предлагает возможность полного развёртывания сети «из коробки».
Дальнейший процесс установки и развёртывания обязательно включает в себя процедуру проверки связанности между ресурсами (network connectivity) и оценку изменений производительности сети в зависимости от режимов её работы. Этот этап подразумевает проведение симуляции перед началом реальной эксплуатации.
Следующий шаг — настройка сервисов под потребности клиента (service provisioning) и их верификация, выполняемые встроенными средствами Huawei. Далее остаётся лишь проконтролировать результат.
Пройти весь описанный путь теперь можно с помощью одного-единственного комплексного механизма на основе платформы iMaster NCE, содержащей Agile Controller-DCN и систему управления элементами сети (EMS) eSight.
На текущий момент Agile Controller-DCN умеет проверять доступность ресурсов и наличие соединений, а также проактивно (после одобрения администратора) реагировать на возникновение проблем в сети. Добавление нужных сервисов сейчас осуществляется вручную, но в будущем Huawei намерена автоматизировать эту и другие операции, такие как развёртывание серверов, конфигурация сетей под СХД и пр.
Сервисные цепочки и микросегментация
Agile Controller-DCN способен обрабатывать сервисные заголовки (Net Service Headers, или NSH), содержащиеся в VXLAN-пакетах. Это пригождается для создания цепочек сервисов (service chains). Например, вы намерены отправить определённого вида пакеты по маршруту, отличающемуся от того, который предлагается стандартным протоколом маршрутизации. Прежде чем покинуть сеть, они должны пройти через какое-то устройство (файрволл и т. п.). Для этого достаточно сконфигурировать сервисную цепочку, содержащую нужные правила. За счёт такого механизма можно, например, конфигурировать политики безопасности, но возможны и другие области его применения.
На схеме наглядно представлена работа RFC-совместимых сервисных цепочек, основанных на NSH, а также приведён перечень поддерживающих их аппаратных коммутаторов.
Возможности решений Huawei в области создания сервисных цепочек дополняются инструментами микросегментации — метода сетевой безопасности, подразумевающего изоляцию сегментов безопасности вплоть до отдельных элементов рабочей нагрузки. Обойти «бутылочное горлышко» списков управления доступом (Access Control List или ACL) помогает отсутствие необходимости вручную конфигурировать огромное количество ACL.
Интеллектуальная эксплуатация
Переходя к вопросу эксплуатации сети, нельзя не упомянуть ещё один компонент зонтичного бренда iMaster NCE — интеллектуальный анализатор сети FabricInsight. Он предоставляет широкие возможности для сбора телеметрии и информации о потоках данных в сети. Телеметрия собирается с помощью gRPC и аккумулирует данные о прошедших, задержанных в буфере и потерянных пакетах. Второй большой массив информации агрегируется посредством ERSPAN (Encapsulated Remote Switch Port Analyzer) и даёт представление о потоках данных в ЦОДе. По сути, речь идёт о сборе TCP-заголовков и объёмов информации, передаваемой в ходе каждой TCP-сессии. Делать это можно с использованием различных устройств Huawei — их список представлен на схеме.
Не забыты также SNMP и NetStream, так что Huawei использует и старые, и новые механизмы, для того чтобы перейти от сети как «черного ящика» к сети, о которой мы знаем буквально всё.
AI Fabric: умные сети без потерь
Функции AI Fabric, поддерживаемые нашим оборудованием, призваны превратить Ethernet в сеть с высокой производительностью, с низкими задержками, без потерь пакетов. Это необходимо для реализации основных сценариев развёртывания приложений в сети ЦОД.
На схеме выше мы видим проблемы, с которыми есть риск столкнуться при эксплуатации сети:
- потеря пакетов;
- переполнение буферов;
- проблема оптимальной загрузки сети при использовании параллельных линков.
В оборудовании Huawei реализованы механизмы, позволяющие решать все эти проблемы. Например, на уровне чипа внедрена технология виртуальных входящих очередей, которая заодно не допускает блокировки на входе (HOL blocking).
На уровне протоколов действует механизм Dynamic ECN — динамическое изменение размера буфера, а также Fast CNP — быстрая отправка источнику пакетов сообщений о проблеме в сети.
Уравнять в правах потоки Elephant и Mice помогает поддержка технологии Dynamic Packet Prioritization (DPP), которая заключается в помещении коротких фрагментов данных из разных потоков в отдельную высокоприоритетную очередь. Таким образом короткие пакеты лучше «выживают» в среде длинных, тяжёлых потоков.
Уточним, что для эффективного действия вышеперечисленных механизмов они должны поддерживаться непосредственно оборудованием.
Все эти функции применяются в одном из трёх сценариев использования оборудования Huawei:
- при построении систем искусственного интеллекта, основанных на распределённых приложениях;
- при создании распределённых систем хранения данных;
- при создании систем для высокопроизводительных вычислений (HPC).
Идеи, воплощённые в «железе»
Обсудив типовые сценарии использования решений Huawei и перечислив их основные возможности, перейдём непосредственно к оборудованию.
CloudEngine 16800 — платформа, которая предусматривает работу по интерфейсам 400 Гбит/с. Её характерная особенность — наличие наряду с ЦП собственных forwarding chip и процессора искусственного интеллекта, необходимого для реализации возможностей AI Fabric.
Платформа выполнена по классической ортогональной архитектуре с системой обдува front to back и поставляется с одним из трёх типов шасси — на 4 (10U), 8 (16U) или 16 (32U) слотов.
В CloudEngine 16800 могут использоваться несколько типов линейных карт. Среди них как традиционные 10-гигабитные, так и 40-, а также 100-гигабитные, в том числе совсем новые. К выпуску планируются карты с интерфейсами 25 и 400 Гбит/с.
Что касается коммутаторов типа ToR (Top of rack), их текущие модели обозначены на таймлайне выше. Самый большой интерес представляют новые 25-гигабитные модели, 100-гигабитные коммутаторы с 400-гигабитными аплинками, а также высокоплотные 100-гигабитные с 96 портами.
Основной коммутатор Huawei с фиксированной конфигурацией на текущий момент — CloudEngine 8850. На смену ему должна прийти модель 8851 с 32 интерфейсами 100 Гбит/с и восемью интерфейсами 400 Гбит/с, а также с возможностью их сплита на 50, 100 или 200 Гбит/с.
Ещё один коммутатор с фиксированной конфигурацией CloudEngine 6865 пока остаётся в линейке актуальных продуктов Huawei. Это прекрасно зарекомендовавшая себя «рабочая лошадка» с доступом 10 / 25 Гбит/с и восемью 100-гигабитными аплинками. Добавим, он также поддерживает AI Fabric.
На схеме видны характеристики всех новых моделей коммутаторов, появления которых мы ждём в ближайшие месяцы, а то и недели. Некоторая задержка с их выходом связана с ситуацией вокруг коронавируса. Также пока остаются актуальными вопросы санкционного давления на компанию Huawei, однако повлиять все эти события могут исключительно на сроки премьер.
Больше информации о решениях Huawei и вариантах их применения легко получить, подписавшись на наши вебинары или обратившись непосредственно к представителям компании.
***
Напоминаем о том, что наши эксперты регулярно проводят вебинары по продуктам Huawei и по технологиям, которые в них используются. Список вебинаров на ближайшие недели доступен по ссылке.
