Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Slurm Workload Manager (Slurm)

Größe und Aktualisierung der Cluster-Kapazität

Die Kapazität des Clusters wird durch die Anzahl der Rechenknoten definiert, die der Cluster skalieren kann. Rechenknoten werden von Amazon EC2-Instances unterstützt, die in der AWS ParallelCluster Konfiguration innerhalb der Rechenressourcen definiert sind. Sie sind in Warteschlangen organisiert(Scheduling/SlurmQueues/ComputeResources), (Scheduling/SlurmQueues) die Partitionen 1:1 zugeordnet Slurm sind.

Innerhalb einer Rechenressource ist es möglich, die Mindestanzahl von Rechenknoten (Instances) zu konfigurieren, die im Cluster immer am Laufen gehalten werden müssen (MinCount), und die maximale Anzahl von Instances, auf die die Rechenressource skaliert werden kann (MaxCount3).

AWS ParallelCluster Startet bei der Clustererstellung oder bei einem Cluster-Update so viele Amazon EC2-Instances, wie MinCount für jede im Cluster definierte Rechenressource (Scheduling/SlurmQueues/ ComputeResources) konfiguriert sind. Die Instances, die gestartet werden, um die Mindestanzahl an Knoten für eine Rechenressource im Cluster abzudecken, werden als statische Knoten bezeichnet. Einmal gestartet, sollen statische Knoten im Cluster persistent sein und werden nicht vom System beendet, es sei denn, ein bestimmtes Ereignis oder eine bestimmte Bedingung tritt ein. Zu diesen Ereignissen gehören beispielsweise das Scheitern von Slurm Amazon EC2-Zustandsprüfungen und die Änderung des Slurm Knotenstatus auf DRAIN oder DOWN.

Die Amazon EC2-Instances im Bereich von 1 bis ‘MaxCount - MinCount’ (MaxCount minus) MinCount), die bei Bedarf gestartet werden, um der erhöhten Belastung des Clusters gerecht zu werden, werden als dynamische Knoten bezeichnet. Sie sind von Natur aus kurzlebig. Sie werden gestartet, um ausstehende Jobs zu bearbeiten, und werden beendet, sobald sie für einen Scheduling/SlurmSettings/ScaledownIdletime in der Cluster-Konfiguration definierten Zeitraum inaktiv bleiben (Standardeinstellung: 10 Minuten).

Statische Knoten und dynamische Knoten entsprechen dem folgenden Benennungsschema:

Zum Beispiel bei der folgenden AWS ParallelCluster Konfiguration:

Scheduling:  
    Scheduler: Slurm  
    SlurmQueues:    
        - Name: queue1      
            ComputeResources:        
                - Name: c5xlarge          
                    Instances:            
                        - InstanceType: c5.xlarge          
                        MinCount: 100          
                        MaxCount: 150        

Die folgenden Knoten werden definiert in Slurm

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
queue1*      up   infinite     50  idle~ queue1-dy-c5xlarge-[1-50]
queue1*      up   infinite    100   idle queue1-st-c5xlarge-[1-100]                
            

Wenn eine Rechenressource MinCount == MaxCount vorhanden ist, sind alle entsprechenden Rechenknoten statisch und alle Instances werden zur creation/update Clusterzeit gestartet und am Laufen gehalten. Beispiel:

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: queue1
      ComputeResources:
        - Name: c5xlarge
          Instances:
            - InstanceType: c5.xlarge
          MinCount: 100
          MaxCount: 100
            

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
queue1*      up   infinite    100   idle queue1-st-c5xlarge-[1-100]               
            

Aktualisierung der Cluster-Kapazität

Die Aktualisierung der Clusterkapazität umfasst das Hinzufügen oder Entfernen von Warteschlangen, Rechenressourcen oder das Ändern MinCount/MaxCount einer Rechenressource. Ab AWS ParallelCluster Version 3.9.0 erfordert das Reduzieren der Größe einer Warteschlange, dass die Rechenflotte gestoppt oder auf QueueUpdateStrategy TERMINATE gesetzt wird, bevor ein Cluster-Update stattfindet. Es ist nicht erforderlich, die Rechenflotte anzuhalten oder auf TERMINATE QueueUpdateStrategy zu setzen, wenn:

Überlegungen und Einschränkungen

In diesem Abschnitt sollen alle wichtigen Faktoren, Einschränkungen oder Einschränkungen beschrieben werden, die bei der Größenänderung der Clusterkapazität berücksichtigt werden sollten.

Bei der Änderung des MinCount Parameters einer Rechenressource können wir zwei verschiedene Szenarien unterscheiden: Wenn MaxCount der Wert gleich bleibt MinCount (nur statische Kapazität), und wenn er größer MaxCount ist als MinCount (gemischte statische und dynamische Kapazität).

Die Kapazität ändert sich nur bei statischen Knoten

Kapazitätsänderungen bei gemischten Knoten

Wenn der Cluster um den Betrag N erhöht MinCount MaxCount wird (vorausgesetztMinCount < MaxCount, er bleibt unverändert), wird der Cluster konfiguriert, indem die Anzahl der statischen Knoten auf den neuen Wert von MinCount (old_MinCount + N): erweitert wird, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount + N> und das System versucht weiterhin, Amazon EC2-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Um der MaxCount Kapazität der Rechenressource gerecht zu werden, wird die Cluster-Konfiguration außerdem aktualisiert, indem die letzten N dynamischen Knoten entfernt werden: <Queue/Name>-dy-<ComputeResource/Name>-[<MaxCount - old_MinCount - N>...<MaxCount - old_MinCount>] und das System beendet die entsprechenden Amazon EC2-Instances.

Wenn MinCount < MaxCount bei Erhöhung MinCount und gleichem Wert N MaxCount der Cluster konfiguriert wird, indem die Anzahl der statischen Knoten auf den neuen Wert von MinCount (old_MinCount + N): erweitert wird, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount + N> und das System versucht weiterhin, Amazon EC2-Instances zu starten, um die neue erforderliche statische Kapazität zu erfüllen. Darüber hinaus wird die Anzahl der dynamischen Knoten nicht geändert, um den neuen Anforderungen gerecht zu werden

MaxCount Wert.

Wenn beim Verringern MinCount der Anzahl N (vorausgesetztMinCount < MaxCount, dass MaxCount sie unverändert bleiben), der Cluster konfiguriert wird, indem die letzten N statischen Knoten entfernt werden, <Queue/Name>-st-<ComputeResource/Name>-[<old_MinCount - N>...<old_MinCount> und das System beendet die entsprechenden Amazon EC2-Instances. Um der MaxCount Kapazität der Rechenressource gerecht zu werden, wird außerdem die Cluster-Konfiguration aktualisiert, indem die Anzahl der dynamischen Knoten erweitert wird, um die Lücke zu schließen. Da es sich MaxCount - new_MinCount: <Queue/Name>-dy-<ComputeResource/Name>-[1..<MazCount - new_MinCount>] in diesem Fall um dynamische Knoten handelt, werden keine neuen Amazon EC2-Instances gestartet, es sei denn, der Scheduler hat auf den neuen Knoten ausstehende Jobs.

Wenn MinCount < MaxCount MaxCount der Cluster abnimmt MinCount und den gleichen Wert N hat, wird der Cluster konfiguriert, indem die letzten N statischen Knoten entfernt werden, <Queue/Name>-st-<ComputeResource/Name>-<old_MinCount - N>...<oldMinCount>] und das System beendet die entsprechenden Amazon EC2-Instances.

Darüber hinaus wird die Anzahl der dynamischen Knoten nicht geändert, um den neuen MaxCount Wert zu berücksichtigen.

Wenn MaxCount der Wert N verringert wird (vorausgesetztMinCount < MaxCount, er bleibt unverändert), MinCount wird der Cluster konfiguriert, indem die letzten N dynamischen Knoten entfernt werden, <Queue/Name>-dy-<ComputeResource/Name>-<old_MaxCount - N...<oldMaxCount>] und das System beendet die entsprechenden Amazon EC2-Instances, falls sie ausgeführt wurden. Es werden keine Auswirkungen auf die statischen Knoten erwartet.

Auswirkungen auf die Arbeitsplätze

In allen Fällen, in denen Knoten entfernt und Amazon EC2-Instances beendet werden, wird ein Sbatch-Job, der auf den entfernten Knoten ausgeführt wird, erneut in die Warteschlange gestellt, es sei denn, es gibt keine anderen Knoten, die die Jobanforderungen erfüllen. In diesem letzten Fall schlägt der Job mit dem Status NODE_FAIL fehl und verschwindet aus der Warteschlange. Er muss erneut manuell eingereicht werden.

Wenn Sie planen, eine Aktualisierung der Clustergröße durchzuführen, können Sie verhindern, dass Jobs auf den Knoten ausgeführt werden, die während des geplanten Updates entfernt werden. Dies ist möglich, indem Sie festlegen, dass die Knoten im Rahmen von Wartungsarbeiten entfernt werden. Bitte beachten Sie, dass die Einstellung eines Nodes im Wartungsmodus keine Auswirkungen auf Jobs hat, die eventuell bereits in dem Knoten ausgeführt werden.

Nehmen wir an, dass Sie mit der geplanten Aktualisierung der Clustergröße den Knoten entfernen werdenqeueu-st-computeresource-[9-10]. Sie können eine Slurm Reservierung mit dem folgenden Befehl erstellen

sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]

Dadurch wird eine Slurm Reservierung erstellt, die maint_for_update auf den Knoten benannt istqeueu-st-computeresource-[9-10]. Ab dem Zeitpunkt, an dem die Reservierung erstellt wurde, können keine Jobs mehr auf den Knoten ausgeführt werdenqeueu-st-computeresource-[9-10]. Bitte beachten Sie, dass die Reservierung nicht verhindert, dass Jobs irgendwann auf den Knoten zugewiesen werdenqeueu-st-computeresource-[9-10].

Wenn die Slurm Reservierung nach der Aktualisierung der Clustergröße nur für Knoten festgelegt wurde, die während der Aktualisierung der Größe entfernt wurden, wird die Wartungsreservierung automatisch gelöscht. Wenn Sie stattdessen eine Slurm Reservierung für Knoten erstellt haben, die nach der Aktualisierung der Clustergröße noch vorhanden sind, möchten wir möglicherweise die Wartungsreservierung auf den Knoten entfernen, nachdem die Aktualisierung der Größe durchgeführt wurde. Verwenden Sie dazu den folgenden Befehl

sudo -i scontrol delete ReservationName=maint_for_update

Weitere Informationen zur Slurm Reservierung finden Sie im offiziellen SchedMD-Dokument hier. https://slurm.schedmd.com/reservations.html

Cluster-Aktualisierungsprozess bei Kapazitätsänderungen

Bei einer Änderung der Scheduler-Konfiguration werden während des Cluster-Aktualisierungsprozesses die folgenden Schritte ausgeführt:

Weitere Informationen zu Slurm finden Sie unter https://slurm.schedmd.com. Downloads finden Sie unter https://github.com/SchedMD/slurm/tags. Sie finden den Quellcode unter https://github.com/SchedMD/slurm.

Unterstützte Cluster- und SLURM-Versionen

In der folgenden Tabelle sind die Slurm Versionen AWS ParallelCluster und aufgeführt, die AWS unterstützt werden.