Шаблон конфигурации рабочей нагрузки Edge

Статья
2023-06-08

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

Контекст и проблема

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

Решение

Существует несколько распространенных характеристик управления конфигурацией для пограничных рабочих нагрузок:

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

Проблемы и рекомендации

При принятии решения о реализации этого шаблона следует учитывать следующие моменты:

Разрешение изменений, когда грань не подключена к облаку, значительно повышает сложность управления конфигурацией. Вы можете реплицировать изменения в облаке, но с этим возникают проблемы:
- Проверка подлинности пользователей, так как она использует облачную службу, например идентификатор Microsoft Entra.
- Разрешение конфликтов после повторного подключения, если рабочие нагрузки получают непредвиденные конфигурации, требующие вмешательства вручную.
Граничная среда может иметь ограничения, связанные с сетью, если топология соответствует требованиям ISA-95. Вы можете преодолеть такие ограничения, выбрав технологию, которая обеспечивает подключение между слоями, например иерархии устройств в Azure IoT Edge.
Если конфигурация во время выполнения отделяется от выпусков программного обеспечения, изменения конфигурации необходимо обрабатывать отдельно. Чтобы предложить функции истории и отката, требуется хранить прошлые конфигурации в хранилище данных в облаке.
Ошибка в конфигурации, например компонент подключения, настроенный для несуществующей конечной точки, может нарушить рабочую нагрузку. Поэтому важно обрабатывать изменения конфигурации при обработке других событий жизненного цикла развертывания в решении наблюдаемости, чтобы панели мониторинга наблюдаемости могли помочь сопоставить системные ошибки с изменениями конфигурации. Дополнительные сведения о наблюдаемости см. в руководстве по мониторингу облака: наблюдаемость.
Общие сведения о ролях, которые играют облачные и пограничные хранилища данных в непрерывности бизнес-процессов. Если облачное хранилище данных является единственным источником истины, пограничные рабочие нагрузки должны иметь возможность восстановить предполагаемые состояния с помощью автоматизированных процессов.
Для обеспечения устойчивости хранилище пограничных данных должно выступать в качестве автономного кэша. Это имеет приоритет над соображениями задержки.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

Примеры рабочих нагрузок:

Решения, которые подключаются к ресурсам на производственной площадке для приема данных — OPC Publisher, например, и управления и контроля.
Рабочие нагрузки машинного обучения для прогнозного обслуживания
Рабочие нагрузки машинного обучения, проверяющие качество в режиме реального времени на производственной линии

Примеры

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

Вариант внешнего контроллера конфигурации

Схема архитектуры для вариантов внешнего контроллера конфигурации.

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

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

Преимущества этого варианта:

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

Вариация конфигурации внутреннего поставщика

Схема архитектуры для варианта внутреннего поставщика конфигурации.

В варианте внутреннего поставщика конфигурации рабочая нагрузка извлекает конфигурации из поставщика конфигурации. Пример реализации см. в статье "Реализация пользовательского поставщика конфигурации в .NET". В этом примере используется C#, но можно использовать другие языки.

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

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

Преимущества этого варианта:

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

Решения на основе IoT Edge

Схема архитектуры для варианта на основе I o T Edge.

Облачный компонент эталонной реализации IoT Edge состоит из Центра Интернета вещей, выступающего в качестве контроллера облачной конфигурации. Функция двойника модуля Центра Интернета вещей Azure распространяет изменения конфигурации и сведения о текущей примененной конфигурации с помощью требуемых и сообщаемых свойств двойника модуля. Служба управления конфигурацией выступает в качестве источника конфигураций. Он также может быть пользовательским интерфейсом для управления конфигурациями, системой сборки и другими средствами, используемыми для разработки конфигураций рабочих нагрузок.

База данных Azure Cosmos DB хранит все конфигурации. Он может взаимодействовать с несколькими центрами Интернета вещей и предоставляет журнал конфигурации.

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

При создании новой конфигурации в службе управления конфигурацией он хранится в Azure Cosmos DB, а требуемые свойства пограничного модуля изменяются в Центре Интернета вещей, где находится устройство. Затем конфигурация передается узлом IoT на граничное устройство. Ожидается, что пограничный модуль будет применять конфигурацию и сообщать через двойника модуля состояние конфигурации. Затем служба состояния конфигурации прослушивает события изменения двойника и при обнаружении того, что модуль сообщает об изменении состояния конфигурации, записывает соответствующее изменение в базе данных Azure Cosmos DB.

Краевой компонент может использовать либо внешний контроллер конфигурации, либо внутреннего поставщика конфигурации. В любой реализации конфигурация передается в нужных свойствах двойника модуля или в случае передачи больших конфигураций, требуемые свойства двойника модуля содержат URL-адрес в хранилище BLOB-объектов Azure или в другую службу, которую можно использовать для получения конфигурации. Затем модуль сигнализирует в отчётных свойствах двойника модуля, успешно ли применена новая конфигурация и какая конфигурация применяется сейчас.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основной автор:

Хизер Камм | Старший менеджер по программам

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

Шаблон внешнего хранилища конфигураций