Confiabilidade do Azure HDInsight no Serviço de Kubernetes do Azure
Observação
Desativaremos o Microsoft Azure HDInsight no AKS em 31 de janeiro de 2025. Para evitar o encerramento abrupto das suas cargas de trabalho, você precisará migrá-las para o Microsoft Fabric ou para um produto equivalente do Azure antes de 31 de janeiro de 2025. Os clusters restantes em sua assinatura serão interrompidos e removidos do host.
Somente o suporte básico estará disponível até a data de desativação.
Importante
Esse recurso está atualmente na visualização. Os Termos de uso complementares para versões prévias do Microsoft Azure incluem mais termos legais que se aplicam aos recursos do Azure que estão em versão beta, em versão prévia ou ainda não lançados em disponibilidade geral. Para obter informações sobre essa versão prévia específica, confira Informações sobre a versão prévia do Azure HDInsight no AKS. Caso tenha perguntas ou sugestões de recursos, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para ver mais atualizações sobre a Comunidade do Azure HDInsight.
Este artigo descreve o suporte à confiabilidade no Azure HDInsight no AKS (Serviço de Kubernetes do Azure) e a recuperação de desastres e a continuidade dos negócios.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos de datacenters fisicamente separados em cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.
Para obter mais informações sobre zonas de disponibilidade no Azure, confira O que são zonas de disponibilidade?.
O Azure HDInsight no AKS dá suporte à zona de disponibilidade aproveitando a capacidade do Serviço de Kubernetes do Azure de criar pools de nós com redundância de zona. Você pode selecionar quais zonas de disponibilidade implantar o pool de clusters e o cluster durante a criação. Depois que o cluster ou o pool de clusters for criado, você não poderá alterar as zonas de disponibilidade.
Pré-requisitos
As zonas de disponibilidade só têm suporte para versão do pool de cluster >=
1.2e versão do cluster >=1.2.1.O Azure HDInsight no AKS tem apenas um SKU padrão e dá suporte ao AZ, desde que a região do Azure tenha suporte a AZ.
As regiões abaixo não dão suporte ao AZ:
Américas Europa Oriente Médio África Pacífico Asiático Oeste dos EUA Norte da Alemanha Alguns SKUs de VM podem não dar suporte a todas as zonas de disponibilidade em uma região. Se você selecionar esses SKUs, os pools de clusters ou clusters do HDInsight no AKS também não serão compatíveis com as zonas de disponibilidade correspondentes.
Aprimoramentos do SLA
Não há SLAs aumentadas para o Azure HDInsight em clusters do AKS com zonas de disponibilidade habilitadas.
Criar um recurso com a zona de disponibilidade habilitada
Pools de cluster Você pode selecionar uma ou mais zonas de disponibilidade durante a criação do pool de clusters depois de selecionar a região.
Clusters Você pode selecionar uma ou mais zonas de disponibilidade durante a criação do cluster.
Tolerância a falhas
Para se preparar para falhas na zona de disponibilidade, é recomendável provisionar em excesso a capacidade de serviço para garantir que o cluster possa tolerar a perda de capacidade de uma zona de disponibilidade e continuar funcionando sem degradação do desempenho durante interrupções em toda a zona. Por exemplo, se você ativar 3 zonas de disponibilidade, seu cluster deverá tolerar 1/3 dos nós inativos (arredonde para o número inteiro mais próximo).
Experiência de zona inoperante
O Azure HDInsight no serviço AKS é redundante por zona. Durante uma interrupção em toda a zona, o cliente deve esperar degradação do desempenho devido à queda de capacidade. Os clientes ainda podem criar novos pools de clusters e clusters nas zonas de disponibilidade que não são afetadas. Os clusters existentes podem funcionar com capacidade reduzida. Recomendações individuais de cargas de trabalho de código aberto e melhores práticas são fornecidas na documentação.
Recuperação de desastre e continuidade dos negócios
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
O Azure HDInsight no serviço do plano de controle do AKS e os bancos de dados são implantados entre regiões do Azure. Entre essas regiões, as instâncias do Azure HDInsight no AKS e as instâncias de banco de dados ficam isoladas. Quando ocorre uma indisponibilidade no nível da região, uma região fica inoperante. Todos os recursos nessa região, incluindo o RP (Provedor de Recursos) do Azure HDInsight no plano de controle do AKS, o banco de dados do Azure HDInsight no plano de controle do AKS e todos os clusters de clientes nessa região. Nesse caso, tudo o que podemos fazer é aguardar o término da indisponibilidade regional. Quando a interrupção zonal for totalmente recuperada, o Azure HDInsight no serviço AKS estará de volta e todos os clusters de clientes voltarão à normalidade. É possível que você encontre alguns problemas devido à inconsistência de dados após a interrupção e precise de uma correção manual com base nas cargas de trabalho do seu aplicativo.
Recuperação de desastre de várias regiões
Atualmente, o Azure HDInsight no AKS não dá suporte ao failover entre regiões. Melhorar a continuidade dos negócios usando a recuperação de desastre de alta disponibilidade entre regiões requer designs de arquitetura de maior complexidade e mais alto custo. Os clientes podem optar por criar sua própria solução para fazer backup de dados importantes e status do trabalho nas diferentes regiões.
Detecção, notificação e gerenciamento de interrupção
Use as ferramentas de monitoramento do Azure no HDInsight no AKS para detectar qualquer comportamento anormal no cluster e definir as notificações de alerta correspondentes. Você pode habilitar o Log Analytics de várias maneiras e usar o serviço do Prometheus gerenciado com painéis de controle do Grafana no Azure para o monitoramento. Para saber mais, confira Integração do Azure Monitor.
Assine os alertas de integridade do Azure para ser notificado sobre problemas de serviço, manutenção planejada, avisos de integridade e segurança de uma assinatura, serviço ou região. Notificações de integridade que incluem a causa do problema e o ETA determinado ajudam você a executar melhor o failover e os failbacks. Para obter mais informações, confira Gerenciar a integridade do serviço e a documentação de Integridade do Serviço do Azure.
Recuperação de desastre em região única
Atualmente, o Azure HDInsight no AKS tem apenas uma oferta de serviço padrão e os clusters são criados em uma localização geográfica de uma única região. Os clientes são responsáveis pelas configurações de recuperação de desastre com base nos requisitos do aplicativo.
Capacidade e resiliência proativa de recuperação de desastre
O Azure HDInsight no AKS e seus clientes operam sob o Modelo de responsabilidade compartilhada, o que significa que o cliente deve atender aos requisitos de recuperação de desastre para o serviço que implanta e controla. Para garantir que a recuperação seja proativa, os clientes devem sempre implantar recursos secundários previamente porque não há garantia de capacidade no momento do impacto para aqueles que não fizeram a alocação prévia.
Ao contrário do HDInsight, as Máquinas Virtuais usadas no HDInsight em clusters AKS exigem a mesma cota que as VMs do Azure. Para obter mais informações, confira Planejamento da capacidade.
Conteúdo relacionado
Para saber mais sobre os itens discutidos neste artigo, veja: