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

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

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

importante

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

  • La alta disponibilidad para flotas de instancias es compatible a partir de las versiones 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1 y 6.12.0 y posteriores de Amazon EMR. Para grupos de instancias, la alta disponibilidad es compatible a partir de la versión 5.23.0 de Amazon EMR. Para obtener más información, consulte Acerca de las versiones de Amazon EMR.

  • En los clústeres de alta disponibilidad, Amazon EMR solo admite el lanzamiento de nodos principales con instancias bajo demanda. 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 dejan de funcionar de manera simultánea, se producirá un error en el clúster de EMR.

  • Todos los clústeres de EMR, incluidos los clústeres 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 utiliza un rol o una política de servicio personalizados al lanzar un clúster dentro de una flota de instancias, puede añadir el permiso ec2:DescribeInstanceTypeOfferings para que Amazon EMR pueda filtrar las zonas de disponibilidad (AZ) no compatibles. Cuando Amazon EMR filtra las AZ que no admiten ningún tipo de instancia de nodos principales, 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, consulte Tipos de instancias no admitidos.

  • Amazon EMR no garantiza la alta disponibilidad de aplicaciones de código abierto distintas de las especificadas en Aplicaciones admitidas en un clúster de Amazon EMR con varios nodos principales.

  • En las versiones desde la 5.23.0 hasta la 5.36.2 de Amazon EMR, solo dos de los tres nodos principales para un clúster de grupos de instancias ejecutan HDFS NameNode.

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

Consideraciones para la configuración la subred:

  • Un clúster de Amazon EMR con varios nodos principales solo puede residir en una zona de disponibilidad o subred. Amazon EMR no puede sustituir un nodo principal que ha dejado de funcionar si la subred se utiliza en su totalidad o por encima de su capacidad en caso de que se produzca una conmutación por error. Para evitar esta situación, se recomienda que dedique una subred completa a un clúster de Amazon EMR. 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 básicos, configure dfs.replication parameter para un mínimo de 2 a fin de que HDFS tenga suficiente replicación DFS. Para más información, consulte Configuración de HDFS.

aviso

  1. Establecer dfs.replication en 1 en clústeres con menos de cuatro nodos puede conllevar la pérdida de datos del HDFS 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 EMR no permitirá que los clústeres escalen los nodos principales por debajo de dfs.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 métricas específicas para las aplicaciones relacionadas con HDFS o YARN. Se recomienda que configure alarmas para monitorizar el recuento de instancias del nodo principal. Configure las alarmas utilizando las siguientes métricas de Amazon CloudWatch: MultiMasterInstanceGroupNodesRunning, MultiMasterInstanceGroupNodesRunningPercentage o MultiMasterInstanceGroupNodesRequested. CloudWatch le notificará en el caso de que un nodo principal deje de funcionar y sea sustituido.

    • 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 intentará sustituir 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.