Unité 4.2 : Images, disques et Cloud-Init
Introduction
Un shell de serveur est inerte jusqu'à ce qu'il dispose d'un disque pour démarrer et d'un moyen de se configurer au premier démarrage. Deux propriétés du disque (son type de stockage et sa zone de disponibilité) sont fixées lors de la mise en service et ne peuvent pas être modifiées par la suite, ce qui fait que la disposition du disque est une décision de conception plutôt qu'une décision à l'exécution. Cette unité étend le Dedicated Core Server de l'Unité 4.1 : elle attache un stockage, associe une image de démarrage et fournit des données d'utilisateur cloud-init afin que le serveur arrive configuré plutôt qu'à l'état brut. Elle ne répète pas la création de serveur.
1. Block Storage Niveaux et le plancher de performance
IONOS Block Storage est un iSCSI Block Storage connecté au réseau, répliqué en mode actif-actif sur deux serveurs de stockage avec RAID à l'intérieur de chacun (quatre copies physiques au total) dans une région. Il est disponible en trois niveaux, et le niveau est l'une des deux propriétés de disque que vous ne pouvez pas modifier plus tard, il est donc choisi à l'avance pour chaque disque.
La performance documentée par Volume est la base pour faire correspondre le niveau au modèle d'accès :
| Performance de stockage | SSD Premium | SSD Standard |
|---|---|---|
| Vitesse de lecture/écriture, séquentielle | 1 Mo/s par Go à une taille de bloc de 1 Mo | 0,5 Mo/s par Go à une taille de bloc de 1 Mo |
| Vitesse de lecture, aléatoire complet | 75 IOPS par Go à une taille de bloc de 4 Ko | 40 IOPS par Go à une taille de bloc de 4 Ko |
| Vitesse d'écriture, aléatoire complet | 50 IOPS par Go à une taille de bloc de 4 Ko | 30 IOPS par Go à une taille de bloc de 4 Ko |
| Performance de stockage | HDD Stockage |
|---|---|
| Vitesse de lecture/écriture, séquentielle | 200 Mo/s à une taille de bloc de 1 Mo |
| Vitesse de lecture/écriture, aléatoire complet, régulier | 1 100 IOPS à une taille de bloc de 4 Ko |
| Vitesse de lecture/écriture, aléatoire complet, en rafale | 2 500 IOPS à une taille de bloc de 4 Ko |
Deux faits déterminent la décision de niveau. Premièrement, la performance de HDD est statique et indépendante de la taille de Volume, alors que la performance de SSD évolue avec la taille de Volume : les taux par Go ci-dessus signifient qu'un petit SSD est un SSD lent. Deuxièmement, IONOS recommande de réserver des volumes SSD d'au moins 100 Go pour bénéficier de la pleine performance ; en dessous de ce plancher, la performance est sous-optimale, ce qui explique pourquoi les volumes SSD inférieurs à environ 100 Go ne sont pas recommandés pour les charges de travail de base de données. Pour un SSD Volume, le système prédit la performance en fonction de la taille, et pour les volumes supérieurs à 600 Go, les taux par Volume sont limités aux maximums documentés (un SSD Premium Volume atteint un maximum de 45 000 lectures IOPS et 600 Mo/s séquentiel par VM, étant donné suffisamment de cœurs et de RAM sur le VM).
La règle de disposition pratique suit directement. Utilisez HDD pour les données froides ou séquentielles (sauvegardes, archives, journaux préparés pour l'exportation) où son débit indépendant de la taille est acceptable et son coût de 0,04 EUR par Go par mois est le moins cher. Utilisez SSD Standard (0,07 EUR par Go par mois) pour les charges de travail générales, et SSD Premium (0,15 EUR par Go par mois) pour les disques sensibles à la latence et les bases de données, en gardant toute base de données Volume à ou au-dessus du plancher de 100 Go afin qu'elle se situe dans la bande de performance complète. Les volumes vont de 1 GiB à 4096 GiB (4 To) ; un VM peut être attaché à jusqu'à 24 volumes HDD ou SSD Standard, mais seulement 4 volumes SSD Premium, ce qui est une contrainte à vérifier avant de déployer une disposition de données à haut niveau. Les niveaux peuvent être mélangés sur un VM, donc un modèle courant est un disque de démarrage/données SSD Premium modeste avec des volumes HDD pour le bulk.
2. Images, immutabilité et verrouillage de région
Un disque devient amorçable en associant une image à celui-ci : une image publique fournie par IONOS (les distributions Linux, y compris Alma, Debian, Rocky et Ubuntu, ainsi que les images Microsoft), ou votre propre image privée téléchargée via FTPS. Les images privées Images & Snapshots sont verrouillées en région : elles sont utilisables dans la région où elles ont été téléchargées ou créées, et IONOS ne crée pas de redondance inter-régionale pour elles. Si une charge de travail doit exister dans deux régions, l'image est téléchargée ou copiée dans chaque région ; il n'y a pas de réplication gérée d'images inter-régionales sur laquelle s'appuyer.
Deux propriétés de stockage sont immuables après la mise en service et doivent être correctes dès le départ :
- Type de stockage. Vous ne pouvez pas modifier un Volume entre HDD, SSD Standard et SSD Premium après sa mise en service. Un changement de niveau signifie la création d'un nouveau Volume et la migration des données.
- Zone de disponibilité. La zone du Volume est fixée lors de sa création ; la sélection de « Auto » permet au système d'attribuer la zone optimale. Notez l'asymétrie héritée de l'unité 1.2 et reprise dans le module 5 : Block Storage propose les zones 1, 2, 3 et « Auto », tandis que le calcul ne propose que les zones 1, 2 et « Auto ». La zone 3 de Block Storage existe ; la zone 3 de calcul n'existe pas.
La taille du Volume, en revanche, peut être augmentée après la mise en service (même sur un serveur en cours d'exécution, si le système d'exploitation le prend en charge) mais ne peut jamais être réduite. La posture de dimensionnement sécurisée consiste donc à commencer de manière conservatrice et à grandir, et non à surdimensionner un disque que l'on ne peut pas réduire. Les instantanés, le mécanisme de restauration au niveau VM, sont également locaux et non incrémentiels : un Snapshot couvre la capacité allouée totale du Volume (un Volume de 100 Go contenant 10 Go de données produit toujours un Snapshot de 100 Go) et constitue un outil de restauration, et non une sauvegarde de base de données. Leur rôle dans le plan de continuité des données est abordé dans le module 5.
3. Cloud-Init pour la configuration du premier démarrage
Cloud-init est le mécanisme qui transforme un serveur Linux fraîchement démarré à partir d'une image bare en un Node configuré sans connexion manuelle. Vous fournissez des données utilisateur au moment de la création, et cloud-init les applique lors du premier démarrage. La limite de capacité est précise et vaut la peine d'être mentionnée : cloud-init est entièrement pris en charge sur toutes les images publiques d'IONOS Linux, et l'injection de clé SSH s'applique aux images publiques d'IONOS Cloud Linux. Il n'est pas pris en charge sur Windows. Pour la configuration du premier démarrage de Windows, vous utilisez un mécanisme différent, et non cloud-init.
Les données utilisateur sont écrites sous forme de script shell ou de cloud-config YAML, et IONOS cloud-init accepte plusieurs formats, notamment un script de données utilisateur (commençant par #! ou Content-Type: text/x-shellscript), des données de cloud-config (commençant par #cloud-config), un fichier d'inclusion, un travail upstart, un cloud boothook, et des charges utiles codées en base64 (que cloud-init décode et traite ensuite comme l'un des types pris en charge). Sur la ressource Volume, les données utilisateur de cloud-init sont définies au moment de la création de Volume et sont immuables par la suite, ce qui est cohérent avec le traitement de la configuration du premier démarrage comme faisant partie de la mise en service plutôt que d'une édition ultérieure. Lorsque vous devez déboguer ce que cloud-init a fait, les journaux se trouvent à /var/log/cloud-init-output.log et /var/log/cloud-init.log.
Un cloud-config minimal qui crée l'utilisateur de l'application FinCorp et installe un paquet au premier démarrage illustre la forme ; le point architectural est que cela s'exécute exactement une fois, au premier démarrage, et est fixé sur la ressource Volume à la création :
#cloud-config
packages:
- nginx
runcmd:
- systemctl enable --now nginx
DCD Marche à suivre pour la mise en œuvre
Ce tutoriel prolonge le Dedicated Core Server provisionné dans l'Unité 4.1. Il attache un disque de démarrage Volume sur le bon niveau de stockage, associe une image Linux et fournit des données d'utilisateur cloud-init afin que le serveur d'application FinCorp arrive configuré. Le prérequis est le shell de serveur de l'Unité 4.1 dans le VDC FinCorp. Ne recréez pas le serveur.
Objectif de construction : Attacher et configurer le stockage ; fournir des données d'utilisateur cloud-init.
Étapes (dans le Data Center Designer) :
- Dans l'Espace de travail, sélectionnez le Dedicated Core Server de l'Unité 4.1. À partir de la Palette, faites glisser un élément de stockage (HDD ou SSD) sur le serveur pour le connecter ; le serveur s'étend pour afficher une section de stockage.
- Sélectionnez le nouvel élément de stockage pour ouvrir l'Inspecteur. Donnez-lui un nom unique au VDC.
- Choisissez le type de stockage (pour le disque de démarrage/données de l'application FinCorp, SSD Premium). Cela est immuable après la mise en service, donc confirmez le niveau maintenant.
- Définissez la Zone de disponibilité (Auto permet au système d'attribuer la zone optimale). Cela est également immuable après la mise en service.
- Définissez la Taille, en gardant un disque SSD Volume à ou au-dessus du plancher de ~100 Go pour une performance complète. La taille peut être augmentée plus tard, mais jamais réduite.
- Sous Image, associez une image : choisissez une image publique Linux IONOS, ou sélectionnez des images personnelles pour une image privée téléchargée. Définissez le mot de passe Root/administrateur (obligatoire pour l'accès à la Console à distance) et/ou une clé SSH.
- Marquez le Volume comme périphérique de démarrage (cliquez sur BOOT / Définir comme périphérique de démarrage) afin que le serveur démarre à partir de celui-ci.
- Étendez le champ cloud-init / user-data et collez le script cloud-config ou user-data. Confirmez que l'image prend en charge cloud-init. Cliquez sur Mettre en service les modifications pour appliquer.
Erreurs courantes :
- Choisir le mauvais type de stockage ou la mauvaise zone, qui sont tous deux immuables. Un changement de niveau ou un déplacement de zone signifie reconstruire le Volume, et non l'éditer.
- Mettre une base de données sur un disque SSD Volume inférieur à 100 Go. En dessous du plancher, le SSD fonctionne à une vitesse IOPS sous-optimale ; gardez les volumes de base de données à ou au-dessus de 100 Go.
- S'attendre à ce que cloud-init soit disponible sur les Windows. Cloud-init est destiné aux images publiques Linux ; l'injection de clé SSH est limitée aux images publiques IONOS Cloud Linux.
- Supposer qu'une image est disponible partout. Les images privées Images & Snapshots sont verrouillées par région ; téléchargez-les ou copiez-les dans chaque région dont vous avez besoin.
- Surprovisionner un disque pour être en sécurité. Les volumes peuvent augmenter, mais jamais diminuer, donc commencez de manière conservatrice et augmentez plus tard.
Résumé
Un serveur devient utile lorsqu'il dispose d'un disque et d'une configuration de premier démarrage. Le Block Storage est disponible en trois niveaux dont les performances et les prix diffèrent, avec des performances SSD qui varient en fonction de la taille et un plancher d'environ 100 Go qui exclut les petits SSD (et donc les petits disques de base de données) de la bande de performances complète. Le type de stockage et la zone de disponibilité sont immuables après la mise en service, tandis que la taille peut augmenter mais jamais diminuer, donc la disposition du disque est une décision de conception. Les images sont verrouillées par région sans réplication gérée entre régions, et cloud-init configure les images publiques Linux au premier démarrage (et non Windows), définies une fois sur le Volume lors de la création. Le didacticiel étend le serveur de l'unité 4.1 en une application FinCorp configurée Node.
Points clés :
- Les performances HDD sont indépendantes de la taille ; les performances SSD varient en fonction de la taille, donc un petit SSD est un SSD lent et les volumes de base de données appartiennent à ou au-dessus d'environ 100 Go.
- Le type de stockage et la zone de disponibilité sont immuables après la mise en service ; la taille augmente mais ne diminue jamais.
- Le Block Storage a des zones 1, 2, 3 et Auto ; le calcul n'a que des zones 1, 2 et Auto.
- Les Images & Snapshots sont verrouillés par région, sans réplication gérée entre régions.
- Cloud-init configure les images publiques Linux au premier démarrage (injection de clé SSH sur les images publiques IONOS Linux) ; il n'est pas pris en charge sur Windows, et les données utilisateur sont fixes sur le Volume lors de la création.
Terminologie importante :
- Plancher de performances SSD : le minimum d'environ 100 Go en dessous duquel un SSD Volume fonctionne à des performances IOPS sous-optimales ; la raison pour laquelle les petits disques de base de données sont découragés.
- Cloud-init : le mécanisme de configuration de premier démarrage pour les images publiques Linux, fourni en tant que données utilisateur et appliqué une fois au démarrage.
- Image verrouillée par région : une image privée ou Snapshot utilisable uniquement dans la région où elle a été téléchargée ou créée.
Lecture supplémentaire
- Unité 4.1 : Sélection de la classe de calcul (le serveur que cette unité étend).
- Unité 5.7 : Protection et cycle de vie des données (instantanés, sauvegarde, et PITR composés en un plan de continuité).
- Unité 7.3 : Ingénierie de performance (planchers de performance de stockage en tant que levier de latence).