View a markdown version of this page

Prácticas recomendadas - AWS ParallelCluster
Prácticas recomendadas: selección del tipo de instancia del nodo principalPrácticas recomendadas: rendimiento de la redPrácticas recomendadas: alertas de presupuestoMejores prácticas: mover un clúster a uno nuevo AWS ParallelCluster versión secundaria o de parchePrácticas recomendadas: comprobaciones del estado de la GPU

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.

Prácticas recomendadas

En las siguientes secciones se describen las mejores prácticas de uso AWS ParallelCluster, que incluyen alertas presupuestarias y de rendimiento de la red. Si tiene problemas a pesar de seguir estas prácticas recomendadas, consulte AWS ParallelCluster solución de problemas las posibles soluciones.

Prácticas recomendadas: selección del tipo de instancia del nodo principal

Aunque el nodo principal no ejecuta ningún trabajo, sus funciones y su tamaño son cruciales para el rendimiento general del clúster. Al elegir el tipo de instancia que se utilizará para el nodo principal, tenga en cuenta las siguientes características:

Tamaño del clúster: el nodo principal organiza la lógica de escalado del clúster y es responsable de adjuntar nuevos nodos al planificador. Para escalar hacia arriba y hacia abajo un clúster que tiene una gran cantidad de nodos, proporcione al nodo principal una capacidad informática adicional.

Sistemas de archivos compartidos: cuando utilice sistemas de archivos compartidos, elija un tipo de instancia con suficiente ancho de banda de la red y suficiente ancho de banda de Amazon EBS para administrar sus flujos de trabajo. Asegúrese de que el nodo principal pueda exponer suficientes directorios de servidores NFS para el clúster y administrar los artefactos que deben compartirse entre los nodos de computación y el nodo principal.

Prácticas recomendadas: rendimiento de la red

El rendimiento de la red es fundamental para las aplicaciones de computación de alto rendimiento (HPC). Sin un rendimiento de red fiable, estas aplicaciones no pueden funcionar según lo esperado. Para optimizar el rendimiento de la red, tenga en cuenta las siguientes prácticas recomendadas.

  • Grupo de ubicación: si utiliza Slurm, considere la posibilidad de configurar cada cola de Slurm para que utilice un grupo con ubicación en clúster. Un grupo con ubicación en clúster es una agrupación lógica de instancias en una misma zona de disponibilidad. Para obtener más información, consulte Grupos de ubicación en la Guía del usuario de Amazon EC2. Puede especificar un PlacementGroup en la sección Networking de la cola; cada recurso de computación se asigna al grupo de ubicación de la cola. Al especificar un PlacementGroup en la sección Networking del recurso de computación, se asigna ese recurso de computación específico a ese grupo de ubicación. La especificación del grupo de ubicación del recurso de computación anula la especificación de la cola del recurso de computación. Para obtener más información, consulte SlurmQueues/Networking/PlacementGroup y SlurmQueues/ComputeResources/Networking/PlacementGroup.

    Networking:
  PlacementGroup:
    Enabled: true
    Id: your-placement-group-name

    Como alternativa, puedes AWS ParallelCluster crear un grupo de ubicación para ti.

    Networking:
  PlacementGroup:
    Enabled: true

    A partir de AWS ParallelCluster la versión 3.3.0, se modifican la creación y la gestión de los grupos de colocación. Al especificar el grupo de ubicación que se va a habilitar, sin un name o Id, en la cola, a cada recurso de computación se le asigna su propio grupo de ubicación administrado, en lugar de un grupo administrado para toda la cola. Esto ayuda a reducir los errores por capacidad insuficiente. Si necesita tener un grupo de ubicación para toda la cola, puede usar un grupo de ubicación con nombre.

    Se ha agregado SlurmQueues/Networking/PlacementGroup/Name como alternativa preferida a SlurmQueues/Networking/PlacementGroup/Id.

    Para obtener más información, consulte Networking.

  • Redes mejoradas: considere la posibilidad de elegir un tipo de instancia que admita redes mejoradas. Esta recomendación se aplica a todas las instancias de la generación actual. Para obtener más información, consulte Redes mejoradas en Linux en la Guía del usuario de Amazon EC2.

  • Elastic Fabric Adapter: para admitir altos niveles de comunicación escalable de instancia a instancia, considere la posibilidad de elegir interfaces de red EFA para su red. El hardware de derivación del sistema operativo personalizado de la EFA mejora las comunicaciones de instancia a instancia con la elasticidad y flexibilidad bajo demanda de la Nube de AWS. Puede configurar cada cola de Slurm ComputeResource para que utilice Efa. Para obtener más información sobre el uso de EFA con AWS ParallelCluster, consulte. Elastic Fabric Adapter

    ComputeResources:
  - Name: your-compute-resource-name
    Efa:
      Enabled: true

    Para obtener más información sobre EFA, consulte Elastic Fabric Adapter en la Guía del usuario para instancias de Linux de Amazon EC2.

  • Ancho de banda de la instancia: el ancho de banda se escala con el tamaño de la instancia. Para obtener información acerca de los distintos tipos de instancia, consulte Instancias optimizadas para Amazon EBS y Tipos de volúmenes de Amazon EBS en la Guía del usuario de Amazon EC2.

Prácticas recomendadas: alertas de presupuesto

Para administrar los costos de los recursos en AWS ParallelCluster, le recomendamos que utilice AWS Budgets acciones para crear un presupuesto. También puede crear alertas de umbrales presupuestarios definidos para AWS los recursos seleccionados. Para obtener más información, consulte Configuring a budget action en la Guía del usuario de AWS Budgets . Del mismo modo, también puedes usar Amazon CloudWatch para crear una alarma de facturación. Para obtener más información, consulte Creación de una alarma de facturación para monitorear los cargos estimados de AWS.

Mejores prácticas: mover un clúster a uno nuevo AWS ParallelCluster versión secundaria o de parche

Actualmente, cada versión AWS ParallelCluster secundaria es independiente junto con su pcluster CLI. Para mover un clúster a una nueva versión secundaria o de parche, debe volver a crear el clúster mediante la CLI de la nueva versión.

Para optimizar el proceso de traslado de un clúster a una nueva versión secundaria o de parche, le recomendamos que haga lo siguiente:

  • Guarde los datos personales en volúmenes externos que se crean fuera del clúster, como Amazon EFS y FSx para Lustre. De este modo, podrá mover fácilmente los datos de un clúster a otro en el futuro.

  • Cree sistemas de almacenamiento compartido con los siguientes tipos. Puede crear estos sistemas mediante el comando AWS CLI o Consola de administración de AWS.

    Defina un sistema de archivos o un volumen en una configuración de clúster como sistema de archivos o volumen existente. De esta forma, se conservan al eliminar el clúster y se pueden asociar a un clúster nuevo.

    Le recomendamos que utilice sistemas de archivos de Amazon EFS o FSx para Lustre. Ambos sistemas se pueden conectar a varios clústeres al mismo tiempo. Además, puede asociar cualquiera de estos sistemas a un clúster nuevo antes de eliminar el clúster existente.

  • Use las acciones de arranque personalizadas para personalizar sus instancias en lugar de usar una AMI personalizada. Si, por el contrario, utiliza una AMI personalizada, tendrá que eliminar y volver a crear esa AMI para cada versión nueva.

  • Se recomienda aplicar las recomendaciones anteriores en la secuencia siguiente:

    1. Actualice la configuración del clúster existente para utilizar las definiciones de sistemas de archivos existentes.

    2. Compruebe la versión de pcluster y actualícela si es necesario.

    3. Cree y pruebe el nuevo clúster. Al probar el nuevo clúster, compruebe lo siguiente:

      • Asegúrese de que sus datos estén disponibles en el clúster nuevo.

      • Asegúrese de que la aplicación funcione en el clúster nuevo.

    4. Cuando haya probado por completo el clúster nuevo, esté en funcionamiento y ya no necesite el clúster existente, elimínelo.

Prácticas recomendadas: comprobaciones del estado de la GPU

La comprobación del estado de la GPU integrada

La comprobación de estado de la GPU integrada (HealthChecks/Gpu/Enabled) está desactivada a menos que la habilites. Cuando está habilitada, ejecuta un diagnóstico de nivel 2 de la DCGM de NVIDIA en las GPU del nodo como parte del prólogo. Slurm Como el diagnóstico se ejecuta en el prólogo y un trabajo no puede iniciarse hasta que se complete el prólogo, este diseño es adecuado para los tipos de instancias en las que el diagnóstico finaliza rápidamente.

La comprobación integrada solo es fiable cuando se asignan tareas exclusivas (una tarea por nodo). En los nodos compartidos por más de una tarea, puede interferir con la ejecución de las tareas y agotar los nodos en buen estado, por lo que debe habilitarla solo en las colas con. JobExclusiveAllocation: true

Además, en las familias de instancias de GPU P6 y P6e (por ejemplo, p6-b200 yp6-b300) y en las generaciones de instancias de P-family GPU posteriores, el diagnóstico tarda lo suficiente como para no ejecutarse en el prólogo: normalmente supera los límites de tiempo del Slurm prólogo y provoca que los nodos en buen estado se agoten y los trabajos vuelvan a ponerse en cola. En estos tipos de instancias, mantén deshabilitada la comprobación del estado de la GPU (). HealthChecks/Gpu/Enabled: false

Opciones para realizar tus propias comprobaciones del estado de la GPU

Para comprobar el estado de la GPU en estas instancias, elige uno de los siguientes métodos y haz coincidir cada comprobación con el momento en que se ejecuta: al iniciar el nodo, antes o después de un trabajo. Esto sigue el modelo de NVIDIA para el estado y el diagnóstico de las GPU (consulte el estado y el diagnóstico de la DCGM de NVIDIA); el dcgmi diag diagnóstico aumenta en profundidad y duración según el nivel (consulte Diagnósticos de la DCGM).

importante

En un nodo compartido por más de un trabajo, ejecute cualquier dcgmi diag diagnóstico (del nivel 1 al nivel 4) solo cuando ningún otro trabajo esté utilizando el nodo. De lo contrario, puede fallar y agotar el nodo.

  • Compruébelo al iniciar el nodo. Úselo para validar un nodo una vez, cuando se una al clúster, antes de que acepte el trabajo. Como todavía no se está ejecutando ningún trabajo, puede ejecutarse de forma profundadcgmi diag; tenga en cuenta que solo detecta los errores presentes al inicio, no las degradaciones que aparecen más adelante. Instala e invoca la comprobación con una acción OnNodeConfigured personalizada. Consulte Acciones de arranque personalizadas.

  • Registra el prólogo. Úselo para prepararse rápidamente antes de cada trabajo. Dado que el prólogo se ejecuta en todos los trabajos e impide que el trabajo se inicie hasta que finalice, mantenga la comprobación durante unos segundos. Por ejemplo nvidia-smi (opcionalmente, con un análisis del registro del núcleo para detectar errores de NVIDIA Xid) o un análisis de nivel 1. dcgmi diag Consulte Slurm y prologepilog.

  • Consulta el epílogo. Utilícela para validar un nodo después de que se complete un trabajo. Por ejemplo, para realizar una comprobación más profunda cuando se produce un error en un trabajo o para detectar una GPU que se ha degradado durante una ejecución antes de que se programe el siguiente trabajo. Puede ejecutarse a una profundidad mayordcgmi diag. Para evitar realizar comprobaciones después de cada trabajo, es posible que desee ejecutar un diagnóstico de nivel 2 solo cuando el trabajo falle. Consulte Slurm y prologepilog.

nota

AWS ParallelCluster reemplaza los nodos estáticos agotados o fallidos (y termina los dinámicos), de modo que si se agota un nodo con un error confirmado, se reemplaza.