Best Practices für Betriebssystemupgrades

In diesem Dokument werden Best Practices und Strategien für das Upgrade von Betriebssystemen auf Compute Engine-Instanzen beschrieben. Hier erfahren Sie, wie Sie Hauptversionen des Betriebssystems mithilfe von unveränderlicher Infrastruktur, dem Neuerstellen von Instanzen oder In-Place-Workflows aktualisieren und wie Sie das routinemäßige Patchen von Sicherheitslücken automatisieren.

Wenn eine Betriebssystemversion das Ende des Supports (End of Support, EOS) oder das Ende des Lebenszyklus (End of Life, EOL) erreicht, müssen Sie ein Upgrade auf eine unterstützte Betriebssystemversion durchführen, um Sicherheitsupdates, Softwarekompatibilität und die Integration der Google Cloud -Plattform zu erhalten. Weitere Informationen zu den Supportphasen finden Sie unter Lebenszyklus von Betriebssystemen.

Risiken bei direkten Upgrades von Hauptversionen des Betriebssystems

Wenn Sie ein großes In-Place-Upgrade des Betriebssystems durchführen, z. B. ein Upgrade von Debian 12 auf 13, von RHEL 9 auf 10 oder von Ubuntu 24.04 auf 26.04 auf einer laufenden Compute-Instanz, birgt dies erhebliche Betriebsrisiken in Cloud-Umgebungen. Im Gegensatz zu physischen On-Premise-Servern sind Ihre Compute-Instanzen auf spezielle Pakete für die Gastumgebung angewiesen, um mit dem Hypervisor und dem Compute Engine-Metadatenserver zu kommunizieren.

Wenn Sie ein Betriebssystem direkt aktualisieren, besteht das Risiko der folgenden Fehler:

  • Verlust der SSH- und RDP-Verbindung: Konfigurationsformate für Netzwerkdienste, Firewallregeln auf Gastebene wie ufw oder firewalld oder SSH-Daemon-Einstellungen können sich zwischen den Betriebssystemversionen ändern, wodurch der administrative Remotezugriff unterbrochen wird.
  • Unterbrechung der Gastumgebung:Die Pakete google-guest-agent und google-oslogin verwalten SSH-Schlüssel, Nutzerkonten, Netzwerkschnittstellen und die Synchronisierung mit Metadaten. Wenn Paket-Repositories oder ‑Abhängigkeiten während eines Distributionsupgrades beschädigt werden, wird der Gast-Agent möglicherweise beendet, wodurch weitere Anmeldungen oder die Netzwerkkonfiguration verhindert werden.
  • Inkompatibilitäten mit Speicher- und Kerneltreibern:Änderungen am Kernel, an initramfs oder an Treibern für Festplattencontroller (z. B. virtio-scsi oder NVMe) können zu Bootfehlern führen oder verhindern, dass die Compute-Instanz angehängte Persistent Disk-Volumes erkennt.
  • Inkonsistente Konfigurationen für Repositories:Betriebssystemanbieter stellen häufig die Unterstützung für alte Paket-Repositories und Signaturschlüssel ein oder ersetzen sie. Dadurch kann es passieren, dass Paketmanager während eines Upgrades fehlschlagen und das Betriebssystem in einem nicht wiederherstellbaren, halb installierten Zustand zurücklassen.

Um diese Risiken zu vermeiden, sollten Sie ein unveränderliches Infrastrukturmodell verwenden, anstatt Hauptversionen des Betriebssystems direkt auf Ihren Produktions-Compute-Instanzen zu aktualisieren.

Die richtige Upgradestrategie auswählen

Wählen Sie je nachdem, ob Ihre Arbeitslasten zustandslos oder zustandsorientiert sind, eine der folgenden Strategien aus:

Strategie Empfohlen für Risiko von Ausfallzeiten Rollback-Mechanismus
Nicht veränderbare Infrastruktur Zustandslose Arbeitslasten, verwaltete Instanzgruppen (MIGs), Microservices, Containerhosts Keine Ausfallzeiten durch rollierenden Austausch Instanzvorlage auf ein früheres Image zurücksetzen
Compute-Instanzen mit nichtflüchtigem Speicher neu erstellen Zustandsorientierte eigenständige Compute-Instanzen, Datenbanken mit angehängtem sekundären Speicher, Hosts für Legacy-Anwendungen Minimal mit geplantem Wartungsfenster Laufwerke wieder an die ursprüngliche Compute-Instanz anhängen oder Snapshots wiederherstellen
Direktes Upgrade des Betriebssystems Eigenständige Compute-Instanzen, bei denen Sie lokale Konfigurationen nicht automatisieren oder extrahieren können Hoch, erfordert Ausfallzeiten und manuelle Planung der Wiederherstellung Aus einem Snapshot eines nichtflüchtigen Speichers wiederherstellen

Unveränderliche Infrastruktur

Die sicherste und zuverlässigste Methode zum Aktualisieren Ihrer Betriebssysteme ist die Verwendung des unveränderlichen Infrastrukturmodells. Anstatt laufende Compute-Instanzen zu ändern, erstellen Sie neue Compute-Instanzen aus aktualisierten öffentlichen oder benutzerdefinierten Betriebssystem-Images und ersetzen Ihre alten Instanzen.

Wenn Ihre Arbeitslasten in verwalteten Instanzgruppen (Managed Instance Groups, MIGs) ausgeführt werden, können Sie diesen Roll-out ohne Dienstausfall automatisieren.

Aktualisiertes Bild erstellen

  1. Wählen Sie das neueste öffentliche Betriebssystem-Image aus der Liste der unterstützten Betriebssystemdetails aus oder erstellen Sie ein benutzerdefiniertes Basis-Image mit Image Builder oder automatisierten Tools wie Packer oder Ansible.
  2. Prüfen Sie, ob Ihre Anwendung und ihre Abhängigkeiten in einer Nicht-Produktions-Testumgebung mit der neuen Betriebssystemversion installiert und ausgeführt werden können.
  3. Erstellen Sie ein benutzerdefiniertes Betriebssystem-Image oder verweisen Sie auf die neue öffentliche Image-Familie. Weitere Informationen finden Sie unter Best Practices für Image-Familien.

Aktualisierte Instanzvorlage erstellen

Erstellen Sie eine neue Instanzvorlage, die auf das aktualisierte Betriebssystem-Image verweist:

gcloud compute instance-templates create NEW_TEMPLATE_NAME \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --machine-type=MACHINE_TYPE \
    --region=REGION

Ersetzen Sie Folgendes:

  • NEW_TEMPLATE_NAME: Name der neuen Instanzvorlage.
  • IMAGE_FAMILY: die Image-Familie des Zielbetriebssystems, z. B. debian-12 oder ubuntu-2404-lts.
  • IMAGE_PROJECT: Das Projekt, in dem das Bild gehostet wird, z. B. debian-cloud oder ubuntu-os-cloud.
  • MACHINE_TYPE: der Maschinentyp für Ihre Instanzen.
  • REGION: die Compute Engine-Region, in der Sie die Vorlage erstellen.

Rolling Replacement in der MIG durchführen

Wenden Sie die aktualisierte Vorlage auf Ihre verwaltete Instanzgruppe an und starten Sie einen rollierenden Austausch:

gcloud compute instance-groups managed rolling-action replace MIG_NAME \
    --max-surge=20% \
    --max-unavailable=0 \
    --region=REGION

Ersetzen Sie Folgendes:

  • MIG_NAME: Name Ihrer verwalteten Instanzgruppe.
  • REGION: Die Region, in der sich die MIG befindet. Ersetzen Sie bei zonalen MIGs --region=REGION durch --zone=ZONE.

Compute-Instanzen mit Persistent Disk neu erstellen

Wenn Sie zustandsorientierte eigenständige Compute-Instanzen ausführen, in denen Anwendungen Konfigurationen und Daten auf Persistent Disk-Volumes speichern, können Sie Ihr Betriebssystem aktualisieren, indem Sie die Compute-Instanz mit einem neuen Bootlaufwerk neu erstellen und gleichzeitig Ihre Datenlaufwerke beibehalten.

Alle Laufwerke sichern

Erstellen Sie vor dem Ändern der Infrastruktur Standard- oder regionale Snapshots des Bootlaufwerks und aller angehängten Persistent Disk-Volumes:

gcloud compute disks snapshot BOOT_DISK_NAME \
    --snapshot-names=SNAPSHOT_NAME \
    --zone=ZONE

Ersetzen Sie Folgendes:

  • BOOT_DISK_NAME: der Name des zu sichernden Bootlaufwerks.
  • SNAPSHOT_NAME: Der Name des neuen Snapshots für den nichtflüchtigen Speicher.
  • ZONE ist die Zone, in der sich das Laufwerk befindet.

Weitere Informationen finden Sie unter Snapshots erstellen und verwalten.

Anwendungsdaten vom Bootlaufwerk trennen

Achten Sie darauf, dass sich Anwendungsdaten, Datenbankdateien und Transaktionsprotokolle auf sekundären Persistent Disk-Volumes oder externen Diensten wie Cloud Storage oder Cloud SQL und nicht auf dem Bootlaufwerk befinden.

Ersatz-Compute-Instanz erstellen

  1. Beenden Sie die alte Compute-Instanz, um die Datenkonsistenz zu gewährleisten:

    gcloud compute instances stop LEGACY_INSTANCE_NAME --zone=ZONE

  2. Trennen Sie die sekundären Datenlaufwerke von der alten Compute-Instanz:

    gcloud compute instances detach-disk LEGACY_INSTANCE_NAME \
    --disk=DATA_DISK_NAME \
    --zone=ZONE

  3. Erstellen Sie eine neue Compute-Instanz mit der Ziel-Betriebssystemversion:

    gcloud compute instances create NEW_INSTANCE_NAME \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE

  4. Hängen Sie die vorhandenen sekundären Datenlaufwerke an die neue Compute-Instanz an:

    gcloud compute instances attach-disk NEW_INSTANCE_NAME \
    --disk=DATA_DISK_NAME \
    --zone=ZONE

  5. Stellen Sie eine Verbindung zur neuen Compute-Instanz her, hängen Sie die Dateisysteme auf den Datenträgern ein und starten Sie Ihre Anwendungsdienste.

  6. Weisen Sie bei Bedarf alle statischen externen IP-Adressen oder DNS-Einträge neu zu, damit sie auf die neue Compute-Instanz verweisen.

Ersetzen Sie Folgendes:

  • LEGACY_INSTANCE_NAME: Der Name der vorhandenen Compute-Instanz, die Sie aktualisieren.
  • DATA_DISK_NAME: der Name des sekundären Persistent Disk-Volumes, das getrennt und wieder angehängt werden soll.
  • NEW_INSTANCE_NAME: der Name der neuen Ersatz-Compute-Instanz.
  • IMAGE_FAMILY: Die Image-Familie für die Zielbetriebssystemversion, z. B. debian-13 oder ubuntu-2604-lts.
  • IMAGE_PROJECT: Das Projekt, das das Image bereitstellt, z. B. debian-cloud oder ubuntu-os-cloud.
  • MACHINE_TYPE: der Maschinentyp für die neue Compute-Instanz.
  • ZONE: die Zone, in der sich Ihre Compute-Instanzen befinden.

Direkte Betriebssystem-Upgrades

Wenn Sie Ihre Compute-Instanz aufgrund komplexer manueller Konfigurationen nicht neu erstellen können und ein In-Place-Upgrade durchführen müssen, führen Sie diese Prüfungen vor dem Upgrade durch und folgen Sie der distributionsspezifischen Anleitung sorgfältig.

Checkliste vor dem Upgrade

Führen Sie alle Schritte in dieser Checkliste aus, bevor Sie mit einem direkten Upgrade beginnen:

  1. Erstellen Sie einen Snapshot des Bootlaufwerks, bevor Sie Upgrade-Befehle ausführen. Dies ist Ihr primärer Wiederherstellungsmechanismus, wenn das Upgrade fehlschlägt.

  2. Aktualisieren Sie alle aktuellen Pakete und die Gastumgebung für Google Cloudauf die neuesten Versionen, die für Ihre aktuelle Betriebssystemversion verfügbar sind:

    • Debian und Ubuntu: sudo apt update && sudo apt dist-upgrade -y
    • Für RHEL, CentOS und Rocky Linux: sudo dnf upgrade -y
    • Für SLES: sudo zypper update

    Prüfen Sie, ob die Pakete google-guest-agent und google-oslogin aktiv sind:

    sudo systemctl status google-guest-agent

  3. Aktivieren Sie die interaktive serielle Konsole auf Ihrer Compute-Instanz, damit Sie Fehler beheben und sich anmelden können, wenn SSH oder das Netzwerk während des Upgrades nicht mehr funktionieren:

    gcloud compute instances add-metadata INSTANCE_NAME \
    --metadata=serial-port-enable=TRUE \
    --zone=ZONE

    Ersetzen Sie Folgendes:

    • INSTANCE_NAME: der Name Ihrer Compute-Instanz.
    • ZONE: die Zone, in der sich Ihre Compute-Instanz befindet.

    Weitere Informationen finden Sie unter Mit der seriellen Konsole interagieren.

  4. Wenn Sie OS Login oder vom Gast-Agent verwaltete SSH-Schlüssel verwenden, legen Sie ein Passwort für ein lokales Nutzerkonto mit Administratorberechtigungen fest, z. B. mit sudo passwd USERNAME. So können Sie sich über die serielle Konsole anmelden, wenn OS Login während des Upgrades vorübergehend nicht verfügbar ist. Ersetzen Sie USERNAME durch den Namen Ihres lokalen Nutzerkontos.

  5. Prüfen Sie, ob die Root-Partition / und die Bootpartition /boot ausreichend freien Speicherplatz haben. Es werden mindestens 5 GB empfohlen, um neue Pakete herunterzuladen und zu entpacken:

    df -h / /boot

  6. Prüfen Sie, ob Drittanbieter-Agents für Sicherheit, Sicherung oder Monitoring (einschließlich des Google Cloud Ops-Agents) die Zielversion des Betriebssystems unterstützen.

Direkte Upgrades

In den folgenden Abschnitten finden Sie allgemeine Workflows für gängige Betriebssysteme. Sehen Sie vor dem Upgrade immer in der offiziellen Upgrade-Dokumentation für Ihr Betriebssystem nach.

Debian

Sie können Debian zwischen aufeinanderfolgenden Hauptversionen aktualisieren. Überspringen Sie keine Hauptversionen. Führen Sie beispielsweise zuerst ein Upgrade von Debian 11 auf 12 und dann von Debian 12 auf 13 durch.

  1. Aktualisieren Sie die vorhandenen Debian-Paket-Repositories:

    sudo apt update && sudo apt upgrade -y && sudo apt dist-upgrade -y

  2. Aktualisieren Sie die Paketquellen in /etc/apt/sources.list und /etc/apt/sources.list.d/, indem Sie den aktuellen Release-Codenamen, z. B. bullseye, durch den Ziel-Release-Codenamen, z. B. bookworm, ersetzen. Achten Sie darauf, dass die URLs des Google Cloud -Paket-Repositorys mit der Neuveröffentlichung übereinstimmen.

  3. Führen Sie ein minimales Upgrade durch, um die wichtigsten Verpackungstools zu aktualisieren:

    sudo apt update
sudo apt upgrade --without-new-pkgs -y

  4. Führen Sie das Upgrade für die vollständige Bereitstellung aus:

    sudo apt full-upgrade -y

  5. Prüfen Sie, ob google-guest-agent aktiv und aktiviert ist:

    sudo systemctl enable --now google-guest-agent

  6. Starten Sie die Compute-Instanz neu:

    sudo systemctl reboot

Ubuntu

Verwenden Sie das Tool do-release-upgrade, um LTS-zu-LTS-Upgrades unter Ubuntu zu verwalten.

  1. Aktualisieren Sie alle aktuellen Pakete:

    sudo apt update && sudo apt dist-upgrade -y

  2. Installieren Sie das Kernpaket für den Update-Manager:

    sudo apt install update-manager-core -y

  3. Starten Sie das Tool für Release-Upgrades:

    sudo do-release-upgrade

  4. Folgen Sie den interaktiven Aufforderungen, um Repository-Updates und Paket-Ersetzungen zu bestätigen. Wenn Sie aufgefordert werden, geänderte Konfigurationsdateien zu überschreiben, prüfen Sie die Unterschiede sorgfältig.

  5. Starten Sie die Compute-Instanz neu, wenn Sie dazu aufgefordert werden.

RHEL

Verwenden Sie zum Upgrade zwischen Hauptversionen von RHEL das unterstützte Red Hat-leapp-Dienstprogramm.

  1. Prüfen Sie den Status Ihres Red Hat-Abos und stellen Sie sicher, dass die Compute-Instanz eine Verbindung zur Compute Engine Red Hat Update Infrastructure (RHUI) herstellt.
  2. Installieren Sie das Leapp-Tool und die Pakete, die Migrationsdaten enthalten.

  3. Führen Sie die Vorabprüfung für das Upgrade aus:

    sudo leapp preupgrade

  4. Sehen Sie sich den Bericht in /var/log/leapp/leapp-report.txt an und beheben Sie alle Probleme, die Leapp als „Inhibitor“ identifiziert.

  5. Führen Sie das Upgrade aus:

    sudo leapp upgrade

  6. Starten Sie die Instanz neu, damit Leapp das Betriebssystemupgrade in einer isolierten Umgebung durchführen kann:

    sudo reboot

SLES

Verwenden Sie zypper, um Service Pack-Migrationen und Distributions-Upgrades der Hauptversion auf SLES durchzuführen:

  1. Vorhandenes System aktualisieren:

    sudo zypper patch

  2. Führen Sie zypper migration aus, um eine Onlinemigration durchzuführen, oder folgen Sie dem Workflow für das Upgrade der Distribution mit zypper dup, wie in der SLES-Upgradedokumentation beschrieben.

Windows

Für Windows Server-Compute-Instanzen können Sie Installationsmedien mit Compute Engine-Volumenlizenzen und PowerShell-Skripts verwenden, um Upgrades ohne manuellen Eingriff zu automatisieren.

Wenn Sie ein direktes Upgrade von Windows Server durchführen möchten, folgen Sie der Anleitung unter Direktes Upgrade von Windows Server durchführen.

Patchverwaltung für kleinere Updates automatisieren

Unterscheiden Sie zwischen Upgrades von Hauptbetriebssystemversionen und routinemäßigen Nebenversionsupdates und Sicherheitspatches. Verwenden Sie VM Manager Patch für die regelmäßige Wartung von Software, Paketaktualisierungen und das Patchen von CVEs, um die Bereitstellung von Patches für Ihre Compute-Instanzen zu automatisieren.

Beachten Sie die folgenden Best Practices, um Patches automatisch zu verwalten:

  • Instanzen mit Labels organisieren:Weisen Sie Labels mit Metadaten wie env:dev, env:prod und tier:frontend zu, um bestimmte Gruppen von Compute-Instanzen für Patches anzusprechen.
  • Zone für Zone bereitstellen:Patch-Jobs über Zonen und Regionen hinweg staffeln. Wenden Sie Patch-Jobs in Produktionsumgebungen niemals gleichzeitig auf alle Zonen an.
  • Pre-Patch- und Post-Patch-Skripts verwenden:Konfigurieren Sie Pre-Patch-Skripts, um Verbindungen sicher zu trennen oder Dienste zu pausieren, und Post-Patch-Skripts, um Systemdiagnosen auszuführen, bevor Instanzen wieder in Betrieb genommen werden.
  • Patch-Compliance überwachen:Mit dem Dashboard für VM Manager in derGoogle Cloud Console können Sie die Compliance mit Patches und den Status von Sicherheitslücken in Ihrer Flotte von Compute-Instanzen verfolgen.

Weitere Informationen finden Sie unter Patch-Jobs erstellen.

Überprüfung und Fehlerbehebung nach dem Upgrade

Führen Sie nach Abschluss eines Upgrades die folgenden Überprüfungsschritte aus:

  1. Prüfen Sie, ob die SSH- oder RDP-Verbindung normal hergestellt wird.

  2. Prüfen Sie, ob der Gast-Agent und der Dienst für OS Login aktiv sind und einen fehlerfreien Status melden:

    sudo systemctl status google-guest-agent
sudo systemctl status google-oslogin-cache

  3. Prüfen Sie, ob die Compute-Instanz den Instanz-Metadatenserver abfragen kann:

    curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/id

  4. Prüfen Sie, ob Ihre Anwendungsdienste gestartet wurden und ob die Systemdiagnosen von Load Balancern fehlerfreie Instanzen melden.

Verbindungsabbrüche beheben

Wenn Sie nach einem In-Place-Upgrade den SSH- oder RDP-Zugriff auf die Compute-Instanz verlieren, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

  1. Prüfen Sie das Konsolenlog auf Kernel Panics, Fehler beim Starten des Dienstes oder Fehler bei der Netzwerkinitialisierung:

    gcloud compute instances tail-serial-port-output INSTANCE_NAME \
    --zone=ZONE

  2. Wenn Sie die interaktive serielle Konsole vor dem Upgrade aktiviert haben, stellen Sie direkt eine Verbindung zum Terminal her:

    gcloud compute connect-to-serial-port INSTANCE_NAME \
    --zone=ZONE

    Melden Sie sich mit Ihren lokalen Nutzeranmeldedaten an, prüfen Sie die Systemlogs mit journalctl -xe und starten Sie das Netzwerk oder den google-guest-agent-Dienst neu.

    Ersetzen Sie Folgendes:

    • INSTANCE_NAME: der Name der Compute-Instanz, für die Sie eine Fehlerbehebung ausführen.
    • ZONE: die Zone, in der sich die Compute-Instanz befindet.

  3. Wenn das Betriebssystem nicht gestartet oder wiederhergestellt werden kann, erstellen Sie aus dem Snapshot, den Sie vor dem Upgrade erstellt haben, ein neues Volume für den nichtflüchtigen Speicher und hängen Sie es als Bootlaufwerk der Compute-Instanz an. Eine ausführliche Anleitung zur Wiederherstellung finden Sie unter Snapshot auf einem neuen Laufwerk wiederherstellen.

Nächste Schritte