Unité 4.1 : Sélection de la classe de calcul

Introduction

La classe de calcul n'est pas une décision de dimensionnement ; c'est une décision architecturale, et sur IONOS CLOUD, elle est définie par niveau plutôt que par ensemble. La classe choisie détermine simultanément quatre aspects : si la charge de travail dispose d'un cœur physique exclusif ou en partage, si vous pouvez fixer la famille de CPU, si vous pouvez attacher du Block Storage réseau, et qui porte le modèle opérationnel. L'une de ces décisions est en réalité permanente (le modèle d'un Cube est immuable après le provisionnement), il est donc plus économique de choisir la bonne classe dès la phase de conception que de recourir à des contournements ultérieurs. Cette unité rend cette décision explicite pour les trois classes de calcul d'IONOS CLOUD, puis se termine par le provisionnement de la coquille Dedicated Core que les unités 4.2 et 4.3 étendent avec le stockage, cloud-init et la mise à l'échelle automatique.

1. La décision de calcul à quatre dimensions

Chaque classe de calcul d'IONOS CLOUD répond différemment aux mêmes quatre questions. Gardez ces quatre axes en tête et la classe se choisira presque d'elle-même.

Isolation des cœurs. Un serveur Dedicated Core est doté d'un cœur physique dédié, exposé au système d'exploitation invité sous forme de deux cœurs logiques (un cœur physique avec Hyper-Threading apparaît comme deux threads). Un serveur vCPU partage les cœurs physiques avec d'autres locataires. L'isolation offre des performances prévisibles en cas de concurrence ; le partage offre un prix plus bas. C'est le modèle de concurrence que l'Unité 2.4 a présenté comme le premier levier de coût, vu ici du côté du calcul.

Contrôle de la famille de CPU. Seul Dedicated Core permet de sélectionner et de modifier ultérieurement la famille de CPU (par exemple, fixer AMD EPYC pour une charge de travail qui en bénéficie, ou standardiser un niveau sur Intel Xeon). Sur un serveur vCPU, la famille n'est pas sélectionnable. Cela importe lorsque la charge de travail est sensible aux différences de jeu d'instructions ou de fréquence par cœur, ou lorsqu'une licence est liée à une famille de CPU.

Attachement du Block Storage. Les serveurs Dedicated Core et vCPU attachent des volumes de Block Storage réseau (le disque de démarrage et tous les disques de données résident sur le tissu de blocs iSCSI, traité dans l'Unité 4.2). Un Cube est livré avec un volume NVMe en direct-attachement obligatoire, qui fait partie de son modèle fixe. Le modèle d'attachement détermine la gestion du cycle de vie du stockage, des instantanés et des redimensionnements.

Modèle opérationnel et SLA. Un serveur Dedicated Core ou vCPU est une VM gérée avec mise à l'échelle verticale en direct et un SLA de disponibilité par service de 99,95 %. Un Cube est une instance à modèle fixe avec un SLA de 99,9 %.

Le tableau suivant confronte les trois classes selon les axes qui guident la décision.

Un serveur Dedicated Core peut être configuré jusqu'à 62 cœurs et 230 Go de RAM. La RAM est allouée par incréments de 0,25 Go. Ces plafonds contraignent rarement un niveau unique, mais ils comptent lors du dimensionnement d'un monolithe important avant de décider de le fractionner.

1.1 Dedicated Core : le choix par défaut pour les niveaux qui exigent une garantie

Choisissez Dedicated Core lorsque le niveau nécessite des performances prévisibles sous charge, ou lorsque vous devez fixer ou modifier la famille de CPU. Le cœur physique exclusif est ce qui achète la garantie de performance en cas de concurrence, et le contrôle de la famille de CPU est propre à cette classe. Si un niveau doit également faire l'objet d'une mise à l'échelle horizontale, sa configuration de calcul des répliques (architecture CPU, cœurs et RAM) est définie au moment de la conception dans le modèle de réplique de VM Auto Scaling (Unité 4.3), de sorte que fixer tôt la forme de calcul du niveau reste avantageux. Le coût du cœur exclusif est le prix à payer pour la garantie de performance.

La sélection de la famille de CPU sur Dedicated Core est réelle mais pas gratuite : changer la famille sur un serveur existant exige un redémarrage. Considérez un changement de famille comme une opération de maintenance planifiée avec une fenêtre, et non comme un réglage en direct.

1.2 vCPU : économique lorsque la concurrence est acceptable

Un serveur vCPU est provisionné et se comporte comme toute autre VM, mais partage les cœurs physiques. C'est pourquoi il constitue le choix par défaut économique pour les environnements de développement et de test, les services logiciels internes, et les niveaux où une concurrence occasionnelle est acceptable. Il prend en charge la mise à l'échelle verticale en direct comme Dedicated Core, mais ne permet pas de sélectionner une famille de CPU. La règle de décision est simple : si le niveau n'a besoin ni d'une garantie de performance ni d'un contrôle de la famille de CPU, un serveur vCPU est le choix correct et moins cher.

1.3 Cubes : l'instance à modèle fixe, pas une impasse pour le stockage

Un Cube est une instance à configuration fixe : vCPU, RAM et volume NVMe en direct-attachement sont livrés en tant que modèle groupé, et vous ne pouvez pas modifier ces propriétés du modèle après le provisionnement. Le volume NVMe est connecté via PCI Express sur le serveur physique et est en RAID logiciel à redondance simple ; il occupe l'un des emplacements de périphériques de l'instance et ne peut ni être détaché ni supprimé tant que le Cube existe. Les modèles de base vont de Basic-Cube-XS (1 vCPU, 2 Go de RAM, 60 Go de NVMe) à Basic-Cube-XL (16 vCPU, 32 Go de RAM, 960 Go de NVMe) ; les modèles mémoire troquent des cœurs contre de la RAM (par exemple Memory-Cube-XL avec 16 vCPU et 64 Go de RAM).

Voici le piège, et il va à l'encontre d'une supposition courante. On rejette souvent le Cube en le considérant comme incapable d'utiliser le Block Storage. C'est faux : un Cube prend en charge jusqu'à 23 périphériques HDD ou SSD (Standard ou Premium) de Block Storage en option, en plus de son volume NVMe obligatoire, et ces périphériques en option peuvent être détachés et supprimés à tout moment après le provisionnement. La contrainte réelle est différente et plus précise : le modèle lui-même (vCPU, RAM et taille du NVMe) est immuable, et le volume NVMe ne peut pas être détaché. Supprimer un Cube supprime son volume NVMe, alors prenez d'abord un instantané si les données doivent subsister. La règle de conception honnête est donc : choisissez un Cube lorsque son groupe fixe correspond à la charge de travail et que vous souhaitez une ligne de coût prévisible unique, et planifiez les données persistantes sur des volumes de Block Storage en option qui survivent au modèle, et non sur le disque NVMe immuable.

2. La classe par niveau comme modèle

L'unité de décision pour la classe de calcul est le niveau, et non l'application. Une conception d'entreprise par couches (la structure publique L7 vers calcul sans état vers privé L4 vers données privées décrite dans l'unité 1.2) associe couramment différentes classes : Dedicated Core pour le niveau qui doit être mis à l'échelle et garantir des performances, vCPU pour les niveaux internes ou non critiques, et un Cube lorsque le regroupement fixe correspond parfaitement aux besoins. Lorsqu'une charge de travail nécessite une plateforme gérée monolocataire (par exemple un environnement VMware réglementé), il s'agit du VMware Private Cloud dédié traité dans l'unité 4.4, et non d'une classe de calcul Public Cloud. L'association de classes par niveau est la norme, et non un compromis.

Deux règles de conception en découlent et méritent d'être formulées clairement, car les deux sont faciles à mal appliquer sous pression temporelle :

• La configuration de calcul des répliques d'un niveau à mise à l'échelle automatique est définie au moment de la conception. VM Auto Scaling crée de nouvelles répliques à partir d'un modèle de réplique (architecture CPU, cœurs, RAM), et une modification du modèle ne s'applique qu'aux répliques créées ultérieurement. La configuration des répliques est donc une décision de conception, et non un réglage en direct (unité 4.3).
• Un changement de famille de CPU est une opération planifiée. Il est disponible sur Dedicated Core mais nécessite un redémarrage, il doit donc être effectué pendant une fenêtre de maintenance, et non dans un guide d'exploitation de réglage en direct.

Pour FinCorp, la société de services financiers allemande réglementée qui sert de fil conducteur à ce cours, le niveau d'application destiné aux clients est celui le plus susceptible de subir une charge variable et le plus exposé au répartiteur de charge public de couche 7. Ce niveau est provisionné en Dedicated Core pour garantir des performances prévisibles sous charge, ce qui permet de standardiser sa famille de CPU pour des performances cohérentes. C'est également le niveau qui sera ensuite mis à l'échelle horizontalement selon une politique basée sur des métriques (unité 4.3). En revanche, le niveau de rapports par lots internes de FinCorp tolère la concurrence et est provisionné en vCPU pour réduire les coûts. L'angle de conformité renforce cette approche : BSI C5 (l'attestation de type 1 du 7 novembre 2023) et IT-Grundschutz (le certificat ISO 27001 du 14 septembre 2022) couvrent tous deux Compute Engine, de sorte que les classes de VM standard s'inscrivent dans le périmètre d'attestation de FinCorp. L'environnement VMware réglementé constitue une décision distincte, gérée par le VMware Private Cloud dédié dans l'unité 4.4.

Considérations de conception

• Coût. Le cœur exclusif de Dedicated Core est le supplément que vous payez pour une garantie de performances et l'éligibilité à la mise à l'échelle automatique. Lorsque ni l'une ni l'autre n'est requise, vCPU est la réponse correcte et moins coûteuse ; n'achetez pas l'isolation dont une couche n'a pas besoin.
• Exploitation. La décision permanente (le modèle immuable d'un Cube) entraîne le coût opérationnel le plus élevé lorsqu'elle est erronée, car la corriger implique de reconstruire plutôt que de reconfigurer. Accordez le plus grand soin de conception à cet aspect.
• Évolutivité. La mise à l'échelle verticale (augmentation en direct de la CPU et de la RAM) est disponible sur Dedicated Core et vCPU, dans les limites décrites dans l'Unité 4.3 ; la mise à l'échelle horizontale gérée ajoute et supprime des répliques entières selon une politique de métriques, la configuration de calcul de la réplique étant fixée dans le modèle de réplique au moment de la conception. Déterminez sur quel axe une couche sera mise à l'échelle avant de choisir sa classe.

Déroulement de la mise en œuvre de DCD

Ce déroulement provisionne le serveur shell Dedicated Core que le reste du Module 4 étend. Il met en œuvre la décision de conception décrite ci-dessus pour la couche destinée aux clients de FinCorp : une classe Dedicated Core pour une garantie de performance prévisible, afin que sa famille de CPU soit sous notre contrôle. Le prérequis est le centre de données virtuel FinCorp créé dans l'Unité 3.1, dans lequel ce serveur est placé. Les détails du stockage et de l'image sont volontairement reportés à l'Unité 4.2, de sorte qu'ici nous créons le serveur et définissons uniquement son nombre de cœurs, sa RAM, sa famille de CPU et ses informations d'identification.

Objectif de construction : Provisionner un serveur shell Dedicated Core (classe, cœurs/RAM, informations d'identification).

Étapes (dans Data Center Designer) :

1. Ouvrir le VDC FinCorp de l'Unité 3.1 dans le Workspace. La procédure ci-dessous s'applique au mode Canvas ; si aucun centre de données n'existe encore, en créer un d'abord.
2. À partir de la Palette, glisser un élément de serveur Dedicated Core sur le Canvas pour l'ajouter au VDC.
3. Sélectionner le nouveau serveur pour ouvrir le volet Inspector à droite, et lui donner un nom unique au sein du VDC (c'est son identité pour le reste du module).
4. Définir l'architecture / famille de CPU. Sur Dedicated Core, cela est sélectionnable ; fixer la famille sur laquelle la couche est standardisée. Noter que le changement de famille ultérieurement nécessite un redémarrage, il faut donc choisir délibérément.
5. Définir les Cœurs et la RAM. Rester dans les limites de Dedicated Core (jusqu'à 62 cœurs, jusqu'à 230 Go de RAM ; la RAM est allouée par incréments de 0,25 Go). Dimensionner pour la charge de base de la couche, et non pour son pic, car la mise à l'échelle horizontale gérera les pics dans l'Unité 4.3.
6. Sous Authentification, définir le mot de passe root/administrateur et/ou attacher une clé SSH (en sélectionner une depuis le SSH Key Manager, ou coller une clé publique ad hoc). C'est ainsi que vous accéderez au serveur une fois qu'il aura démarré.
7. Laisser le stockage et l'image pour l'Unité 4.2 ; ne pas encore démarrer à partir d'une image. Cliquer sur Provision Changes pour appliquer, ce qui engage le serveur shell.

Erreurs courantes :

• Traiter la forme du réplique d'auto-mise à l'échelle comme un réglage d'exécution. La configuration de calcul du modèle de réplique (architecture de CPU, cœurs, RAM) est définie au moment de la conception et ne s'applique qu'aux nouvelles répliques ; il faut donc dimensionner et façonner la réplique délibérément avant que le groupe ne fonctionne (Unité 4.3).
• Traiter la famille de CPU comme un réglage en direct. La changer sur Dedicated Core nécessite un redémarrage ; planifier cela comme une maintenance programmée.
• Surdimensionner le shell pour son pic. Dimensionner la base Dedicated Core pour la charge en régime permanent et laisser la mise à l'échelle horizontale (Unité 4.3) absorber les pics, plutôt que de payer pour une seule VM de grande taille en permanence.
• Oublier qu'un serveur nouvellement provisionné avec plus de 8 Go de RAM peut ne pas démarrer proprement au tout premier démarrage tant que la mémoire de travail n'a pas été traitée ; c'est un comportement attendu, et non une défaillance.

Le point architectural que porte un attribut immuable est visible même dans une création CLI en une ligne : la famille de CPU et la classe sont définies à la création, et le changement de famille ultérieurement est une opération entraînant un redémarrage, et non une modification libre.

ionosctl server create --datacenter-id "$FINCORP_VDC" \
  --name fincorp-app-01 --cpu-family INTEL_SKYLAKE --cores 4 --ram 8192

Résumé

La classe de calcul sur IONOS CLOUD est une décision architecturale par niveau, guidée par quatre axes : l'isolation des cœurs, le contrôle de la famille de CPU, le rattachement de Block Storage et le modèle opérationnel. Dedicated Core est le choix par défaut lorsqu'un niveau nécessite une garantie de performance, un contrôle de la famille de CPU ou une éligibilité à la mise à l'échelle automatique gérée ; vCPU est l'option moins coûteuse lorsque la concurrence est acceptable ; et un Cube est une instance à modèle fixe dont le bundle vCPU/RAM/NVMe est immuable, mais qui peut tout de même rattacher du Block Storage en option. Déterminez la classe avant la dimensionnement, car les contraintes les plus déterminantes sont les permanentes, et provisionnez la coquille Dedicated Core comme fondation sur laquelle le reste du Module 4 s'appuie.

Points clés :

• Effectuez la décision à quatre volets (isolation, famille de CPU, rattachement du stockage bloc, modèle opérationnel) par niveau, et non par ensemble.
• VM Auto Scaling est uniquement horizontal : il ajoute et supprime des répliques entières selon une politique de métriques, et la configuration de calcul de la réplique est fixée dans le modèle de réplique au moment de la conception.
• Le modèle d'un Cube (vCPU, RAM, NVMe) est immuable et son NVMe ne peut pas être détaché, mais un Cube peut tout de même rattacher jusqu'à 23 périphériques Block Storage en option ; la contrainte est le modèle fixe, et non l'impossibilité d'utiliser Block Storage.
• Un changement de famille de CPU sur Dedicated Core nécessite un redémarrage ; considérez-le comme une maintenance planifiée.

Terminologie importante :

• Serveur Dedicated Core : une VM dotée d'un cœur physique exclusif (deux cœurs logiques), avec une famille de CPU sélectionnable.
• Serveur vCPU : une VM partageant des cœurs physiques ; économique, sans contrôle de la famille de CPU.
• Cube : une instance à modèle fixe avec un volume NVMe rattaché directement obligatoire ; les propriétés du modèle sont immuables après le provisionnement.
• Live Vertical Scaling (LVS) : l'augmentation ou la réduction des ressources d'une VM en cours d'exécution, abordée en détail dans l'Unité 4.3.

Lectures complémentaires

• Unité 4.2 : Images, disques et Cloud-Init (étend cette coquille de serveur).
• Unité 4.3 : Élasticité et VM Auto Scaling (comment cette couche se met à l'échelle horizontalement).
• Unité 2.4 : Architecture des coûts et FinOps (le modèle de concurrence comme premier levier de coût).