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

Como primeiro passo para implementar uma solução IoT resiliente, arquitetos, desenvolvedores e empresários devem definir os objetivos de uptime para as soluções que estão construindo. Estes objetivos podem ser definidos principalmente com base em objetivos de negócio específicos para cada cenário. Neste contexto, o artigo Azure Business Continuity Technical Guidance descreve um quadro geral para ajudá-lo a pensar na continuidade do negócio e na recuperação de desastres. O trabalho de recuperação de desastres e alta disponibilidade para aplicações Azure fornece orientação de arquitetura sobre estratégias para aplicações Azure para alcançar Alta Disponibilidade (HA) e Recuperação de Desastres (DR).

Este artigo discute as funcionalidades HA e DR oferecidas especificamente pelo serviço Hub IoT. As grandes áreas discutidas neste artigo são:

  • HA intrarregião
  • Região transversal DR
  • Alcançar a região transversal HA

Dependendo dos objetivos de uptime que define para as suas soluções IoT, deverá determinar quais das opções descritas abaixo se adequam melhor aos seus objetivos de negócio. A incorporação de qualquer uma destas alternativas HA/DR na sua solução IoT requer uma avaliação cuidadosa das trocas entre:

  • Nível de resiliência que precisa
  • Complexidade de implementação e manutenção
  • Impacto COGS

HA intrarregião

O serviço Hub IoT presta HA intrarregião implementando despedimentos em quase todas as camadas do serviço. O SLA publicado pelo serviço Hub IoT é conseguido recorrendo a estes despedimentos. Não é necessário nenhum trabalho adicional por parte dos desenvolvedores de uma solução IoT para tirar partido destas funcionalidades HA. Embora Hub IoT ofereça uma garantia razoavelmente elevada de tempo, ainda podem ser esperadas falhas transitórias como em qualquer plataforma de computação distribuída. Se está apenas a começar a migrar as suas soluções para a nuvem a partir de uma solução no local, o seu foco precisa de passar de otimizar "o tempo médio entre falhas" para "tempo médio para recuperar". Por outras palavras, as falhas transitórias devem ser consideradas normais durante o funcionamento com a nuvem na mistura. Devem ser incorporadas políticas de reorientação adequadas aos componentes que interagem com uma aplicação em nuvem para lidar com falhas transitórias.

Zonas de Disponibilidade

Hub IoT apoia Zonas de Disponibilidade. Uma Zona de Disponibilidade é uma oferta de alta disponibilidade que protege as suas aplicações e dados contra falhas no datacenter. Uma região com apoio zona de disponibilidade é composta por três zonas de apoio a essa região. Cada zona fornece um ou mais datacenters cada um num local físico único com potência, arrefecimento e networking independentes. Isto proporciona 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 de 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

Região transversal DR

Pode haver algumas situações raras quando um datacenter experimenta interrupções prolongadas devido a falhas de energia ou outras falhas envolvendo ativos físicos. Tais eventos são raros durante os quais a capacidade ha intrarregião acima descrita pode nem sempre ajudar. Hub IoT fornece múltiplas soluções para a recuperação de tais interrupções prolongadas.

As opções de recuperação disponíveis para os clientes em tal situação são falha de falha iniciada pela Microsoft e falha manual. A diferença fundamental entre os dois é que a Microsoft inicia a primeira e o utilizador inicia este último. Além disso, a falha manual fornece um objetivo de tempo de recuperação mais baixo (RTO) em comparação com a opção de failover iniciada pela Microsoft. Os RTOs específicos oferecidos com cada opção são discutidos nas secções abaixo. Quando qualquer uma destas opções para executar o failover de um hub IoT da sua região primária é exercida, o hub torna-se totalmente funcional na região geo-emparelhada Azure correspondente.

Ambas as opções de failover oferecem os seguintes objetivos de ponto de recuperação (RPOs):

Tipo de dados Objetivos do ponto de recuperação (RPO)
Registo de identidade Perda de dados de 0 a 5 minutos
Dados gémeos do dispositivo Perda de dados de 0 a 5 minutos
Mensagens nuvem-para-dispositivo1 Perda de dados de 0 a 5 minutos
Trabalhos parentais e de dispositivos Perda de dados de 0 a 5 minutos
Mensagens do dispositivo para a cloud Todas as mensagens não lidas estão perdidas
Mensagens de feedback em nuvem-para-dispositivo Todas as mensagens não lidas estão perdidas

1 As mensagens em nuvem-para-dispositivo e os trabalhos dos pais não são recuperados como parte do failover manual.

Uma vez concluída a operação de failover para o hub IoT, espera-se que todas as operações do dispositivo e aplicações de back-end continuem a funcionar sem necessidade de uma intervenção manual. Isto significa que as suas mensagens dispositivo-nuvem devem continuar a funcionar e todo o registo do dispositivo está intacto. Os eventos emitidos através da Grade de Eventos podem ser consumidos através das mesmas subscrições configuradas mais cedo, desde que essas subscrições da Grelha de Eventos continuem disponíveis. Não é necessário manuseamento adicional para pontos finais personalizados.

Atenção

  • O nome e ponto final compatíveis com o Event Hub do Hub IoT alteração do ponto final de eventos incorporado após a falha. Ao receber mensagens de telemetria do ponto final incorporado utilizando o cliente Event Hub ou o anfitrião do processador de eventos, deverá utilizar o fio de ligação do hub IoT para estabelecer a ligação. Isto garante que as suas aplicações de back-end continuem a funcionar sem exigir o failover do pós de intervenção manual. Se utilizar o nome e o ponto final compatíveis com o Event Hub na sua aplicação diretamente, terá de ir buscar o novo ponto final compatível com o Event Hub após a falha para continuar as operações. Para mais informações, consulte o Manual de Failover e o Event Hub.

  • Se utilizar Funções do Azure ou Azure Stream Analytics para ligar o ponto final de Eventos incorporados, poderá ter de realizar um Restart. Isto porque durante o failover offsets anteriores já não são válidos.

  • Ao encaminhar para o armazenamento, recomendamos listar as bolhas ou ficheiros e, em seguida, iterar sobre eles, para garantir que todas as bolhas ou ficheiros são lidos sem fazer quaisquer suposições de partição. O intervalo de partição pode potencialmente mudar durante uma falha de falha iniciada pela Microsoft ou falha manual. Pode utilizar a Lista Blobs API para enumerar a lista de blobs ou Lista ADLS Gen2 API para a lista de ficheiros. Para saber mais, veja o Azure Armazenamento como um ponto final de encaminhamento.

Falha iniciada pela Microsoft

O failover iniciado pela Microsoft é exercido pela Microsoft em situações raras para falhar em todos os centros IoT de uma região afetada para a região geo-emparelhada correspondente. Este processo é uma opção padrão e não requer qualquer intervenção do utilizador. A Microsoft reserva-se o direito de determinar quando esta opção será exercida. Este mecanismo não envolve o consentimento do utilizador antes do hub do utilizador ser chumbado. O failover iniciado pela Microsoft tem um objetivo de tempo de recuperação (RTO) de 2-26 horas.

O grande RTO deve-se ao facto de a Microsoft ter de realizar a operação de failover em nome de todos os clientes afetados naquela região. Se você está executando uma solução IoT menos crítica que pode sustentar um tempo de inatividade de aproximadamente um dia, não há problema em tomar uma dependência desta opção para satisfazer os objetivos globais de recuperação de desastres para a sua solução IoT. O tempo total para as operações de tempo de funcionamento ficarem totalmente operacionais uma vez que este processo é desencadeado, é descrito na secção "Tempo para recuperar".

Os únicos utilizadores que podem optar por não participar nesta funcionalidade são os que se deslocam para as regiões do Sul e Sudeste Asiático (Singapura). Para mais informações, consulte Desativar a recuperação de desastres.

Nota

Hub IoT do Azure não armazena ou processa dados de clientes fora da geografia onde implementa a instância de serviço. Para mais informações, consulte a replicação cross-region em Azure.

Ativação pós-falha manual

Se os objetivos de uptime do seu negócio não forem satisfeitos pelo RTO que a Microsoft iniciou a falha fornece, considere usar o failover manual para desencadear o processo de failover. O RTO que usa esta opção pode estar entre 10 minutos e algumas horas. O RTO é atualmente uma função do número de dispositivos registados contra a instância do hub IoT que está a ser chumbada. Você pode esperar que o RTO para um hub que hospeda aproximadamente 100.000 dispositivos esteja no estádio de 15 minutos. O tempo total para as operações de tempo de funcionamento ficarem totalmente operacionais uma vez que este processo é desencadeado, é descrito na secção "Tempo para recuperar".

A opção de failover manual está sempre disponível para utilização, independentemente de a região primária estar ou não a passar por tempo de inatividade. Por conseguinte, esta opção poderia potencialmente ser utilizada para executar falhas planeadas. Um exemplo de utilização de falhas planeadas é a realização de exercícios periódicos de failover. Uma palavra de precaução é, no entanto, que uma operação de failover planeada resulta numa paragem para o hub para o período definido pelo RTO para esta opção, e também resulta numa perda de dados tal como definida pelo quadro de RPO acima. Você poderia considerar a criação de um teste ioT hub instância para exercer periodicamente a opção de failover planeada para ganhar confiança na sua capacidade de colocar as suas soluções de ponta a ponta em funcionamento quando um verdadeiro desastre acontece.

O failover 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, consulte Tutorial: Execute a falha manual para um hub IoT

Failover manual e Centro de Eventos

Como indicado anteriormente na secção Advertência, o nome e ponto final compatíveis com o Event Hub do Hub IoT alteração do ponto final de eventos incorporado após a falha manual. Isto porque o cliente do Event Hub não tem visibilidade para Hub IoT eventos. O mesmo acontece com outros clientes baseados na nuvem, como Functions e Azure Stream Analytics. Para recuperar o ponto final e o nome, pode utilizar o portal do Azure ou alavancar uma amostra incluída.

Utilizar o portal

Para obter mais informações sobre a utilização do portal para recuperar o ponto de final compatível com o Event Hub e o nome compatível com o Event Hub, consulte ler a partir do ponto final incorporado.

Utilize a amostra incluída

Para utilizar o fio de ligação Hub IoT para recapturar o ponto final compatível com o Event Hub, aproveite uma amostra localizada https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs que mostre como utilizar a cadeia de ligação Hub IoT para recapturar o ponto final compatível com o EventHub. O exemplo de código utiliza a cadeia de ligação para obter o novo ponto final do Event Hub e restabelecer a ligação. Deve ter Visual Studio instalado.

Exercícios de teste de execução

Os exercícios de ensaio não devem ser efetuados em centros IoT que estão a ser utilizados nos seus ambientes de produção.

Não use o failover manual para migrar o hub IoT para uma região diferente

O failover manual não deve ser utilizado como um mecanismo para migrar permanentemente o seu hub entre as regiões geo emparelhadas Azure. Ao fazê-lo, aumenta a latência para as operações que estão a ser realizadas contra o hub IoT a partir de dispositivos aoariados na antiga região primária.

Reativação pós-falha

O regresso à antiga região primária pode ser conseguido desencadeando outra vez a ação de incumprimento. Se a operação original de failover foi realizada para recuperar de uma paragem prolongada na região primária original, recomendamos que o hub seja falhado de volta ao local original uma vez que esse local tenha recuperado da situação de paragem.

Importante

  • Os utilizadores só podem realizar 2 falhas bem sucedidas e 2 operações de failback bem sucedidas por dia.

  • Não são permitidas operações de recuo/failback. Tens de esperar 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 o mesmo pós-failover, o endereço IP subjacente altera. Portanto, o tempo geral para as operações de tempo de execução que estão a ser realizadas contra a sua instância do hub IoT para ficar em pleno funcionamento após o processo de failover ser desencadeado pode ser expresso usando a seguinte função.

Tempo para recuperar = RTO [10 min - 2 horas para falha manual | 2 - 26 horas para failover iniciado pela Microsoft] + atraso de propagação de DNS + Tempo tomado pela aplicação do cliente para refrescar qualquer endereço IP Hub IoT em cache.

Importante

Os SDKs IoT não cache o endereço IP do hub IoT. Recomendamos que o código de utilizador que inter-rela contrário com os SDKs não cache o endereço IP do hub IoT.

Desativar a recuperação de desastres

Hub IoT fornece Microsoft-Initiated Failover e Falha Manual replicando dados para a região emparelhada para cada hub IoT. Para algumas regiões, pode evitar a replicação de dados fora da região, desativando a recuperação de desastres ao criar um hub IoT. As seguintes regiões apoiam esta característica:

  • Brasil Sul; região emparelhada, South Central US.
  • Sudeste Asiático (Singapura); região emparelhada, Ásia Oriental (Hong Kong).

Para desativar a recuperação de desastres em regiões apoiadas, certifique-se de que a recuperação de desastres ativada não électada quando criar o seu hub IoT:

Screenshot that shows disaster recovery option for an IoT hub in Singapore region.

Também pode desativar a recuperação de desastres quando criar um hub IoT utilizando um modelo ARM.

A capacidade de falha não estará disponível se desativar a recuperação de desastres para um hub IoT.

Screenshot that shows disaster recovery disabled for an IoT hub in Singapore region.

Você só pode desativar a recuperação de desastres para evitar a replicação de dados fora da região emparelhada no Sul do Brasil ou sudeste asiático quando você criar um hub IoT. Se quiser configurar o seu hub IoT existente para desativar a recuperação de desastres, precisa de criar um novo hub IoT com a recuperação de desastres desativado e migrar manualmente o seu hub IoT existente. Para orientação, veja como clonar uma Hub IoT do Azure para outra região. Este artigo contém conselhos sobre rotas migratórias, pontos finais personalizados e outros artefactos Hub IoT ao migrar para um novo hub. Pode ignorar preocupações que têm a ver com a migração através de regiões.

Alcance a região transversal HA

Se os objetivos de uptime do seu negócio não forem satisfeitos pelo RTO que as opções de failover iniciadas pela Microsoft ou as opções manuais de failover fornecem, deve considerar a implementação de um mecanismo de falha de falha automática por dispositivo. Um tratamento completo das topologias de implantação em soluções IoT está fora do âmbito deste artigo. O artigo discute o modelo regional de implantação de failover com o objetivo de elevada disponibilidade e recuperação de desastres.

Num modelo regional de failover, a solução de back end funciona principalmente num local de datacenter. Um centro de IoT secundário e a parte traseira são implantados em outro local do datacenter. Se o hub IoT na região primária sofrer uma paragem ou a conectividade da rede do dispositivo para a região primária for interrompida, os dispositivos usam um ponto final de serviço secundário. Pode melhorar a disponibilidade da solução implementando um modelo de failover transversal em vez de permanecer numa única região.

A um nível elevado, para implementar um modelo regional de failover com Hub IoT, é necessário dar os seguintes passos:

  • Uma lógica de encaminhamento de ioT secundária e de encaminhamento de dispositivos: Se o serviço na sua região primária for interrompido, os dispositivos devem começar a ligar-se à sua região secundária. Dada a natureza consciente do Estado da maioria dos serviços envolvidos, é comum que os administradores de soluções desencadeiem o processo de failover inter-região. A melhor forma de comunicar o novo ponto final aos dispositivos, mantendo o controlo do processo, é fazê-los verificar regularmente um serviço de concierge para o atual ponto final ativo. O serviço de concierge pode ser uma aplicação web que é replicada e mantida acessível usando técnicas de redirecionamento de DNS (por exemplo, usando Gestor de Tráfego do Azure).

    Nota

    O serviço de hub IoT não é um tipo de ponto final suportado em Gestor de Tráfego do Azure. A recomendação é integrar o serviço de concierge proposto com o gestor de tráfego Azure, tornando-o implementar a sonda de saúde final API.

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

  • Lógica de fusão: Quando a região primária voltar a estar disponível, todo o estado e dados que foram criados no local secundário devem ser migrados de volta para a região primária. Este estado e os dados dizem principalmente respeito às identidades dos dispositivos e metadados de aplicação, que devem ser fundidos com o hub ioT primário e quaisquer outras lojas específicas da aplicação na região primária.

Para simplificar este passo, deve utilizar operações idempotentes. As operações idempotentes minimizam os efeitos secundários da eventual distribuição consistente de eventos, e de duplicados ou entregas fora de ordem de eventos. Além disso, a lógica da aplicação deve ser concebida para tolerar potenciais inconsistências ou estado ligeiramente desatualizado. Esta situação pode ocorrer devido ao tempo adicional que o sistema leva para curar com base em objetivos de ponto de recuperação (RPO).

Escolha a opção HA/DR certa

Aqui está um resumo das opções HA/DR apresentadas neste artigo que podem ser usadas 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 de implementação Impacto adicional dos custos
Falha iniciada pela Microsoft 2 - 26 horas Consulte a tabela RPO acima No Nenhuma Nenhuma
Ativação pós-falha manual 10 min - 2 horas Consulte a tabela RPO acima Yes Muito baixo. Só precisa de ativar esta operação a partir do portal. Nenhuma
Região transversal HA < 1 min Depende da frequência de replicação da sua solução ha personalizada No Alto > 1x o custo de 1 hub IoT

Passos seguintes