Considerações e práticas recomendadas ao criar um cluster do Amazon EMR com vários nós primários - Amazon EMR

Considerações e práticas recomendadas ao criar um cluster do Amazon EMR com vários nós primários

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 para frotas de instâncias é compatível com as 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.

  • Caso esteja usando uma política ou perfil de serviço personalizados ao iniciar um cluster dentro de uma frota de instâncias, poderá adicionar a permissão ec2:DescribeInstanceTypeOfferings para que o Amazon EMR filtre zonas de disponibilidade (AZ) sem suporte. Quando o Amazon EMR filtra as AZs que não oferecem suporte a nenhum tipo de instância de nós primários, o Amazon EMR evita que as inicializações de cluster falhem devido a tipos de instância primária não compatíveis. Para obter mais informações, consulte Instance type not supported.

  • 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 primários de um cluster de grupos de instâncias executam o HDFS NameNode.

  • Nas versões 6.x e superiores do Amazon EMR, todos os três nós primários de um grupo de instâncias executam 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 métricas do Amazon CloudWatch: MultiMasterInstanceGroupNodesRunning, MultiMasterInstanceGroupNodesRunningPercentage ou MultiMasterInstanceGroupNodesRequested. O 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.