Serviços de alta disponibilidade suportados pelo Azure HDInsight
Para fornecer níveis ideais de disponibilidade para seus componentes de análise, o HDInsight foi desenvolvido com uma arquitetura exclusiva para garantir alta disponibilidade (HA) de serviços críticos. A Microsoft desenvolveu alguns componentes dessa arquitetura para fornecer failover automático. Outros componentes são componentes Apache padrão que são implantados para suportar serviços específicos. Este artigo explica a arquitetura do modelo de serviço de HA no HDInsight, como o HDInsight oferece suporte a failover para serviços de HA e as práticas recomendadas para recuperar de outras interrupções de serviço.
Nota
Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.
Infraestrutura de alta disponibilidade
O HDInsight fornece infraestrutura personalizada para garantir que quatro serviços principais sejam de alta disponibilidade com recursos de failover automático:
- Servidor Apache Ambari
- Servidor de linha do tempo do aplicativo para Apache YARN
- Servidor de histórico de trabalho para Hadoop MapReduce
- Apache Lívio
Esta infraestrutura consiste em muitos serviços e componentes de software, alguns dos quais são projetados pela Microsoft. Os seguintes componentes são exclusivos da plataforma HDInsight:
- Controlador de failover escravo
- Controlador mestre de failover
- Serviço de alta disponibilidade escravo
- Dominar o serviço de alta disponibilidade
Há também outros serviços de alta disponibilidade, que são suportados por componentes de confiabilidade Apache de código aberto. Esses componentes também estão presentes nos clusters HDInsight:
- Hadoop File System (HDFS) NameNode
- Gestor de Recursos YARN
- Mestre HBase
As seções a seguir fornecem mais detalhes sobre como esses serviços funcionam juntos.
Serviços de alta disponibilidade do HDInsight
A Microsoft fornece suporte para os quatro serviços Apache na tabela a seguir em clusters HDInsight. Para distingui-los dos serviços de alta disponibilidade suportados por componentes do Apache, eles são chamados de serviços HA do HDInsight.
| Serviço | Nós do cluster | Tipos de cluster | Propósito |
|---|---|---|---|
| Servidor Apache Ambari | Nó de cabeça ativo | Todos | Monitora e gerencia o cluster. |
| Servidor de linha do tempo do aplicativo para Apache YARN | Nó de cabeça ativo | Todos, exceto Kafka | Mantém informações de depuração sobre trabalhos YARN em execução no cluster. |
| Servidor de histórico de trabalho para Hadoop MapReduce | Nó de cabeça ativo | Todos, exceto Kafka | Mantém dados de depuração para trabalhos do MapReduce. |
| Apache Lívio | Nó de cabeça ativo | Spark | Permite uma interação fácil com um cluster Spark através de uma interface REST |
Nota
Atualmente, os clusters do HDInsight Enterprise Security Package (ESP) fornecem apenas a alta disponibilidade do servidor Ambari. O Application Timeline Server, o Job History Server e o Livy estão sendo executados apenas em headnode0 e não fazem failover para headnode1 quando o Ambari failover. O banco de dados de linha do tempo do aplicativo também está no headnode0 e não no servidor Ambari SQL.
Arquitetura
Cada cluster HDInsight tem dois nós principais nos modos ativo e de espera, respectivamente. Os serviços HA do HDInsight são executados apenas em nós principais. Esses serviços devem estar sempre em execução no headnode, e parados e colocados em modo de manutenção no headnode.
Para manter os estados corretos dos serviços de HA e fornecer um failover rápido, o HDInsight utiliza o Apache ZooKeeper, que é um serviço de coordenação para aplicativos distribuídos, para conduzir a eleição ativa de headnode. O HDInsight também provisiona alguns processos Java em segundo plano, que coordenam o procedimento de failover para serviços HA do HDInsight. Esses serviços são: o controlador de failover mestre, o controlador de failover escravo, o master-ha-service e o slave-ha-service.
Apache ZooKeeper
O Apache ZooKeeper é um serviço de coordenação de alto desempenho para aplicações distribuídas. Na produção, o ZooKeeper geralmente é executado no modo replicado, onde um grupo replicado de servidor do ZooKeeper forma um quórum. Cada cluster HDInsight tem três nós do ZooKeeper que permitem que três servidores do ZooKeeper formem um quórum. O HDInsight tem dois quóruns do ZooKeeper funcionando em paralelo um com o outro. Um quórum decide o nó principal ativo em um cluster no qual os serviços HA do HDInsight devem ser executados. Outro quórum é usado para coordenar os serviços de HA fornecidos pelo Apache, conforme detalhado nas seções posteriores.
Controlador de failover escravo
O controlador de failover escravo é executado em cada nó de um cluster HDInsight. Este controlador é responsável por iniciar o agente Ambari e slave-ha-service em cada nó. Ele consulta periodicamente o primeiro quórum do ZooKeeper sobre o headnode ativo. Quando os nós principais ativos e em espera mudam, o controlador de failover escravo executa as seguintes etapas:
- Atualiza o arquivo de configuração do host.
- Reinicia o agente Ambari.
O slave-ha-service é responsável por interromper os serviços HA do HDInsight (exceto o servidor Ambari) no headnode.
Controlador mestre de failover
Um controlador mestre de failover é executado em ambos os nós principais. Ambos os controladores mestre de failover se comunicam com o primeiro quórum do ZooKeeper para nomear o nó principal em que estão sendo executados como o nó principal ativo.
Por exemplo, se o controlador mestre de failover no nó principal 0 vencer a eleição, as seguintes alterações ocorrerão:
- O nó de cabeça 0 torna-se ativo.
- O controlador mestre de failover inicia o servidor Ambari e o master-ha-service no headnode 0.
- O outro controlador mestre de failover para o servidor Ambari e o master-ha-service no headnode 1.
O master-ha-service só é executado no headnode, ele para os serviços HA do HDInsight (exceto o servidor Ambari) no headnode standby e os inicia no headnode ativo.
O processo de failover
Um monitor de integridade é executado em cada nó principal junto com o controlador mestre de failover para enviar notificações de pulsação para o quórum do Zookeeper. O nó principal é considerado como um serviço HA neste cenário. O monitor de integridade verifica se cada serviço de alta disponibilidade está saudável e se está pronto para participar da eleição de liderança. Se sim, este headnode disputa a eleição. Caso contrário, abandona a eleição até ficar pronto novamente.
Se o nó principal em espera alcançar a liderança e se tornar ativo (como no caso de uma falha com o nó ativo anterior), seu controlador mestre de failover iniciará todos os serviços HA do HDInsight nele. O controlador mestre de failover interrompe esses serviços no outro nó principal.
Para falhas de serviço HA do HDInsight, como um serviço inativo ou não íntegro, o controlador mestre de failover deve reiniciar ou interromper automaticamente os serviços de acordo com o status do nó principal. Os usuários não devem iniciar manualmente os serviços HA do HDInsight em ambos os nós principais. Em vez disso, permita o failover automático ou manual para ajudar na recuperação do serviço.
Intervenção manual inadvertida
Os serviços de HA do HDInsight só devem ser executados no nó principal ativo e são reiniciados automaticamente quando necessário. Como os serviços de HA individuais não têm seu próprio monitor de integridade, o failover não pode ser acionado no nível do serviço individual. O failover é garantido no nível do nó e não no nível do serviço.
Alguns problemas conhecidos
Ao iniciar manualmente um serviço HA no headnode, ele não será interrompido até que o próximo failover aconteça. Quando os serviços HA estão sendo executados em ambos os headnodes, alguns problemas potenciais incluem: Ambari UI está inacessível, Ambari lança erros, YARN, Spark e trabalhos Oozie podem ficar presos.
Quando um serviço HA no headnode ativo para, ele não será reiniciado até que o próximo failover aconteça ou o controlador mestre de failover/master-ha-service seja reiniciado. Quando um ou mais serviços HA param no headnode, especialmente quando o servidor Ambari para, a interface do usuário do Ambari fica inacessível, outros problemas potenciais incluem falhas de trabalhos YARN, Spark e Oozie.
Serviços de alta disponibilidade Apache
O Apache fornece alta disponibilidade para HDFS NameNode, YARN ResourceManager e HBase Master, que também estão disponíveis em clusters HDInsight. Ao contrário dos serviços HA do HDInsight, eles são suportados em clusters ESP. Os serviços Apache HA se comunicam com o segundo quórum do ZooKeeper (descrito na seção acima) para eleger estados ativos/em espera e realizar failover automático. As seções a seguir detalham como esses serviços funcionam.
Hadoop Distributed File System (HDFS) NameNode
Os clusters HDInsight baseados no Apache Hadoop 2.0 ou superior fornecem alta disponibilidade NameNode. Há dois NameNodes em execução nos headnodes, que são configurados para failover automático. Os NameNodes usam o ZKFailoverController para se comunicar com o Zookeeper para eleger o status ativo/em espera. O ZKFailoverController é executado em ambos os nós principais e funciona da mesma maneira que o controlador mestre de failover.
O segundo quórum do Zookeeper é independente do primeiro quórum, portanto, o NameNode ativo pode não ser executado no nó principal ativo. Quando o NameNode ativo está morto ou insalubre, o NameNode em standby ganha a eleição e torna-se ativo.
Gestor de Recursos YARN
Os clusters HDInsight baseados no Apache Hadoop 2.4 ou superior suportam alta disponibilidade do YARN ResourceManager. Há dois ResourceManagers, rm1 e rm2, rodando no headnode 0 e headnode 1, respectivamente. Como NameNode, o YARN ResourceManager também está configurado para failover automático. Outro ResourceManager é automaticamente eleito para estar ativo quando o ResourceManager ativo atual fica inativo ou deixa de responder.
O YARN ResourceManager usa seu ActiveStandbyElector incorporado como um detetor de falhas e eleitor líder. Ao contrário do HDFS NameNode, o YARN ResourceManager não precisa de um daemon ZKFC separado. O ResourceManager ativo grava seus estados no Apache Zookeeper.
A alta disponibilidade do YARN ResourceManager é independente do NameNode e de outros serviços HA do HDInsight. O ResourceManager ativo não pode ser executado no headnode ativo ou no headnode onde o NameNode ativo está sendo executado. Para obter mais informações sobre a alta disponibilidade do YARN ResourceManager, consulte Alta disponibilidade do ResourceManager.
Mestre HBase
Os clusters HBase do HDInsight suportam alta disponibilidade do HBase Master. Ao contrário de outros serviços HA, que são executados em headnodes, o HBase Masters é executado nos três nós do Zookeeper, onde um deles é o mestre ativo e os outros dois estão em espera. Como NameNode, o HBase Master coordena com o Apache Zookeeper para a eleição do líder e faz failover automático quando o mestre ativo atual tem problemas. Existe apenas um HBase Master ativo em qualquer altura.