Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
ROSA Architektur
Red Hat OpenShift Service in AWS (ROSA) hat die folgenden Cluster-Topologien:
-
Gehostete Kontrollebene (HCP) — Die Kontrollebene wird bei Red Hat gehostet AWS-Konto und von Red Hat verwaltet. Worker-Knoten werden beim Kunden eingesetzt AWS-Konto.
-
Klassisch — Die Steuerungsebene und die Worker-Knoten werden beim Kunden bereitgestellt AWS-Konto.
ROSAHCPbietet eine effizientere Architektur der Steuerungsebene, die dazu beiträgt, die beim Betrieb anfallenden AWS Infrastrukturgebühren zu senken ROSA und die Clustererstellung zu beschleunigen. HCPSowohl ROSA mit als auch mit ROSA Classic können in der AWS ROSA Konsole aktiviert werden. Sie haben die Wahl, welche Architektur Sie verwenden möchten, wenn Sie ROSA Cluster mithilfe von bereitstellen ROSA CLI.
Anmerkung
ROSAmit Hosted Control Planes (HCP) bietet keine Compliance-Zertifizierungen für RAMP hohe und HIPAA qualifizierte Fed. Weitere Informationen finden Sie unter Compliance
Anmerkung
ROSAmit Hosted Control Planes (HCP) bietet keine Federal Information Processing Standard (FIPS) -Endpunkte.
Vergleich ROSA mit HCP und klassisch ROSA
In der folgenden Tabelle werden ROSA klassische Architekturmodelle verglichenROSA. HCP
| ROSAmit HCP | ROSAklassisch | |
|---|---|---|
|
Hosting der Cluster-Infrastruktur |
Komponenten der Steuerungsebene, wie etcd, API Server und OAuth, werden in einem Unternehmen von Red Hat gehostet. AWS-Konto |
Komponenten der Steuerungsebene, wie etcd, API Server und Oauth, werden in einem kundeneigenen Gebäude gehostet. AWS-Konto |
|
Amazon VPC |
Worker-Knoten kommunizieren mit der Steuerungsebene über. AWS PrivateLink |
Worker-Knoten und Knoten auf der Kontrollebene werden beim Kunden eingesetztVPC. |
|
AWS Identity and Access Management |
Verwendet AWS verwaltete Richtlinien. |
Verwendet vom Kunden verwaltete Richtlinien, die vom Service definiert werden. |
|
Bereitstellung in mehreren Zonen |
Die Steuerungsebene wird in mehreren Availability Zones (AZs) eingesetzt. |
Die Kontrollebene kann innerhalb einer einzelnen AZ oder in mehreren AZ bereitgestellt werdenAZs. |
|
Infrastrukturknoten |
Verwendet keine dedizierten Infrastrukturknoten. Plattformkomponenten werden auf Worker-Knoten bereitgestellt. |
Verwendet zwei dedizierte Single-AZ- oder drei Multi-AZ-Knoten zum Hosten von Plattformkomponenten. |
|
OpenShift Fähigkeiten |
Plattformüberwachung, Image-Registrierung und der Ingress-Controller werden in den Worker-Knoten bereitgestellt. |
Plattformüberwachung, Image-Registrierung und der Ingress-Controller werden in speziellen Infrastrukturknoten bereitgestellt. |
|
Cluster-Upgrades |
Die Steuerungsebene und jeder Maschinenpool können separat aktualisiert werden. |
Der gesamte Cluster muss gleichzeitig aktualisiert werden. |
|
Minimaler Amazon EC2 Platzbedarf |
Zwei Amazon EC2 Instanzen sind erforderlich, um einen Cluster zu erstellen. |
Sieben Single-AZ- oder neun Amazon EC2 Multi-AZ-Instances sind erforderlich, um einen Cluster zu erstellen. |
|
AWS-Regionen |
Informationen zur AWS-Region Verfügbarkeit finden Sie unter Red Hat OpenShift Service in AWS Endpunkte und Kontingente im AWS Allgemeinen Referenzhandbuch. |
Informationen zur AWS-Region Verfügbarkeit finden Sie unter Red Hat OpenShift Service in AWS Endpunkte und Kontingente im AWS Allgemeinen Referenzhandbuch. |
