View a markdown version of this page

Administración de clústeres virtuales - Amazon EMR

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Administración de clústeres virtuales

Un clúster virtual es un espacio de nombres de Kubernetes en el que Amazon EMR está registrado. Puede crear, describir, enumerar y eliminar clústeres virtuales. No consumen recursos adicionales en el sistema. Un único clúster virtual se asigna a un único espacio de nombres Kubernetes. Dada esta relación, puede modelar clústeres virtuales de la misma manera que modela los espacios de nombres Kubernetes para satisfacer sus necesidades. Consulte los posibles casos de uso en la documentación de información general de conceptos de Kubernetes.

Para registrar Amazon EMR con un espacio de nombres de Kubernetes en un clúster de Amazon EKS, necesita el nombre del clúster de EKS y el espacio de nombres que se ha configurado para ejecutar su carga de trabajo. Estos clústeres registrados en Amazon EMR se denominan clústeres virtuales porque no administran la computación física ni el almacenamiento, sino que apuntan a un espacio de nombres de Kubernetes en el que está programada la carga de trabajo.

nota

Antes de crear un clúster virtual, debe completar los pasos del 1 al 8 que se indican en Configuración de Amazon EMR en EKS.

Crear un clúster virtual

Ejecute el siguiente comando para crear un clúster virtual mediante el registro de Amazon EMR con un espacio de nombres en un clúster de EKS. virtual_cluster_nameSustitúyalo por el nombre que proporcione para el clúster virtual. eks_cluster_nameSustitúyalo por el nombre del clúster de EKS. Sustitúyalo por el espacio de nombres namespace_name con el que desea registrar Amazon EMR.

aws emr-containers create-virtual-cluster \ --name virtual_cluster_name \ --container-provider '{ "id": "eks_cluster_name", "type": "EKS", "info": { "eksInfo": { "namespace": "namespace_name" } } }'

Como alternativa, puede crear un archivo JSON que incluya los parámetros necesarios para el clúster virtual, tal como se muestra en el siguiente ejemplo.

{ "name": "virtual_cluster_name", "containerProvider": { "type": "EKS", "id": "eks_cluster_name", "info": { "eksInfo": { "namespace": "namespace_name" } } } }

A continuación, ejecute el comando create-virtual-cluster con la ruta al archivo JSON.

aws emr-containers create-virtual-cluster \ --cli-input-json file://./create-virtual-cluster-request.json
nota

Para validar la creación correcta de un clúster virtual, consulte el estado de los clústeres virtuales mediante la ejecución del comando list-virtual-clusters o en la página Clústeres virtuales de la consola de Amazon EMR.

Enumerar los clústeres virtuales

Para ver el estado de los clústeres virtuales, ejecute el siguiente comando.

aws emr-containers list-virtual-clusters

Describir un clúster virtual

Ejecute el siguiente comando para obtener más detalles sobre un clúster virtual, como el espacio de nombres, el estado y la fecha de registro. 123456Sustitúyalo por su ID de clúster virtual.

aws emr-containers describe-virtual-cluster --id 123456

Eliminar un clúster virtual

Ejecute el siguiente comando para eliminar un clúster virtual. 123456Sustitúyalo por el ID de su clúster virtual.

aws emr-containers delete-virtual-cluster --id 123456

Estados del clúster virtual

En la siguiente tabla, se describen los cuatro estados posibles de un clúster virtual.

State Description (Descripción)

RUNNING

El estado del clúster virtual es RUNNING.

TERMINATING

La terminación del clúster virtual solicitada está en curso.

TERMINATED

La terminación solicitada se ha completado.

ARRESTED

Se ha producido un error en la terminación solicitada debido a la insuficiencia de permisos.

Límites de trabajos simultáneos para clústeres virtuales

Puede configurar los límites de trabajos simultáneos en un clúster virtual de Amazon EMR o EKS para controlar cuántos trabajos se ejecutan simultáneamente y cuántos pueden esperar en cola. Puede establecer el límite de simultaneidad (maxConcurrentJobRuns) y la profundidad de la cola (maxInQueueJobRuns) de forma independiente, de modo que puede limitar las ejecuciones de trabajos en ejecución, las ejecuciones de trabajos en cola o ambas. Al establecer estos límites, la StartJobRun API proporciona contrapresión a nivel de clúster virtual. El trabajo supera el límite de ejecución, espera en la cola en PENDING estado «SUBMITTEDo» en lugar de comenzar de inmediato y, una vez que la cola está llena, StartJobRun rechaza los envíos posteriores. Por ejemplo, si configura un clúster virtual para permitir la ejecución simultánea de 500 trabajos y 100 en cola, se rechazará el envío número 101 en cola y podrá reequilibrar esa carga de trabajo entre otros clústeres virtuales del mismo clúster de EKS o añadir capacidad. Si no ha establecido un límite de simultaneidad y la profundidad de las colas sigue aumentando, de modo que las ejecuciones de trabajos permanecen en el PENDING estado SUBMITTED O durante más tiempo antes de que comiencen, puede indicar que el clúster de EKS subyacente se está quedando sin recursos informáticos y no puede programar nuevos pods con la suficiente rapidez. En ese caso, dirija la carga de trabajo a otro clúster o añada capacidad.

Los límites de tareas simultáneas añaden una capa de control frente al programador de Kubernetes y a la ResourceQuota función del sitio web de Kubernetes. Como se aplican enStartJobRun, antes de que se cree cualquier pod, la API pone en cola la carga sobrante o la rechaza, lo que protege el clúster subyacente antes de que los trabajos lleguen a él. Kubernetes sigue imponiendo el límite máximo actual de CPU y memoria.

Ventajas clave de los límites de trabajos simultáneos

  • Evita la sobrecarga de vecinos ruidosos: limita la cantidad de ejecuciones de trabajos en ejecución y en cola por clúster virtual, de modo que un solo clúster virtual no pueda monopolizar el clúster de EKS compartido y provocar errores de programación de vecinos ruidosos en otros clústeres virtuales.

  • Permite configurar el tráfico: devuelve un rechazo inmediato cuando la cola de un clúster virtual está llena, de modo que puede redirigir los envíos a otros clústeres virtuales en lugar de abrumar a un solo clúster virtual.

  • Proporciona visibilidad: emite la información por clúster virtual JobsRunning y JobsInQueue CloudWatch las métricas del espacio de AWS/EMRContainers nombres para el recuento de ejecuciones de trabajos activos y en cola cada 5 minutos, lo que indica el estado de la programación.

Cómo empezar con los límites de trabajos simultáneos

Los límites de trabajos simultáneos se configuran con el schedulerConfiguration campo de un clúster virtual. Este campo acepta dos parámetros:

maxConcurrentJobRuns

El número máximo de trabajos ejecutados que puede haber en el RUNNING estado en cualquier momento.

maxInQueueJobRuns

El número máximo de trabajos que pueden estar en el SUBMITTED estado PENDING o (profundidad de la cola) en cualquier momento.

AWS CLI

Para establecer límites al crear un clúster virtual, especifíquelo schedulerConfiguration en la solicitud.

aws emr-containers create-virtual-cluster \ --name my-virtual-cluster \ --container-provider '{ ... }' \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

Para cambiar los límites de un clúster virtual existente, utilice el update-virtual-cluster comando.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

Para eliminar los límites de un clúster virtual, coloque un campo vacíoschedulerConfiguration. Esto borra la configuración, por lo que no se aplican límites y el clúster virtual vuelve al comportamiento predeterminado (ilimitado). Tenga en cuenta que, si omite schedulerConfiguration en la solicitud, los límites existentes no cambian; debe pasar un objeto vacío para borrarlos.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{}'

Para ver los límites actuales y el recuento de trabajos activos, usa el describe-virtual-cluster comando. La respuesta incluye tanto su schedulerConfiguration objeto como un SchedulerStatus objeto con la letra activeJobRunCount y actualinQueueJobRunCount.

nota

Cuando envía una ejecución de trabajo a un clúster virtual cuya cola está llena, StartJobRun devuelve unValidationException.

Elegir valores para max ConcurrentJobRuns y max InQueueJobRuns

Los límites correctos dependen de tres factores: la cantidad de trabajo que pueda ejecutar su clúster de Amazon EKS a la vez, el volumen de sus envíos y el comportamiento que desee que tenga el clúster virtual cuando esté lleno. Utilice la siguiente guía para elegir un punto de partida y, a continuación, perfeccionarlo a partir de los contadores activos.

Establecer el máximo ConcurrentJobRuns (espacios para correr)

maxConcurrentJobRunses una barrera basada en el recuento y granularidad de los trabajos. Una estimación aproximada a este respecto puede proteger el clúster subyacente de Amazon EKS para que no se degrade debido a la carga y puede mejorar la disponibilidad.

  • Comience dividiendo la capacidad por el espacio ocupado por trabajo. Báñelo en lo que solicite cada trabajo (controlador, ejecutores y sobrecarga de memoria) y destine aproximadamente del 70 al 80 por ciento de la capacidad de su espacio de nombres para dejar espacio para la sobrecarga de controladores, el escalamiento de nodos y las ráfagas.

  • Limite el tamaño de cada trabajo (tamaño). T-shirt Limite cada trabajo a unos pocos tamaños spark.dynamicAllocation.maxExecutors y estandarícelos (por ejemplo, pequeño (20 ejecutores), mediano (100) y grande (aproximadamente 500), de modo que maxConcurrentJobRuns multiplicado por el límite se asigne de manera predecible a la capacidad en lugar de sobreaprovisionar o subaprovisionar para obtener un promedio variable. Para obtener los cálculos más claros, dirija cada clase de tamaño a su propio clúster virtual.

  • Sintonice desde contadores en vivo. Empieza de forma conservadora y aumenta el valor gradualmente mientras activeJobRunCount observas la JobsRunning métrica en el espacio de AWS/EMRContainers nombres.

Configuración del máximo InQueueJobRuns (profundidad de cola)

maxInQueueJobRunscontrola el volumen de trabajo pendiente que acepta el clúster virtual antes de empezar a rechazar los envíos. Es un búfer de absorción de ráfagas. Tenga en cuenta los siguientes factores.

  • Perfil de ráfaga: ajuste el tamaño de la cola para absorber las ráfagas de envíos que espera que superen su velocidad de ejecución. Si las canalizaciones programadas despiden muchos trabajos a la vez, una cola más larga evita los rechazos falsos. Base la profundidad en el tamaño de ráfaga esperado, en lugar de en un múltiplo fijo demaxConcurrentJobRuns, y valídela comparándola con el límite de tiempo de drenaje que se indica a continuación.

  • Tiempo de espera aceptable: los trabajos en cola esperan a que se libere un espacio disponible. El trabajo que se encuentra al final de una cola llena espera aproximadamente la profundidad de la cola dividida entre el rendimiento de finalización. Por ejemplo, si los trabajos terminan a N por minuto y la cola contiene Q, la cola espera alrededor de Q dividido por N minutos. Mantén esto dentro de tu SLA. Como los trabajos en búfer fallan después de 30 minutos si no queda espacio libre, mantén un maxInQueueJobRuns tamaño lo suficientemente pequeño como para que toda la cola se agote en 30 minutos a un ritmo constante de finalización. De lo contrario, se agotará el tiempo de espera de los trabajos en cola.

  • Contrapresión en comparación con el almacenamiento en búfer: una cola más profunda suaviza las ráfagas, pero retrasa el rechazo con la cola llena que se utiliza para modelar el tráfico y aumenta la latencia final. Las colas menos profundas fallan rápidamente, lo que da a los clientes una señal temprana y práctica para volver a intentarlo o dirigirse a otro lugar. Elige en función de si prefieres almacenar en búfer la carga o la deshecha y redirigirla.

  • Comportamiento de reintento del cliente: cuando la cola está llena, StartJobRun devuelve un. ValidationException Asegúrese de que los remitentes gestionan esta excepción: vuelva a intentarlo con un retraso o dirija la carga de trabajo a otro clúster virtual. Establezca la profundidad para que los rechazos se produzcan solo durante una sobrecarga real, no durante una operación rutinaria.

Consideraciones sobre los límites de trabajos simultáneos

  • De forma predeterminada, no se aplica ningún límite. Los clústeres virtuales y las cargas de trabajo existentes no se ven afectados, a menos que se establezca de forma explícita. schedulerConfiguration

  • Como los contadores se mantienen en un sistema distribuido, a veces se puede esperar un pequeño delta transitorio con respecto al valor real. La reconciliación interna corrige cualquier desviación.