12 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Associer un niveau de Block Storage (HDD, SSD Standard, SSD Premium) à un motif d'accès, et d'expliquer pourquoi le seuil de 100 Go pour les SSD modifie le calcul pour les disques de démarrage et de données.
  • Identifier les attributs de stockage qui sont immuables après le provisionnement (type de stockage et zone de disponibilité) et de concevoir en tenant compte de ces contraintes.
  • Utiliser les données utilisateur cloud-init pour configurer un serveur Linux au premier démarrage, et d'indiquer où cloud-init s'applique et où il ne s'applique pas.
  • Attacher et configurer le stockage sur le serveur de l'Unité 4.1, associer une image, et fournir des données utilisateur cloud-init dans Data Center Designer.

Unité 4.2 : Images, disques et Cloud-Init

Introduction

Une coquille de serveur est inerte tant qu'elle ne dispose pas d'un disque de démarrage et d'un moyen de se configurer lors de la première mise en route. Deux propriétés du disque (son type de stockage et sa zone de disponibilité) sont fixées lors de la provision et ne peuvent pas être modifiées par la suite, ce qui fait de la configuration du disque une décision de conception plutôt qu'une décision d'exécution. Cette unité prolonge le serveur Dedicated Core de l'unité 4.1 : elle attache du stockage, associe une image de démarrage et fournit des données utilisateur cloud-init afin que le serveur arrive configuré plutôt qu'à l'état brut. Elle ne répète pas la création du serveur.

1. Niveaux de Block Storage et le seuil de performance

IONOS CLOUD Block Storage est un stockage de blocs iSCSI attaché 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) au sein d'une région. Il est disponible en trois niveaux, et le niveau est l'une des deux propriétés du disque que vous ne pouvez pas modifier ultérieurement, il est donc choisi à l'avance pour chaque disque.

Les performances par Volume documentées sont la base pour associer le niveau au motif d'accès :

Performance de stockage SSD Premium SSD Standard
Vitesse de lecture/écriture, séquentielle 1 Mo/s par Go avec une taille de bloc de 1 Mo 0,5 Mo/s par Go avec une taille de bloc de 1 Mo
Vitesse de lecture, aléatoire complète 75 IOPS par Go avec une taille de bloc de 4 Ko 40 IOPS par Go avec une taille de bloc de 4 Ko
Vitesse d'écriture, aléatoire complète 50 IOPS par Go avec une taille de bloc de 4 Ko 30 IOPS par Go avec une taille de bloc de 4 Ko
Performance de stockage Stockage HDD
Vitesse de lecture/écriture, séquentielle 200 Mo/s avec une taille de bloc de 1 Mo
Vitesse de lecture/écriture, aléatoire complète, régulière 1 100 IOPS avec une taille de bloc de 4 Ko
Vitesse de lecture/écriture, aléatoire complète, en rafale 2 500 IOPS avec une taille de bloc de 4 Ko

Deux faits guident la décision de stratification. Premièrement, les performances des HDD sont statiques et indépendantes de la taille du Volume, tandis que les performances des SSD évoluent avec la taille du Volume : les taux par Go ci-dessus signifient qu'un petit SSD est un SSD lent. Deuxièmement, IONOS CLOUD recommande de réserver des Volumes SSD d'au moins 100 Go pour en tirer pleinement parti ; en dessous de ce seuil, les performances sont sous-optimales, c'est 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 Volume SSD, le système prédit les performances à partir de la taille, et pour les Volumes supérieurs à 600 Go, les taux par Volume sont limités aux maxima documentés (un Volume SSD Premium atteint un maximum de 45 000 IOPS en lecture et 600 Mo/s en séquentiel par Volume, à condition de disposer d'un nombre suffisant de cœurs et de RAM sur la VM).

La règle de disposition pratique en découle directement. Utilisez les HDD pour les données froides ou séquentielles (sauvegardes, archives, journaux préparés pour l'export) où son débit indépendant de la taille est suffisant et où son tarif 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 disques de base de données, en maintenant tout Volume de base de données à ou au-dessus du seuil de 100 Go afin qu'il se situe dans la bande de pleine performance. Les Volumes vont de 1 Gio à 4096 Gio (4 Tio) ; une VM peut attacher 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 de haut niveau. Les niveaux peuvent être mélangés sur une seule VM, donc un schéma courant consiste en un disque de démarrage/de données SSD Premium modeste plus des Volumes HDD pour les données volumineuses.

2. Images, immuabilité et verrouillage par région

Un disque devient amorçable en lui associant une image : une image publique fournie par IONOS CLOUD (distributions Linux, notamment Alma, Debian, Rocky et Ubuntu, ainsi que des images Microsoft), ou une image privée personnelle téléchargée via FTPS. Les images privées et les instantanés sont verrouillés par région : ils ne sont utilisables que dans la région où ils ont été téléchargés ou créés, et IONOS CLOUD n'assure pas de redondance inter-régions pour ceux-ci. Si une charge de travail doit exister dans deux régions, l'image est téléchargée ou copiée dans chacune d'elles ; il n'existe pas de réplication inter-régions gérée des images sur laquelle s'appuyer.

Deux propriétés de stockage sont immuables après le provisionnement et doivent donc être correctes dès le départ :

  • Type de stockage. Il est impossible de modifier le type d'un volume entre HDD, SSD Standard et SSD Premium après son provisionnement. Un changement de gamme implique de créer un nouveau volume et de migrer les données.
  • Zone de disponibilité. La zone du volume est fixée à la 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 réexaminée 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 du calcul n'existe pas.

La taille du volume, en revanche, peut être augmentée après le provisionnement (même sur un serveur en cours d'exécution, si le système d'exploitation le prend en charge), mais jamais réduite. L'approche prudente en matière de dimensionnement consiste donc à commencer de manière conservatrice et à augmenter progressivement, plutôt que de surdimensionner un disque qui ne peut pas être réduit. Les instantanés, mécanisme de retour arrière au niveau de la VM, sont également locaux à la région et non incrémentiels : un instantané couvre l'intégralité de la capacité allouée au volume (un volume de 100 Go contenant 10 Go de données génère toujours un instantané de 100 Go) et constitue un outil de retour arrière, 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 au premier démarrage

Cloud-init est le mécanisme qui transforme un serveur Linux nouvellement démarré, à partir d'une image vierge, en un nœud configuré sans connexion manuelle. Vous fournissez les données utilisateur au moment de la création, et cloud-init les applique lors du premier démarrage. La portée des fonctionnalités est précise et mérite d'être soulignée : cloud-init est entièrement pris en charge sur toutes les images Linux publiques d'IONOS CLOUD, et l'injection de clés SSH s'applique aux images Linux publiques d'IONOS CLOUD. Il n'est pas pris en charge sur Windows. Pour la configuration au 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 YAML cloud-config, et cloud-init d'IONOS CLOUD accepte plusieurs formats, y compris un script user-data (commençant par #! ou Content-Type: text/x-shellscript), des données cloud-config (commençant par #cloud-config), un fichier d'inclusion, un travail upstart, un cloud boothook, et des charges utiles encodées en base64 (que cloud-init décode puis traite comme l'un des types pris en charge). Sur la ressource volume, les données utilisateur cloud-init sont définies lors de la création du volume et sont immuables par la suite, ce qui est cohérent avec le fait de considérer la configuration au premier démarrage comme faisant partie de la provisionnement plutôt que d'une modification ultérieure. Lorsque vous devez déboguer ce que cloud-init a fait, les journaux se trouvent dans /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 structure ; le point architectural est que cela s'exécute exactement une fois, au premier démarrage, et est fixé sur le volume lors de la création :

#cloud-config
packages:
  - nginx
runcmd:
  - systemctl enable --now nginx

Déroulement de la mise en œuvre de DCD

Ce déroulement prolonge le serveur Dedicated Core provisionné dans l'Unité 4.1. Il attache un Volume de démarrage sur le niveau de stockage approprié, associe une image Linux et fournit des données utilisateur cloud-init afin que le serveur d'application FinCorp soit livré préconfiguré. Le prérequis est le serveur de base 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 utilisateur cloud-init.

Étapes (dans Data Center Designer) :

  1. Dans l'Espace de travail, sélectionnez le serveur Dedicated Core de l'Unité 4.1. Depuis la Palette, faites glisser un élément de stockage (HDD ou SSD) sur le serveur pour l'y connecter ; le serveur se déploie pour afficher une section de stockage.
  2. Sélectionnez le nouvel élément de stockage pour ouvrir l'Inspecteur. Donnez-lui un nom unique dans le VDC.
  3. Choisissez le type de stockage (pour le disque de démarrage/données de l'application FinCorp, SSD Premium). Cette caractéristique est immuable après le provisionnement, donc confirmez le niveau maintenant.
  4. Définissez la Zone de disponibilité (Auto permet au système d'assigner la zone optimale). Cette caractéristique est également immuable après le provisionnement.
  5. Définissez la Taille, en maintenant un Volume SSD à ou au-dessus du seuil d'environ 100 Go pour des performances optimales. La taille peut être augmentée ultérieurement, mais jamais réduite.
  6. Sous Image, associez une image : choisissez une image Linux publique IONOS CLOUD, ou sélectionnez Own Images pour une image privée téléversée. Définissez le Mot de passe racine/administrateur (requis pour l'accès à la console distante) et/ou une clé SSH.
  7. Marquez le Volume comme périphérique de démarrage (cliquez sur BOOT / Make Boot Device) afin que le serveur démarre à partir de celui-ci.
  8. Dépliez le champ cloud-init / user-data et collez le script cloud-config ou user-data. Confirmez que l'image signale la prise en charge de cloud-init. Cliquez sur Provision Changes pour appliquer.

Erreurs courantes :

  • Choisir le mauvais type de stockage ou la mauvaise zone, les deux étant immuables. Un changement de niveau ou un déplacement de zone implique de reconstruire le Volume, et non de le modifier.
  • Placer une base de données sur un Volume SSD de moins de 100 Go. En dessous du seuil, le SSD fonctionne avec des IOPS sous-optimaux ; maintenez les Volumes de base de données à ou au-dessus de 100 Go.
  • S'attendre à cloud-init sur Windows. Cloud-init est destiné aux images Linux publiques ; l'injection de clés SSH est limitée aux images Linux publiques IONOS CLOUD.
  • Supposer qu'une image est disponible partout. Les images privées et les instantanés sont verrouillés par région ; téléversez-les ou copiez-les dans chaque région dont vous avez besoin.
  • Sur-provisionner un disque par sécurité. Les Volumes peuvent augmenter mais jamais diminuer, donc commencez de manière conservatrice et augmentez-les plus tard.

Résumé

Un serveur devient utile lorsqu'il dispose d'un disque et d'une configuration au premier démarrage. Block Storage est proposé en trois niveaux dont les performances et les prix diffèrent, avec des performances SSD qui évoluent en fonction de la taille et un seuil d'environ 100 Go qui exclut les petits SSD (et donc les petits disques de base de données) de la plage de performances optimales. Le type de stockage et la zone de disponibilité sont immuables après le provisionnement, tandis que la taille peut augmenter mais jamais diminuer, ce qui en fait une décision de conception. Les images sont verrouillées par région, sans réplication inter-régions gérée, et cloud-init configure les images Linux publiques au premier démarrage (et non Windows), en étant défini une seule fois sur le volume lors de sa création. Le guide pratique étend le serveur de l'Unité 4.1 en un nœud d'application FinCorp configuré.

Points clés :

  • Les performances des HDD sont indépendantes de la taille ; les performances des SSD évoluent avec la taille, de sorte qu'un petit SSD est un SSD lent et que les volumes de base de données doivent être d'environ 100 Go ou plus.
  • Le type de stockage et la zone de disponibilité sont immuables après le provisionnement ; la taille augmente mais ne diminue jamais.
  • Block Storage propose les zones 1, 2, 3 et Auto ; le calcul ne propose que les zones 1, 2 et Auto.
  • Les images et les instantanés sont verrouillés par région, sans réplication inter-régions gérée.
  • Cloud-init configure les images Linux publiques au premier démarrage (injection de clé SSH sur les images Linux publiques d'IONOS CLOUD) ; il n'est pas pris en charge sur Windows, et les données utilisateur sont figées sur le volume lors de sa création.

Terminologie importante :

  • Seuil de performance SSD : le minimum d'environ 100 Go en dessous duquel un volume SSD fonctionne avec des IOPS sous-optimaux ; la raison pour laquelle les petits disques de base de données sont déconseillés.
  • Cloud-init : le mécanisme de configuration au premier démarrage pour les images Linux publiques, fourni sous forme de données utilisateur et appliqué une seule fois au démarrage.
  • Image verrouillée par région : une image ou un instantané privé utilisable uniquement dans la région où il a été téléversé ou créé.

Lectures complémentaires

  • Unité 4.1 : Sélection de la classe de calcul (le serveur que cette unité étend).
  • Unité 5.7 : Protection des données et cycle de vie (instantanés, sauvegarde et PITR composés en un plan de continuité).
  • Unité 7.3 : Ingénierie des performances (planchers de performance du stockage comme levier de latence).