Subskriptions-Guide zu selbst gemanagtem Red Hat OpenShift

In diesem Dokument wird das Subskriptionsmodell für selbst gemanagte Red Hat® OpenShift® Angebote erläutert. Außerdem erhalten Sie eine Schritt-für-Schritt-Anleitung, wie Sie die Anzahl der erforderlichen Berechtigungen für Ihre Red Hat OpenShift Umgebung in etwa bestimmen können. Informationen zur Bestimmung des genauen Umfangs sind auf Anfrage erhältlich.

Zunächst definieren wir einige Begriffe, die Sie unbedingt kennen sollten:

• Kernpaar: Hierbei handelt es sich um eine der Grundlagen für selbst gemanagte OpenShift-Subskriptionen. Ein Kernpaar wird als 2 physische Kerne oder als 4 vCPUs definiert. Auf einer Bare Metal-Maschine bezieht sich der Begriff immer auf den physischen Kern, unabhängig von Hyperthreading oder symmetrischer Multithreading-Technologie. Wenn Hyperthreading aktiviert ist, werden 2 physische Kerne, die als 4 vCPUs auftreten, trotzdem als ein einziges Kernpaar gezählt. Für Hyperscaler Deployments, wie etwa AWS, Azure und GCP, werden 4 vCPUs immer als ein einzelnes Kernpaar betrachtet. Kernpaar-Subskriptionen werden auf der Cluster-Ebene gezählt und können daher mehrere Cloud-Instanzen, virtuelle Maschinen (VMs) und physische Server umfassen.
• Bare Metal Socket-Paar: Hierbei handelt es sich um eine weitere Grundlage für selbst gemanagte OpenShift-Subskriptionen. Pro Server ist mindestens 1 Subskription für ein Bare Metal Socket-Paar erforderlich, die maximal 128 Kerne abdeckt. Eine einzelne Subskription für ein Bare Metal Socket-Paar kann sich nicht über mehr als 1 Server erstrecken, und auch die Kerne in einer Subskription können sich nicht über mehr als 1 Server erstrecken. Die Subskriptionen für Bare Metal Socket-Paare können gestapelt werden, um eine größere Anzahl von Kernen und Sockets abzudecken.
• AI Accelerator: Die Anzahl der erforderlichen Red Hat AI Accelerator-Subskriptionen richtet sich nach der Anzahl der physischen Hardware-Add-on-Geräte, die bestimmte Rechenfunktionen außerhalb der CPUs (Central Processing Units) beschleunigen. Dabei kann es sich unter anderem um diskrete GPUs (Graphic Processing Units), TPUs (Tensor Processing Units), DPUs (Data Processing Units), FPGAs (Field Programmable Gate Arrays), ASICs ( Application Specific Integrated Circuits) und NPUs ( Network Processing Units) handeln, die als Add-ons installiert sind. Dies gilt nicht für Accelerators, die eng mit der Haupt-CPU integriert sind (wie integrierte GPU, NPU und andere Arten von Accelerators). Diese können zwar oft virtualisiert und für mehr als 1 VM oder Instanz bereitgestellt werden und können 1 oder mehrere „Kerne“ haben, ähnlich wie bei CPU-Kernen, die Subskription basiert jedoch auf der Anzahl der physischen Geräte.
• SLA: Bei Red Hat Subskriptionen müssen Sie sich für ein Support-SLAs (Service Level Agreement) entscheiden. Dabei stehen 2 Support-SLAs zur Auswahl: Standard (werktags von 8:00 bis 17:00 Uhr) oder Premium (rund um die Uhr).
• Rechenknoten: Instanzen (VMs oder Bare Metal-Hosts) von Red Hat Enterprise Linux® oder Red Hat Enterprise Linux CoreOS, auf denen Endbenutzeranwendungs-Pods ausgeführt werden. OpenShift-Umgebungen können über zahlreiche Rechenknoten verfügen. Diese Knoten erfordern OpenShift-Subskriptionen. Für die Control Plane-Knoten und die Infrastrukturknoten, die die Rechenknoten unterstützen, sind keine Subskriptionen erforderlich. Sie können allerdings Infrastrukturkosten verursachen.
• Control Plane-Knoten: Instanzen (VMs oder Bare Metal-Hosts) von Red Hat Enterprise Linux CoreOS, die als Kubernetes-Orchestrierungs- oder -Verwaltungsschicht für Red Hat OpenShift fungieren. Berechtigungen für Control Plane-Knoten sind in selbst gemanagten OpenShift-Subskriptionen enthalten und müssen nicht gezählt werden, um die Anzahl der zu erwerbenden Subskriptionen zu bestimmen. Weitere Details finden Sie im Abschnitt über Red Hat OpenShift Control Plane- und Infrastrukturknoten.
• Infrastrukturknoten: Knoten, auf denen Pods ausgeführt werden, die eine OpenShift Cluster-Infrastruktur und keine Anwendungsinstanzen unterstützen. (Beispielsweise Knoten, auf denen der HAProxy-basierte Load Balancer für den Ingress-Datenverkehr ausgeführt wird.) Berechtigungen für Infrastrukturknoten sind in selbst gemanagten OpenShift-Subskriptionen enthalten und müssen nicht gezählt werden, um die Anzahl der zu erwerbenden Subskriptionen zu bestimmen, solange keine Benutzeranwendungsinstanzen darauf ausgeführt werden.
• Cluster: Ein OpenShift Kubernetes-Cluster, der aus einer Control Plane, optionalen Infrastrukturknoten und mindestens einem Rechenknoten besteht.

Anwendungsinstanz: Eine Anwendung kann eine einzelne Pod-Instanz sein oder in mehreren Pod-Instanzen bereitgestellt werden, die einen Anwendungsservice bilden. Ein hochverfügbarer Anwendungsservice kann beispielsweise aus 2 oder mehr Pods bestehen. Anwendungsinstanzen müssen immer auf berechtigten Rechenknoten mit Subskriptionen für Red Hat OpenShift ausgeführt werden.

Red Hat OpenShift bietet eine konsistente Plattform für Anwendungsentwicklung und -management in einer Open Hybrid Cloud-Umgebung und unterstützt Deployments auf lokaler, virtueller und physischer Infrastruktur sowie Private Cloud-, Public Cloud- und Edge-Deployments. Red Hat OpenShift kann auf 2 Arten ausgeführt und genutzt werden: als selbst gemanagtes OpenShift und als vollständig gemanagte OpenShift Cloud Services. Dieser Guide konzentriert sich auf selbst gemanagtes OpenShift.

Mit selbst gemanagtem OpenShift können Sie Red Hat OpenShift Umgebungen mit maximaler Kontrolle, Flexibilität und Anpassung installieren, ausführen und verwalten. So können Sie Ihre eigene Umgebung betreiben, angefangen bei der Infrastruktur. Selbst gemanagtes OpenShift wird On-Premise unterstützt – mit physischen Servern, Virtualisierung und in einer Private Cloud-Umgebung – sowie in unterstützten Public Cloud-Umgebungen. Sie kontrollieren die Upgrades, verwalten die untergeordnete Infrastruktur und sorgen für die Einhaltung der SLAs (Service Level Agreements).

Die gemanagten OpenShift  Cloud Services werden von Red Hat und seinen Public Cloud-Partnern in großen Public Clouds vollständig verwaltet und betrieben. Ein dediziertes SRE-Team (Site Reliability Engineering) übernimmt das Management und die Wartung der zentralen Services und Infrastruktur von Red Hat OpenShift, sodass sich Ihre DevSecOps-Teams auf die Entwicklung und das Deployment neuer und auf die Modernisierung bestehender Anwendungen konzentrieren können.

Angebote von OpenShift Cloud Services und weitere Informationen:

• Red Hat OpenShift Dedicated: Ein vollständig gemanagter Service von Red Hat OpenShift auf AWS (Amazon Web Services) und Google Cloud.
• Microsoft Azure Red Hat OpenShift: Ein vollständig gemanagter Service von Red Hat OpenShift auf Microsoft Azure, gemeinsam von Red Hat und Microsoft gemanagt.
• Red Hat OpenShift Service on AWS: Ein vollständig gemanagter Service von Red Hat OpenShift auf Amazon Web Services, gemeinsam von Red Hat und AWS gemanagt.
• Red Hat OpenShift on IBM Cloud: Ein vollständig gemanagter Service von Red Hat OpenShift auf IBM Cloud, gemeinsam von Red Hat und IBM gemanagt.

Sämtliche Editionen von Red Hat OpenShift bieten ein konsistentes Benutzererlebnis für Entwicklungs- und Operations-Teams, unabhängig von der Umgebung. So können Sie Ihre Kompetenzen und Anwendungen in die Cloud-Umgebungen übertragen, in denen Ihre Anwendungen am besten laufen.

Selbst gemanagtes OpenShift (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine und Red Hat OpenShift Virtualization Engine) kann in sämtlichen Umgebungen genutzt werden, in denen 64-Bit Red Hat Enterprise Linux zertifiziert ist und unterstützt wird. In der Dokumentation erhalten Sie weitere Informationen zu den Deployment-Methoden von OpenShift und den unterstützten Infrastrukturtypen.

Softwareeditionen für selbst gemanagtes OpenShift:

• Red Hat OpenShift Kubernetes Engine: Eine unternehmensgerechte Kubernetes Runtime Engine für Hybrid Clouds, die zentrale OpenShift-Funktionen für die Bereitstellung und Ausführung von Anwendungen bietet. Sie kann sowohl in Rechenzentren als auch in Public Cloud- oder Edge-Umgebungen installiert und gemanagt werden.
• Red Hat OpenShift Container Platform: Eine vollumfängliche unternehmensgerechte Kubernetes-Anwendungsplattform für Hybrid Clouds, mit der Sie Anwendungen entwickeln, bereitstellen und ausführen können. Sie kann sowohl in Rechenzentren als auch in Public Cloud- oder Edge-Umgebungen installiert und gemanagt werden.
• Red Hat OpenShift Platform Plus: Eine Hybrid Cloud-Plattform, mit der Unternehmen intelligente Anwendungen in großem Umfang in verschiedenen Clustern und Cloud-Umgebungen entwickeln, bereitstellen, ausführen und verwalten können. Mehrere Sicherheits-, Verwaltungs- und Automatisierungsschichten sorgen für Konsistenz in der gesamten Softwarelieferkette. Die Subskriptionen für OpenShift Platform Plus sind nur für x86-basierte Cluster verfügbar.
• Red Hat OpenShift Virtualization Engine: Ein reines Bare Metal-Virtualisierungsinfrastrukturangebot auf der Basis von Red Hat OpenShift und dem quelloffenen KVM-Hypervisor (Kernel-based Virtual Machine), das Unternehmen eine zuverlässige, unternehmensgerechte Lösung für die Bereitstellung, Verwaltung und Skalierung von VMs bietet. Diese Edition von OpenShift ist ein Subset der OpenShift-Funktionalität und richtet sich ausschließlich an VM-Workloads, wobei nur Infrastrukturservices in Containern unterstützt werden (also keine Unterstützung für Endbenutzeranwendungs-Container).

Subskriptionstypen

Es gibt 2 Subskriptionstypen (Kernpaar und Bare Metal Socket-Paar) für selbst gemanagtes OpenShift, wobei für die beiden Subskriptionstypen jeweils 2 Supportstufen verfügbar sind.

Für die Rechenknoten in Ihrer Umgebung sind Rechenknoten-Subskriptionen erforderlich. Diese können durch Kernpaare oder durch Bare Metal Socket-Paare berechtigt sein:

1. Kernpaar (2 Kerne oder 4 vCPUs)
   • Diese Subskriptionsoption ist für OpenShift Kubernetes Engine, OpenShift Container Platform und OpenShift Platform Plus verfügbar. Kernpaar-Subskriptionen sind nicht auf OpenShift Virtualization Engine anwendbar.
   • Beim Erteilen von Berechtigungen für CPU-Kerne zählen Sie die Gesamtzahl der physischen Kerne oder vCPUs auf sämtlichen OpenShift-Rechenknoten, die auf den verschiedenen OpenShift Clustern ausgeführt werden, die Sie mit Kernpaar-Subskriptionen berechtigen möchten.
   • Dabei ist ein SLA mit Standard-Support (werktags von 8:00 bis 17:00 Uhr) oder Premium-Support (rund um die Uhr) verfügbar.
2. Bare Metal Socket-Paar (1–2 Sockets mit bis zu 128 Kernen)
   • Diese Subskriptionsoption ist für sämtliche selbst gemanagten OpenShift-Editionen verfügbar und ist die einzige Option für OpenShift Virtualization Engine.
   • Diese Subskription ist nur für physische x86- und ARM Bare Metal-Knoten verfügbar, bei denen OpenShift direkt auf der Hardware installiert ist. Ein Hypervisor eines Drittanbieters ist nicht zulässig.
   • Es handelt sich ausdrücklich nicht um eine Subskription für ein „virtuelles Rechenzentrum“ (wie Red Hat Enterprise Linux for Virtual Datacenters, bei dem Sie mit einer einzigen Subskription eine unbegrenzte Anzahl von VM-Guest-Betriebssystemen auf einem beliebigen Hypervisor-Host installieren können).
   • Dabei ist ein SLA mit Standard-Support (werktags von 8:00 bis 17:00 Uhr) oder Premium-Support (rund um die Uhr) verfügbar.
   • Kann als Stack für Bare Metal-Server mit mehr als 2 Sockets oder mit mehr als 128 Kernen verwendet werden, aber eine einzelne Subskription darf nicht mehrere Bare Metal-Server umfassen.

Zusätzlich benötigen Sie Red Hat AI Accelerator-Subskriptionen für die Accelerators in Ihrer Umgebung:

1. AI Accelerator (1 Accelerator)
   • Diese Subskription ist erforderlich für Accelerator-Karten (GPU, TPU, NPU, FPGA, DPU usw.), die die Rechenleistung für KI-Workloads beschleunigen. Dabei handelt es sich um separate Add-ons, die nicht Teil des CPU-Pakets sind.
   • Dieselbe Subskription wird für die einzelnen physischen AI Accelerators verwendet, unabhängig von der Red Hat OpenShift Edition.
   • Eine einzelne AI Accelerator-Subskription ist ausreichend für Red Hat OpenShift und OpenShift AI, wenn beide auf dem Cluster installiert sind.
   • Diese Subskription ist nicht erforderlich, solange die Funktion des Accelerators nicht für die Rechenbeschleunigung verwendet wird (beispielsweise DPUs, die als SmartNICs nur für die Netzwerkbeschleunigung verwendet werden, auch wenn sie über adressierbare ARM-Kerne verfügen, die nicht verwendet werden, oder GPUs, die für das Rendern von Grafiken und nicht für die KI-Beschleunigung verwendet werden).
   • Dabei ist ein SLA mit Standard-Support (werktags von 8:00 bis 17:00 Uhr) oder Premium-Support (rund um die Uhr) verfügbar. Das SLA muss mit dem SLA der unterstützenden Subskription für das Kernpaar oder Bare Metal Socket-Paar übereinstimmen.

Wann empfiehlt sich eine Kernpaar-Subskription?

Die Wahl einer Kernpaar-Subskription erfolgt in den meisten Fällen, wenn Sie OpenShift in selbst gemanagten Public Cloud-Hyperscalern, in einer IaaS Private Cloud (Infrastructure as a Service) oder auf einem Hypervisor wie VMware vSphere, Red Hat OpenStack® Platform oder Nutanix bereitstellen möchten.

Mit Kernpaar-Subskriptionen erübrigt sich das Anhängen von Subskriptionen an physische Server. Die Pods können bei Bedarf standortunabhängig in Ihrer Hybrid Cloud bereitgestellt werden.

Sie können Kernpaar-Subskriptionen auch auf Bare Metal-Servern oder -Geräten (also ohne Hypervisor) verwenden. Beachten Sie, dass es in der Regel eine Dichte für Rechen-Pods gibt, bei der Bare Metal Socket-Paar-Subskriptionen kosteneffektiver sein können.

Wenn Sie OpenShift Virtualization Engine als dedizierte Virtualisierungsplattform verwenden, können Sie OpenShift Container auf VMs mit Kernpaar-Subskriptionen zusätzlich zu den Bare Metal Socket-Paar-Subskriptionen für den Hypervisor berechtigen. Dazu erwerben Sie separat Kernpaar-Subskriptionen für selbst gemanagtes OpenShift und weisen diese den VMs in dieser Umgebung zu, genau wie bei anderen Anwendungen, die Sie erwerben und als VM ausführen können. In diesem Fall gibt es eine Kerndichte, bei der ein Wechsel zum Bare Metal Socket-Paar-Modell für selbst gemanagtes OpenShift, mit unbegrenzten OpenShift-Containern auf dem Bare Metal-Server und Unterstützung für das Ausführen dieser Container in OpenShift-VMs, kostengünstiger sein kann.

Kernpaar-Subskriptionen können so verteilt werden, dass sie die gesamten OpenShift Rechenknoten in den OpenShift Clustern abdecken. Beispiel: 100 Kernpaar-Subskriptionen für Red Hat OpenShift Platform Plus bieten 200 Kerne (400 vCPUs), die für eine beliebige Anzahl von Rechenknoten in den ausgeführten OpenShift Clustern in ihren verschiedenen Hybrid Cloud-Umgebungen genutzt werden können.

Wann empfiehlt sich eine Bare Metal Socket-Paar-Subskription?

Bare Metal Socket-Paar-Subskriptionen sind nur eine Option für Rechenknoten von OpenShift, die auf dedizierten physischen Servern bereitgestellt werden, entweder in Ihrem Rechenzentrum, in einer gehosteten Private Cloud für ein unterstütztes Bare Metal-Angebot oder mit einem Hyperscaler für ein unterstütztes Bare Metal-Angebot. Bare Metal Socket-Paar-Subskriptionen sind die einzige Option für OpenShift Virtualization Engine und werden für die Unterstützung der OpenShift Virtualization-Funktion in den anderen selbst gemanagten OpenShift-Editionen benötigt.

Eine einzige Bare Metal Socket-Paar-Subskription berechtigt bis zu 128 physische Kerne für das Socket-Paar. Bare Metal-Subskriptionen sind stapelbar, um sowohl Socket-Paare mit insgesamt mehr als 128 Kernen als auch physische Server mit mehr als einem Socket-Paar abzudecken.

Wenn Sie einen physischen Server verwenden möchten, kombinieren Sie eine oder mehrere Subskriptionen, um entweder die Gesamtzahl der Sockets oder der physischen Kerne abzudecken (je nachdem, welche Anzahl größer ist). Als Beispiel: Ein Server verfügt über 2 Sockets mit 48 Kernen pro CPU, insgesamt also 96 Kerne. Hierfür ist 1 Subskription erforderlich, weil der Server über 1–2 Sockets und weniger als 128 Kerne verfügt. Für einen zweiten Server mit 2 Sockets und insgesamt 192 Kernen werden 2 Subskriptionen benötigt. 2 Subskriptionen sind erforderlich, um 192 Kerne abzudecken, weil eine einzige Subskription maximal 128 Kerne abdeckt. Eine einzelne Bare Metal Socket-Paar-Subskription kann nicht auf mehrere physische Hosts aufgeteilt werden (um 2 Server mit je einem Socket abzudecken oder um Kerne auf separaten Servern abzudecken).

Ein physischer Bare Metal-Server, der socketbasierte Berechtigungen verwendet, kann aufgrund der inhärenten Architektur von Kubernetes nur als ein einzelner OpenShift-Knoten genutzt werden. Da die einzelnen Knoten in Kubernetes nur zu einem einzigen Cluster gehören können, bedeutet dies, dass sich sämtliche Container auf einem Bare Metal-Server im selben Cluster befinden. Dies eignet sich für ressourcenintensive Workloads wie OpenShift Virtualization (wobei pro Workload eine vollständige VM ausgeführt wird), ist aber für andere möglicherweise nicht geeignet. Obwohl OpenShift bis zu 2500 Container auf einem einzelnen Knoten unterstützt, gibt es Situationen, in denen Sie aus Performance- oder Architekturgründen Container möglicherweise auf verschiedene Knoten oder Cluster aufteilen möchten. Dies ist ohne Virtualisierung zum Erstellen separater Rechenknoten auf dem Bare Metal-Server jedoch nicht möglich.

Ein häufiges Deployment-Modell für Container besteht in der Architektur einer großen Anzahl von Clustern mit jeweils einer kleineren Anzahl von Containern. Dieses Modell ist in Hyperscaler-Umgebungen üblich und kann im Rechenzentrum durch Verwenden eines Hypervisors zum Erstellen von VMs erreicht werden, die dann als Rechenknoten dienen, auf denen Container bereitgestellt werden. Bei Hypervisoren wie VMware vSphere, Red Hat OpenStack Platform und Nutanix müssen Sie Kernpaar-Subskriptionen für OpenShift verwenden, die in VMs bereitgestellt werden.

OpenShift Kubernetes Engine-, OpenShift Container Platform- und OpenShift Platform Plus-Cluster, die auf Bare Metal- und berechtigten Socket-Paar-Subskriptionen bereitgestellt werden, umfassen OpenShift Virtualization und Subskriptionen für sämtliche virtuellen OpenShift Cluster desselben Produkttyps, die auf ihnen bereitgestellt werden. Das bedeutet, dass virtuelle OpenShift Cluster, die beispielsweise auf einem Bare Metal OpenShift Container Platform-Cluster bereitgestellt werden, die Subskriptionen für OpenShift Container Platform vom Bare Metal-Hosting-Cluster übernehmen.

Ein wichtiger Hinweis ist, dass die Subskription für OpenShift Virtualization Engine keine Unterstützung für containerisierte Anwendungsinstanzen beinhaltet, mit Ausnahme von Infrastruktur-Workloads, wie im Abschnitt über die OpenShift Virtualization Engine weiter unten definiert. Wenn Sie Ihre eigenen containerisierten Anwendungs-Workloads mit OpenShift Virtualization Engine ausführen möchten, müssen Sie die VMs mit Kernpaar-Subskriptionen für selbst gemanagtes OpenShift berechtigen. Bei höheren Dichten können Sie stattdessen auch eine Bare Metal Socket-Paar-Subskription für selbst gemanagte OpenShift Kubernetes Engine, OpenShift Container Platform oder OpenShift Platform Plus erwerben. Dann können Sie containerbasierte Anwendungen nativ auf dem Bare Metal-Cluster ausführen, oder virtuelle Cluster übernehmen Subskriptionen wie im vorherigen Absatz beschrieben.

Sie können die OpenShift-Produkttypen innerhalb desselben Clusters nicht mischen. Sämtliche Knoten müssen eine Subskription desselben OpenShift Virtualization Engine-, OpenShift Kubernetes Engine-, OpenShift Container Platform- oder OpenShift Platform Plus-Produkttyps haben, jedoch können Kernpaar- und Socket-Paar-Subskriptionen innerhalb eines Clusters verwendet werden. Sie können beispielsweise keinen einzelnen Bare Metal-Cluster mit einer bestimmten Anzahl von OpenShift Virtualization Engine-Knoten zum Hosten von VMs und anderen Knoten haben, die über eine Subskription für OpenShift Platform Plus zum Hosten containerisierter Anwendungen und virtueller OpenShift-Instanzen verfügen.

Wie Sie AI Accelerator-Subskriptionen zählen

In den letzten Jahren sind neue Hardware-Technologien auf den Markt gekommen, mit denen bestimmte Workloads schneller ausgeführt werden können. Diese Hardware-Geräte werden in einigen Materialien von Red Hat als Accelerators oder AI Accelerators bezeichnet. Für moderne Server stehen verschiedene Arten von Hardware-Geräten zur Verfügung, die als „Accelerators“ (Beschleuniger) bezeichnet werden können, wie beispielsweise GPUs, TPUs, ASICs, NPUs und FPGAs.

Bei diesen Accelerators handelt es sich in der Regel um eine Karte, ein Board oder ein anderes physisches Gerät, das einen PCI-Steckplatz (Peripheral Component Interconnect) in einem Server belegt. Dabei handelt es sich fast immer um die Stückzahl, die Sie beim Anbieter des Accelerators gekauft haben. Bei einem Server, der laut Anbieter über 8 GPUs verfügt, sind damit fast immer 8 physische Accelerator-Einheiten gemeint.

Eine einzelne AI Accelerator-Subskription deckt 1 physisches Accelerator-Gerät ab. Beispiel: Der Fokus liegt nur auf den AI Accelerator-Subskriptionen:

• Ein physischer Rechenknoten mit 4 physischen GPU-Geräten erfordert 4 AI Accelerator-Subskriptionen zusätzlich zu den CPU-Kernpaar- oder -Socket-Paar-Subskriptionen, die den Rechenknoten abdecken.
• Ein einzelner virtueller Rechenknoten mit 1 physischen GPU-Gerät, das den VMs als mehrere vGPUs präsentiert wird, erfordert 1 AI Accelerator-Subskription, da die Zählung auf physischen Accelerators und nicht auf virtuellen beruht.

Accelerators werden nur gezählt, wenn sie zur Ausführung einer Computing Workload verwendet werden. Eine Workload gilt als Computing Workload, wenn der Hauptzweck der Workload nicht darin besteht, aktiv und nahezu in Echtzeit Pixel auf den Bildschirm der einzelnen Nutzenden zu übertragen oder Daten innerhalb eines Netzwerks zu verschieben.

Diese Unterscheidung ist wichtig, weil VFX- und Streaming-Anwendungen zwar GPUs und andere Beschleunigungshardware verwenden können, der Hauptzweck in diesen Fällen aber das Zeichnen von Pixeln auf einem Bildschirm ist. In einigen Fällen besteht die Hauptfunktion im Verschieben von Daten innerhalb eines Netzwerks (beispielsweise bei Datenverarbeitungseinheiten für Netzfunktionen), was ebenfalls nicht als Rechenleistung gilt.

Beispiele für Computing Workloads sind unter anderem:

• Traditionelle Softwareanwendungen wie Java, Python und Perl
• LLMs oder andere rechenintensive Software
• Data Science-Modelltraining und -abstimmung
• Wissenschaftliches Modellieren und physikalische Simulationen wie Proteinfaltung und Fluiddynamik

Red Hat OpenShift Control Plane- und Infrastrukturknoten

Eine selbst gemanagte OpenShift Subskription beinhaltet Berechtigungen für Red Hat OpenShift und andere für OpenShift relevante Komponenten. OpenShift Kubernetes Engine, OpenShift Container Platform und OpenShift Platform Plus enthalten Berechtigungen für Red Hat Enterprise Linux für Rechen- und Infrastrukturknoten. Red Hat OpenShift Virtualization Engine unterstützt keine standardmäßigen Red Hat Enterprise Linux Worker- oder Infrastrukturknoten, sondern nur das Red Hat Enterprise Linux CoreOS Betriebssystem, das Teil der OpenShift-Berechtigung ist.

Diese Berechtigungen sind enthalten, damit die erforderliche OpenShift Control Plane und Infrastruktur ausgeführt werden kann. Sie müssen jedoch bei der Bestimmung der Anzahl der benötigten Red Hat Subskriptionen nicht berücksichtigt werden.

Die Subskriptionen für Red Hat OpenShift Platform Plus beinhalten auch die Verwaltung sämtlicher Knoten durch Red Hat Advanced Cluster Security for Kubernetes und Red Hat Advanced Cluster Management for Kubernetes.

Bei einer Standardinstallation wird eine hochverfügbare OpenShift Control Plane bereitgestellt, die aus 3 Control Plane-Knoten und mindestens 2 OpenShift Rechenknoten besteht, auf denen Endbenutzeranwendungen ausgeführt werden. Standardmäßig werden die Komponenten der Kubernetes-Control Plane (wie etwa API-Server, etcd, Scheduler) und unterstützende Cluster-Services (wie etwa Monitoring, Registry) auf den OpenShift Control Plane-Knoten bereitgestellt. Sie können jedoch entscheiden, einige dieser unterstützenden Cluster-Services auf dedizierte Infrastrukturknoten zu verlagern.

Voraussetzung für die Einstufung als Infrastrukturknoten und die Nutzung der enthaltenen Berechtigung ist, dass auf diesen Instanzen nur Komponenten ausgeführt werden, die den Cluster unterstützen und nicht Teil einer Endbenutzeranwendung sind. Beispiele:

• OpenShift-Registry
• OpenShift Ingress Router (lokaler und globaler und Multi-Cluster-Ingress)
• OpenShift Observability
• HAProxy-basierte Instanzen für den Cluster-Ingress
• Red Hat Quay
• Red Hat OpenShift Data Foundation
• Red Hat Advanced Cluster Management for Kubernetes
• Red Hat Advanced Cluster Security for Kubernetes
• Red Hat OpenShift GitOps
• Red Hat OpenShift Pipelines
• Gehostete Control Planes für Red Hat OpenShift

Sie können benutzerdefinierte und externe Agenten und Tools für die Überwachung, Protokolldatenerfassung und -weiterleitung, Hardwaretreiber, Infrastrukturintegration wie Virtualisierungsagenten usw. auf Infrastrukturknoten bereitstellen und ausführen, ohne dass der Knoten von der Infrastrukturlizenzierung ausgeschlossen wird. Dies gilt jedoch nur für Agenten und zugehörige Komponenten, darunter Controller-Pods für Operatoren, nicht für die benutzerdefinierte oder die Drittanbieter-Software. Beispiele für nicht von Red Hat stammende Software, die als berechtigte Infrastruktur-Workload gilt:

• Benutzerdefinierte und externe Monitoring-Agenten
• CNI-(Container Network Interface-) und CSI-(Container Storage Interface-)Treiber und -Controller (Plugins)
• Hardware- oder Virtualisierungsbeschleuniger
• Controller-Pods für Kubernetes-CRD oder -Operatoren (benutzerdefinierte oder Drittanbieter-Software)

Auf einem Infrastrukturknoten dürfen keine anderen Anwendungsinstanzen oder -typen von Endbenutzenden unter Verwendung der enthaltenen Berechtigung ausgeführt werden. Wenn Sie andere Infrastruktur-Workloads als Anwendungsinstanzen auf Red Hat OpenShift ausführen möchten, müssen Sie diese Instanzen auf regulären Anwendungsknoten mit gültigen Red Hat OpenShift Subskriptionen ausführen. Wenden Sie sich an Red Hat, um zu erfahren, ob eine App oder ein Service als Infrastruktur-Workload berechtigt ist. 

Red Hat Enterprise Linux Berechtigungen

Red Hat Enterprise Linux Berechtigungen für OpenShift-Rechen- und Infrastrukturknoten sind in OpenShift Kubernetes Engine, OpenShift Container Platform und OpenShift Platform Plus enthalten. Dazu gehören auch berechtigte Pods für Anwendungen und Berechtigungen für Guest-Betriebssysteme für VMs. Red Hat OpenShift Subskriptionen umfassen jedoch keine anderen Berechtigungen für Red Hat Enterprise Linux Knoten, mit der folgenden Ausnahme:

• Red Hat Enterprise Linux Knoten, die speziell für die Provisionierung einer Bare Metal-Installationsinfrastruktur (IPI) verwendet werden

In OpenShift Virtualization Engine ist Red Hat Enterprise Linux nicht enthalten, weder für Rechen- und Infrastrukturknoten noch für Guest-Betriebssystemberechtigungen von VMs. Für Red Hat Enterprise Linux Guests auf OpenShift Virtualization Engine ist eine Subskription für Red Hat Enterprise Linux for Virtual Datacenters oder eine Subskription pro VM erforderlich.

Für externe Knoten, die Services wie Internet Proxies, Load Balancer oder die Mirror Registry hosten, von denen OpenShift abhängt, sind Red Hat Enterprise Linux Berechtigungen nicht enthalten. Red Hat Satellite ist nicht Bestandteil der Berechtigung.

Bootstrapping der Container Registry für das Mirroring von OpenShift Container Images

Die Mirror Registry für OpenShift ist eine Quay-Berechtigung mit der alleinigen Aufgabe, das Mirroring von Inhalten für das Bootstrapping unverbundener OpenShift Cluster zu vereinfachen. Die Registry ist als Teil der Red Hat OpenShift Subskription enthalten. Es handelt sich um eine begrenzte Support-Berechtigung für ein minimales Quay-Deployment, das von einem speziellen Installer erstellt wird. Damit können Sie eine Quay Registry auf einem vorab provisionierten, vom Kunden gemanagten Red Hat Enterprise Linux Host ausführen.

Hinweis: Sie sind berechtigt, Quay als Registry Mirror zu verwenden, der ausschließlich zum Mirroring von OpenShift Release Payload, OperatorHub-Inhalten, Beispiel-Operator-Images, Cincinnati-Graph-Images und Images im Zusammenhang mit den Angeboten von Red Hat OpenStack Platform einschließlich Red Hat OpenStack Services on OpenShift und Red Hat OpenShift Data Foundation dient.

Die Mirror Registry für OpenShift ist nicht als Universal-Registry gedacht, die in beliebigem Umfang arbeitet. Eine begrenzte Anzahl von benutzerdefinierten Images darf jedoch dort gespeichert werden, die benötigte Zusatzsoftware enthalten, zum Beispiel Agenten und Container Images für bestimmte Infrastruktur-Workloads. Einige Beispiele dafür sind:

• Monitoring-Agenten
• CNI- und CSI-Anbieter
• Hardware- oder Virtualisierungsagenten
• Operatoren, die Services unabhängiger Softwareanbieter (ISV) unterstützen
• Benutzerdefinierte Operatoren zur Prüfung von Deployments

Gehostete Control Planes

Die klassische OpenShift-Infrastruktur erfordert mindestens 3 Control Plane-Knoten pro OpenShift Cluster. Eine Alternative ist die Verwendung gehosteter Control Planes, bei denen die Control Planes auf einem zentralen Control Plane-Cluster ausgeführt werden und die logische Control Plane für OpenShift Cluster bereitstellen. Wie immer zählen die Control Plane-Knoten und die Infrastrukturknoten nicht für die Subskriptionen, müssen aber in der Architektur berücksichtigt werden.

Gehostete Control Planes können auf beliebigen Bare Metal OpenShift Clustern ausgeführt werden. Die Rechenknoten für diese Cluster benötigen jedoch Berechtigungen, die der Infrastruktur entsprechen, auf der sie ausgeführt werden. Beispielsweise benötigen virtuelle Cluster, die auf OpenShift Virtualization Engine gehostet werden, Kernpaar-Subskriptionen für die Rechenknoten. Ein Cluster, dessen Control Plane von einem OpenShift Virtualization Engine-Cluster gehostet wird und Bare Metal-Rechenknoten verwendet, benötigt dagegen Bare Metal Socket-Paar-Subskriptionen.

Ausnahme 1: Wenn Sie sich für das Ausführen von Anwendungsinstanzen auf Control Plane- oder Infrastrukturknoten entscheiden

OpenShift Control Plane-Knoten werden standardmäßig nicht als Rechenknoten verwendet und führen daher keine Anwendungsinstanzen aus. Ob ein Control Plane-Knoten eine vollständige Red Hat OpenShift Subskription benötigt, hängt davon ab, ob er nur unterstützende OpenShift Cluster-Komponenten oder Endbenutzeranwendungen ausführt. Wenn Sie einen Control Plane-Knoten als Knoten für das Hosting von Endbenutzeranwendungen verwenden möchten, sind für sämtliche Kerne Subskriptionen erforderlich. Im Abschnitt über Infrastrukturknoten finden Sie Informationen zu berechtigten Workloads, für die keine Subskription erforderlich ist.

Ausnahme 2: Kompakte Cluster Deployments

In einem kompakten Cluster Deployment wie OpenShift mit 3 Knoten werden die Workloads der Endbenutzeranwendungen auf den Control Plane-Knoten ausgeführt. Hierfür müssen Sie die Kerne auf den 3 Knoten für Red Hat OpenShift Subskriptionen zählen, unabhängig von ihrer Funktion.

Eine OpenShift-Instanz aus einem einzelnen Knoten stellt sämtliche OpenShift-Services und Endbenutzeranwendungen auf einem einzigen physischen oder virtuellen Knoten bereit – einschließlich Optimierungen, um den Arbeitsspeicherbedarf zu reduzieren und die für die Anwendungen verfügbaren Ressourcen zu maximieren. Wie bei den oben beschriebenen Clustern mit 3 Knoten gibt es auch für dieses Deployment-Modell keine besonderen Anpassungen – sämtliche Kerne auf dem Knoten müssen berechtigt werden.

Disaster Recovery

Red Hat definiert 3 Arten von Disaster Recovery-Umgebungen: Hot, Warm und Cold. Kostenpflichtige Red Hat OpenShift Subskriptionen werden nur für Hot Disaster Recovery benötigt.

• Hot Disaster Recovery-Systeme gelten definitionsgemäß als voll funktionsfähig und werden parallel zu den Produktionssystemen ausgeführt. Sie sind bereit, sofort Datenverkehr zu empfangen und bei einem Notfall den Betrieb innerhalb der primären Umgebung zu übernehmen. Wenn Datenvolumen aktiv entweder synchron oder asynchron zwischen Clustern repliziert werden, werden diese DR-Systeme als „hot“ bezeichnet.
• Warm Disaster Recovery-Systeme sind per Definition bereits darauf ausgelegt, containerisierte Workloads bereitzustellen und zu hosten, die ein angemessenes Duplikat der Workload des primären Standorts darstellt, aber keine Kunden-Workloads aus dem Quell-Cluster enthält. Warm Disaster Recovery-Systeme sollten nicht an der aktiven Replikation von Datenträgern zwischen Clustern teilnehmen, weder synchron noch asynchron. Bei der Warm-DR müssen die Daten des Kunden auf der vorhandenen Cluster-Hardware von außerhalb des Clusters wiederhergestellt werden.
• Bei Cold Disaster Recovery-Systemen ist per Definition zwar die Infrastruktur vorhanden, aber nicht die gesamte Technologie (Hardware, Software, Daten), die zur Wiederherstellung des Service benötigt wird.

Cluster im Ruhezustand, die nicht speziell für Warm Disaster Recoveries oder Cold Disaster Recoveries konfiguriert und konzipiert sind, erfordern Subskriptionen. Dazu zählen etwa über Cloud Services ausgeführte Cluster, die sich aufgrund einer geringeren Nachfrage vorübergehend im Ruhezustand befinden. Wenn Warm- oder Cold-DR-Cluster zur Ausführung von Workloads wieder aktiviert werden, sind dafür Subskriptionen erforderlich. Die vorübergehende Aktivierung von Clustern im Ruhezustand für routinemäßige Wartungen oder Tests erfordert keine zusätzlichen Subskriptionen für die Komponenten in OpenShift-Software-Angeboten.

Sowohl bei der Warm-DR als auch bei der Cold-DR können die Red Hat OpenShift Subskriptionen von der primären Umgebung in die DR-Umgebung übertragen werden, wenn der Ernstfall eintritt, um den Service wiederherzustellen und die Einhaltung der Subskriptionsbedingungen von Red Hat zu gewährleisten.

Migration und Swing Upgrades

Red Hat OpenShift 4 bietet In-Place-Upgrades zwischen Nebenversionen. Wenn Sie jedoch ein Upgrade von Red Hat OpenShift 3 durchführen oder aufgrund von Wartungsfenstern oder anderen Überlegungen ein Swing Upgrade in Nebenversionen von Red Hat OpenShift 4 durchführen müssen, deckt Ihre Red Hat OpenShift Subskription jedoch sowohl die ursprüngliche als auch die Zielinfrastruktur einer einseitigen Migration ab, bis diese Migration abgeschlossen ist. Während der Migration zeigen die Managementtools der Red Hat Subskription Ihre Umgebung je nach Anzahl der von Ihnen erworbenen Red Hat OpenShift Subskriptionen als nicht konform an. Für Hauptversions-Upgrades lässt Red Hat das zu, und Sie müssen keine zusätzlichen Subskriptionen kaufen, um die Compliance während der Migration aufrechtzuerhalten. Red Hat OpenShift bietet außerdem Tools, die bei diesen Migrationen helfen, und auf Wunsch auch Red Hat Consulting Services. Weitere Informationen finden Sie in der Dokumentation zum Migrations-Toolkit für Container.

Berechtigungen für Kerne mit Hyperthreading

Die Entscheidung, ob ein bestimmter OpenShift-Knoten 1 oder mehrere physische Kerne verwendet (oder nicht), hängt davon ab, ob für das System mehrere Threads pro Kern aktiviert sind. Erfahren Sie, wie Sie feststellen können, ob ein bestimmtes System Hyperthreading unterstützt.

Virtualisierte OpenShift-Knoten, die logische CPU-Threads verwenden, auch bekannt als simultanes Multithreading (SMT) für AMD EPYC-CPUs oder Hyperthreading bei Intel-CPUs, berechnen ihre Kernauslastung für Red Hat OpenShift Subskriptionen auf Basis der Anzahl der Kerne/CPUs, die dem Knoten zugewiesen sind, wobei eine einzelne Subskription 4 vCPUs/Kerne abdeckt, wenn logische CPU-Threads verwendet werden. Die Managementtools für Red Hat Subskriptionen gehen davon aus, dass logische CPU-Threads auf sämtlichen Systemen standardmäßig aktiviert sind.

Bare Metal-Subskriptionen zählen nur physische Kerne. Logische CPU-Threads werden beim Berechnen der Anzahl der für Bare Metal benötigten Subskriptionen nicht berücksichtigt.

Alternative Architekturen (ARM, IBM Z, IBM LinuxONE, IBM Power)

Hinweis: Obwohl sich dieses Dokument ab hier nur auf IBM Z bezieht, gelten die Informationen, die sich auf IBM Z beziehen, auch für IBM LinuxONE.

Red Hat OpenShift Container Platform kann auch auf ARM-, IBM Z- und IBM Power-Systemen ausgeführt werden, wenn Kunden diese Plattformen als Standard für die Entwicklung und Bereitstellung von cloudnativen Anwendungen und Microservices nutzen. Nur das kernbasierte Subskriptionsmodell wird für IBM Z- und IBM Power-Plattformen unterstützt.

Für die Berechtigung von ARM-Clustern gelten dieselben Regeln wie für x86.

Für Kunden von IBM Z muss in Red Hat OpenShift nicht der gesamte physische Knoten bereitgestellt werden, sondern nur die von OpenShift verwendeten Kerne. IBM Z-Kunden kennen dies als „Sub-Capacity“-Nutzung. Kunden, die nur eine Teilmenge der verfügbaren Kerne (Rechenkapazität) in ihrer IBM Z-Umgebung für OpenShift Container Platform nutzen, benötigen nur Subskriptionen für die Teilmenge, die für die Rechenknoten verwendet wird. Dies gilt unabhängig davon, wie die CPU-Partitionierung erreicht wird, ob durch CPU-Pooling, Capping, separate logische Partitionen (LPARs) oder andere Mittel.

Bei IBM Z ist für 1 IFL (Integrated Facility for Linux) 1 OpenShift Kernpaar-Subskription erforderlich. Ohne Partitionierung können bis zu 3 IFLs pro Cluster pro OpenShift Cluster für auf dem Host ausgeführte Control Plane- oder Infrastrukturservices bestimmt werden. Diese müssen für Control Plane- und/oder Infrastrukturservices aktiv genutzt werden, damit sie berechtigt sind, und erfordern keine OpenShift-Berechtigungen. Bei kompakten Cluster Deployments mit 3 Knoten müssen alle IFLs berechtigt sein.

Red Hat OpenShift Platform Plus Komponenten, die über OpenShift Container Platform hinausgehen, werden derzeit nicht auf IBM Z und IBM Power unterstützt, mit den folgenden Ausnahmen:

• Eine Standalone-Subskription von Red Hat Quay, die auf x86-Architekturen ausgeführt wird, bietet eine globale Registry für mehrere Architekturen, einschließlich IBM Z- und IBM Power-Clustern. Red Hat Quay selbst kann auf IBM Z oder IBM Power nicht ausgeführt werden.
• Red Hat Advanced Cluster Management for Kubernetes kann in IBM Z- oder IBM Power-Umgebungen installiert werden und Red Hat OpenShift Knoten verwalten, die in IBM Z- oder IBM Power-Umgebungen ausgeführt werden.
• Mit Red Hat Advanced Cluster Security für Kubernetes können Sie Cluster schützen, die auf Red Hat OpenShift auf IBM Z oder IBM Power ausgeführt werden, indem Sie den Red Hat Advanced Cluster Security Operator verwenden.
• Red Hat OpenShift Data Foundation unterstützt die Installation auf IBM Z oder IBM Power.

Die Komponenten der Red Hat OpenShift Platform Plus Subskription haben unterschiedliche Supportstufen für alternative (Nicht-x86-)Architekturen. Mehr Informationen hierzu finden Sie im Artikel Red Hat OpenShift Container Platform 4.16 Multi Architecture Component Availability Matrix. Details zur Interoperabilität zwischen den OpenShift Platform Plus Komponenten und Nicht-x86-Architekturen finden Sie in den Kompatibilitätsmatrizen für Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay und Red Hat OpenShift Data Foundation.

Red Hat OpenShift Kubernetes Engine und Red Hat OpenShift Virtualization Engine werden auf IBM Z und IBM Power nicht unterstützt.

Unterstützung für Microsoft Windows Server-Container

Selbst gemanagtes OpenShift unterstützt einen Teil der Installationsinfrastrukturen und OpenShift-Funktionen mit Microsoft Windows Server-Containern. Windows Server-Container werden nur auf Microsoft Windows Server-basierten Rechenknoten unterstützt. Die Control Plane und die Infrastrukturebene der OpenShift-Umgebung müssen mit Red Hat Enterprise Linux oder Red Hat Enterprise Linux CoreOS auf einer x86-Infrastruktur ausgeführt werden. Aus diesem Grund wird die Unterstützung von Windows Server-Containern als Standalone-Subskription verkauft, deren Preis sich nach der Kernanzahl richtet.

Die Infrastruktur von Red Hat OpenShift Platform Plus und Red Hat OpenShift Container Platform kann für das Deployment und Management von Windows Server-Rechenknoten verwendet werden. Die Unterstützung von Microsoft Windows Server-Containern für Red Hat OpenShift Subskriptionen muss als separates Add-on erworben werden.

Red Hat Advanced Cluster Management und Red Hat Advanced Cluster Security werden nicht für die Verwaltung von Microsoft Windows-Knoten unterstützt, aber Red Hat Quay auf x86-Architekturen kann Container Images für Microsoft Windows Server-basierte Workloads verwalten.

Keine Situation ist wie die andere, daher stellen diese Angaben nur Richtlinien und keine Garantien dar

Red Hat OpenShift unterstützt viele Funktionen für Skalierbarkeit, Pod-Planung, ungenutzte Kapazitäten und Ressourcen-Quotas/-begrenzungen. Bei den obigen Berechnungen handelt es sich um Richtlinien. Sie können Ihre tatsächliche Umgebung möglicherweise so anpassen, dass die Ressourcen besser genutzt werden oder die gesamte Umgebung kleiner ist. OpenShift Platform Plus Kunden sollten die Anforderungen der zusätzlichen Softwareanwendungen (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security und Quay) einschließlich Storage- und Rechenressourcen berücksichtigen, auch wenn diese keine zusätzlichen Computing-Subskriptionen erfordern.

Wenn Sie mit einem Drittanbieter zusammenarbeiten, beachten Sie dessen spezifische Bedingungen und Vereinbarungen für Red Hat Produkte und Services. 

Red Hat OpenShift Platform Plus umfasst neben OpenShift Container Platform zusätzliche Software, mit der Sie Ihre OpenShift-Umgebung in großem Umfang über mehrere Cluster und Clouds hinweg verwalten und sichern können. Red Hat OpenShift Platform Plus ist sowohl im Kernpaar- als auch im Bare Metal Socket-Paar-Subskriptionsmodell mit den zuvor genannten Einschränkungen erhältlich.

Die zusätzliche Software, die in Red Hat OpenShift Platform Plus enthalten ist, beschränkt sich im Allgemeinen auf die Verwaltung der Knoten, die im Rahmen von OpenShift Platform Plus Subskriptionen genutzt werden. So kann beispielsweise die in OpenShift Platform Plus enthaltene Subskription für Red Hat Advanced Cluster Management nur zur Verwaltung von für OpenShift Platform Plus berechtigte Knoten und Cluster verwendet werden. Kunden, die auch Knoten und Cluster verwalten möchten, die nicht für OpenShift Platform Plus berechtigt sind, etwa Red Hat OpenShift Services on AWS Cluster, müssen zusätzliche Add-on-Subskriptionen für Red Hat Advanced Cluster Management erwerben, um diese abzudecken.

Die zusätzlichen Software-Subskriptionen sind ebenfalls untrennbar mit der OpenShift Platform Plus Subskription verbunden. So können Sie beispielsweise nicht 100 OpenShift Platform Plus Subskriptionen erwerben, 200 Kerne von Red Hat OpenShift Container Platform Subskriptionen installieren und separat Red Hat Advanced Cluster Management verwenden, um 200 Kerne von Azure Red Hat OpenShift mit derselben Subskription zu verwalten. Die zusätzliche Software kann nur verwendet werden, um dieselben 200 Kerne zu verwalten, auf denen auch die zentrale Software OpenShift Platform Plus installiert ist.

Spezifische Regeln für die mehrschichtigen Produkte:

• Red Hat Advanced Cluster Security for Kubernetes: Die OpenShift Platform Plus Subskription, mit der Sie so viele zentrale Instanzen von Red Hat Advanced Cluster Management installieren können, wie Sie für die Verwaltung Ihrer Umgebung benötigen. Außerdem wird das Management der mit OpenShift Platform Plus berechtigten Knoten und Cluster abgedeckt, einschließlich Control Plane- und Infrastrukturknoten. Wenn Sie Knoten und Cluster ohne OpenShift Platform Plus Berechtigungen verwalten möchten (beispielsweise wenn Sie auch selbst gemanagte für OpenShift Container Platform oder Red Hat OpenShift Kubernetes Engine berechtigte Cluster, in einer vollständig gemanagten OpenShift Cloud ausgeführte Cluster oder Kubernetes-Umgebungen von Drittanbietern haben, die von Red Hat Advanced Cluster Management unterstützt werden), müssen Sie Red Hat Advanced Cluster Management Add-on-Subskriptionen erwerben, um diese Umgebungen abzudecken. Sie können wählen, ob Sie diese zentral von der Red Hat Advanced Cluster Management Konsole, die auf OpenShift Platform Plus installiert ist, oder von einer separaten zentralen Anwendung aus verwalten möchten, wenn dies Ihren Anforderungen entspricht. Erfahren Sie mehr über Red Hat Advanced Cluster Management Subskriptionen, unterstützte Umgebungen und Best Practices.
• Red Hat Advanced Cluster Security for Kubernetes: Die OpenShift Platform Plus Subskription, mit der Sie so viele zentrale Anwendungen von Red Hat Advanced Cluster Security installieren können, wie Sie für die Verwaltung Ihrer Umgebung benötigen. Außerdem wird das Management der mit OpenShift Platform Plus berechtigten Knoten und Cluster abgedeckt, einschließlich Control Plane- und Infrastrukturknoten. Wenn Sie Knoten und Cluster ohne OpenShift Platform Plus Berechtigungen verwalten möchten (beispielsweise wenn Sie auch selbst gemanagte für OpenShift Container Platform oder OpenShift Kubernetes Engine berechtigte Cluster, in einer vollständig gemanagten Red Hat OpenShift Cloud ausgeführte Cluster oder Kubernetes-Umgebungen von Drittanbietern haben, die von Red Hat Advanced Cluster Security unterstützt werden), müssen Sie Red Hat Advanced Cluster Security Add-on-Subskriptionen erwerben, um diese Umgebungen abzudecken. Red Hat empfiehlt, die einzelnen Umgebungen jeweils mit einer separaten zentralen Red Hat Advanced Cluster Security Anwendung zu verwalten. Erfahren Sie mehr über Red Hat Advanced Cluster Security und die davon unterstützten Umgebungen.
• Red Hat Quay: Mit den OpenShift Platform Plus Subskription können Sie Red Hat Quay auf einem beliebigen Cluster installieren, der für OpenShift Platform Plus berechtigt ist. Sie können beliebig viele Quay-Deployments auf Ihren OpenShift Platform Plus Clustern installieren. Quay kann dann auf Ihren Wunsch beliebige unterstützte Kubernetes-Umgebungen bedienen, einschließlich der OpenShift Platform Plus Umgebung, anderer selbst gemanagter OpenShift Cluster, gemanagter OpenShift-Services und unterstützter Kubernetes-Cluster von Drittanbietern. Wenn Sie Quay in einer Umgebung ohne OpenShift Platform Plus installieren möchten, müssen Sie eine separate Red Hat Quay Subskription erwerben. Quay ist auch als vollständig gemanagtes SaaS-Angebot verfügbar.
• Red Hat OpenShift Data Foundation: Mit der OpenShift Platform Plus Subskription können Sie Red Hat OpenShift Data Foundation Essentials auf einem beliebigen Cluster installieren, der für OpenShift Platform Plus berechtigt ist. Die Red Hat Data Foundation Berechtigung gilt nur für die in Essentials verfügbaren Funktionen und ist auf 256 TB Data Storage pro OpenShift Cluster begrenzt. Sie haben die Möglichkeit, den Funktionsumfang und die Kapazität über zusätzliche Subskriptionen zu erweitern. Lesen Sie den Subskriptions-Guide zu OpenShift Data Foundation (Anmeldung im Customer Portal erforderlich), oder kontaktieren Sie den Red Hat Vertrieb, um weitere Hinweise oder zusätzliche Beratung zu erhalten.

OpenShift Virtualization ist seit langem in sämtlichen selbst gemanagten OpenShift-Editionen enthalten, damit Kunden VM-Workloads in cloudnative Anwendungen integrieren und VMs in Microservices und Container modernisieren können.

Die aktuellen Veränderungen auf dem Virtualisierungsmarkt haben die Nachfrage nach alternativen Virtualisierungsplattformen erhöht, insbesondere nach Lösungen, die zur Modernisierung geeignet sind. Viele dieser Kunden benötigen nicht sämtliche Funktionen von OpenShift für die anfängliche Migration von VMs und hätten für diese Use Cases lieber eine vereinfachte und kostengünstigere alternative Edition von selbst gemanagtem OpenShift.

Red Hat OpenShift Virtualization Engine ist eine selbst gemanagte OpenShift-Edition, die sich speziell an Kunden richtet, die eine alternative Virtualisierungsplattform für die VM-Ausführung bevorzugen. OpenShift Virtualization Engine wird durch Bare Metal Socket-Paar-Subskriptionen auf unterstützten physischen Servern und auf unterstützten Hyperscaler Bare Metal-Instanzen berechtigt.

OpenShift Virtualization Engine enthält nur die Funktionen, die für das Bereitstellen, Verwalten und Ausführen von VMs erforderlich sind, wie etwa:

• Unbegrenzte Anzahl von VMs auf Hosts mit Subskriptionen
• Kann nicht verwendet werden, um Anwendungsinstanzen (wie kommerzielle Software oder Kundenanwendungen) in Containern auszuführen, sondern nur VMs
• Enthält keine Subskriptionen für das Ausführen von Red Hat OpenShift Editionen in VMs (separater Kauf von Kernpaar-Subskriptionen erforderlich)
• Guest-Berechtigungen für Red Hat Enterprise Linux für VMs sind nicht enthalten (separater Kauf von Red Hat Enterprise Linux für Virtual Datecenter oder Subskriptionen pro VM erforderlich)

Red Hat bietet jetzt 2 Add-on-Produkte für OpenShift Virtualization Engine an.

• Red Hat Advanced Cluster Management for Virtualization unterstützt Virtualisierungs- und Hypervisor Lifecycle Management und -Operationen zu einem reduzierten Preis im Vergleich zur Vollversion von Advanced Cluster Management (1 Subskription pro OpenShift Virtualization Engine Subskription).
• Red Hat Ansible® Application Platform for Virtualization bietet Unterstützung für den Hypervisor-Knoten, auf dem OpenShift Virtualization Engine für die Migration und Day-1-Operationen ausgeführt wird (1 Subskription pro OpenShift Virtualization Engine Subskription).

Bestehende Kunden von Advanced Cluster Management und Ansible Application Platform können ihre bestehenden Installationen dieser zentralen Anwendungen nutzen, um den Rest ihrer Umgebung zu unterstützen und die OpenShift Virtualization Engine-Hosts mit dem Kauf der erwähnten Add-on-Subskriptionen zu verwalten.

Bei Kunden, die die zentralen Anwendungen Advanced Cluster Management oder Ansible Application Platform noch nicht installiert haben, umfasst Ihre Subskription für die genannten Add-ons auch Unterstützung für die Installation der zentralen Anwendungen als Infrastruktur-Container auf Ihren OpenShift Virtualization Engine-Hosts. In der Dokumentation für Advanced Cluster Management oder Ansible Application Platform finden Sie Informationen zur Installation dieser zentralen Anwendungen und Best Practices für die Architektur.

Für Kunden, die eine Day-2-Automatisierung für ihre VMs benötigen, empfiehlt sich Ansible Automation Platform. Zusätzlich zu den oben aufgeführten Subskriptionen für Hypervisor-Knoten benötigen Kunden eine Subskription für die einzelnen VM-Instanzen. In der Dokumentation zu Ansible Automation Platform finden Sie weitere Informationen.

Während die Berechtigung für OpenShift Virtualization Engine die Anwendungsinstanzen der Kunden auf VMs beschränkt, werden viele der Infrastrukturanforderungen, wie beispielsweise Storage-Treiber, Backup-Anwendungen, Weiterleitungsagenten, Advanced Cluster Management und Ansible Automation Platform, als Infrastruktur-Container in Red Hat OpenShift ausgeführt. Ihre Berechtigung erlaubt es Ihnen daher, diese Infrastrukturfunktionen in Containern auszuführen. Darüber hinaus sind auch SDS-Lösungen (Software-Defined Storage), die Speicher für VMs bereitstellen, aber selbst in Containern ausgeführt werden, in der Berechtigung enthalten. Die Richtlinien für die Eignung dieser Infrastruktur-Container sind dieselben wie die für andere Editionen von Red Hat OpenShift zulässigen Workloads auf Infrastrukturknoten. Weitere Informationen zu Infrastrukturknoten finden Sie im Abschnitt „Was nicht gezählt wird“. Wenden Sie sich an Red Hat, um zu erfahren, ob eine App oder ein Service als Infrastruktur-Workload berechtigt ist.

Zur Bestimmung, wie viele selbst gemanagte OpenShift Subskriptionen (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform oder Red Hat OpenShift Kubernetes Engine) oder Add-on-Subskriptionen Sie benötigen, verwenden Sie die folgenden Fragen und Beispiele.

Zusammenfassung:

• Anwendungen sind in Container Images oder VMs paketiert.
• Container und VMs werden als Pods bereitgestellt.
• Pods werden auf OpenShift-Rechenknoten ausgeführt, die von den OpenShift Control Plane-Knoten verwaltet werden.

Bestimmung der erforderlichen Berechtigungen

Red Hat OpenShift Subskriptionen enthalten eine unbegrenzte Anzahl von Anwendungsinstanzen. Sie können so viele Anwendungsinstanzen in der Red Hat OpenShift Umgebung ausführen, wie die zugrunde liegende Hardware und Infrastruktur zulässt. Hardware mit großer Kapazität kann viele Anwendungsinstanzen auf einer kleinen Anzahl von Hosts ausführen, während Hardware mit kleiner Kapazität möglicherweise viele Hosts benötigt, um viele Anwendungsinstanzen auszuführen. Der wichtigste Faktor bei der Umfangsbestimmung einer Red Hat OpenShift Umgebung ist die Anzahl der Pods oder Anwendungsinstanzen, die zu einem beliebigen Zeitpunkt ausgeführt werden.

Schritt 1: Ermittlung der Anzahl und des Typs der benötigten Anwendungsinstanzen

Beginnen Sie mit den Anwendungen. Bestimmen Sie, wie viele Anwendungsinstanzen oder Pods Sie bereitstellen möchten. Bei der Umfangsbestimmung für die Umgebung werden die einzelnen Anwendungskomponenten, die auf Red Hat OpenShift bereitgestellt werden (etwa eine Datenbank, ein statischer Frontend-Server oder eine VM-Instanz), als Anwendungsinstanz betrachtet.

Diese Zahl kann ein Näherungswert sein, der Ihnen hilft, eine grobe Schätzung des Umfangs Ihrer Red Hat OpenShift Umgebung zu berechnen. CPU, Arbeitsspeicherüberbelegung, Quotas und Limits sowie andere Funktionen können verwendet werden, um diese Schätzung weiter zu verfeinern.

Tabelle 1: Fragen zur Umfangsbestimmung von Anwendungen und Instanzen

Wir haben eine Anwendung, die aus 200 Container-Instanzen besteht, die jeweils durchschnittlich 1 vCPU und 4 GB RAM verbrauchen. Unsere bevorzugte maximale Auslastung liegt bei 80 %. Wir führen die Anwendung auf AWS aus und haben Zugriff auf EC2 M6i-Instanztypen. Unsere Anwendung benötigt keine spezielle Hardware oder AI Accelerators. Wir haben uns für Red Hat OpenShift Platform Plus als selbst gemanagte Edition entschieden und brauchen im Moment nur eine Schätzung der Anzahl der benötigten Subskriptionen.

Schritt 1: Ermittlung der Anzahl und des Typs der benötigten Anwendungsinstanzen

Anhand der Informationen in unserem Beispiel:

• Anzahl der Anwendungsinstanzen = 200
• Bevorzugte maximale Knotenauslastung = 80 %
• Durchschnittlicher vCPU-Bedarf der Anwendung =1 vCPU
• Durchschnittlicher Arbeitsspeicherbedarf für die Anwendung = 4 GB

Schritt 2: Bestimmung des benötigten Gesamtspeichers und der Gesamtanzahl der Kerne

Mit den Zahlen aus Schritt 1 in unseren Berechnungen:

• Maximale Auslastung = 80 %
• Erforderliche vCPUs insgesamt = 1 vCPU X 200 X 1/80 % = 250 vCPUs
• Erforderlicher Speicherplatz insgesamt = 4 GB X 200 X 1/80 % = 1000 GB

Schritt 3: Auswahl eines standardmäßigen Rechenknotens

Nach den vorliegenden Informationen benötigen wir keinen Instanztyp mit GPU oder spezieller Hardware. Unser Verhältnis von vCPU:Speicher ist 250 vCPU:1000 GB, also 1:4. Glücklicherweise gibt es viele Instanztypen mit diesem Verhältnis. Nach einer Analyse der anderen für unsere Anwendung erforderlichen Faktoren sind wir zu dem Ergebnis gekommen, dass der Instanztyp m6i.4xlarge am besten für unsere Anforderungen geeignet ist. Jede Instanz verfügt über 16 vCPUs und 64 GB Speicher.

Schritt 4: Berechnung der erforderlichen Gesamtzahl an Subskriptionen

In diesem Fall wissen wir, dass wir Kernpaar-Subskriptionen benötigen, da wir in einer Hyperscaler Cloud arbeiten, und unsere Hyperscaler Cloud verwendet vCPU, also verwenden wir die Kernpaar-Subskriptionsformel in Schritt 2.

Gesamtzahl der Kernpaar-Subskriptionen = Gesamtzahl der benötigten vCPUs / 4, aufgerundet

250 vCPUs / 4 = 62,5 oder 63 aufgerundet

Schritt 5: Berechnung der gesamten AI Accelerator-Subskriptionen (falls zutreffend)

In diesem Beispiel zur Umfangsbestimmung werden keine AI Accelerators verwendet, sodass dies nicht zutrifft.

Ergebnis

In diesem Beispiel 1 werden 63 OpenShift Platform Plus Kernpaar-Subskriptionen benötigt.

Wir möchten nun dieselbe Anwendung On-Premise und auf Bare Metal ausführen, wobei wir VM-Rechenknoten mit der OpenShift Virtualization-Funktion von Red Hat OpenShift bereitstellen. Die Anwendung besteht aus 200 Container-Instanzen, die jeweils durchschnittlich 1 vCPU und 4 GB RAM verbrauchen. Unsere bevorzugte maximale Auslastung liegt bei 80 %. Unsere Anwendung benötigt keine spezielle Hardware oder AI Accelerators. Wir haben uns für Red Hat OpenShift Platform Plus als selbst gemanagte Edition entschieden und brauchen im Moment nur eine Schätzung der Anzahl der benötigten Subskriptionen. Wir haben eine gewisse Flexibilität bei der Wahl der Bare Metal-Konfiguration, aber wir verwenden handelsübliche Standard-Serverkonfigurationen.

Schritt 1: Ermittlung der Anzahl und des Typs der benötigten Anwendungsinstanzen

Anhand der Informationen in unserem Beispiel:

• Anzahl der Anwendungsinstanzen = 200
• Bevorzugte maximale Knotenauslastung = 80 %
• Durchschnittlicher vCPU-Bedarf der Anwendung =1 vCPU
• Durchschnittlicher Arbeitsspeicherbedarf für die Anwendung = 4 GB

Schritt 2: Bestimmung des benötigten Gesamtspeichers und der Gesamtanzahl der Kerne

Mit den Zahlen aus Schritt 1 in unseren Berechnungen:

• Maximale Auslastung = 80 %
• Erforderliche vCPUs insgesamt = 1 vCPU X 200 X 1/80 % = 250 vCPUs
• Erforderlicher Speicherplatz insgesamt = 4 GB X 200 X 1/80 % = 1000 GB

Schritt 3: Auswahl eines standardmäßigen Rechenknotens

Unser aktueller Bare Metal-Serverstandard ist ein Server mit 2 Sockets und 32 Kernen/64 vCPUs pro Socket. Wir haben die Wahl zwischen verschiedenen RAMs. Da das Verhältnis von vCPU zu RAM 1:4 ist, statten wir unsere Server mit 256 GB RAM aus. Daher ist unsere Wahl für einen Bare Metal-Server ein Server mit 2 Sockets und 32 Kernen/64 vCPUs pro Socket (64 Kerne/128 vCPUs pro Server) und 256 GB RAM.

Schritt 4: Berechnung der erforderlichen Gesamtzahl an Subskriptionen

Bei einem Bare Metal-Server haben wir die Wahl zwischen Kernpaar-Subskriptionen und Bare Metal Socket-Paar-Subskriptionen. Berechnen wir also beides:

Gesamtzahl der Kernpaar-Subskriptionen = Gesamtzahl der benötigten vCPUs / 4, aufgerundet

250 vCPUs / 4 = 62,5 oder 63 aufgerundet

Gesamtanzahl Socket-Paar-Subskriptionen =

• Gesamtzahl der benötigten Server = 250 vCPUs / 128 vCPUs pro Server, aufgerundet = 2 Server
• Gesamtzahl der benötigten Subskriptionen pro Server = Anzahl der Kerne pro Socket-Paar / 128, aufgerundet = 64/128 = 0,5 aufgerundet auf  1 Subskription
• 2 Server x 1 Subskription/Server = 2 Bare Metal Socket-Paar-Subskriptionen

Da wir in diesem Fall einen Server auswählen konnten, der das richtige Verhältnis von vCPU zu Arbeitsspeicher bietet, brauchen wir nicht die Anzahl der Server zu berechnen, die für die Speicheranforderungen erforderlich sind, und wählen den größeren der beiden. Wenn der von uns gewählte Server über eine andere Menge an Arbeitsspeicher verfügen würde, müssten wir diesen Unterschied in Betracht ziehen.

Schritt 5: Berechnung der gesamten AI Accelerator-Subskriptionen (falls zutreffend)

In diesem Beispiel zur Umfangsbestimmung werden keine AI Accelerators verwendet, sodass dies nicht zutrifft.

Ergebnis

Für dieses Beispiel sind 63 OpenShift Platform Plus Kernpaar-Subskriptionen oder 2 Bare Metal Socket-Paar-Subskriptionen erforderlich. In diesem Fall geht es darum, die beste finanzielle und architektonische Entscheidung zu treffen. 

Wir verschieben unsere VMs von einem anderen Hypervisor zu Red Hat. Dabei handelt es sich um eine gemischte Umgebung, aber wir haben die folgende Anzahl verschiedener VM-Größen ermittelt:

• 1000 Small = 1000 vCPUs, 4000 GiB. Plus 228 GiB Speicher-Overhead
• 300 Medium = 600 vCPUs, 2400 GiB. Plus 73 GiB Speicher-Overhead
• 200 Large = 800 vCPUs, 4800 GiB. Plus 58 GiB Speicher-Overhead
• 200 X-Large = 1600 vCPUs, 9600 GiB. Plus 64 GiB Speicher-Overhead

Schritt 1: Ermittlung der Anzahl und des Typs der benötigten Anwendungsinstanzen

Anhand der Informationen in unserem Beispiel:

• Anzahl der Anwendungsinstanzen = 1700
• vCPUs insgesamt = 4000 vCPUs
• Speicher insgesamt = 20800 GB + 423 GB Overhead = 21223 GB
• Durchschnittlicher vCPU-Bedarf der Anwendung =2,4 vCPUs
• Durchschnittlicher Arbeitsspeicherbedarf für die Anwendung = 12,5 GB

Schritt 2: Bestimmung des benötigten Gesamtspeichers und der Gesamtanzahl der Kerne

Mit den Zahlen aus Schritt 1 in unseren Berechnungen:

• Erforderlicher Speicher insgesamt = 20.800 GB + 423 GB Overhead = 21.223 GB
• Erforderliche vCPUs insgesamt = 4000 vCPUs

Die Metrik der maximalen Auslastung für VMs ist etwas anders als die für Container, sollte aber Virtualisierungsadmins bekannt sein.

Im Allgemeinen empfehlen wir keine übermäßige Speicherbelegung für VMs, sodass der Gesamtspeicherbedarf generell zum wichtigsten Faktor für die Anzahl der Rechenknoten wird.

Bei den Rechenressourcen erwarten wir eine Überbelegung der CPU, da die meisten VMs im Durchschnitt nicht alle ihre Rechenressourcen nutzen. Das maximale CPU-Überbelegungsverhältnis für OpenShift Virtualization ist auf 10:1 festgelegt, sodass die Wahl eines Verhältnisses von 4:1 konservativ ist. Hier können wir auch wählen, ob wir Kerne oder Threads (mit Hyperthreading-Unterstützung sind es 2 Threads pro Kern) verwenden wollen, um eine vCPU zu erhalten. Wir können vorsichtig sein und 1 vCPU = 1 Kern und kein Hyperthreading wählen. Unsere Anforderungen lauten also:

• Erforderlicher Speicher insgesamt = 20.800 GB + 423 GB Overhead = 21.223 GB
• Erforderliche Kerne insgesamt = 4000 vCPUs x 1/4 x 1 Kern/vCPU = 1000 Kerne

Schritt 3: Auswahl eines standardmäßigen Rechenknotens

Die Wahl eines Bare Metal-Rechenknotens für die Virtualisierung hängt von vielen Faktoren ab, unter anderem von der Redundanz und den Fehler-Domains, der Größe des Clusters usw. On-Premise haben wir einige Möglichkeiten, einschließlich der Erhöhung des RAM pro Server. Da der Arbeitsspeicher im Allgemeinen die Serveranforderungen bestimmt, können wir dort beginnen.

Wir verfügen über 1700 VMs und entscheiden uns für einen Server mit 2 Sockets und 32 Kernen pro Socket. Anhand der Anzahl der Kerne können wir die Anzahl der benötigten Server ermitteln:

• 1000 Kerne / 64 Kerne/Server, aufgerundet = 16 Server

Bei 16 Servern benötigen wir 21.223 GB / 16 Server = 1.326 GB Ram pro Server. Bei unserem Server können wir 1.536 GB RAM wählen. Unsere Bare Metal-Konfiguration lautet also:

• Server mit 2 Sockets und 32 Kernen/Socket (64 Kerne insgesamt), 1.536 GB RAM

Bei 16 Servern mit dieser Konfiguration ergibt sich schließlich eine Gesamtzahl von:

• 16 x 64 Kerne = 1024 Kerne
• 16 x 1.536 GB = 24.576 GB Speicher

Dies reicht aus, um die VM-Workloads auszuführen, aber wir benötigen zusätzliche Server für die Redundanz. Wir können uns derzeit den Ausfall eines einzelnen Servers oder schwerwiegende Performance-Einbußen nicht leisten. Unsere Virtualisierungsadmins raten uns, 25 % freie Kapazität für Failover und Redundanz bereitzuhalten. Daher benötigen wir:

• 16 Server + (16 Server * 25 %) = 20 Server insgesamt

Wir verteilen die VMs auf die 20 Server, sodass wir auch bei einem Ausfall von 1–4 Servern die Anforderungen unserer VMs erfüllen können. (Ihre Resilienzanforderungen können hiervon abweichen.)

Schritt 4: Berechnung der erforderlichen Gesamtzahl an Subskriptionen

Für einen reinen Virtualisierungs-Use Case verwenden wir die OpenShift Virtualization Engine, die nur in Bare Metal Socket-Paar-Subskriptionen verfügbar ist.

Gesamtanzahl Socket-Paar-Subskriptionen =

• Gesamtzahl der benötigten Server = 20
• Gesamtzahl der benötigten Subskriptionen pro Server= 1, da unsere Server eine Höchstgrenze von 64 Kernen/Socket-Paar haben
• 20 Server x 1 Subskription/Server = 20 Bare Metal Socket-Paar-Subskriptionen

Schritt 5: Berechnung der gesamten AI Accelerator-Subskriptionen (falls zutreffend)

In diesem Beispiel zur Umfangsbestimmung werden keine AI Accelerators verwendet, sodass dies nicht zutrifft.

Ergebnis

Für dieses Beispiel sind 20 Bare Metal Socket-Paar-Subskriptionen für OpenShift Virtualization Engine erforderlich. 

Tabelle 1: Allgemeine Funktionsunterschiede nach Red Hat OpenShift Edition

Tabelle 2: Detaillierte Unterschiede zwischen den Editionen von Red Hat OpenShift, einschließlich der Operatoren, die diese Funktionen bereitstellen

Hinweis 1: Der in Red Hat OpenShift enthaltene OpenShift Elasticsearch Operator ist nur für die Unterstützung der internen Infrastruktur-Suchanforderungen des OpenShift Clusters lizenziert und kann nicht als Standalone-Lösung für Kundenanwendungen verwendet werden.

Gängige Software von Red Hat, die in keiner der Red Hat OpenShift Editionen enthalten ist

Sofern nicht anders angegeben, müssen die folgenden Softwareangebote von Red Hat, die üblicherweise in Verbindung mit OpenShift verwendet werden, separate Berechtigungen erhalten. Red Hat OpenShift Platform Plus umfasst Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay und Red Hat OpenShift Data Foundation Essentials. Andere selbst gemanagte OpenShift Subskriptionen beinhalten diese zusätzlichen Produkte nicht, sie können aber separat erworben werden. Weitere Software von Red Hat, die mit Red Hat OpenShift verwendet wird, aber nicht in diesem Subskriptions-Guide enthalten ist:

• Red Hat Ansible Automation Platform
• Red Hat Application Foundations
• Red Hat Enterprise Linux AI
• Portfolio von Red Hat Integration, einschließlich 3scale, AMQ, Camel K, Fuse usw.
• Red Hat JBoss EAP
• Red Hat Middleware Bundles
• Red Hat OpenShift Developer Hub (Version von Red Hat für das Backstage-Projekt)
• Red Hat OpenShift AI
• Red Hat Satellite (für die Verwaltung von Red Hat Enterprise Linux)
• IBM CloudPaks

Weitere Informationen zu den oben genannten Angeboten erhalten Sie über den Vertrieb von Red Hat oder Ihren jeweiligen Partner.