As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # 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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html). + 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-INSTANCE_TYPE_NOT_SUPPORTED-error.html). + 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](emr-plan-ha-applications.md#emr-plan-ha-applications-list). + 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](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html). **Atenção** 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. 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. 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`, ou`MultiMasterInstanceGroupNodesRequested`. CloudWatch notificará você em caso de falha e substituição do nó primário. + Se `MultiMasterInstanceGroupNodesRunningPercentage` for menor que 100% e maior que 50%, 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 50%, 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html#UsingEMR_ViewingMetrics_Alarm).