Confiabilidade no Azure HDInsight no Serviço Kubernetes do Azure
Nota
Vamos desativar o Azure HDInsight no AKS em 31 de janeiro de 2025. Antes de 31 de janeiro de 2025, você precisará migrar suas cargas de trabalho para o Microsoft Fabric ou um produto equivalente do Azure para evitar o encerramento abrupto de suas cargas de trabalho. Os clusters restantes na sua subscrição serão interrompidos e removidos do anfitrião.
Apenas o apoio básico estará disponível até à data da reforma.
Importante
Esta funcionalidade está atualmente em pré-visualização. Os Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure incluem mais termos legais que se aplicam a funcionalidades do Azure que estão em versão beta, em pré-visualização ou ainda não disponibilizadas para disponibilidade geral. Para obter informações sobre essa visualização específica, consulte Informações de visualização do Azure HDInsight no AKS. Para perguntas ou sugestões de recursos, envie uma solicitação no AskHDInsight com os detalhes e siga-nos para obter mais atualizações na Comunidade do Azure HDInsight.
Este artigo descreve o suporte de confiabilidade no Azure HDInsight no Serviço Kubernetes do Azure (AKS), recuperação de desastres e continuidade de negócios.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de 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, consulte O que são zonas de disponibilidade?.
O Azure HDInsight no AKS dá suporte à zona de disponibilidade aproveitando a capacidade do Serviço Kubernetes do Azure de criar pools de nós redundantes de zona. Você pode selecionar quais zonas de disponibilidade implantar o pool de clusters e o cluster durante sua criação. Depois que o pool de clusters ou cluster for criado, não será possível alterar as zonas de disponibilidade.
Pré-requisitos
As zonas de disponibilidade só são suportadas para a versão >do pool de clusters =
1.2e a versão >do cluster =1.2.1.O Azure HDInsight no AKS tem apenas uma SKU padrão e dá suporte a AZ, desde que a região do Azure tenha suporte a AZ.
As regiões abaixo não suportam AZ:
Américas Europa Médio Oriente África Ásia-Pacífico E.U.A. Oeste Norte da Alemanha Algumas SKUs de VM podem não suportar todas as zonas de disponibilidade em uma região. Se você selecionar essas SKUs, o HDInsight em pools de clusters ou clusters AKS também não suportará as zonas de disponibilidade correspondentes.
Melhorias no SLA
Não há SLAs aumentados para o Azure HDInsight em clusters AKS com zonas de disponibilidade habilitadas.
Criar um recurso com a zona de disponibilidade ativada
Pools de clusters 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 excessivamente a capacidade de serviço para garantir que seu cluster possa tolerar a perda de capacidade de uma zona de disponibilidade para baixo e continuar a funcionar sem desempenho degradado durante interrupções em toda a zona. Por exemplo, se você habilitar 3 zonas de disponibilidade, seu cluster deverá tolerar 1/3 dos nós para baixo (arredondar para cima para o número inteiro mais próximo).
Experiência de zoneamento
O serviço Azure HDInsight no AKS é redundante de 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 afetados. Os clusters existentes podem funcionar com capacidade reduzida. Cargas de trabalho de código aberto, recomendações e práticas recomendadas individuais são fornecidas na documentação.
Recuperação após desastre e continuidade de negócio
A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para 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 plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.
O serviço de plano de controle do Azure HDInsight no AKS e os bancos de dados são implantados em regiões do Azure. Entre essas regiões, o Azure HDInsight em instâncias AKS e instâncias de banco de dados são isoladas. Quando ocorre uma interrupção a nível de região, uma região está inativa. Todos os recursos nesta região, incluindo o RP (Provedor de Recursos) do Azure HDInsight no plano de controle AKS, o banco de dados do Azure HDInsight no plano de controle AKS e todos os clusters de clientes nessa região. Neste caso, só podemos esperar que a interrupção regional termine. Quando a interrupção zonal é totalmente recuperada, o serviço Azure HDInsight no AKS está de volta e todos os clusters de clientes voltam à 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 desastres em várias regiões
Atualmente, o Azure HDInsight no AKS não oferece suporte a failover entre regiões. Melhorar a continuidade de negócios usando a recuperação de desastres de alta disponibilidade entre regiões requer projetos arquitetônicos de maior complexidade e maior custo. Os clientes podem optar por projetar sua própria solução para fazer backup de dados importantes e status do trabalho em diferentes regiões.
Deteção, notificação e gerenciamento de interrupções
Use as ferramentas de monitoramento do Azure no HDInsight no AKS para detetar comportamentos anormais 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 Prometheus gerenciado com painéis do Azure Grafana para monitoramento. Para obter mais informações, consulte 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. As notificações de integridade que incluem a causa do problema e o ETA resoluto ajudam você a executar melhor o failover e os failbacks. Para obter mais informações, consulte Gerenciar a integridade do serviço e a documentação do Azure Service Health.
Recuperação de desastres em uma única região
Atualmente, o Azure HDInsight no AKS tem apenas uma oferta de serviço padrão e os clusters são criados em uma geografia de região única. Os clientes são responsáveis pelas configurações de recuperação do diáster com base nos requisitos do aplicativo.
Capacidade e resiliência proativa de recuperação de desastres
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 desastres para o serviço que implanta e controla. Para garantir que a recuperação seja proativa, os clientes devem sempre pré-implantar secundários, pois não há garantia de capacidade no momento do impacto para aqueles que não foram pré-alocados.
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, consulte Planejamento de capacidade.
Conteúdos relacionados
Para saber mais sobre os itens discutidos neste artigo, consulte: