Solución de YARN HA
Principios de HA y solución de implementación
ResourceManager en YARN gestiona los recursos y programa las tareas en el clúster. En versiones anteriores a Hadoop 2.4, los SPOF pueden ocurrir en el ResourceManager en el clúster de YARN. La solución YARN HA utiliza nodos de ResourceManager redundantes para hacer frente a los desafíos de confiabilidad del servicio y tolerancia a fallas.
El HA de ResourceManager se consigue usando nodos de ResourceManager activo-en espera, como se muestra en Figura 1. Al igual que la solución HDFS HA, el HA ResourceManager permite que solo un nodo de ResourceManager esté en el estado activo en cualquier momento. Cuando el ResourceManager activo falla, la conmutación activa-en espera se puede activar de forma automática o manual.
Cuando la función de conmutación por error automática no está habilitada, después de que el clúster YARN esté habilitado, los administradores de clúster MRS necesitan ejecutar el comando yarn rmadmin para cambiar manualmente uno de los nodos ResourceManager al estado activo. Tras un evento de mantenimiento planificado o una falla, se espera que primero desciendan el ResourceManager activo al estado de espera y el ResourceManager de espera promocionen al estado activo.
Cuando se habilita la conmutación por error automática, se utiliza un ActiveStandbyElector integrado basado en ZooKeeper para decidir qué nodo ResourceManager debe ser el activo. Cuando el ResourceManager activo es defectuoso, se selecciona automáticamente otro nodo ResourceManager para que sea el activo para hacerse cargo del nodo defectuoso.
Cuando los nodos ResourceManager del clúster se implementan en modo HA, el yarn-site.xml de configuración utilizado por los clientes debe enumerar todos los nodos de ResourceManager. El cliente (incluido ApplicationMaster y NodeManager) busca el ResourceManager activo en modo de sondeo. Es decir, el cliente necesita proporcionar el mecanismo de tolerancia a fallas. Si no se puede conectar con el ResourceManager activo, el cliente busca continuamente uno nuevo en modo de sondeo.
Después de que el nodo ResourceManager en espera se convierte en el activo, las aplicaciones de capa superior pueden recuperarse a su estado cuando se produce el fallo. Para obtener más información, consulte Reiniciar ResourceManager. Cuando ResourceManager Restart está habilitado, el nodo ResourceManager reiniciado carga la información del nodo activo anterior de ResourceManager y toma la información del estado del contenedor en todos los nodos de NodeManager para continuar la ejecución del servicio. De esta manera, la información de estado se puede guardar ejecutando periódicamente operaciones de punto de control, evitando la pérdida de datos. Asegúrese de que los nodos de ResourceManager activos y en espera puedan acceder a la información de estado. Actualmente, se proporcionan tres métodos para compartir información de estado por sistema de archivos (FileSystemRMStateStore), base de datos de LevelDB (LeveldbRMStateStore) y ZooKeeper (ZKRMStateStore). Entre ellos, solo ZKRMStateStore es compatible con el mecanismo de Fencing. De forma predeterminada, Hadoop utiliza ZKRMStateStore.
Para obtener más información acerca de la solución YARN HA, visite el siguiente sitio Web:
http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html
https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html
