Compartilhar via

Confiabilidade no Azure IoT Hub

Azure IoT Hub é um serviço gerenciado hospedado na nuvem que atua como um hub de mensagens central para comunicação entre um aplicativo IoT e seus dispositivos anexados.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar os IoT Hub resilientes a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) IoT Hub.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas Azure quando se comunicam com apis, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

IoT Hub fornece uma garantia de tempo de atividade razoavelmente alta, mas falhas transitórias podem ocorrer em qualquer plataforma de computação distribuída. Para lidar com falhas transitórias, crie os padrões de repetição apropriados em componentes que interagem com aplicativos de nuvem.

Resiliência a falhas de zona de disponibilidade

as zonas Availability são grupos fisicamente separados de datacenters em uma região Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

IoT Hub dá suporte a dois tipos distintos de suporte à zona de disponibilidade:

  • Redundância de zona para dados, que replica automaticamente os dados entre várias zonas de disponibilidade para os componentes de armazenamento subjacentes que armazenam o registro de identidade do dispositivo e as mensagens do dispositivo para a nuvem.

  • Redundância de zona para computação, que fornece resiliência nos componentes responsáveis por gerenciar os dispositivos e rotear mensagens.

Requirements

Suporte à região: O tipo de suporte de zona de disponibilidade para o hub IoT depende da região em que ele está implantado.

Região Redundância de zona para dados Redundância de zona para computação
Leste da Austrália Yes Yes
Sul do Brasil Yes Yes
Canadá Central Yes Yes
Índia Central Não Yes
EUA Central Yes Yes
Leste dos EUA Não Yes
França Central Yes Yes
Centro-oeste da Alemanha Yes Yes
Leste do Japão Yes Yes
Coreia Central Não Yes
Europa Setentrional Yes Yes
Leste da Noruega Não Yes
Catar Central Não Yes
Centro-Sul dos EUA Não Yes
Sudeste Asiático Yes Yes
Sul do Reino Unido Yes Yes
Oeste da Europa Não Yes
Oeste dos EUA 2 Yes Yes
Oeste dos EUA 3 Não Yes

Os hubs IoT criados em regiões que não estão nessa lista não são resilientes a interrupções de zona.

Custo

Não há custo adicional com a redundância de zona no IoT Hub.

Configurar o suporte à zona de disponibilidade

Recursos do IoT Hub suportam automaticamente a redundância de zona quando implantados em regiões suportadas. Nenhuma configuração adicional é necessária.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando os recursos do IoT Hub estão configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.

  • Replicação de dados entre zonas: Quando o hub IoT é implantado em uma região que dá suporte à redundância de zona para dados, as alterações nos dados são replicadas automaticamente entre zonas de disponibilidade. A replicação ocorre de forma síncrona.

  • Roteamento de tráfego entre zonas: Quando o hub IoT é implantado em uma região que dá suporte à redundância de zona para componentes de computação, as solicitações são roteadas para uma instância primária do serviço em uma das zonas de disponibilidade. Azure seleciona automaticamente a instância ativa e a zona.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando os recursos do IoT Hub são configurados para zona de redundância em caso de uma interrupção da zona de disponibilidade.

  • Detecção e resposta: O serviço IoT Hub é responsável por detectar falhas em zonas de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Azure Service Health para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Durante uma falha de zona, as solicitações ativas podem ser descartadas. Seus clientes e dispositivos devem ter lógica de repetição suficiente implementada para lidar com falhas transitórias.

  • Perda de dados esperada: Quando o hub IoT é implantado em uma região que dá suporte à redundância de zona para dados, uma falha de zona não deve causar nenhuma perda de dados.

  • Expected downtime: Quando o IoT hub é implantado em uma região que dá suporte à redundância de zona para componentes de computação e de dados, uma falha de zona não deve causar tempo de inatividade para seus recursos de IoT Hub.

  • Roteamento de tráfego: Quando o hub IoT é implantado em uma região que suporta redundância de zona para componentes de computação, o hub IoT detecta a perda da zona. Em seguida, todas as novas solicitações são redirecionadas automaticamente para uma nova instância primária do serviço em uma das zonas de disponibilidade íntegras.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, IoT Hub restaura automaticamente as instâncias na zona de disponibilidade e redireciona o tráfego entre suas instâncias normalmente.

Testar falhas em zonas

Como o IoT Hub gerencia totalmente o roteamento de tráfego, o failover e o failback em caso de falhas de zona, você não precisa validar os processos de falhas em zonas de disponibilidade nem fornecer qualquer informação adicional.

Resiliência a falhas em toda a região

IoT Hub é um serviço de região única. Se a região ficar indisponível, seus recursos de IoT Hub também ficarão indisponíveis.

No entanto, se os recursos estiverem em uma região emparelhada, os dados do hub IoT serão replicados para a região emparelhada.

O hub IoT pode fazer failover para a região emparelhada nos seguintes cenários:

  • Failover iniciado pelo cliente: Você pode iniciar o failover manual para a região emparelhada você mesmo, quer a região esteja passando por tempo de inatividade ou não. Você pode usar essa abordagem para executar failovers e drills planejados.

  • Failover iniciado pela Microsoft: Se uma região for perdida, a Microsoft poderá iniciar um failover de hubs IoT para a região emparelhada. No entanto, é improvável que a Microsoft inicie o failover, a não ser após um atraso significativo e fazendo o melhor possível. O failover de recursos do IoT Hub pode ocorrer em um momento diferente do que o failover de outros serviços do Azure. Esse processo é uma opção padrão e não requer nenhuma intervenção de você.

Se os recursos estiverem em uma região não emparelhada, a Microsoft não replicará a configuração e os dados entre regiões e não haverá failover interno entre regiões. No entanto, você pode implantar recursos separados em várias regiões. Nesse cenário, é sua responsabilidade gerenciar a replicação, a distribuição de tráfego e o failover.

Se o seu hub IoT estiver em uma região não pareada ou se o comportamento padrão de replicação e failover não corresponder às suas necessidades, você poderá usar soluções personalizadas de várias regiões para resiliência para planejar e iniciar failovers.

Requirements

  • Suporte à região: A replicação e o failover padrão só têm suporte em regiões emparelhadas.
  • As opções de replicação e failover de regiões emparelhadas estão disponíveis para todas as camadas de IoT Hub.

Considerações

Não use o failover iniciado pelo cliente para migrar permanentemente o hub entre as regiões emparelhadas do Azure. Em geral, os dispositivos estão localizados perto da região primária do hub. Se você mover o hub para a região secundária, a latência aumentará para operações entre os dispositivos e o hub IoT no local secundário.

Custo

Para hubs em regiões emparelhadas, não há custo adicional para replicação ou failover de dados entre regiões.

Se o hub IoT estiver em uma região não emparelhada, consulte soluções multirregionais personalizadas para resiliência para obter informações de custo possíveis.

Configurar a replicação e preparar-se para failover

Por padrão, a replicação de dados entre regiões é configurada automaticamente quando você cria um hub IoT em uma região emparelhada. Esse processo é uma opção padrão e não requer nenhuma intervenção de você. Em regiões com exceção do Sul do Brasil e sudeste da Ásia (Cingapura), os dados do cliente não são armazenados ou processados fora da geografia em que você implanta a instância de serviço.

Se o hub IoT estiver nas regiões Sul do Brasil ou Sudeste Da Ásia (Cingapura), você poderá desabilitar a replicação de dados e recusar o failover. Para obter mais informações, consulte Desabilitar recuperação de desastre (DR).

Se o hub IoT estiver em uma região não controlada, você precisará planejar sua própria abordagem de replicação e failover entre regiões. Para obter mais informações, consulte soluções personalizadas de várias regiões para resiliência.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando um hub IoT é configurado para replicação e failover entre regiões e a região primária está operacional.

  • Replicação de dados entre regiões: Os dados são replicados automaticamente para a região emparelhada. A replicação ocorre de forma assíncrona, o que significa que alguma perda de dados é esperada se ocorrer um failover. Não há nenhuma replicação de dados entre regiões para hubs IoT em regiões não internas.

  • Roteamento de tráfego entre regiões: Em operações normais, o tráfego flui apenas para a região primária.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando um hub IoT é configurado para replicação e failover entre regiões e há uma interrupção na região primária.

  • Detecção e resposta: A responsabilidade de detectar e responder a uma interrupção na região primária pode variar.

    • Failover iniciado pelo cliente: Você é responsável por detectar uma perda de região e decidir quando fazer failover. Para obter mais informações sobre como executar o failover iniciado pelo cliente entre regiões emparelhadas, consulte Executar failover manual para um hub IoT.

      Há limites sobre a frequência com que você pode executar failover ou failback iniciado pelo cliente:

      • Os usuários têm permissão para executar duas operações de failover bem-sucedidas e duas operações de failback bem-sucedidas por dia.

      • Não são permitidas operações consecutivas de failover ou failback. Você deve esperar uma hora entre essas operações.

    • Failover iniciado pela Microsoft: A Microsoft pode decidir executar um failover se a região primária for perdida. Esse processo pode levar várias horas após a perda da região primária ou até mais tempo em alguns cenários. O failover dos recursos do IoT Hub pode não ocorrer ao mesmo tempo que outros serviços do Azure.

  • Solicitações ativas: As solicitações que a região primária está processando durante um failover provavelmente serão perdidas. Os clientes devem repetir as solicitações após a conclusão do failover.

  • Perda de dados esperada: Para regiões emparelhadas, os dados são replicados de forma assíncrona para a região emparelhada. Como resultado, algumas perdas de dados são esperadas após o failover. Esse processo se aplica a failovers gerenciados pela Microsoft e gerenciados pelo cliente. A tabela a seguir descreve o RPO (objetivo de ponto de recuperação) ou a perda de dados esperada de cada tipo de dados armazenados pelos hubs IoT.

    Tipo de dados RPO
    Registro de identidade Perda de dados de 0 a 5 minutos
    Dados do dispositivo gêmeo Perda de dados de 0 a 5 minutos
    Mensagens de nuvem para dispositivo 1 Perda de dados de 0 a 5 minutos
    Trabalhos pai 1 e dispositivo Perda de dados de 0 a 5 minutos
    Mensagens do dispositivo para a nuvem Todas as mensagens não lidas são perdidas
    Mensagens de feedback da nuvem para o dispositivo Todas as mensagens não lidas são perdidas

    1 Mensagens de nuvem para dispositivo e trabalhos pai não são recuperados como parte de um failover iniciado pelo cliente.

  • Tempo de inatividade esperado: O tempo de inatividade esperado durante o failover da região depende do tipo de failover.

    • Failover iniciado pelo cliente: Espere aproximadamente 10 minutos a 2 horas de tempo de inatividade desde quando a região é perdida até quando o recurso está operacional na região emparelhada. O número de dispositivos registrados na instância do hub IoT que está sendo reprovada afeta o tempo de recuperação. Você pode esperar que o tempo de recuperação de um hub que hospeda aproximadamente 100.000 dispositivos seja de cerca de 15 minutos.

    • Failover iniciado pela Microsoft: Espere aproximadamente 2 a 26 horas de tempo de inatividade desde a perda da região até a disponibilização do recurso na região emparelhada.

      A alta quantidade de tempo de recuperação ocorre porque a Microsoft deve executar a operação de failover em nome de todos os clientes afetados nessa região. Para sistemas críticos, você deve usar o failover iniciado pelo cliente para obter menos tempo de inatividade. No entanto, se você executar uma solução de IoT menos crítica que possa sustentar um tempo de inatividade de aproximadamente um dia, talvez seja possível usar uma dependência da opção iniciada pela Microsoft para atender às metas gerais de dr para sua solução de IoT.

    • Para ambos os tipos de failover, o nome de domínio totalmente qualificado da instância do hub IoT permanece o mesmo após o failover, o que significa que o connection string também permanece o mesmo. No entanto, como o endereço IP subjacente é alterado, os clientes devem aguardar que os registros DNS (Sistema de Nomes de Domínio) sejam atualizados antes de acessar o hub IoT após o failover.

      Importante

      Os SDKs de IoT Hub não armazenam em cache o endereço IP do IoT hub. O código do usuário que interage com os SDKs também não deve armazenar em cache o endereço IP do hub IoT.

      Devido a esses fatores, o tempo para que as operações de runtime que estão sendo executadas em sua instância do hub IoT se tornem totalmente operacionais depois que o processo de failover pode ser expresso usando a seguinte função:

      Tempo de recuperação = RTO [10 minutos a 2 horas para failover iniciado pelo cliente ou de 2 a 26 horas para failover iniciado pela Microsoft] + atraso de propagação de DNS + Tempo que o aplicativo cliente leva para atualizar qualquer endereço IP do hub IoT armazenado em cache

  • Traffic rerouting: Durante o processo de failover, o IoT Hub atualiza os registros de DNS para direcionar a região emparelhada. Todas as solicitações subsequentes são enviadas para a região associada.

    Após a conclusão da operação de failover do hub IoT, espera-se que todas as operações do dispositivo e dos aplicativos de back-end continuem funcionando sem a necessidade de intervenção manual. Essa continuidade garante que as mensagens do dispositivo para a nuvem continuem funcionando e que todo o registro de dispositivo esteja intacto. Se você emitir eventos por meio de Azure Event Grid, eles poderão ser consumidos por meio das mesmas assinaturas configuradas anteriormente, desde que essas assinaturas da Grade de Eventos continuem disponíveis. Nenhum tratamento adicional é necessário para endpoints personalizados.

Configuração pós-failover necessária

Dependendo de onde você roteia as mensagens do hub IoT, talvez seja necessário executar etapas extras após a conclusão do failover.

  • Azure Event Hubs: O nome e o ponto de extremidade compatíveis com os Hubs de Eventos do ponto de extremidade interno de eventos do hub IoT são alterados após o failover. Essa alteração ocorre porque o cliente dos Hubs de Eventos não tem visibilidade dos eventos de IoT Hub.

    Quando você recebe mensagens de telemetria do ponto de extremidade interno usando o cliente dos Hubs de Eventos ou o host do processador de eventos, utilize a cadeia de conexão do Hub IoT para estabelecer a conexão. Essa abordagem garante que seus aplicativos de back-end continuem funcionando sem a necessidade de intervenção manual após o failover.

    Se você usar diretamente o nome e o ponto de extremidade compatíveis com Os Hubs de Eventos em seu aplicativo, será necessário buscar o novo ponto de extremidade compatível com Hubs de Eventos após o failover para continuar as operações. Para recuperar o endpoint e o nome, você pode usar o portal do Azure ou o SDK do .NET.

    • O portal do Azure: Para obter mais informações sobre como usar o portal para recuperar o ponto de extremidade compatível com Hubs de Eventos e o nome compatível com Hubs de Eventos, consulte Conectar ao ponto de extremidade interno.

    • O .NET SDK: Para usar a cadeia de conexão do hub IoT para recuperar o ponto de extremidade compatível com o Event Hubs, use o código de exemplo. Este exemplo de código usa a cadeia de conexão para obter o novo endpoint do Event Hubs e reconectar. Você deve ter Visual Studio instalado.

  • Azure Functions e Azure Stream Analytics: Se você usar o Azure Functions ou o Stream Analytics para se conectar ao ponto de extremidade de eventos interno, deverá atualizar o ponto de extremidade do Event Hubs ao qual a função ou o trabalho se conecta, seguindo o mesmo processo descrito no ponto de marcador anterior. Em seguida, execute uma ação de reinicialização porque os deslocamentos de fluxo de eventos se tornam inválidos após o failover.

  • Azure Storage: Ao rotear para Azure Storage, liste os blobs ou arquivos primeiro. Em seguida, itera sobre eles para garantir que todos os blobs ou arquivos sejam lidos sem assumir o particionamento. O intervalo de partição pode potencialmente ser alterado durante um failover iniciado pela Microsoft ou pelo cliente. Você pode usar a API List Blobs para enumerar a lista de blobs ou a API List Azure Data Lake Storage para listar arquivos. Para obter mais informações, consulte Azure Storage como um ponto de extremidade de roteamento.

Recuperação de região

Para fazer failback para a região primária, você pode disparar manualmente a ação de failover uma segunda vez. É importante lembrar as restrições sobre a frequência com que você pode fazer failover.

Se a operação de failover original foi executada para se recuperar de uma interrupção estendida na região primária original, execute o failback para a região primária após a região primária se recuperar da interrupção.

Teste de falhas na região

Para simular um problema durante uma falha regional, você pode acionar um failover manual da central IoT. No entanto, como o failover regional causa tempo de inatividade e perda de dados, você só deve executar failovers de teste em ambientes não-produtivos. Para obter mais informações, consulte Comportamento durante uma falha na região. Considere configurar uma instância de teste do IoT Hub para iniciar a alternativa de failover planejada periodicamente. Testes periódicos podem ajudá-lo a aumentar a confiança em sua capacidade de restaurar e operar suas soluções de ponta a ponta efetivamente quando ocorre um desastre real.

Soluções personalizadas de várias regiões para resiliência

Os recursos de failover entre regiões de IoT Hub não são adequados para os seguintes cenários:

  • Seu hub IoT está em uma região não interna.

  • Suas metas de continuidade operacional não são atendidas pelo tempo de recuperação ou perda de dados que a opção de failover interna proporciona.

  • Você precisa fazer failover para uma região que não seja o par da região primária.

Você pode criar uma solução de failover entre regiões personalizada para cada dispositivo individual. Um tratamento completo das topologias de implantação em soluções de IoT está fora do escopo deste artigo, mas você pode considerar um modelo de implantação de várias regiões. Nesse modelo, o hub IoT primário e o back-end da solução são executados principalmente em uma região Azure. Um hub IoT secundário e um back-end são implantados em outra região Azure. Se o hub IoT na região primária sofrer uma interrupção ou a conectividade de rede do dispositivo para a região primária for interrompida, os dispositivos usarão um ponto de extremidade de serviço secundário.

  • Tempo de inatividade esperado: Essa abordagem tem menos de um minuto de tempo de inatividade, mas pode ser complexa de implementar.

  • Perda de dados esperada: A quantidade de perda de dados depende dos armazenamentos de dados específicos que você usa e da maneira como você configura a replicação geográfica entre eles.

  • Custar: Essa abordagem exige que você provisione pelo menos um hub IoT extra, o que aumenta seu custo geral.

Em um alto nível, para implementar um modelo de failover regional com IoT Hub, você precisa tomar as seguintes medidas:

  • Uma lógica de roteamento de dispositivo e hub IoT secundário: Se o serviço em sua região primária for interrompido, os dispositivos deverão começar a se conectar à sua região secundária. Devido à natureza com reconhecimento de estado da maioria dos serviços envolvidos, os administradores de solução geralmente disparam manualmente o processo de failover inter-regional. A melhor maneira de comunicar o novo ponto de extremidade aos dispositivos, mantendo o controle sobre o processo é fazer com que eles verifiquem regularmente um serviço de concierge para o ponto de extremidade ativo atual. O serviço de concierge pode ser um aplicativo Web replicado e mantido acessível usando técnicas de redirecionamento de DNS, como Azure Traffic Manager.

    Observação

    O Gerenciador de Tráfego não tem suporte interno para IoT Hub. Você pode configurar endpoints personalizados do Traffic Manager para cada hub IoT. Configure a investigação de integridade do ponto de extremidade do Gerenciador de Tráfego para usar o ponto de extremidade do Hub IoT.

  • Replicação do registro de identidade: Para ser utilizável, o hub IoT secundário deve conter todas as identidades de dispositivo que podem se conectar à solução. A solução deve manter backups replicados geograficamente de identidades de dispositivo e carregá-los no hub IoT secundário antes de alternar o ponto de extremidade ativo para os dispositivos. A funcionalidade de exportação de identidade do dispositivo de IoT Hub é útil nesse contexto. Para obter mais informações, consulte Entender o registro de identidade no Hub IoT.

  • Lógica de mesclagem: Quando a região primária estiver disponível novamente, todo o estado e os dados criados na região secundária deverão ser migrados de volta para a região primária. Esse estado e os dados estão relacionados principalmente às identidades de dispositivo e aos metadados do aplicativo, que deverão ser mesclados ao Hub IoT primário e com todos os outros armazenamentos específicos do aplicativo na região primária.

    Para simplificar essa etapa, use operações idempotentes . Operações Idempotentes minimizam os efeitos colaterais da distribuição consistente eventual de eventos e da entrega de eventos duplicados ou fora de ordem. Além disso, a lógica do aplicativo deve ser projetada para tolerar possíveis inconsistências ou estado ligeiramente desatualizado. Esse cenário pode ocorrer devido ao tempo extra necessário para o sistema se curar com base em RPOs.

Backup e restauração

O serviço IoT Hub permite operações de exportação em massa, que permitem exportar todo o registro de identidade de um IoT hub. Esses dados são transferidos para um contêiner de blob Azure Storage usando uma assinatura de acesso compartilhado. Esse método permite criar backups confiáveis das informações do dispositivo em um contêiner de blobs controlado por você. Para obter mais informações, consulte Importar e exportar identidades de dispositivo IoT Hub em lote.

Você também pode exportar o modelo do ARM (Azure Resource Manager) de um hub IoT existente para criar um backup da configuração do Hub IoT. Para obter mais informações, consulte Migrar manualmente um hub IoT usando um modelo do ARM.

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Conteúdo relacionado

  • Last updated on