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

Considere o seguinte ao criar um EMR cluster da Amazon com vários nós primários:

Importante

Para lançar EMR clusters de alta disponibilidade com vários nós primários, é altamente recomendável que você use a EMR versão mais recente da Amazon. 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 EMR 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 da Amazon. Para grupos de instâncias, a alta disponibilidade é suportada nas EMR versões 5.23.0 e superiores da Amazon. Para saber mais, consulte Sobre os EMR lançamentos da Amazon.

• Em clusters de alta disponibilidade, a Amazon EMR só oferece suporte ao lançamento de nós primários com instâncias On Demand. 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, seu EMR cluster falhará.

• Todos os EMR clusters, incluindo clusters de alta disponibilidade, são lançados 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.

• Se você usar Se estiver usando uma função ou política de serviço personalizada ao iniciar um cluster dentro de uma frota de instâncias, poderá adicionar a ec2:DescribeInstanceTypeOfferings permissão para que a Amazon EMR possa filtrar zonas de disponibilidade (AZ) não suportadas. Quando a Amazon EMR filtra as AZs que não oferecem suporte a nenhum tipo de instância de nós primários, a Amazon EMR evita que as inicializações do cluster falhem devido a tipos de instância primária não suportados. Para obter mais informações, consulte Instance type not supported.

• A Amazon EMR não garante alta disponibilidade para aplicativos de código aberto além dos especificados emAplicativos compatíveis em um EMR cluster da Amazon com vários nós primários.

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

• Nas EMR versões 6.x e superiores da Amazon, 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 EMR cluster da Amazon com vários nós primários pode residir somente em uma zona de disponibilidade ou sub-rede. A Amazon EMR não pode substituir um nó primário com falha se a sub-rede for totalmente utilizada ou estiver com excesso de assinaturas no caso de um failover. Para evitar esse cenário, é recomendável que você dedique uma sub-rede inteira a um cluster da AmazonEMR. 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 menor com três ou menos nós principais, dfs.replication parameter defina como pelo menos 2 HDFS para ter DFS replicação suficiente. Para obter mais informações, consulte HDFSconfiguração.

Atenção

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

2. A Amazon não EMR permitirá que os clusters escalem os nós principais abaixodfs.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:

• A Amazon EMR não fornece métricas específicas de aplicativos sobre ou. HDFS 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. Nessa situação, a 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.