Hostwartung für Knoten durchführen, auf denen Trainings- und Inferenzarbeitslasten ausgeführt werden

In diesem Dokument wird beschrieben, wie Sie die Hostwartung der zugrunde liegenden Compute Engine-Instanzen für Knoten in Google Kubernetes Engine-Clustern (GKE) durchführen. Sie müssen diese Wartung nur für bestimmte Arten von Compute Engine-Instanzen aktiv verwalten, die nicht live migriert werden, einschließlich Instanzen mit GPUs und TPUs. Die in diesem Dokument beschriebenen Strategien eignen sich gut für Trainings- und Inferenz-Workloads. Wenn Sie die Hostwartung nur für einen einzelnen Knoten manuell durchführen müssen oder Ihre Arbeitslasten die automatische Hostwartung tolerieren, lesen Sie den Abschnitt Hostwartung in GKE durchführen.

Mit diesen Strategien wird die Hostwartung für Knotengruppen durchgeführt und optional werden GKE-Cluster-Upgrades initiiert.

Verwenden Sie die parallele Strategie für die Knoten von Arbeitslasten, bei denen es nur eine Ausfallzeit geben kann, z. B. für die Knoten von Trainingsarbeitslasten. Verwenden Sie die Rolling-Strategie für die Knoten von Arbeitslasten, bei denen Sie Batch-Ausfallzeiten in Kauf nehmen können, während die Verfügbarkeit der meisten Ressourcen aufrechterhalten wird, z. B. für die Knoten von Inferenzarbeitslasten.

Parallele Strategie zum Aktualisieren der Knoten von Trainingsarbeitslasten verwenden

Bei dieser Strategie werden Änderungen gleichzeitig für eine Gruppe von Knoten vorgenommen, die Beschleuniger verwenden. Sie können diese Strategie für Trainingsarbeitslasten verwenden. Alternativ können Sie sie für andere Arten von Arbeitslasten verwenden, bei denen die am wenigsten störende Methode zum Ausführen von Änderungen darin besteht, ein einzelnes Zeitfenster mit vollständiger Ausfallzeit für alle Knoten in der Gruppe und die darauf ausgeführten Arbeitslasten zu haben.

Die Strategie umfasst die folgenden allgemeinen Schritte:

  1. Arbeitslasten beenden: Wählen Sie die Knotenpools aus und beenden Sie entweder die darauf ausgeführten Arbeitslasten oder verschieben Sie die Arbeitslasten auf andere Knoten, die weiterhin verfügbar sind.
  2. Hostwartung auslösen: Wenden Sie das Wartungslabel gleichzeitig auf alle ausgewählten Knoten an und warten Sie, bis der Vorgang auf allen Knoten abgeschlossen ist.
  3. GKE-Version aktualisieren: Ändern Sie die GKE-Version der Knoten.
  4. Arbeitslasten neu starten: Starten Sie Ihre Arbeitslasten neu, nachdem alle Hostwartungen und ‑upgrades abgeschlossen sind.

Die bereitgestellten Anleitungen beziehen sich auf Änderungen für einen einzelnen Knotenpool. Sie können die Schritte jedoch anpassen, um Änderungen für mehrere Knotenpools gleichzeitig vorzunehmen. Achten Sie darauf, dass Sie vor Beginn dieser Schritte mindestens einige Stunden Zeit haben, in denen diese Arbeitslast nicht auf diesen Knoten ausgeführt werden muss.

Um Unterbrechungen zu minimieren, wenn wichtige Änderungen sowohl für die zugrunde liegenden Compute Engine-Instanzen als auch für die GKE-Knoten vorgenommen werden, nutzen Sie diese Ausfallzeit, um sowohl die Hostwartung als auch die GKE-Versionsupgrades durchzuführen. Sie können jedoch nur die Hostwartung durchführen, wenn Sie die Version Ihrer GKE-Knoten nicht aktualisieren möchten.

Hinweise

Lesen Sie sich die folgenden Hinweise durch, bevor Sie beginnen:

  • Neu bereitgestellte Arbeitslasten vermeiden: Um unnötige Verzögerungen aufgrund von PodDisruptionBudgets zu vermeiden, sollten Sie keine Arbeitslasten neu bereitstellen, bis Sie alle Schritte ausgeführt haben.
  • Unterbrechungen einplanen: Sorgen Sie dafür, dass Ihre Arbeitslasten für einen bestimmten Zeitraum unterbrochen werden können. Diese Schritte dauern mehrere Stunden, hauptsächlich aufgrund der Zeit, die für die Hostwartung erforderlich ist.

Updates für alle Knoten gleichzeitig durchführen

Führen Sie die folgenden Schritte aus, um die Hostwartung und optional GKE-Versionsupgrades durchzuführen:

  1. Arbeitslasten vorbereiten: Beenden Sie Ihre Arbeitslasten oder sorgen Sie dafür, dass sie einen aktuellen Snapshot oder Prüfpunkt erstellt haben.

  2. Hostwartung starten und überwachen:

    • Unterblöcke aus Reservierungen, für die die gruppierte Wartungsplanung verwendet wird: Sie können die Wartung für Reservierungen, Reservierungsblöcke oder Reservierungsunterblöcke mit dem entsprechenden Unterbefehl gcloud compute reservations auslösen. Mit dem folgenden Befehl wird beispielsweise die Wartung für einen Unterblock gestartet:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: der Name des Reservierungsblocks.
      • SUB_BLOCK_NAME: der Name des Reservierungsunterblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.

      Compute Engine beginnt gleichzeitig mit dem Leeren und Aktualisieren aller Instanzen im Unterblock. Dieser Vorgang kann einige Stunden dauern.

      Sie können den Status der Wartung überwachen, indem Sie das Metadatenfeld upcomingGroupMaintenance in den Reservierungsressourcen prüfen. Weitere Informationen finden Sie unter Wartungsstatus ansehen.

    • Instanzen, die eine unabhängige Wartungsplanung verwenden: Lösen Sie die Wartung für On-Demand-Instanzen oder für Reservierungen aus, die keine Unterblöcke verwenden, indem Sie das Label cloud.google.com/perform-maintenance=true auf die Knoten in Ihrem Knotenpool anwenden:

      kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite

      Compute Engine beginnt gleichzeitig mit dem Leeren und Aktualisieren der zugrunde liegenden Instanzen. Dieser Vorgang kann einige Stunden dauern. Weitere Informationen finden Sie unter Ablauf der ordnungsgemäßen Beendigung.

      Prüfen Sie die Knoten, um den Status der Wartung zu überwachen. GKE entfernt das Wartungslabel nach Abschluss der Wartung, sofern es angewendet wurde. Nach Abschluss der Wartung finden Sie in Cloud Logging einen Logeintrag mit der folgenden Meldung:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

  3. Optional: Version der GKE-Knoten aktualisieren: Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

Rolling-Strategie zum Aktualisieren der Knoten von Inferenzarbeitslasten verwenden

In dieser Strategie wird ein manueller Ansatz für die Wartung von GKE-Knoten beschrieben, auf denen Inferenzarbeitslasten ausgeführt werden. Dabei werden Knoten in Batches aktualisiert, um die Dienstverfügbarkeit aufrechtzuerhalten. Diese Methode eignet sich am besten für Arbeitslasten, bei denen ein bestimmter Prozentsatz von Replikaten vorübergehend offline sein kann.

Die Strategie umfasst die folgenden allgemeinen Schritte:

  1. Knoten identifizieren und in Batches zusammenfassen: Wählen Sie die Knotenpools aus, die aktualisiert werden sollen. Gruppieren Sie die Knoten in Batches, deren Größe der Fehlertoleranz Ihrer Arbeitslast entspricht.
  2. Batches durchlaufen: Wenden Sie für jeden Batch das Wartungslabel an und beobachten Sie den Batch von Knoten, bis das Label entfernt wird.
  3. GKE-Version aktualisieren: Nachdem alle Batches die Hostwartung abgeschlossen haben, ändern Sie die Version der GKE-Knoten.

Hinweise

Lesen Sie sich die folgenden Hinweise durch, bevor Sie beginnen:

  • Bereitstellung verstehen: Für den Erfolg sind detaillierte Kenntnisse der Verteilung der Arbeitslast, der Platzierung von Replikaten und der Fehlerdomains erforderlich. Achten Sie darauf, dass Sie während des gesamten Prozesses über ausreichend Kapazität für die Bereitstellung verfügen.
  • Batchgrößen planen: Knoten in Batches aktualisieren. Die Größe der einzelnen Batches wird durch die Fehlertoleranz Ihrer Arbeitslast bestimmt. Dazu gehören unter anderem folgende Faktoren:
    • Die Anzahl der Replikate pro Serving-Modell.
    • Die Verteilung von Replikaten auf Knoten und Ausfalldomains.
    • Mit PodDisruptionBudgets können Sie die maximale Anzahl von Pods erzwingen, die gleichzeitig nicht verfügbar sind.
    • Empfehlung: Um die Verwaltung zu vereinfachen, sollten Sie verschiedene Knotenpools für verschiedene Replikatsätze verwenden. So können Sie Fehlerdomains auf Knotenpoolebene isolieren.
  • Zeitliche Einschränkungen berechnen: Berücksichtigen Sie die folgenden Zeitfaktoren:
    • Die Durchführung des Hostwartungsschritts kann für jeden Batch mehrere Stunden dauern.
    • Berechnen Sie die Mindestbatchgröße, damit alle Wartungsarbeiten innerhalb der erforderlichen Fristen abgeschlossen werden können:
      1. MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4), wobei HOURS_TO_MAINTENANCE die insgesamt verfügbare Zeit ist.
      2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
    • Die ausgewählte Batchgröße muss mindestens MIN_PER_BATCH betragen.
  • Bestimmte Arbeitslasttypen prüfen: Berücksichtigen Sie für die jeweiligen Konfigurationstypen Folgendes:
    • Mixture of Experts (MOE): Achten Sie darauf, dass mit Ihrer Batching-Strategie die erforderliche Mindestanzahl an Replikaten für jedes Modell beibehalten wird.
    • Disaggregated Serving: Achten Sie darauf, dass Sie beim Planen von Batches alle Replikate berücksichtigen, die an der disaggregierten Einrichtung beteiligt sind.
    • Knotenpools mit mehreren Hosts (TPU, MNNVL): Bei diesen Konfigurationen wird wahrscheinlich jeweils ein ganzer Knotenpool heruntergefahren. Planen Sie Ihre Ausfalldomänen entsprechend über mehrere Knotenpools hinweg.

Rolling Updates in Batches durchführen

Wenn Sie rollierende Wartungsupdates für Hosts durchführen möchten, können Sie die Kapazität aus Reservierungen, für die die gruppierte Wartungsplanung verwendet wird, in Batches von einem oder mehreren Unterblöcken aktualisieren. Alternativ können Sie bestimmte Knotengruppen im Cluster anhand des Namens mit unabhängiger Wartungsplanung aktualisieren.

Wählen Sie die passende Strategie für Ihre Ressourcen aus:

Reservierungen in Batches von Unterblöcken aktualisieren

So führen Sie die fortlaufende Hostwartung für Kapazitätsreservierungen in Batches von Unterblöcken durch:

  1. Reservierungen für die Wartung identifizieren: Ermitteln Sie den Namen der Kapazitätsreservierung und die Reservierungsblöcke oder ‑unterblöcke, die vom GKE-Cluster verwendet werden. Führen Sie dazu eine Suche mit GKE-Knotenlabels und dem Befehl gcloud compute reservations aus:

    1. Listen Sie den Reservierungsnamen und die IDs der physischen Block- und Unterblocktopologie der Knoten in Ihrem Knotenpool auf:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
    -o custom-columns='NAME:.metadata.name,RESERVATION:.metadata.labels.cloud\.google\.com/reservation-name,BLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-subblock'

      Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

      Notieren Sie sich die Ausgabewerte: den Reservierungsnamen (z. B. nvidia-gb300-m7kp2xq9vd4j1), die Block-ID (z. B. 3f2a8c9b1d4e0756f8a2b3c1d9e4f0a5) und die Unterblock-ID (z. B. e7b91f4a3c2d58069e1a4b7f3d2c8056).

    2. Um den Ressourcennamen des Reservierungsblocks zu ermitteln, fragen Sie die Liste der Compute Engine-Reservierungsblöcke mit dem Reservierungsnamen ab und filtern Sie nach der Block-ID:

      gcloud compute reservations blocks list RESERVATION_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.block=BLOCK_ID"

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.
      • PROJECT_ID: die Projekt-ID, in der die Reservierung vorhanden ist.
      • BLOCK_ID: Die Block-ID, die aus den Knotenlabels abgerufen wurde.

      Notieren Sie sich den Namen des Blocks aus der Ausgabe.

    3. Wenn Sie den Ressourcennamen des Reservierungsunterblocks ermitteln möchten, fragen Sie die Liste der Reservierungsunterblöcke mit dem Reservierungsnamen und dem Blocknamen ab und filtern Sie nach der Unterblock-ID:

      gcloud compute reservations sub-blocks list RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.subBlock=SUBBLOCK_ID"

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: Der Ressourcenname des Reservierungsblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.
      • PROJECT_ID: die Projekt-ID, in der die Reservierung vorhanden ist.
      • SUBBLOCK_ID: Die ID des Unterblocks, die aus den Knotenlabels abgerufen wurde.

      Die Ausgabe enthält Details zum übereinstimmenden Reservierungsunterblock, einschließlich des zugehörigen Ressourcennamens.

  2. Reservierungen in Batches aufteilen: Teilen Sie die ermittelten Unterblöcke für die Kapazitätsreservierung in gleich große Batches auf. Bestimmen Sie die Batchgröße anhand der Formel, die im Listenelement Zeitbeschränkungen berechnen im vorherigen Abschnitt Überlegungen vor dem Beginn beschrieben wird. Jeder Batch entspricht einem oder mehreren Reservierungsunterblöcken und muss mindestens die Größe eines Unterblocks haben.

  3. Hostwartung durchführen: Führen Sie für jeden Batch die folgenden Schritte aus:

    1. Wählen Sie eine Gruppe von Reservierungsunterblöcken aus und lösen Sie die Hostwartung aus. Sie können die Wartung für Ihre Reservierungen, Reservierungsblöcke oder Reservierungsunterblöcke auslösen. Bei Maschinentypen wie A4X, A4X Max, TPU v6e und TPU7x müssen Sie die Wartung auf diese Weise auslösen. Die Wartung erfolgt in Gruppen von Unterblöcken. Führen Sie den Befehl gcloud compute reservations sub-blocks perform-maintenance aus:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

      Ersetzen Sie Folgendes:

      • RESERVATION_NAME: der Name der Reservierung.
      • BLOCK_NAME: der Name des Reservierungsblocks.
      • SUB_BLOCK_NAME: der Name des Reservierungsunterblocks.
      • ZONE: die Zone, in der die Reservierung vorhanden ist.

      Compute Engine beginnt gleichzeitig mit dem Leeren und Aktualisieren aller Instanzen im Unterblock. Dieser Vorgang kann einige Stunden dauern.

    2. Sie können den Status der Wartung überwachen, indem Sie den Status des Metadatenfelds upcomingGroupMaintenance in den Reservierungsressourcen prüfen. Weitere Informationen finden Sie unter Wartungsstatus von Reservierungen ansehen.

    3. Wiederholen Sie die vorherigen Schritte für jeden verbleibenden Batch, bis Sie die Hostwartung für alle Batches abgeschlossen haben.

  4. Optional: Version der GKE-Knoten aktualisieren: Führen Sie diesen Schritt erst aus, nachdem die Hostwartung für alle Reservierungsunterblöcke abgeschlossen ist, um Szenarien zu vermeiden, in denen die GKE-Knoten auf Hosts bereitgestellt werden, bei denen die Wartung noch nicht abgeschlossen ist. Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

Knoten in Batches aktualisieren

So führen Sie die fortlaufende Hostwartung für On-Demand-Instanzen oder Reservierungen durch, die keine Subblöcke in Batches unterstützen:

  1. Knoten für die Wartung identifizieren: Identifizieren Sie alle Knoten, für die Sie eine Wartung durchführen möchten, und speichern Sie diese Liste. Verwenden Sie eine der folgenden Methoden, um Knoten zu identifizieren oder manuell auszuwählen:

    • Alle Knoten im Cluster abrufen, die Beschleuniger (TPUs oder GPUs) verwenden:

      kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'

    • Alle Knoten in einem bestimmten Knotenpool abrufen:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"

      Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

    • Alle Knoten mit einem bestimmten Label abrufen:

      kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'

      Ersetzen Sie LABEL durch das Knotenlabel.

  2. Knoten in Batches aufteilen: Teilen Sie die ermittelten Knoten in gleich große Batches auf. Bestimmen Sie die Batchgröße anhand der Formel, die im Listenelement Zeitbeschränkungen berechnen im vorherigen Abschnitt Überlegungen vor dem Beginn beschrieben wird.

  3. Hostwartung durchführen: Führen Sie für jeden Batch die folgenden Schritte aus:

    1. Wählen Sie eine Gruppe von Knoten aus und lösen Sie die Wartung auf Instanzebene mit der instances API aus, indem Sie das Wartungslabel anwenden:

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite

      Ersetzen Sie LIST_OF_NODES_IN_BATCH durch eine durch Leerzeichen getrennte Liste von Knoten aus dem Batch. Beispiel: node-1 node-2 node-3

      Compute Engine beginnt gleichzeitig mit dem Leeren und Aktualisieren der zugrunde liegenden Instanzen. Dieser Vorgang kann einige Stunden dauern. Weitere Informationen finden Sie unter Ablauf der ordnungsgemäßen Beendigung.

    2. Status der Hostwartung überwachen GKE entfernt das Wartungslabel, wenn die Wartung abgeschlossen ist, sofern es angewendet wurde. Nach Abschluss der Wartungsarbeiten finden Sie in Logging ein Log mit der folgenden Meldung:

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

    3. Wiederholen Sie die vorherigen Schritte für jeden verbleibenden Batch, bis Sie die Hostwartung für alle Batches abgeschlossen haben.

  4. Optional: Version der GKE-Knoten aktualisieren: Führen Sie diesen Schritt erst aus, wenn die Hostwartung für alle Knoten abgeschlossen ist, um Szenarien zu vermeiden, in denen die GKE-Knoten auf Hosts bereitgestellt werden, bei denen die Wartung noch nicht abgeschlossen ist. Folgen Sie der Anleitung zum Aktualisieren der GKE-Version der Knoten.

GKE-Version der Knoten aktualisieren

Berücksichtigen Sie die Anzahl der Knoten, die Sie gleichzeitig aktualisieren möchten. Bei der parallelen Strategie wurde die Hostwartung für den gesamten Knotenpool oder mehrere Knotenpools gleichzeitig durchgeführt. Bei der rollierenden Strategie haben Sie die Hostwartung in Batches durchgeführt. Legen Sie anhand der Größe der Knotengruppen fest, welche Upgrademethode Sie verwenden möchten:

  • Parallele Strategie: Wenn Ihre Knotenpools jeweils 100 oder weniger Knoten pro Zone haben, verwenden Sie Surge-Upgrades. Wenn Ihre Knotenpools jeweils mehr als 100 Knoten pro Zone haben, löschen Sie die Knotenpools und erstellen Sie sie neu.
  • Rolling-Strategie: Wenn Ihre Batches 100 Knoten pro Zone, pro Knotenpool oder weniger haben, verwenden Sie Surge-Upgrades. Wenn Ihre Batches mehr als 100 Knoten pro Zone und Knotenpool enthalten, löschen Sie die Knoten und erstellen Sie sie neu.

Surge-Upgrades verwenden

  1. Konfigurieren Sie Surge-Upgrades mit der Einstellung maxUnavailable, um festzulegen, wie viele Knoten in einem Knotenpool gleichzeitig pro Zone nicht verfügbar sein können. Wenn Sie beispielsweise 18 Knoten in einer Zone in einem Knotenpool haben, legen Sie den Wert des Felds maxUnavailable auf 18 fest.

    Diese Einstellung funktioniert am besten, wenn Sie Kapazität aus einer Reservierung verwenden, in der Sie keine überschüssige Kapazität haben. Weitere Informationen dazu, warum Sie diese Einstellung verwenden sollten, finden Sie unter Upgrade in einer ressourcenknappen Umgebung.

  2. Führen Sie mit dem folgenden Befehl ein Upgrade des Knotenpools aus. Wenn Sie mehrere Knotenpools aktualisieren möchten, führen Sie diesen Befehl für jeden Knotenpool aus:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool NODE_POOL_NAME \
    --cluster-version VERSION \
    --location CONTROL_PLANE_LOCATION \
    --quiet

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • NODE_POOL_NAME ist der Name des Knotenpools.
    • VERSION: Ein empfohlenes Ziel für das automatische Upgrade für den Knotenpool. Weitere Informationen finden Sie unter Informationen zu Upgrades für Knotenpools von Standardclustern abrufen. Wenn für Ihren Cluster kein empfohlenes Ziel für automatische Upgrades vorhanden ist, sehen Sie in den GKE-Versionshinweisen unter Versionsupdates nach.
    • CONTROL_PLANE_LOCATION: Der Standort der Steuerungsebene Ihres Clusters.

Knoten löschen und neu erstellen

Löschen Sie den Knotenpool und erstellen Sie ihn mit der neueren Version neu:

  1. Löschen Sie den Knotenpool:

    gcloud container node-pools delete NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

  2. Erstellen Sie den Knotenpool noch einmal und übergeben Sie die neue Version mit dem Flag --cluster-version. Übergeben Sie das empfohlene Ziel für automatische Upgrades für den Knotenpool. Weitere Informationen finden Sie unter Informationen zu Upgrades für Knotenpools von Standardclustern abrufen. Wenn für Ihren Cluster kein empfohlenes Ziel für automatische Upgrades vorhanden ist, sehen Sie in den GKE-Versionshinweisen unter Versionsupdates nach.