Comprender a fondo la asignación de recursos de YARN

---

Problemas a resolver en este artículo:

• ¿De qué forma funciona el contenedor? ¿Es un proceso JVM separado?
• ¿Cuál es la relación entre el vcore de YARN y el número de núcleos de CPU de la máquina? ¿Cuál es la memoria física y la memoria virtual que puede utilizar cada contenedor?
• ¿Cuántos contenedores se pueden asignar a un NodeManager?
• ¿Cuál es la memoria mínima que puede asignar un contenedor? ¿Cuál es la memoria máxima? ¿Y cuál es el VCore más pequeño y más grande?
• Al implementar programas Spark en YARN, ¿cuál es la relación entre AM y Driver?
• Spark en YARN, ¿cuántos ejecutores puede ejecutar un contenedor? ¿Cuál es la relación entre la memoria establecida por el ejecutor y el contenedor?

---

Breve introducción a la gestión de recursos de YARN

Proceso de ejecución de aplicaciones distribuidas en YARN

Esta imagen es un diagrama de flujo de la ejecución de tareas clásicas de YARN. Puede encontrar que hay 5 tipos de roles en la imagen de arriba:

1. Cliente
2. Administrador de recursos
3. Administrador de nodo
4. Maestro de aplicaciones
5. Envase

Resolvamos brevemente el proceso de envío de tareas.

1. Para ejecutar un programa de aplicación (MapReduce / Spark / Flink) en un clúster YARN, primero debe tener un cliente para enviar tareas a trabajos, es decir, un cliente. Inicia una solicitud a Resource Manager (RM) y RM genera un ID de TRABAJO para el trabajo enviado. En este momento, el estado del TRABAJO es: NUEVO
2. El cliente continúa enviando la información detallada del TRABAJO a RM, y el RM guarda la información detallada del trabajo. En este punto, el estado del TRABAJO es: ENVIAR
3. RM continúa enviando la información del trabajo al programador (programador), el programador verificará los permisos del cliente y verificará si la cola correspondiente (predeterminada: cola predeterminada) del Application Master (AM) que se ejecutará tiene recursos suficientes. En este momento, el estado de TRABAJO es ACEPTAR.
4. A continuación, RM comienza a ejecutar el recurso Container para AM e inicia AM en el Container. En este momento, el estado de TRABAJO está EN EJECUCIÓN
5. Una vez que el MA se inicia con éxito, comienza a coordinarse con el RM y se aplica al RM para que los recursos ejecuten el programa y verifica periódicamente el estado.
6. Si el TRABAJO se completa como se esperaba. En este momento, el estado de TRABAJO está FINALIZADO. Si ocurre una falla durante la operación, en este momento, el estado de TRABAJO es FALLIDO. Si el cliente mata activamente el trabajo, en este momento, el estado del TRABAJO es MATADO.

---

Gestión de recursos del clúster YARN

Recursos totales del clúster

Saber cuántos recursos hay en el clúster de YARN es fácil, podemos verlo directamente a través de la interfaz de usuario web de YARN.

Al observar las métricas de clúster, puede ver que la memoria total es de 24 GB y el núcleo de la CPU virtual es de 24. También podemos ver los recursos de cada NodeManager. Obviamente, la memoria total que se puede usar en el clúster YARN es la memoria disponible de cada NodeManager cargado en conjunto, y lo mismo ocurre con VCORE.

Recursos totales de NodeManager

La memoria disponible y la CPU disponible de NodeManager son 8G y 8Core respectivamente. Este recurso es incompatible con el sistema Linux. Usamos free -g para ver la memoria total y los núcleos de CPU del sistema operativo Linux.

>第一个节点（总计内存是10G，空闲的是8G）

>第二个节点（总计内存是7G，空闲是不到6G）

>第三个节点（和第二个节点一样）

¡Esto muestra que la memoria disponible del NodeManager no está directamente relacionada con la memoria total del sistema operativo!

¿Cómo se determina la memoria disponible de NodeManager?

Hay una configuración en yarn-default.xml: yarn.nodemanager.resource.memory-mb, y su valor predeterminado es: -1 (hadoop 3.1.4). Echemos un vistazo a la explicación oficial de Hadoop:

Esta configuración indica la memoria física total que puede usar NodeManager, que también es la memoria física que puede usar el contenedor. Si la configuración es -1 y yarn.nodemanager.resource.detect-hardware-Capacidades está configurado como verdadero, entonces se calculará automáticamente en función de la memoria física de la operación. Y yarn.nodemanager.resource.detect-hardware-Capacidades es falso de forma predeterminada, por lo que el NodeManager predeterminado aquí es 8G. Esto explica por qué la memoria disponible de cada NM es 8G.

Hay otra configuración importante: yarn.nodemanager.vmem-pmem-ratio, su configuración predeterminada es 2.1

Esta configuración es para el contenedor en el NodeManager. Si la memoria física de un contenedor determinado es insuficiente, la memoria virtual se puede utilizar. La memoria virtual que se puede utilizar es 2,1 veces la memoria física por defecto.

Para el número de núcleos de CPU virtuales, también hay una configuración yarn.nodemanager.resource.cpu-vcores, y su configuración predeterminada también es -1. Eche un vistazo a la explicación oficial de Hadoop: similar a la memoria, también tiene un valor predeterminado: 8.

Esto explica por qué el recurso total de cada NodeManager es 8G y 8 núcleos de CPU virtuales.

---

programador de recursos de programación

A través de la webui de YARN, haga clic en el programador, podemos ver la estrategia de programación, asignación de recursos mínima y máxima.

• A través de la interfaz de usuario web, podemos ver que la estrategia de programación de YARN actual es la programación de capacidad. La unidad de recursos de programación es la memoria basada en MB y Vcore (núcleo de CPU virtual). La asignación de recursos única más pequeña es: 1024M (1G) y 1 VCORE. La asignación más grande es: 4096M (4G) y 4 VCORE. Nota: Container transporta tanto los recursos de memoria como VCORE.

yarn.scheduler.minimum-allocation-mb

默认值：1024

说明：该配置表示每个容器的最小分配。因为RM是使用scheduler来进行资源调度的，如果请求的资源小于1G，也会设置为1G。这表示，如果我们请求一个256M的container，也会分配1G。

yarn.scheduler.maximum-allocation-mb

默认值：8192

说明：最大分配的内存，如果比这个内存高，就会抛出InvalidResourceRequestException异常。这里也就意味着，最大请求的内存不要超过8G。上述截图显示是4G，是因为我在yarn-site.xml中配置了最大分配4G。



yarn.scheduler.minimum-allocation-vcores

默认值：1

说明：同内存的最小分配

yarn.scheduler.maximum-allocation-vcores

默认值：4

说明：同内存的最大分配

---

Recursos totales del contenedor

• En YARN, los recursos se programan a través de Container y los programas también se ejecutan en Container. El planificador determina el recurso máximo que puede utilizar un contenedor. '
• Si sigue la configuración predeterminada de Hadoop, un contenedor puede solicitar hasta 8 G de memoria y 4 núcleos virtuales. Por ejemplo: solicitamos un contenedor con una memoria de 3G y un VCORE de 2, que está bien. Considere una pregunta: ¿Qué pasa si la memoria disponible restante en la máquina NM actual es menor que 3G? En este momento, se utiliza la memoria virtual.
• Sin embargo, la memoria virtual es como máximo 2,1 veces la memoria.Si la memoria física + la memoria virtual aún es menor que 3G, no podrá asignar recursos al contenedor.
• Según el análisis anterior, si la memoria del contenedor que solicitamos es 1G y 1 VCORE. Entonces NodeManager puede ejecutar hasta 8 contenedores. Si la memoria del contenedor que solicitamos es 4G y 4 vcores, NodeManager puede ejecutar hasta 2 contenedores.

---

¿Container es un proceso de JVM?

• Se estima que muchas personas que usan Hadoop todos los días pueden no conocer este problema. Después de solicitar recursos de RM, el contenedor se creará en NodeManager. La pregunta es: ¿Container tiene su propio proceso de JVM independiente? ¿O es posible ejecutar varios contenedores en el NodeManager? ¿Cuál es la relación entre Container y JVM?
• Aquí, para ser claros, cada contenedor es una instancia de JVM independiente. (Aquí, no discutiremos el modelo Uber). Cada tarea se ejecuta de forma independiente en el contenedor, como MapTask y ReduceTask. Cuando el programador lo programe, se aplicará al contenedor de acuerdo con las necesidades de ejecución de la tarea, y cada tarea es en realidad una JVM independiente.
• Para verificar este punto, ejecutemos un programa MapReduce. Luego usamos JPS en un NodeManager para verificar el proceso: (Esto es lo que he tratado, de lo contrario es demasiado largo, principalmente miramos el uso de la memoria).
• Hemos visto algunos procesos Java como MRAppMaster y YarnChild. Esto significa que cada contenedor es una JVM que se ejecuta de forma independiente y son independientes entre sí.

Spark en la gestión de recursos de YARN

• Por lo general, en un entorno de producción, ejecutamos programas Spark en YARN. El programa Spark se ejecuta en YARN en dos modos, uno es el modo Cluster y el otro es el modo Cliente. La diferencia clave entre estos dos modos es donde se ejecuta el controlador Spark. Si el modo de funcionamiento es el modo Clúster, el controlador se ejecuta en la aplicación maestra. Si está en modo Cliente, el controlador se ejecuta donde se envía el programa Spark. Spark Driver necesita interactuar continuamente con el contenedor que ejecuta la tarea, por lo que el cliente que ejecuta el controlador debe estar disponible en la red hasta que finalice la aplicación.
• Estas dos imágenes describen claramente.

Preste atención a la ubicación del controlador.

• A través del análisis anterior, podemos dejar en claro que si está en modo Cliente, Driver y ApplicationMaster se ejecutan en lugares diferentes. ApplicationMaster se ejecuta en el contenedor y el controlador se ejecuta en la máquina donde se encuentra el cliente que envía la tarea.
• Porque si se trata de un clúster independiente, el maestro y el trabajador completan toda la gestión de recursos y la ejecución de tareas. Cuando se ejecuta en YARN, no existen esos dos conceptos. La gestión de recursos sigue el método de programación de recursos de YARN. Anteriormente, en el tipo de clúster independiente, se podían ejecutar varios ejecutores en un trabajador, y ahora lo correspondiente es que se pueden ejecutar varios contenedores en un NodeManager, y el número de ejecutores es el mismo que el número de contenedores. Puedes entender directamente al ejecutor como un contenedor.

Echemos un vistazo a algunas configuraciones de parámetros de spark-submit.

• Entre las opciones de configuración, una es una configuración pública y algunos de los parámetros son diferentes para la ejecución de Spark-Submit en diferentes clústeres.

Configuración común:

• -driver-memory, -executor-memory, esta es la configuración que podemos especificar para ejecutar el controlador Spark y el ejecutor. El ejecutor en realidad especifica la memoria del contenedor, y si el controlador está en modo de clúster, es el maestro de la aplicación incorporado, de lo contrario es la memoria solicitada en la máquina donde se ejecuta el cliente.
• Si se ejecuta en modo Clúster, puede especificar el núcleo de la CPU que requiere el controlador.
• Si se ejecuta en Spark Standalone, --total-executeor-cores indica cuántos ejecutores se deben ejecutar en total.
• Si se ejecuta en un clúster independiente o en un clúster YARN, --executor-cores indica los núcleos de CPU requeridos por cada ejecutor.
• Si se ejecuta en yum, --num-executeors indica cuántos ejecutores iniciar, de hecho, cuántos contenedores se iniciarán.

---

Flink sobre la gestión de recursos de YARN

• Flink también tiene dos modos en HILO: uno es sesión de hilo y el otro es hilo por trabajo. El modo de sesión YARN es más interesante, que equivale a ejecutar un clúster Flink basado en Container en el clúster YARN.
• El contenedor tiene la función de JobManager y TaskManager. Luego, el cliente puede enviar trabajos continuamente a este Flink Cluster que se ejecuta en YARN.
• El comando anterior indica que se asignan 4 contenedores en YARN, TaskManager se ejecuta en cada contenedor, cada TaskManager corresponde a 8 vcores y cada TaskManager tiene 32 Gs. Esto requiere que el programador en YARN asigne una memoria máxima de contenedor grande; de ​​lo contrario, una memoria tan grande no se puede asignar en absoluto. Este modo es más adecuado para pruebas interactivas.
• El segundo modo, hilo por trabajo, es equivalente a un modo de envío de un solo TRABAJO. De manera similar, existen los conceptos de JobManager y TaskManager en YARN, pero actualmente es para un TRABAJO, y hay dos roles para el inicio. JobManager se ejecuta en Application Master y es responsable de la aplicación de recursos.
• El comando anterior indica que para ejecutar dos TaskManagers (es decir, 2 contenedores), el contenedor donde se encuentra el administrador de trabajos es la memoria 1G, el contenedor donde se encuentra el administrador de tareas es la memoria 3G y cada TaskManager usa 3 vcores.

para resumir

Si lo lee con atención, puede responder fácilmente a las siguientes preguntas:

• ¿De qué forma funciona el contenedor? ¿Es un proceso JVM separado?

Sí, cada contenedor es un proceso de JVM independiente.

• ¿Cuál es la relación entre el vcore de YARN y el número de núcleos de CPU de la máquina?

Está bien. El valor predeterminado se configura manualmente en yarn-default.xml. De manera predeterminada, cada NodeManager tiene 8 vcores. Los vcores en todos los NodeManagers se agregan para formar todos los vcores de todo el YARN.

• ¿Cuál es la memoria física y la memoria virtual que puede utilizar cada contenedor?

La cantidad de memoria que el programador asigna al contenedor es la memoria física máxima que se puede usar, pero si se excede la memoria física, se puede usar la memoria virtual. De forma predeterminada, la memoria virtual es 2,1 veces la memoria física.

• ¿Cuántos contenedores se pueden asignar a un NodeManager?

Esto depende del tamaño de la memoria del contenedor y del número de núcleos virtuales. Divida el Mem y Vcore más grande disponible en NM.

• ¿Cuál es la memoria mínima que puede asignar un contenedor? ¿Cuál es la memoria máxima? ¿Y cuál es el VCore más pequeño y más grande?

Determinado de acuerdo con la memoria mínima / máxima y el vcore mínimo / máximo asignado por el planificador.

• Al implementar programas Spark en YARN, ¿cuál es la relación entre AM y Driver?

Hay dos modos, el modo de clúster y el controlador se ejecuta en AM. Si está en modo cliente, no importa.

• Spark en YARN, ¿cuántos ejecutores puede ejecutar un contenedor? ¿Cuál es la relación entre la memoria establecida por el ejecutor y el contenedor?

Un contenedor corresponde a un ejecutor. La memoria configurada por el ejecutor es la memoria del contenedor solicitada por AM. Si la unidad mínima de asignación del contenedor es 1G, y la configuración del ejecutor incorporado es 512M, se asigna de acuerdo con la unidad mínima del contenedor.