Куда идешь, Ежик? Подходы VK Tech для построения Cloud-on-the-Edge решений

Добрый день, хабровчане! Вы больше привыкли к моим статьям об истории техники, но сегодня пришла пора поговорить о современных решениях. С вами Виталий Прокофьев, и в этот раз я выступаю не как основатель коллекции Digital Vintage, а как человек, который уже много лет занимается развитием и внедрением On-Premise облачных решений на базе VK Private Cloud. Сегодня хочу рассказать вам о нашем видении инфраструктурных решений для пограничных (Edge) вычислений с сохранением привычной облачной среды — Cloud-on-the-Edge. Объясню, когда облачная автоматизация оправдана на удаленных площадках, сравню Standalone Edge и Hub-and-Spoke по накладным расходам, автономности и требованиям к связи. Покажу, как сочетать эти подходы в одной инфраструктуре и упростить развертывание с помощью готовых программно-аппаратных комплексов.

В подготовке материалов статьи также принял участие мой коллега Сергей Сухов (@xelld), ведущий архитектор облачных платформ VK Tech, которого я хотел бы поблагодарить за вклад в проработку дизайна наших Cloud-on-the-Edge решений и особенно их сетевой составляющей.

Зачем нужна облачная автоматизация на пограничных площадках 

Сегодня Edge применяется для сбора данных с IoT-устройств и обеспечения работы технологических площадок разного масштаба. Мы поговорим о площадках с достаточно большой нагрузкой и объемом информации, — от автозаправок и буровых установок до небольших заводов. На таких площадках строить полноценное, пусть и компактное облако на 10–30 узлов еще рано, но инфраструктура уже нужна, а ИТ-подразделение компании привыкло к определенному уровню автоматизации, который дает облако.

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

Стена ограничений: когда использовать Cloud-on-the-Edge не стоит

Что же мешает внедрить Cloud-on-the-Edge повсеместно? Главной проблемой всегда становится экономика проекта. Техника в годы ИИ-бума дорожает с каждым днем, облачные платформы на малых масштабах дают большой оверхед, широкий и стабильный сетевой канал стоит дорого, а в некоторых случаях и вовсе становится недоступной роскошью. Но многие из ограничений можно обойти или нивелировать, если грамотно подойти к архитектуре системы.

Первым делом важно определиться, где строить Cloud-on-the-Edge не нужно. Если на площадке живут один-два статичных сервиса, например унаследованная SCADA-система для управления оборудованием, СКУД или видеонаблюдение, то с большой долей вероятности внедрение автоматизации только усложнит обслуживание и потребует дополнительных затрат на технику и ПО, которые не окупятся. Не стоит идти в Cloud-on-the-Edge и в случае, когда компания еще не внедрила облачные подходы в своей центральной инфраструктуре. Без определенной степени зрелости ИТ-процессов новое усложнение не принесет положительного эффекта.

Компания может активно цифровизировать свои производственные процессы, использовать Cloud-Native-подход, Managed-сервисы, IaC и различную автоматизацию. При этом она планомерно увеличивает объем собираемых данных и стремится предоставить сотрудникам новые информационные сервисы. Или, напротив, хочет приземлить часть ранее централизованных функций на площадку. В таких условиях Cloud-on-the-Edge становится технически и экономически оправданным решением (да, я опять про те же автозаправки!).

Но что же тогда с каналами и оверхедом? Для работы облака нужен слой управления — control plane. Базово это три сервера для обеспечения отказоустойчивости. Они потребляют определенный объем ресурсов, и чем шире функциональность облачной платформы и чем пристальнее следит за ней мониторинг, тем выше это потребление. Да, слой управления можно разместить на тех же серверах, что и нагрузку (самонесущая платформа), но в минимальных инсталляциях оверхед все равно может достигать неприемлемых значений. А еще остается вопрос с хранением данных: далеко не всегда оправданно держать на объекте еще и СХД, а программно определяемое хранилище (SDS) потребует своей доли ресурсов.

Standalone Edge: автономное облако на трех серверах 

Даже в такой архитектуре возможна оптимизация. Гиперконвергентное решение на трех серверах, объединяющее слой управления, программно определяемое хранилище (в нашем случае Ceph и/или High-IOPS) и нагрузку, показывает приемлемый оверхед даже при очень гуманных уровнях переподписки по процессорам — 3.0 по физическим ядрам и 1.5 по потокам. 

Потребление слоя управления составляет 24 vCPU и 128 Гб ОЗУ на один узел, Ceph — 16 vCPU и 64 Гб ОЗУ. Еще 16 vCPU и 64 Гб ОЗУ потребуется выделить для узла логирования и мониторинга. 

При использовании двухсокетных серверов с 32-ядерными процессорами, включенным HT/SMT и 1024 Гб ОЗУ доступный для нагрузки объем ресурсов составит:

(3 сервера × 2 сокета × 32 ядра × 3.0 переподписка) − (3 узла × 24 vCPU) − (3 узла × 16 vCPU) − (1 узел × 16 vCPU) = 440 vCPU

При общем количестве 576 vCPU оверхед по процессорам составит (576 − 440) / 576 = 23,6% — значение высокое, но допустимое для столь компактного и при этом полнофункционального облака.

Аналогично по памяти:

(3 сервера × (1024 Гб − 16 Гб)) − (3 узла × 128 Гб) − (3 узла × 64 Гб) − (1 узел × 64 Гб) = 2384 Гб

* Накладные расходы на ОС гипервизора принимаем равными 16 Гб.

Оверхед по памяти получается еще ниже — 22,3%.

Можно использовать и серверы с меньшим объемом памяти, но относительные накладные расходы станут уже весьма заметны. Оверхед составит почти 45%!

(3 сервера × 512 Гб) − (3 узла × 128 Гб) − (3 узла × 64 Гб) − (1 узел × 64 Гб) = 848 Гб

Для удобства сведем результаты расчетов в таблицу:

И все же такое архитектурное решение применимо для наиболее удаленных локаций с повышенными требованиями к автономности, где невозможно построить мало-мальски стабильный канал. Помимо сравнительно высокого оверхеда на минимальном масштабе, Standalone-архитектура усложняет централизацию управления. Текущие средства управления VK Private Cloud не позволяют управлять множеством инсталляций платформы как единым целым: у каждой будет отдельный набор проектов и сетей, хотя централизованная аутентификация и единый слой автоматизации через Terraform или API все еще возможны. Но это ограничение тоже временное — в одном из будущих релизов появится полноценная поддержка управления несколькими регионами.

Важный плюс Standalone-решения — возможность расширения до полноценного облака. Можно добавить нужное количество гипервизоров, отделить слой управления и СХД и получить классическую инсталляцию частного облака.

Классический Cloud-on-the-Edge по рецепту VK Tech

Отдельно стоящее решение при всех плюсах в части автономности зачастую избыточно. Основной рекомендуемый подход — архитектура Hub-and-Spoke, при которой Edge-площадки выступают в роли зон доступности (Availability Zones) единой распределенной инсталляции.

Слой управления (control plane) располагается в центральной локации или для обеспечения катастрофоустойчивости, распределяется по ЦОДам, связанным быстрыми и стабильными каналами с минимальной задержкой (Hub). На этих же площадках размещаются и основные вычислительные ресурсы компании. Edge-площадки (Spoke) подключаются к единой облачной платформе. За счет масштаба и переиспользования ресурсов центрального слоя управления удается снизить оверхед до 2,4% при общем числе вычислительных узлов более 100 и использовании выделенной СХД или программно определяемого хранилища. Минимальное количество узлов для такого решения — 2 при использовании внешней СХД или SDS High-IOPS HA от VK Tech и 3 при использовании Ceph в конвергентном режиме.

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

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

• Требования к сетевому каналу. Они остаются сравнительно невысокими. Платформа толерантна к умеренному джиттеру и относительно высоким задержкам — до 100 мс RTT.

• Пропускная способность. В основном она зависит от бизнес-требований к обмену данными между площадками. Для нужд управления и мониторинга, который может быть как локальным, так и централизованным, обычно достаточно скромных 5–10 Мбит/с.

• Особенности сетевой архитектуры. Использование в таких зонах оверлейных сетей и технологий вроде Floating IP стоит исключить, чтобы не зависеть от функций control plane. Более надежным выбором будет прямое назначение адресов из маршрутизируемых в КСПД сегментов.

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

• Логика отказоустойчивости. В текущей версии платформы для эвакуации ВМ с отказавшего гипервизора нужна связь с Hub. Edge-площадка выдержит отказ канала или вычислительного узла, но при одновременном отказе обоих эвакуация не запустится.

Гибридный ландшафт: все и сразу

На самом деле, для многих крупных компаний выбор между Hub-and-Spoke и Standalone не будет жестким и однозначным. Чаще всего он зависит от конкретной площадки. Если разбавить пример с автозаправками энергетическим сектором, то для крупных тепло- или гидроэлектростанций идеальным выбором станет классический Hub-and-Spoke с минимальным оверхедом и глубокой интеграцией. А для небольших цифровых подстанций или малых лесных ГЭС, затерянных в лесах Карелии, критически важна полная автономность, а значит, выбор падает на Standalone Edge.

Более того, самой центральной инфраструктуре компании может потребоваться несколько зон доступности в разных регионах, связанных с основным control plane. И все это — абсолютно валидные, рабочие подходы, которые могут и должны сосуществовать в одной ИТ-стратегии.

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

• Изолированные сегменты. Набор полностью независимых Standalone-инсталляций для объектов с экстремальными требованиями к автономности.

• Пограничные зоны (Spoke). Десятки или сотни легковесных Edge-площадок, управляемых из единого центра.

• Выход в публичное облако (Hybrid Cloud). Подключение ресурсов публичного облака для размещения временных или сезонных нагрузок, а также выноса сред разработки и тестирования (Dev/Test). Это можно реализовать как в традиционном формате, так и в виде дополнительной зоны доступности на bare-metal серверах провайдера, связанной с частным облаком компании через выделенный защищенный канал.

Программно-аппаратные комплексы для Edge: готовое решение с единой поддержкой 

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

Традиционно наши преимущества складываются из нескольких факторов:

• Совместимость. Поддержка широкого пула аппаратного обеспечения и бесшовная интеграция с другими программными продуктами.

• Гибкие форматы поставки. Возможность приобрести как отдельные лицензии на ПО для установки на собственное железо, так и готовое решение в формате программно-аппаратного комплекса (ПАК).

• Экспертное сопровождение. Мои коллеги из VK Tech помогают спроектировать целевую архитектуру под ваши задачи и развернуть ее на площадках.

• Высокий уровень Enterprise-поддержки. Полный цикл сопровождения — от базовых консультаций до помощи в режиме 24/7 на этапе промышленной эксплуатации.

• Соответствие регуляторным требованиям. Продукт включен в реестр отечественного ПО, имеет сертифицированную ФСТЭК версию и поставляется с полным пакетом документов для прохождения аттестации.

Особое значение для инфраструктурного софта имеет выбор совместимого железа. Мы принципиально не привязываем заказчика к конкретным вендорам оборудования (no vendor lock-in). Но для тех, кто хочет быть уверен в стабильности системы или кому банально удобнее приобрести решение под ключ, мы предлагаем готовые ПАК.

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

Заключение

Построение Cloud-on-the-Edge — это всегда поиск компромисса между тремя переменными: уровнем автономности площадки, доступной полосой пропускания сети и ресурсами железа, которые приходится отдавать под оверхед платформы.

Опыт VK Tech показывает, что эффективная пограничная инфраструктура строится на трех принципах:

1. Четкая сегментация. Не стоит тянуть облачную автоматизацию туда, где годами крутятся два статичных сервиса. Но если ваша распределенная инфраструктура растет и автоматизируется, а инженеры больше не хотят жить без Terraform, то Cloud-on-the-Edge быстро окупает себя.

2. Гибкий выбор архитектуры. Для глухой тайги или автономных объектов идеален Standalone Edge, пусть и с оверхедом по памяти до 45% на минимальном масштабе. Для распределенной сети объектов с доступным аплинком эффективнее использовать Hub-and-Spoke, где накладные расходы платформы на точках стремятся к нулю.

3. Стандартизация оборудования. На масштабе в десятки и сотни Edge-площадок ручная сборка и разнородное железо становятся неподъемными для поддержки. Проверенные программно-аппаратные комплексы в этом сценарии — базовое условие выживания ИТ-отдела.

Мир Edge-вычислений быстро эволюционирует, и подходы, которые вчера казались прерогативой гигантских ЦОДов, сегодня успешно работают на обычных АЗС, буровых и небольших заводах.

А как у вас? Расскажите в комментариях, с какими инфраструктурными болями вы сталкивались при автоматизации удаленных площадок? Что выбираете в своих проектах — полную автономность на местах или жесткую централизацию управления? Будет интересно обсудить ваш опыт!