Confiabilidade no Hub IoT do Azure

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, reliability é uma responsabilidade compartilhada. 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 Hub IoT 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) Hub IoT.

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

Para cargas de trabalho de produção, recomendamos que você siga estas recomendações:

Visão geral da arquitetura de confiabilidade

Ao criar um hub IoT, você implanta um recurso do Hub IoT que inclui todas as funcionalidades necessárias para gerenciar e se comunicar com seus dispositivos. Os principais componentes de um hub IoT incluem:

• Registro de identidade do dispositivo: Um banco de dados que armazena informações sobre os dispositivos e módulos que podem se conectar ao hub IoT. Cada dispositivo deve ter uma entrada no registro de identidade antes de se conectar. Para obter mais informações, consulte Entender o registro de identidade no Hub IoT.

• Messaging components: Hub IoT manipula mensagens bidirecionais entre dispositivos e seus aplicativos de back-end, incluindo telemetria de dispositivo para nuvem, comandos de nuvem para dispositivo e invocações de método direto.

• Dispositivos gêmeos: Documentos JSON que armazenam informações de estado do dispositivo, incluindo metadados, configurações e condições. Dispositivos e aplicativos de back-end podem ler e atualizar dispositivos gêmeos.

Para fins de confiabilidade, Hub IoT componentes são categorizados em dois grupos:

• Componentes de computação: Gerenciar conexões de dispositivo, autenticar solicitações, rotear mensagens e processar invocações de método direto. Esses componentes determinam a capacidade do Hub IoT de aceitar e processar solicitações.

• Componentes de dados: Armazene o registro de identidade do dispositivo, os dispositivos gêmeos e as mensagens do dispositivo para a nuvem. Esses componentes determinam a disponibilidade e a durabilidade dos dados.

Essa distinção é importante porque regiões diferentes dão suporte a diferentes tipos de redundância para esses componentes.

Integração com outros serviços

Você pode integrar Hub IoT com o Registro de Dispositivo do Azure. Se você usar essa abordagem, examine Relibilidade no Registro de Dispositivo Azure para entender a confiabilidade em ambos os serviços.

Se você usar Hub IoT DPS (Serviço de Provisionamento de Dispositivos) para provisionamento de dispositivos, a confiabilidade da solução também dependerá do DPS. Para obter mais informações, consulte alta disponibilidade e recuperação de desastre do Serviço de Provisionamento de Dispositivos 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 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.

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.

Para implantações de alta escala, é uma boa prática usar jitter aleatório nas tentativas de repetição. O Jitter ajuda a distribuir a carga entre as partições do hub e reduz a probabilidade de regulação durante grandes eventos de reconexão em larga escala.

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.

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.

Quando uma região dá suporte a ambos esses tipos de dados de serviço críticos com redundância de zonas, incluindo o Registro de Identidade do Dispositivo, são replicados de forma síncrona entre zonas de disponibilidade dentro da região. Como resultado, no caso de uma falha de zona única, nenhuma perda de dados é esperada e o serviço redireciona automaticamente a conectividade do dispositivo e o tráfego de mensagens para uma zona íntegra. Embora as solicitações em andamento possam ser afetadas transitoriamente durante o evento de falha, a continuidade do serviço é mantida e a lógica de tentativa novamente do dispositivo normalmente garante a recuperação.

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

Configurar o suporte à zona de disponibilidade

Os recursos do Hub IoT dão suporte automaticamente à redundância zonal 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 Hub IoT são configurados para redundância zonal 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 Hub IoT são configurados para redundância de zona de disponibilidade e há uma interrupção na zona de disponibilidade.

• Detecção e resposta: O serviço 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.

• Notification: Microsoft não notifica automaticamente quando uma zona está inoperante. 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 Integridade do Serviço do Azure 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.

• ** Tempo de indisponibilidade esperado: Quando o Hub IoT é implantado em uma região que oferece suporte à redundância de zona para componentes de computação e de dados, uma falha de zona não deve causar indisponibilidade aos seus recursos do Hub IoT.

• Traffic rerouting: Quando o Hub IoT é implantado em uma região que oferece 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 é recuperada, 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 em zonas de disponibilidade, você não precisa validar os processos de falhas em zonas de disponibilidade ou fornecer qualquer informação adicional.

Resiliência a falhas em toda a região

Hub IoT é um serviço de região única. Se a região ficar indisponível, seus recursos de Hub IoT também ficarão indisponíveis. Embora o Hub IoT dê suporte à replicação de dados assíncrona para uma região emparelhada do Azure para fins de recuperação de desastre, não há failover interno entre regiões para conectividade de dispositivo.

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 entre regiões embutido. 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 hub IoT estiver em uma região não pareada ou se o comportamento padrão de replicação e failover não atender às suas necessidades, você projetará e implementará uma estratégia personalizada de failover de várias regiões, incluindo as seguintes etapas:

• Provisionando um Hub IoT secundário em uma região de Azure diferente.
• Implementando um mecanismo de redirecionamento de endpoint para encaminhar dispositivos à região alternativa quando necessário. Por exemplo, você pode provisionar cada dispositivo em ambos os hubs com antecedência e configurar ambas as cadeias de conexão nos dispositivos para que eles possam alternar entre hubs quando necessário.

Failover gerenciado pela Microsoft para uma região emparelhada

Se os recursos estiverem em uma região emparelhada, os dados do hub IoT serão replicados para a região emparelhada. Essa abordagem destina-se a dar suporte à recuperação de desastre. Se houver uma falha de região na região primária do hub IoT, você não precisará executar nenhuma ação para permitir que a conectividade do dispositivo continue na região emparelhada.

Tipos de failover

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.

• Falha de sistema iniciada pela Microsoft: Se uma região for perdida, a Microsoft pode iniciar um processo de failover dos hubs IoT para a região pareada. No entanto, é improvável que Microsoft inicie o failover, exceto após um atraso significativo e com base no melhor esforço. O failover dos 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ê.

Requirements

• Suporte à região: A replicação e o failover padrão só têm suporte em regiões emparelhadas.
• Tier: Opções de replicação de região emparelhada e de failover estão disponíveis para todos os tiers 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, incluindo o Registro de Identidade do 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á 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.

  • Microsoft-initiated failover: 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 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 por 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 de 2 a 26 horas de tempo de inatividade desde a perda da região até a disponibilidade do recurso na região emparelhada.

    A alta quantidade de tempo de recuperação ocorre porque 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 por 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 de Hub IoT 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 por 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, 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 de 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.

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

  Quando você recebe mensagens de telemetria do ponto de extremidade embutido 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 através do SDK .NET.

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

  • O .NET SDK: 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 endpoint dos Hubs de Eventos e restabelecer a conexão. Você deve ter Visual Studio instalado.

• Azure Functions e Azure Stream Analytics: Se você usar Azure Functions ou Stream Analytics para se conectar ao ponto de extremidade de eventos incorporado, deverá atualizar o ponto de extremidade dos Hubs de Eventos ao qual a função ou a tarefa 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 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 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 a lista de 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 de teste do Hub IoT para ativar a opção de failover planejado 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 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 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 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 Gerenciador de Tráfego do Azure.

  Observação

  O Gerenciador de Tráfego não tem suporte interno para 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 de Hub IoT é ú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 Hub IoT 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 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 dispositivo Hub IoT 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?.

Resiliência à manutenção do serviço

Microsoft aplica regularmente atualizações de serviço e executa outra manutenção. A plataforma Azure manipula essas atividades automaticamente, garantindo que a manutenção seja perfeita e transparente para você. Nenhum tempo de inatividade é esperado durante eventos de manutenção, a menos que você tenha sido informado através de manutenção planejada do Integridade do Serviço do Azure.

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

• Escalabilidade da solução de IoT, alta disponibilidade e DR
• Confiabilidade no Registro de Dispositivos do Azure
• Relibilidade em Azure