Conceitos de reprovisionamento de dispositivos do Hub IoT
Durante o ciclo de vida de uma solução de IoT, é comum mover dispositivos entre hubs IoT. Os motivos para essa mudança podem incluir os seguintes cenários:
Geolocalização / GeoLatência: À medida que um dispositivo se move entre locais, a latência da rede é melhorada ao fazer com que o dispositivo migre 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 da 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 conectado a outros componentes back-end.
Quarentena: semelhante a uma mudança de solução. Um dispositivo com mau funcionamento, comprometido ou desatualizado pode ser reatribuído a um hub IoT que só pode ser atualizado e voltar a estar em conformidade. Quando o dispositivo estiver funcionando corretamente, ele será migrado de volta para seu hub principal.
O suporte ao reprovisionamento no Serviço de Provisionamento de Dispositivos atende a essas necessidades. Os dispositivos podem ser reatribuídos automaticamente a 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 gêmeo do dispositivo e pelos recursos do dispositivo. Esses dados são armazenados na instância do Serviço de Provisionamento de Dispositivo e no hub IoT ao qual um dispositivo está atribuído.
Quando um dispositivo é inicialmente provisionado com uma instância do Serviço de Provisionamento de Dispositivo, as seguintes etapas são executadas:
O dispositivo envia uma solicitação de provisionamento para uma instância do Serviço de Provisionamento de Dispositivo. 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 de registro e retorna essa atribuição de hub IoT ao dispositivo.
A instância do serviço de provisionamento fornece uma cópia de todos os dados de estado inicial do dispositivo para o hub IoT atribuído. O dispositivo se conecta ao hub IoT atribuído e inicia as operações.
Com o tempo, os dados de estado do dispositivo no hub IoT podem ser atualizados por 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 permanecem intocadas. Esses dados de estado do dispositivo intocados são a configuração inicial.
Dependendo do cenário, à medida 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 por políticas de reprovisionamento no Serviço de Provisionamento de Dispositivos.
Políticas de reaprovisionamento
Dependendo do cenário, um dispositivo pode enviar uma solicitação para uma instância de serviço de provisionamento na reinicialização. Ele também suporta um método para acionar manualmente o provisionamento sob demanda. A política de reprovisionamento em uma entrada de registro determina como a instância do serviço de provisionamento de dispositivo 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 inscrições individuais e grupos de inscrição:
Reprovisionar e migrar dados: esta política é o padrão para novas entradas de registro. Esta política entra em ação quando os dispositivos associados à entrada de inscrição 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 alterando hubs IoT, o registro do dispositivo com o hub IoT inicial será removido. As informações atualizadas de estado do dispositivo desse hub IoT inicial serão migradas para o novo hub IoT (2). Durante a migração, o status do dispositivo será relatado como Atribuição.
Reprovisionar e redefinir para a configuração inicial: esta política atua quando 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 alterando hubs IoT, o registro do dispositivo com o hub IoT inicial será removido. Os dados de configuração inicial que a instância do 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 Atribuição.
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. Esta política é fornecida para gerenciar a compatibilidade com versões anteriores.
Nota
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 considerar. Por exemplo:
- Com que frequência espera que os seus dispositivos sejam reiniciados
- As quotas e limites do DPS
- Tempo de implementação esperado para a sua frota (implementação faseada vs tudo de uma só vez)
- Capacidade de repetição implementada no código do cliente, conforme descrito na orientação geral Repetir no Centro de Arquitetura do Azure
Gorjeta
Recomendamos não provisionar em cada reinicialização do dispositivo, pois isso pode causar alguns problemas ao reprovisionar vários milhares ou milhões de dispositivos de uma só vez. Em vez disso, você deve tentar usar a API de Pesquisa de Status de Registro de Dispositivo e tentar se conectar com essas informações ao Hub IoT. Se isso falhar, tente reprovisionar, 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 registro do dispositivo. Considere também a implementação de uma lógica de repetição apropriada, como back-off exponencial com randomização, conforme descrito na orientação geral de Repetir. 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, certifique-se de implementar um mecanismo de fallback caso ocorram erros específicos do Hub, por exemplo, considere os seguintes cenários:
- Repita a operação Hub se o código de resultado for 429 (Muitas Solicitações) ou um erro no intervalo 5xx. Não realize repetições para outros erros.
- Para erros 429, tente novamente somente após o tempo indicado no cabeçalho Retry-After.
- Para erros 5xx, use back-off exponencial, com a primeira tentativa pelo menos 5 segundos após a resposta.
- Em caso de erros que não sejam 429 e 5xx, registre-se novamente através do DPS
- Idealmente, você também deve oferecer suporte a um método para acionar manualmente o provisionamento sob demanda.
Também recomendamos que se tenha em conta os limites de serviço ao planear atividades como enviar atualizações para a sua frota. Por exemplo, atualizar a frota de uma só vez pode fazer com que todos os dispositivos se registem novamente através do DPS (o que pode facilmente estar acima do limite da quota de registo) - Para esses cenários, considere planear atualizações de dispositivos por fases, em vez de atualizar toda a sua frota ao mesmo tempo.
Gerenciando a compatibilidade com versões anteriores
Antes de setembro de 2018, as atribuições de dispositivos para hubs IoT tinham um comportamento pegajoso. Quando um dispositivo voltava pelo processo de provisionamento, ele só era atribuído de volta ao mesmo hub IoT.
Para soluções que dependeram desse comportamento, o serviço de provisionamento inclui compatibilidade com versões anteriores. Este comportamento é atualmente mantido para dispositivos de acordo com os seguintes critérios:
Os dispositivos se conectam a uma versão da API antes da disponibilidade do suporte nativo ao reprovisionamento no Serviço de Provisionamento de Dispositivos. Consulte a tabela da 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 tenham o mesmo comportamento presente durante os testes iniciais. Para preservar o comportamento anterior, não salve uma política de reprovisionamento nesses 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 podem atualizar o comportamento do dispositivo sem precisar criar uma nova imagem do dispositivo.
O fluxograma a seguir ajuda a mostrar quando o comportamento está presente:
A tabela a seguir mostra as versões da API antes da disponibilidade do suporte ao reprovisionamento nativo no Serviço de Provisionamento de Dispositivos:
| API REST | C SDK | Python SDK | SDK Node | SDK Java | SDK do .NET |
|---|---|---|---|---|---|
| 2018-04-01 e anteriores | 1.2.8 e anteriores | 1.4.2 e anteriores | 1.7.3 ou anterior | 1.13.0 ou anterior | 1.1.0 ou anterior |
Nota
É provável que estes valores e ligações mudem. Esta é apenas uma tentativa de espaço reservado para determinar onde as versões podem ser determinadas por um cliente e quais serão as versões esperadas.