iMaster NCE-Fabric: управление, контроль и аналитика для конвергентных платформ
Решение Huawei CloudFabric 3.0 призвано помочь предприятиям из самых разных отраслей раскрыть потенциал гиперконвергентных сетей нового поколения, быстро и эффективно обрабатывать огромные объёмы данных, ускорить цифровую трансформацию — и в целом придать новый импульс развитию цифровой экономики. Об одном из ключевых элементов этого решения, платформе iMaster NCE-Fabric, синергично сводящей воедино возможности искусственного интеллекта, анализа и управления для сетей центров обработки данных, рассказывают Михаил Шпак, технический директор Нuawei по работе со «Сбером», и Андрей Иванько, руководитель группы коммуникационной инфраструктуры «ИНЛАЙН ГРУП».
Насколько в целом актуальны сегодня конвергентные и гиперконвергентные инфраструктуры? В каких отраслях экономики они находят применение — в частности, в России?
Михаил Шпак: В моём понимании даже термин «гиперконвергенция» в определённом смысле уже устарел. Технологии идут вперёд, и заказчикам мало иметь просто некую виртуальную инфраструктуру, как код, — им хочется располагать более гибкой, управляемой платформой, использование которой будет давать реальный результат. Суть в том, что time-to-market и прочие характеристики современного бизнеса — это сегодня не просто красивые KPI, но важные инструменты повседневной работы, и достичь их заметного улучшения можно только за счёт существенной оптимизации ИТ-инфраструктуры.
Пожалуй, самые прогрессивные в этом смысле заказчики сосредоточены у нас в банковском секторе: для них оптимизация процессов жизненно необходима именно в нынешних условиях. Давно прошли те времена, когда банки могли неспешно, по три-четыре месяца, вводить в строй новые участки ИТ-инфраструктуры. Уже года два назад на эту операцию отводилось порядка десяти суток, а сегодня все хотят получать полностью готовые к работе инфраструктурные расширения буквально за считанные часы. По этой причине виртуальные ЦОДы, контейнеры, гибридные облака наиболее интенсивно востребованы именно в банковском секторе, и прямолинейная, безыскусная гиперконвергенция — без автоматизации, без DevOps/SecOps и других новейших инструментов — уже попросту неприменима.
Становятся решительно необходимы сети, связанные с намерениями, выстраиваемые и реорганизуемые по требованию под конкретные приложения. Это уже не просто SDN, столь популярные в недавнем прошлом, но это ADN — autonomous driving networks. Интенсивнее всего ADN развиваются операторами сетей 5G, поскольку там и потребность в них, и конкуренция между участниками рынка наиболее высоки. В enterprise-среде развитие ADN чуть отстаёт по ряду причин, но и здесь они находятся на условном третьем уровне зрелости: далеко ушли от классических SDN, от наложенных сетей, от бесшовной интеграции гибридных облаков и прочих технологий, которые ещё недавно считались самыми передовыми.
Андрей Иванько: Хотел бы дополнить, что гиперконвергентные инфраструктуры обходятся заказчику дешевле классических, — именно поэтому гиперконвергенция сегодня находит приложение практически повсеместно. Достаточно буквально трёх серверов и пары коммутаторов, чтобы начать строить гиперконвергентную инфраструктуру с уровня CloudFabric Easy Solution.
Чем Huawei CloudFabric 3.0 выделяется среди прочих доступных заказчикам DCN-решений? В чём разница между NoF+ и другими реализациями NVMe-oF, например? Насколько широки интегрированные в CloudFabric 3.0 возможности автоматизации, в том числе автоматизации управления и поддержания работоспособности различного оборудования?
М. Ш.: Скорость прогресса технологий сегодня по-прежнему велика: продолжают действовать законы Мура (для полупроводниковых кристаллов) и Меткалфа (для телекоммуникационных сетей). На этом фоне классическая организация сети на основе протокола Ethernet выглядит едва ли не анахронизмом — по сравнению с тем же Fibre Channel: протокол TCP/IP исходно, ещё со времён проекта ARPANET, развивался с упором на гарантию прохождения пакета данных от отправителя к получателю по сети заведомо нестабильного качества, а не на скорость установившегося обмена данными.
И к настоящему времени, хотя Ethernet и успел обойти Fibre Channel по формальной предельной пропускной способности, его продолжают отягощать множество унаследованных из прошлого проблем. Да, теперь на нём возможно запустить протокол NVMe через фабрику — NVMe-oF. Но от потерь на уровне стека TCP/IP, неизбежных вследствие самой природы Ethernet, здесь всё равно никуда не деться. А ведь достаточно буквально 0,1% потерь в канале, чтобы, к примеру, время выхода на ожидаемый результат для системы машинного обучения, основанной на логических регрессиях, увеличилось вдвое.
Вот почему Ethernet начали совершенствовать: придумали механизм ECN (explicit congestion notification), per-flow control и протокол DCBX (data center bridging capability exchange). И всё было бы хорошо, если бы не статичность этих механизмов: они позволяют подстроить параметры сети только под определённые паттерны обмена данными. Стоит этим паттернам измениться — из-за расширения серверного парка, внедрения гибридного облака, запуска новой СУБД и т. п. — и параметры, что называется, плывут, а итоговая производительность падает. Подход Huawei к организации NoF+ отличается тем, что в наши коммутаторы встроены дополнительные тензорные процессоры для машинного обучения.
В результате коммутатор имеет возможность определить, что вот эту порцию трафика, допустим, генерирует СУБД с такими-то параметрами работы, и что для неё необходимы такой-то класс обслуживания и такие-то пороги производительности. Благодаря тензорным процессорам трафик гранулярно замеряется по всей ткани сети, а не только на ключевых узлах, что даёт возможность получать глубокую аналитику — и на её основе оптимально маршрутизировать каждый пакет. Как раз банкам это весьма интересно: скажем, Bank of China, один из топ-4 в Китае, благодаря переходу на такие наши коммутаторы серьёзно увеличил производительность своих СУБД и сократил задержки.
Раньше тензорными процессорами для NoF+ были изготовленные по нашему заказу ASIC-микросхемы, теперь же Huawei применяет чипы исключительно собственной разработки. На территории КНР уже действуют 28-нм процессорные фабрики, так что весь цикл IPD (integrated product development) целиком в наших руках. При этом, хочу отметить, качество работы тензорных процессоров в немалой степени зависит от исполняемых на них алгоритмов, — в их разработке принимает активнейшее участие московская алгоритмическая лаборатория Huawei.
Какую роль в CloudFabric 3.0 исполняет iMaster NCE-Fabric? Какие именно из решаемых этой платформой задач операторы других средств администрирования DCN вынуждены обрабатывать вручную или с привлечением внешних систем автоматизации? Что в целом позволяет говорить об этой платформе как об «интеллектуальной»?
М. Ш.: Об iMaster NCE-Fabric корректно говорить как о платформе, предназначенной для полного цикла работы сети. С точки зрения поставщика сетевого оборудования есть условный «день 0», когда сеть только сама запускается, без каких бы то ни было сервисов; затем настаёт «день 1», «день 2» и т. д. — и в каждый из этих дней вендор должен обеспечивать партнёру и заказчику соответствующую поддержку. Например, в «день 0» это будет помощь с автоматизированным запуском фабрики. И вот как раз iMaster NCE-Fabric обеспечивает то, чего остро недоставало прежде, — автоматизацию «нулевого дня». Теперь можно с помощью довольно простых операций, внеся в стартовую веб-страничку определённые параметры, — через процедуру zero touch provisioning, без ручной настройки сетевых элементов — запустить нашу фабрику.
«День 1» — это запуск сервисов для ЦОДа в целом, для облака, для контейнеров, и он уже требует полностью интеграционных вертикальных решений. Здесь мы сотрудничаем с основными поставщиками облачных продуктов, обеспечивая готовность интегрироваться не только с собственным Huawei Cloud, но и с публичными облаками, такими как AWS, с классическими системами виртуализации (VMware, Hyper-V), с приватными облаками и системами контейнеризации: открытыми (Kubernetes) и проприетарными (IBM OpenShift).
В «день 2» и далее для обеспечения полного жизненного цикла нужно уметь обнаруживать инциденты и очень быстро исправлять их. Телеметрию с целью поиска неисправностей позволяют собирать упомянутые ранее тензорные процессоры, а затем действует известная схема «1—3—5»: примерно за одну минуту собирается информация; анализ с применением дистрибутива больших данных (собранных на кластерах порядка 10–20 тыс. машин) и выдачей рекомендаций занимает около трёх минут. А далее эти рекомендации реализуют администраторы заказчика: либо вручную, тратя на это не более пяти минут, либо просто соглашаясь с предложенным системой рецептом и нажав кнопку в интерфейсе iMaster NCE-Fabric. Вот так выглядит сегодня полный жизненный цикл работы сети: как реализация синергии ADN, аналитики на основе машинного и глубокого обучения, а также NoF+.
Насколько применение iMaster NCE-Fabric упрощает задачи оркестрации контейнерных приложений в условиях гиперконвергентного ЦОДа с динамически меняющимися пулом клиентов и объёмами запрашиваемых ими ресурсов? Как такие задачи решаются на других DCN, в отсутствие подобной платформы?
А. И.: Важнейшее значение с точки зрения обслуживания сети имеет уже упомянутая политика «1—3—5». Кроме того, встроенный интеллект iMaster NCE-Fabric позволяет автоматически обнаруживать петли, выявлять ошибки маршрутизации — словом, с его помощью можно создать knowledge graph, увязывающий все ошибки сети между собой. Банальный пример: если пропадает соединение между двумя коммутаторами, обычное средство определения неисправностей покажет две ошибки, поскольку собирает информацию с устройств по отдельности. И только iMaster NCE-Fabric, автоматически проанализировав ситуацию, покажет, что ошибка одна: эта система в целом настроена на непрерывное изучение всей поступающей информации и выдачу конкретных, детальных рекомендаций. Ещё одна полезная возможность — network change simulation — позволяет проверить, как будет работать сервис (все потоки трафика, включая виртуализацию, контейнеры и пр.) после внедрения некоего нового сервиса ещё до фактического внесения изменений в таблицу маршрутизации. Упомяну и о функции создания снэпшотов, которая делает возможным откат к определённому моменту состояния всей сети разом, без ручного восстановления настроек каждого маршрутизатора, просто по нажатии одной кнопки.
Приведите примеры, желательно уже реализованные в России, развёртывания CloudFabric 3.0 и тех реально ощутимых заказчиками преимуществ, которые обеспечило применение iMaster NCE-Fabric. Каковы сроки окупаемости типичного проекта подобной гиперконвергентной инфраструктуры?
М. Ш.: Российские заказчики — не знаю уж, с чем это связано, — в последнее время стараются не раскрывать технические детали своих новых проектов. Причём наблюдается это повсеместно, и в госсекторе, и в банковской сфере, и в ТЭКе. Примеров реализации CloudFabric 3.0 в России уже немало, а по объёму они зачастую превосходят и ближневосточные, и японские аналогичные кейсы, — но делать такую информацию публичной наши заказчики, увы, не спешат. Самые, конечно, интересные примеры внедрения связаны с банками, поскольку банки в последнее время активно становятся digital first, mobile first, организуют экосистемы, строят облака и т. п. Но и ASP (application service providers), и государственные заказчики тоже проявляют большой интерес к вертикально интегрированным платформам, таким как iMaster NCE-Fabric. Особо отмечу, что на уровне государства уже модно быть технократом, — и в подходе к организации ИТ-инфраструктуры это проявляется самым очевидным образом.