Fiabilidade no Hub IoT do Azure

Hub IoT do Azure é 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 se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft disponibiliza uma variedade de capacidades para apoiar a resiliência e a 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 potenciais falhas e problemas, incluindo falhas transitórias, falhas 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 Hub IoT.

Recomendações de implantação de produção para confiabilidade

Para cargas de trabalho em ambientes de produção, recomendamos seguir estas recomendações:

Visão geral da arquitetura de confiabilidade

Quando cria um hub IoT, implementa um recurso de hub IoT que inclui toda a funcionalidade necessária para gerir e comunicar com os seus dispositivos. Os principais componentes de um hub IoT incluem:

• Registo de identidade do dispositivo: Uma base de dados que armazena informações sobre os dispositivos e módulos que podem ligar-se ao seu hub IoT. Cada dispositivo deve ter uma entrada no registo de identidade antes de se poder ligar. Para obter mais informações, consulte Compreender o registro de identidade em seu hub IoT.

• Componentes de mensagens: Hub IoT trata de mensagens bidirecionais entre dispositivos e as suas aplicações de back-end, incluindo telemetria de dispositivos para a nuvem, comandos da nuvem para o dispositivo e invocações diretas de métodos.

• Gémeos de dispositivos: Documentos JSON que armazenam informação sobre o estado do dispositivo, incluindo metadados, configurações e condições. Dispositivos e aplicações de back-end podem ler e atualizar dispositivos gémeos.

Para fins de fiabilidade, os componentes do Hub IoT são categorizados em dois grupos:

• Componentes de computação: Gerir ligações ao dispositivo, autenticar pedidos, encaminhar mensagens e processar invocações diretas de métodos. Estes componentes determinam a capacidade do Hub IoT para aceitar e processar pedidos.

• Componentes de dados: Armazene o registo de identidade do dispositivo, os gémeos de dispositivo e as mensagens dispositivo-para-nuvem. Estes componentes determinam a disponibilidade e durabilidade dos dados.

Esta distinção é importante porque diferentes regiões suportam diferentes tipos de redundância para estes componentes.

Integração noutros serviços

Pode integrar o Hub IoT com o Registo de Dispositivos do Azure. Se usar esta abordagem, consulte Reliability in Azure Device Registry para compreender a fiabilidade em ambos os serviços.

Se usar Hub IoT Device Provisioning Service (DPS) para provisionamento de dispositivos, a fiabilidade da sua solução também depende do DPS. Para mais informações, consulte Hub IoT Device Provisioning Service alta disponibilidade e recuperação em desastres.

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.

Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

O Hub IoT oferece uma garantia de tempo de atividade razoavelmente elevada, 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.

Para implementações de grande escala, é uma boa prática usar jitter de tentativa de nova tentativa aleatório. O jitter ajuda a distribuir a carga entre as partições do hub e reduz a probabilidade de throttling durante eventos de reconexão em grande escala.

Resiliência a falhas na zona de disponibilidade

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 a zonas 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.

Quando uma região suporta ambos os tipos de redundância de zona, dados críticos de serviço – incluindo o Registo de Identidade de Dispositivo – são replicados de forma síncrona entre zonas de disponibilidade dentro da região. Como resultado, no caso de uma falha numa única zona, não se espera perda de dados, e o serviço redireciona automaticamente a conectividade do dispositivo e o tráfego de mensagens para uma zona saudável. Embora os pedidos em voo possam ser temporariamente impactados durante o evento de failover, a continuidade do serviço é mantida e a lógica de retentativa do dispositivo normalmente assegura a recuperação.

Requerimentos

Apoio regional: O tipo de suporte a zonas de disponibilidade para o seu hub IoT depende da região onde está implementado.

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
E.U.A. Central
E.U.A. Leste
Centro de França
Alemanha Centro-Oeste
Leste do Japão
Coreia Central
Europa do Norte
Leste da Noruega
Catar Central
E.U.A. Centro-Sul
Sudeste Asiático
Sul do Reino Unido
Europa Ocidental
E.U.A. Oeste 2
E.U.A. Oeste 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 extra pela redundância de zona com o Hub IoT.

Configurar o suporte à zona de disponibilidade

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

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando os recursos do Hub IoT são configurados para redundância de zonas 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 automaticamente a instância ativa e a zona.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando os recursos do Hub IoT são configurados para redundância de zonas e há uma falha na zona de disponibilidade.

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

• Notification: A Microsoft não notifica automaticamente quando uma zona está indisponível. No entanto, pode usar Azure Resource Health para monitorizar a saúde de um recurso individual, e pode configurar alertas Resource Health para o notificar de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar 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 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 seu IoT hub está implementado numa região que suporta redundância de zona tanto para componentes de computação como de dados, uma falha de zona não deve causar inatividade nos seus recursos Hub IoT.

• Reencaminhamento de tráfego: Quando o seu IoT hub está implantado numa região que suporta redundância de zona para componentes de computaçã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 recupera, o Hub IoT restaura automaticamente as instâncias na zona de disponibilidade e redireciona o tráfego entre as suas instâncias normalmente.

Teste de falhas de zona

Como o Hub IoT gere totalmente o encaminhamento do tráfego, o failover e o failback para falhas de zona, não precisa de validar os processos de falha das zonas de disponibilidade nem fornecer qualquer contributo adicional.

Resiliência a falhas em toda a região

Hub IoT é um serviço de uma única região. Se a região ficar indisponível, os recursos do seu Hub IoT também ficam indisponíveis. Embora o Hub IoT suporte a replicação assíncrona de dados para uma região Azure emparelhada para fins de recuperação de desastres, não há um mecanismo de failover integrado entre regiões para a conectividade de dispositivos.

Se os recursos estiverem numa região não emparelhada, a Microsoft não replica a configuração e os dados entre regiões não emparelhadas, e não há um sistema de failover de forma integrada 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 satisfizer as suas necessidades, desenha e implementa uma estratégia personalizada de failover multi-região, incluindo os seguintes passos:

• A disponibilizar um Hub IoT secundário numa região Azure diferente.
• Implementar um mecanismo de redirecionamento de endpoint para direcionar dispositivos para a região alternativa quando necessário. Por exemplo, podes provisionar cada dispositivo em ambos os hubs com antecedência e configurar ambas as cadeias de ligação nos dispositivos para que possam alternar entre hubs quando necessário.

Transição gerida pela Microsoft para uma região associada

Se os seus recursos estiverem numa região emparelhada, os dados do seu hub IoT são replicados para a região emparelhada. Esta abordagem destina-se a apoiar a recuperação de desastres. Se houver uma falha de região na região principal do seu hub IoT, não precisa de tomar qualquer ação para permitir que a conectividade dos dispositivos continue na região emparelhada.

Tipos de failover

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 pode iniciar um failover dos 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 dos recursos do Azure Hub IoT pode ocorrer numa altura diferente do failover de outros serviços do Azure. Este processo é uma opção padrão e não requer nenhuma intervenção sua.

Requerimentos

• Apoio regional: A replicação e o failover predefinidos só são suportados em regiões emparelhadas.
• Tier: Existem opções de replicação e failover para regiões emparelhadas em todos os tiers do Hub IoT.

Considerações

Não uses o failover iniciado pelo cliente para migrar permanentemente o teu hub entre as regiões emparelhadas com o 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, incluindo o Registo de Identidade de Dispositivo, 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 realizar 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 dos recursos do Hub IoT pode não ocorrer ao mesmo tempo que outros serviços 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. Este processo aplica-se tanto a failovers geridos pela Microsoft como geridos 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

  ¹ 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: Espere aproximadamente 2 a 26 horas de inatividade desde a perda da região até que o recurso esteja disponível na região emparelhada.

    O elevado tempo de recuperação deve-se ao facto de a Microsoft ter de realizar 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 utilizar uma solução IoT menos crítica que consiga suportar um tempo de inatividade de cerca de um dia, poderá ser possível depender da opção iniciada pela Microsoft para satisfazer os objetivos globais de DR da sua solução IoT.

  • Para ambos os tipos de failover, o nome de domínio totalmente qualificado da instância do hub IoT mantém-se igual 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 IoT hub. 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 DNS + Tempo que a aplicação cliente demora a atualizar qualquer endereço IP de hub IoT em cache

• Redirecionamento de tráfego: Durante o processo de failover, Hub IoT atualiza os registos 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 emitir eventos através do Azure Event Grid, eles podem ser consumidos através das mesmas subscrições que configurou anteriormente, desde que essas subscrições do Event Grid 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 endpoint compatível com Event Hubs do seu hub IoT mudam após o failover no endpoint de eventos incorporado. Esta alteração ocorre porque o cliente Event Hubs não tem visibilidade sobre os eventos do Hub IoT.

  Quando receber mensagens de telemetria do endpoint incorporado, usando o cliente Event Hubs ou o host do processador de eventos, use a cadeia de conexão do hub IoT para estabelecer a ligaçã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 endpoint e o nome, pode usar o portal Azure ou o SDK .NET:

  • O portal do Azure: Para mais informações sobre como utilizar o portal para obter o ponto final compatível com o Event Hubs e o nome compatível com o Event Hubs, consulte Ligar ao ponto final incorporado.

  • The .NET SDK: Para usar a cadeia de conexão do hub IoT para recapturar o endpoint compatível com o Event Hubs, utilize o código de exemplo. Este exemplo de código usa a cadeia de ligação para obter o novo endpoint dos Event Hubs e restabelecer a ligação. Tem de ter o Visual Studio instalado.

• Funções do Azure e Azure Stream Analytics: Se usar Funções do Azure ou Stream Analytics para se ligar ao endpoint de eventos incorporado, deve atualizar o endpoint dos Event Hubs ao qual a função ou job se liga, seguindo o mesmo processo descrito no ponto 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 encaminhar para Armazenamento do Azure, liste primeiro os blobs ou ficheiros. Em seguida, itere sobre eles para garantir que todos os blobs ou arquivos sejam lidos sem assumir particionamento. O intervalo de partições pode potencialmente mudar durante um failover iniciado pela Microsoft ou iniciado pelo cliente. Pode usar a API List Blobs para enumerar a lista de blobs ou a API List Azure Data Lake Storage para a lista de ficheiros. Para mais informações, veja Armazenamento do Azure como endpoint 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 Hub IoT de teste para iniciar periodicamente a opção de failover planeada. 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

As capacidades de failover entre regiões do Hub IoT não são adequadas 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 seu principal hub IoT e o back-end da solução funcionam principalmente numa única região Azure. Um hub IoT secundário e um back-end são implementados noutra 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.

A um nível geral, para implementar um modelo regional de failover com o Hub IoT, é necessário 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 uma aplicação web replicada e mantida acessível através de técnicas de redirecionamento DNS, como Gestor de Tráfego do Azure.

  Observação

  O Traffic Manager não tem suporte integrado 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, o que lhe permite exportar todo o registo de identidade de um IoT hub. Estes dados são transferidos para um contentor de blob do Armazenamento do Azure através de uma assinatura de acesso partilhada. 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 mais informações, consulte Importar e exportar identidades de dispositivos do Hub IoT em massa.

Também pode exportar o modelo Azure Resource Manager (modelo ARM) de um hub IoT existente para criar uma cópia de segurança 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?.

Resiliência à manutenção de serviços

A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não se espera tempo de inatividade durante os eventos de manutenção, a menos que tenha sido informado através do Azure Service Health manutenção programada.

Contrato de nível de serviço

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

Conteúdo relacionado

• Escalabilidade da solução IoT, alta disponibilidade e DR
• Fiabilidade no Registo de Dispositivos Azure
• Fiabilidade em Azure