Основные понятия повторной подготовки устройств к добавлению в центр Интернета вещей
Во время жизненного цикла решения Интернета вещей часто приходится перемещать устройства между центрами Интернета вещей. Причинами этого перемещения могут быть следующие сценарии.
Географическое расположение и географическая задержка: при перемещении устройства между расположениями сетевая задержка снижается за счет переноса устройства в ближайший центр Интернета вещей.
Мультитенантность: устройство можно использовать в одном решении Интернета вещей и переназначить новому клиенту или расположению клиента. Обслуживание этого нового клиента может выполняться с помощью другого Центра Интернета вещей.
Смена решения: устройство может быть перемещено в новое или обновленное решение Интернета вещей. Для этого переопределения устройству может потребоваться взаимодействовать с новым центром Интернета вещей, подключенным к другим компонентам серверной части.
Карантин: аналогичен смене решения. Неисправное, скомпрометированное или устаревшее устройство может быть переназначено центру Интернета вещей,который может только пройти обновление и вернуться в состояние соответствия требованиям. Когда устройство будет работать надлежащим образом, оно переносится в свой основной центр.
Все эти вопросы решает поддержка повторной подготовки в службе подготовки устройств. Устройства можно автоматически переназначить новому центру Интернета вещей на основе политики повторной подготовки, которая настроена в записи регистрации устройства.
Данные о состоянии устройства
Данные о состоянии устройства формируются из возможностей устройства и двойника устройства. Эти данные хранятся в экземпляре службы подготовки устройств и в центре Интернета вещей, которому назначено устройство.
При начальной подготовке устройства с помощью экземпляра службы подготовки устройств выполняются следующие действия:
Устройство отправляет запрос на подготовку в экземпляр службы подготовки устройств. Экземпляр службы проверяет подлинность удостоверения устройства на основе записи регистрации и создает начальную конфигурации данных о состоянии устройства. Экземпляр службы назначает устройство центру Интернета вещей на основе конфигурации регистрации и возвращает это назначение центра Интернета вещей устройству.
Экземпляр службы подготовки предоставляет копию данных о начальном состоянии устройства в назначенный центр Интернета вещей. Устройство подключается к назначенному центру Интернета вещей и начинает работать.
Со временем данные о состоянии устройства в центре Интернета могут обновляться с помощью операций на устройстве и операций в серверной части. Сведения о начальном состоянии устройства, хранящиеся в экземпляре службы подготовки устройств, не затрагиваются. Эти данные представляют начальную конфигурацию.
В зависимости от сценария при перемещении устройства между центрами Интернета вещей может также потребоваться перенести состояние устройства, обновленное в предыдущем центре Интернета вещей, в новый центр Интернета вещей. Эта миграция поддерживается политиками повторной подготовки в службе подготовки устройств.
Политики повторной подготовки
В зависимости от сценария устройство может отправить запрос экземпляру службы подготовки при перезагрузке. Она также поддерживает метод запуска подготовки вручную по требованию. Политика повторной подготовки в записи регистрации определяет способ обработки этих запросов экземпляром службы подготовки устройств. Политика также определяет, следует ли переносить данные о состоянии устройства во время повторной подготовки. К отдельным регистрациям и группам регистраций применяются одни и те же политики.
Повторное создание и перенос данных. Эта политика используется по умолчанию для новых записей регистрации. Эта политика начинает действовать, когда устройства, связанные с записью регистрации, отправляют новый запрос (1). В зависимости от конфигурации записи регистрации устройство может быть переназначено другому Центру Интернета вещей. При смене Центров Интернета вещей происходит удаление регистрации устройства в начальном Центре Интернета вещей. Обновленные сведения о состоянии устройства из этого начального центра Интернета вещей будут перенесены в новый центр Интернета вещей (2). Во время переноса устройство находится в состоянии Идет назначение.
Повторное создание и сброс на начальную конфигурацию. Эта политика принимает меры, когда устройства, связанные с записью регистрации, отправляют новый запрос на подготовку (1). В зависимости от конфигурации записи регистрации устройство может быть переназначено другому Центру Интернета вещей. При смене Центров Интернета вещей происходит удаление регистрации устройства в начальном Центре Интернета вещей. Данные начальной конфигурации, полученные экземпляром службы подготовки во время подготовки устройства, предоставляются в новый центр Интернета вещей (2). Во время переноса устройство находится в состоянии Идет назначение.
Эта политика часто используется для сброса параметров до заводских настроек без смены центров Интернета вещей.
Никогда не повторное создание: устройство никогда не переназначается другому концентратору. Эта политика предоставляется для управления обратной совместимостью.
Примечание.
DPS всегда будет вызывать пользовательский веб-перехватчик выделения независимо от политики повторной подготовки, если для устройства есть новый ReturnData . Если политика повторной подготовки не настроена для повторной подготовки, веб-перехватчик будет вызван, но устройство не изменит назначенный концентратор.
При проектировании решения и определении логики повторной подготовки следует учитывать несколько аспектов. Например:
- Как часто устройства будут перезапущены
- Квоты и ограничения DPS
- Ожидаемое время развертывания для вашего флота (поэтапное развертывание и все одновременно)
- Возможность повторных попыток, реализованная в клиентском коде, как описано в общем руководстве по повторным попыткам в Центре архитектуры Azure
Совет
Рекомендуется не подготавливать каждую перезагрузку устройства, так как это может вызвать некоторые проблемы при повторной подготовке нескольких тысяч или миллионов устройств одновременно. Вместо этого следует попытаться использовать API поиска состояния регистрации устройств и попытаться подключиться к этой информации для Центр Интернета вещей. Если это не удается, попробуйте повторно представить Центр Интернета вещей сведения, возможно, изменились. Помните, что запрос к состоянию регистрации будет считаться новой регистрацией устройства, поэтому следует учитывать ограничение регистрации устройства. Кроме того, рекомендуется реализовать соответствующую логику повторных попыток, например экспоненциальную обратную откат с помощью случайной обработки, как описано в общем руководстве по повторным попыткам. В некоторых случаях в зависимости от возможностей устройства можно сохранить сведения Центр Интернета вещей непосредственно на устройстве, чтобы подключиться непосредственно к Центр Интернета вещей после первой подготовки с помощью DPS. Если вы решили сделать это, убедитесь, что вы реализуете резервный механизм в случае возникновения определенных ошибок из Центра, например, рассмотрим следующие сценарии:
- Повторите операцию концентратора, если результирующий код равен 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 или более ранние версии |
Примечание.
Эти значения и ссылки могут меняться. Это лишь попытка выяснить, когда версии могут быть определены клиентом и какими будут ожидаемые версии.