Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
ROSA architecture
Red Hat OpenShift Service on AWS (ROSA) possède les topologies de cluster suivantes :
-
Plan de contrôle hébergé (HCP) - Le plan de contrôle est hébergé dans Red Hat Compte AWS et géré par Red Hat. Les nœuds de travail sont déployés chez le client Compte AWS.
-
Classique — Le plan de contrôle et les nœuds de travail sont déployés chez le client Compte AWS.
ROSAavec HCP offre une architecture de plan de contrôle plus efficace qui permet de réduire les frais AWS d'infrastructure liés à l'exécution ROSA et d'accélérer les temps de création de clusters. La version ROSA avec HCP et la ROSA version classique peuvent être activées dans la AWS ROSA console. Vous avez le choix de sélectionner l'architecture que vous souhaitez utiliser lorsque vous provisionnez des ROSA clusters à l'aide du ROSA CLI.
Note
ROSAavec des plans de contrôle hébergés (HCP) n'offre pas les certifications de conformité Fed RAMP High et HIPAA Qualified. Pour plus d'informations, consultez la section Conformité
Note
ROSAavec des plans de contrôle hébergés (HCP) ne propose pas de points de terminaison Federal Information Processing Standard (FIPS).
Comparaison ROSA avec HCP et ROSA classique
Le tableau suivant ROSA compare HCP les modèles d'architecture ROSA classiques.
| ROSAavec HCP | ROSAclassique | |
|---|---|---|
|
Hébergement d'infrastructures de clusters |
Les composants du plan de contrôle, tels que etcd, API server et oauth, sont hébergés dans un environnement appartenant à Red Hat. Compte AWS |
Les composants du plan de contrôle, tels que etcd, API server et oauth, sont hébergés dans un établissement appartenant au client. Compte AWS |
|
Amazon VPC |
Les nœuds de travail communiquent avec le plan de contrôle AWS PrivateLink. |
Les nœuds de travail et les nœuds du plan de contrôle sont déployés chez le clientVPC. |
|
AWS Identity and Access Management |
Utilise des politiques AWS gérées. |
Utilise les politiques gérées par le client définies par le service. |
|
Déploiement multizone |
Le plan de contrôle est déployé sur plusieurs zones de disponibilité (AZs). |
Le plan de contrôle peut être déployé au sein d'une seule zone d'exploitation ou sur plusieurs zonesAZs. |
|
Nœuds d'infrastructure |
N'utilise pas de nœuds d'infrastructure dédiés. Les composants de la plate-forme sont déployés sur les nœuds de travail. |
Utilise deux nœuds dédiés mono-AZ ou trois nœuds dédiés multi-AZ pour héberger les composants de la plate-forme. |
|
OpenShift capacités |
La surveillance de la plate-forme, le registre d'images et le contrôleur d'entrée sont déployés dans les nœuds de travail. |
La surveillance de la plate-forme, le registre d'images et le contrôleur d'entrée sont déployés dans des nœuds d'infrastructure dédiés. |
|
Améliorations de clusters |
Le plan de commande et chaque parc de machines peuvent être mis à niveau séparément. |
L'ensemble du cluster doit être mis à niveau en même temps. |
|
Amazon EC2 Encombrement minimal |
Deux Amazon EC2 instances sont nécessaires pour créer un cluster. |
Sept instances mono-AZ ou neuf Amazon EC2 instances multi-AZ sont nécessaires pour créer un cluster. |
|
Régions AWS |
Pour en Région AWS savoir plus sur la disponibilité, consultez la section Red Hat OpenShift Service on AWS Points de terminaison et quotas dans le Guide de référence AWS général. |
Pour en Région AWS savoir plus sur la disponibilité, consultez la section Red Hat OpenShift Service on AWS Points de terminaison et quotas dans le Guide de référence AWS général. |
