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 presupuestoPrácticas recomendadas: mover un clúster a una nueva versión de AWS ParallelCluster secundaria o de parche

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

Las siguientes secciones proporcionan las mejores prácticas de uso de AWS ParallelCluster, que incluyen alertas de rendimiento de la red y de presupuesto.

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 los nuevos nodos al programador. Para escalar y reducir verticalmente un clúster que tenga un gran número de nodos, proporcione al nodo principal capacidad de computación 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

    También puede hacer que AWS ParallelCluster cree un grupo de ubicaciones para usted.

    Networking:
  PlacementGroup:
    Enabled: true

    A partir de AWS ParallelCluster versión 3.3.0, se modifica la creación y administración de los grupos de ubicació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 gestionar los costes de los recursos en AWS ParallelCluster, le recomendamos que utilice acciones de AWS Budgets para crear un presupuesto. También puede crear alertas de umbrales presupuestarios definidos para los recursos de AWS 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 puede utilizar 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.

Prácticas recomendadas: mover un clúster a una nueva versión de AWS ParallelCluster secundaria o de parche

Actualmente, cada versión de AWS ParallelCluster secundaria es autónoma junto con su CLI de pcluster. 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 la AWS CLI o la AWS Management Console.

    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.