Partilhar via

Confiabilidade no Hub IoT do Azure

O Azure IoT Hub é um serviço gerido alojado na cloud que atua como um centro central de mensagens para a comunicação entre uma aplicação IoT e os seus dispositivos ligados.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 IoT Hub resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas e destaca algumas informações-chave sobre o acordo de nível de serviço (SLA) do IoT Hub.

Resiliência a falhas transitórias

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

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o 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 em nuvem.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Hub IoT suporta 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 mensagens do dispositivo para a nuvem.

  • Redundância de zona para computação, que fornece resiliência nos componentes responsáveis pelo gerenciamento dos dispositivos e roteamento de mensagens.

Suporte de região

O tipo de suporte de zona de disponibilidade para seu hub IoT depende da região em que ele é implantado.

Região Redundância de zona para dados Redundância de zona para computação
Leste da Austrália Sim Sim
Sul do Brasil Sim Sim
Canadá Central Sim Sim
Índia Central Não Sim
E.U.A. Central Sim Sim
E.U.A. Leste Não Sim
Centro de França Sim Sim
Alemanha Centro-Oeste Sim Sim
Leste do Japão Sim Sim
Coreia Central Não Sim
Europa do Norte Sim Sim
Leste da Noruega Não Sim
Catar Central Não Sim
E.U.A. Centro-Sul Não Sim
Sudeste Asiático Sim Sim
Sul do Reino Unido Sim Sim
Europa Ocidental Não Sim
E.U.A. Oeste 2 Sim Sim
E.U.A. Oeste 3 Não Sim

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

Configurar o suporte à zona de disponibilidade

Os recursos do Hub IoT suportam automaticamente redundância de zona quando implantados em regiões suportadas. Não é necessário efetuar mais configurações.

Comportamento quando todas as zonas estão íntegras

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 oferece 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 oferece 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 a instância ativa e a zona automaticamente.

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.

  • Deteção e resposta: O serviço Hub IoT é responsável por detetar uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.

  • 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 seu hub IoT é implantado em uma região que oferece 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 oferece 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.

  • Reencaminhamento do tráfego: Quando seu hub IoT é implantado em uma região que oferece suporte à redundância de zona para componentes de computação, o Hub IoT deteta 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 íntegra.

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.

Teste de falhas de zona

Como o Hub IoT é responsável por gerir completamente o roteamento, failover e failback de tráfego para falhas em zonas de disponibilidade, não é necessário validar processos de falhas em zonas de disponibilidade ou fornecer informação 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 seu hub IoT pode comutar para a região emparelhada nos seguintes cenários:

  • Failover iniciado pelo cliente: Você mesmo pode acionar o failover manual para a região emparelhada, independentemente de a região estar enfrentando tempo de inatividade ou não. Você pode usar essa abordagem para executar failovers e exercícios 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, exceto após um atraso significativo e com base no melhor esforço. O failover de recursos do Hub IoT pode ocorrer em um momento diferente do failover de outros serviços do Azure. Este processo é uma opção padrão e não requer nenhuma intervenção sua.

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 numa região não emparelhada, ou se o comportamento padrão de replicação e failover não corresponder às suas necessidades, pode usar soluções multi-região personalizadas para resiliência para planear e iniciar failovers.

Suporte de região

A replicação padrão e o failover só são suportados em regiões emparelhadas.

Requerimentos

As opções de replicação e failover de região emparelhada 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 seu ou sua hub entre as regiões emparelhadas do Azure. Geralmente, os dispositivos estão localizados perto da região principal do hub. Se você mover seu 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 extra para a replicação ou recuperação de dados entre regiões.

Se o seu hub IoT estiver numa região não emparelhada, consulte Soluções multi-região personalizadas para resiliência para possível informação de custos.

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. Este processo é uma opção padrão e não requer nenhuma intervenção sua. Em regiões, exceto Brasil, Sul e Sudeste Asiático (Cingapura), os dados do cliente não são armazenados ou processados fora da geografia onde você implanta a instância de serviço.

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

Se o hub IoT estiver em uma região não emparelhada, 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á replicação de dados entre regiões para hubs IoT em regiões não pareadas.

  • 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 interrupção regional

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.

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

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

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

      • Os utilizadores têm permissão para realizar duas operações de failover com sucesso e duas operações de failback com sucesso por dia.

      • Operações de failover ou failback consecutivas não são permitidas. Deve aguardar uma hora entre estas 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 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: Quaisquer solicitações que a região primária esteja 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, alguma perda de dados é esperada após o failover. Esse processo se aplica a failovers gerenciados pela Microsoft e gerenciados pelo cliente. A tabela a seguir descreve o RPO (Recovery Point Objetive, objetivo de ponto de recuperação), ou perda de dados esperada, de cada tipo de dados que os hubs IoT armazenam.

    Tipo de dados RPO
    Registo de identidade 0-5 minutos de perda de dados
    Dados gêmeos do dispositivo 0-5 minutos de perda de dados
    Mensagens da nuvem para o dispositivo 1 0-5 minutos de perda de dados
    Principal 1 e tarefas de dispositivo 0-5 minutos de perda de dados
    Mensagens do dispositivo para a cloud 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 As mensagens da nuvem para o dispositivo e os 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 de 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 submetido a failover 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: Preveja aproximadamente 2 a 26 horas de interrupção desde a perda da região até que o recurso fique disponível na região emparelhada.

      O alto 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 depender da opção iniciada pela Microsoft para satisfazer as 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 a atualização dos registros DNS (Sistema de Nomes de Domínio) 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. A interface de código do usuário 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 tempo de execução que estão sendo executadas em sua instância do hub IoT se tornem totalmente operacionais após 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 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

  • Reencaminhamento do 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 emparelhada.

    Após a conclusão da operação de failover para o hub IoT, espera-se que todas as operações do dispositivo e dos aplicativos back-end continuem funcionando sem exigir intervenção manual. Essa continuidade garante que as mensagens do dispositivo para a nuvem continuem a funcionar e que todo o registro do 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 que você configurou anteriormente, desde que essas assinaturas da Grade de Eventos continuem disponíveis. Nenhuma manipulação adicional é necessária para pontos de extremidade 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.

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

    Quando o utilizador receber mensagens de telemetria do ponto final incorporado usando o cliente de 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 back-end continuem a funcionar sem exigir intervenção manual após o failover.

    Se utilizares diretamente o nome e o ponto de extremidade compatíveis com os Hubs de Eventos na tua aplicação, precisarás de obter o novo ponto de extremidade compatível com os Hubs de Eventos após o failover para continuar as operações. Para recuperar o ponto de extremidade 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 .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 string de conexão para obter o novo endpoint de Hubs de Eventos e restabelecer a conexão. Você deve ter o Visual Studio instalado.

  • Azure Functions e Azure Stream Analytics: Se utilizar o Azure Functions ou o Stream Analytics para se conectar ao ponto de extremidade de eventos incorporado, deverá atualizar o ponto de extremidade do Event Hubs ao qual a função ou trabalho se conecta, seguindo o mesmo processo delineado no marcador anterior. Em seguida, execute uma ação Reiniciar porque qualquer deslocamento de fluxo de eventos se torna inválido após o failover.

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

Recuperação da região

Para fazer failback para a região primária, você pode acionar 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 recuperar de uma interrupção prolongada na região primária original, execute o failback para a mesma região após esta se recuperar da interrupção.

Teste para falhas regionais

Para simular uma falha durante uma interrupção de região, você pode acionar um failover manual do seu hub IoT. No entanto, como o failover regional causa tempo de inatividade e perda de dados, você só deve executar failovers de teste em ambientes que não sejam de produção. Para mais informações, consulte Comportamento durante uma falha de região. Considere configurar uma instância de teste do Hub IoT para iniciar a opção de failover planejada periodicamente. Os testes periódicos podem ajudá-lo a criar confiança em sua capacidade de restaurar e operar suas soluções de ponta a ponta de forma eficaz 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:

  • O seu hub IoT está numa região não emparelhada.

  • As metas de tempo de atividade da sua empresa não são satisfeitas pelo tempo de recuperação ou perda de dados que qualquer opção de failover integrada oferece.

  • Você precisa fazer failover para uma região que não seja o par da sua região principal.

Você pode projetar uma solução de failover entre regiões adaptada a cada dispositivo individual. Um tratamento completo de 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. Neste modelo, o hub IoT principal e o back-end da solução são executados principalmente em uma região do Azure. Um hub IoT secundário e 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 se 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.

  • Custo: 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:

  • Um hub IoT secundário e uma lógica de roteamento de dispositivos: Se o serviço na região principal for interrompido, os dispositivos deverão começar a se conectar à região secundária. Devido à natureza sensível ao estado atual da maioria dos serviços envolvidos, os administradores de soluções geralmente acionam o processo de failover entre regiões manualmente. 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 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. Pode configurar endpoints personalizados do Gerenciador de Tráfego para cada hub IoT. Configure a sonda 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 cópias de segurança geo-replicadas das identidades dos dispositivos e carregá-las para o hub IoT secundário antes de alternar o ponto de extremidade ativo dos dispositivos. A funcionalidade de exportação de identidade de dispositivo do Hub IoT é útil neste contexto. Para obter mais informações, consulte Compreender o registro de identidade em seu hub IoT.

  • Lógica de mesclagem: Quando a região primária fica disponível novamente, todos os estados e dados criados na região secundária devem ser migrados de volta para a região primária. Esse estado e esses dados estão principalmente relacionados a identidades de dispositivo e metadados de aplicativos, que devem ser mesclados com o hub IoT primário e quaisquer outros armazenamentos específicos de aplicativos na região primária.

    Para simplificar esta etapa, use operações idempotentes . As operações idempotentes minimizam os efeitos colaterais da eventual distribuição consistente de eventos e de duplicatas ou entregas fora de ordem de eventos. Além disso, a lógica do aplicativo deve ser projetada para tolerar possíveis inconsistências ou um estado ligeiramente desatualizado. Esse cenário pode ocorrer devido ao tempo extra que o sistema leva para se recuperar dependendo dos RPOs.

Backup e restauração

O serviço 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 de Armazenamento do Azure usando uma assinatura de acesso compartilhado. Esse método permite que você crie backups confiáveis das informações do seu dispositivo em um contêiner de blob que você controla. Para obter mais informações, consulte Importar e exportar identidades de dispositivo do Hub IoT em grande quantidade.

Você também pode exportar o 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 ARM.

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

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do 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 Acordos de Nível de Serviço (SLAs) para serviços online.

Conteúdo relacionado

  • Last updated on