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

Introduction

La classe de calcul n'est pas une décision de taille ; c'est une décision architecturale, et sur IONOS Cloud elle est prise par niveau plutôt que par domaine. La classe que vous choisissez définit quatre choses à la fois : si la charge de travail obtient un noyau physique exclusif ou partagé, si vous pouvez épingler la famille CPU, si vous pouvez attacher un réseau Block Storage, et qui porte le modèle opérationnel. L'une de ces décisions est effectivement permanente (un modèle de Cube est immuable après la mise en service), donc choisir la bonne classe au moment de la conception est moins coûteux que toute solution de contournement ultérieure. Cette unité rend cette décision explicite sur les trois classes de calcul IONOS Cloud, puis se termine par la mise en service de l'enveloppe Dedicated Core que les unités 4.2 et 4.3 étendent avec un stockage, cloud-init et une mise à l'échelle automatique.

1. La décision de calcul à quatre voies

Chaque classe de calcul IONOS répond aux mêmes quatre questions de manière différente. Tenez ces quatre axes en tête et la classe se sélectionne presque d'elle-même.

Isolement du noyau. Un Dedicated Core Server est donné un noyau physique dédié, exposé au système d'exploitation invité comme deux noyaux logiques (un noyau physique avec Hyper-Threading présente deux threads). Un vCPU Server partage des noyaux physiques avec d'autres locataires. L'isolement achète des performances prévisibles en cas de contention ; le partage achète un prix inférieur. Il s'agit du modèle de contention que l'unité 2.4 a présenté comme le premier levier de coût, maintenant vu du côté du calcul.

Contrôle de la famille CPU. Seul Dedicated Core vous permet de sélectionner et de modifier par la suite la famille CPU (par exemple, en fixant AMD EPYC pour une charge de travail qui en bénéficie, ou en standardisant un niveau sur Intel Xeon). Sur un vCPU Server, la famille n'est pas sélectionnable. Cela est important lorsque une charge de travail est sensible aux différences d'ensemble d'instructions ou d'horloge par noyau, ou lorsque une licence est liée à une famille CPU.

Attachement du stockage sur blocs. Dedicated Core et les serveurs vCPU attachent des volumes de réseau Block Storage (le disque de démarrage et les disques de données vivent sur le tissu de blocs iSCSI, couvert dans l'unité 4.2). Un Cube est livré avec un NVMe Volume directement attaché obligatoire qui fait partie de son modèle fixe. Le modèle d'attachement décide de la façon dont vous effectuez le cycle de vie du stockage, les instantanés et la redimensionnement.

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

Le tableau suivant présente les trois classes par rapport aux axes qui déterminent la décision.

Un Dedicated Core Server peut être configuré jusqu'à 62 noyaux et 230 Go RAM. Le RAM est alloué en incréments de 0,25 Go. Ces plafonds lient rarement un seul niveau, mais ils sont importants lorsque vous dimensionnez un grand monolithe avant de décider s'il faut le diviser.

1.1 Dedicated Core : le paramètre par défaut pour les niveaux qui nécessitent 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 CPU. Le noyau physique exclusif est ce qui achète la garantie de performance sous contention, et le contrôle de la famille CPU est unique à cette classe. Lorsqu'un niveau sera également mis à l'échelle horizontalement, sa configuration de calcul de réplique (architecture CPU, noyaux et RAM) est définie à la conception dans le modèle de réplique VM Auto Scaling (unité 4.3), donc la fixation de la forme de calcul du niveau tôt paie encore. Le coût du noyau exclusif est le prix que vous payez pour la garantie de performance.

La sélection de la famille CPU sur Dedicated Core est réelle mais n'est pas gratuite : la modification de la famille sur un serveur existant nécessite un redémarrage. Traitez une modification de famille comme une opération de maintenance planifiée avec une fenêtre, et non comme un réglage en temps réel.

1.2 vCPU : rentable lorsque la contention est acceptable

Un vCPU Server est provisionné et se comporte comme n'importe quelle autre instance VM, mais partage des noyaux physiques, ce qui le rend rentable par défaut pour les environnements de développement et de test, les services logiciels internes essentiels et les niveaux où une contention occasionnelle est acceptable. Il prend en charge la mise à l'échelle verticale en temps réel comme Dedicated Core, mais ne peut pas sélectionner une famille CPU. La règle de décision est simple : si le niveau n'a besoin ni d'une garantie de performance ni de contrôle de la famille CPU, un vCPU Server est le choix correct et moins cher.

1.3 Cubes : l'instance à modèle fixe, et non une impasse de stockage

Un Cube est une instance à configuration fixe : vCPU, RAM et un NVMe Volume directement attaché viennent comme un modèle bundle, et vous ne pouvez pas modifier ces propriétés de modèle après la mise en service. Le NVMe Volume est connecté via PCI Express sur le serveur physique et est en RAID logiciel à simple redondance ; il occupe l'un des emplacements d'appareil de l'instance et ne peut pas être démonté ou supprimé tant que le Cube existe. Les modèles de base vont du Basic-Cube-XS (1 vCPU, 2 Go RAM, 60 Go NVMe) au Basic-Cube-XL (16 vCPU, 32 Go RAM, 960 Go NVMe) ; les modèles de mémoire échangent des noyaux pour du RAM (par exemple, Memory-Cube-XL à 16 vCPU et 64 Go RAM).

Voici le piège, et il fonctionne à l'opposé d'une hypothèse courante. Un Cube est souvent rejeté comme incapable d'utiliser des Block Storage. C'est faux : un Cube prend en charge jusqu'à 23 appareils HDD ou SSD (Standard ou Premium) Block Storage supplémentaires en plus de son NVMe Volume obligatoire, et ces appareils supplémentaires peuvent être démontés et supprimés à tout moment après la mise en service. La véritable contrainte est différente et plus spécifique : le modèle lui-même (vCPU, RAM et taille NVMe) est immuable, et le NVMe Volume ne peut pas être détaché. La suppression d'un Cube supprime son NVMe Volume, donc prenez d'abord un Snapshot si les données doivent survivre. La règle de conception honnête est donc : choisissez un Cube lorsque son bundle fixe correspond à la charge de travail et que vous voulez une ligne de compte unique prévisible, et planifiez des données persistantes sur des volumes Block Storage supplémentaires qui survivent au modèle, et non sur le disque NVMe immuable.

2. Class-Per-Tier comme modèle

L'unité de la décision de classe de calcul est le niveau, et non l'application. Un design d'entreprise en couches (la forme publique-L7-à-stateless-compute-à-privé-L4-à-privé-données de l'Unité 1.2) mélange régulièrement les classes : Dedicated Core pour le niveau qui doit être mis à l'échelle et garantir les performances, vCPU pour les niveaux internes ou non critiques, et un Cube où un forfait fixe est une solution propre. Lorsqu'une charge de travail nécessite une plateforme gérée à locataire unique (par exemple, un domaine réglementé VMware), c'est la plateforme dédiée VMware Private Cloud traitée dans l'Unité 4.4, et non une classe de calcul Public Cloud. Le mélange de classes par niveau est la norme, et non un compromis.

Deux règles de conception découlent de ceci et valent la peine d'être énoncées clairement, car les deux sont faciles à mal interpréter sous pression :

• 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 un changement de modèle ne s'applique qu'aux répliques créées par la suite, donc la forme de la réplique est une décision de conception plutôt qu'un réglage en direct (Unité 4.3).
• Un changement de famille CPU est une opération planifiée. Il est disponible sur Dedicated Core mais nécessite un redémarrage, il appartient donc à une fenêtre de maintenance, et non à un livre de recettes de réglage en direct.

Pour FinCorp, la société financière réglementée allemande qui traverse ce cours, le niveau d'application orienté client est celui qui est le plus susceptible de subir une charge variable et celui qui est le plus exposé au répartiteur de charge publique de la couche 7. Ce niveau est provisionné en tant que Dedicated Core pour une garantie de performances prévisible sous charge, donc sa famille CPU peut être standardisée pour des performances cohérentes, et c'est le niveau qui sera plus tard mis à l'échelle horizontalement sous une politique de métrique (Unité 4.3). Le niveau de rapport de traitement par lots interne de FinCorp, en revanche, tolère les conflits et est provisionné en tant que vCPU pour économiser les coûts. L'angle de conformité renforce ceci : BSI C5 (l'attestation de type 1 du 7 novembre 2023) et IT-Grundschutz (le certificat ISO 27001 du 14 septembre 2022) ont tous deux pour portée Compute Engine, donc les classes standard VM se situent à l'intérieur de l'enveloppe d'attestation de FinCorp. Le domaine réglementé VMware est une décision distincte traitée par la plateforme dédiée VMware Private Cloud dans l'Unité 4.4.

Considérations de conception

• Coût. Le cœur exclusif de Dedicated Core est le prix premium que vous payez pour une garantie de performance et une éligibilité à la mise à l'échelle automatique. Lorsque ni l'un ni l'autre n'est requis, vCPU est la réponse correcte moins chère ; n'achetez pas l'isolement dont un niveau n'a pas besoin.
• Opérations. La décision permanente (un modèle immutable d'un Cube) comporte le coût opérationnel le plus élevé lorsqu'elle est incorrecte, car la corriger signifie reconstruire plutôt que reconfigurer. Accordez le plus de soin de conception ici.
• Évolutivité. La mise à l'échelle verticale (la croissance en direct de CPU et RAM) est disponible sur Dedicated Core et vCPU dans les limites couvertes à l'unité 4.3 ; la mise à l'échelle horizontale gérée ajoute et supprime des répliques entières sous une politique de métrique, avec la configuration de calcul de réplique fixée dans le modèle de réplique au moment de la conception. Déterminez sur quel axe un niveau va mettre à l'échelle avant de choisir sa classe.

DCD Marche à suivre pour la mise en œuvre

Cette marche à suivre met en place le shell Dedicated Core Server que le REST du Module 4 étend. Elle réalise la décision de conception ci-dessus pour le niveau client de FinCorp : une classe Dedicated Core pour une garantie de performance prévisible et donc sa famille CPU est sous notre contrôle. Le prérequis est le centre de données virtuel de FinCorp créé dans l'Unité 3.1, dans lequel ce serveur est placé. Les détails de stockage et d'image sont délibérément reportés à l'Unité 4.2, nous créons donc ici le serveur et définissons uniquement son noyau, RAM, famille CPU et informations d'identification.

Objectif de construction : Mettre en place un shell Dedicated Core Server (classe, noyaux/RAM, informations d'identification).

Étapes (dans le Data Center Designer) :

1. Ouvrez le centre de données virtuel de FinCorp de l'Unité 3.1 dans l'espace de travail. La procédure ci-dessous s'applique au mode Canvas ; si aucun centre de données n'existe encore, créez-en un d'abord.
2. À partir de la Palette, faites glisser un élément de serveur Dedicated Core sur le Canvas pour l'ajouter au centre de données virtuel.
3. Sélectionnez le nouveau serveur pour ouvrir le volet Inspector sur la droite, et donnez-lui un nom unique dans le centre de données virtuel (il s'agit de son identité pour le REST du module).
4. Définissez l'architecture/famille CPU. Sur Dedicated Core, celle-ci est sélectionnable ; épinglez la famille sur laquelle le niveau est standardisé. Notez que la modification de la famille plus tard nécessite un redémarrage, choisissez donc délibérément.
5. Définissez les noyaux et le RAM. Restez dans les limites de Dedicated Core (jusqu'à 62 noyaux, jusqu'à 230 Go RAM ; le RAM est alloué par incréments de 0,25 Go). Dimensionnez pour la ligne de base du niveau, et non pour son pic, car la mise à l'échelle horizontale gérera les pics dans l'Unité 4.3.
6. Sous Authentification, définissez le mot de passe Root/administrateur et/ou attachez une clé SSH (sélectionnez-en une dans le SSH Key Manager, ou collez une clé publique ad hoc). C'est ainsi que vous accéderez au serveur une fois qu'il sera démarré.
7. Laissez le stockage et l'image pour l'Unité 4.2 ; ne démarrez pas encore à partir d'une image. Cliquez sur Provision Changes pour appliquer, ce qui valide le shell du serveur.

Erreurs courantes :

• Traiter la forme de réplica à mise à l'échelle automatique comme un réglage à l'exécution. La configuration de calcul du modèle de réplica (architecture CPU, noyaux, RAM) est définie au moment de la conception et s'applique uniquement aux nouvelles répliques, dimensionnez donc le modèle de réplica délibérément avant que le groupe ne s'exécute (Unité 4.3).
• Traiter la famille CPU comme un réglage à l'exécution. La modification de celle-ci sur Dedicated Core nécessite un redémarrage ; planifiez-la comme une maintenance planifiée.
• Surdimensionner le shell pour son pic. Dimensionnez la ligne de base de Dedicated Core pour la charge d'état stable et laissez la mise à l'échelle horizontale (Unité 4.3) absorber les pics, plutôt que de payer pour un seul VM permanent de grande taille.
• Oublier qu'un serveur fraîchement provisionné avec plus de 8 Go RAM peut ne pas démarrer proprement au premier démarrage jusqu'à ce que la mémoire de travail soit traitée ; il s'agit d'un comportement attendu, et non d'une erreur.

Le point architectural qu'un attribut immuable porte est visible même dans une commande CLI à une ligne : la famille CPU et la classe sont définies lors de la création, et la modification de la famille plus tard est une opération qui nécessite un redémarrage, et non une édition gratuite.

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'isolement du noyau, le contrôle de la famille CPU, l'attachement de Block Storage et le modèle opérationnel. Dedicated Core est le paramètre par défaut lorsque un niveau nécessite une garantie de performance, un contrôle de la famille CPU ou une éligibilité pour le scaling automatique géré ; vCPU est le choix moins coûteux lorsque la contention est acceptable ; et un Cube est une instance à modèle fixe dont le bundle vCPU/RAM/NVMe est immuable, mais qui peut toujours attacher des Block Storage supplémentaires. Déterminez la classe avant de dimensionner, car les contraintes les plus conséquentes sont les permanentes, et provisionnez le shell Dedicated Core comme base sur laquelle le REST du Module 4 est construit.

Points clés :

• Exécutez la décision à quatre voies (isolement, famille CPU, attachement de stockage sur bloc, modèle opérationnel) par niveau, et non par domaine.
• VM Auto Scaling est uniquement horizontal : il ajoute et supprime des répliques entières sous une politique de métrique, et la configuration de calcul de 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 toujours attacher jusqu'à 23 appareils Block Storage supplémentaires ; la contrainte est le modèle fixe, et non une incapacité à utiliser Block Storage.
• Un changement de famille CPU sur Dedicated Core nécessite un redémarrage ; traitez-le comme une maintenance planifiée.

Terminologie importante :

• Dedicated Core Server : un VM qui se voit attribuer un noyau physique exclusif (deux noyaux logiques), avec une famille CPU sélectionnable.
• vCPU Server : un VM partageant des noyaux physiques ; rentable, sans contrôle de la famille CPU.
• Cube : une instance à modèle fixe avec un stockage direct NVMe Volume obligatoire ; les propriétés du modèle sont immuables après la mise en service.
• Live Vertical Scaling (LVS) : croissance ou réduction des ressources d'un VM en cours d'exécution, couvert en profondeur dans l'Unité 4.3.

Lecture supplémentaire

• Unité 4.2 : Images, disques et Cloud-Init (étend ce shell de serveur).
• Unité 4.3 : Élasticité et VM Auto Scaling (comment ce niveau mise à l'échelle horizontalement).
• Unité 2.4 : Architecture de coût et FinOps (le modèle de contention comme premier levier de coût).