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. # Aktualisieren Sie die Scheduler-Version eines AWS PCS-Cluster Gehen Sie wie folgt vor, um die Scheduler-Version auf Ihrem Cluster zu aktualisieren. Je nachdem, ob Sie eine Arbeitsunterbrechung tolerieren können, gibt es zwei Optionen. Weitere Informationen zur Auswahl zwischen Optionen finden Sie unter[Aktualisierung der Scheduler-Version eines Clusters in AWS STCK](working-with_clusters_version_update.md). **Anmerkung** Wir empfehlen, dass Sie das neue AMI und das Aktualisierungsverfahren auf einem Cluster außerhalb der Produktionsumgebung testen, bevor Sie Änderungen an Ihrer Produktionsumgebung vornehmen. ## Option 1: Fortlaufendes Update Der Controller wird aktualisiert, während die Flotte weiterläuft. Bestehende Knoten verwenden weiterhin die vorherige Slurm-Version, bis sie entleert und ersetzt werden. Neue Knoten, die nach dem Update gestartet werden, verwenden die Zielversion. Laufende Jobs werden nicht unterbrochen. **Wann sollte man Folgendes verwenden: ** + Der Cluster-Controller ist auf Slurm-Version 24.05 oder höher. ### Schritt 0 — Überprüfen Sie den Startstatus Auf Ihrem Cluster wird Controller-Version „A“ (z. B. 24.11) ausgeführt, und Sie möchten auf Version „B“ (z. B. 25.11) migrieren. Vergewissern Sie sich, dass alle Rechenknoten in Ihrer Flotte dieselbe Hauptversion ausführen, indem Sie diesen Befehl von einem Cluster-Knoten aus verwenden: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Bestätigen Sie die AWS PCS-Agent-Version auf einem Rechenknoten. Stellen Sie mit Systems Manager eine Verbindung zum Knoten her und überprüfen Sie das Bootstrap-Protokoll: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` Für fortlaufende Updates ist der AWS PCS-Agent Version 1.4.0 oder höher auf allen Rechenknoten-AMIs erforderlich. Weitere Informationen finden Sie unter [AWS PCS-Agent-Versionen](pcs-agent-versions.md). ### Schritt 1 — Bereiten Sie die Ziel-AMIs vor Erstellen oder identifizieren Sie AMIs, die ** Slurm-Version B und den neuesten AWS PCS-Agenten ** enthalten. + Sie können die neuesten ** PCS-ready ** DLAMIs verwenden. Solche AMIs werden mit den letzten drei unterstützten Slurm-Versionen ausgeliefert. Weitere Informationen finden Sie unter [Verwenden von PCS-ready DLAMI mit AWS 5 STCK](working-with_ami_pcs-ready-dlami.md). + Sie können ein ** benutzerdefiniertes AMI erstellen**, indem Sie den Installationsschritten für Slurm-Pakete und den AWS PCS-Agenten folgen. Weitere Informationen finden Sie unter [Benutzerdefinierte Amazon Machine Images (AMIs) für AWS PCS](working-with_ami_custom.md). + Wir empfehlen das **AWS PCS-Beispiel-AMI nicht ** für den Einsatz in der Produktion. Diese AMIs dienen nur zum Testen. **Anmerkung** Das gleiche AMI kann mehrere Slurm-Versionen enthalten. AWS PCS wählt automatisch die Version aus, die zum Controller passt. Die Installation zusätzlicher Versionen verursacht keine Probleme. ### Schritt 2 — Aktualisieren Sie den Cluster-Controller Rufen Sie `UpdateCluster` mit der `scheduler.version` Einstellung auf Version B auf. ------ #### [ AWS-Managementkonsole ] 1. Öffnen Sie die AWS PCS-Konsole unter [ https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. Klicken Sie im Navigationsbereich auf **Cluster**. 1. Wählen Sie den Cluster aus, der aktualisiert werden soll, und wählen Sie ** Bearbeiten**. 1. Wählen Sie unter ** Cluster-Details ** die Ziel-Scheduler-Version aus der ** Scheduler-Dropdown-Liste ** aus. 1. Wählen Sie ** Update**, um das Versionsupdate einzureichen. 1. Überwachen Sie den Cluster-Status. Der Cluster wird wie `UPDATING` bei der Aktualisierung angezeigt und kehrt zum Status zurück, `ACTIVE` wenn der Vorgang abgeschlossen ist. Das Update ist in der Regel in 5—15 Minuten abgeschlossen. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Warten Sie, bis der Cluster zu ihm zurückgekehrt ist. `ACTIVE` Das Update ist in der Regel in 5—15 Minuten abgeschlossen. ------ Während dieses Vorgangs ist der Controller kurzzeitig nicht verfügbar: + Laufende Jobs auf Rechenknoten ** werden weiterhin ausgeführt**. + Neue Jobübermittlungen und Scheduler-Befehle sind erst verfügbar, wenn das Update abgeschlossen ist. + Die automatische Skalierung wird unterbrochen, bis der Cluster wieder den Wert erreicht hat. `ACTIVE` **Anmerkung** Fügen Sie keine für Version B spezifischen Slurm-Einstellungen hinzu, solange die Flotte noch Knoten in Version A enthält. Die Konfiguration wird an alle Knoten verteilt; die alten erkennen `slurmd` möglicherweise keine neuen Parameter. Wenn der Cluster nicht zu `ACTIVE` oder `UPDATE_FAILED` innerhalb von 30 Minuten zurückkehrt, wenden Sie sich an den Support, um AWS Unterstützung zu erhalten. ### Schritt 3 — Compute-Knotengruppen aktualisieren Stellen Sie für jede Rechenknotengruppe das neue AMI mit der Ziel-Slurm-Version ein: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --ami-id {{new-ami-id}} ``` AWS PCS setzt Knoten, auf denen die vorherige Version ausgeführt wird, auf `DRAIN` Status. Nachdem die leeren Knoten ihre aktuellen Aufgaben beendet haben, beendet AWS PCS die Knoten und ersetzt sie durch neue Knoten, auf denen Slurm Version B ausgeführt wird. ### Schritt 4 — Überprüfen Sie die konsistente Flotte auf Slurm-Version B Überwachen Sie den Flottenwechsel. Überprüfen Sie von einem Clusterknoten aus die Versionsübersicht für alle Knoten: ``` scontrol show nodes | grep "Version=" | awk -F'=' '{print $NF}' | sort | uniq -c ``` Überprüfen Sie den `DRAIN` Status der Knoten und ihre Version: ``` scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=.*DRAIN/{print name, ver}' ``` Überprüfen Sie die Version für alle aktiven Knoten: ``` scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=/{if (ver) print name, ver}' ``` Das Update ist abgeschlossen, wenn in der Versionsübersicht nur die Zielversion angezeigt wird und keine Knoten mehr im `DRAIN` `DRAINING` Status sind. Knoten im `POWERED_DOWN` Status melden erst dann eine Version, wenn sie von AWS PCS gestartet werden. ## Option 2: Full-fleet Wartungsstopp Sie beenden die gesamte Flotte, bevor Sie den Controller aktualisieren, und skalieren ihn dann von einem neuen AMI aus mit der Ziel-Slurm-Version wieder hoch. Dieses Verfahren ist einfacher, aber es beendet alle Knoten und laufenden Jobs. **Wann sollte man Folgendes verwenden: ** + Der Cluster-Controller ist auf Version 23.11 (Option 1 ist für 23.11-Cluster nicht verfügbar). **Anmerkung** Wenn die gesamte Flotte auf einmal beendet wird, erhöht sich die Wahrscheinlichkeit, dass bei der erneuten Skalierung Fehler aufgrund unzureichender Kapazität auftreten. Erwägen Sie die Nutzung reservierter Kapazitäten oder die Planung außerhalb der Spitzenzeiten. ### Schritt 0 — Überprüfen Sie den Startstatus Auf Ihrem Cluster wird Controller-Version „A“ (z. B. 24.11) ausgeführt, und Sie möchten auf Version „B“ (z. B. 25.11) migrieren. Vergewissern Sie sich, dass alle Rechenknoten in Ihrer Flotte dieselbe Hauptversion ausführen, indem Sie diesen Befehl von einem Cluster-Knoten aus verwenden: ``` scontrol show nodes | grep "Version=" # Example output: # NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7 # NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7 ``` Bestätigen Sie die AWS PCS-Agent-Version auf einem Rechenknoten. Stellen Sie mit Systems Manager eine Verbindung zum Knoten her und überprüfen Sie das Bootstrap-Protokoll: ``` grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1 # Example output: # /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1 ``` Verwenden Sie den neuesten AWS PCS-Agenten auf Ihren Ziel-AMIs. Weitere Informationen finden Sie unter [AWS PCS-Agent-Versionen](pcs-agent-versions.md). ### Schritt 1 — Bereiten Sie die Ziel-AMIs vor Erstellen oder identifizieren Sie AMIs, die ** Slurm-Version B und den neuesten AWS PCS-Agenten ** enthalten. + Sie können die neuesten ** PCS-ready ** DLAMIs verwenden. Solche AMIs werden mit den letzten drei unterstützten Slurm-Versionen ausgeliefert. Weitere Informationen finden Sie unter [Verwenden von PCS-ready DLAMI mit AWS 5 STCK](working-with_ami_pcs-ready-dlami.md). + Sie können ein ** benutzerdefiniertes AMI erstellen**, indem Sie den Installationsschritten für Slurm-Pakete und den AWS PCS-Agenten folgen. Weitere Informationen finden Sie unter [Benutzerdefinierte Amazon Machine Images (AMIs) für AWS PCS](working-with_ami_custom.md). + Wir empfehlen das **AWS PCS-Beispiel-AMI nicht ** für den Einsatz in der Produktion. Diese AMIs dienen nur zum Testen. ### Schritt 2 — Verkleinern Sie die gesamte Flotte Notieren Sie die aktuelle `minNodeCount` und `maxNodeCount` für jede Compute-Knotengruppe — diese werden Sie in Schritt 4 wiederherstellen. ``` for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do aws pcs get-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier "$cng" \ --query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \ --output table done ``` **Warnung** Der folgende Vorgang beendet alle laufenden Knoten und die darauf befindlichen Jobs. Setze `minNodeCount` und `maxNodeCount` `0` auf für jede Rechenknotengruppe: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` Stellen Sie sicher, dass keine Instances, `aws:pcs:cluster-id` die Ihrem Cluster entsprechen, ausgeführt werden, bevor Sie fortfahren: ``` aws ec2 describe-instances \ --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \ --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \ --output table ``` ### Schritt 3 — Aktualisieren Sie den Cluster-Controller ------ #### [ AWS-Managementkonsole ] 1. Öffnen Sie die AWS PCS-Konsole unter [ https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/). 1. Klicken Sie im Navigationsbereich auf **Cluster**. 1. Wählen Sie den Cluster aus, der aktualisiert werden soll, und wählen Sie ** Bearbeiten**. 1. Wählen Sie unter ** Cluster-Details ** die Ziel-Scheduler-Version aus der ** Scheduler-Dropdown-Liste ** aus. 1. Wählen Sie ** Update**, um das Versionsupdate einzureichen. 1. Überwachen Sie den Cluster-Status. Der Cluster wird wie `UPDATING` bei der Aktualisierung angezeigt und kehrt zum Status zurück, `ACTIVE` wenn der Vorgang abgeschlossen ist. Das Update ist in der Regel in 5—15 Minuten abgeschlossen. ------ #### [ AWS CLI ] ``` aws pcs update-cluster \ --cluster-identifier {{cluster-id}} \ --scheduler version={{25.11}} ``` Warten Sie, bis der Cluster zu ihm zurückgekehrt ist. `ACTIVE` Das Update ist in der Regel in 5—15 Minuten abgeschlossen. Wenn der Cluster nicht zu `ACTIVE` oder `UPDATE_FAILED` innerhalb von 30 Minuten zurückkehrt, wenden Sie sich an den Support, um AWS Unterstützung zu erhalten. ------ ### Schritt 4 — Compute-Knotengruppen aktualisieren und Kapazität wiederherstellen Stellen Sie für jede Rechenknotengruppe das neue AMI ein und stellen Sie die ursprünglichen Mindest- und Höchstkapazitätsgrenzen wieder her: ``` aws pcs update-compute-node-group \ --cluster-identifier {{cluster-id}} \ --compute-node-group-identifier {{cng-id}} \ --ami-id {{new-ami-id}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` Der Cluster wird wieder hochskaliert. Auf allen neuen Knoten wird Slurm Version B mit dem neuesten AWS PCS-Agenten ausgeführt. ## Beispiel: Aktualisierung über mehrere Versionen hinweg Wenn sich die Zielversion außerhalb des Kompatibilitätsfensters Ihrer aktuellen Version befindet, müssen Sie den Controller durch eine oder mehrere Zwischenversionen verschieben und ihn Schritt für Schritt aktualisieren. Jeder Hop muss auf eine unterstützte Version innerhalb des Kompatibilitätsfensters der aktuellen Controller-Version abzielen. Da die Flotte vor der Aktualisierung des Controllers auf Null [Option 2: Full-fleet Wartungsstopp](#version_update-procedure-option2) skaliert wird, laufen keine Rechenknoten, während der Controller zwischen den Versionen wechselt. Dadurch können Ihre AMIs die ** endgültige ** Zielversion direkt verwenden — nur das Controller-Update (Schritt 3) wird für jeden Hop wiederholt. Im folgenden Beispiel wird ein Cluster ** mithilfe der Option 2-Prozedur von ** 23.11 auf 25.11 aktualisiert. 23.11 liegt außerhalb des Kompatibilitätsfensters von 25.11, sodass der Controller in zwei Hops aktualisiert wird (23.11 auf 25.05, dann 25.05 auf 25.11). Folgen Sie den Schritten von Option 2, wobei Schritt 3 in ein Update pro Hop aufgeteilt ist: 1. **Schritt 1 — Bereiten Sie die Ziel-AMIs vor. ** Erstellen oder identifizieren Sie AMIs mit der ** endgültigen ** Version (25.11) und dem neuesten AWS PCS-Agenten. Siehe [Schritt 1 — Bereiten Sie die Ziel-AMIs vor](#version_update-procedure-option2-step1). 1. **Schritt 2 — Verkleinern Sie die gesamte Flotte. ** Notieren Sie die aktuelle Kapazität (siehe[Schritt 2 — Verkleinern Sie die gesamte Flotte](#version_update-procedure-option2-step2)) und setzen Sie dann jede Rechenknotengruppe auf Null. ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}' ``` 1. **Schritt 3a — Aktualisieren Sie den Controller von 23.11 auf 25.05. ** Warten Sie, bis der Cluster zu ihm zurückkehrt`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.05 ``` 1. **Schritt 3b — Aktualisieren Sie den Controller von 25.05 auf 25.11. ** Warten Sie, bis der Cluster zu ihm zurückkehrt`ACTIVE`. ``` aws pcs update-cluster --cluster-identifier {{my-cluster}} \ --scheduler version=25.11 ``` 1. **Schritt 4 — Aktualisieren Sie die Rechenknotengruppen und stellen Sie die Kapazität wieder her. ** Stellen Sie das 25.11-AMI auf jeder Rechenknotengruppe ein und stellen Sie die ursprünglichen Kapazitätsgrenzen wieder her (siehe[Schritt 4 — Compute-Knotengruppen aktualisieren und Kapazität wiederherstellen](#version_update-procedure-option2-step4)). ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} \ --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}' ``` **Anmerkung** Jeder Controller-Hop muss auf einer Version landen, die innerhalb des Kompatibilitätsfensters der vorherigen Version liegt. Informationen zur Suche nach gültigen Zwischenversionen finden Sie unter[Versionskompatibilität](working-with_clusters_version_update.md#version_update-cluster-compatibility). Die Flotte bleibt während der Schritte 3a und 3b auf Null, sodass keine AMI-Zwischenaktualisierungen erforderlich sind.