Consideraciones y prácticas recomendadas al crear un EMR clúster de Amazon con varios nodos principales

Tenga en cuenta lo siguiente cuando cree un EMR clúster de Amazon con varios nodos principales:

importante

Para lanzar EMR clústeres de alta disponibilidad con varios nodos principales, te recomendamos encarecidamente que utilices la última EMR versión de Amazon. Esto garantiza que obtenga el nivel más alto de resiliencia y estabilidad para sus clústeres de alta disponibilidad.

• La alta disponibilidad, por ejemplo, las flotas, es compatible con las EMR versiones 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1, 6.12.0 y superiores de Amazon. Por ejemplo, los grupos, la alta disponibilidad es compatible con las EMR versiones 5.23.0 y posteriores de Amazon. Para obtener más información, consulta Acerca de Amazon EMR Releases.

• En los clústeres de alta disponibilidad, Amazon EMR solo admite el lanzamiento de nodos principales con instancias On Demand. Esto garantiza la máxima disponibilidad de su clúster.

• Puede seguir especificando varios tipos de instancias para la flota principal, pero todos los nodos principales de los clústeres de alta disponibilidad se lanzan con el mismo tipo de instancia, incluidas las sustituciones de los nodos principales en mal estado.

• Para continuar funcionando, un clúster de alta disponibilidad con varios nodos principales requiere que dos de cada tres nodos principales estén en buen estado. Como resultado, si dos nodos principales fallan simultáneamente, el EMR clúster fallará.

• Todos los EMR clústeres, incluidos los de alta disponibilidad, se lanzan en una única zona de disponibilidad. Por lo tanto, no toleran errores de zonas de disponibilidad. En el caso de que deje de funcionar una zona de disponibilidad, se perderá el acceso al clúster.

• Si utilizas un rol o una política de servicio personalizados al lanzar un clúster dentro de una flota de instancias, puedes añadir el ec2:DescribeInstanceTypeOfferings permiso para que Amazon EMR pueda filtrar las zonas de disponibilidad (AZ) no compatibles. Cuando Amazon EMR filtra los nodos principales AZs que no admiten ningún tipo de instancia, Amazon EMR evita que los lanzamientos de clústeres fallen debido a que los tipos de instancias principales no son compatibles. Para obtener más información, consulta el artículo Tipo de instancia no compatible.

• Amazon EMR no garantiza la alta disponibilidad de las aplicaciones de código abierto distintas de las especificadas enAplicaciones compatibles en un Amazon EMR Cluster con varios nodos principales.

• En las EMR versiones 5.23.0 a 5.36.2 de Amazon, solo se ejecutan dos de los tres nodos principales de un clúster de grupo de instancias HDFS NameNode.

• En las EMR versiones 6.x y posteriores de Amazon, los tres nodos principales de un grupo de instancias se ejecutan HDFS NameNode.

Consideraciones para la configuración la subred:

• Un EMR clúster de Amazon con varios nodos principales solo puede residir en una zona de disponibilidad o subred. Amazon EMR no puede reemplazar un nodo principal defectuoso si la subred se utiliza por completo o tiene un exceso de suscripciones en caso de una conmutación por error. Para evitar este escenario, se recomienda dedicar una subred completa a un EMR clúster de Amazon. Además, debe asegurarse de que haya suficientes direcciones IP privadas disponibles en la subred.

Consideraciones para configurar los nodos principales:

• Para garantizar que los nodos centrales también tengan un alto nivel de disponibilidad, le recomendamos que lance al menos cuatro nodos centrales. Si decide lanzar un clúster más pequeño con tres o menos nodos principales, configúrelo como mínimo dfs.replication parameter 2 HDFS para que haya suficiente DFS replicación. Para obtener más información, consulte HDFSla configuración.

aviso

1. Si dfs.replication se establece en 1 en los clústeres con menos de cuatro nodos, se pueden perder HDFS datos si un solo nodo deja de funcionar. Se recomienda que utilice un clúster con al menos cuatro nodos principales para las cargas de trabajo de producción.

2. Amazon no EMR permitirá que los clústeres escalen los nodos principales a continuacióndfs.replication. Por ejemplo, si dfs.replication = 2, el número mínimo de nodos principales es 2.

3. Cuando utiliza el escalado administrado, el escalado automático o decide cambiar el tamaño del clúster manualmente, se recomienda que establezca dfs.replication en 2 o más.

Consideraciones para configurar alarmas de métricas:

• Amazon EMR no proporciona estadísticas específicas de la aplicación sobre HDFS o. YARN Se recomienda que configure alarmas para monitorizar el recuento de instancias del nodo principal. Configura las alarmas con las siguientes CloudWatch métricas de Amazon: MultiMasterInstanceGroupNodesRunningMultiMasterInstanceGroupNodesRunningPercentage, oMultiMasterInstanceGroupNodesRequested. CloudWatch le notificará en caso de que el nodo principal falle o lo reemplace.

  • Si el MultiMasterInstanceGroupNodesRunningPercentage es inferior a 1,0 y superior a 0,5, es posible que el clúster haya perdido un nodo principal. En esta situación, Amazon EMR intenta reemplazar un nodo principal.

  • Si el MultiMasterInstanceGroupNodesRunningPercentage cae por debajo de 0,5, es posible que hayan dejado de funcionar dos nodos principales. En esta situación, se pierde el cuórum y el clúster no se puede recuperar. Debe migrar manualmente los datos de este clúster.

  Para más información, consulte Configuración de alarmas en métricas.