Características que admiten la alta disponibilidad y cómo funcionan con las aplicaciones de código abierto

En este tema se proporciona información sobre las funciones de alta disponibilidad de Hadoop de HDFS NameNode y dentro de YARN ResourceManager un EMR clúster de Amazon, y sobre cómo funcionan las funciones de alta disponibilidad con las aplicaciones de código abierto y otras funciones de Amazon. EMR

Alta disponibilidad HDFS

Un EMR clúster de Amazon con varios nodos principales permite HDFS NameNode función de alta disponibilidad en Hadoop. Para obtener más información, consulte HDFSalta disponibilidad.

En un EMR clúster de Amazon, dos o más nodos independientes se configuran como NameNodes. Uno NameNode está en un active estado y los demás están en un standby estado. Si se produce un active NameNode error en el nodo, Amazon EMR inicia un proceso de HDFS conmutación por error automático. Un nodo que standby NameNode pasa a ser el encargado de todas las operaciones del cliente en el clúster active y se hace cargo de ellas. Amazon EMR reemplaza el nodo fallido por uno nuevo, que luego se vuelve a unir comostandby.

nota

En EMR las versiones 5.23.0 y 5.30.1 de Amazon, solo se ejecutan dos de los tres nodos principales. HDFS NameNode

Si necesita averiguar cuál NameNode esactive, puede usarlo SSH para conectarse a cualquier nodo principal del clúster y ejecutar el siguiente comando:

hdfs haadmin -getAllServiceState

El resultado muestra los nodos en los que NameNode está instalado y su estado. Por ejemplo:

ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby

Alta disponibilidad YARN ResourceManager

Un EMR clúster de Amazon con varios nodos principales habilita la función YARN ResourceManager de alta disponibilidad en Hadoop. Para obtener más información, consulte ResourceManager Alta disponibilidad.

En un EMR clúster de Amazon con varios nodos principales, YARN ResourceManager se ejecuta en los tres nodos principales. Uno ResourceManager está en active el estado y los otros dos están en el standby estado. Si se produce un active ResourceManager error en el nodo principal, Amazon EMR inicia un proceso de conmutación por error automático. Un nodo principal con a standby ResourceManager se encarga de todas las operaciones. Amazon EMR reemplaza el nodo principal fallido por uno nuevo, que luego se vuelve a unir al ResourceManager quórum como. standby

Puede conectarse a «http://master-public-dns-name:8088/cluster» para cualquier nodo principal, lo que lo dirige automáticamente al administrador de recursos. active Para saber qué administrador de recursos esactive, utilice esta opción SSH para conectarse a cualquier nodo principal del clúster. A continuación, ejecute el comando siguiente para obtener una lista de los tres nodos principales y su estado:

yarn rmadmin -getAllServiceState

Aplicaciones compatibles en un Amazon EMR Cluster con varios nodos principales

Puede instalar y ejecutar las siguientes aplicaciones en un EMR clúster de Amazon con varios nodos principales. Para cada aplicación, el proceso de conmutación por error del nodo principal varía.

Aplicación	Disponibilidad durante la conmutación por error del nodo principal	Notas
Flink	La conmutación por error del nodo principal no afecta a la disponibilidad	Los trabajos de Flink en Amazon EMR se ejecutan como YARN aplicaciones. Flink se JobManagers ejecuta tal cual ApplicationMasters en YARN los nodos principales. No JobManager se ve afectado por el proceso de conmutación por error del nodo principal. Si utilizas Amazon 5.27.0 o una EMR versión anterior, el error JobManager se debe a un único punto. Cuando se JobManager produce un error, pierde todos los estados de las tareas y no reanudará las tareas en ejecución. Puede habilitar la JobManager alta disponibilidad configurando el recuento de intentos de aplicación, los puntos de control y habilitándolos ZooKeeper como almacenamiento de estado para Flink. Para obtener más información, consulte Configuración de Flink en un Amazon EMR Cluster con varios nodos principales. A partir de la EMR versión 5.28.0 de Amazon, no es necesaria ninguna configuración manual para habilitar la JobManager alta disponibilidad.
Ganglia	La conmutación por error del nodo principal no afecta a la disponibilidad	Ganglia está disponible en todos los nodos principales, por lo que se puede seguir ejecutando durante el proceso de conmutación por error del nodo principal.
Hadoop	Alta disponibilidad	HDFS NameNode y YARN ResourceManager conmuta automáticamente por error al nodo en espera cuando se produce un error en el nodo principal activo.
HBase	Alta disponibilidad	HBasecuando se produce un error en el nodo principal activo, se realiza una conmutación automática por error al nodo en espera. Si se conecta a HBase través de un servidor Thrift REST o Thrift, debe cambiar a un nodo principal diferente cuando se produzca un error en el nodo principal activo.
HCatalog	La conmutación por error del nodo principal no afecta a la disponibilidad	HCatalogse basa en el metaalmacén de Hive, que existe fuera del clúster. HCatalogpermanece disponible durante el proceso de conmutación por error del nodo principal.
JupyterHub	Alta disponibilidad	JupyterHub está instalado en las tres instancias principales. Se recomienda configurar la persistencia de los cuadernos con el fin de evitar su pérdida en caso de error del nodo principal. Para más información, consulte Configuración de la persistencia de los cuadernos en Amazon S3.
Livy	Alta disponibilidad	Livy se ha instalado en los tres nodos principales. Cuando deja de funcionar el nodo principal activo, se pierde el acceso a la sesión actual de Livy y es necesario crear una nueva sesión de Livy en otro nodo principal o en el nodo de sustitución nuevo.
Mahout	La conmutación por error del nodo principal no afecta a la disponibilidad	Dado que Mahout no tiene daemon, no se ve afectado por el proceso de conmutación por error del nodo principal.
MXNet	La conmutación por error del nodo principal no afecta a la disponibilidad	Como no MXNet tiene ningún daemon, no se ve afectado por el proceso de conmutación por error del nodo principal.
Phoenix	Alta disponibilidad	Phoenix' solo QueryServer se ejecuta en uno de los tres nodos principales. El Phoenix de los tres maestros está configurado para conectar el Phoenix. QueryServer Puede encontrar la IP privada del servidor de consultas de Phoenix mediante el archivo /etc/phoenix/conf/phoenix-env.sh
Pig	La conmutación por error del nodo principal no afecta a la disponibilidad	Dado que Pig no tiene daemon, no se ve afectado por el proceso de conmutación por error del nodo principal.
Spark	Alta disponibilidad	Todas las aplicaciones de Spark se ejecutan en YARN contenedores y pueden reaccionar ante la conmutación por error del nodo principal de la misma manera que las funciones de alta disponibilidad. YARN
Sqoop	Alta disponibilidad	De forma predeterminada, sqoop-job y sqoop-metastore almacenan los datos (descripciones de trabajos) en el disco local del nodo principal que ejecuta el comando. Si desea guardar los datos del metaalmacén en una base de datos externa, consulte la documentación de Apache Sqoop.
Tez	Alta disponibilidad	Como los contenedores de Tez se ejecutan en ellosYARN, Tez se comporta de la misma manera que YARN durante el proceso de conmutación por error del nodo principal.
TensorFlow	La conmutación por error del nodo principal no afecta a la disponibilidad	Como no TensorFlow tiene ningún daemon, no se ve afectado por el proceso de conmutación por error del nodo principal.
Zeppelin	Alta disponibilidad	Zeppelin se ha instalado en los tres nodos principales. Zeppelin almacena las notas y las configuraciones de los intérpretes de forma HDFS predeterminada para evitar la pérdida de datos. Las sesiones de intérprete están completamente aisladas en las tres instancias principales. Los datos de la sesión se perderán en caso de error de la instancia principal. Se recomienda no modificar la misma nota simultáneamente en diferentes instancias principales.
ZooKeeper	Alta disponibilidad	ZooKeeper es la base de la función de conmutación por error HDFS automática. ZooKeeper proporciona un servicio de alta disponibilidad para el mantenimiento de los datos de coordinación, la notificación a los clientes de los cambios en esos datos y la supervisión de los clientes para detectar errores. Para obtener más información, consulte la conmutación por error HDFS automática.

Para ejecutar las siguientes aplicaciones en un EMR clúster de Amazon con varios nodos principales, debe configurar una base de datos externa. La base de datos externa se encuentra fuera del clúster y hace que persistan los datos durante el proceso de conmutación por error del nodo principal. Para las siguientes aplicaciones, los componentes de servicio se recuperarán automáticamente durante el proceso de conmutación por error del nodo principal, pero se pueden producir errores en los trabajos activos, en cuyo caso deberán repetirse.

Aplicación	Disponibilidad durante la conmutación por error del nodo principal	Notas
Hive	Alta disponibilidad únicamente para los componentes de servicio	Se requiere un metaalmacén externo para Hive. Debe ser un metaalmacén SQL externo de My, ya que Postgre no SQL es compatible con clústeres con varios maestros. Para más información, consulte Configuración de un metaalmacén externo para Hive.
Hue	Alta disponibilidad únicamente para los componentes de servicio	Se requiere una base de datos externa para Hue. Para obtener más información, consulta Uso de Hue con una base de datos remota en Amazon RDS.
Oozie	Alta disponibilidad únicamente para los componentes de servicio	Se requiere una base de datos externa para Oozie. Para obtener más información, consulta Uso de Oozie con una base de datos remota en Amazon RDS. Oozie-server y oozie-client se han instalado en los tres nodos principales. Los oozie-client están configurados para conectarse al oozie-server correcto de forma predeterminada.
PrestoDB o Presto/Trino SQL	Alta disponibilidad únicamente para los componentes de servicio	Se necesita un metaalmacén de Hive externo para PrestoDB (Presto SQL en Amazon EMR 6.1.0-6.3.0 o Trino en Amazon 6.4.0 y versiones posteriores). EMR Puede utilizar Presto con AWS Glue Data Catalog o utiliza una base de SQL datos My Database externa para Hive. El Presto CLI está instalado en los tres nodos principales, por lo que puede usarlo para acceder al coordinador de Presto desde cualquiera de los nodos principales. El coordinador de Presto se ha instalado en un solo nodo principal. Para encontrar el DNS nombre del nodo principal en el que está instalado el Presto Coordinator, llame a Amazon EMR describe-cluster API y lea el valor devuelto por el MasterPublicDnsName campo en la respuesta.

nota

Cuando se produce un error en un nodo principal, la conectividad de base de datos Java (JDBC) o la conectividad de base de datos abierta (ODBC) finaliza su conexión con el nodo principal. Puede conectarse a cualquiera de los demás nodos principales para continuar su trabajo porque el daemon del metaalmacén de Hive se ejecuta en todos los nodos principales. También puede esperar a que se sustituya el nodo principal que ha dejado de funcionar.

Cómo funcionan EMR las funciones de Amazon en un clúster con varios nodos principales

Conexión a los nodos principales mediante SSH

Puedes conectarte a cualquiera de los tres nodos principales de un EMR clúster de Amazon de SSH la misma manera que te conectas a un único nodo principal. Para obtener más información, consulte Conectarse al nodo principal mediante SSH.

Si se produce un error en un nodo principal, finaliza la SSH conexión con ese nodo principal. Para continuar con su trabajo, puede conectarse a uno de los otros dos nodos principales. Como alternativa, puedes acceder al nuevo nodo principal después de que Amazon EMR sustituya el que ha fallado por uno nuevo.

nota

La dirección IP privada del nodo principal de sustitución es la misma que la del anterior. La dirección IP pública del nodo principal de sustitución puede cambiar. Puede recuperar las nuevas direcciones IP en la consola o mediante el describe-cluster comando del AWS CLI.

NameNode solo se ejecuta en dos de los nodos principales. Sin embargo, puede ejecutar hdfs CLI comandos y ejecutar tareas para acceder HDFS a los tres nodos principales.

Trabajar con los pasos de un Amazon EMR Cluster con varios nodos principales

Puedes enviar los pasos a un EMR clúster de Amazon con varios nodos principales del mismo modo que trabajas con los pasos de un clúster con un único nodo principal. Para más información, consulte Enviar trabajo a un clúster.

Las siguientes son consideraciones para trabajar con los pasos de un EMR clúster de Amazon con varios nodos principales:

• Si un nodo principal falla, los pasos que se están ejecutando en el nodo principal se marcan comoFAILED. Los datos que se hayan escrito localmente se pierden. Sin embargo, es FAILED posible que el estado no refleje el estado real de los pasos.

• Si un paso en ejecución ha iniciado una YARN aplicación cuando se produce un error en el nodo principal, el paso puede continuar y tener éxito gracias a la conmutación por error automática del nodo principal.

• Se recomienda que compruebe el estado de los pasos consultando la salida de los trabajos. Por ejemplo, los MapReduce trabajos utilizan un _SUCCESS archivo para determinar si el trabajo se completa correctamente.

• Se recomienda establecer el ActionOnFailure parámetro enCONTINUE, o CANCEL _ AND _WAIT, en lugar de TERMINATE JOB _ _ FLOW o TERMINATE _CLUSTER.

Protección automática contra la terminación

Amazon habilita EMR automáticamente la protección de terminación para todos los clústeres con varios nodos principales y anula cualquier configuración de ejecución de pasos que proporciones al crear el clúster. Puede deshabilitar la protección contra la terminación después de que se haya lanzado el clúster. Consulte Configuración de la protección de terminación para ejecutar clústeres. Para cerrar un clúster con varios nodos principales, primero debe modificar los atributos del clúster para deshabilitar la protección contra la terminación. Para obtener instrucciones, consulte Terminar un Amazon EMR Cluster con varios nodos principales.

Para más información sobre la protección de terminación, consulte Uso de la protección de terminación para proteger sus clústeres de un cierre accidental.

Funciones no compatibles en un Amazon EMR Cluster con varios nodos principales

Las siguientes EMR funciones de Amazon no están disponibles actualmente en un EMR clúster de Amazon con varios nodos principales:

• EMRCuadernos

• Acceso de un clic al servidor del historial de Spark persistente

• Interfaces de usuario de aplicaciones persistentes

• El acceso con un clic a las interfaces de usuario de las aplicaciones persistentes no está disponible actualmente para EMR los clústeres de Amazon con varios nodos principales ni para los EMR clústeres de Amazon integrados con AWS Lake Formation.

nota

Para usar la autenticación Kerberos en su clúster, debe configurar una externaKDC.

A partir de la EMR versión 5.27.0 de Amazon, puede configurar el cifrado HDFS transparente en un EMR clúster de Amazon con varios nodos principales. Para obtener más información, consulta Cifrado transparente HDFS en Amazon EMR.