Lebenszyklus von Betriebssystemen

In diesem Dokument wird der Lebenszyklus einer Betriebssystemversion beschrieben – von der Erstellung bis zur End of Life-Phase (EOL-Phase).

Eine Betriebssystemversion durchläuft im Rahmen ihres Lebenszyklus zwei Hauptphasen:

  1. Mainstream-Support oder allgemeine Verfügbarkeit (GA)

  2. Eingestellt oder Ende des Supports (EOS): Diese Phase ist in die folgenden zwei Unterphasen unterteilt:

    1. Verlängerter Support
    2. Ende des Produktzyklus (End of Life, EOL)

Bei einigen Betriebssystemversionen kann es nach der Einstellung auch eine erweiterte Supportphase geben, bevor die endgültige Einstellung erfolgt.

In den folgenden Abschnitten werden die Lebenszyklusphasen einer Betriebssystemversion in der Compute Engine beschrieben.

Mainstream-Support oder allgemeine Verfügbarkeit (GA)

In dieser Phase finden die folgenden Prozesse statt:

  1. Wenn eine neue Betriebssystemversion eingeführt wird, erstellt der Anbieter des Betriebssystem-Images ein neues Betriebssystem-Image und weist ihm einen Namen zu, der der Benennungskonvention für diese Betriebssystemdistribution entspricht. Beispiel: debian-11-bullseye-v20230801.

  2. Der Bildanbieter erstellt dann eine neue Bildfamilie. Beispiel: debian-11..

    Mithilfe von Image-Familien können Sie Betriebssystem-Images in Ihrem Projekt so verwalten, dass ähnliche Images zusammengefasst werden und Rollforwards und Rollbacks zwischen bestimmten Betriebssystem-Image-Versionen möglich sind. Weitere Informationen finden Sie unter Best Practices für Image-Familien.

    Alle Aufrufe der Image-Familie verweisen auf dieses kürzlich erstellte Betriebssystem-Image. Wenn Sie beispielsweise beim Erstellen einer VM eine Imagefamilie angeben, indem Sie das Flag --image-family mit der entsprechenden --image-project verwenden, wird die neueste Version des Images verwendet.

  3. Gelegentlich wendet der Imageanbieter kritische Sicherheits- oder Fehlerkorrekturen, die vom Betriebssystemanbieter gesendet werden, auf das Betriebssystem-Image an. In diesen Updates werden möglicherweise neue Funktionen eingeführt. Wenn ein Update gesendet wird, geschieht Folgendes:

    • Das aktuelle Betriebssystem-Image wird aktualisiert und ein neuer Name generiert. Beispiel: Aus debian-11-bullseye-v20230801 mit den Updates wird debian-11-bullseye-v20230901..
    • Die Image-Familie debian-11 verweist jetzt auf das neue Betriebssystem-Image debian-11-bullseye-v20230901.
    • Das vorherige Betriebssystem-Image (debian-11-bullseye-v20230801) ist mit deprecated gekennzeichnet.

Einstellung oder Ende des Supports (EOS)

Jede Betriebssystemversion erreicht irgendwann die Phase der Einstellung. Informationen zu den Einstellungsdaten von Betriebssystemversionen finden Sie unter Details zu Betriebssystemen.

Verworfene Betriebssystemversionen befinden sich entweder in der Phase des erweiterten Supports oder im Endstadium des Lebenszyklus.

In dieser Phase stellen die Betriebssystemanbieter keine Image-Updates mehr bereit und die Betriebssystem-Images werden als verworfen gekennzeichnet. Sie können diese Betriebssystem-Images möglicherweise weiterhin verwenden, sind aber für die Beschaffung von Updates verantwortlich, die je nach Verfügbarkeit von der Betriebssystem-Distribution, dem Hersteller oder der Open Source-Community zur Verfügung gestellt werden.

Wenn für eine Betriebssystemversion das EOS erreicht wird, geschieht Folgendes:

  • Das neueste Image in der Image-Familie wird entweder gelöscht oder als veraltet markiert.

  • Sie können die Image-Familie nicht mehr verwenden. Sie können jedoch einige oder alle Betriebssystem-Images weiterhin verwenden, indem Sie sie direkt referenzieren, mit Ausnahme von Windows, bei dem alle Betriebssystem-Images am Ende des Lebenszyklus gelöscht werden.

    Wenn Sie eine VM aus einem verworfenen Image erstellen möchten, müssen Sie die gcloud CLI oder REST verwenden. Beim Angeben des Images müssen Sie das Flag --image verwenden, da Image-Familien nicht auf verworfene Images verweisen. Weitere Informationen zum Erstellen von VMs finden Sie unter VM-Instanz aus einem öffentlichen Image erstellen.

  • Wenn eine Betriebssystemversion die erweiterte Lebenszyklusphase erreicht oder überschreitet, kann Google die Funktionskompatibilität mit neuen Maschinenfamilien oder CPU-Plattformen für diese verworfenen Versionen nicht garantieren.

    Alle VMs, die Betriebssystem-Images verwenden, die zu dieser EOS-Betriebssystemversion gehören, funktionieren weiterhin in der Compute Engine und können auch nach dem EOS-Datum weiterhin Google Cloud -Support in Anspruch nehmen. Wenn jedoch Probleme mit der VM mit der eingestellten Betriebssystemversion zusammenhängen, kann Google das Problem möglicherweise nicht beheben, da der Support des Betriebssystemanbieters nicht mehr verfügbar ist.

Für eingestellte Betriebssystemversionen kann es sich entweder um eine Phase des erweiterten Supports oder um das Ende des Lebenszyklus handeln.

Verlängerter Support

Für einige Betriebssysteme stellen die jeweiligen Anbieter in der Phase der Einstellung ein Wartungs-, erweitertes oder langfristiges kostenpflichtiges Paket zur Verfügung, das auf Ihr Betriebssystem angewendet werden kann:

  • Für das Betriebssystem Red Hat Enterprise Linux (RHEL): Support für die Wartung, Erweiterte Lebensdauer, Extended Lifecycle Support ELS (Add-on) oder Extended Update Support (EUS)
  • Für Rocky Linux: Langzeitsupport kann bei CIQ erworben werden.
  • Für SUSE Linux Enterprise Server (SLES): Long Term Service Pack Support, Extended Service Pack Overlap Support (ESPOS)
  • Für Ubuntu Pro-Betriebssystem: Erweiterte Sicherheitswartung (ESM)
  • Für Windows-Betriebssysteme: Erweiterte Sicherheitsupdates

Weitere Informationen zu diesen erweiterten Lebenszykluspaketen finden Sie in der Dokumentation des Betriebssystemanbieters.

Ende des Produktzyklus (End of Life, EOL)

Für Betriebssysteme, für die der erweiterte Supportzeitraum abgelaufen ist, oder für Betriebssysteme, die keinen erweiterten Supportzeitraum unterstützen, gilt Folgendes:

  • Das neueste Image in der Image-Familie wird als veraltet gekennzeichnet oder aus Google Cloudgelöscht.

  • Die von Google bereitgestellte Software für die Gastumgebung wird für Betriebssystemversionen, die das Ende der Lebensdauer erreicht haben, nicht mehr aktualisiert. Repositories werden nicht mehr aktualisiert oder gepflegt.

  • Bei vorhandenen VMs, die EOL-Betriebssystemversionen verwenden, geschieht Folgendes:

    • Die VM kann keine Softwarepakete oder Updates vom Betriebssystemanbieter herunterladen oder installieren und Sicherheitsupdates sind nicht mehr verfügbar. Das liegt daran, dass Inhalte des Betriebssystemanbieters möglicherweise nicht mehr über die vorhandenen Kanäle verfügbar sind, da die konfigurierte Software-Repository-Infrastruktur des Betriebssystemanbieters möglicherweise deaktiviert oder archiviert wurde.
    • Die VM wird weiterhin ausgeführt, aber die laufende Kompatibilität ist nicht garantiert. Aktiver Support ist möglicherweise nicht vom Betriebssystemanbieter oder von Google verfügbar. Google kann Optionen für die Migration oder Upgrades auf neuere Betriebssystemversionen bereitstellen.

Namenskonvention für Betriebssystem-Images, Zeitplan für Updates und Einstellungsrichtlinie

In der folgenden Tabelle sind die Namenskonvention für Betriebssystem-Images und Imagefamilien, der Zeitplan für Updates und die geltende EOS-Richtlinie aufgeführt.

Definitionen

In der Tabelle werden die folgenden Notationen verwendet:

  • V ist die numerische Version des Betriebssystems. Beispiel: RHEL-7, wobei 7 die numerische Version ist
  • R ist der Release-String, der manchmal auch als Entwicklungscodename für das Betriebssystem bezeichnet wird. Beispiel: debian-12-bookworm-v20240213, wobei bookworm der Release-String ist. Release-Strings gelten nur für Debian- und Ubuntu-Betriebssystem-Images.
  • N ist die numerische Build-Nummer. Build-Nummern gelten nur für Container-Optimized OS und Fedora CoreOS.
  • YYYYMMDD ist das Jahr/Monat/Tag, an dem das Betriebssystem-Image erstellt oder veröffentlicht wurde. Bei einigen Betriebssystemen geht dem Datum ein kleines v voraus. Beispiel: vYYYYMMDD
Betriebssystem Image-Familie Betriebssystem-Image Zeitplan aktualisieren Einstellungsrichtlinie
CentOS Stream
  • centos-stream-V
  • centos-stream-V-arm64
  • centos-stream-V-vYYYYMMDD
  • centos-stream-V-arm64-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Container-Optimized OS
  • cos-V-lts
  • cos-arm64-V
  • cos-V-N
  • cos-arm64-V-N
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Debian
  • debian-V
  • debian-V-arm64
  • debian-V-R-vYYYYMMDD
  • debian-V-R-arm64-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Fedora CoreOS
  • fedora-coreos-R
  • fedora-coreos-R-arm64
  • fedora-coreos-V-YYYYMMDD-N-gcp-x86-64
  • fedora-coreos-V-YYYYMMDD-N-gcp-aarch64
 Kritische Fehler oder Sicherheitsprobleme Betriebssystem-Images werden am EOS-Datum gelöscht.
RHEL
  • rhel-V
  • rhel-V-arm64
  • rhel-V-vYYYYMMDD
  • rhel-V-arm64-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
RHEL BYOS
  • rhel-V-byos
  • rhel-V-byos-arm64
  • rhel-V-sap-byos
  • rhel-V-byos-vYYYYMMDD
  • rhel-V-byos-arm64-vYYYYMMDD
  • rhel-V-sap-byos-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
RHEL für SAP
  • rhel-V-sap-ha
  • rhel-V-sap-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Rocky Linux
  • rocky-linux-V
  • rocky-linux-V-arm64
  • rocky-linux-V-optimized-gcp
  • rocky-linux-V-optimized-gcp-arm64
  • rocky-linux-V-vYYYMMDD
  • rocky-linux-arm64-V-vYYYMMDD
  • rocky-linux-V-optimized-gcp-vYYYYMMDD
  • rocky-linux-V-optimized-gcp-arm64-vYYYYMMDD
 Monatlich Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
SQL Server auf Windows Server
  • sql-R-V-win-V
  • sql-V-R-windows-V-dc-vYYYYMMDD
 Monatlich Betriebssystem-Images werden am End of Service-Datum gelöscht.
SLES
  • sles-V
  • sles-V-arm64
  • sles-V-vYYYYMMDD-x86-64
  • sles-V-vYYYYMMDD-arm64
 Vierteljährlich Nur das neueste Betriebssystem-Image wird als verworfen markiert.

Eingestellte Betriebssystem-Images werden sechs Monate nach dem Einstellungsdatum gelöscht.
SLES für SAP
  • sles-V-sap
  • sles-V-sap-hardened
  • sles-V-sap-vYYYYMMDD-x86-64
  • sles-V-sap-hardened-vYYYYMMDD-x86-64
 Vierteljährlich Nur das neueste Betriebssystem-Image wird als verworfen markiert.

Eingestellte Betriebssystem-Images werden sechs Monate nach dem Einstellungsdatum gelöscht.
SLES for SAP BYOS
  • sles-V-byos
  • sles-V-byos-arm64
  • sles-V-sap-byos
  • sles-V-byos-vYYYYMMDD-x86-64
  • sles-V-byos-vYYYYMMDD-arm64
  • sles-V-sap-byos-vYYYYMMDD-x86-64
 Vierteljährlich Nur das neueste Betriebssystem-Image wird als verworfen markiert.

Eingestellte Betriebssystem-Images werden sechs Monate nach dem Einstellungsdatum gelöscht.
Ubuntu LTS
  • ubuntu-V-lts
  • ubuntu-V-lts-arm64
  • ubuntu-minimal-V-lts
  • ubuntu-minimal-V-lts-arm64
  • ubuntu-V-R-vYYYYMMDD
  • ubuntu-V-R-arm64-vYYYYMMDD
  • ubuntu-minimal-V-R-vYYYYMMDD
  • ubuntu-minimal-V-R-arm64-vYYYYMMDD
 Kritische Fehler oder Sicherheitsprobleme Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Ubuntu Pro
  • ubuntu-pro-V-lts
  • ubuntu-pro-V-lts-arm64
  • ubuntu-pro-fips-V-lts
  • ubuntu-pro-V-R-vYYYYMMDD
  • ubuntu-pro-V-R-arm64-vYYYYMMDD
  • ubuntu-pro-fips-V-R-vYYYYMMDD
 Kritische Fehler oder Sicherheitsprobleme Betriebssystem-Images werden als verworfen gekennzeichnet, können aber weiterhin verwendet werden.
Windows Server
  • windows-V
  • windows-V-core
  • windows-server-V-dc-vYYYYMMDD
  • windows-server-V-dc-core-vYYYYMMDD
 Monatlich Betriebssystem-Images werden am EOS-Datum gelöscht.

Nächste Schritte

  • Mehr über Betriebssysteme erfahren, die in Compute Engine verfügbar sind