Diese Seite wurde von der Cloud Translation API übersetzt.

Lebenszyklus von Betriebssystemen

Linux Windows

In diesem Dokument wird der Lebenszyklus einer Betriebssystemversion beschrieben – von der Erstellung bis zum Ende des Lebenszyklus (End of Life, EOL).

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

Mainstream-Support oder allgemeine Verfügbarkeit (GA)
Eingestellt oder Ende des Supports (End of Support, EOS): Diese Phase ist in die folgenden zwei Unterphasen unterteilt:
1. Verlängerter Support
2. End of Life (EOL)

Bei einigen Betriebssystemversionen kann es nach der Markierung als veraltet auch eine verlängerte Supportphase geben, bevor sie das vollständige EOL erreichen.

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

Mainstream-Support oder allgemeine Verfügbarkeit (GA)

In dieser Phase finden die folgenden Prozesse statt:

Mit der Einführung einer neuen Betriebssystemversion erstellt der Betriebssystem-Image-Anbieter ein neues Betriebssystem-Image und weist ihm einen Namen zu, der der Namenskonvention für diese Betriebssystemdistribution entspricht. Beispiel: debian-11-bullseye-v20230801.
Der Bildanbieter erstellt dann eine neue Image-Familie. Beispiel: debian-11..

Image-Familien helfen Ihnen, Betriebssystem-Images in Ihrem Projekt zu verwalten, indem ähnliche Images zusammengefasst werden, sodass Sie Rollforwards und Rollbacks zwischen bestimmten Betriebssystem-Image-Versionen durchführen können. Weitere Informationen finden Sie unter Best Practices für Image-Familien.

Alle Aufrufe der Image-Familie verweisen auf dieses neu erstellte Betriebssystem-Image. Wenn Sie beispielsweise beim Erstellen einer VM eine Imagefamilie angeben, indem Sie das Flag --image-family mit dem entsprechenden --image-project verwenden, wird die neueste Version des Images verwendet.
Gelegentlich wendet der Bildanbieter 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, passiert Folgendes:
- Das aktuelle Betriebssystem-Image wird aktualisiert und ein neuer Name wird 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.

Eingestellt oder Ende des Supports (EOS)

Irgendwann erreicht jede Betriebssystemversion die Phase der Einstellung. Die Einstellungsdaten für Betriebssystemversionen finden Sie unter Details zu Betriebssystemen.

Verworfene Betriebssystemversionen können sich entweder in einer Phase mit erweitertem Support oder am Ende des Lebenszyklus befinden.

In dieser Phase stellen Betriebssystemanbieter keine Image-Updates mehr bereit und die Betriebssystem-Images werden als verworfen markiert. 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 eine Betriebssystemversion das EOS erreicht, geschieht Folgendes:

Das neueste Image in der Image-Familie wurde entweder gelöscht oder als verworfen markiert.
Sie können die Image-Familie nicht mehr verwenden. Sie können jedoch weiterhin einige oder alle Betriebssystem-Images verwenden, indem Sie direkt darauf verweisen. Eine Ausnahme bildet Windows, wo alle Betriebssystem-Images bei EOS 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, garantiert Google keine Feature-Kompatibilität mit neuen Maschinenfamilien oder CPU-Plattformen für diese verworfenen Versionen.

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

Verworfene Betriebssystemversionen können sich entweder in einer Phase des erweiterten Supports oder am Ende des Lebenszyklus befinden.

Verlängerter Support

Für einige Betriebssysteme bieten Betriebssystemanbieter ein kostenpflichtiges Wartungs-, erweitertes oder langfristiges Paket an, das auf Ihr Betriebssystem angewendet werden kann, wenn es die Einstellungsphase erreicht:

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 das Betriebssystem SUSE Linux Enterprise Server (SLES): Long Term Service Pack Support, Extended Service Pack Overlap Support (ESPOS)
Für Ubuntu Pro-Betriebssystem: Erweiterte Sicherheitswartung (ESM)
Windows-Betriebssystem: Erweiterte Sicherheitsupdates

Weitere Informationen zu diesen Paketen mit verlängertem Lebenszyklus finden Sie in der Dokumentation des Betriebssystemanbieters.

End of Life (EOL)

Bei Betriebssystemen, bei denen der erweiterte Supportzeitraum abgelaufen ist, oder bei Betriebssystemen, die keinen erweiterten Supportzeitraum unterstützen, gilt Folgendes:

Das neueste Image in der Image-Familie ist als verworfen markiert oder wurde aus Google Cloudgelöscht.
Die von Google bereitgestellte Software für die Gastumgebung wird für EOL-Betriebssystemversionen nicht aktualisiert und die zugehörigen Repositories werden nicht mehr aktualisiert oder gewartet.
Für vorhandene VMs, die EOL-Betriebssystemversionen verwenden, gilt Folgendes:
- Die VM kann keine Softwarepakete oder Updates vom Betriebssystemanbieter herunterladen oder installieren und es sind keine Sicherheitsupdates mehr verfügbar. Dies 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 Kompatibilität wird nicht garantiert. Möglicherweise ist kein aktiver Support vom Betriebssystemanbieter oder von Google verfügbar. Google kann Optionen für die Migration oder das Upgrade auf neuere Betriebssystemversionen anbieten.

Namenskonvention für Betriebssystem-Images, Update-Zeitplan und Richtlinie zur Einstellung

In der folgenden Tabelle sind die Namenskonvention für Betriebssystem-Images und Imagefamilien, der Aktualisierungszeitplan und die anwendbare 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 Entwicklungs-Codename 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/der Monat/der Tag, an dem das Betriebssystem-Image erstellt oder veröffentlicht wurde. Bei einigen Betriebssystemen wird dem Datum ein kleines v vorangestellt. 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 markiert, 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 markiert, 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 markiert, 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 markiert, 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 markiert, können aber weiterhin verwendet werden.
RHEL für SAP	rhel-V-sap-ha	rhel-V-sap-vYYYYMMDD	Monatlich	Betriebssystem-Images werden als verworfen markiert, 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 markiert, 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 EOS-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 ist 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 ist als verworfen markiert. Eingestellte Betriebssystem-Images werden sechs Monate nach dem Einstellungsdatum gelöscht.
SLES für 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 ist 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 markiert, 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 markiert, 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

Lebenszyklus von Betriebssystemen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.