2.5. Infrastructure AWS provisionnée
Il s’agit d’un aperçu des composants Amazon Web Services (AWS) fournis sur un cluster Red Hat OpenShift Service sur AWS (ROSA) déployé.
2.5.1. Instances EC2 Copier lienLien copié sur presse-papiers!
Les instances AWS EC2 sont nécessaires pour déployer les fonctions de plan de contrôle et de plan de données pour Red Hat OpenShift Service sur AWS.
Les types d’instances peuvent varier pour les nœuds de plan de contrôle et d’infrastructure, en fonction du nombre de nœuds de travail.
Au minimum, les instances EC2 suivantes sont déployées:
- 3 m5.2x grands nœuds de plan de commande
- Deux nœuds d’infrastructure r5.xlarge
- Deux nœuds de travail m5.xlarge
Le type d’instance affiché pour les nœuds de travail est la valeur par défaut, mais vous pouvez personnaliser le type d’instance pour les nœuds de travail en fonction des besoins de votre charge de travail.
Afin d’obtenir de plus amples conseils sur le comptage des nœuds des travailleurs, consultez les informations sur les considérations de planification initiales dans le sujet « Limites et évolutivité » figurant dans la section « Ressources supplémentaires » de cette page.
2.5.2. Amazon Elastic Block Store stockage Copier lienLien copié sur presse-papiers!
Le stockage de blocs Amazon Elastic Block Store (Amazon EBS) est utilisé à la fois pour le stockage des nœuds locaux et le stockage en volume persistant. Les valeurs suivantes sont la taille par défaut du stockage éphémère local prévu pour chaque instance EC2.
Exigences en volume pour chaque instance EC2:
Contrôle du volume du plan
- Format: 350 Go
- Catégorie: gp3
- Entrée/sortie Opérations par seconde: 1000
Le volume de l’infrastructure
- Dimensions: 300 Go
- Catégorie: gp3
- Entrées/sorties par seconde : 900
Le volume des travailleurs
- Taille par défaut: 300 Go
- Format minimum: 128 Go
- Format minimum: 75 Go
- Catégorie: gp3
- Entrées/sorties par seconde : 900
Les clusters déployés avant la sortie d’OpenShift Container Platform 4.11 utilisent le stockage de type gp2 par défaut.
2.5.3. Équilibrage de charge élastique Copier lienLien copié sur presse-papiers!
Chaque cluster peut utiliser jusqu’à deux balanceurs de charge classiques pour le routeur d’application et jusqu’à deux balanceurs de charge réseau pour API.
Consultez la documentation ELB pour AWS.
2.5.4. Le stockage S3 Copier lienLien copié sur presse-papiers!
Le registre des images est soutenu par le stockage AWS S3. La valorisation des ressources est effectuée régulièrement afin d’optimiser l’utilisation de S3 et la performance des clusters.
Deux seaux sont nécessaires avec une taille typique de 2 To chacun.
2.5.5. LE VPC Copier lienLien copié sur presse-papiers!
Configurez votre VPC selon les exigences suivantes:
Deux sous-réseaux pour un cluster avec une seule zone de disponibilité, ou six sous-réseaux pour un cluster avec plusieurs zones de disponibilité.
Le Red Hat recommande fortement d’utiliser des sous-réseaux uniques pour chaque cluster. Le partage de sous-réseaux entre plusieurs clusters n’est pas recommandé.
NoteLe sous-réseau public se connecte directement à Internet via une passerelle Internet. Le sous-réseau privé se connecte à Internet via une passerelle de traduction d’adresse réseau (NAT).
- Les tables d’itinéraire: une table de route par sous-réseau privé, et une table supplémentaire par cluster.
- Passerelles Internet: une passerelle Internet par cluster.
- Passerelles NAT: Une passerelle NAT par sous-réseau public.
Figure 2.1. Exemple d’architecture VPC
2.5.6. Groupes de sécurité Copier lienLien copié sur presse-papiers!
Les groupes de sécurité AWS assurent la sécurité au niveau du protocole et de l’accès au port; ils sont associés aux instances EC2 et aux balanceurs de charge Elastic Load Balancing (ELB). Chaque groupe de sécurité contient un ensemble de règles qui filtrent le trafic entrant et sortant d’une ou de plusieurs instances EC2.
Assurez-vous que les ports requis pour l’installation et le fonctionnement du cluster sont ouverts sur votre réseau et configurés pour permettre l’accès entre les hôtes. Les exigences pour les groupes de sécurité par défaut sont listées dans les ports requis pour les groupes de sécurité par défaut.
Groupe de travail | Le type | Le protocole de propriété intellectuelle | Gamme de ports |
---|---|---|---|
Groupe MasterSecurity |
|
|
|
|
| ||
|
| ||
|
| ||
Groupe WorkerSecurity |
|
|
|
|
| ||
BootstrapSecurityGroup |
|
|
|
|
|
2.5.6.1. Groupes de sécurité personnalisés supplémentaires Copier lienLien copié sur presse-papiers!
Lorsque vous créez un cluster à l’aide d’un VPC existant non géré, vous pouvez ajouter des groupes de sécurité personnalisés supplémentaires lors de la création de clusters. Les groupes de sécurité personnalisés sont soumis aux limitations suivantes:
- Il faut créer les groupes de sécurité personnalisés dans AWS avant de créer le cluster. Consultez les groupes de sécurité Amazon EC2 pour les instances Linux.
- Il faut associer les groupes de sécurité personnalisés au VPC dans lequel le cluster sera installé. Les groupes de sécurité personnalisés ne peuvent pas être associés à un autre VPC.
- Il vous faudra peut-être demander un quota supplémentaire pour votre VPC si vous ajoutez des groupes de sécurité personnalisés supplémentaires. Afin d’obtenir des informations sur les exigences de quotas AWS pour ROSA, consultez les quotas de service AWS requis dans Préparez votre environnement. Afin d’obtenir des informations sur la demande d’augmentation du quota AWS, consultez Demander une augmentation de quota.