Elevada disponibilidade e recuperação após desastre do Hub IoT

Como primeiro passo para implementar uma solução IoT resiliente, os arquitetos, programadores e empresários têm de definir os objetivos de tempo de atividade para as soluções que estão a criar. Estes objetivos podem ser definidos principalmente com base em objetivos empresariais específicos para cada cenário. Neste contexto, o artigo Azure Business Continuity Technical Guidance (Orientação Técnica de Continuidade de Negócio do Azure ) descreve uma estrutura geral que o ajuda a pensar na continuidade do negócio e na recuperação após desastre. O documento Recuperação após desastre e elevada disponibilidade para aplicações do Azure fornece orientações de arquitetura sobre estratégias para as aplicações do Azure alcançarem Elevada Disponibilidade (HA) e Recuperação Após Desastre (DR).

Este artigo aborda as funcionalidades ha e DR oferecidas especificamente pelo serviço de Hub IoT. As grandes áreas abordadas neste artigo são:

  • HA intra-região
  • DR entre regiões
  • Alcançar a HA entre regiões

Consoante os objetivos de tempo de atividade definidos para as suas soluções de IoT, deve determinar quais das opções descritas neste artigo melhor se adequam aos seus objetivos empresariais. Incorporar qualquer uma destas alternativas HA/DR na sua solução de IoT requer uma avaliação cuidadosa das compensações entre:

  • Nível de resiliência necessário
  • Complexidade da implementação e manutenção
  • Impacto do COGS

HA intra-região

O serviço Hub IoT fornece HA intra-região ao implementar redundâncias em quase todas as camadas do serviço. O SLA publicado pelo serviço Hub IoT é obtido ao utilizar estas redundâncias. Os programadores de uma solução de IoT não necessitam de mais trabalho para tirar partido destas funcionalidades ha. Embora Hub IoT ofereça uma garantia de tempo de atividade razoavelmente elevada, as falhas transitórias ainda podem ser esperadas como em qualquer plataforma de computação distribuída. Se estiver apenas a começar a migrar as suas soluções para a cloud a partir de uma solução no local, o foco tem de passar da otimização do "tempo médio entre falhas" para "tempo médio para recuperar". Por outras palavras, as falhas transitórias devem ser consideradas normais ao operar com a cloud na mistura. As políticas de repetição adequadas têm de ser incorporadas nos componentes que interagem com uma aplicação na cloud para lidar com falhas transitórias.

Zonas de disponibilidade

Hub IoT suporta zonas de disponibilidade do Azure. Uma zona de disponibilidade é uma oferta de elevada disponibilidade que protege as suas aplicações e dados contra falhas do datacenter. Uma região com suporte de zona de disponibilidade é composta por três zonas que suportam essa região. Cada zona fornece um ou mais datacenters, cada um numa localização física exclusiva com energia, refrigeração e rede independentes. Esta configuração fornece replicação e redundância na região. O suporte da zona de disponibilidade para Hub IoT é ativado automaticamente para novos recursos de Hub IoT criados nas seguintes regiões do Azure:

  • Leste da Austrália
  • Sul do Brasil
  • Canadá Central
  • E.U.A. Central
  • França Central
  • Alemanha Centro-Oeste
  • Leste do Japão
  • Europa do Norte
  • Sudeste Asiático
  • Sul do Reino Unido
  • E.U.A. Oeste 2

DR entre regiões

Podem existir algumas situações raras em que um datacenter se depare com interrupções prolongadas devido a falhas de energia ou outras falhas que envolvam recursos físicos. Estes eventos são raros durante os quais a capacidade ha intra-região descrita anteriormente pode nem sempre ajudar. Hub IoT fornece várias soluções para recuperar de tais interrupções prolongadas.

As opções de recuperação disponíveis para os clientes nesta situação são a ativação pós-falha iniciada pela Microsoft e a ativação pós-falha manual. A diferença fundamental entre os dois é que a Microsoft inicia o primeiro e o utilizador inicia este último. Além disso, a ativação pós-falha manual fornece um objetivo de tempo de recuperação (RTO) inferior em comparação com a opção de ativação pós-falha iniciada pela Microsoft. As RTOs específicas oferecidas com cada opção são abordadas nas secções seguintes. Quando qualquer uma destas opções para efetuar a ativação pós-falha de um hub IoT a partir da região primária é exercido, o hub torna-se totalmente funcional na região geo emparelhada do Azure correspondente.

Ambas as opções de ativação pós-falha oferecem os seguintes objetivos de ponto de recuperação (RPOs):

Tipo de dados Objetivos de ponto de recuperação (RPO)
Registo de identidades Perda de dados de 0 a 5 minutos
Dados do dispositivo duplo Perda de dados de 0 a 5 minutos
Mensagens da cloud para o dispositivo1 Perda de dados de 0 a 5 minutos
Tarefas principais 1 e de dispositivo Perda de dados de 0 a 5 minutos
Mensagens do dispositivo para a cloud Todas as mensagens não lidas são perdidas
Mensagens de feedback da cloud para o dispositivo Todas as mensagens não lidas são perdidas

1 As mensagens da cloud para o dispositivo e as tarefas principais não são recuperadas como parte da ativação pós-falha manual.

Assim que a operação de ativação pós-falha do hub IoT for concluída, espera-se que todas as operações do dispositivo e das aplicações de back-end continuem a funcionar sem que seja necessária uma intervenção manual. Isto significa que as mensagens do dispositivo para a cloud devem continuar a funcionar e que todo o registo do dispositivo está intacto. Os eventos emitidos através do Event Grid podem ser consumidos através das mesmas subscrições configuradas anteriormente, desde que essas subscrições do Event Grid continuem disponíveis. Não é necessário processamento adicional para pontos finais personalizados.

Atenção

  • O nome e o ponto final compatíveis com os Hubs de Eventos do Hub IoT ponto final de eventos incorporados mudam após a ativação pós-falha. Ao receber mensagens de telemetria do ponto final incorporado com o cliente dos Hubs de Eventos ou o anfitrião do processador de eventos, deve utilizar a cadeia de ligação do hub IoT para estabelecer a ligação. Isto garante que as suas aplicações de back-end continuam a funcionar sem que seja necessária intervenção manual após a ativação pós-falha. Se utilizar o nome e o ponto final compatíveis com o Hub de Eventos na sua aplicação diretamente, terá de obter o novo ponto final compatível com o Hub de Eventos após a ativação pós-falha para continuar as operações. Para obter mais informações, veja Ativação pós-falha manual e Hub de Eventos.
  • Se utilizar o Funções do Azure ou o Azure Stream Analytics para ligar o ponto final de Eventos incorporado, poderá ter de executar um Reinício. Isto acontece porque, durante a ativação pós-falha, os desvios anteriores já não são válidos.
  • Ao encaminhar para o armazenamento, recomendamos que liste os blobs ou ficheiros e, em seguida, iterando sobre os mesmos, para garantir que todos os blobs ou ficheiros são lidos sem fazer suposições de partição. O intervalo de partições pode ser alterado durante uma ativação pós-falha iniciada pela Microsoft ou uma ativação pós-falha manual. Pode utilizar a API de Blobs de Lista para enumerar a lista de blobs ou Listar a API do ADLS Gen2 para a lista de ficheiros. Para saber mais, veja Armazenamento do Azure como um ponto final de encaminhamento.

Ativação pós-falha iniciada pela Microsoft

A ativação pós-falha iniciada pela Microsoft é efetuada pela Microsoft em situações raras para efetuar a ativação pós-falha de todos os hubs IoT de uma região afetada para a região geoconjunta correspondente. Este processo é uma opção predefinida e não requer intervenção do utilizador. A Microsoft reserva-se o direito de determinar quando é que esta opção será exercido. Este mecanismo não envolve o consentimento de um utilizador antes da ativação pós-falha do hub do utilizador. A ativação pós-falha iniciada pela Microsoft tem um objetivo de tempo de recuperação (RTO) de 2 a 26 horas.

O RTO grande deve-se ao facto de a Microsoft ter de realizar a operação de ativação pós-falha em nome de todos os clientes afetados nessa região. Se estiver a executar uma solução de IoT menos crítica que possa manter um período de indisponibilidade de aproximadamente um dia, não há problema em assumir uma dependência desta opção para cumprir os objetivos gerais de recuperação após desastre da sua solução de IoT. O tempo total para as operações de runtime ficarem totalmente operacionais assim que este processo é acionado, é descrito na secção "Tempo para recuperar".

Apenas os utilizadores que implementem hubs IoT nas regiões Sul e Sudeste Asiático (Singapura) do Brasil podem optar ativamente por não participar nesta funcionalidade. Para obter mais informações, veja Desativar a recuperação após desastre.

Nota

Hub IoT do Azure não armazena nem processa dados de clientes fora da geografia onde implementa a instância de serviço. Para obter mais informações, veja Replicação entre regiões no Azure.

Ativação pós-falha manual

Se os seus objetivos de tempo de atividade empresarial não forem satisfeitos com o RTO que a Microsoft iniciou a ativação pós-falha, considere utilizar a ativação pós-falha manual para acionar o processo de ativação pós-falha manualmente. O RTO que utiliza esta opção pode estar entre 10 minutos e algumas horas. O RTO é atualmente uma função do número de dispositivos registados relativamente à ativação pós-falha da instância do hub IoT. Pode esperar que o RTO de um hub que aloja aproximadamente 100.000 dispositivos esteja no estádio de 15 minutos. O tempo total para as operações de runtime ficarem totalmente operacionais assim que este processo for acionado, é descrito na secção "Hora de recuperar".

A opção de ativação pós-falha manual está sempre disponível para utilização, independentemente de a região primária estar ou não com um período de indisponibilidade. Por conseguinte, esta opção pode potencialmente ser utilizada para realizar ativações pós-falha planeadas. Um exemplo de utilização de ativações pós-falha planeadas é efetuar exercícios periódicos de ativação pós-falha. No entanto, uma palavra de cuidado é que uma operação de ativação pós-falha planeada resulta num período de inatividade para o hub para o período definido pelo RTO para esta opção e também resulta numa perda de dados, conforme definido pela tabela RPO acima. Pode considerar a configuração de uma instância do hub IoT de teste para exercer periodicamente a opção de ativação pós-falha planeada para obter confiança na sua capacidade de pôr as suas soluções ponto a ponto em execução quando ocorre um desastre real.

A ativação pós-falha manual está disponível sem custos adicionais para os hubs IoT criados após 18 de maio de 2017

Para obter instruções passo a passo, veja Tutorial: Executar a ativação pós-falha manual para um hub IoT

Ativação pós-falha manual e Hubs de Eventos

O nome e o ponto final compatíveis com os Hubs de Eventos do Hub IoT ponto final de eventos incorporados mudam após a ativação pós-falha manual. Isto deve-se ao facto de o cliente dos Hubs de Eventos não ter visibilidade sobre Hub IoT eventos. O mesmo acontece com outros clientes baseados na cloud, como As Funções e o Azure Stream Analytics. Para obter o ponto final e o nome, pode utilizar o portal do Azure ou o SDK .NET.

Utilizar o portal

Para obter mais informações sobre como utilizar o portal para obter o ponto final compatível com o Hub de Eventos e o nome compatível com o Hub de Eventos, consulte Ler a partir do ponto final incorporado.

Utilizar o .NET SDK

Para utilizar a cadeia de ligação Hub IoT para recapturar o ponto final compatível com os Hubs de Eventos, utilize um exemplo localizado em https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. O exemplo de código utiliza a cadeia de ligação para obter o novo ponto final dos Hubs de Eventos e restabelecer a ligação. Tem de ter o Visual Studio instalado.

Executar testes de teste

Os testes de teste não devem ser realizados em hubs IoT que estão a ser utilizados nos seus ambientes de produção.

Não utilize a ativação pós-falha manual para migrar o hub IoT para uma região diferente

A ativação pós-falha manual não deve ser utilizada como um mecanismo para migrar permanentemente o hub entre as regiões geográficas emparelhadas do Azure. Partindo do princípio de que os dispositivos estavam localizados mais próximos da região primária do hub, a latência das operações em execução no hub IoT aumentará quando o hub efetuar a ativação pós-falha para uma região secundária.

Reativação pós-falha

Pode efetuar a reativação pós-falha para a região primária antiga ao acionar a ação de ativação pós-falha uma segunda vez. Se a operação de ativação pós-falha original tiver sido efetuada para recuperar de uma interrupção prolongada na região primária original, recomendamos que o hub volte à localização original após a recuperação da situação de indisponibilidade.

Importante

  • Os utilizadores só podem realizar 2 operações de ativação pós-falha com êxito e 2 operações de reativação pós-falha bem-sucedidas por dia.
  • Não são permitidas operações de ativação pós-falha/reativação pós-falha. Tem de aguardar 1 hora entre estas operações.

Hora de recuperar

Embora o FQDN (e, portanto, a cadeia de ligação) da instância do hub IoT permaneça a mesma pós-ativação pós-falha, o endereço IP subjacente muda. O tempo para que as operações de runtime que estão a ser executadas na instância do hub IoT fiquem totalmente operacionais depois de o processo de ativação pós-falha poder ser expresso com a seguinte função:

Tempo de recuperação = RTO [10 min - 2 horas para ativação pós-falha manual | 2 a 26 horas para ativação pós-falha iniciada pela Microsoft] + Atraso de propagação de DNS + Tempo decorrido pela aplicação cliente para atualizar qualquer endereço IP Hub IoT em cache.

Importante

Os SDKs IoT não colocam em cache o endereço IP do hub IoT. Recomendamos que a inter-ligação de código do utilizador com os SDKs não coloque em cache o endereço IP do hub IoT.

Desativar a recuperação após desastre

Hub IoT fornece Microsoft-Initiated Ativação Pós-falha e Ativação Pós-falha Manual ao replicar dados para a região emparelhada para cada hub IoT. Em algumas regiões, pode evitar a replicação de dados fora da região ao desativar a recuperação após desastre ao criar um hub IoT. As seguintes regiões suportam esta funcionalidade:

  • Sul do Brasil; região emparelhada, E.U.A. Centro-Sul.
  • Sudeste Asiático (Singapura); região emparelhada, Ásia Oriental (RAE de Hong Kong).

Para desativar a recuperação após desastre em regiões suportadas, certifique-se de que a recuperação após desastre ativada não está selecionada quando criar o hub IoT:

Captura de ecrã que mostra a opção de recuperação após desastre para um hub IoT na região de Singapura.

Também pode desativar a recuperação após desastre quando cria um hub IoT com um modelo do ARM.

A capacidade de ativação pós-falha não estará disponível se desativar a recuperação após desastre para um hub IoT.

Captura de ecrã que mostra a recuperação após desastre desativada para um hub IoT na região de Singapura.

Só pode desativar a recuperação após desastre para evitar a replicação de dados fora da região emparelhada no Sul do Brasil ou sudeste asiático quando criar um hub IoT. Se quiser configurar o hub IoT existente para desativar a recuperação após desastre, tem de criar um novo hub IoT com a recuperação após desastre desativada e migrar manualmente o hub IoT existente. Para obter orientações, veja Como clonar um Hub IoT do Azure para outra região. Este artigo contém conselhos sobre a migração de rotas, pontos finais personalizados e outros artefactos Hub IoT ao migrar para um novo hub Iot. Pode ignorar as preocupações que têm a ver com a migração entre regiões.

Obter HA entre regiões

Se os seus objetivos de tempo de atividade empresarial não estiverem satisfeitos com o RTO que as opções de ativação pós-falha iniciadas pela Microsoft ou de ativação pós-falha manual fornecem, deve considerar a implementação de um mecanismo de ativação pós-falha entre regiões automática por dispositivo. Um tratamento completo das topologias de implementação em soluções IoT está fora do âmbito deste artigo. O artigo aborda o modelo de implementação pós-falha regional para elevada disponibilidade e recuperação após desastre.

Num modelo de ativação pós-falha regional, o back-end da solução é executado principalmente numa localização de datacenter. Um hub IoT secundário e um back-end são implementados noutra localização do datacenter. Se o hub IoT na região primária sofrer uma falha ou a conectividade de rede do dispositivo para a região primária for interrompida, os dispositivos utilizam um ponto final de serviço secundário. Pode melhorar a disponibilidade da solução ao implementar um modelo de ativação pós-falha entre regiões em vez de permanecer numa única região.

A um nível elevado, para implementar um modelo de ativação pós-falha regional com Hub IoT, tem de seguir os seguintes passos:

  • Um hub IoT secundário e uma lógica de encaminhamento de dispositivos: se o serviço na sua região primária for interrompido, os dispositivos têm de começar a ligar-se à sua região secundária. Dada a natureza com conhecimento do estado da maioria dos serviços envolvidos, é comum que os administradores de soluções acionem o processo de ativação pós-falha entre regiões. A melhor forma de comunicar o novo ponto final aos dispositivos, mantendo o controlo do processo, é pedir-lhes que verifiquem regularmente um serviço de assistente para o ponto final ativo atual. O serviço de assistente pode ser uma aplicação Web que é replicada e mantida acessível através de técnicas de redirecionamento de DNS (por exemplo, com o Gestor de Tráfego do Azure).

    Nota

    O serviço hub IoT não é um tipo de ponto final suportado no Gestor de Tráfego do Azure. A recomendação é integrar o serviço de assistente proposto com o gestor de tráfego do Azure ao fazê-lo implementar a API de pesquisa de estado de funcionamento do ponto final.

  • Replicação do registo de identidades: para ser utilizável, o hub IoT secundário tem de conter todas as identidades do dispositivo que se possam ligar à solução. A solução deve manter cópias de segurança georreplicadas de identidades de dispositivos e carregá-las para o hub IoT secundário antes de mudar o ponto final ativo para os dispositivos. A funcionalidade de exportação de identidade do dispositivo de Hub IoT é útil neste contexto. Para obter mais informações, veja Hub IoT guia do programador – registo de identidades.

  • Lógica de intercalação: quando a região primária fica novamente disponível, todo o estado e os dados que foram criados no site secundário têm de ser migrados novamente para a região primária. Este estado e os dados relacionam-se principalmente com identidades de dispositivos e metadados de aplicações, que têm de ser intercalados com o hub IoT primário e quaisquer outros arquivos específicos da aplicação na região primária.

Para simplificar este passo, deve utilizar operações idempotentes. As operações Idempotent minimizam os efeitos colaterais da eventual distribuição consistente de eventos e de duplicados ou entrega fora de ordem de eventos. Além disso, a lógica da aplicação deve ser concebida para tolerar potenciais inconsistências ou um estado ligeiramente desatualizado. Esta situação pode ocorrer devido ao tempo extra que o sistema demora a ser curado com base nos objetivos do ponto de recuperação (RPO).

Escolha a opção HA/DR correta

Eis um resumo das opções HA/DR apresentadas neste artigo que podem ser utilizadas como um quadro de referência para escolher a opção certa que funciona para a sua solução.

Opção HA/DR RTO RPO Requer intervenção manual? Complexidade da implementação Impacto nos custos
Ativação pós-falha iniciada pela Microsoft 2 - 26 horas Veja a tabela RPO acima No Nenhuma Nenhuma
Ativação pós-falha manual 10 min - 2 horas Veja a tabela RPO acima Yes Muito baixo. Só precisa de acionar esta operação a partir do portal. Nenhuma
HA entre regiões < 1 minuto Depende da frequência de replicação da sua solução de HA personalizada No Alto > 1x o custo de 1 hub IoT

Passos seguintes