Confiabilidade no Hub IoT do Azure

O Hub IoT do Azure é 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 o Hub IoT resiliente 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) do Hub IoT.

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 do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

O Hub IoT 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 de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Hub IoT 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.

Suporte de regiões

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
Sul do Brasil
Canadá Central
Índia Central
EUA Central
Leste dos EUA
França Central
Centro-oeste da Alemanha
Leste do Japão
Coreia Central
Europa Setentrional
Leste da Noruega
Catar Central
Centro-Sul dos EUA
Sudeste Asiático
Sul do Reino Unido
Oeste da Europa
Oeste dos EUA 2
Oeste dos EUA 3

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 para redundância de zona com o Hub IoT.

Configurar o suporte à zona de disponibilidade

Os recursos do Hub IoT dão suporte automaticamente à redundância de zona quando implantados em regiões com suporte. 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 Hub IoT sã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. O 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 Hub IoT são configurados para redundância de zona e há uma interrupção da zona de disponibilidade.

• Detecção e resposta: O serviço do Hub IoT é responsável por detectar uma falha em uma zona 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 o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de 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.

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

• Redirecionamento de tráfego: Quando o hub IoT é implantado em uma região que dá suporte à 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 se recupera, o Hub IoT 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 Hub IoT gerencia totalmente o roteamento de tráfego, o failover e o failback para falhas de zona, você não precisa validar os processos de falha da zona de disponibilidade ou fornecer qualquer entrada adicional.

Resiliência a falhas em toda a região

O Hub IoT é um serviço de região única. Se a região ficar indisponível, os recursos do Hub IoT 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 Hub IoT pode ocorrer em um momento diferente do 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.

Suporte de regiões

A replicação e o failover padrão só têm suporte em regiões emparelhadas.

Requisitos

As opções de replicação e failover de região emparelhadas estão disponíveis para todas as camadas do Hub IoT.

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 de recursos do Hub IoT 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

  ¹ 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 a cadeia de conexão também permanece a mesma. 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 do Hub IoT não armazenam em cache o endereço IP do hub IoT. 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

• Redirecionamento de tráfego: Durante o processo de failover, o Hub IoT atualiza os registros DNS para apontar para 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 da Grade de Eventos do Azure, 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ível com os Hubs de Eventos do ponto de extremidade de eventos internos 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 do Hub IoT.

  Ao receber mensagens de telemetria do ponto de extremidade interno usando o cliente dos Hubs de Eventos ou o host do processador de eventos, use 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 obter 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-se ao ponto de extremidade interno.

  • O SDK do .NET: para usar a cadeia de conexão do hub IoT para recapturar o ponto de extremidade compatível com Hubs de Eventos, use o código de exemplo. Este exemplo de código usa a cadeia de conexão para obter o novo ponto de extremidade dos Hubs de Eventos e restabelecer a conexão. Você deve ter o 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 dos Hubs de Eventos 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.

• Armazenamento do Azure: Ao rotear para o Armazenamento do Azure, 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 listar blobs ou a API List Azure Data Lake Storage para listar arquivos. Para obter mais informações, consulte Armazenamento do Azure 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 do Hub IoT de teste para iniciar a opção 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 do Hub IoT 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 do Azure. Um hub IoT secundário e um back-end são implantados em outra região do 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 o Hub IoT, 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 o Gerenciador de Tráfego do Azure.

  Observação

  O Gerenciador de Tráfego não tem suporte interno para o Hub IoT. 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 do Hub IoT é útil neste 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 do Hub IoT permite operações de exportação em massa, que permitem exportar todo o registro de identidade de um hub IoT. Esses dados são transferidos para um contêiner de blob do Armazenamento do Azure 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 dispositivos do IoT Hub em grande escala.

Você também pode exportar um modelo do Azure Resource Manager (modelo ARM) 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 acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Conteúdo relacionado

• Confiabilidade no Azure
• Escalabilidade da solução de IoT, alta disponibilidade e DR