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 ist als 2 physische Kerne oder als 4 vCPUs (Virtual Central Processing Units) 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-Knoten: Hierbei handelt es sich um eine weitere Grundlage für selbst gemanagte OpenShift-Subskriptionen. Pro physischem Server ist eine Subskription für einen Bare Metal-Knoten erforderlich. Eine einzelne Subskription für einen Bare Metal-Knoten 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.
• 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 Upgrades, verwalten die untergeordnete Infrastruktur und sorgen für die Einhaltung der SLAs (Service Level Agreements).

Gemanagte 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 Kernservices und der 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 Amazon Web Services (AWS) und Google Cloud.
• Microsoft Azure Red Hat OpenShift: Ein vollständig gemanagter Service von Red Hat OpenShift auf Microsoft Azure, von Red Hat und Microsoft gemeinsam gemanagt.
• Red Hat OpenShift Service on AWS: Ein vollständig gemanagter Service von Red Hat OpenShift auf Amazon Web Services, von Red Hat und AWS gemeinsam gemanagt.
• Red Hat OpenShift on IBM Cloud: Ein vollständig gemanagter Service von Red Hat OpenShift auf IBM Cloud, von Red Hat und IBM gemeinsam 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 Red Hat OpenShift Kernfunktionen für die Bereitstellung und Ausführung von Anwendungen bietet. Sie kann in Rechenzentrums-, 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 in Rechenzentrums-, 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 Schichten für Sicherheit, Verwaltbarkeit und Automatisierung sorgen für Konsistenz in der gesamten Softwarelieferkette. 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-Knoten) 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-Knoten 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 Gesamtanzahl 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 stehen 2 Support-SLAs zur Auswahl: Standard (werktags von 8:00 bis 17:00 Uhr) oder Premium (rund um die Uhr).

2. Bare Metal-Knoten (1 physischer Knoten) 

• Ein physischer Knoten ist 1 Server, unabhängig von der Anzahl der CPU-Sockets im Server oder der Kerne in den CPUs.
• 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 stehen 2 Support-SLAs zur Auswahl: Standard (werktags von 8:00 bis 17:00 Uhr) oder Premium (rund um die Uhr).

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 stehen 2 Support-SLAs zur Auswahl: Standard (werktags von 8:00 bis 17:00 Uhr) oder Premium (rund um die Uhr). Das SLA muss mit dem SLA der unterstützenden Subskription für das Kernpaar oder den Bare Metal-Knoten ü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 Subskriptionen für Bare Metal-Knoten 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 Subskriptionen für Bare Metal-Knoten 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-Knotenmodell 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 Subskription für Bare Metal-Knoten?

Subskriptionen für Bare Metal-Knoten sind nur eine Option für OpenShift-Rechenknoten, 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. Subskriptionen für Bare Metal-Knoten 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 Subskriptionen für Bare Metal-Knoten berechtigt einen einzelnen physischen Knoten, unabhängig von der Gesamtanzahl der CPU-Sockets oder -Kerne.

Ein physischer Bare Metal-Server, der Berechtigungen pro Knoten 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 Subskriptionen mit Knoten 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 nachfolgenden Abschnitt über die OpenShift Virtualization Engine 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 Subskription für Bare Metal-Knoten 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 Subskriptionen für Kernpaare und Bare Metal-Knoten 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 -Knoten-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.

Um als Infrastrukturknoten zu fungieren und die enthaltene Berechtigung zu nutzen, dürfen 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 sowie Multi Cluster-Ingress)
• OpenShift Observability
• HAProxy-basierte Instanzen, die für den Cluster-Ingress verwendet werden
• 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
• Ansible Automation Platform, wenn es nur für das Cluster-Management verwendet wird

Sie können benutzerdefinierte und externe Agenten und Tools für Monitoring, 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-Suite. Beispiele für nicht von Red Hat stammende Software, die als berechtigte Infrastruktur-Workload gilt:

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

Mit der enthaltenen Berechtigung können keine anderen Endbenutzeranwendungs-Instanzen oder -Typen auf einem Infrastrukturknoten 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-IPI (Installer-Provisioned Infrastructure) 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 zum Spiegeln 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 Installationsprogramm 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 Subskriptionen für Bare Metal-Knoten.

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 kompakten Cluster Deployments 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 mit einem einzelnen Knoten stellt sämtliche OpenShift-Services und Endbenutzeranwendungen auf einem einzigen physischen oder virtuellen Knoten bereit, einschließlich Optimierungen, um den Footprint 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 DR-Umgebungen (Disaster Recovery): Hot, Warm und Cold. Kostenpflichtige Red Hat OpenShift Subskriptionen werden nur für Hot-DR benötigt.

• Hot-DR-Systeme sind per Definition voll funktionsfähig und werden gleichzeitig mit den Produktionssystemen ausgeführt. Sie sind bereit, sofort Datenverkehr zu empfangen und im Falle einer Störung in der primären Umgebung die Aufgaben zu übernehmen. Wenn Daten-Volumes aktiv repliziert werden – entweder synchron oder asynchron durch auf OpenShift gehostetem Software-Defined Storage zwischen Clustern –, werden diese Systeme als Hot-DR-Systeme bezeichnet.
• Warm-DR-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-DR-Cluster sollten nicht an der aktiven Replikation von Daten-Volumes zwischen Clustern teilnehmen, weder synchron noch asynchron, wenn der sekundäre (DR-)Standort diese Daten in Container-Workloads mountet, die aktiv auf dem Cluster ausgeführt werden. Externe Storage-Geräte, die eine Volume-Replikation durchführen, gelten weiterhin als Warm-DR. Bei auf OpenShift gehostetem Software-Defined Storage erfordert die Warm-DR, dass die Kundendaten von außerhalb des Clusters auf der vorhandenen Cluster-Hardware wiederhergestellt werden.
• Cold-DR-Systeme verfügen per Definition über die Infrastruktur, aber nicht über die gesamte Technologie (Hardware, Software und Daten), die zur Wiederherstellung des Betriebs erforderlich ist. 

Cluster im Ruhezustand, die nicht speziell für Warm- oder Cold-DR 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 den Softwareangeboten von Red Hat OpenShift. 

Sowohl bei der Warm-DR als auch bei der Cold-DR können 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 sicherzustellen.

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. Socketbasierte Bare Metal-Subskriptionen von Red Hat OpenShift können nicht mit IBM Z- und IBM Power-Plattformen verwendet werden. 

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 Kern-Subskription erforderlich (IBM Z ist die einzige Architektur, bei der die Grundlage für Subskriptionen ein einzelner Kern ist). In dieser Architektur gibt es kein vCPU-Konzept. 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. 

Für IBM Power wird das Kernpaar-Subskriptionsmodell verwendet. In dieser Architektur gibt es kein vCPU-Konzept.

Die Komponenten der Red Hat OpenShift Platform Plus Subskription haben unterschiedliche Supportstufen für alternative (Nicht-x86-)Architekturen. Weitere Informationen hierzu finden Sie im Artikel „Red Hat OpenShift Container Platform 4.19 Multi Architecture Component Availability Matrix“ im Red Hat Customer Portal (Anmeldung erforderlich). 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 eigenständige Subskription verkauft, deren Preis pro Kern berechnet wird.

Die Infrastruktur von Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform und Red Hat OpenShift Kubernetes Engine 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. Die vorherigen Berechnungen sind Richtlinien, und möglicherweise können Sie Ihre tatsächliche Umgebung für eine bessere Ressourcennutzung oder eine geringere Gesamtgröße der Umgebung optimieren. 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 als Reseller zusammenarbeiten, beachten Sie dessen spezifische Bedingungen und Vereinbarungen für Red Hat Produkte und Services. 

Red Hat OpenShift Platform Plus umfasst zusätzliche Software über die OpenShift Container Platform hinaus, mit der Sie Ihre Red Hat OpenShift Umgebung in großem Umfang über mehrere Cluster und mehrere Clouds hinweg verwalten und schützen können. OpenShift Platform Plus ist sowohl im Subskriptionsmodell für Kernpaare als auch für Bare Metal-Knoten 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. 

Auch die zusätzlichen Software-Subskriptionen können nicht von der Subskription für OpenShift Platform Plus getrennt werden. 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 zur Verwaltung derselben 200 Kerne verwendet werden, auf denen die OpenShift Platform Plus-Kernsoftware installiert ist.

Spezifische Regeln für die mehrschichtigen Produkte:

• Red Hat Advanced Cluster Management for Kubernetes: Mit einer OpenShift Platform Plus Subskription können Sie so viele zentrale Instanzen von Red Hat Advanced Cluster Management installieren, 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 Subskriptionen für Red Hat Advanced Cluster Management, von Red Hat Advanced Cluster Management unterstützten Umgebungen und Best Practices für Red Hat Advanced Cluster Management.
• Red Hat Advanced Cluster Security for Kubernetes: Mit der OpenShift Platform Plus Subskription können Sie so viele zentrale Anwendungen von Red Hat Advanced Cluster Security installieren, 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 von Red Hat Advanced Cluster Security unterstützten Umgebungen.
• Red Hat Quay: Mit der 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 unbegrenzt 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 (Software as a Service) 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 Berechtigung für Red Hat Data Foundation gilt nur für die in Essentials verfügbaren Funktionen und ist auf 256 TB Daten-Storage pro OpenShift Cluster begrenzt. Sie können Funktionen und Kapazitäten mit zusätzlichen Subskriptionen 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.
• Argo CD Agent: Mit der OpenShift Platform Plus Subskription können Sie die Argo CD Agent-Komponente von Red Hat OpenShift GitOps auf beliebigen Clustern installieren, für die eine Subskription für OpenShift Platform Plus besteht. Argo CD Agent kann in Red Hat OpenShift oder unterstützten Kubernetes-Umgebungen ausgeführt werden. (Red Hat OpenShift GitOps ist in OpenShift Container Platform enthalten.)

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. Die Kunden konzentrieren sich ausschließlich auf die Virtualisierung und haben die Option, moderne Anwendungsentwicklungs- und Containerisierungsfunktionen in ihrem eigenen Tempo einzuführen.

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 Subskriptionen für Bare Metal-Knoten auf unterstützten physischen Servern und auf unterstützten Hyperscaler Bare Metal-Instanzen berechtigt. Wenn Nutzende für ein Upgrade auf das erweiterte Portfolio bereit sind, können sie ihre Subskriptionsberechtigungen ändern und müssen bestehende Cluster nicht erneut bereitstellen.

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 for Virtual Datacenters oder Subskriptionen pro VM erforderlich)

OpenShift Virtualization Engine wird sowohl von Red Hat Advanced Cluster Management als auch von Red Hat Ansible® Automation Platform unterstützt. Add-on-Subskriptionen für beide Produkte sind speziell für reine Virtualisierungs-Use Cases zu einem reduzierten Preis im Vergleich zur Vollversion erhältlich. 

Bestehende Kunden von Red Hat Advanced Cluster Management und Ansible Automation 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 Red Hat Advanced Cluster Management oder Ansible Automation 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 Red Hat Advanced Cluster Management oder Ansible Automation 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, Red Hat 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, mit dem sich eine grobe Schätzung des Umfangs Ihrer Red Hat OpenShift Umgebung berechnen lässt. 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

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

Sobald Sie die Anforderungen für eine Anwendungsinstanz und die Anzahl der Anwendungsinstanzen bestimmt haben, ist die Ermittlung des Gesamtbedarfs an Ressourcen, sowohl an Rechenleistung als auch an Speicher, einfach. 

Zu diesem Zeitpunkt sollten Sie eine maximale Auslastung festlegen, die Ihre Rechenknoten erfüllen sollen. Dies sollte Platz für den Management-Overhead von OpenShift schaffen (weitere Details finden Sie in der Dokumentation, aber typischerweise 1 Kern oder 1 vCPU und  1 GB RAM pro Rechenknoten) und normale Schwankungen in der Anwendung zulassen, bevor eine automatische Skalierung erforderlich ist. Wenn Sie von einer aggressiven Auslastung ausgehen (mehr als 80 %), müssen Sie möglicherweise die OpenShift-Overhead-Anforderungen bei der Berechnung der Speicher- und Kernressourcen explizit berücksichtigen.

Bei Virtualisierungs-Use Cases müssen Sie die Überlastung von CPU und Speicher, Redundanz und Hochverfügbarkeit sowie die Gesamtarchitektur der Umgebung berücksichtigen. In Beispiel 3 zur Umfangsbestimmung werden wir das anhand einer Illustration erläutern.

Tabelle 2: Fragen zur gewünschten maximalen OpenShift-Knotenauslastung

Maximale Auslastung = % nach Wahl des Architekturteams

Erforderliche Kerne (oder vCPUs) insgesamt = „Kerne für 1 Anwendung“ x „Anzahl der Anwendungsinstanzen“ x 1 / „Prozent Auslastung“

Erforderlicher Speicher insgesamt = „Speicher für 1 Anwendung“ x „Anzahl der Anwendungsinstanzen“ x 1 / „Prozent Auslastung“

Schritt 3: Auswahl eines Standard-Rechenknotens (VM, Cloud-Instanz oder Bare Metal-Server)

Nun haben Sie die Gesamtanzahl der Kerne und die Gesamtmenge des Speichers, die Sie berücksichtigen wollen. Sie müssen nun einen Standard-Rechenknoten auswählen, um die Worker-Knoten für Ihre Anwendungen bereitzustellen. 

In einer Virtualisierungsinfrastruktur können Sie in Ihrer Umgebung die Konfiguration der VMs wählen, die als Rechenknoten dienen sollen, oder Sie müssen einen von mehreren Standardgrößen für VMs auswählen. 

In einer Hyperscaler Cloud müssen Sie in der Regel einen Cloud-Instanztyp mit unterschiedlicher Rechenleistung, Speicher und Zugang zu optionaler Ausstattung wie AI Accelerators wählen. 

Beim Deployment auf Bare Metal, entweder On-Premise oder in einer Hyperscaler Bare Metal-Instanz, haben Sie möglicherweise eine Standard-Serverkonfiguration, und manchmal können Sie die Konfiguration festlegen. 

Wenn möglich, sollten Sie Rechenknoten wählen, die dem Verhältnis zwischen Kern- und Speicherbedarf am ehesten entsprechen. Wenn beispielsweise der Gesamtbedarf für die Container 400 vCPUs und 1600 GB RAM beträgt, ergibt sich das beste durchschnittliche Konsolidierungsverhältnis durch die Auswahl von Rechenknoten mit einem Verhältnis von etwa 1:4 aus vCPU und Speicher. 

Tabelle 3: Fragen zur Umfangsbestimmung für VMs und Hardware

Schritt 4: Berechnung der erforderlichen Gesamtanzahl an Subskriptionen

Bestimmen Sie schließlich die Anzahl der benötigten Red Hat OpenShift Subskriptionen anhand der in den Schritten 1–3 gesammelten Daten. Im Falle von Subskriptionen auf VMs oder Hyperscaler Cloud-Instanzen müssen Sie das Kernpaar-Subskriptionsmodell verwenden. Bei Bare Metal-Servern sollten Sie die Subskription mit beiden Modellen berechnen, die Kosten- und Flexibilitätsunterschiede der einzelnen Modelle vergleichen und die für Ihre Anforderungen am besten geeignete Wahl treffen. 

Für das Kernpaar-Subskriptionsmodell

• Anzahl der selbst gemanagten OpenShift-Kernpaar-Subskriptionen¹ 

= Kerne insgesamt / 2, aufgerundet oder

= vCPUs insgesamt / 4, aufgerundet

Für das Subskriptionsmodell für Bare Metal-Knoten

• Erstens: Berechnen Sie die Anzahl der für Ihre Anwendung benötigten Kernpaar-Subskriptionen, da Sie das Kernpaar-Modell in einer Bare Metal-Installation verwenden können.
• Zweitens: Bestimmen Sie die Anzahl der Bare Metal-Subskriptionen: Jeder physische Server erfordert eine Bare Metal-Knotensubskription (Sie benötigen 1 Subskription pro Knoten).
• Drittens: Vergleichen Sie die Kosten- und Flexibilitätsunterschiede zwischen den beiden Modellen.
  • Finanziell:
    • Ein Subskriptionsmodell ist für Ihre Umgebung wahrscheinlich kostengünstiger als ein anderes.
    • Bei der Zukunftsplanung kann es eine Rentabilitätsschwelle geben, ab der das andere Modell aus finanzieller Sicht die bessere Wahl ist.
  • Architektonisch:
    • Kernpaar-Subskriptionen können standortunabhängig in Ihrer Umgebung verwendet werden (VMs, Cloud-Instanzen, Bare Metal-Server), während Subskriptionen für Bare Metal-Knoten nur auf Bare Metal-Servern verwendet werden können.
    • Kernpaar-Subskriptionen auf Bare Metal-Servern müssen Container direkt auf Bare Metal ausführen und sich im selben Cluster befinden.
    • Sie können OpenShift Virtualization Engine auf Bare Metal-Servern installieren und dann Kernpaar-OpenShift-Subskriptionen für Container darauf aufsetzen (OpenShift auf OpenShift). Dies eignet sich am besten für eine gemischte VM-Umgebung mit einer relativ geringen Anzahl von OpenShift-Subskriptionen pro Server.
    • Wenn Sie eine hohe Dichte an Red Hat OpenShift Workloads auf einem Bare Metal-Server benötigen, erhalten Sie mit einer Subskription für Bare Metal-Knoten eine unbegrenzte Anzahl an OpenShift-Containern entweder direkt auf dem Bare Metal-Server oder mit der OpenShift Virtualization-Funktion innerhalb von VMs, die auf dem Server ausgeführt werden.

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

Fügen Sie sämtliche oben genannten AI Accelerator-Subskriptionen hinzu. Sie benötigen eine AI Accelerator-Subskription pro physischem Accelerator On-Premise oder auf einem Bare Metal-Server. In einer Hyperscaler Cloud-Umgebung wird bei den Instanztypen für beschleunigtes Computing die Anzahl der physischen GPUs oder Accelerators aufgeführt, die in diesem Instanztyp enthalten sind. Denken Sie daran, das SLA der AI Accelerator-Subskription mit der entsprechenden Red Hat OpenShift Subskription abzugleichen.

Hinweis: Red Hat OpenShift unterstützt viele Funktionen für Skalierbarkeit, Pod-Planung, ungenutzte Kapazitäten und Ressourcen-Quotas/-begrenzungen. Die vorherigen Berechnungen sind Richtlinien, und möglicherweise können Sie Ihre tatsächliche Umgebung für eine bessere Ressourcennutzung oder eine geringere Gesamtgröße der Umgebung optimieren. 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 als Reseller zusammenarbeiten, beachten Sie dessen spezifische Bedingungen und Vereinbarungen für Red Hat Produkte und Services. 

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 Speicher-Footprint der 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 Gesamtanzahl 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 Speicher-Footprint der 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 Gesamtanzahl an Subskriptionen

Bei einem Bare Metal-Server haben wir die Wahl zwischen Subskriptionen für Kernpaare oder für Bare Metal-Knoten. Berechnen wir also beides:

Gesamtanzahl der Kernpaar-Subskriptionen = Gesamtanzahl der benötigten vCPUs / 4, aufgerundet 
250 vCPUs / 4 = 62,5 oder 63 aufgerundet

Gesamtanzahl der Knotensubskriptionen = Gesamtanzahl der physischen Server

• Gesamtanzahl der benötigten Server = 250 vCPUs / 128 vCPUs pro Server, aufgerundet = 2 Server
• 2 Server x 1 Subskription/Server = 2 Bare Metal-Knotensubskriptionen

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 Erfüllung der 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-Knotensubskriptionen 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 = 20.800 GB + 423 GB Overhead = 21.223 GB
• Durchschnittlicher vCPU-Bedarf der Anwendung = 2,4 vCPUs
• Durchschnittlicher Speicher-Footprint der 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 = 4.000 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 = 4.000 vCPUs x 1/4 x 1 Kern/vCPU = 1.000 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 Gesamtanzahl 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 Gesamtanzahl an Subskriptionen

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

Gesamtanzahl der Knotensubskriptionen = 

• Gesamtanzahl der benötigten Server = 20
• 20 Server x 1 Subskription/Server = 20 Bare Metal-Knotensubskriptionen

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-Knotensubskriptionen 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 (üblicherweise in Verbindung mit Red Hat OpenShift verwendet) 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 Advanced Developer Suite
• 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 Data Foundation Advanced
• 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.