Conceitos de reprovisionamento de dispositivos no Hub IoT
Durante o ciclo de vida de uma solução IoT, é comum mover dispositivos entre os Hubs IoT. Os motivos para essa mudança podem incluir os seguintes cenários:
Localização geográfica / GeoLatency: uma vez que um dispositivo se move entre locais, a latência de rede é aprimorada fazendo com que o dispositivo seja migrado para um Hub IoT mais próximo.
Multilocação: um dispositivo pode ser usado dentro da mesma solução de IoT e reatribuído a um novo cliente ou site do cliente. Esse novo cliente pode ser atendido usando um Hub IoT diferente.
Alteração de solução: um dispositivo pode ser movido para uma solução de IoT nova ou atualizada. Essa reatribuição pode exigir que o dispositivo se comunique com um novo Hub IoT que está conectado a outros componentes de back-end.
Quarentena: semelhante a uma alteração de solução. Um dispositivo que está com defeito, comprometido ou desatualizado pode ser reatribuído a um Hub IoT em que tudo o que ele pode fazer é atualizar e voltar em conformidade. Depois que o dispositivo estiver funcionando corretamente, ele é migrado de volta a seu hub principal.
O reprovisionamento oferece suporte dentro dos endereços de Serviço de Provisionamento de Dispositivo a essas necessidades. Os dispositivos podem ser reatribuídos automaticamente para novos hubs IoT com base na política de reprovisionamento configurada na entrada de registro do dispositivo.
Dados de estado do dispositivo
Os dados de estado do dispositivo são compostos pelo dispositivo gêmeo e recursos do dispositivo. Esses dados são armazenados na instância do Serviço de Provisionamento de Dispositivos e Hub IoT atribuídos a um dispositivo.
Quando um dispositivo for inicialmente provisionado com uma instância do Serviço de Provisionamento de Dispositivos, as etapas a seguir são executadas:
O dispositivo envia uma solicitação de provisionamento para a instância do Serviço de Provisionamento de Dispositivos. A instância de serviço autentica a identidade do dispositivo com base em uma entrada de registro e cria a configuração inicial dos dados de estado do dispositivo. A instância de serviço atribui o dispositivo a um hub IoT com base na configuração do registro e retorna essa atribuição de hub IoT para o dispositivo.
A instância do serviço de provisionamento dá uma cópia de quaisquer dados de estado inicial do dispositivo ao hub IoT atribuído. O dispositivo se conecta ao hub IoT atribuído e inicia as operações.
Ao longo do tempo, os dados de estado do dispositivo no hub IoT podem ser atualizados pelas operações de dispositivo e operações de back-end. As informações de estado inicial do dispositivo armazenadas na instância do Serviço de Provisionamento de Dispositivo ficam inalteradas. Esses dados de estado do dispositivo inalterados são a configuração inicial.
Dependendo do cenário, uma vez que um dispositivo se move entre hubs IoT, também pode ser necessário migrar o estado do dispositivo atualizado no hub IoT anterior para o novo hub IoT. Essa migração é suportada pelas políticas de reprovisionamento no Serviço de Provisionamento de Dispositivos.
Políticas de reprovisionamento
Dependendo do cenário, um dispositivo pode enviar uma solicitação a uma instância de serviço de provisionamento na reinicialização. Ele também dá suporte a um método para disparar manualmente o provisionamento sob demanda. A política de reprovisionamento em uma entrada de registro determina como a instância de serviço de provisionamento de dispositivos lida com essas solicitações de provisionamento. A política também determina se os dados de estado do dispositivo devem ser migrados durante o reprovisionamento. As mesmas políticas estão disponíveis para os registros individuais e grupos de registro:
Reprovisionar e migrar dados: essa política é o padrão para novas entradas de registro. Essa política entra em ação quando os dispositivos associados com a entrada de registro enviam uma nova solicitação (1). Dependendo da configuração de entrada de registro, o dispositivo pode ser reatribuído a outro hub IoT. Se o dispositivo estiver mudando entre hubs IoT, o registro de dispositivo com o hub IoT inicial será removido. As informações atualizadas de estado do dispositivo do hub IoT inicial serão migradas para o novo hub IoT (2). Durante a migração, o status do dispositivo será relatado como Atribuindo.
Reprovisionar e redefinir para a configuração inicial: essa política executa uma ação quando os dispositivos associados à entrada de registro enviam uma nova solicitação de provisionamento (1). Dependendo da configuração de entrada de registro, o dispositivo pode ser reatribuído a outro hub IoT. Se o dispositivo estiver mudando entre hubs IoT, o registro de dispositivo com o hub IoT inicial será removido. Os dados de configuração inicial que a instância de serviço de provisionamento recebeu quando o dispositivo foi provisionado são fornecidos ao novo hub IoT (2). Durante a migração, o status do dispositivo será relatado como Atribuindo.
Essa política é geralmente usada para uma redefinição de fábrica sem alterar os hubs IoT.
Nunca reprovisionar: o dispositivo nunca é reatribuído a um hub diferente. Essa política é fornecida para gerenciar compatibilidade com versões anteriores.
Observação
O DPS sempre chamará o webhook de alocação personalizado, independentemente da política de reprovisionamento, caso haja novos ReturnData para o dispositivo. Se a política de reprovisionamento estiver definida para nunca reprovisionar, o webhook será chamado, mas o dispositivo não alterará seu hub atribuído.
Ao projetar sua solução e definir uma lógica de reprovisionamento, há algumas coisas a serem consideradas. Por exemplo:
- Com que frequência você espera que seus dispositivos sejam reiniciados
- Cotas e limites do DPS
- Tempo de implantação esperado para sua frota (lançamento em fases ou de uma só vez)
- Recurso de repetição implementado no código do cliente, conforme descrito em Diretrizes gerais de repetição no Centro de Arquitetura do Azure
Dica
Não recomendamos o provisionamento a cada reinicialização do dispositivo, pois isso pode causar alguns problemas ao reprovisionar diversos milhares ou milhões de dispositivos de uma só vez. Em vez disso, tente usar a API de Pesquisa do status de registro do dispositivo e se conectar ao Hub IoT com essas informações. Se isso falhar, tente repetir o provisionamento, pois as informações do Hub IoT podem ter sido alteradas. Lembre-se de que consultar o estado de registro contará como um novo registro de dispositivo, portanto, você deve considerar o limite de registros de dispositivo. Considere também implementar uma lógica de repetição apropriada, como recuo exponencial com randomização, conforme descrito em Diretrizes gerais de repetição. Em alguns casos, dependendo dos recursos do dispositivo, é possível salvar as informações do Hub IoT diretamente no dispositivo para se conectar diretamente ao Hub IoT após o primeiro provisionamento usando o DPS. Se você optar por fazer isso, implemente um mecanismo de fallback para casos de erros específicos do Hub como, por exemplo, os seguintes cenários:
- Repita a operação do Hub se o código de resultado for 429 (Muitas solicitações) ou um erro no intervalo 5xx. Não repita para nenhum outro erro.
- Para erros 429, somente repita após o tempo indicado no cabeçalho Retry-After.
- Para erros 5xx, use uma nova retirada exponencial, com a repetição pelo menos cinco segundos após a resposta.
- Em erros diferentes de 429 e 5xx, registre-se novamente por meio do DPS
- Idealmente, você também deve dar suporte a um método para disparar manualmente o provisionamento sob demanda.
Também recomendamos levar em consideração os limites de serviço ao planejar atividades como o envio de atualizações para a frota. Por exemplo, atualizar a frota de uma só vez pode fazer com que todos os dispositivos se registrem novamente por meio do DPS (o que pode facilmente estar acima do limite de cota de registro). Para esses cenários, considere planejar as atualizações do dispositivo em fases, em vez de atualizar toda a frota ao mesmo tempo.
Gerenciar compatibilidade com versões anteriores
Antes de setembro de 2018, as atribuições de dispositivo para os hubs IoT tinham um comportamento adesivo. Quando um dispositivo passava novamente pelo processo de provisionamento, ele só seria atribuído de volta ao mesmo hub IoT.
Para soluções que obtiveram uma dependência nesse comportamento, o serviço de provisionamento inclui compatibilidade com versões anteriores. Atualmente, esse comportamento é mantido para dispositivos de acordo com os seguintes critérios:
Os dispositivos se conectam com uma versão de API antes da disponibilidade de suporte nativo de reprovisionamento no Serviço de Provisionamento de Dispositivos. Consulte a tabela de API abaixo.
A entrada de registro para os dispositivos não tem uma política de reprovisionamento definida neles.
Essa compatibilidade garante que os dispositivos implantados anteriormente, experimentem o mesmo comportamento que estava presente durante o teste inicial. Para preservar o comportamento anterior, não salve uma política de reprovisionamento para esses registros. Se uma política de reprovisionamento for definida, a política de reprovisionamento terá precedência sobre o comportamento. Ao permitir que a política de reprovisionamento tenha precedência, os clientes poderão atualizar o comportamento do dispositivo sem precisar refazer a imagem de dispositivo.
O fluxograma a seguir ajuda a mostrar quando o comportamento está presente:
A tabela a seguir mostra as versões de API antes da disponibilidade de suporte nativo de reprovisionamento no Serviço de Provisionamento de Dispositivos:
| API REST | SDK C | SDK do Python | SDK do Node | Java SDK | SDK .NET |
|---|---|---|---|---|---|
| 2018-04-01 e anterior | 1.2.8 e anterior | 1.4.2 e anterior | 1.7.3 ou anterior | 1.13.0 ou anterior | 1.1.0 ou anterior |
Observação
Esses valores e links provavelmente mudarão. Isso é apenas uma tentativa de marcação para determinar onde as versões podem ser determinadas por um cliente e quais serão as versões esperadas.