Visión general de la arquitectura YARN

YARN (Yet Another Resource Negotiator) es el componente de gestión de recursos y programación de tareas de Hadoop. Su arquitectura se divide en dos servicios principales a nivel de clúster:

• ResourceManager (RM): Gestiona los recursos globales del clúster (CPU, memoria) y asigna contenedores a las aplicaciones.
• NodeManager (NM): Ejecuta y supervisa los contenedores en un nodo individual del clúster, reportando su uso de recursos al ResourceManager.

Cada aplicación presentada al clúster es gestionada por un ApplicationMaster (AM), que negocia recursos con el ResourceManager y coordina la ejecución de las tareas dentro de los contenedores proporcionados por los NodeManagers.

Configuración del planificador Fair Scheduler

El Fair Scheduler asigna recursos de manera que, a lo largo del tiempo, todas las aplicaciones reciben una cantidad equitativa de los mismos. Su configuración reside en el archivo fair-scheduler.xml.

Estructura básica y configuración de cola raíz

<?xml version="1.0"?>
<allocations>
    <queue name="raiz">
        <weight>1.0</weight>
        <policyScheduling>drf</policyScheduling>
        <aclSubmitApps>*</aclSubmitApps>
        <aclAdministerApps>*</aclAdministerApps>
        <!-- Definición de subcolas aquí -->
    </queue>
    <defaultSchedulingPolicy>drf</defaultSchedulingPolicy>
</allocations>

Los recursos se asignan a las subcolas mediante pesos relativos. El ratio de recursos que una cola obtiene es proporcional a su peso dividido por la suma de los pesos de todas las colas hermanas. Esta asignación es dinámica y se ajusta con cambios en el clúster.

Restricciones de recursos por cola

Se pueden aplicar varios límites en la definición de una cola:

• minResources y maxResources: Establecen límites mínimos y máximos absolutos de recursos (ej: 10240 mb, 5 vcores).
• maxRunningApps: Limita el número máximo de aplicaciones en ejecución simultánea en la cola.
• maxAMShare: Controla la fracción máxima de recursos de la cola que puede ser utilizada por Application Masters (útil para prevenir que los AMs consuman todos los recursos).
• Listas de Control de Acceso (ACLs): Usando aclSubmitApps y aclAdministerApps, se controla qué usuarios o grupos pueden enviar o administrar aplicaciones en la cola.

Preemptive de recursos entre colas

Para evitar que una cola con alta demanda monopolice recursos destinados a otras, se puede configurar la preemción. Primero, se habilita globalmente en yarn-site.xml:

<property>
    <name>yarn.scheduler.fair.preemption</name>
    <value>true</value>
</property>

Luego, se configura la tolerancia en la cola que necesita recuperar recursos:

<queue name="colab">
    <weight>10.0</weight>
    <fairSharePreemptionTimeout>120</fairSharePreemptionTimeout>
    <fairSharePreemptionThreshold>0.6</fairSharePreemptionThreshold>
</queue>

Esto significa que si colab recibe menos del 60% de su cuota justa (Threshold) durante 120 segundos (Timeout), el planificador puede matar tareas en otras colas para reasignar recursos.

Para proteger una cola de que le arebaten sus recursos, se establece:

<queue name="colaProtegida">
    <allowPreemptionFrom>false</allowPreemptionFrom>
</queue>

Políticas de programación internas de una cola

Dentro de una cola, la política determina cómo se asignan los recursos a sus aplicaciones hijas:

• fair (FairSharePolicy): Busca equilibrar el uso de memoria entre aplicaciones.
• fifo (FifoPolicy): Prioriza aplicaciones por orden de llegada.
• drf (DominantResourceFairnessPolicy): Política por defecto recomendada. Asigna recursos intentando equilibrar la fracción dominante de recursos solicitados (CPU o memoria) por cada aplicación, siguiendo el principio de "justicia en recursos dominantes".

Política de ubicación de aplicaciones en colas (queuePlacementPolicy)

Define en qué cola se coloca una aplicación enviada. Se evalúa como una lista de reglas en orden:

<queuePlacementPolicy>
    <rule name="specified" create="true"/>
    <rule name="nestedUserQueue">
        <rule name="primaryGroup" create="true"/>
    </rule>
    <rule name="default"/>
</queuePlacementPolicy>

Reglas comunes incluyen:

• specified: Usa la cola explícitamente mencionada en la solicitud de la aplicación.
• user o primaryGroup: Crea o ubica la aplicación en una cola con el nombre del usuario o su grupo principal.
• nestedUserQueue: Permite anidar la lógica de asignación (ej: crear una cola de usuario dentro de una cola de grupo).
• default o reject: Reglas de cierre para ubicar en una cola por defecto o rechazar la aplicación.

Ejemplo práctico: Aislamiento por grupos en un clúster CDH

Supongamos un clúster donde se requiere garantizar recursos para tres flujos de trabajo: cálculos batch con Azkaban (60%), procesamiento en tiempo real con Flink (10%) y consultas interactivas desde Hue (30%).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
    <queue name="raiz">
        <weight>1.0</weight>
        <policyScheduling>drf</policyScheduling>
        <queue name="batch_azkaban" type="parent">
            <weight>6.0</weight>
            <fairSharePreemptionTimeout>90</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.7</fairSharePreemptionThreshold>
            <allowPreemptionFrom>false</allowPreemptionFrom>
        </queue>
        <queue name="stream_flink">
            <weight>1.0</weight>
            <fairSharePreemptionTimeout>90</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.7</fairSharePreemptionThreshold>
            <allowPreemptionFrom>false</allowPreemptionFrom>
        </queue>
        <queue name="interactive_hue" type="parent">
            <weight>3.0</weight>
            <fairSharePreemptionTimeout>90</fairSharePreemptionTimeout>
            <fairSharePreemptionThreshold>0.7</fairSharePreemptionThreshold>
        </queue>
    </queue>
    <queuePlacementPolicy>
        <rule name="specified" create="true"/>
        <rule name="nestedUserQueue">
            <rule name="primaryGroup" create="true"/>
        </rule>
        <rule name="default" queue="interactive_hue"/>
    </queuePlacementPolicy>
</allocations>

En este caso, la cola interactive_hue permite la preemción (configuración por defecto), mientras que batch_azkaban y stream_flink están protegidas contra ella con <allowPreemptionFrom>false</allowPreemptionFrom>. La política de ubicación coloca aplicaciones en colas basadas en el grupo principal del usuario de Linux, lo cual es crucial si se integra con herramientas como Hue.

Nota importante: Para que la asignación por grupo funcione con cuentas creadas en Hue, es necesario crear el usuario correspondiente en el sistema operativo de los nodos del clúster (ej: adduser nuevo_usuario) y asignarlo al grupo deseado (ej: usermod -G interactive_hue nuevo_usuario), ya que YARN lee los grupos del sistema operativo.