Considerações e práticas recomendadas

Considere os seguintes pontos ao criar um cluster do Amazon EMR com vários nós primários:

Importante

Para executar clusters de alta disponibilidade do EMR com vários nós primários, é altamente recomendável usar a versão mais recente do Amazon EMR. Isso garante que você obtenha o mais alto nível de resiliência e estabilidade para os seus clusters de alta disponibilidade.

• A alta disponibilidade, por exemplo, de frotas é suportada pelas versões 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1, 6.12.0 e superiores do Amazon EMR. Nos grupos de instâncias, a alta disponibilidade é compatível com as versões 5.23.0 e superiores do Amazon EMR. Para saber mais, consulte Sobre as versões do Amazon EMR.

• Em clusters de alta disponibilidade, o Amazon EMR só oferece suporte à execução de nós primários com instâncias sob demanda. Isso garante a maior disponibilidade para o seu cluster.

• Você ainda pode especificar vários tipos de instância para a frota primária, mas todos os nós primários de clusters de alta disponibilidade são executados com o mesmo tipo de instância, incluindo substituições de nós primários não íntegros.

• Para continuar as operações, um cluster de alta disponibilidade com vários nós primários exige que dois dos três nós primários estejam íntegros. Como resultado, se dois nós primários falharem simultaneamente, o cluster do EMR falhará.

• Todos os clusters do EMR, incluindo os de alta disponibilidade, são executados em uma única zona de disponibilidade. Portanto, eles não são tolerantes a falhas na zona de disponibilidade. Se houver uma interrupção na zona de disponibilidade, você perde o acesso ao cluster.

• O Amazon EMR não garante alta disponibilidade para aplicações de código aberto que não estejam especificadas em Aplicações compatíveis com um cluster do Amazon EMR com múltiplos nós primários.

• Nas versões 5.23.0 a 5.36.2 do Amazon EMR, somente dois dos três nós principais de um cluster de grupo de instâncias são executados. HDFS NameNode

• Nas versões 6.x e superiores do Amazon EMR, todos os três nós principais de um grupo de instâncias são executados. HDFS NameNode

Considerações para configurar a sub-rede:

• Um cluster do Amazon EMR com múltiplos nós primários pode residir somente em uma zona de disponibilidade ou sub-rede. O Amazon EMR não conseguirá substituir um nó primário com falha se a sub-rede estiver sendo utilizada totalmente ou em excesso no caso de failover. Para evitar esse cenário, é recomendável dedicar uma sub-rede a um cluster do Amazon EMR. Além disso, certifique-se de que há endereços IP privados suficientes disponíveis na sub-rede.

Considerações para configurar nós core:

• Para também garantir a alta disponibilidade dos nós centrais, é recomendável executar pelo menos quatro nós centrais. Se você decidir iniciar um cluster com três nós centrais ou menos, configure dfs.replication parameter como, no mínimo, 2 para o HDFS ter replicação DFS suficiente. Para obter mais informações, consulte HDFS configuration.

Atenção

1. Definir dfs.replication como 1 em clusters com menos de quatro nós poderá causar perda de dados do HDFS se um único nó ficar inativo. É recomendável usar um cluster com pelo menos quatro nós centrais para workloads de produção.

2. O Amazon EMR não permitirá que os clusters escalem os nós principais abaixo de dfs.replication. Por exemplo, se dfs.replication = 2, o número mínimo de nós central será 2.

3. Ao usar o Ajuste de Escala Gerenciado, o Auto Scaling ou optar por redimensionar manualmente o cluster, é recomendável definir dfs.replication como 2 ou mais.

Considerações para configurar alarmes em métricas:

• O Amazon EMR não fornece métricas específicas da aplicação sobre o HDFS ou YARN. É recomendável definir alarmes para monitorar a contagem de instâncias para nós primários. Configure os alarmes usando as seguintes CloudWatch métricas da Amazon:MultiMasterInstanceGroupNodesRunning,MultiMasterInstanceGroupNodesRunningPercentage, ouMultiMasterInstanceGroupNodesRequested. CloudWatch notificará você em caso de falha e substituição do nó primário.

  • Se MultiMasterInstanceGroupNodesRunningPercentage for menor que 1,0 e maior que 0,5, o cluster pode ter perdido um nó primário. Nesse caso, o Amazon EMR tenta substituir um nó primário.

  • Se a MultiMasterInstanceGroupNodesRunningPercentage ficar abaixo de 0,5, dois nós primários podem ter falhado. Nesse caso, o quórum do cluster é perdido e não é possível recuperá-lo. É necessário migrar os dados desse cluster manualmente.

  Para obter mais informações, consulte Setting alarms on metrics.