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

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

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

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

Решение

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

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

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

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

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

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

Используйте этот шаблон в следующих случаях:

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соавторы

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

Автор субъекта:

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

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

Следующие шаги

• Azure IoT Edge
• Что такое Azure IoT Edge?
• Центр Интернета вещей Azure
• Концепция Интернета вещей и Центр Интернета вещей Azure
• Azure Cosmos DB
• Вас приветствует Azure Cosmos DB
• Хранилище BLOB-объектов Azure
• Общие сведения о хранилище BLOB-объектов Azure

Связанные ресурсы

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