Переход бизнеса на периферийные вычисления (edge computing) требует тщательного планирования. Технологический евангелист Red Hat Гордон Хафф рассказывает на портале Enterprisers Project о ключевых факторах, которые надо учитывать в своей стратегии.
Когда облака появились на сцене, одним из довольно популярных мнений было то, что они поглотят все вычисления. Распространенной аналогией служила электрическая сеть, в значительной степени устраняющая распределенную местную генерацию энергии.
Но существует множество причин, по которым публичные облака не всегда могут заменить локальное оборудование. Если говорить конкретно о периферийных вычислениях, то часто желательно приблизить вычисления к месту сбора данных и их использования. Это становится важным в частности потому, что машинное обучение все чаще используется для автоматизации локальных операций в критических ко времени ситуациях. Кроме того, локальное принятие мер зачастую не только быстрее, но и более устойчиво к перебоям связи, чем постоянная зависимость от центрального узла.
Однако внедрение edge-архитектуры не всегда бывает простым. Вот четыре принципа, которые следует учитывать, когда вы выводите свой бизнес на периферию.
1. Автоматизация и управление не являются необязательными
Нельзя сказать, что автоматизация и управление не важны практически для любой ИТ-инфраструктуры. Конечно, важны. Но огромное количество периферийных устройств и отсутствие местного ИТ-персонала (или даже отсутствие постоянных сотрудников на месте) означает, что они нуждаются в автоматизации и управлении.
Автоматизация использует ПО для создания повторяющихся инструкций и процессов, которые сокращают взаимодействие человека с ИТ-системами. Это, в свою очередь, может улучшить обеспечение ИТ, управление конфигурацией, исправления, оркестровку приложений, безопасность и соответствие нормативным требованиям. Автоматизация обычно осуществляется с помощью рабочих процессов, размещаемых вблизи периферийных конечных точек, и централизованного уровня управления. Локальное выполнение защищает от высоких задержек и разрывов соединения, а централизованное управление обеспечивает интегрированный контроль всей периферийной среды.
Например, розничная сеть может автоматизировать конечные точки для упрощения работы инфраструктуры, усиления политик безопасности и стандартизации конфигурации устройств в филиалах. Массовое конфигурирование, аварийное восстановление, миграция филиалов и действия в ответ на определенные события — все это примеры ролей, которые автоматизация может играть в периферийной среде.
С этим тесно связано управление, которое включает в себя создание стандартной операционной среды. Это является ключом к масштабированию. По мере развертывания стандартного образа во всех средах, от разработки до производства, эти системы необходимо регистрировать в консоли управления периферийной среды. Поддержание политик безопасности также является важной функцией управления.
2. Не вносите случайности в свои бизнес-процессы
Периферия может стать похожей на Дикий Запад, если вы позволите ей это сделать. Даже при наличии систем автоматизации и управления, для поддержания высокой степени согласованности в периферийной среде (и среде дата-центра) все равно требуется приверженность архитектуре.
Одно из объяснений отсутствия согласованности заключается в том, что периферийные устройства зачастую компактнее и менее мощные, чем серверы в дата-центре. Отсюда следует, что на них должно работать другое ПО.
Но это не обязательно так — или, по крайней мере, это не вся история. Вы можете создавать образы системы из небольшого ядра ОС Linux, которое используется в других местах, и настраивать его, добавляя именно то, что вам нужно в плане драйверов, расширений и рабочих нагрузок. Затем образы могут быть версионированы, протестированы, подписаны и развернуты как единое целое, чтобы ваша операционная команда точно знала, что работает на устройствах.
Поэтапные обновления образов можно настроить так, чтобы они происходили только при следующей перезагрузке или цикле питания, что обеспечивает минимальное время простоя. Оно также может быть сокращено благодаря интеллектуальному откату, который может отменить обновление в результате проверки работоспособности конкретного приложения.
Хотя в гибридном облаке, включающем периферийные устройства, как правило требуется некоторая настройка, все же часто можно иметь согласованную основную среду, лежащую в основе всех необходимых настроек.
3. Периферия тоже нуждается в Kubernetes
Эти соображения согласованности могут распространяться и на Kubernetes.
Вы можете подумать: «Подождите... разве Kubernetes не предназначен только для облачных и серверных кластеров?». Не обязательно.
Во-первых, периферийные устройства не обязательно такие уж маленькие. Например, в недавнем исследовании Frost & Sullivan руководители высшего звена компаний заявили, что возможность локального анализа данных является значительным преимуществом периферийных вычислений.
Хотя обучение моделей МО часто по-прежнему происходит в централизованном месте, развертываются они все чаще на периферии. Это позволяет значительно снизить потребность в высокоскоростных соединениях для передачи всех данных для анализа. Это также означает, что любые необходимые локальные действия (например, отключение неисправной машины) не зависят от надежного и быстрого сетевого соединения.
Даже если сегодняшняя рабочая нагрузка относительно невелика, вы можете захотеть оставить свои возможности открытыми. Возможно, рабочая нагрузка будет расти. Возможно, вы захотите добавить опцию высокой доступности. Возможно, вы решите меньше зависеть от надежности сетевого соединения.
Однако применять Kubernetes может иметь смысл по той же причине, которая обсуждалась в предыдущем разделе: согласованность. Если вы развернули Kubernetes в дата-центре, то использование Kubernetes на периферии поможет вам стандартизировать управление жизненным циклом ПО и обеспечить согласованность в гибридной облачной среде. С этой целью реализуется множество проектов по оптимизации Kubernetes для различных сценариев использования с различными требованиями к площадкам, доступности и сетевым ресурсам.
4. Воспользуйтесь помощью сообщества
Существует множество источников информации о периферийных вычислениях. Однако я хотел бы обратить ваше внимание на пару Open Source-проектов, которые документируют полные edge-архитектуры, основанные на шаблонах, которые уже были реализованы организациями.
Portfolio architectures демонстрирует успешное развертывание ПО с открытым исходным кодом, включая периферийные развертывания, и предоставляют лучшие практики архитектуры, инструменты и ссылки на другие связанные ресурсы. Ресурс включает высокоуровневые абстракции сервисов и платформ, схемы, описывающие основные узлы и сервисы, а также их взаимодействие и сетевые соединения, и подробное описание конкретных сервисов.
Validated patterns является естественным продолжением эталонных архитектур. Ресурс содержит весь код, необходимый для создания стека ПО, чтобы ускорить процесс проверки концепции. Типичный шаблон включает в себя дата-центр и один или несколько периферийных кластеров на базе Kubernetes. Все шаги полностью автоматизированы с помощью GitOps для автоматизации развертывания последовательно и в масштабе. Пользователи могут модифицировать шаблон для своего конкретного приложения. Более того, ассоциированный пользователь может сообщать об улучшениях — это еще один пример того, как модель разработки Open Source применяется как для первоначального развертывания, так и для текущей эксплуатации сложного распределенного программного стека.
Отчасти потому, что развертывания периферийных вычислений должны взаимодействовать с беспорядочным физическим миром, они всегда будут иметь свои сложности и уникальные аспекты. Однако если вы воспользуетесь тем, чему научились другие, и будете помнить об основных принципах, таких как автоматизация, управление и последовательность, то сможете получить реальную выгоду для бизнеса.
