View a markdown version of this page

Best practice - AWS ParallelCluster
Procedure consigliate: selezione del tipo di istanza del nodo principaleProcedure consigliate: prestazioni di reteProcedure consigliate: avvisi sul budgetProcedure consigliate: spostare un cluster in un nuovo AWS ParallelCluster versione minore o patchataProcedure consigliate: controlli dello stato della GPU

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice

Le sezioni seguenti forniscono le migliori pratiche per l'utilizzo AWS ParallelCluster, tra cui avvisi sulle prestazioni di rete e sul budget. Se riscontri problemi anche se segui queste best practice, consulta AWS ParallelCluster risoluzione dei problemi le possibili soluzioni.

Procedure consigliate: selezione del tipo di istanza del nodo principale

Anche se il nodo principale non esegue un job, le sue funzioni e il suo dimensionamento sono fondamentali per le prestazioni complessive del cluster. Quando scegli il tipo di istanza da utilizzare per il nodo principale, considera le seguenti caratteristiche:

Dimensione del cluster: il nodo principale orchestra la logica di ridimensionamento del cluster ed è responsabile del collegamento di nuovi nodi allo scheduler. Per aumentare e diminuire la scalabilità di un cluster con un numero elevato di nodi, fornisci al nodo principale una capacità di calcolo aggiuntiva.

File system condivisi: quando utilizzi file system condivisi, scegli un tipo di istanza con larghezza di banda di rete e larghezza di banda Amazon EBS sufficienti per gestire i tuoi flussi di lavoro. Assicurati che il nodo principale sia in grado di esporre un numero sufficiente di directory del server NFS per il cluster e di gestire gli artefatti che devono essere condivisi tra i nodi di calcolo e il nodo principale.

Procedure consigliate: prestazioni di rete

Le prestazioni di rete sono fondamentali per le applicazioni HPC (High Performance Computing). Senza prestazioni di rete affidabili, queste applicazioni non possono funzionare come previsto. Per ottimizzare le prestazioni della rete, prendi in considerazione le seguenti best practice.

  • Gruppo di collocamento: se utilizziSlurm, valuta la possibilità di configurare ogni Slurm coda per utilizzare un gruppo di posizionamento del cluster. Il gruppo di posizionamento di un cluster è un raggruppamento logico di istanze all'interno di una singola zona di disponibilità. Per ulteriori informazioni, consulta i gruppi di posizionamento nella Amazon EC2 User Guide. Puoi specificare a PlacementGroup nella Networking sezione della coda, ogni risorsa di calcolo viene assegnata al gruppo di posizionamento della coda. Quando si specifica a PlacementGroup nella Networking sezione della risorsa di calcolo, quella specifica risorsa di calcolo viene assegnata a quel gruppo di posizionamento. La specifica del gruppo di posizionamento delle risorse di elaborazione sovrascrive la specifica della coda per la risorsa di calcolo. Per ulteriori informazioni, vedere SlurmQueues//e///Networking. PlacementGroup SlurmQueues ComputeResources Networking PlacementGroup

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

    In alternativa, chiedi di AWS ParallelCluster creare un gruppo di collocamento per te.

    Networking:
  PlacementGroup:
    Enabled: true

    A partire dalla AWS ParallelCluster versione 3.3.0, la creazione e la gestione dei gruppi di collocamento vengono modificate. Quando si specifica il gruppo di posizionamento da abilitare, senza name oId, nella coda, a ciascuna risorsa di calcolo viene assegnato il proprio gruppo di posizionamento gestito, anziché un gruppo gestito per l'intera coda. Questo aiuta a ridurre gli errori di capacità insufficienti. Se è necessario disporre di un gruppo di posizionamento per l'intera coda, è possibile utilizzare un gruppo di posizionamento denominato.

    SlurmQueues/Networking/PlacementGroup/Nameè stato aggiunto come alternativa preferita a SlurmQueues//Networking/PlacementGroup. Id

    Per ulteriori informazioni, consulta Networking.

  • Rete avanzata: valuta la possibilità di scegliere un tipo di istanza che supporti reti avanzate. Questa raccomandazione si applica a tutte le istanze di generazione attuale. Per ulteriori informazioni, consulta Enhanced Networking on Linux nella Amazon EC2 User Guide.

  • Elastic Fabric Adapter: per supportare alti livelli di comunicazione scalabile da istanza a istanza, valuta la scelta delle interfacce di rete EFA per la tua rete. L'hardware di bypass del sistema operativo (OS) personalizzato dell'EFA migliora le comunicazioni da istanza a istanza grazie all'elasticità e alla flessibilità su richiesta di. Cloud AWSÈ possibile configurare ciascuna coda da utilizzare. Slurm ComputeResource Efa Per ulteriori informazioni sull'utilizzo di EFA con AWS ParallelCluster, vedere. Elastic Fabric Adapter

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

    Per ulteriori informazioni su EFA, consulta Elastic Fabric Adapter nella Amazon EC2 User Guide for Linux Instances.

  • Larghezza di banda dell'istanza: la larghezza di banda varia in base alle dimensioni dell'istanza. Per informazioni sui diversi tipi di istanze, consulta Amazon EBS: istanze ottimizzate e tipi di volume Amazon EBS nella Amazon EC2 User Guide.

Procedure consigliate: avvisi sul budget

Per gestire i costi delle risorse in AWS ParallelCluster, ti consigliamo di utilizzare Budget AWS le azioni per creare un budget. È inoltre possibile creare avvisi sulle soglie di budget definite per AWS le risorse selezionate. Per ulteriori informazioni, vedere Configurazione di un'azione di budget nella Guida per l'Budget AWS utente. Allo stesso modo, puoi anche utilizzare Amazon CloudWatch per creare un avviso di fatturazione. Per ulteriori informazioni, consulta Creazione di un allarme di fatturazione per il monitoraggio dei costi di AWS stimati.

Procedure consigliate: spostare un cluster in un nuovo AWS ParallelCluster versione minore o patchata

Attualmente ogni versione AWS ParallelCluster secondaria è autonoma insieme alla relativa pcluster CLI. Per spostare un cluster in una nuova versione secondaria o con patch, è necessario ricreare il cluster utilizzando l'interfaccia a riga di comando della nuova versione.

Per ottimizzare il processo di spostamento di un cluster verso una nuova versione secondaria o con patch, ti consigliamo di effettuare le seguenti operazioni:

  • Salva i dati personali in volumi esterni creati all'esterno del cluster, come Amazon EFS e FSx for Lustre. In questo modo, puoi spostare facilmente i dati da un cluster all'altro in futuro.

  • Crea sistemi di storage condivisi utilizzando i seguenti tipi. È possibile creare questi sistemi utilizzando il pulsante AWS CLI o Console di gestione AWS.

    Definire un file system o un volume in una configurazione cluster come file system o volume esistente. In questo modo, vengono conservati quando si elimina il cluster e possono essere collegati a un nuovo cluster.

    Ti consigliamo di utilizzare Amazon EFS o FSx for Lustre file system. Entrambi questi sistemi possono essere collegati a più cluster contemporaneamente. Inoltre, è possibile collegare uno di questi sistemi a un nuovo cluster prima di eliminare il cluster esistente.

  • Utilizza azioni di bootstrap personalizzate per personalizzare le tue istanze anziché utilizzare un'AMI personalizzata. Se invece utilizzi un'AMI personalizzata, devi eliminare e ricreare quell'AMI per ogni nuova versione rilasciata.

  • Ti consigliamo di applicare i consigli precedenti nella seguente sequenza:

    1. Aggiorna la configurazione del cluster esistente per utilizzare le definizioni dei file system esistenti.

    2. Verifica la pcluster versione e aggiornala se necessario.

    3. Crea e testa il nuovo cluster. Quando testate il nuovo cluster, verificate quanto segue:

      • Assicurati che i tuoi dati siano disponibili nel nuovo cluster.

      • Assicurati che l'applicazione funzioni nel nuovo cluster.

    4. Dopo che il nuovo cluster è stato completamente testato e operativo e non è più necessario il cluster esistente, eliminalo.

Procedure consigliate: controlli dello stato della GPU

Il controllo dello stato della GPU integrato

Il controllo dello stato della GPU integrato (HealthChecks/Gpu/Enabled) è disattivato a meno che non lo si abiliti. Quando è abilitato, esegue una diagnostica NVIDIA DCGM di livello 2 sulle GPU del nodo come parte del prologo. Slurm Poiché la diagnostica viene eseguita nel prologo e un processo non può iniziare fino al completamento del prologo, questo design è adatto ai tipi di istanza in cui la diagnostica termina rapidamente.

Il controllo integrato è affidabile solo con l'allocazione esclusiva del job (un job per nodo). Sui nodi condivisi da più di un job, può interferire con l'esecuzione dei job e svuotare i nodi integri, quindi abilitalo solo nelle code con. JobExclusiveAllocation: true

Inoltre, nelle famiglie di istanze GPU P6 e P6e (ad esempio p6-b200 ep6-b300) e nelle generazioni successive di istanze P-family GPU, la diagnostica richiede abbastanza tempo da non dover essere eseguita nel prolog: in genere supera i limiti di tempo del Slurm prolog e causa il drenaggio dei nodi integri e la coda dei lavori. In questi tipi di istanze, mantieni disabilitato il controllo dello stato della GPU (). HealthChecks/Gpu/Enabled: false

Opzioni per eseguire controlli di integrità della GPU personalizzati

Per eseguire i controlli sullo stato della GPU su queste istanze, scegli tra i seguenti approcci, abbinando ogni controllo a quando viene eseguito: all'avvio del nodo, prima di un processo o dopo un lavoro. Questo segue il modello di NVIDIA per lo stato e la diagnostica delle GPU (vedi NVIDIA DCGM Health and diagnostics); la diagnostica aumenta in profondità e durata per livello (vedi dcgmi diag Diagnostica DCGM). https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html#run-levels-and-tests

Importante

Su un nodo condiviso da più di un job, esegui qualsiasi tipo di dcgmi diag diagnostica (dal livello 1 al livello 4) solo quando nessun altro job utilizza il nodo. Altrimenti, può fallire e svuotare il nodo.

  • Verifica all'avvio del nodo. Usalo per convalidare un nodo una volta, quando si unisce al cluster, prima che accetti il lavoro. Poiché nessun job è ancora in esecuzione, può essere eseguito in modo approfonditodcgmi diag; notate che rileva solo i guasti presenti all'avvio, non i degradi che compaiono in seguito. Installa e richiama il controllo con un'azione personalizzata. OnNodeConfigured Per informazioni, consulta Azioni bootstrap personalizzate.

  • Effettua il check-in nel prolog. Usalo per una rapida preparazione prima di ogni lavoro. Poiché il prolog viene eseguito su ogni lavoro e ne blocca l'avvio fino al completamento, mantieni il controllo per alcuni secondi. Ad esempio, nvidia-smi (opzionalmente con una scansione del registro del kernel per individuare eventuali errori di NVIDIA Xid) o un livello 1. dcgmi diag Per informazioni, consulta Slurm e prolog epilog.

  • Effettua il check-in nell'epilogo. Usalo per convalidare un nodo dopo il completamento di un job. Ad esempio, per eseguire un controllo più approfondito quando un processo fallisce o per rilevare una GPU che si è deteriorata durante un'esecuzione prima della pianificazione del lavoro successivo. Può essere più profondo. dcgmi diag Per evitare il controllo dopo ogni lavoro, è consigliabile eseguire una diagnostica di livello 2 solo quando il lavoro fallisce. Per informazioni, consulta Slurm e prolog epilog.

Nota

AWS ParallelCluster sostituisce i nodi statici svuotati o guasti (e termina quelli dinamici), quindi lo svuotamento di un nodo con un errore confermato comporta la sua sostituzione.