Confiabilidade no Azure HDInsight
Esse artigo descreve o suporte à confiabilidade do Azure HDInsight e aborda as zonas de disponibilidade e a recuperação entre regiões e a continuidade dos negócios. Para obter uma visão geral mais detalhada da confiabilidade no Azure, confira Confiabilidade do Azure.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
O Azure HDInsight dá suporte a uma configuração de implantação zonal. Os nós de cluster do Azure HDInsight são colocados em uma única zona selecionada na região selecionada. Um cluster do HDInsight zonal é isolado de qualquer interrupção que ocorra em outras zonas. No entanto, se uma interrupção afetar a zona específica escolhida para o cluster do HDInsight, o cluster não estará disponível. Esse modelo de implantação também fornece uma conectividade de rede barata e de baixa latência no cluster. Replicar esse modelo de implantação em várias zonas de disponibilidade pode fornecer um nível mais alto de disponibilidade para proteção contra falhas de hardware.
Importante
Para implantações em que os usuários não especificam uma zona específica, os tipos de nó não são resilientes à zona e podem experimentar tempo de inatividade durante uma interrupção em qualquer zona nessa região.
Pré-requisitos
O recurso de zona de disponibilidade só tem suporte para clusters criados após 15, 2023 de junho. Não é possível atualizar as configurações da zona de disponibilidade depois que o cluster for criado. Você também não pode atualizar um cluster de zona de não disponibilidade existente para usar zonas de disponibilidade.
Os clusters devem ser criados em uma VNet personalizada.
Você precisa trazer seu próprio banco de dados SQL para o Ambari DB e o metastore externo, como o do Hive, para configurar esses bancos de dados na mesma zona de disponibilidade.
Seus clusters HDInsight devem ser criados com a opção de zona de disponibilidade em uma das seguintes regiões:
- Leste da Austrália
- Brazil South
- Canadá Central
- Centro dos EUA
- Leste dos EUA
- Leste dos EUA 2
- França Central
- Centro-Oeste da Alemanha
- Leste do Japão
- Coreia Central
- Norte da Europa
- Catar Central
- Sudeste Asiático
- Centro-Sul dos Estados Unidos
- Sul do Reino Unido
- Gov. dos EUA – Virgínia
- Europa Ocidental
- Oeste dos EUA 2
Criar um cluster do HDInsight usando a zona de disponibilidade
Você pode usar o modelo do Azure Resource Manager (ARM) para iniciar um cluster do HDInsight em uma zona de disponibilidade especificada.
Na seção de recursos, você precisa adicionar uma seção de "zonas" e informar em qual zona de disponibilidade deseja que esse cluster seja implantado.
"resources": [
{
"type": "Microsoft.HDInsight/clusters",
"apiVersion": "2021-06-01",
"name": "[parameters('cluster name')]",
"location": "East US 2",
"zones": [
"1"
],
}
]
Verificar nós de uma zona de disponibilidade entre zonas
Quando o cluster do HDInsight estiver pronto, verifique o local para ver em qual zona de disponibilidade eles estão implantados.
Obtenha a resposta da API:
[
{
"location": "East US 2",
"zones": [
"1"
],
}
]
Aumentar o tamanho do cluster
Você pode aumentar o tamanho de um cluster do HDInsight com mais nós de trabalho. Os novos nós de trabalho adicionados serão colocados na mesma zona de disponibilidade do cluster.
Migração da zona de disponibilidade
Atualmente, os clusters do Azure HDInsight não dão suporte à migração in-loco de instâncias de cluster existentes para o suporte à zona de disponibilidade. No entanto, você pode optar por recriar o cluster e escolher uma zona ou região de disponibilidade diferente durante a criação do cluster. Um cluster em espera secundário em uma região diferente e uma zona de disponibilidade diferente podem ser usados em cenários de recuperação de desastre.
Experiência de zona inoperante
Quando uma zona de disponibilidade fica inoperante:
- Não é possível acessar este cluster via SSH.
- Não é possível excluir ou aumentar/reduzir o tamanho desse cluster.
- Não é possível enviar trabalhos ou ver o histórico de trabalhos.
- Você ainda pode enviar uma nova solicitação de criação de cluster em uma região diferente
Recuperação de desastre entre regiões 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 desastre 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.
Os clusters do Azure HDInsight dependem de muitos serviços do Azure, como armazenamento, bancos de dados, Active Directory, Active Directory Domain Services, rede e Key Vault. Um aplicativo de análise bem projetado, altamente disponível e tolerante a falhas deve ser projetado com redundância suficiente para resistir a interrupções regionais ou locais em um ou mais desses serviços. Esse artigo fornece uma visão geral das práticas recomendadas, disponibilidade de região única e opções de otimização para o planejamento da continuidade de negócios.
Recuperação de desastre na geografia de várias 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. As tabelas a seguir detalham algumas áreas técnicas que podem aumentar o custo total de propriedade.
Otimizações de custo
| Área | Causa do escalonamento de custos | Estratégias de otimização |
|---|---|---|
| Armazenamento de dados | Duplicar dados/tabelas primárias em uma região secundária | Replicar apenas dados coletados |
| Saída de Dados | As transferências de dados entre regiões de saída trazem custos. Revisar as Diretrizes de preços de largura de banda | Replicar apenas dados coletados para reduzir o volume de saída da região |
| Computador de cluster | Cluster(s) adicional(is) do HDInsight na região secundária | Use scripts automatizados para implantar a computação secundária após a falha primária. Use o dimensionamento automático para manter o cluster secundário no tamanho mínimo. Use SKUs de VMs mais baratas. Crie secundários em regiões onde os SKUs de VMs podem vir a ser descontados. |
| Autenticação | Cenários de vários usuários na região secundária incorrerão em configurações extras do Serviço de Domínio do Microsoft Entra | Evite configurações multiusuários na região secundária. |
Otimizações de complexidade
| Área | Causa do escalonamento de complexidade | Estratégias de otimização |
|---|---|---|
| Padrões de leitura e gravação | Exigir que tanto o primário quanto o secundário sejam habilitados para leitura e gravação | Projetar o secundário para ser somente leitura |
| RPO & RTO zero | Exigir perda de dados zero (RPO = 0) e tempo de inatividade zero (RTO = 0) | Projete o RPO e o RTO de maneira a reduzir o número de componentes que precisam de failover. Para obter mais informações sobre RTO e RPO, consulte os objetivos de recuperação. |
| Funcionalidade de negócios | Exigir funcionalidade comercial total do primário no secundário | Avalie se é possível executar no secundário com um subconjunto crítico mínimo da funcionalidade de negócios. |
| Conectividade | Exigir que todos os sistemas upstream e downstream do primário se conectem também ao secundário | Limite a conectividade secundária ao mínimo de um subconjunto crítico. |
Ao criar seu plano de recuperação de desastre de várias regiões, considere as seguintes recomendações:
Determine a funcionalidade de negócios mínima de que você precisa em caso de desastre e o porquê. Por exemplo, avalie se você precisa de funcionalidades de failover para a camada de transformação de dados (mostrada em amarelo) e a camada de serviço de dados (mostrada em azul), ou se você precisa de failover apenas para a camada de serviços de dados.
Segmente seus clusters com base na carga de trabalho, no ciclo de vida de desenvolvimento e nos departamentos. Ter mais clusters reduz as chances de uma única grande falha afetar vários processos de negócios diferentes.
Torne suas regiões secundárias somente leitura. Regiões de failover com recursos tanto de leitura quanto de gravação podem levar a arquiteturas complexas.
Clusters transitórios são mais fáceis de gerenciar quando há um desastre. Projete suas cargas de trabalho de forma que os clusters possam ser desligados e reiniciados e nenhum estado seja mantido em clusters.
Muitas vezes, as cargas de trabalho permanecem inacabadas se houver um desastre e precisam ser reiniciadas na nova região. Projete suas cargas de trabalho para serem idempotentes por natureza.
Use a automação durante implantações de cluster e certifique-se de que as definições de configuração de cluster tenham o máximo de detalhes em script para garantir uma implantação rápida e totalmente automatizada em caso de desastre.
Detecção, notificação e gerenciamento de interrupção
Use as ferramentas de monitoramento do Azure no HDInsight para detectar comportamento anormal no cluster e definir notificações de alerta correspondentes. Você pode implantar as soluções de gerenciamento pré-configuradas específicas do cluster no HDInsight para coletarem métricas de desempenho importantes de tipos de cluster específico. Para saber mais, veja Monitoramento do Azure para o HDInsight.
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, consulte a Documentação da Integridade do Serviço do Azure.
Recuperação de desastre na geografia de região única
Cada componente em um sistema HDInsight básico tem seus próprios mecanismos de tolerância a falhas de região única. Nem sempre é preciso um evento catastrófico para afetar a funcionalidade dos negócios. Os incidentes de serviço em um ou mais dos seguintes serviços em uma única região também podem levar à perda da funcionalidade de negócios esperada.
Computação (máquinas virtuais): cluster do Azure HDInsight. O HDInsight oferece um SLA de disponibilidade de 99,9%. Para fornecer alta disponibilidade em uma única implantação, o HDInsight é acompanhado por muitos serviços que estão no modo de alta disponibilidade por padrão. Os mecanismos de tolerância a falhas no HDInsight são fornecidos pelos serviços de alta disponibilidade do ecossistema do Apache OSS e da Microsoft.
Os seguintes componentes de infraestrutura foram projetados para serem altamente disponíveis:
- Nós de cabeçalho ativos e em espera
- Vários nós de gateway
- Três nós de quorum do Zookeeper
- Nós de trabalho distribuídos por domínios de falha e de atualização
Os seguintes serviços foram projetados para serem altamente disponíveis:
- Servidor Apache Ambari
- Servidores de linha do tempo de aplicativo para o YARN
- Servidor de histórico de trabalho para o MapReduce do Hadoop
- Apache Livy
- HDFS
- YARN Resource Manager
- HBase Master
Para mais informações, consulte Serviços de alta disponibilidade com suporte do Azure HDInsight.
Metastore(s): Banco de Dados SQL do Azure. O HDInsight usa o Banco de Dados SQL do Azure como um metastore, que fornece um SLA de 99,99%. Três réplicas de dados persistem em um data center com replicação síncrona. Se houver uma perda de réplica, uma réplica alternativa será servida sem interrupções. A replicação geográfica ativa tem suporte pronto para uso com um máximo de quatro data centers. Quando houver um failover, seja manual ou no data center, a primeira réplica na hierarquia se tornará automaticamente compatível com leitura e gravação. Para saber mais, confira a Continuidade de negócios do Banco de Dados SQL do Azure.
Armazenamento: Azure Data Lake Gen2 ou Armazenamento de Blobs O HDInsight recomenda o uso do Azure Data Lake Storage Gen2 como a camada de armazenamento subjacente. O Armazenamento do Microsoft Azure, incluindo o Azure Data Lake Storage Gen2, fornece um SLA de 99,9%. O HDInsight usa o serviço LRS no qual três réplicas de dados persistem dentro de um data center e a replicação é síncrona. Se houver uma perda de réplica, uma réplica será servida sem interrupções.
Autenticação: Microsoft Entra ID, Microsoft Entra Domain Services, Enterprise Security Package.
- O Microsoft Entra ID fornece um SLA de 99,9%. O Active Directory é um serviço global com vários níveis de redundância interna e capacidade de recuperação automática. Para mais informações, consulte como a Microsoft está continuamente aprimorando a confiabilidade do Microsoft Entra ID.
- O Microsoft Entra Domain Services fornece um SLA de 99,9%. O Microsoft Entra Domain Services é um serviço altamente disponível hospedado em data centers distribuídos globalmente. Os conjuntos de réplicas são uma versão prévia do recurso do Microsoft Entra Domain Services que habilita a recuperação geográfica de desastre caso uma região do Azure fique offline. Para saber mais, consulte Conceitos e recursos dos conjuntos de réplicas do Microsoft Entra Domain Services.
- O DNS do Azure fornece um SLA de 100%. O HDInsight usa o DNS do Azure em vários locais para resolução de nomes de domínio.
Serviços opcionais, como o Azure Key Vault e o Azure Data Factory.
