Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Во время жизненного цикла решения Интернета вещей часто приходится перемещать устройства между центрами Интернета вещей. Причины этого перемещения могут включать следующие сценарии:
Географическое расположение и географическая задержка: при перемещении устройства между расположениями сетевая задержка снижается за счет переноса устройства в ближайший центр Интернета вещей.
Многотенантность: устройство может использоваться в одном решении Интернета вещей и переназначать новому клиенту или сайту клиента. Этот новый клиент может обслуживаться с помощью другого центра Интернета вещей.
Смена решения: устройство может быть перемещено в новое или обновленное решение Интернета вещей. Для переназначения устройства может потребоваться взаимодействие с новым центром Интернета вещей, подключенным к другим компонентам внутреннего сервера.
Карантин: аналогичен смене решения. Устройство, которое неисправно, скомпрометировано или устарело, может быть переназначено в хаб IoT, который позволяет только обновляться и возвращаться в соответствие. Как только устройство будет функционировать должным образом, оно переносится в свой основной центр.
Поддержка переподготовки в службе подготовки устройств удовлетворяет эти требования. Устройства можно автоматически переназначить новым центрам Интернета вещей на основе политики повторной подготовки, настроенной в записи регистрации устройства.
Данные о состоянии устройства
Данные о состоянии устройства формируются из двойника устройства и возможностей устройства. Эти данные хранятся в экземпляре службы развертывания устройств и в узле Интернета вещей, которому назначено устройство.
При начальной подготовке устройства с помощью экземпляра службы предварительной настройки устройств выполняются следующие действия:
Устройство отправляет запрос на подготовку в экземпляр службы подготовки устройств. Инстанция службы проверяет подлинность идентичности устройства на основе записи регистрации и создает начальную конфигурацию данных о состоянии устройства. Экземпляр службы назначает устройство центру Интернета вещей на основе конфигурации регистрации и возвращает это назначение центра Интернета вещей устройству.
Экземпляр службы подготовки предоставляет копию данных о начальном состоянии устройства в назначенный центр Интернета вещей. Устройство подключается к назначенному центру Интернета вещей и начинает работать.
С течением времени операции устройства и внутренние операции могут обновлять данные о состоянии устройства в Центре Интернета вещей. Сведения о начальном состоянии устройства, которые хранятся в экземпляре службы подготовки устройств, остаются без изменений. Эти данные представляют начальную конфигурацию.
В зависимости от сценария, когда устройство перемещается между центрами Интернета вещей, также может потребоваться перенести состояние устройства, обновленное в предыдущем Центре Интернета вещей, в новый центр Интернета вещей. Политики повторной настройки в Службе подготовки устройств могут поддерживать эту миграцию.
Политики повторной подготовки
В зависимости от сценария устройство может отправить запрос экземпляру сервиса настройки при перезагрузке. Она также поддерживает метод запуска подготовки вручную по требованию. Политика повторной подготовки в записи регистрации определяет способ обработки этих запросов экземпляром службы подготовки устройств. Политика также определяет, следует ли переносить данные о состоянии устройства во время повторной подготовки. К отдельным регистрациям и группам регистраций применяются одни и те же политики.
Повторное создание и перенос данных. Эта политика используется по умолчанию для новых записей регистрации. Эта политика начинает действовать, когда устройства, связанные с записью регистрации, отправляют новый запрос (1). В зависимости от конфигурации параметров регистрации устройство может быть переназначено другому узлу IoT. Если устройство сменяет центр Интернета вещей, регистрация устройства в начальном Центре Интернета вещей удаляется. Обновленные сведения о состоянии устройства из этого начального центра Интернета вещей переносятся в новый центр Интернета вещей (2). Во время миграции состояние устройства сообщается как назначение.
Повторное создание и сброс на начальную конфигурацию. Эта политика принимает меры, когда устройства, связанные с записью регистрации, отправляют новый запрос на подготовку (1). В зависимости от конфигурации параметров регистрации устройство может быть переназначено другому узлу IoT. Если устройство сменяет центр Интернета вещей, регистрация устройства в начальном Центре Интернета вещей удаляется. Данные начальной конфигурации, полученные экземпляром службы подготовки во время подготовки устройства, предоставляются в новый центр Интернета вещей (2). Во время миграции состояние устройства сообщается как назначение.
Эта политика часто используется для сброса параметров до заводских настроек без смены центров Интернета вещей.
Никогда не повторное создание: устройство никогда не переназначается другому концентратору. Эта политика предоставляется для управления обратной совместимостью.
Примечание.
DPS всегда вызывает пользовательский веб-хук выделения, независимо от политики реподготовки, в случае наличия нового ReturnData для устройства. Если политика повторной подготовки настроена на "никогда не подготавливать повторно", вызывается веб-перехватчик, но устройство не изменяет назначенный концентратор.
При проектировании решения и определении логики повторной подготовки необходимо учитывать несколько действий. Например:
- Как часто устройства будут перезапущены
- Квоты и ограничения DPS
- Ожидаемое время развертывания для вашего флота (поэтапное развертывание и все одновременно)
- Возможность повторных попыток, реализованная в клиентском коде, как описано в общем руководстве по повторным попыткам в Центре архитектуры Azure
Совет
Рекомендуется не проводить подготовку при каждой перезагрузке устройства, поскольку это действие может вызвать проблемы при проведении повторной подготовки нескольких тысяч или миллионов устройств одновременно. Вместо этого следует попытаться использовать API поиска состояния регистрации устройств и попытаться подключиться к этой информации для Центр Интернета вещей. Если это не удается, попробуйте повторно представить данные Центра Интернета вещей, которые могут измениться. Помните, что запрос к состоянию регистрации считается новой регистрацией устройства, поэтому следует учитывать ограничение регистрации устройства. Кроме того, рекомендуется реализовать соответствующую логику повторных попыток, например экспоненциальное замедление с рандомизацией, как описано в общем руководстве по повторным попыткам. В некоторых случаях, в зависимости от возможностей устройства, можно сохранить сведения о IoT Hub непосредственно на устройстве, чтобы подключиться непосредственно к IoT Hub после первоначальной настройки с помощью DPС. Если вы решили сохранить непосредственно на устройстве, убедитесь, что вы реализуете резервный механизм в случае возникновения конкретных ошибок из Центра Интернета вещей . Например, рассмотрим следующие сценарии:
- Повторите операцию Центра Интернета вещей, если код результата равен 429 (слишком много запросов) или ошибка в диапазоне 5xx. Не повторяйте попытку для других ошибок.
- В случае ошибки 429 повторите попытку только по истечении времени, указанного в заголовке Retry-After.
- В случае ошибок 5xx используйте экспоненциальное увеличение интервала между попытками, начиная первую повторную попытку по крайней мере через 5 секунд после ответа.
- При ошибках, отличных от 429 и 5xx, повторно зарегистрируйтесь через DPS
- В идеале вы также должны поддерживать прямой метод, чтобы вручную инициировать развертывание по запросу.
Мы также рекомендуем учитывать ограничения службы при планировании таких действий, как отправка обновлений в ваш флот. Например, обновление парка одновременно может привести ко всем устройствам повторной регистрации через DPS (что может быть легко выше ограничения квоты регистрации). Для таких сценариев рекомендуется планировать обновления устройств на этапах, а не обновлять весь флот одновременно.
Управление обратной совместимостью
До сентября 2018 г. назначения устройств центрам Интернета вещей были фиксированными. Когда устройство проходило процедуру повторной подготовки, оно могло быть назначено только тому же центру Интернета вещей.
Для решений, которые зависят от этого поведения, служба развертывания обеспечивает обратную совместимость. Сейчас такое поведение сохраняется для устройств в соответствии со следующими критериями.
Устройства подключаются с помощью версии API до доступности встроенной поддержки повторной настройки в службе подготовки устройств. Ознакомьтесь со следующей таблицей API.
В записи регистрации для устройств не задана политика их повторной подготовки.
Такая совместимость гарантирует, что к ранее развернутым устройствам применяется то же поведение, которое было во время начального тестирования. Чтобы сохранить прежнее поведение, не сохраняйте политику переподготовки для этих регистраций. Если политика повторной подготовки задана, она имеет приоритет над поведением. Разрешив политике повторного обеспечения приоритет, клиенты могут обновлять функционирование устройства без необходимости повторного создания его образа.
Следующая блок-схема помогает определить, когда поведение проявляется.
В следующей таблице приводятся версии API до появления собственной поддержки повторной подготовки в службе подготовки устройств:
| REST API | Пакет C SDK | Пакет SDK для Python | Пакет SDK для Node | пакет SDK для Java | Пакет SDK для .NET |
|---|---|---|---|---|---|
| 2018-04-01 и более ранние версии | 1.2.8 и более ранние версии | 1.4.2 и более ранние версии | 1.7.3 или более ранние версии | 1.13.0 или более ранние версии | 1.1.0 или более ранние версии |
Примечание.
Эти значения и ссылки могут меняться. Программные пакеты SDK и API для Интернета вещей Azure имеют версии, чтобы гарантировать, что приложения и службы продолжают работать по мере развития продуктов и API. Мы рекомендуем проверить последние версии пакетов SDK и API Для Интернета вещей Azure в справочной документации по этим пакетам SDK и API. Например, последняя версия REST API службы подготовки устройств Центра Интернета вещей Azure — 2021-10-01.