Cloudengine

Постоянное усложнение сетевой инфраструктуры современных ЦОДов ведёт к лавинообразному росту количества параметров, которые нужно контролировать ради оптимальных производительности и надёжности. Повысить уровень информированности администраторов о происходящих в сети процессах и помочь быстро выявлять зарождающиеся проблемы призвана концепция Huawei, воплотившаяся в решениях типа Intent-Driven Network: они предназначены для создания саморегулирующихся и самоуправляемых сетей, отвечающих принципу от автоматизации к автономности.



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

Четыре этапа развития ЦОДа

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

Ещё одна сфера применения ИИ анализ и мониторинг работы ЦОДа. Нам предстоит перейти от идеологии, подразумевающей функционально ограниченный мониторинг состояния неких чёрных ящиков, к концепции полностью прозрачных сетей, о которых известно всё.



В качестве основных инфраструктурных сетевых единиц для построения сетей ЦОД Huawei предлагает сейчас линейку четырёх-, восьми- и шестнадцатислотовых коммутаторов CloudEngine 16800 с аплинками 400 Гбит/с; их выпуск намечен на текущий год. Также среди новинок отметим построенные на нашей собственной элементной базе ToR-свитчи CloudEngine 6881 и 6863 с интерфейсами 10 и 25 Гбит/с соответственно.



На иллюстрации показаны модели коммутаторов из линейки CloudEngine 16800 с классической ортогональной архитектурой, которые оснащены системой охлаждения front-to-back, а также совместимые с ними линейные карты, снабжённые интерфейсами 10, 40 и 100 Гбит/с.

Из важных базовых функций CloudEngine 16800 выделим его умение работать с NSH (Network Service Header), что позволяет реализовать в ЦОДе распределённую по нескольким свитчам микросегментацию (изоляцию на уровне виртуальных машин), обеспечить широкие возможности телеметрии и проводить анализ трафика на границе сети (edge intelligence) с применением технологий искусственного интеллекта на базе AI-чипов Huawei.

По-настоящему революционной станет модель V1R19C10. Именно в ней должны быть реализованы многие давно ожидаемые функции, в том числе EVPN Multihoming без перемычки в виде M-LAG (Multi-Switch Link Aggregation) на основании первого и четвертого типов маршрутов в EVPN-роутинге VXLAN.

Знакомая архитектура и новые возможности

На схеме видна привычная ортогональная архитектура трёхуровневой фабрики Non-blocking Switching. К её первоочередным достоинствам стоит отнести оптимальное расположение плат фабрики, линейных карт, коннекторов и системы обдува, основанной на вентиляторах с переменной скоростью вращения.



Важно, что на новых моделях коммутаторов аппаратно реализован протокол BFD (Bidirectional Forwarding Detection) и есть возможность настройки VXLAN в адресном пространстве IPv6. Базовая архитектура осталась прежней и строится на процессоре, сопроцессоре и forwarding chip. Функциональность каждого из узлов представлена на схеме. Главное же изменение 2020 года переход на собственные чипы Huawei во флагманских коммутаторах, полноценно конкурирующие с аналогами от Broadcom.



Поддержка операций с Network Service Header позволяет новым коммутаторам менять дефолтные маршруты пакетов VXLAN и подключать такие сервисы, как межсетевые экраны (FW), системы обнаружения вторжений (IDS), балансировщики нагрузки (SLB) и NAT.



Вернёмся ненадолго к ранее упомянутой разделённой микросегментации. Новые ToR-коммутаторы Huawei с помощью всё тех же NSH позволяют изолировать рабочие нагрузки на уровне имён виртуальных машин. Эти машины можно дополнительно группировать на уровне подсетей, на основании номеров портов, вышестоящих протоколов и пр., таким образом формируя группы приложений.

Полный спектр телеметрических данных

Информация с устройств собирается в реальном времени с использованием нескольких основных протоколов. Задачей ERSPAN+ является сбор TCP-заголовков для последующего детального анализа TCP-потоков в ЦОДе. Дополнительные данные добываются с помощью протокола gRPC и таблицы переадресации (Flow table). Всё это собирается с Protobuf over UDP.



Основное направление развития средств O&M в Huawei переход от ручного или полуавтоматического контроля сети к полностью автоматическому, основанному на технологиях искусственного интеллекта. Всеохватная система телеметрии достаточно крупной площадки производит огромные объёмы данных, анализ которых в сжатые сроки возможен только с применением ИИ. Особенно это важно в тех ЦОДах, где сбои и простои просто недопустимы.



К превентивным мерам, призванным не допустить возникновения неполадок в работе сети, прежде всего стоит отнести мониторинг здоровья сети: контроль загрузки каналов, выявление причин потери пакетов (допустим, поиск корреляции с временем суток или периодами работы какого-либо приложения), обнаружение узких мест (capacity forecasting) и пр.

Если неполадки всё же наблюдаются, минимизировать время диагностики и восстановления помогает выдвинутый Huawei принцип 1-3-5: минута на поиск, три минуты на локализацию, пять минут на ликвидацию проблемы. Для того чтобы укладываться в эти рамки, продукты Huawei поддерживают постоянно расширяющийся список типовых неисправностей, которые определяются автоматически.

Модель V100R019C10 для небольших ЦОДов

Одним из главных нововведений в V100R019C10 стала поддержка визуализации на основе телеметрических данных во всех типах сценариев. По сути, речь идёт о наглядном отображении любых изменений в сети. Кроме того, устройство теперь умеет определять более 75 первопричин возникновения тех или иных проблем и помогает наметить действия для их устранения (запуск скриптов и пр.).

Важной новостью стало появление версии Standalone, включающей в себя как iMaster NCE, так и FabricInsight и предназначенной главным образом для дата-центров небольшого размера, не требующих нескольких серверов для управления сетью.

Изменения в системе лицензирования

Для лучшего понимания функциональных особенностей FabricInsight следует пояснить, какие изменения произошли в бизнес-модели распространения сетевых продуктов Huawei. Если количество коммутаторов не достигает сотни, такой вариант классифицируется как standalone edition и подразумевает наличие лицензии N1. Кластер из трёх и более серверов уже поставляется в комплекте с платформой аналитики больших данных. Решение Advanced solution, включающее в себя несколько сотен свитчей, рекомендуется использовать совместно с инструментарием для анализа сетевых потоков. Все три варианта допускают использование возможностей FabricInsight при наличии лицензии N1.



Любая лицензия подразумевает применение всего набора телеметрических инструментов и сценариев 1-3-5, за исключением средств анализа TCP-потоков, доступных только в Advanced solution.



Осталось рассказать о конфигурациях серверов, предназначенных для решений Standard и Advanced solution. На сегодняшний день standalone node (один узел) доступен только на сервере Taishan 200. Для работы кластера из трёх узлов необходимо 16 или более вычислительных ядер, 128 Гбайт оперативной памяти и т. д. (см. схему). Объём дата-диска напрямую зависит от того, как долго должна храниться статистика.

KPI-мониторинг

Чуть подробнее остановимся на KPI-мониторинге. Для его применения достаточно задать временной интервал и конкретные пороговые значения, достижение которых будет проверяться на основании полученных телеметрических данных. Доступно много типов метрик, среди которых:

• использование ЦПУ и памяти;
• использование FIB / MAC;
• использование троичной ассоциативной памяти (TCAM) чипа;
• параметры портов;
• размер буфера для очереди;
• разные метрики AI Fabric;
• уровень сигнала, температура и другие параметры работы оптического модуля;
• потеря пакетов.

Предварительная проверка

Инструмент предварительной проверки также оперирует данными, получаемыми с помощью телеметрии. CT scanner позволяет понять, происходили ли в сети те или иные нежелательные события. Часть метрик совпадает с метриками KPI-мониторинга фабрики (главным образом касающиеся ёмкости и производительности). Остальные основываются на результатах анализа верхнего уровня (VXLAN, BGP и др.) и анализа конфигурации. После запуска CT scanner собирает необходимые сведения и формирует исчерпывающий отчёт о состоянии сети.



Выполнять подобные проверки необходимо регулярно, заранее определив интервалы времени между ними. Так легче вовремя заметить возникающие в сети тренды, включающие как периодические, так и непериодические изменения. Это позволяет гораздо полнее и оперативнее понимать, что именно происходит. Притом какой-либо параметр, представляющий особый интерес, можно выбрать для более детального мониторинга.

Неполадки устройств

Мониторинг позволяет выявлять самые разнообразные проблемы, возникающие на уровне устройств. В рассматриваемом случае объектом проверки является свитч, 36 регистрируемых параметров работы которого дают возможность обнаруживать 29 типов неисправностей.

В таблице на схеме перечислены виды неисправностей; модели коммутаторов, позволяющих FabricInsight обнаружить проблему; используемые FabricInsight функции; автоматические действия, предпринимаемые при обнаружении неполадок (предупреждения, рекомендации, запуск скрипта).



Допустим, у устройства зафиксирована нехватка ресурсов, ведущая к падению уровня сервиса. Данные из системного журнала, объединённые с данными телеметрии FIB-ресурсов, позволяют оперативно оценить ситуацию в режиме ручной проверки.



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

Неполадки сети

Посредством FabricInsight с опорой на 18 доступных для анализа метрик удаётся выявлять 10 типов сетевых неполадок. На схеме приведён их полный перечень, а также как и в случае с неполадками устройств модели коммутаторов, позволяющих FabricInsight обнаружить проблему, используемые функции и доступные автоматические действия.



Допустим, деградация или неисправность оптического модуля приводит к ухудшению его работы: линк становится нестабильным. Такие ситуации возникают нерегулярно, и их трудно воспроизвести. Из-за этого обнаружение проблемы может занять много времени. Средства FabricInsight дают возможность сразу заметить падение уровня сигнала или изменение напряжения на модуле.



Средствами сетевой диагностики FabricInsight можно своевременно выявить и проблемы с буфером, часто возникающие в системах с большим количеством серверов, которые отведены под обработку big data. Традиционная NMS (Network Management System) проверяет связанные с буфером параметры каждые пять минут. Возможности телеметрии FabricInsight позволяют уменьшить эти интервалы вплоть до 100 мс и выявить даже самые короткие микроинциденты.

Неполадки на уровне протоколов

Здесь FabricInsight умеет определять шесть типов неполадок, включая конфликт двух мастер-свитчей в M-LAG; проблемы взаимодействия соседних коммутаторов и пр. Эта функциональность доступна при использовании коммутаторов V200R005C00 и более новых.



Рассмотрим конфликт мастер-свитчей. При всех достоинствах технологии M-LAG в случае обрыва линка и неисправности одноранговой сети в системе появляются два мастер-свитча. FabricInsight умеет проактивно реагировать на подобную ситуацию благодаря постоянному контролю состояния peer-линка и DFS.

Неполадки оверлейной сети

Семь типов неполадок оверлейной сети могут быть выявлены благодаря контролю десяти различных метрик. FabricInsight умеет проверять статус лицензии VXLAN, находить ошибки в конфигурациях, определять падение sub-интерфейса и т. д. Опции реагирования аналогичны описанным ранее.

Неполадки сервисов

Для выявления шести типов неполадок на уровне сервисов используется контроль семи метрик. Обнаружению поддаются конфликты IP-адресов, проблемы с установлением соединения, флуд-атака TCP SYN и др. Обратим внимание на то, что для поддержки этих возможностей FabricInsight может понадобиться наличие анализатора TCP-потоков.

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

От автоматизации к автономности

В качестве резюме скажем, что в основе идеологии Intent-Driven Network лежит трёхступенчатая модель реагирования, которая включает в себя сбор информации, её анализ с привлечением средств ИИ и предложения по изменению состояния сети, в том числе в автоматическом режиме.

***

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

С ростом инфраструктуры облака mClouds.ru, нам потребовалось ввести в эксплуатацию новые коммутаторы на 25 Гбит/с на уровне доступа серверов. Расскажем, как мы выбрали Huawei 6865, распакуем оборудование и расскажем наши первые впечатления от эксплуатации.

Формируем требования

Исторически у нас положительный опыт как с Cisco, так и с Huawei. Cisco используем для маршрутизации, а Huawei для коммутации. На данный момент используем CloudEngine 6810. С ним все хорошо оборудование работает исправно и предсказуемо, а стоимость внедрения дешевле, чем аналоги от Cisco и других вендоров. Кстати, про серию 6800 мы уже писали ранее.

Логично продолжить использовать эту связку и далее, но нам нужно более мощное решение расширение сети до 25 Гбит/с на порт, вместо текущих 10 Гбит/с.

Остальные наши требования: аплинки 40/100, неблокируемая коммутация, производительная матрица, поддержка L3, стекирование. Из желаемого на перспективу: поддержка Leaf-Spine, VXLAN, BGP EVPN. Ну и, конечно, цена стоимость эксплуатации влияет на конечную стоимость облака для наших клиентов, поэтому важно выбрать вариант с хорошим соотношением цена-качество.

Выбор и ввод в эксплуатацию

При выборе мы остановились на трех производителях Dell, Cisco и Huawei. Как уже писали выше, мы стараемся использовать уже проверенных временем партнеров, и имеем хорошее представление о том, как ведет себя их оборудование и как работает сервис.

Под наши требования подходили следующие модели:

• Huawei Cloud Engine 6865
• Cisco Nexus 93180YC-EX
• Dell EMC PowerSwitch S5248F-ON

Но после недолгого сравнения мы остановились на первом варианте. Тут повлиял ряд факторов: привлекательная цена, полное соответствие нашим требованиям и бесперебойная работа прошлых моделей этого производителя. Решено, смело заказываем партию CE 6865.


Сравнили, заказали и наконец получили новые коммутаторы

И вот партия приехала в ЦОД. Открываем и на первый взгляд практически не видим визуальных отличий от используемых нами 6810. Единственное, что заметно у новой версии большее число аплинков и порты другого типа (SFP28 и QSFP28, вместо SFP+ и QSFP+ соответственно), что позволит нам увеличить скорость работы сети до 25 Гбит/с вместо 10 Гбит/с для SFP28 и до 100 Гбит/с вместо 40 Гбит/с для QSFP28.


Устанавливаем коммутаторы в новую стойку

Опыт эксплуатации

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

По нашим ощущениям интерфейс Huawei VRP где то между IOS и Comware. И тут будет проще, если вы работали именно с Comware от HPE, а вот пользователям Cisco, наоборот будет посложнее. Конечно, это не критично, но тоже стоит учесть при выборе оборудования.

Опыт работы с коммутацией Huawei на протяжении уже более 4 лет, не оставляет сомнений в выборе. CloudEngine 6885 не уступает решениям конкурентов в техническом плане, радует своей ценой и позволяет предоставлять нам надежные облачные решения для наших клиентов.

C удовольствием готовы ответить на ваши вопросы про железо и облака в комментариях. Про настройку CloudEngine 6885 мы также расскажем подробнее в одной из следующих статей подписывайтесь на наш блог, чтобы не пропустить.

На прошедшей в онлайн-режиме Huawei FSI Week 2020 технический директор линейки продуктов Huawei для передачи данных Дэниел Тан (Daniel Tang) доступным языком рассказал про новейшие достижения компании по части сетевых решений для дата-центров, которые обеспечивают превращение ЦОДа из просто облачного в по-настоящему интеллектуальный. А заодно сделал короткий экскурс в предысторию этого превращения.

Что изменилось в банкинге для потребителя

В Китае ещё каких-то пять лет назад получить кредит было делом небыстрым для простого смертного уж точно. Требовалось заполнить уйму бумаг, отправить или отнести их в отделение банка, возможно даже отстояв в очереди, и назад домой, ждать решения. Сколько ждать? А как выйдет, от недели до нескольких месяцев.

К 2020 году эта процедура упростилась разительно. Недавно я провёл маленький эксперимент попробовал получить кредит с помощью мобильного приложения своего банка. Несколько тапов по экрану смартфона и система обещает дать мне ответ самое позднее через четверть часа. Но уже меньше чем через пять минут мне падает push-уведомление с указанием того, на заём какого размера я вправе рассчитывать. Согласитесь, впечатляющий прогресс в сравнении с ситуацией пятилетней давности. Любопытно, на что требовались целые дни и недели в недавнем прошлом.



Так вот, раньше большая часть времени уходила на проверку данных и скоринг вручную. Все сведения из анкет и прочих бумаг нужно было внести в IT-систему банка. Но это было лишь началом мытарств: сотрудники банка лично проверяли вашу кредитную историю, после чего принимали итоговое решение. Покидали офис они в 17:00 или 18:00, на выходных отдыхали, и процесс, как следствие, мог затянуться надолго.

В наши дни всё иначе. Человеческий фактор во многих задачах цифрового банкинга вообще вынесен за скобки. Оценка, включая антифрод- и AML-проверки, выполняется автоматически, с применением умных алгоритмов. Машинам отдых ни к чему, поэтому функционируют они без выходных и круглосуточно. Кроме того, изрядный объём сведений, необходимых для принятия решений, уже хранится в банковских базах данных. А значит, вынесение вердикта осуществляется за гораздо более короткий период, чем в айтишной древности.

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



Такие преобразования происходят не только в финансах, но и практически во всех бизнес-вертикалях. Для компаний самого разного профиля (и для нас, как производителя решений) дата-центры сейчас главная опора в мире, где как никогда остра конкуренция интеллектуальных разработок. Ещё лет пять назад было мейнстримом рассуждать в русле того, что дата-центр вписан в мир облачных технологий, и это предполагало возможности гибко масштабировать общий распределяемый пул ресурсов для вычислений и хранения данных. Но на дворе эра умных решений, и в ЦОДе мы можем на постоянной основе производить интеллектуальный анализ данных, конвертируя полученные результаты в экстраординарный рост производительности. В финансовом секторе эти изменения как раз и приводят в числе многих прочих результатов к тому, что вынесение оценки по запросам на выдачу кредитов радикально ускоряется. Или, например, дают возможность моментально рекомендовать наиболее подходящие конкретному клиенту банка финансовые продукты.

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

Каким должен быть умный ЦОД

Мы в Huawei выделили три главных вызова для дата-центров в эпоху интеллектуальных ЦОДов.

Во-первых, для работы с неиссякающими потоками новых данных необходима экстраординарная пропускная способность. По нашим наблюдениям, за последние пять лет объём хранимых в дата-центрах данных вырос вдесятеро. Но что ещё больше впечатляет, так это какой трафик генерируется при обращении к таким данным. В дата-центрах регистрационного типа вся эта информация использовалась для решения задач учётного характера и нередко лежала мёртвым грузом, а в ЦОДах нового типа она работает нам необходимо обеспечивать постоянный data mining. Как следствие, при доступе к единице хранимых данных производится в 101000 раз больше итераций, чем прежде. Скажем, при обучении ИИ-моделей практически нон-стоп фоново выполняются вычислительные задачи с постоянным функционированием алгоритмов нейросети, ради того чтобы повысить интеллектуальность системы. Таким образом, растут не только объёмы хранимых данных, но и трафик, который формируется при обращении к ним. Так что вовсе не по прихоти телеком-вендоров на новых моделях цодовских серверах всё больше сто- и двухсотгигабитных портов.

Во-вторых, отсутствие потерь пакетов данных в 2020 году абсолютный the must. Во всяком случае, с нашей точки зрения. Раньше такие потери не были головной болью для инженеров банковских ЦОДов. Узкими местами были вычислительная мощность и эффективность хранения данных. Но средние по индустрии значения и того и другого показателя за минувшие пять лет в мировом масштабе существенно повысились. Закономерно, что бутылочным горлышком в работе дата-центров оказалась эффективность сетевой инфраструктуры. При работе с одним из наших ведущих клиентов мы установили, что каждый процент, добавляющийся к показателю потери пакетов данных, грозит снизить эффективность обучения ИИ-моделей вдвое. Отсюда огромное влияние на продуктивность и результативность использования вычислительных ресурсов и систем хранения данных. Вот что необходимо преодолеть, чтобы поддержать превращение простого дата-центра в дата-центр интеллектуальной эпохи.

В-третьих, важно предоставлять сервис бесшовно и беспрерывно. Современный цифровой банкинг приучил, и приучил совершенно правильно, людей к тому, что услуги финансовых организаций могут, вернее, даже должны быть доступны 24/7. Обычная ситуация: замотавшийся предприниматель со сбитым распорядком дня, остро нуждающийся в дополнительных средствах, просыпается ближе к полночи и хочет выяснить, на какую кредитную линию ему рассчитывать. Пути назад отрезаны: у банка больше нет возможности планово приостановить работу ДЦ, чтобы что-то починить или провести апгрейд.

Наше решение CloudFabric 2.0 как раз и предназначено для того, чтобы справляться с перечисленными вызовами. Оно поддерживает высочайшую пропускную способность, интеллектуальное управление сетями ЦОД и безукоризненное функционирование сетей с автономным управлением (англ. autonomous driving networks ADN).

Что есть в CloudFabric 2.0 для умных ЦОДов

Что касается высокой пропускной способности, мы закладываемся не только на масштабирование своих сетевых решений, но и на гибкость в работе с ними. Например, цодовские коммутаторы Huawei линейки CloudEngine стали первыми в индустрии устройствами такого класса со встроенным процессором для нейросетевых вычислений в режиме реального времени, помогающим в том числе решать проблемы внутри сетевой инфраструктуры и не допускать потери пакетов данных (это достигается применением алгоритма iLossless, в том числе для сценария iNOF RoCE). Но, разумеется, имеет значение и собственно пропускная способность. В том числе важна поддержка интерфейсов 400 Гбит/с, равно как и обратная совместимость с распространёнными на текущий момент десяти-, сорока- и стогигабитными подключениями.

Опорным узлам инфраструктуры должна быть под силу и работа с высокой плотностью подключений (так называемые high-density-сценарии), при возможности значительного масштабирования решения. В нашей флагманской цодовской модели CloudEngine 16800 реализована поддержка до 48 портов по 400 Гбит/с на слот втрое больше, чем у ближайшего к ней аналога от наших конкурентов.

Что касается системы в целом, возможности по расширению пропускной способности в расчёте на шасси (per chassis scalability) тоже впечатляющие 768 портов по 400 Гбит/с на одно шасси, или вшестеро больше, чем позволяют решения других игроков рынка. Это даёт нам основания называть CloudEngine 16800 самым производительным коммутатором для ЦОДа в эпоху победившего ИИ.



На передний план выходит и интеллектуальная составляющая сетевого решения. В частности, необходима она и для того, чтобы обеспечивать нулевой уровень потерь пакетов данных. Для достижения такого результата мы применяем самые передовые свои технологические достижения, включая встроенный ИИ-процессор для нейросетевых вычислений, а также ранее упомянутый алгоритм iLossless. Делая проекты для своих ведущих заказчиков, мы убедились в том, что эти решения способны существенно повысить производительность систем по меньшей мере в двух распространённых сценариях.

Первый обучение ИИ-моделей. Оно требуется постоянного обращения к данным и вычислений по огромным матрицам или тяжеловесных операций с TensorFlow. Наш iLossless способен увеличивать производительность обучения ИИ-моделей на 27% процентов доказано на реальных кейсах и подтверждено тестом лаборатории The Tolly Group. Второй сценарий повышение эффективности систем хранения данных. Её, в свою очередь, применение наших разработок способно поднять приблизительно на 30%.

Помимо всего прочего, вместе со своими заказчиками мы стремимся опробовать новые возможности, которые открывают наши разработки. Уверены, посредством улучшения завязанной на Ethernet коммутационной фабрики (switching fabric) для дата-центра нам под силу преобразовать высокопроизводительную цодовскую фабрику с сетью хранения данных в единую, целостную основанную на Ethernet инфраструктуру. Так, чтобы не только поднять производительность процессов обучения ИИ-моделей и улучшить доступ к программно-определяемым хранилищам данных, но и ощутимо оптимизировать совокупную стоимость владения дата-центром путём взаимной интеграции и объединения вертикальных, независимых на физическом уровней сетей.



Многим нашим клиентам нравится обкатывать эти новые возможности. И один из таких клиентов сама Huawei. В частности, входящая в состав нашей группы компаний Huawei Cloud. Тесно сотрудничая с нашими коллегами из этого подразделения, мы удостоверились в том, что, гарантировав им отсутствие потерь пакетов данных, дали импульс к заметному улучшению их бизнес-процессов. Наконец, среди своих внутренних достижений отметим тот факт, что в Atlas 900, самом крупном ИИ-кластере в мире, мы в состоянии обеспечивать вычислительную мощность, задействуемую под обучение искусственного интеллекта, на отметке выше 1 тыс. петафлопс высочайший показатель в компьютерной индустрии на сегодняшний день.

Другой остроактуальный сценарий облачное хранение данных с использованием All-Flash-систем. По меркам отрасли это очень трендовый сервис. При наращивании вычислительных ресурсов и расширении хранилищ естественным образом требуются и передовые технологии из сферы цодовских сетевых решений. Так что мы продолжаем работать с Huawei Cloud и воплощаем всё новые и новые прикладные сценарии с применением своих сетевых решений.

Что умеют сегодня ADN-сети

Обратимся к сетям с автономным управлением (ADN). Спору нет, программно-определяемые сети (software-defined networks) с точки зрения технологий уверенный шаг вперёд в управлении сетевой составляющей дата-центра. Прикладное воплощение концепции SDN значительно ускоряет инициализацию и конфигурирование сетевого слоя ЦОДа. Но, конечно, предоставляемых ею возможностей недостаточно для того, чтобы полностью автоматизировать O&M дата-центра. Чтобы пойти дальше, нужно справиться с тремя первоочередными вызовами.

Во-первых, в сетевой инфраструктуре дата-центров всё больше возможностей, связанных с предоставлением сервисов и настройками их функционирования, в финансовом секторе особенно. Важно иметь возможность автоматически переводить запрос сервисного уровня (service-level intent) на сетевой уровень.

Во-вторых, дело упирается и в верификацию таких инкрементальных команд (incremental provisioning commands). Понятное дело, в сетях ЦОДов многое сконфигурировано давным-давно, на базе крепко укоренившихся или даже устаревших подходов. Как убедиться в том, что дополнительная настройка не нарушит отлаженных процедур? Без автоматической верификации новых дополнительных настроек не обойтись. Именно автоматической, поскольку совокупность существующих настроек в ЦОДе обычно непомерно велика. Вручную с ней практически не совладать.

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

Сети класса ADN могут помочь нам ответить на эти вызовы, которые сопряжены с переходом к подлинно умным дата-центрам. И идеология сетей с автономным управлением (она перекочевала в мир дата-центров из соседней индустрии на стыке IoT и V2X, в частности) позволяет пересмотреть подходы к автоматизации на разных уровнях сети ЦОДа.



На текущий момент в автономности управлении сетей для дата-центров мы достигли уровня L3 (conditional automation). Это означает высокую степень автоматизации ЦОДа, при которой вмешательство человека требуется точечно и лишь при определённых условиях.

Между тем в ряде сценариев возможна и полная автоматизация. С нашими клиентами мы уже работаем в рамках совместной программы по реализации инноваций для всесторонней автоматизации сетей ЦОДов в соответствии с концепцией ADN, прежде всего в разрезе устранения проблем в сети, и применительно к самым злободневным и трудоёмким из них добились успехов: так, с помощью наших интеллектуальных технологий автоматически удаётся закрыть около 85% наиболее часто развивающихся сценариев сбоев в сетях дата-центров.

Эта функциональность реализуется в рамках нашей концепции O&M 1-3-5: минута на установление того факта, что сбой произошёл, или на обнаружение риска сбоя, три минуты на то, чтобы определить его первопричину, и пять минут на то, чтобы предложить, как его ликвидировать. Само собой, пока для принятия окончательных решений необходимо человеческое участие в частности, выбрать одно из возможных решений и отдать команду на его исполнение. Кто-то должен брать на себя ответственность за выбор. Однако, отталкиваясь от практики, мы полагаем, что система и в нынешнем её исполнении предлагает весьма квалифицированные и уместные решения.

Вот вкратце наиболее сложные вызовы, которые стоят перед архитекторами умных ЦОДов в 2020 году, и мы с ними уже фактически справились. Например, функциональность для перевода запросов с сервисного уровня на сетевой и для автоматической верификации настроек уже входит в CloudFabric 2.0.



Нам приятно, что наши достижения были оценены и в этом году мы получили награду Выбор клиентов в рамках рейтинга Gartner Peer Insights, а также F&S Global Data Center Switch Technology Leadership Award за коммутатор CloudEngine 16800, который был отмечен за выдающуюся пропускную способность, высочайшую плотность 400-гигабитных интерфейсов и общую масштабируемость системы, а также за интеллектуальные технологии, позволяющие, в частности, свести к нулю уровень потери пакетов данных.