Периферийные вычисления (Edge Computing) могут стать ключом к более быстрым и эффективным процессам, но они включают в себя сложный набор переменных. Технологический евангелист Red Hat Гордон Хафф описывает на портале Enterprisers Project факторы, которые следует учитывать при разработке корпоративной стратегии периферийных вычислений.

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

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

Могут сыграть свою роль и различные аспекты сетевого подключения: пропускная способность — ограниченный ресурс, и сеть может быть не на 100% надежной; а вы можете захотеть, чтобы ваш розничный магазин мог работать на определенном уровне, даже если связь с головным офисом прервется. Также могут быть причины, связанные с нормативными требованиями или управлением данными, для отправки их в какое-то центральное место.

1. Единой периферии не существует

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

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

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

Периферия — это гибрид!

2. Масштабирование периферии требует автоматизации

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

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

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

3. Kubernetes нужен и на периферии

Kubernetes обычно ассоциируется с кластерами контейнеров. Но эта платформа занимает все большее место и на периферии. На это есть несколько причин.

Первая заключается в том, что «периферийный» не обязательно означает «маленький». Например, телекоммуникационные компании все чаще заменяют специализированное оборудование программно-определяемыми инфраструктурами, такими как сеть радиодоступа (RAN), связывающая пользовательское оборудование с опорной сетью. Подобные приложения могут выиграть от использования Kubernetes для координации множества компонентов архитектуры.

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

Например, компания Lockheed Martin использует edge-решения для развертывания обученных на системе в Денвере моделей на небольшом периферийном компьютере в своей беспилотной авиационной системе Stalker (UAS). Это позволяет «Сталкеру» использовать бортовые датчики и искусственный интеллект для адаптации в реальном времени к внешним угрозам.

Если предприятие использует Kubernetes в своем дата-центре, разве оно не должно хотеть использовать то же самое ПО везде, где это возможно? Больше стандартизации означает меньше работы с уникальными платформами на разных уровнях архитектуры. Это также помогает избежать необходимости увеличения мощностей для периферийных вычислений в будущем.

Хотя некоторые edge-узлы могут оказаться слишком ограничены для запуска Kubernetes, сообщество активно работает над вариантами платформы, которые уменьшают объем кода, который необходимо запускать, обеспечивая при этом согласованное управление. Это область активных исследований. Наилучший подход для конкретного развертывания будет зависеть от таких факторов, как степень ограниченности ресурсов, надежность сети и требования к доступности.

4. Воспользуйтесь преимуществами устоявшихся схем

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

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

Есть и другие портфельные архитектуры, имеющие непосредственное отношение к периферийным вычислениям. К ним, в частности, относится промышленная периферия (industrial edge), которая применима в нескольких вертикальных отраслях, включая производство. Она обеспечивает маршрутизацию данных датчиков для двух целей: разработки моделей в основном дата-центре и оперативной передачи аналитических выводов в заводские дата-центры.

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

В дополнение к уже рассмотренным портфельным архитектурам следует отметить, что edge-приложения существуют во всех областях: от 5G-телекоммуникаций до профилактического техобслуживания на заводах, эксплуатации автомобильного парка, мониторинга активов и многого другого. Хотя объединение ИТ- и ОТ-систем является сложной задачей, периферийные вычисления уже широко и продуктивно используются.

Edge может стать ключом к более быстрым результатам, основанным на данных, лучшему опыту конечных пользователей и более высокой отказоустойчивости приложений и процессов.