Guide sur les souscriptions des solutions Red Hat OpenShift autogérées

Introduction

Ce guide vous aidera à comprendre le modèle de souscription pour les solutions Red Hat® OpenShift® autogérées. Il fournit des instructions pas à pas afin d'estimer le nombre de licences nécessaires pour votre environnement Red Hat OpenShift. De plus amples informations sur le dimensionnement sont disponibles sur demande.

Définitions

Pour commencer, voici la définition de quelques termes importants utilisés dans le document :

• Paire de cœurs : il s'agit de l'une des unités de base pour les souscriptions OpenShift autogérées, qui correspond à 2 cœurs physiques ou à 4 processeurs virtuels (vCPU). Sur une machine bare metal, cette unité désigne toujours le cœur physique, que les technologies d'hyper-threading ou de multithreading symétrique soient activées ou non. Lorsque la technologie d'hyper-threading est activée, 2 cœurs physiques qui apparaissent comme 4 vCPU comptent comme une seule paire de cœurs. Pour les déploiements d'hyperscaler (AWS, Azure et GCP par exemple), 4 vCPU sont toujours considérés comme une seule paire de cœurs. Étant donné que les souscriptions de paires de cœurs sont comptabilisées au niveau du cluster, elles peuvent couvrir plusieurs instances de cloud, machines virtuelles et serveurs physiques.
• Paire de sockets bare metal : il s'agit d'une autre unité de base pour les souscriptions OpenShift autogérées. Au minimum, il faut une souscription de paire de sockets bare metal par serveur, laquelle prend en charge jusqu'à 128 cœurs. Une souscription de paire de sockets bare metal ne peut couvrir qu'un seul serveur ; idem pour les cœurs d'une souscription. Il est possible de cumuler plusieurs souscriptions de ce type pour couvrir un plus grand nombre de cœurs et de sockets.
• AI Accelerator : le nombre de souscriptions Red Hat AI Accelerator requis dépend du nombre de modules physiques complémentaires qui améliorent certaines fonctions de calcul en parallèle aux processeurs (CPU). Il peut notamment s'agir de processeurs graphiques (GPU), d'unités de traitement de tenseur (TPU), d'unités de traitement de données (DPU), de circuits FPGA (Field-Programmable Gate Array), de circuits ASIC (Application-Specific Integrated Circuit) et de processeurs réseau (NPU) distincts installés sous forme de modules complémentaires. Ne sont pas inclus les accélérateurs étroitement intégrés au processeur principal (par exemple, les GPU et NPU intégrés, ainsi que d'autres types d'accélérateurs). Ils peuvent être virtualisés et partagés entre plusieurs VM ou instances et ils sont dotés d'un ou de plusieurs cœurs similaires à ceux des processeurs, mais la souscription est basée sur le nombre d'appareils physiques.
• SLA : les souscriptions Red Hat requièrent un contrat de niveau de service d'assistance disponible en version Standard (assistance en journée, du lundi au vendredi) et Premium (assistance 24 h/24, 7 j/7).
• Nœud de calcul : instance (machine virtuelle ou hôte bare metal) de Red Hat Enterprise Linux® ou de Red Hat Enterprise Linux CoreOs où s'exécutent les pods des applications des utilisateurs finaux. Les environnements OpenShift peuvent comporter plusieurs nœuds de calcul, lesquels requièrent une souscription OpenShift. Les nœuds de plan de contrôle et d'infrastructure qui prennent en charge les nœuds de calcul ne nécessitent pas de souscription, mais ils peuvent entraîner des coûts associés à l'infrastructure.
• Nœud de plan de contrôle : instance (machine virtuelle ou hôte bare metal) de Red Hat Enterprise Linux CoreOs qui sert de couche d'orchestration ou de gestion de Kubernetes pour Red Hat OpenShift. Les souscriptions OpenShift autogérées incluent un droit d'utilisation des nœuds de plan de contrôle. Il n'est donc pas nécessaire de comptabiliser ces nœuds pour déterminer le nombre de souscriptions à acheter. Vous trouverez de plus amples informations dans la section sur les nœuds de plan de contrôle et d'infrastructure pour Red Hat OpenShift.
• Nœuds d'infrastructure : nœuds chargés de l'exécution des pods qui prennent en charge une infrastructure de cluster OpenShift et non les instances d'application (les nœuds qui exécutent l'équilibreur de charge basé sur HAProxy pour le trafic entrant par exemple). Les souscriptions OpenShift autogérées incluent un droit d'utilisation des nœuds d'infrastructure. Il n'est donc pas nécessaire de comptabiliser ces nœuds pour déterminer le nombre de souscriptions à acheter, tant qu'ils ne servent pas à l'exécution d'instances d'application utilisateur.
• Cluster : un cluster OpenShift Kubernetes se compose d'un nœud de plan de contrôle, de nœuds d'infrastructure facultatifs et d'un ou plusieurs nœuds de calcul.

Instance d'application : une application peut se limiter à une seule instance de pod ou être déployée sur plusieurs instances de pod qui constituent alors un service d'application. Par exemple, un service d'application hautement disponible se compose de 2 pods ou plus. Les instances d'application doivent toujours être exécutées sur des nœuds de calcul couverts par une souscription Red Hat OpenShift.

Versions de la souscription Red Hat OpenShift

Red Hat OpenShift est une plateforme cohérente pour le développement et la gestion d'applications dans les environnements de cloud hybride ouvert. Cette solution s'utilise avec les infrastructures virtuelles et physiques sur site, les clouds privés, les clouds publics et les déploiements en périphérie du réseau. La solution Red Hat OpenShift existe en deux formules : une version autogérée et des services cloud entièrement gérés. Ce guide est consacré à la version autogérée d'OpenShift.

Les solutions autogérées vous permettent d'installer, d'exploiter et de gérer les environnements Red Hat OpenShift tout en bénéficiant d'un maximum de contrôle, de flexibilité et d'options de personnalisation. Vous exploitez votre propre environnement, à commencer par l'infrastructure. Ces solutions s'utilisent sur site (sur des serveurs physiques, dans des environnements virtualisés et dans des clouds privés), ainsi que dans les clouds publics compatibles. Il vous incombe d'appliquer les mises à niveau, de gérer l'infrastructure de niveau inférieur et d'assurer le suivi des contrats de niveau de service (SLA).

Les services cloud gérés OpenShift sont entièrement gérés et exploités par Red Hat et ses partenaires de cloud public dans les principaux clouds publics. Une équipe spécialisée d'ingénierie de la fiabilité des sites (SRE) gère et assure le bon fonctionnement des services et de l'infrastructure de base de Red Hat OpenShift. Vos équipes DevSecOps peuvent ainsi se concentrer sur le développement, le déploiement et la modernisation des applications.

Vous trouverez ci-dessous les offres de services cloud OpenShift ainsi que des ressources pour en savoir plus :

• Red Hat OpenShift Dedicated : service Red Hat OpenShift entièrement géré pris en charge sur Amazon Web Services (AWS) et Google Cloud.
• Microsoft Azure Red Hat OpenShift : service Red Hat OpenShift entièrement géré par Red Hat et Microsoft, sur Microsoft Azure.
• Red Hat OpenShift Service on AWS : service Red Hat OpenShift entièrement géré par Red Hat et AWS, sur Amazon Web Services.
• Red Hat OpenShift on IBM Cloud : service Red Hat OpenShift entièrement géré par Red Hat et IBM, sur IBM Cloud.

Toutes les versions de Red Hat OpenShift offrent une expérience utilisateur cohérente pour les équipes de développement et d'exploitation dans tous les environnements. Vous pouvez ainsi transférer vos compétences et applications vers les clouds les plus adaptés.

Éléments à inclure dans le calcul des souscriptions OpenShift autogérées

Les solutions OpenShift autogérées (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine et Red Hat OpenShift Virtualization Engine) peuvent être utilisées dans tous les environnements pour lesquels une version 64 bits de Red Hat Enterprise Linux est certifiée et prise en charge. Consultez la documentation pour en savoir plus sur les méthodes de déploiement d'OpenShift et les types d'infrastructures pris en charge.

Versions logicielles OpenShift autogérées :

• Red Hat OpenShift Kubernetes Engine : moteur d'exécution Kubernetes dans le cloud hybride pour les entreprises, qui fournit les fonctionnalités essentielles de Red Hat OpenShift pour le déploiement et l'exécution d'applications que vous pouvez installer et gérer dans un datacenter, un cloud public ou un environnement d'edge computing.
• Red Hat OpenShift Container Platform : plateforme complète de cloud hybride Kubernetes pour les entreprises, conçue pour le développement, le déploiement et l'exécution d'applications que vous pouvez installer et gérer dans un datacenter, un cloud public ou un environnement d'edge computing
• Red Hat OpenShift Platform Plus : plateforme de cloud hybride qui permet aux entreprises de créer, de déployer, d'exécuter et de gérer des applications intelligentes à grande échelle dans plusieurs clusters et environnements cloud. Plusieurs couches de sécurité, de gestion et d'automatisation assurent la cohérence de la chaîne d'approvisionnement des logiciels. Les souscriptions OpenShift Platform Plus sont uniquement disponibles pour les clusters basés sur une architecture x86.
• Red Hat OpenShift Virtualization Engine : offre d'infrastructure de virtualisation bare metal reposant sur Red Hat OpenShift et l'hyperviseur Open Source KVM, spécialement conçue pour fournir aux entreprises des outils fiables et adaptés pour le déploiement, la gestion et la mise à l'échelle de machines virtuelles. Composant de l'offre OpenShift, cette version est destinée aux charges de travail de machine virtuelle. Seuls les services d'infrastructure sont pris en charge dans les conteneurs (les conteneurs d'application d'utilisateur final ne sont pas pris en charge).

Types de souscriptions

Il existe deux types de souscriptions (basées sur des paires de cœurs ou sur des paires de sockets bare metal) pour les solutions OpenShift autogérées, chacune d'entre elles présentant deux niveaux d'assistance.

Les nœuds de calcul de votre environnement nécessitent des souscriptions. Elles sont disponibles sur la base de paires de cœurs ou de paires de sockets bare metal :

1. Paire de cœurs (2 cœurs ou 4 vCPU)
   • Cette souscription est disponible pour les solutions OpenShift Kubernetes Engine, OpenShift Container Platform et OpenShift Platform Plus. Les souscriptions de paires de cœurs ne s'appliquent pas à OpenShift Virtualization Engine.
   • Lorsque vous acquérez une souscription pour des cœurs de processeur, calculez le nombre total de cœurs physiques ou de vCPU dans tous les nœuds de calculs exécutés sur les clusters OpenShift à couvrir à l'aide d'une souscription de paire de cœurs.
   • Disponible avec un contrat de niveau de service Standard (8 h/j, 5 j/7) ou Premium (24 h/24, 7 j/7).
2. Paire de sockets bare metal (1 ou 2 sockets comptant jusqu'à 128 cœurs)
   • Disponible pour toutes les versions d'OpenShift autogérées, il s'agit de la seule option de souscription pour OpenShift Virtualization Engine.
   • Cette souscription s'applique uniquement aux serveurs x86 et aux nœuds physiques bare metal ARM, lorsque la solution OpenShift a été directement installée sur le matériel. Les hyperviseurs tiers ne sont pas autorisés.
   • Il ne s'agit pas d'une souscription pour datacenter virtuel, contrairement à Red Hat Enterprise Linux for Virtual Datacenters, où une seule souscription vous permet d'installer un nombre illimité de systèmes d'exploitation de VM invités sur tous les hôtes d'hyperviseur.
   • Disponible avec un contrat de niveau de service Standard (8 h/j, 5 j/7) ou Premium (24 h/24, 7 j/7).
   • Il est possible de cumuler ces souscriptions pour les serveurs bare metal dotés de plus de 2 sockets ou de plus de 128 cœurs, mais une seule souscription ne suffit pas à couvrir plusieurs serveurs bare metal.

De plus, vous devrez acquérir des souscriptions Red Hat AI Accelerator pour les accélérateurs de votre environnement :

1. AI Accelerator (1 accélérateur)
   • Cette souscription est requise pour les cartes d'accélérateur (GPU, TPU, NPU, FPGA, DPU, etc.) qui fournissent de la puissance de calcul aux charges de travail d'IA, et qui sont des modules complémentaires distincts (ils ne font pas partie du processeur).
   • La même souscription sert pour chaque accélérateur d'IA physique, quelle que soit la version Red Hat OpenShift.
   • Une seule souscription suffit à couvrir les solutions Red Hat OpenShift et OpenShift AI lorsqu'elles sont toutes deux installées sur le cluster.
   • Cette souscription n'est pas requise tant que l'accélérateur n'est pas exploité pour renforcer la puissance de calcul (par exemple, lorsqu'un DPU est utilisé en tant que carte accélératrice de réseau SmartNIC, même s'il comporte des cœurs ARM adressables non utilisés, ou lorsque le GPU sert au rendu graphique et non à l'accélération de l'IA).
   • Disponible avec un contrat de niveau de service Standard (8 h/j, 5 j/7) ou Premium (24 h/24, 7 j/7). Le SLA doit correspondre au SLA de la souscription de paire de cœurs ou de paire de sockets bare metal sous-jacente.

Cas d'utilisation des souscriptions de paires de cœurs

Ce type de souscription est adapté au déploiement de solutions OpenShift autogérées dans le cloud public d'un hyperscaler, dans un cloud privé de type IaaS, ou à un déploiement sur un hyperviseur tel que VMware vSphere, Red Hat OpenStack® Platform ou Nutanix.

Avec une souscription de paire de cœurs, nul besoin de rattacher vos souscriptions à des serveurs physiques. Vous pouvez déployer librement des pods à travers votre cloud hybride.

Ces souscriptions s'appliquent également aux serveurs ou appareils bare metal (sans hyperviseur). Notez qu'à partir d'un certain volume de pods, la souscription de type paire de sockets bare metal peut s'avérer plus rentable.

Lorsque vous utilisez OpenShift Virtualization Engine en tant que plateforme de virtualisation dédiée, vous pouvez appliquer la souscription de paire de cœurs à des conteneurs OpenShift sur des VM, en plus de la souscription de paire de sockets bare metal pour l'hyperviseur. Il vous faudra acheter séparément des souscriptions de paires de cœurs pour la solution OpenShift autogérée et les attribuer aux machines virtuelles de l'environnement, comme vous le feriez avec une application achetée et exécutée en tant que VM. Dans ce cas d'utilisation, à partir d'un certain volume de cœurs, il peut s'avérer plus rentable de passer au modèle de paires de sockets bare metal pour une solution OpenShift autogérée, qui prévoit une quantité illimitée de conteneurs OpenShift sur le serveur bare metal, ainsi que la prise en charge de leur exécution sur les VM OpenShift.

Les souscriptions de paires de cœurs peuvent être distribuées pour couvrir tous les nœuds de calcul OpenShift dans tous les clusters OpenShift. Par exemple, 100 souscriptions Red Hat OpenShift Platform Plus de paires de cœurs couvriront 200 cœurs (400 vCPU) qui pourront être utilisés sur autant de nœuds de calcul que nécessaire, dans tous les clusters OpenShift exécutés dans vos environnements de cloud hybride.

Cas d'utilisation des souscriptions de paires de sockets bare metal

Ce type de souscription ne sert que si vous disposez de nœuds de calcul OpenShift déployés sur des serveurs physiques dédiés, que ce soit dans votre datacenter, dans un cloud privé hébergé sur un système bare metal pris en charge, ou via un hyperscaler sur un système bare metal pris en charge. Si vous disposez de la solution OpenShift Virtualization Engine, vous n'avez pas d'autre choix que d'acquérir des souscriptions de paires de sockets bare metal. Elles permettent la prise en charge de la fonction OpenShift Virtualization des autres versions OpenShift autogérées.

Chaque souscription de ce type couvre un maximum de 128 cœurs physiques dans la paire de sockets. Vous pouvez accumuler plusieurs souscriptions bare metal pour couvrir des paires de sockets comprenant plus de 128 cœurs au total et des serveurs physiques comprenant plus d'une paire de sockets.

Afin d'utiliser un serveur physique, il faut cumuler une ou plusieurs souscriptions pour couvrir soit le nombre total de sockets, soit le nombre total de cœurs physiques du serveur (le plus élevé des deux). Prenons, par exemple, un serveur qui dispose de 2 sockets et de 48 cœurs par processeur, soit un total de 96 cœurs. Résultat : une seule souscription suffit, car le serveur comprend 1 à 2 sockets et moins de 128 cœurs. Avec un deuxième serveur doté de 2 sockets, nous aurions 192 cœurs au total. Il faudrait donc deux souscriptions, car chaque souscription couvre au maximum 128 cœurs. Il n'est pas possible de partager une souscription de paire de sockets bare metal entre plusieurs hôtes physiques (pour couvrir deux serveurs dotés d'un socket chacun ou plusieurs cœurs sur différents serveurs).

Chaque serveur physique et bare metal qui utilise des souscriptions basées sur le nombre de sockets ne peut être utilisé que comme un nœud OpenShift unique en raison de l'architecture de Kubernetes. Étant donné que chaque nœud dans Kubernetes ne peut appartenir qu'à un seul cluster, tous les conteneurs sur un serveur bare metal se trouveront sur le même cluster. Cette option est adaptée aux charges de travail qui mobilisent beaucoup de ressources (dont OpenShift Virtualization, où chaque charge de travail exécute une VM complète), mais pas forcément aux autres charges. Bien que la solution OpenShift prenne en charge jusqu'à 2 500 conteneurs sur un seul nœud, il peut s'avérer nécessaire de répartir les conteneurs entre différents nœuds ou clusters pour optimiser soit les performances, soit l'architecture. Il n'est pas possible de créer plusieurs nœuds de calcul distincts sur un serveur bare metal sans recourir à la virtualisation.

Un modèle de déploiement de conteneurs courant consiste à créer un grand nombre de clusters qui contiennent moins de conteneurs. Souvent utilisé dans les environnements d'hyperscaler, ce type de déploiement peut être réalisé dans les datacenters en utilisant un hyperviseur pour créer les VM, qui deviennent les nœuds de calcul servant au déploiement des conteneurs. Pour des hyperviseurs tels que VMware vSphere, Red Hat OpenStack Platform et Nutanix, vous devez utiliser des souscriptions de paires de cœurs pour un déploiement de la solution OpenShift sur des VM.

Les clusters OpenShift Kubernetes Engine, OpenShift Container Platform et OpenShift Platform déployés sur un système bare metal et couverts par une souscription de paires de sockets incluent la fonction OpenShift Virtualization ainsi que des souscriptions pour les clusters virtuels OpenShift du même type de produit qui y est déployé. Par exemple, des clusters virtuels OpenShift déployés sur un cluster OpenShift Container Platform bare metal hériteraient des souscriptions OpenShift Container Platform du cluster bare metal hôte.

Notez que la souscription OpenShift Virtualization Engine n'inclut pas la prise en charge d'instances d'applications conteneurisées, à l'exception des charges de travail d'infrastructure définies dans la section ci-après consacrée à OpenShift Virtualization Engine. Si vous souhaitez exécuter vos propres charges de travail d'application conteneurisée à l'aide d'OpenShift Virtualization Engine, vous devez acquérir des souscriptions de paires de cœurs en version autogérée d'OpenShift pour vos VM. À partir d'un certain volume, vous pouvez acheter une souscription de paire de sockets bare metal pour les solutions OpenShift Kubernetes Engine, OpenShift Container Platform ou OpenShift Platform Plus autogérées. Vous pourrez ainsi exécuter vos applications conteneurisées de façon native sur le cluster bare metal ou hériter des souscriptions sur les clusters virtuels, comme indiqué précédemment.

Il n'est pas possible de combiner différents types de produits OpenShift dans le même cluster : tous les nœuds doivent être couverts par une souscription pour le même produit OpenShift Virtualization Engine, OpenShift Kubernetes Engine, OpenShift Container Platform ou OpenShift Platform Plus. Il est toutefois permis d'utiliser des souscriptions de paires de cœurs et de sockets dans un même cluster. Par exemple, un cluster bare metal ne peut pas comprendre à la fois des nœuds OpenShift Virtualization Engine pour héberger des VM et d'autres nœuds couverts par une souscription OpenShift Platform Plus pour héberger des applications conteneurisées et des instances virtuelles d'OpenShift.

Calcul du nombre de souscriptions AI Accelerator

Apparues sur le marché ces dernières années, des technologies matérielles permettent d'accélérer certaines charges de travail de calcul. Ces solutions matérielles sont généralement appelées « accélérateurs » ou « accélérateurs d'IA » dans certaines ressources Red Hat. Différents types de dispositifs matériels qui renforcent les capacités des serveurs modernes sont aujourd'hui proposés sous ces noms. Il s'agit notamment de GPU, de TPU, de circuits ASIC, de NPU et de circuits FPGA.

Ces accélérateurs se présentent généralement sous forme de carte, de circuit ou d'un autre appareil physique connecté à un PCI de serveur. Leur nombre correspond très souvent aux unités achetées auprès de votre fournisseur d'accélérateur. Par exemple, si ce dernier vous indique que le serveur est doté de 8 GPU, cela équivaut presque toujours à 8 unités d'accélérateur physique.

Chaque souscription d'accélérateur d'IA s'applique à un dispositif physique d'accélération. Par exemple, si l'on considère uniquement les souscriptions d'accélérateur d'IA :

• Pour un nœud de calcul physique doté de 4 GPU physiques, il faudrait 4 souscriptions d'accélérateur d'IA en plus des souscriptions de paires de cœurs et de sockets de processeur qui couvrent le nœud de calcul.
• Un nœud de calcul virtuel unique doté d'un GPU physique partagé avec les machines virtuelles en tant que vGPU multiples requiert une seule souscription d'accélérateur d'IA, étant donné que le calcul est basé sur les accélérateurs physiques, et non sur les accélérateurs virtuels.

Les accélérateurs ne sont comptabilisés que lorsqu'ils servent à exécuter une charge de travail de calcul. Une charge de travail est qualifiée de charge de travail de calcul lorsque son objectif principal n'est pas de dessiner activement des pixels sur l'écran d'un utilisateur en temps réel ou de déplacer des données sur un réseau.

Il est important de faire cette distinction, car certains effets visuels et certaines applications de streaming nécessitent l'utilisation de GPU et d'autres accélérateurs dont le but premier est, cette fois, de dessiner des pixels sur un écran. Dans certains cas, leur fonction première est de déplacer des données sur un réseau (c'est le cas des unités de traitement de données consacrées à des fonctions du réseau). Là encore, il ne s'agit pas d'une charge de travail de calcul.

Voici quelques exemples de charges de travail de calcul

• Applications logicielles traditionnelles telles que Java, Python et Perl
• Grands modèles de langage ou autres logiciels demandant une grande puissance de calcul
• Entraînement et ajustement de modèles de science des données
• Modélisation scientifique et simulation physique telles que le repliement des protéines et la dynamique des fluides

Éléments à exclure du calcul

Nœuds de plan de contrôle et d'infrastructure Red Hat OpenShift

Chaque souscription pour les solutions OpenShift autogérées vous donne le droit d'utiliser Red Hat OpenShift ainsi que d'autres composants liés à OpenShift. Les offres OpenShift Kubernetes Engine, OpenShift Container Platform et OpenShift Platform Plus permettent d'utiliser Red Hat Enterprise Linux pour les nœuds de calcul et d'infrastructure. Red Hat OpenShift Virtualization Engine ne prend pas en charge les nœuds de calcul ou d'infrastructure Red Hat Enterprise Linux standard. Seul le système d'exploitation Red Hat Enterprise Linux CoreOS faisant partie de l'offre OpenShift est pris en charge.

Ces droits d'utilisation permettent d'exécuter le plan de contrôle et l'infrastructure OpenShift nécessaires, mais vous ne devez pas les ajouter au calcul du nombre de souscriptions Red Hat requis.

Les souscriptions Red Hat OpenShift Platform Plus incluent également la gestion de l'ensemble des nœuds par Red Hat Advanced Cluster Security for Kubernetes et Red Hat Advanced Cluster Management for Kubernetes.

L'installation par défaut déploie un plan de contrôle OpenShift hautement disponible composé de trois nœuds de plan de contrôle, en complément d'un minimum de deux nœuds de calcul OpenShift pour exécuter les applications des utilisateurs finaux. Par défaut, les composants du plan de contrôle Kubernetes (serveur d'API, etcd, planificateur, etc.) et les services de cluster sous-jacents (par exemple la surveillance ou le registre) seront déployés sur les nœuds de plan de contrôle OpenShift. Vous pouvez toutefois déplacer certains de ces services de cluster vers des nœuds d'infrastructure spécialisés.

Pour être considérée comme un nœud d'infrastructure et bénéficier des droits d'utilisation associés, une instance doit exécuter uniquement des composants qui permettent le fonctionnement du cluster, et donc aucun composant qui appartient à l'application d'un utilisateur final. Exemples :

• Registre OpenShift
• Routeur Ingress OpenShift (entrée réseau locale, globale et multicluster)
• OpenShift Observability
• Instances basées sur HAProxy utilisées pour les entrées de cluster
• 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
• Plans de contrôle hébergés pour Red Hat OpenShift

Vous pouvez déployer et exécuter des agents et outils tiers et personnalisés pour la surveillance, la collecte et la transmission de données de journal, la gestion de pilotes matériels ou encore l'intégration de l'infrastructure, notamment des agents de virtualisation, sur des nœuds d'infrastructure, sans pour autant exclure ces nœuds de la licence d'infrastructure. Toutefois, ne sont concernés que les agents et les composants connexes, notamment les pods de contrôleurs pour les opérateurs. Les suites logicielles tierces et personnalisées sont exclues. Exemples de logiciels tiers qui entrent dans les charges de travail d'infrastructure :

• Agents de surveillance tiers et personnalisés
• Pilotes et contrôleurs (plug-ins) d'interfaces CNI (Container Network Interface) et CSI (Container Storage Interface)
• Accélérateurs de systèmes virtuels ou matériels
• Pods de contrôleurs utilisés pour les définitions de ressources personnalisées ou les opérateurs Kubernetes (logiciels tiers ou personnalisés)

Aucune autre instance ni aucun autre type d'application d'utilisateur final ne peuvent être exécutés sur un nœud d'infrastructure avec le droit d'utilisation inclus. Pour exécuter d'autres charges de travail d'infrastructure en tant qu'instances d'applications sur Red Hat OpenShift, vous devez exécuter ces instances sur des nœuds d'application ordinaires couverts par une souscription Red Hat OpenShift valide. Vous pouvez demander à Red Hat si une application ou un service entre dans les charges de travail d'infrastructure.

Droits d'utilisation associés à Red Hat Enterprise Linux

Les offres OpenShift Kubernetes Engine, OpenShift Container Platform et OpenShift Platform Plus permettent d'utiliser Red Hat Enterprise Linux sur les nœuds de calcul et d'infrastructure OpenShift. Ces droits d'utilisation s'étendent également aux pods pour les applications et aux systèmes d'exploitation invités sur les VM. Les souscriptions Red Hat OpenShift ne couvrent cependant aucun autre nœud Red Hat Enterprise Linux, à une exception près :

• Un nœud Red Hat Enterprise Linux spécialement utilisé pour le provisionnement d'une infrastructure IPI (Installer-Provisioned Infrastructure) bare metal

OpenShift Virtualization Engine n'inclut pas Red Hat Enterprise Linux, ni pour les nœuds de calcul et d'infrastructure, ni pour les SE invités sur les VM. Les invités Red Hat Enterprise Linux sur OpenShift Virtualization Engine requièrent une souscription Red Hat Enterprise Linux for Virtual Datacenters ou des souscriptions par VM.

Les droits d'utilisation de Red Hat Enterprise Linux ne sont pas inclus pour des nœuds externes qui hébergent les services essentiels à OpenShift, comme les proxys Internet, les équilibreurs de charge ou le registre miroir. La souscription ne donne pas non plus accès à Red Hat Satellite.

Registre de conteneurs bootstrap pour la mise en miroir des images de conteneurs OpenShift

Le registre miroir d'OpenShift, issu de Quay, facilite la mise en miroir du contenu nécessaire pour le démarrage des clusters OpenShift déconnectés. Il est inclus dans la souscription Red Hat OpenShift. Il s'agit d'une prise en charge limitée d'un déploiement Quay réduit, créé via un programme d'installation spécifique qui vous permet d'exécuter un registre Quay sur un hôte Red Hat Enterprise Linux préprovisionné, que vous gérez vous-même.

Remarque : l'utilisation de Quay en tant que registre miroir est limitée à la mise en miroir des composants et fichiers (ou « payload ») associés à une version d'OpenShift, du contenu OperatorHub, des échantillons d'images d'opérateurs, des images de graphique Cincinnati d'OpenShift et des images liées aux offres Red Hat OpenStack Platform, dont Red Hat OpenStack Services on OpenShift et Red Hat OpenShift Data Foundation.

Le registre miroir d'OpenShift ne doit pas servir de registre générique à grande échelle. Vous pouvez cependant y stocker un nombre limité d'images personnalisées qui contiennent des agents logiciels auxiliaires nécessaires, par exemple des agents et des images de conteneur pour les charges de travail d'infrastructure remplissant les conditions requises. Voici quelques exemples :

• Agents de surveillance
• Fournisseurs CNI et CSI
• Agents d'activation de la virtualisation ou du matériel
• Opérateurs prenant en charge les services des éditeurs de logiciels indépendants (ISV)
• Opérateurs personnalisés utilisés comme contrôleurs de déploiement

Plans de contrôle hébergés

L'infrastructure OpenShift classique requiert au moins trois nœuds de plan de contrôle pour chaque cluster OpenShift. Il est toutefois possible d'utiliser des plans de contrôle hébergés exécutés sur un cluster centralisé qui fournit un plan de contrôle logique aux clusters OpenShift. Comme toujours, les nœuds de plan de contrôle et d'infrastructure ne sont pas pris en compte dans le calcul des souscriptions, mais ils le sont pour l'architecture.

Les plans de contrôle hébergés peuvent être exécutés sur tous types de clusters OpenShift bare metal, mais les nœuds de calcul de ces clusters devront être couverts par une souscription correspondant à l'infrastructure sur laquelle ils sont exécutés. Par exemple, il faut des souscriptions de paires de cœurs pour les nœuds de calcul des clusters virtuels hébergés sur OpenShift Virtualization Engine, alors qu'un cluster dont le plan de contrôle est hébergé dans un cluster OpenShift Virtualization Engine et qui utilise des nœuds de calcul bare metal nécessite des souscriptions de paires de sockets bare metal.

Exception 1 : exécution d'instances d'applications sur des nœuds de plan de contrôle ou d'infrastructure

Les nœuds de plan de contrôle OpenShift ne sont pas utilisés comme nœuds de calcul par défaut, ils n'exécutent donc pas d'instances d'applications. Pour savoir si un nœud de plan de contrôle nécessite une souscription Red Hat OpenShift complète, il faut déterminer s'il exécute uniquement des composants de cluster OpenShift ou aussi des applications d'utilisateurs finaux. Tout nœud de plan de contrôle qui héberge des d'applications d'utilisateurs finaux doit être assorti d'une souscription pour tous les cœurs. Pour identifier les charges de travail qui se passent de souscription, consultez la section sur les nœuds d'infrastructure.

Exception 2 : déploiements de clusters compacts

Dans les clusters compacts de type OpenShift à trois nœuds, les charges de travail des applications d'utilisateurs finaux sont exécutées sur les nœuds de plan de contrôle. Les cœurs des trois nœuds sont à comptabiliser pour les souscriptions Red Hat OpenShift, quel que soit leur rôle.

Une instance OpenShift à un seul nœud déploie tous les services et applications OpenShift des utilisateurs finaux dans un seul nœud, physique ou virtuel, tout en appliquant des réglages qui réduisent l'empreinte et optimisent les ressources. Comme pour les clusters compacts à trois nœuds, ce modèle de déploiement ne dispose d'aucun aménagement spécial : il faut couvrir tous les cœurs.

Cas d'utilisation particuliers

Récupération après sinistre

Red Hat a défini trois types d'environnements de récupération après sinistre : à chaud, intermédiaire et à froid. Seule la récupération après sinistre à chaud nécessite une souscription Red Hat OpenShift payante.

• Les systèmes de récupération après sinistre à chaud sont entièrement fonctionnels et s'exécutent en parallèle des systèmes de production. Ils sont prêts à capter immédiatement le trafic et à prendre le relais en cas de sinistre dans l'environnement principal. Lorsque les volumes de données sont activement répliqués de manière synchrone ou asynchrone entre les clusters, ils sont considérés comme des systèmes de récupération après sinistre à chaud.
• Les systèmes de récupération après sinistre intermédiaire sont préparés au déploiement et à l'hébergement de charges de travail conteneurisées qui constituent une copie raisonnable de celles présentes sur le site principal, mais qui ne contiennent aucune charge de travail client issue des clusters sources. Ces systèmes ne doivent pas participer à la réplication active des volumes de données entre les clusters, qu'elle soit synchrone ou asynchrone. Dans le cadre de la récupération après sinistre intermédiaire, les données du client sont restaurées sur le matériel du cluster existant depuis l'extérieur du cluster.
• Les systèmes de récupération après sinistre à froid disposent déjà de l'infrastructure, mais pas de toutes les technologies (matériel, logiciels, données) nécessaires pour rétablir le bon fonctionnement du service.

Les clusters en hibernation qui n'ont pas été expressément prévus pour une récupération après sinistre intermédiaire ou à froid nécessitent des souscriptions, c'est notamment le cas des clusters placés en hibernation temporaire sur des services cloud en raison d'une faible demande. Des souscriptions s'imposent également pour les clusters de récupération après sinistre intermédiaire ou à froid qui sortent de leur hibernation pour des charges de travail en cours d'exécution. En revanche, si ces clusters sortent de leur hibernation temporairement pour des questions de maintenance ou de tests, aucun des composants des solutions logicielles OpenShift ne nécessite de souscription supplémentaire.

Dans le cas des récupérations après sinistre intermédiaires et à froid, les souscriptions Red Hat OpenShift peuvent être transférées depuis l'environnement principal vers l'environnement de récupération après sinistre au moment du sinistre, afin de rétablir le fonctionnement du service et de préserver la conformité aux conditions de souscription de Red Hat.

Migration et mises à niveau transitoires

Avec Red Hat OpenShift 4, il est possible d'effectuer des mises à niveau sur place entre les versions mineures. Si vous devez toutefois effectuer une mise à niveau depuis Red Hat OpenShift 3 ou faire une mise à niveau transitoire entre des versions mineures de Red Hat OpenShift 4 pour respecter les créneaux de maintenance ou pour d'autres motifs, sachez que la souscription Red Hat OpenShift couvre l'infrastructure d'origine et de destination d'une migration unilatérale jusqu'à la fin de l'opération. Pendant la migration, les outils de gestion des souscriptions de Red Hat indiqueront que votre environnement ne respecte pas le nombre de souscriptions Red Hat OpenShift achetées. Red Hat accorde une exception pour les mises à niveau de versions majeures et n'exige pas l'achat de nouvelles souscriptions pour rétablir la conformité pendant la migration. Enfin, Red Hat OpenShift fournit des outils qui facilitent ces migrations, en parallèle des services de consulting Red Hat. Consultez la documentation sur la boîte à outils de migration pour les conteneurs.

Droits d'utilisation pour les cœurs lorsque la technologie d'hyper-threading est activée

Actuellement, pour déterminer si un nœud OpenShift donné est doté d'un ou de plusieurs cœurs physiques, il faut savoir si le système permet l'utilisation de plusieurs threads par cœur. Cliquez ici pour apprendre à déterminer si un système est compatible avec l'hyper-threading.

En ce qui concerne les nœuds virtualisés OpenShift qui utilisent des threads de processeur logique (multithreading simultané pour les processeurs EPYC AMD ou hyper-threading pour les processeurs Intel), calculez le nombre de souscriptions Red Hat OpenShift en fonction du nombre de cœurs/processeurs attribués au nœud. Notez toutefois que chaque souscription couvre 4 vCPU/cœurs lorsque des threads de processeur logique sont utilisés. Les outils de gestion des souscriptions Red Hat partent du principe que des threads logiques de processeur sont activés par défaut sur tous les systèmes.

Puisque les souscriptions bare metal ne comptabilisent que les cœurs physiques, les threads logiques de processeur ne sont pas pris en compte dans le calcul du nombre de souscriptions nécessaires pour les systèmes bare metal.

Autres architectures (ARM, IBM Z, IBM LinuxONE, IBM Power)

Remarque : bien qu'à partir de cette section, il ne soit fait référence qu'à l'architecture IBM Z, toutes les informations s'appliquent également à l'architecture IBM LinuxONE.

La solution Red Hat OpenShift Container Platform peut également être exécutée sur les systèmes ARM, IBM Z et IBM Power pour les clients qui utilisent ces plateformes comme système standard pour la création et le déploiement d'applications cloud-native et de microservices. Seul le modèle de souscription basé sur les cœurs s'applique aux plateformes IBM Z et IBM Power.

Les clusters ARM sont couverts selon les mêmes règles que les serveurs x86.

Pour les clients IBM Z, seuls les cœurs utilisés par Red Hat OpenShift doivent être couverts, pas le nœud physique tout entier. Ce modèle propre aux systèmes IBM Z est appelé « capacité partielle ». Les clients qui n'utilisent qu'un sous-ensemble des cœurs disponibles (capacité de calcul) dans leur environnement IBM Z pour OpenShift Container Platform doivent acheter des souscriptions uniquement pour le sous-ensemble utilisé pour les nœuds de calcul. Ce modèle s'applique indépendamment de la manière dont le partitionnement des processeurs est réalisé, que ce soit par la mise en commun de processeurs, la limitation, les partitions logiques (LPAR) distinctes ou par d'autres moyens.

Pour IBM Z, il faut une souscription OpenShift de paire de cœurs par processeur IFL (Integrated Facility for Linux). En l'absence de partitionnement, le plan de contrôle ou les services d'infrastructure qui s'exécutent sur l'hôte peuvent compter jusqu'à trois processeurs IFL par cluster OpenShift. Ceux-ci ne nécessitent pas de souscription OpenShift à condition qu'ils soient activement utilisés pour le plan de contrôle ou les services d'infrastructure. Dans le cas d'un déploiement de cluster compact à trois nœuds, l'ensemble des processeurs IFL doit être couvert par une souscription.

À l'heure actuelle, les composants de Red Hat OpenShift Platform Plus, à l'exception d'OpenShift Container Platform, ne sont pas pris en charge sur les systèmes IBM Z et IBM Power, sauf dans les cas suivants :

• Une souscription autonome de Red Hat Quay exécutée sur des architectures x86 fournit un registre global pour plusieurs architectures, y compris des clusters IBM Z et IBM Power. La solution Red Hat Quay elle-même ne s'exécutera pas sur des systèmes IBM Z ou IBM Power.
• La solution Red Hat Advanced Cluster Management for Kubernetes peut être installée dans des environnements IBM Z ou IBM Power afin de gérer les nœuds Red Hat OpenShift qui s'y exécutent.
• Avec Red Hat Advanced Cluster Security for Kubernetes, vous pouvez protéger les clusters exécutés sur Red Hat OpenShift sur des systèmes IBM Z ou IBM Power à l'aide de l'opérateur Red Hat Advanced Cluster Security.
• Red Hat OpenShift Data Foundation est entièrement compatible avec les systèmes IBM Z ou IBM Power.

Les composants de la souscription Red Hat OpenShift Platform Plus présentent différents niveaux de prise en charge des architectures autres que x86. Vous pouvez consulter l'article présentant la matrice de compatibilité des composants de la version 4.16 de Red Hat OpenShift Container Platform avec différentes architectures. Pour en savoir plus sur l'interopérabilité entre les composants d'OpenShift Platform Plus et les architectures autres que x86, consultez les matrices de compatibilité pour Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay et Red Hat OpenShift Data Foundation.

Les offres Red Hat OpenShift Kubernetes Engine et Red Hat OpenShift Virtualization Engine ne sont pas prises en charge par IBM Z et IBM Power.

Prise en charge des conteneurs Microsoft Windows Server

Grâce aux conteneurs Microsoft Windows Server, la solution OpenShift autogérée prend en charge un sous-ensemble d'infrastructures d'installations et de fonctions OpenShift. Ces conteneurs sont uniquement compatibles avec les nœuds de calcul basés sur Microsoft Windows Server. Les plans de contrôle et d'infrastructure de l'environnement OpenShift doivent être exécutés sur une infrastructure x86 dotée de Red Hat Enterprise Linux ou Red Hat Enterprise Linux CoreOs. C'est pourquoi la prise en charge des conteneurs Windows Server est vendue sous la forme d'une souscription autonome facturée par cœur.

Il est possible d'utiliser les infrastructures Red Hat OpenShift Platform Plus et Red Hat OpenShift Container Platform pour déployer et gérer les nœuds de calcul Windows Server. La prise en charge des conteneurs Microsoft Windows Server est disponible sous forme de module complémentaire distinct à acheter dans le cadre d'une souscription Red Hat OpenShift.

Les solutions Red Hat Advanced Cluster Management et Red Hat Advanced Cluster Security ne permettent pas la gestion des nœuds Microsoft Windows. Cependant, la solution Red Hat Quay exécutée sur des architectures x86 permet de gérer les images de conteneurs relatives aux charges de travail basées sur Microsoft Windows Server.

Des consignes à adapter à vos besoins

Red Hat OpenShift prend en charge de nombreuses fonctions et capacités qui ont une influence sur les fonctions d'évolutivité, de planification des pods, d'inactivité et de quota/limitation des ressources. Les calculs ci-dessus sont purement indicatifs. Vous pourrez peut-être adapter votre environnement réel pour optimiser l'utilisation des ressources ou réduire sa taille totale. Les clients OpenShift Platform Plus doivent prendre en compte les besoins des applications logicielles complémentaires (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security et Quay), notamment les ressources de stockage et de calcul, même si elles ne nécessitent pas de souscriptions supplémentaires pour des nœuds de calcul.

Si vous travaillez avec un revendeur tiers, consultez ses conditions et accords spécifiques relatifs aux produits et services Red Hat.

Prise en charge des composants de Red Hat OpenShift Platform Plus

Outre les fonctions de base d'OpenShift Container Platform, Red Hat OpenShift Platform Plus comprend des logiciels supplémentaires qui vous aident à gérer et sécuriser votre environnement OpenShift à grande échelle dans plusieurs clusters et plusieurs clouds. Les souscriptions Red Hat OpenShift Platform Plus se déclinent en deux versions : basée sur les cœurs et basée sur les sockets bare metal, avec les limites mentionnées ci-dessus.

Les logiciels supplémentaires inclus avec Red Hat OpenShift Platform Plus se limitent généralement à la gestion des nœuds couverts par les souscriptions OpenShift Platform Plus. Par exemple, la souscription Red Hat Advanced Cluster Management incluse avec OpenShift Platform Plus ne peut servir qu'à gérer les nœuds et clusters couverts par une licence OpenShift Platform Plus. Les clients qui souhaitent également gérer d'autres nœuds et clusters, par exemple des clusters Red Hat OpenShift Services on AWS, devront acheter des souscriptions supplémentaires pour Red Hat Advanced Cluster Management.

Ces souscriptions logicielles supplémentaires sont indissociables de la souscription OpenShift Platform Plus. Par exemple, vous ne pouvez pas acheter 100 souscriptions OpenShift Platform Plus, installer 200 cœurs Red Hat OpenShift Container Platform et utiliser séparément Red Hat Advanced Cluster Management pour gérer 200 cœurs Azure Red Hat OpenShift avec cette même souscription. Les logiciels supplémentaires peuvent uniquement être utilisés pour gérer les 200 cœurs sur lesquels le logiciel OpenShift Platform Plus de base est installé.

Voici les règles spécifiques pour chaque produit à couches :

• Red Hat Advanced Cluster Management for Kubernetes : une souscription OpenShift Platform Plus vous permet d'installer autant d'instances centrales de Red Hat Advanced Cluster Management que nécessaire pour gérer votre environnement, et permet la gestion de tous les nœuds et clusters couverts par OpenShift Platform Plus, y compris les nœuds de plan de contrôle et d'infrastructure. Si vous souhaitez gérer des nœuds et des clusters non couverts, vous devez acheter des souscriptions pour le module complémentaire Red Hat Advanced Cluster Management. C'est notamment le cas pour les clusters OpenShift Container Platform ou Red Hat OpenShift Kubernetes Engine autogérés, les clusters exécutés dans un cloud OpenShift entièrement géré et les environnements Kubernetes tiers pris en charge par Red Hat Advanced Cluster Management. Vous pouvez opter pour une gestion centralisée à partir de la console Red Hat Advanced Cluster Management installée sur OpenShift Platform Plus, ou à partir d'une application centrale distincte, selon vos exigences. Découvrez les meilleures pratiques relatives à la solution Red Hat Advanced Cluster Management, ses souscriptions et ses environnements pris en charge.
• Red Hat Advanced Cluster Security for Kubernetes : une souscription OpenShift Platform Plus vous permet d'installer autant d'applications centrales de Red Hat Advanced Cluster Security que nécessaire pour gérer votre environnement, et permet la gestion de tous les nœuds et clusters couverts par OpenShift Platform Plus, y compris les nœuds de plan de contrôle et d'infrastructure. Si vous souhaitez gérer des nœuds et des clusters non couverts, vous devez acheter des souscriptions pour le module complémentaire Red Hat Advanced Cluster Security. C'est notamment le cas pour les clusters OpenShift Container Platform ou OpenShift Kubernetes Engine autogérés, les clusters exécutés dans un cloud Red Hat OpenShift entièrement géré et les environnements Kubernetes tiers pris en charge par Red Hat Advanced Cluster Security. Nous vous recommandons de gérer chaque environnement à l'aide d'une application Red Hat Advanced Cluster Security centrale distincte. Découvrez les environnements Red Hat Advanced Cluster Security pris en charge.
• Red Hat Quay : une souscription OpenShift Platform Plus vous permet d'installer Red Hat Quay dans tous les clusters où s'exécute OpenShift Platform Plus. Vous pouvez installer autant de déploiements Quay que vous le souhaitez dans vos clusters OpenShift Platform Plus. La solution Quay peut ensuite être utilisée dans tous les environnements Kubernetes pris en charge, y compris l'environnement OpenShift Platform Plus, d'autres clusters OpenShift autogérés, des services OpenShift gérés et des environnements Kubernetes tiers compatibles. Si vous souhaitez installer Quay dans un environnement différent d'OpenShift Platform Plus, vous devrez acheter une souscription Red Hat Quay distincte. Red Hat Quay est également disponible sous la forme d'une offre SaaS entièrement gérée.
• Red Hat OpenShift Data Foundation : une souscription OpenShift Platform Plus vous permet d'installer Red Hat OpenShift Data Foundation Essentials sur tous les clusters où s'exécute OpenShift Platform Plus. L'accès est limité aux fonctions disponibles dans la version Essentials, et la capacité de stockage à 256 To par cluster OpenShift. Vous pouvez ajouter des souscriptions pour étendre la fonctionnalité et la capacité. Pour en savoir plus, consultez le guide sur les souscriptions OpenShift Data Foundation (connexion requise au portail client) ou contactez un représentant Red Hat.

Red Hat OpenShift Virtualization Engine et produits associés

OpenShift Virtualization est une fonction incluse depuis longtemps dans toutes les versions autogérées d'OpenShift. Elle permet d'inclure des charges de travail de VM dans des applications cloud-native et de migrer les machines virtuelles vers des microservices et des conteneurs pour les moderniser.

Suite aux changements récents sur le marché de la virtualisation, les utilisateurs recherchent de nouvelles plateformes de virtualisation et se concentrent sur celles qui leur donnent les moyens de moderniser leur environnement. Nombre d'entre eux n'ont pas besoin de toutes les fonctionnalités d'OpenShift pour effectuer leurs premières migrations de VM. Il existe une version simplifiée et moins coûteuse de la solution OpenShift autogérée pour ces cas d'utilisation.

Red Hat OpenShift Virtualization Engine est une version autogérée d'OpenShift destinée aux clients qui cherchent une autre solution de plateforme de virtualisation pour exécuter leurs VM. Elle est couverte par les souscriptions de paires de sockets bare metal sur les serveurs physiques et les instances bare metal des hyperscalers pris en charge.

OpenShift Virtualization Engine inclut uniquement les fonctions de déploiement, de gestion et d'exécution de machines virtuelles et présente les caractéristiques suivantes :

• Nombre illimité de VM sur les hôtes avec souscription
• Non valide pour exécuter des instances d'application (logiciels commerciaux ou applications client) sur des conteneurs (uniquement sur des VM)
• N'inclut pas de souscriptions pour l'exécution de versions Red Hat OpenShift au sein de VM (nécessite l'achat de souscriptions de paires de cœurs)
• N'inclut pas de droits d'utilisation d'instances invitées de Red Hat Enterprise Linux pour les VM (nécessite l'achat de la solution Red Hat Enterprise Linux for Virtual Datacenters ou d'une souscription basée sur le nombre de VM)

Nous proposons désormais deux modules complémentaires pour OpenShift Virtualization Engine.

• Red Hat Advanced Cluster Management for Virtualization aide à la gestion et à l'exploitation du cycle de vie de la virtualisation et des hyperviseurs à moindre coût par rapport à la version complète de la solution (une souscription par souscription OpenShift Virtualization Engine).
• Red Hat Ansible® Application Platform for Virtualization prend en charge le nœud d'hyperviseur qui exécute OpenShift Virtualization Engine pour les opérations de migration et de déploiement (une souscription par souscription OpenShift Virtualization Engine).

Les utilisateurs des solutions Advanced Cluster Management et Ansible Application Platform peuvent utiliser l'installation existante de ces applications centrales en tant que base pour leur environnement ainsi que pour gérer les hôtes OpenShift Virtualization Engine en achetant des souscriptions pour les modules complémentaires.

Concernant les clients qui ne disposent pas des applications centrales d'Advanced Cluster Management et d'Ansible Application Platform, la souscription pour les modules mentionnés inclut également une aide pour l'installation de ces applications en tant que conteneurs d'infrastructure sur leurs hôtes OpenShift Virtualization Engine. Consultez la documentation sur Advanced Cluster Management et Ansible Application Platform pour en savoir plus sur l'installation de ces applications et découvrir les meilleures pratiques relatives à l'architecture.

Nous conseillons la solution Ansible Automation Platform aux clients qui souhaitent automatiser les tâches de maintenance de leurs machines virtuelles. En plus des souscriptions de nœud d'hyperviseur citées ci-dessus, les clients doivent acquérir une souscription de nœud pour chaque instance de VM. Consultez la documentation relative à Ansible Automation Platform pour en savoir plus.

Même si l'offre OpenShift Virtualization Engine n'autorise l'exécution des applications client que sous la forme de VM, de nombreux éléments de l'infrastructure, notamment les pilotes de stockage, les applications de sauvegarde, les agents de transfert, Advanced Cluster Management et Ansible Automation Platform, sont exécutés en tant que conteneurs d'infrastructure dans la solution Red Hat OpenShift. Cette offre vous permet donc d'exécuter ces fonctions d'infrastructure dans des conteneurs. Idem pour les solutions de stockage logiciel conteneurisées qui fournissent des capacités de stockage aux VM. Les conditions de couverture de ces conteneurs d'infrastructure sont identiques à celles des charges de travail exécutées sur les nœuds d'infrastructure pour d'autres versions de Red Hat OpenShift. Consultez les informations concernant les nœuds d'infrastructure dans la section « Éléments à exclure ». Vous pouvez demander à votre représentant Red Hat si une application ou un service entre dans les charges de travail d'infrastructure pour OpenShift Virtualization Engine.

Dimensionner un environnement OpenShift autogéré

Pour déterminer le nombre de souscriptions pour les solutions OpenShift autogérées (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform ou Red Hat OpenShift Kubernetes Engine) ou pour les modules complémentaires dont vous avez besoin, référez-vous aux questions et aux exemples de réponses proposés plus bas.

En résumé :

• Les applications sont regroupées dans des images de conteneur ou des VM.
• Les conteneurs et les VM sont déployés sous forme de pods.
• Les pods s'exécutent sur des nœuds de calcul OpenShift gérés par les nœuds de plan de contrôle OpenShift.

Estimation des besoins en souscription

Les souscriptions Red Hat OpenShift ne limitent pas le nombre d'instances d'applications dans l'environnement OpenShift. Il est possible d'en exécuter autant que le matériel et l'infrastructure sous-jacents le permettent. Avec du matériel de grande capacité, vous pouvez exécuter de nombreuses instances sur un petit nombre d'hôtes, tandis qu'avec du matériel de plus petite capacité, vous aurez besoin de davantage d'hôtes pour un gros volume d'instances. Le principal facteur à prendre en compte pour déterminer la taille d'un environnement Red Hat OpenShift est le nombre de pods, ou instances d'applications, susceptibles de s'exécuter en même temps.

Étape 1 : identifier le nombre et le type d'instance d'application requis

Commencez par les applications. Déterminez le nombre d'instances d'applications, ou pods, que vous comptez déployer. Lors du dimensionnement de l'environnement, tout composant d'application déployé sur Red Hat OpenShift (base de données, serveur statique front-end, instance de machine virtuelle, etc.) est considéré comme une instance d'application.

Le résultat obtenu permet de calculer la taille approximative de votre environnement Red Hat OpenShift. Pour affiner cette estimation, tenez également compte des données liées au processeur, à la sursouscription de la mémoire, aux quotas et limites, ainsi qu'à d'autres fonctions.

Tableau 1 : questions relatives au dimensionnement des applications et instances

Exemple 1 : application conteneurisée exécutée dans un cloud d'hyperscaler

Prenez une application comprenant 200 instances de conteneurs dont chacune utilise 1 vCPU et 4 Go de RAM en moyenne. Le seuil d'utilisation maximal souhaité est de 80 %. Vous exécutez l'application sur AWS et avez accès aux types d'instances EC2 M6i. L'application ne nécessite pas de matériel particulier ni d'accélérateur d'IA. Vous avez choisi Red Hat OpenShift Platform Plus en version autogérée et vous devez estimer le nombre de souscriptions nécessaires.

Étape 1 : identifier le nombre et le type d'instance d'application requis

D'après les informations tirées de notre exemple :

• Nombre d'instances de l'application = 200
• Seuil d'utilisation maximal des nœuds = 80 %
• Besoin moyen en vCPU de l'application = 1 vCPU
• Taille moyenne de la mémoire de l'application 4 Go

Étape 2 : déterminer la quantité totale de mémoire et de cœurs requise

En injectant les chiffres de l'étape 1 dans les calculs :

• Utilisation maximale = 80 %
• Nombre total de vCPU requis = 1 vCPU x 200 x 1/80 % = 250 vCPU
• Mémoire totale requise = 4 Go x 200 x 1/80 % = 1 000 Go

Étape 3 : choisir un nœud de calcul standard

D'après les informations à disposition, vous n'avez pas besoin d'une instance dotée d'un GPU ou de matériel spécifique. Le rapport entre les vCPU et la mémoire est de 250 vCPU:1 000 Go, ou 1:4. Il existe de nombreux types d'instances pour ce ratio. Après avoir analysé les autres facteurs spécifiques à votre application, vous avez déterminé que le type d'instance m6i.4xlarge était le plus adapté à vos besoins. Chaque instance dispose de 16 vCPU et de 64 Go de mémoire.

Étape 4 : calculer le nombre total de souscriptions requis

Dans cet exemple, vous avez besoin de souscriptions de paires de cœurs, car votre application est exécutée dans un cloud d'hyperscaler qui utilise des vCPU. Vous choisissez donc la formule « paire de cœurs » de l'étape 2.

Nombre total de souscriptions de paires de cœurs = Nombre total de vCPU requis / 4, arrondi

250 vCPU / 4 = 62,5, arrondi à 63

Étape 5 : calculer le nombre total de souscriptions AI Accelerator (le cas échéant)

Cette étape ne s'applique pas à cet exemple, car vous n'utilisez pas d'accélérateur d'IA.

Résultat

Dans ce premier exemple, il vous faudrait 63 souscriptions OpenShift Platform Plus de type « paire de cœurs ».

Exemple 2 : application conteneurisée exécutée dans un environnement bare metal sur site

Vous souhaitez maintenant déployer cette même application sous la forme de machines virtuelles sur des serveurs bare-metal sur site, à l'aide de la fonction OpenShift Virtualization de Red Hat OpenShift. L'application comprend 200 instances de conteneurs dont chacune utilise 1 vCPU et 4 Go de RAM. Le seuil d'utilisation maximal souhaité est de 80 %. L'application ne nécessite pas de matériel particulier ni d'accélérateur d'IA. Vous avez choisi Red Hat OpenShift Platform Plus en version autogérée et vous devez estimer le nombre de souscriptions nécessaires. Vous avez le choix pour la configuration des serveurs bare metal, mais vous optez pour des configurations standard.

Étape 1 : identifier le nombre et le type d'instance d'application requis

D'après les informations tirées de notre exemple :

• Nombre d'instances de l'application = 200
• Seuil d'utilisation maximal des nœuds = 80 %
• Besoin moyen en vCPU de l'application = 1 vCPU
• Taille moyenne de la mémoire de l'application 4 Go

Étape 2 : déterminer la quantité totale de mémoire et de cœurs requise

En injectant les chiffres de l'étape 1 dans les calculs :

• Utilisation maximale = 80 %
• Nombre total de vCPU requis = 1 vCPU x 200 x 1/80 % = 250 vCPU
• Mémoire totale requise = 4 Go x 200 x 1/80 % = 1 000 Go

Étape 3 : choisir un nœud de calcul standard

Votre serveur bare metal actuel possède 2 sockets avec 32 cœurs et 64 vCPU par socket. Vous pouvez choisir la taille de la mémoire RAM. Puisque le ratio entre les vCPU et la RAM est de 1:4, vous équipez vos serveurs de 256 Go de RAM. Au final, vous choisissez un serveur bare metal avec 2 sockets, 32 cœurs, 64 vCPU par socket (64 cœurs, 128 vCPU par serveur) et 256 Go de RAM.

Étape 4 : calculer le nombre total de souscriptions requis

Avec un serveur bare metal, vous avez le choix entre des souscriptions de type paire de cœurs ou paire de sockets bare metal. Voici le calcul pour les deux options :

Nombre total de souscriptions de paires de cœurs = Nombre total de vCPU requis / 4, arrondi

250 vCPU / 4 = 62,5, arrondi à 63

Nombre total de souscriptions de paires de sockets =

• Nombre total de serveurs requis = 250 vCPU / 128 vCPU par serveur = 2 serveurs (après arrondissement)
• Nombre total de souscriptions requises par serveur = nombre de cœurs par paire de sockets / 128 = 64 / 128 = 0,5, arrondi à 1 souscription
• 2 serveurs x 1 souscription/serveur = 2 souscriptions de paires de sockets bare metal

Ici, puisque vous avez pu choisir un serveur adapté au ratio entre les vCPU et la mémoire, il est inutile de refaire le calcul pour déterminer le nombre de serveurs requis pour répondre aux besoins de la mémoire pour ensuite choisir le résultat le plus élevé. Si vous aviez choisi un serveur doté d'une capacité RAM différente, vous auriez dû en tenir compte.

Étape 5 : calculer le nombre total de souscriptions AI Accelerator (le cas échéant)

Cette étape ne s'applique pas à cet exemple, car vous n'utilisez pas d'accélérateur d'IA.

Résultat

Dans cet exemple, il vous faudrait 63 souscriptions OpenShift Platform Plus de type « paire de cœurs » ou deux souscriptions de paires de sockets bare metal . À ce stade, la décision devra être prise en fonction des aspects financiers et architecturaux.

Exemple 3 : environnement uniquement constitué de machines virtuelles

Vous migrez vos machines virtuelles à partir d'un hyperviseur tiers vers Red Hat. Il s'agit d'un environnement mixte et vous avez calculé le nombre de VM que vous avez classées selon leur taille :

• 1 000 VM de petite taille = 1 000 vCPU, 4 000 Gio, plus 228 Gio de mémoire supplémentaire
• 300 VM de taille moyenne = 600 vCPU, 2 400 Gio, plus 73 Gio de mémoire supplémentaire
• 200 VM de grande taille = 800 vCPU, 4 800 Gio, plus 58 Gio de mémoire supplémentaire
• 200 VM de très grande taille = 1 600 vCPU, 9 600 Gio, plus 64 Gio de mémoire supplémentaire

Étape 1 : identifier le nombre et le type d'instance d'application requis

D'après les informations tirées de notre exemple :

• Nombre d'instances d'application = 1 700
• Nombre total de processeurs virtuels = 4 000
• Mémoire totale = 20 800 Go + 423 Go supplémentaires = 21 223 Go
• Besoin moyen en vCPU de l'application = 2,4 vCPU
• Taille moyenne de la mémoire de l'application 12,5 Go

Étape 2 : déterminer la quantité totale de mémoire et de cœurs requise

En injectant les chiffres de l'étape 1 dans les calculs :

• Mémoire totale requise = 20 800 Go + 423 Go supplémentaires = 21 223 Go
• Nombre total de vCPU requis = 4 000

Le calcul de l'utilisation maximale des VM est légèrement différent de celui des conteneurs, mais il est connu des administrateurs chargés de la virtualisation.

En général, nous recommandons de ne pas surallouer de mémoire pour les VM. Privilégiez plutôt les besoins totaux en mémoire pour déterminer le nombre de nœuds de calcul.

Au niveau de la gestion des ressources de calcul, on observe souvent une surallocation de processeur, car la plupart des VM n'utilisent pas la totalité de leurs ressources de calcul. Le ratio de surallocation de processeur maximal pour OpenShift Virtualization étant de 10:1, un ratio de 4:1 est un choix prudent. Ici, vous pouvez également choisir d'utiliser des cœurs ou des threads (avec la prise en charge de l'hyper-threading, chaque cœur peut comporter 2 threads) pour égaler un vCPU. Par prudence, vous choisissez 1 vCPU = 1 cœur, et pas d'hyper-threading. Voici vos besoins :

• Mémoire totale requise = 20 800 Go + 423 Go supplémentaires = 21 223 Go
• Nombre total de cœurs requis = 4 000 vCPU x 1/4 x 1 cœur/vCPU = 1 000 cœurs

Étape 3 : choisir un nœud de calcul standard

Le choix d'un nœud de calcul bare metal pour la virtualisation dépend de nombreux facteurs, notamment la redondance, les domaines de défaillance et la taille des clusters. Un environnement sur site offre plusieurs options, dont l'augmentation de la capacité de RAM par serveur. Étant donné que la mémoire détermine souvent les besoins du serveur, vous pouvez commencer par cela.

Vous avez 1 700 VM et choisissez un serveur à 2 sockets de 32 cœurs chacun. Pour que le nombre de cœurs soit adapté au nombre de serveurs, voici le calcul :

• 1 000 cœurs / 64 cœurs/serveur = 16 serveurs (après arrondissement)

Avec 16 serveurs, vous avez besoin de 21 223 Go / 16 serveurs = 1 326 Go de RAM par serveur. Au vu des caractéristiques de votre serveur, vous pouvez choisir une RAM de 1 536 Go. La configuration de votre système bare metal est la suivante :

• Serveur à 2 sockets avec 32 cœurs/socket (64 cœurs au total), 1 536 Go de RAM

Enfin, avec 16 serveurs et cette configuration, vous obtenez les résultats totaux suivants :

• 16 x 64 cœurs = 1 024 cœurs
• 16 x 1 536 Go = 24 576 Go de mémoire

Ces ressources sont suffisantes pour l'exécution des charges de VM, mais vous aurez besoin de serveurs supplémentaires pour assurer la redondance. Avec la configuration actuelle, vous ne pouvez pas vous permettre une panne de serveur ou une baisse importante de performances. Pour assurer le basculement et la redondance, vous devriez prévoir 25 % de capacité de réserve. Vous aurez donc besoin des ressources suivantes :

• 16 serveurs + (16 serveurs x 25 %) = 20 serveurs au total

En répartissant les VM sur ces 20 serveurs, vous pourrez toujours satisfaire les besoins des VM en cas d'indisponibilité d'un à quatre serveurs. Notez que toutes les entreprises n'ont pas les mêmes exigences en matière de résilience.

Étape 4 : calculer le nombre total de souscriptions requis

Dans ce cas d'utilisation entièrement virtualisé, vous utilisez OpenShift Virtualization Engine, une solution uniquement disponible avec une souscription de paire de sockets bare metal.

Nombre total de souscriptions de paires de sockets =

• Nombre total de serveurs requis =20
• Nombre total de souscriptions requises par serveur = 1, étant donné que vos serveurs ont une capacité de 64 cœurs par paire de sockets
• 20 serveurs x 1 souscription/serveur = 20 souscriptions de paires de sockets bare metal

Étape 5 : calculer le nombre total de souscriptions AI Accelerator (le cas échéant)

Cette étape ne s'applique pas à cet exemple, car vous n'utilisez pas d'accélérateur d'IA.

Résultat

Dans cet exemple, vous auriez besoin de 20 souscriptions OpenShift Virtualization Engine de type paire de sockets bare metal .

Annexe 1: caractéristiques des versions autogérées d'OpenShift

Tableau 1 : disponibilité des fonctions générales par version de Red Hat OpenShift

Tableau 2 : caractéristiques des versions Red Hat OpenShift et opérateurs associés aux fonctions

Remarque 1 : la licence de l'opérateur OpenShift Elasticsearch inclus dans Red Hat OpenShift ne couvre que la prise en charge des besoins de recherche au sein de l'infrastructure interne du cluster OpenShift et ne peut pas être utilisée de manière autonome pour les applications client.

Logiciels Red Hat courants exclus de toutes les souscriptions Red Hat OpenShift

Sauf indication contraire, les offres logicielles Red Hat suivantes, bien que couramment associées à OpenShift, nécessitent une souscription séparée. La plateforme Red Hat OpenShift Platform Plus inclut Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay et Red Hat OpenShift Data Foundation Essentials. Les autres souscriptions OpenShift autogérées n'incluent pas ces produits supplémentaires, mais ils peuvent être achetés séparément. Voici la liste des logiciels Red Hat utilisés avec Red Hat OpenShift, non inclus dans ce guide de souscriptions :

• Red Hat Ansible Automation Platform
• Red Hat Application Foundations
• Red Hat Enterprise Linux AI
• Gamme Red Hat Integration, y compris 3scale, AMQ, CamelK, Fuse, etc.
• Red Hat JBoss EAP
• Offres groupées Red Hat Middleware
• Red Hat OpenShift Developer Hub (version Red Hat du projet Backstage)
• Red Hat OpenShift AI
• Red Hat Satellite (pour la gestion de Red Hat Enterprise Linux)
• IBM CloudPaks

Contactez un représentant ou un partenaire Red Hat pour en savoir plus sur ces offres.