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

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 droits d'utilisation nécessaires pour votre environnement Red Hat OpenShift. Vous pouvez aussi faire une demande pour obtenir des informations plus précises concernant le dimensionnement.

Pour commencer, définissons quelques termes importants qui sont utilisés dans ce guide :

• Paire de cœurs : première unité de base pour les souscriptions des solutions OpenShift autogérées, qui correspond à deux cœurs physiques ou à quatre processeurs virtuels (vCPU). Sur une machine bare metal, cette unité fait toujours référence au 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 basées sur des paires de cœurs sont comptabilisées au niveau du cluster, elles peuvent couvrir plusieurs instances cloud, machines virtuelles et serveurs physiques.
• Nœud bare metal : autre unité de base pour les souscriptions des solutions OpenShift autogérées. Il faut compter une souscription de nœud bare metal par serveur physique. Chacune ne peut couvrir qu'un seul serveur, tout comme avec une souscription de paire de cœurs.
• 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 des 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 machines virtuelles (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.
• Contrat de niveau de service (SLA) : les souscriptions Red Hat nécessitent 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 sur lesquelles s'exécutent les pods d'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 d'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 pour les solutions 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œud d'infrastructure : nœud chargé de l'exécution des pods prenant en charge une infrastructure de cluster OpenShift (nœuds qui exécutent l'équilibreur de charge basé sur HAProxy pour le trafic entrant, par exemple). Les souscriptions pour les solutions 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 : groupe de ressources composé 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 : application composée d'une seule instance de pod ou 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 deux 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.

Red Hat OpenShift offre 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, physiques et sur site, ainsi qu'avec les clouds privés, les clouds publics et les déploiements à la périphérie du réseau. La solution Red Hat OpenShift est proposée sous forme de versions autogérées et de services cloud entièrement gérés. Ce guide couvre uniquement les solutions OpenShift autogérées.

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. Vous pouvez contrôler les mises à niveau, gérer l'infrastructure de niveau inférieur et assurer le suivi des SLA.

Les services cloud OpenShift gérés 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 gère les services et l'infrastructure de base de Red Hat OpenShift, et en assure le bon fonctionnement. Vos équipes DevSecOps peuvent ainsi concentrer leurs efforts 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é et pris en charge par 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 éditions 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.

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.

Solutions logicielles OpenShift autogérées :

• Red Hat OpenShift Kubernetes Engine : moteur d'exécution Kubernetes adapté aux entreprises dans le cloud hybride, fournissant 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 basée sur Kubernetes et adaptée aux entreprises, conçue pour l'assemblage, 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 d'assembler, de déployer, d'exécuter et de gérer des applications intelligentes à grande échelle dans plusieurs clusters et environnements cloud. La sécurité, la facilité de gestion et l'automatisation reposent sur plusieurs couches qui assurent la cohérence dans toute la chaîne d'approvisionnement des logiciels. Les souscriptions pour 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 qui conviennent au déploiement, à la gestion et à la mise à l'échelle de machines virtuelles. Cette édition est exclusivement conçue pour les charges de travail de machines virtuelles. Seuls les services d'infrastructure sont pris en charge dans les conteneurs (les conteneurs d'applications des utilisateurs finaux 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 nœuds 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 proposées sur la base de paires de cœurs ou de nœuds bare metal :

1. Paire de cœurs (2 cœurs ou 4 vCPU)

• Cette souscription est proposée pour les solutions OpenShift Kubernetes Engine, OpenShift Container Platform et OpenShift Platform Plus. Les souscriptions de paire de cœurs ne s'appliquent pas à OpenShift Virtualization Engine.

• Pour obtenir des droits d'utilisation 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 dans les clusters OpenShift à couvrir avec une souscription de paire de cœurs.
• SLA disponible en version Standard (assistance en journée, du lundi au vendredi) et Premium (assistance 24 h/24, 7 j/7).

2. Nœud bare metal (1 nœud physique) 

• Un nœud physique correspond à un serveur, quel que soit le nombre de sockets de processeur dans le serveur ou de cœurs dans les processeurs.
• Proposée pour toutes les éditions 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 à la solution Red Hat Enterprise Linux for Virtual Datacenters, où une seule souscription permet d'installer un nombre illimité de systèmes d'exploitation de machines virtuelles invités sur tous les hôtes d'hyperviseur.
• SLA disponible en version Standard (assistance en journée, du lundi au vendredi) et Premium (assistance 24 h/24, 7 j/7).

Vous devrez aussi 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 les ressources 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 dans le cluster.
• Cette souscription n'est pas requise tant que l'accélérateur n'est pas exploité pour renforcer les ressources de calcul (par exemple, lorsqu'un DPU est utilisé comme 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).
• SLA disponible en version Standard (assistance en journée, du lundi au vendredi) et Premium (assistance 24 h/24, 7 j/7). Le SLA doit correspondre au SLA de la souscription sous-jacente (paire de cœurs ou nœud bare metal).

Cas d'utilisation des souscriptions de paire 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 basée sur les nœuds bare metal peut s'avérer plus rentable.

Lorsque vous utilisez OpenShift Virtualization Engine comme plateforme de virtualisation dédiée, vous pouvez appliquer la souscription de paire de cœurs à des conteneurs OpenShift sur des machines virtuelles, en plus de la souscription de nœud bare metal pour l'hyperviseur. Il vous faudra acheter séparément des souscriptions de paire 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 sous forme de machine virtuelle. 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 basé sur les nœuds 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 machines virtuelles OpenShift.

Les souscriptions de paire 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 paire 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 nœud 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 nœud bare metal. Celles-ci permettent la prise en charge de la fonction OpenShift Virtualization des autres éditions OpenShift autogérées. 

Chaque souscription de nœud bare metal donne droit d'utiliser un seul nœud physique, quel que soit le nombre total de sockets ou cœurs de processeurs.

Chaque serveur physique et bare metal qui utilise des souscriptions basées sur le nombre de nœuds 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 dans 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 paire de cœurs pour un déploiement de la solution OpenShift sur des machines virtuelles.

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 nœud incluent la fonction OpenShift Virtualization ainsi que des souscriptions pour les clusters OpenShift virtuels du même type de produit qui y est déployé. Par exemple, des clusters OpenShift virtuels déployés dans 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'application conteneurisées, à l'exception des charges de travail d'infrastructure définies dans la section ci-après relative à OpenShift Virtualization Engine. Si vous souhaitez exécuter vos propres charges de travail d'applications conteneurisée avec OpenShift Virtualization Engine, vous devez acquérir des souscriptions de paire de cœurs pour vos machines virtuelles avec une édition autogérée d'OpenShift. À partir d'un certain volume, vous pouvez acheter une souscription de nœud bare metal pour les solutions autogérées OpenShift Kubernetes Engine, OpenShift Container Platform ou OpenShift Platform Plus. Vous pourrez ainsi exécuter vos applications conteneurisées de façon native dans le cluster bare metal ou hériter des souscriptions dans 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 paire de cœurs et de nœud 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 machines virtuelles 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 paire de cœurs ou de nœud 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 comme 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

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 bénéficier du droit d'utilisation qu'offre un nœud d'infrastructure, les instances ne doivent exécuter que des composants qui font fonctionner le cluster sans faire partie d'une application d'utilisateur final. Exemples :

• Registre OpenShift
• OpenShift Ingress Router (Ingress locaux, globaux et multiclusters)
• OpenShift Observability
• Instances basées sur HAProxy et utilisées pour gérer les Ingress des clusters
• 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
• Ansible Automation Platform, lorsque la plateforme sert uniquement à gérer les clusters

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 la catégorie des charges de travail d'infrastructure :

• Agents de surveillance tiers et personnalisés
• Pilotes et contrôleurs (plug-ins) CNI (Container Networking Interface) et CSI (Container Storage Interface)
• Accélérateurs de mise en œuvre pour le matériel ou la virtualisation
• Pods de contrôleurs utilisés pour les définitions de ressources personnalisées ou les opérateurs Kubernetes (logiciels tiers ou personnalisés)

Il est impossible d'exécuter une autre instance ou un autre type d'application d'utilisateur final 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 machines virtuelles. 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 systèmes d'exploitation invités sur les machines virtuelles. 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 machine virtuelle. 

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.

Démarrage d'un registre de conteneurs pour mettre en miroir les 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 réduit de Quay, 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 comme registre miroir est limitée à la mise en miroir des composants et fichiers (ou « payload ») associés à une version d'OpenShift, des contenus 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 conteneurs pour les charges de travail d'infrastructure remplissant les conditions requises. Voici quelques exemples :

• Agents de surveillance
• Fournisseurs CNI et CSI
• Agents de mise en œuvre pour le matériel ou la virtualisation
• Opérateurs compatibles avec les services des éditeurs de logiciels indépendants (ISV)
• Opérateurs personnalisés servant de 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 paire 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 nœud bare metal.

Première exception : exécution d'instances d'application sur des nœuds de plan de contrôle ou d'infrastructure

Puisque 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 pas d'instances d'application. 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 n'ont pas besoin de souscription, consultez la section sur les nœuds d'infrastructure.

Seconde exception : 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 à nœud unique déploie l'ensemble des services OpenShift et des applications d'utilisateur final sur un seul nœud physique ou virtuel, en les optimisant pour réduire l'empreinte et maximiser les ressources auxquelles les applications ont accès. 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.

Récupération après sinistre

Chez Red Hat, nous avons 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 à accueillir 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, au moyen d'une solution de stockage logiciel hébergée sur OpenShift, 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. Les clusters de récupération après sinistre intermédiaire ne doivent pas participer à la réplication active des volumes de données entre les clusters, que ce soit de manière synchrone ou asynchrone, lorsque le site secondaire monte ces données dans les charges de travail de conteneurs qui s'exécutent activement dans le cluster. Les périphériques de stockage externe chargés de répliquer les volumes sont également considérés comme des systèmes de récupération après sinistre intermédiaire. Pour les solutions de stockage logiciel hébergées sur OpenShift, la récupération après sinistre intermédiaire implique de restaurer les données du client sur le matériel du cluster existant depuis l'extérieur du cluster.
• Les systèmes de récupération après sinistre à froid ont une infrastructure en place, mais ne disposent pas de l'ensemble des technologies (matériel, logiciels et données) nécessaires pour rétablir le 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. Vous n'avez pas besoin d'acquérir une souscription supplémentaire pour l'un des composants des offres logicielles Red Hat OpenShift si vous souhaitez faire sortir temporairement un cluster de son hibernation à des fins de maintenance ou de test. 

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é avec les 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 avec hyper-threading

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 OpenShift virtualisés 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 : même s'il n'est fait référence qu'à l'architecture IBM Z à partir de cette section, 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 afin d'assembler et de déployer des applications cloud-native et des microservices. Seul le modèle de souscription basé sur les cœurs s'applique aux plateformes IBM Z et IBM Power. Les souscriptions Red Hat OpenShift basées sur les nœuds bare metal ne peuvent pas être utilisées pour les plateformes IBM Z et IBM Power. 

Les clusters ARM sont couverts par 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 distinctes ou d'autres moyens. 

Pour IBM Z, il faut une souscription OpenShift de cœur par processeur IFL (Integrated Facility for Linux). IBM Z est la seule architecture pour laquelle les souscriptions sont basées sur un seul cœur. Elle n'est associée à aucun vCPU. 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. Ces processeurs doivent être activement utilisés pour le plan de contrôle et/ou les services d'infrastructure et ne nécessitent pas de droits d'utilisation OpenShift. Pour les déploiements de clusters compacts à trois nœuds, tous les processeurs IFL doivent être couverts. 

L'architecture IBM Power utilise le modèle de souscription de paire de cœurs. Elle n'est associée à aucun vCPU.

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 vous rendre sur le portail client Red Hat (connexion requise) pour consulter l'article présentant la matrice de compatibilité des composants de la version 4.19 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. Les conteneurs Windows Server fonctionnent uniquement sur 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 proposée sous la forme d'une souscription indépendante dont le tarif est calculé sur la base du nombre de cœurs.

Il est possible d'utiliser les infrastructures Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform et Red Hat OpenShift Kubernetes Engine pour déployer et gérer des nœuds de calcul Windows Server. La prise en charge des conteneurs Microsoft Windows Server est proposée sous forme de module complémentaire indépendant à 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 précédents sont fournis à titre indicatif uniquement. Vous pourrez peut-être optimiser votre environnement actuel pour en réduire la taille totale ou améliorer l'utilisation des ressources. 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. 

Outre les fonctions de base d'OpenShift Container Platform, Red Hat OpenShift Platform Plus comprend des logiciels supplémentaires qui vous aideront à gérer et protéger votre environnement Red Hat OpenShift à grande échelle dans plusieurs clusters et plusieurs clouds. Les souscriptions OpenShift Platform Plus sont proposées sur la base des paires de cœurs ou des nœuds 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. Un logiciel supplémentaire ne peut servir qu'à gérer les 200 cœurs sur lesquels le logiciel OpenShift Platform Plus est installé.

Voici les règles spécifiques de 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, ainsi que de gérer tous les nœuds et clusters couverts par OpenShift Platform Plus, notamment 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, les souscriptions proposées et les 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, ainsi que de gérer tous les nœuds et clusters couverts par OpenShift Platform Plus, notamment 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 voulez dans vos clusters OpenShift Platform Plus. La solution Quay peut ensuite être utilisée dans tous les environnements Kubernetes pris en charge, notamment 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. La solution Red Hat Quay est également proposée 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 dans tous les clusters où s'exécute OpenShift Platform Plus. L'accès est limité aux fonctions disponibles dans l'édition Essentials, et la capacité de stockage à 256 To par cluster OpenShift. Vous pouvez acquérir d'autres souscriptions pour bénéficier d'autres fonctionnalités et d'une plus grande 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.
• Argo CD Agent : une souscription OpenShift Platform Plus vous permet d'installer Argo CD Agent, composant de Red Hat OpenShift GitOps, dans tous les clusters où s'exécute OpenShift Platform Plus. Argo CD Agent peut s'exécuter sur Red Hat OpenShift ou dans les environnements Kubernetes pris en charge (OpenShift Container Platform inclut Red Hat OpenShift GitOps).

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 récents changements sur le marché de la virtualisation, les utilisateurs recherchent de nouvelles plateformes de virtualisation et s'intéressent en particulier à celles qui leur donnent les moyens de moderniser leur environnement. Ces clients souhaitent uniquement mettre en œuvre la virtualisation, en se réservant la possibilité d'adopter les fonctionnalités modernes de développement d'applications et de conteneurisation à leur propre rythme.

Red Hat OpenShift Virtualization Engine est une édition autogérée d'OpenShift destinée aux clients qui cherchent une autre plateforme de virtualisation pour exécuter leurs machines virtuelles. Elle est couverte par les souscriptions de nœud bare metal sur les serveurs physiques et les instances bare metal des hyperscalers pris en charge. Lorsqu'ils sont prêts à exploiter la gamme complète des produits, les utilisateurs peuvent modifier leurs droits de souscription sans redéployer les clusters existants.

OpenShift Virtualization Engine inclut uniquement les fonctions de déploiement, de gestion et d'exécution des machines virtuelles avec 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 d'éditions Red Hat OpenShift au sein de machines virtuelles (nécessite l'achat de souscriptions de paire de cœurs)
• N'inclut pas de droits d'utilisation d'instances invitées de Red Hat Enterprise Linux pour les machines virtuelles (nécessite l'achat de la solution Red Hat Enterprise Linux for Virtual Datacenters ou d'une souscription basée sur le nombre de machines virtuelles)

Les solutions Red Hat Advanced Cluster Management et Red Hat Ansible® Automation Platform peuvent fonctionner avec OpenShift Virtualization Engine. Pour ces deux produits, il existe des souscriptions complémentaires réservées aux cas d'utilisation de la virtualisation, à un coût inférieur à celui de la version complète. 

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

Concernant les clients qui ne disposent pas des applications centrales Red Hat Advanced Cluster Management et Ansible Automation Platform, la souscription pour les modules complémentaires mentionnés inclut également une assistance pour l'installation de ces applications sous forme de conteneurs d'infrastructure sur leurs hôtes OpenShift Virtualization Engine. Consultez la documentation sur Red Hat Advanced Cluster Management et Ansible Automation 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œuds d'hyperviseur citées ci-dessus, les clients doivent acquérir une souscription de nœud pour chaque instance de machine virtuelle. Consultez la documentation relative à Ansible Automation Platform pour en savoir plus.

Même si les droits d'utilisation pour OpenShift Virtualization Engine limitent l'exécution des instances d'application client aux machines virtuelles, de nombreux éléments de l'infrastructure, notamment les pilotes de stockage, les applications de sauvegarde, les agents de transfert, Red Hat Advanced Cluster Management et Ansible Automation Platform, sont exécutés sous forme de conteneurs d'infrastructure dans Red Hat OpenShift. Cette souscription 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.

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 machines virtuelles et les conteneurs 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 matière de droits d'utilisation 

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'application, susceptibles de s'exécuter à tout moment donné.

Étape 1 : identifier le nombre et le type d'instances d'application requises

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. D'autres éléments peuvent affiner cette estimation, notamment les processeurs, la sursouscription de la mémoire, ou encore les quotas et les limites.

Tableau 1 : questions relatives au dimensionnement des applications et des instances

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

Une fois que vous avez déterminé les besoins d'une instance d'application et le nombre d'instances, vous pourrez facilement calculer la quantité totale de ressources de calcul et de mémoire nécessaire. 

À ce stade, vous devez déterminer le seuil maximal d'utilisation pour vos nœuds de calcul. Prévoyez également des ressources pour la charge de travail d'OpenShift (1 cœur ou 1 vCPU et 1 Go de RAM par nœud de calcul, consultez la documentation pour en savoir plus) et pour les variations normales de la charge d'application afin d'éviter une mise à l'échelle automatique systématique. Si vous envisagez une utilisation intensive (supérieure à 80 %), tenez compte des ressources supplémentaires nécessaires pour OpenShift lorsque vous calculez la capacité de mémoire et le nombre de cœurs.

Pour les cas d'utilisation liés à la virtualisation, réfléchissez aux questions de surallocation du processeur et de la mémoire, de redondance et de haute disponibilité, ainsi qu'à l'architecture de l'environnement dans son ensemble. L'exemple 3 illustre ce type de situation.

Tableau 2 : questions relatives au seuil d'utilisation maximal des nœuds OpenShift

Utilisation maximale = pourcentage déterminé par l'architecte

Nombre total de cœurs (ou vCPU) requis = « cœurs pour 1 application » x « nombre d'instances d'application » x 1 / « pourcentage d'utilisation »

Mémoire totale requise = « mémoire pour 1 application » x « nombre d'instances d'application » x 1 / « pourcentage d'utilisation »

Étape 3 : choisir un nœud de calcul standard (machine virtuelle, instance cloud ou serveur bare metal)

Maintenant que vous avez déterminé la quantité totale de cœurs et de mémoire à prendre en compte, vous devez choisir un nœud de calcul standard pour le déploiement des nœuds de calcul de vos applications. 

Dans le cas d'une infrastructure de virtualisation, soit votre environnement vous permet de choisir la configuration des VM qui serviront de nœud de calcul, soit vous devez sélectionner une option parmi plusieurs types de VM standard. 

Dans un cloud d'hyperscaler, vous devez généralement choisir un type d'instance cloud selon vos besoins en capacité de calcul, mémoire et accès aux équipements facultatifs tels que les accélérateurs d'IA. 

Les déploiements bare metal sur site ou auprès d'un hyperscaler proposent une configuration de serveur standard, ou plus personnalisée dans certains cas. 

Si possible, choisissez des nœuds de calcul qui respectent au mieux votre ratio nombre de cœurs/mémoire. Par exemple, si vos conteneurs ont besoin, en tout, de 400 vCPU et 1 600 Go de RAM, vous obtiendrez les meilleurs ratios de consolidation moyens en optant pour les nœuds de calcul présentant un ratio de 1:4 entre les vCPU et la mémoire. 

Tableau 3 : questions relatives au dimensionnement des machines virtuelles et du matériel

Étape 4 : calculer le nombre total de souscriptions requises

Pour finir, déterminez le nombre de souscriptions Red Hat OpenShift requises en fonction des données recueillies aux étapes 1 à 3. Dans le cas de souscriptions pour des VM ou des instances cloud d'hyperscaler, vous devez utiliser le modèle de souscription de paire de cœurs. Si vous utilisez des serveurs bare metal, faites le calcul des souscriptions pour les deux modèles, puis comparez les coûts et la flexibilité afin de déterminer celui qui sera le plus adapté à vos besoins. 

Modèle de souscription de paire de cœurs

• Nombre de souscriptions de paire de cœurs pour une solution OpenShift autogérée¹ 

= nombre total de cœurs / 2, arrondi ou

= nombre total de vCPU / 4, arrondi

Modèle de souscription de nœud bare metal

• Dans un premier temps, calculez le nombre de souscriptions de paire de cœurs requises pour votre application, puisque ce modèle est aussi adapté à une installation bare metal.
• Ensuite, déterminez le nombre de souscriptions bare metal : chaque serveur physique nécessite une souscription de nœud bare metal (une souscription par nœud).
• Enfin, comparez les deux modèles en tenant compte des coûts et de la flexibilité.
  • Aspect financier :
    • Choisissez le modèle le moins coûteux en fonction de la taille actuelle de votre environnement.
    • À l'avenir, au-delà d'un certain seuil de rentabilité, l'autre modèle pourra s'avérer plus intéressant d'un point de vue financier.
  • Aspect architectural :
    • Les souscriptions de paire de cœurs peuvent être utilisées dans tout l'environnement (machines virtuelles, instances cloud, serveurs bare metal), tandis que les souscriptions de nœud bare metal ne concernent que les serveurs bare metal.
    • Les souscriptions de paire de cœurs utilisées sur des serveurs bare metal doivent y exécuter des conteneurs et se trouver dans un seul et même cluster.
    • Vous pouvez choisir d'installer OpenShift Virtualization Engine sur vos serveurs bare metal, puis ajouter des souscriptions OpenShift de paire de cœurs pour les conteneurs (OpenShift sur OpenShift). Cette solution est plus adaptée à un environnement de machine virtuelle mixte présentant peu de charges de travail OpenShift par serveur.
    • Si le volume de charges de travail Red Hat OpenShift sur un serveur bare metal est élevé, une souscription de nœud bare metal permettra de déployer un nombre illimité de conteneurs OpenShift, soit directement sur le serveur bare metal, soit dans les machines virtuelles exécutées sur le serveur, via la fonction OpenShift Virtualization.

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

Ajoutez toutes les souscriptions AI Accelerator ci-dessus. Il vous faut une souscription AI Accelerator par accélérateur physique sur site ou serveur bare metal. Dans un environnement cloud d'hyperscaler, il est indiqué pour chaque type d'instance permettant d'améliorer les performances de calcul le nombre de GPU physiques ou d'accélérateurs inclus. Rappelez-vous que le SLA de la souscription AI Accelerator doit correspondre celui de la souscription Red Hat OpenShift choisie.

Remarque : Red Hat OpenShift prend en charge de nombreuses fonctions et capacités qui ont une influence sur les fonctions d'évolutivité, d'ordonnancement des pods, d'inactivité et de quota/limitation des ressources. Les calculs précédents sont fournis à titre indicatif uniquement. Vous pourrez peut-être optimiser votre environnement actuel pour en réduire la taille totale ou améliorer l'utilisation des ressources. 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. 

Votre application comprend 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 l'édition Red Hat OpenShift Platform Plus comme solution autogérée et vous devez estimer le nombre de souscriptions nécessaires.

Étape 1 : identifier le nombre et le type d'instances d'application requises

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

• Nombre d'instances d'application = 200
• Seuil d'utilisation maximal des nœuds = 80 %
• Besoins moyens 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

Injectons 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 ratio entre les vCPU et la mémoire est de 250 vCPU pour 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 de 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 requises

Dans cet exemple, vous avez besoin de souscriptions de paire de cœurs, car votre application est exécutée dans le cloud d'un hyperscaler qui utilise des vCPU. Vous choisissez donc la formule basée sur les paires 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 de paire de cœurs pour OpenShift Platform Plus.

Vous souhaitez maintenant déployer cette même application sur site et sur des serveurs bare metal, avec des nœuds de calcul de machines virtuelles, à 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 standards.

Étape 1 : identifier le nombre et le type d'instances d'application requises

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

• Nombre d'instances d'application = 200
• Seuil d'utilisation maximal des nœuds = 80 %
• Besoins moyens 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

Injectons 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. Vous choisissez finalement 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 requises

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

Nombre total de souscriptions de paire de cœurs = nombre total de vCPU requis / 4, arrondi
250 vCPU / 4 = 62,5, arrondi à 63

Nombre total de souscriptions de nœud = nombre total de serveurs physiques

• Nombre total de serveurs requis = 250 vCPU / 128 vCPU par serveur = 2 serveurs (après arrondissement)
• 2 serveurs x 1 souscription/serveur = 2 souscriptions de nœud 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 afin de déterminer le nombre de serveurs requis pour répondre aux besoins de la mémoire puis de choisir le résultat le plus élevé. Si vous aviez choisi un serveur doté d'une quantité différente de RAM ou de cœurs de processeur, 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 de paire de cœurs ou 2 souscriptions de nœud bare metal pour OpenShift Platform Plus. À ce stade, la décision devra être prise en fonction des aspects financiers et architecturaux. 

Vous migrez vos machines virtuelles depuis un hyperviseur tiers vers Red Hat. Il s'agit d'un environnement mixte et vous avez calculé le nombre de machines virtuelles 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'instances d'application requises

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
• Besoins moyens 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

Injectons 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 machines virtuelles est légèrement différent de celui des conteneurs, mais les administrateurs chargés de la virtualisation doivent normalement le connaître. 

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 avoir un nombre de cœurs adapté au nombre de serveurs, voici le calcul à effectuer :

• 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 requises

Dans ce cas d'utilisation reposant entièrement sur la virtualisation, vous utilisez la solution OpenShift Virtualization Engine, pour laquelle seule la souscription de nœud bare metal est proposée.

Nombre total de souscriptions de nœud = 

• Nombre total de serveurs requis = 20
• 20 serveurs x 1 souscription/serveur = 20 souscriptions de nœud 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, il faudrait 20 souscriptions de nœud bare metal pour OpenShift Virtualization Engine.

Tableau 1 : fonctions incluses dans les différentes éditions de Red Hat OpenShift

Tableau 2 : caractéristiques détaillées des éditions de 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 il ne peut pas être utilisé de manière autonome pour les applications client.

Logiciels Red Hat courants non inclus dans les éditions de 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. L'édition 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 sur les souscriptions :

• Red Hat Advanced Developer Suite
• 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 Data Foundation Advanced
• 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.