Elevada disponibilidade e recuperação após desastre do Hub IoT
Como primeiro passo para implementar uma solução de IoT resiliente, arquitetos, desenvolvedores e proprietários de empresas devem definir as metas de tempo de atividade para as soluções que estão criando. Essas metas podem ser definidas principalmente com base em objetivos de negócios específicos para cada cenário. Nesse contexto, o artigo Orientação Técnica de Continuidade de Negócios do Azure descreve uma estrutura geral para ajudá-lo a pensar sobre continuidade de negócios e recuperação de desastres. O documento Recuperação de desastres e alta disponibilidade para aplicativos do Azure fornece orientação de arquitetura sobre estratégias para aplicativos do Azure alcançarem alta disponibilidade (HA) e recuperação de desastres (DR).
Este artigo discute os recursos de HA e DR oferecidos especificamente pelo serviço Hub IoT. As grandes áreas discutidas neste artigo são:
- HA intrarregional
- DR entre regiões
- Obtenção de HA entre regiões
Dependendo das metas de tempo de atividade definidas para suas soluções de IoT, você deve determinar qual das opções descritas neste artigo melhor se adequa aos seus objetivos de negócios. A incorporação de qualquer uma dessas alternativas de HA/DR em sua solução de IoT requer uma avaliação cuidadosa das compensações entre:
- Nível de resiliência de que necessita
- Complexidade de implementação e manutenção
- Impacto do COGS
HA intrarregional
O serviço Hub IoT fornece HA intrarregião implementando redundâncias em quase todas as camadas do serviço. O SLA publicado pelo serviço IoT Hub é alcançado fazendo uso dessas redundâncias. Nenhum trabalho extra é necessário pelos desenvolvedores de uma solução de IoT para aproveitar esses recursos de HA. Embora o Hub IoT ofereça uma garantia de tempo de atividade razoavelmente alta, falhas transitórias ainda podem ser esperadas, como em qualquer plataforma de computação distribuída. Se você está apenas começando a migrar suas soluções para a nuvem a partir de uma solução local, seu foco precisa mudar da otimização do "tempo médio entre falhas" para o "tempo médio de recuperação". Em outras palavras, falhas transitórias devem ser consideradas normais ao operar com a nuvem na mistura. Padrões de repetição apropriados devem ser incorporados aos componentes que interagem com um aplicativo em nuvem para lidar com falhas transitórias.
Zonas de disponibilidade
O Hub IoT dá suporte a zonas de disponibilidade do Azure. Uma zona de disponibilidade é uma oferta de alta disponibilidade que protege seus aplicativos e dados contra falhas no datacenter. Uma região com suporte de zona de disponibilidade compreende três zonas que suportam essa região. Cada zona fornece um ou mais datacenters, cada um em um local físico exclusivo com energia, resfriamento e rede independentes. Essa configuração fornece replicação e redundância dentro da região.
As zonas de disponibilidade oferecem duas vantagens: resiliência de dados e implantações mais suaves.
A resiliência de dados vem da substituição dos serviços de armazenamento subjacentes por armazenamento suportado por zonas de disponibilidade. A resiliência dos dados é importante para as soluções de IoT porque essas soluções geralmente operam em ambientes complexos, dinâmicos e incertos, onde falhas ou interrupções podem ter consequências significativas. Quer uma solução de IoT suporte um chão de fábrica, ambientes de varejo ou restaurante, sistemas de saúde ou infraestrutura, a disponibilidade e a qualidade dos dados são necessárias para se recuperar de falhas e fornecer serviços confiáveis e consistentes.
Implantações mais suaves vêm da substituição do hardware subjacente do data center por hardware mais recente que suporta zonas de disponibilidade. Essas melhorias de hardware minimizam o impacto no cliente das desconexões e reconexões de dispositivos, bem como de outros tempos de inatividade relacionados à implantação. A equipe de engenharia do Hub IoT implanta várias atualizações em cada hub IoT todos os meses, por motivos de segurança e para fornecer melhorias de recursos. O hardware suportado por zonas de disponibilidade é dividido em 15 domínios de atualização para que cada atualização seja mais suave, com impacto mínimo nos seus fluxos de trabalho. Para obter mais informações sobre domínios de atualização, consulte Conjuntos de disponibilidade.
O suporte da zona de disponibilidade para o Hub IoT é habilitado automaticamente para novos recursos do Hub IoT criados nas seguintes regiões do Azure:
| País/Região | Resiliência de dados | Implantações mais suaves |
|---|---|---|
| Leste da Austrália | 
|
|
| Sul do Brasil |
|
|
| Canadá Central |
|
|
| Índia Central | 
|
|
| E.U.A. Central |
|
|
| E.U.A. Leste |
|
|
| França Central |
|
|
| Alemanha Centro-Oeste |
|
|
| Leste do Japão |
|
|
| Coreia do Sul Central |
|
|
| Europa do Norte |
|
|
| Leste da Noruega |
|
|
| Catar Central |
|
|
| Centro-Sul dos EUA |
|
|
| Sudeste Asiático |
|
|
| Sul do Reino Unido |
|
|
| Europa Ocidental |
|
|
| E.U.A. Oeste 2 |
|
|
| EUA Oeste 3 |
|
|
DR entre regiões
Pode haver algumas situações raras em que um datacenter sofre 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 de HA intrarregião descrita anteriormente pode nem sempre ajudar. O Hub IoT fornece várias soluções para a recuperação dessas interrupções prolongadas.
As opções de recuperação disponíveis para os clientes em tal situação são failover iniciado pela Microsoft e failover manual. A diferença fundamental entre os dois é que a Microsoft inicia o primeiro e o usuário inicia o segundo. Além disso, o failover manual fornece um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) mais baixo 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 seções a seguir. Quando qualquer uma dessas opções para executar failover de um hub IoT de sua região primária é exercida, o hub se torna totalmente funcional na região correspondente do Azure geopareada.
Ambas as opções de failover oferecem os seguintes RPOs (Recovery Point Objetives, objetivos de ponto de recuperação):
| Tipo de dados | RPO (Recovery Point Objetives, objetivos de ponto de recuperação) |
|---|---|
| Registo de identidade | 0-5 minutos de perda de dados |
| Dados gêmeos do dispositivo | 0-5 minutos de perda de dados |
| Mensagensda nuvem para o dispositivo 1 | 0-5 minutos de perda de dados |
| Pai 1 e trabalhos dedispositivo | 0-5 minutos de perda de dados |
| Mensagens do dispositivo para a cloud | Todas as mensagens não lidas são perdidas |
| Mensagens de feedback da nuvem para o dispositivo | Todas as mensagens não lidas são perdidas |
1 As mensagens da nuvem para o dispositivo e os trabalhos pai não são recuperados como parte do failover manual.
Quando a operação de failover para o hub IoT for concluída, espera-se que todas as operações do dispositivo e dos aplicativos back-end continuem funcionando sem a necessidade de uma intervenção manual. Isso significa que as mensagens do dispositivo para a nuvem devem continuar a funcionar e todo o registro do dispositivo está intacto. Os eventos emitidos através da Grelha de Eventos podem ser consumidos através da(s) mesma(s) subscrição(ões) configurada(s) anteriormente, desde que essas subscrições da Grelha de Eventos continuem disponíveis. Nenhuma manipulação adicional é necessária para pontos de extremidade personalizados.
Atenção
- O nome compatível com os Hubs de Eventos e o ponto de extremidade dos eventos internos do Hub IoT mudam após o failover. Ao receber mensagens de telemetria do ponto de extremidade interno usando o cliente de Hubs de Eventos ou o host do processador de eventos, você deve usar a cadeia de conexão do hub IoT para estabelecer a conexão. Isso garante que seus aplicativos back-end continuem a funcionar sem a necessidade de intervenção manual após o failover. Se você usar o nome e o ponto de extremidade compatíveis com o Hub de Eventos em seu aplicativo diretamente, precisará buscar o novo ponto de extremidade compatível com o Hub de Eventos após o failover para continuar as operações. Para obter mais informações, consulte Failover manual e Hub de Eventos.
- Se você usar o Azure Functions ou o Azure Stream Analytics para conectar o ponto de extremidade interno de Eventos, talvez seja necessário executar uma Reinicialização. Isso ocorre porque durante o failover os deslocamentos anteriores não são mais válidos.
- Ao rotear para o armazenamento, recomendamos listar os blobs ou arquivos e, em seguida, iterar sobre eles, para garantir que todos os blobs ou arquivos sejam lidos sem fazer suposições de partição. O intervalo de partições pode mudar durante um failover iniciado pela Microsoft ou failover manual. Você pode usar a API List Blobs para enumerar a lista de blobs ou List ADLS Gen2 API para a lista de arquivos. Para saber mais, consulte Armazenamento do Azure como um ponto de extremidade de roteamento.
Ativação pós-falha iniciada pela Microsoft
O failover iniciado pela Microsoft é exercido pela Microsoft em situações raras para fazer failover de todos os hubs IoT de uma região afetada para a região correspondente emparelhada geograficamente. Este processo é uma opção padrão e não requer intervenção do usuário. A Microsoft reserva-se o direito de determinar quando esta opção será exercida. Esse mecanismo não envolve um consentimento do usuário antes que o hub do usuário seja submetido a failover. O failover iniciado pela Microsoft tem um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de 2 a 26 horas.
O RTO grande ocorre porque a Microsoft deve executar a operação de failover em nome de todos os clientes afetados nessa região. Se você estiver executando uma solução de IoT menos crítica que possa sustentar um tempo de inatividade de aproximadamente um dia, não há problema em depender dessa opção para satisfazer as metas gerais de recuperação de desastres para sua solução de IoT. O tempo total para que as operações de tempo de execução se tornem totalmente operacionais assim que esse processo for acionado é descrito na seção "Tempo de recuperação".
Somente os usuários que implantam hubs IoT nas regiões do Brasil, Sul e Sudeste Asiático (Cingapura) podem optar por não usar esse recurso. Para obter mais informações, consulte Desabilitar a recuperação de desastres.
Nota
O 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, consulte Replicação entre regiões no Azure.
Ativação pós-falha manual
Se as metas de tempo de atividade da sua empresa não forem satisfeitas pelo RTO fornecido pelo failover iniciado pela Microsoft, considere usar o failover manual para acionar o processo de failover você mesmo. O RTO usando essa opção pode ser de 10 minutos a algumas horas. Atualmente, o RTO é uma função do número de dispositivos registrados na instância do hub IoT que está sendo objeto de failover. Você pode esperar que o RTO para um hub que hospeda aproximadamente 100.000 dispositivos esteja no ballpark de 15 minutos. O tempo total para que as operações de tempo de execução se tornem totalmente operacionais assim que esse processo for acionado é descrito na seção "Tempo de recuperação".
A opção de failover manual está sempre disponível para uso, independentemente de a região principal estar enfrentando tempo de inatividade ou não. Portanto, essa opção poderia ser usada para executar failovers planejados. Um exemplo de uso de failovers planejados é executar exercícios periódicos de failover. Uma palavra de cautela, porém, é que uma operação de failover planejada resulta em um tempo de inatividade para o hub pelo período definido pelo RTO para essa opção e também resulta em uma perda de dados, conforme definido pela tabela RPO acima. Você pode considerar configurar uma instância de hub IoT de teste para exercer a opção de failover planejada periodicamente para ganhar confiança em sua capacidade de colocar suas soluções de ponta a ponta em funcionamento quando um desastre real acontece.
O failover manual está disponível sem custo adicional para hubs IoT criados após 18 de maio de 2017
Para obter instruções passo a passo, consulte Tutorial: Executar failover manual para um hub IoT
Failover manual e Hubs de Eventos
O nome compatível com Hubs de Eventos e o ponto de extremidade dos eventos internos do Hub IoT mudam após o failover manual. Isso ocorre porque o cliente dos Hubs de Eventos não tem visibilidade dos eventos do Hub IoT. O mesmo vale para outros clientes baseados em nuvem, como o Functions e o Azure Stream Analytics. Para recuperar o ponto de extremidade e o nome, você pode usar o portal do Azure ou o SDK do .NET.
Utilizar o portal
Para obter mais informações sobre como usar o portal para recuperar o ponto de extremidade compatível com o Hub de Eventos e o nome compatível com o Hub de Eventos, consulte Conectar-se ao ponto de extremidade interno.
Utilizar 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 um exemplo localizado em https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. O exemplo de código usa a cadeia de conexão para obter o novo ponto de extremidade de Hubs de Eventos e restabelecer a conexão. Você deve ter o Visual Studio instalado.
Executar exercícios de teste
Os exercícios de teste não devem ser realizados em hubs IoT que estão sendo usados em seus ambientes de produção.
Não use failover manual para migrar o hub IoT para uma região diferente
O failover manual não deve ser usado como um mecanismo para migrar permanentemente seu hub entre as regiões emparelhadas geográficas do Azure. Supondo que os dispositivos estejam localizados mais próximos da região primária do hub, a latência das operações que estão sendo executadas no hub IoT aumentará quando o hub fizer failover para uma região secundária.
Reativação pós-falha
Você pode fazer failback para a região primária antiga acionando a ação de failover uma segunda vez. Se a operação de failover original foi executada para recuperar de uma interrupção prolongada na região primária original, recomendamos que o hub seja retornado ao local original assim que esse local se recuperar da situação de interrupção.
Importante
- Os usuários só podem executar 2 operações de failover bem-sucedidas e 2 operações de failback bem-sucedidas por dia.
- Não são permitidas operações de failover/failback back back. Tem de aguardar 1 hora entre estas operações.
Tempo para recuperar
Embora o FQDN (e, portanto, a cadeia de conexão) da instância do hub IoT permaneça o mesmo failover de postagem, o endereço IP subjacente é alterado. 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 min - 2 horas para failover manual | 2 - 26 horas para failover iniciado pela Microsoft] + atraso de propagação de DNS + Tempo necessário pelo aplicativo cliente para atualizar qualquer endereço IP do Hub IoT armazenado em cache.
Importante
Os SDKs de IoT não armazenam em cache o endereço IP do hub IoT. Recomendamos que a interface de código do usuário com os SDKs não armazene em cache o endereço IP do hub IoT.
Desativar a recuperação de desastres
O Hub IoT fornece failover iniciado pela Microsoft e failover manual replicando dados para a região emparelhada para cada hub IoT. Para algumas regiões, você pode evitar a replicação de dados fora da região desabilitando a recuperação de desastres ao criar um hub IoT. As seguintes regiões oferecem suporte a esse recurso:
- Brasil Sul; região emparelhada, Centro-Sul dos EUA.
- Sudeste Asiático (Singapura); região emparelhada, Ásia Oriental (RAE de Hong Kong).
Para desativar a recuperação de desastres em regiões suportadas, verifique se a opção Recuperação de desastres habilitada está desmarcada ao criar seu hub IoT:
Você também pode desabilitar a recuperação de desastres ao criar um hub IoT usando um modelo ARM.
O recurso de failover não estará disponível se você desabilitar a recuperação de desastres para um hub IoT.
Você só pode desabilitar a recuperação de desastres para evitar a replicação de dados fora da região emparelhada no Brasil, Sul ou Sudeste Asiático ao criar um hub IoT. Se você quiser configurar seu hub IoT existente para desabilitar a recuperação de desastres, precisará criar um novo hub IoT com recuperação de desastres desabilitada e migrar manualmente seu hub IoT existente. Para obter orientação, consulte Como migrar um hub IoT.
Alcance HA entre regiões
Se as metas de tempo de atividade da sua empresa não forem satisfeitas pelo RTO que as opções de failover iniciado pela Microsoft ou as opções de failover manual fornecem, você deve considerar a implementação de um mecanismo automático de failover entre regiões por dispositivo. Um tratamento completo das topologias de implantação em soluções de IoT está fora do escopo deste artigo. O artigo discute o modelo de implantação de failover regional para alta disponibilidade e recuperação de desastres.
Em um modelo de failover regional, o back-end da solução é executado principalmente em um local de datacenter. Um hub IoT secundário e um back-end são implantados em outro local de datacenter. 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. Você pode melhorar a disponibilidade da solução implementando um modelo de failover entre regiões em vez de permanecer em uma única região.
Em um alto nível, para implementar um modelo de failover regional com o Hub IoT, você precisa executar as seguintes etapas:
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. Dada a natureza consciente do estado da maioria dos serviços envolvidos, é comum que os administradores de soluções acionem o processo de failover entre regiões. A melhor maneira de comunicar o novo endpoint aos dispositivos, mantendo o controle do processo, é fazer com que eles verifiquem regularmente um serviço de concierge para o endpoint ativo atual. O serviço de concierge pode ser um aplicativo Web replicado e acessível usando técnicas de redirecionamento de DNS (por exemplo, usando o Gerenciador de Tráfego do Azure).
Nota
O serviço de hub IoT não é um tipo de ponto de extremidade com suporte no Gerenciador de Tráfego do Azure. A recomendação é integrar o serviço de concierge proposto com o gerenciador de tráfego do Azure, fazendo-o implementar a API de investigação de integridade do ponto de extremidade.
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 dispositivos e carregá-los para o hub IoT secundário antes de alternar o ponto de extremidade ativo para os dispositivos. A funcionalidade de exportação de identidade de dispositivo do Hub IoT é útil neste contexto. Para obter mais informações, consulte Guia do desenvolvedor do Hub IoT - registro de identidade.
Lógica de mesclagem: quando a região primária fica disponível novamente, todos os estados e dados criados no site secundário 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, você deve usar 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. Essa situação pode ocorrer devido ao tempo extra que leva para o sistema se curar com base em RPO (Recovery Point Objetives, objetivos de ponto de recuperação).
Escolha a opção HA/DR certa
Aqui está um resumo das opções de HA/DR apresentadas neste artigo que podem ser usadas como um quadro de referência para escolher a opção certa que funciona para 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 | Consulte a tabela de RPO acima | Não | Nenhuma | Nenhuma |
| Ativação pós-falha manual | 10 min - 2 horas | Consulte a tabela de RPO acima | Sim | Muito baixo. Você só precisa acionar essa 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 | Não | Alto | > 1x o custo de 1 hub IoT |