API OVHcloud et Stockage
Objectif
Cet article est destiné aux utilisateurs expérimentés qui ont au minimum des connaissances de base sur Linux, mais surtout des connaissances plus approfondies sur le stockage et en particulier sur les RAID logiciels, RAID matériels ainsi que sur la gestion logique des volumes (LVM).
Les serveurs dédiés OVHcloud vous permettent de configurer les disques, le RAID matériel, le RAID logiciel, LVM, ZFS, etc. pendant la réinstallation de votre système d'exploitation depuis l’API OVHcloud ou depuis votre espace client OVHcloud. Dans cet article, nous allons nous concentrer sur l'API OVHcloud.
Cela vous donnera plus de détails sur le moteur qui s'exécute en arrière-plan, afin de créer la personnalisation du stockage sur le serveur dédié à partir des données d'entrée transmises à l'API OVHcloud.
Fournir des détails avancés sur la configuration du stockage peut vous aider à comprendre pourquoi :
- votre personnalisation du stockage n'a pu être appliquée sur votre serveur dédié.
- la personnalisation du stockage réelle sur votre serveur dédié est légèrement différente de ce que vous aviez demandé.
Prérequis
- Un serveur dédié prêt à être installé/réinstallé sur votre compte OVHcloud.
- Avoir accès à l'API OVHcloud.
La réinstallation d'un serveur dédié supprime toutes les données qui y sont actuellement stockées.
En pratique
Lors de l'installation du système d'exploitation par défaut, l'installateur du système d'exploitation (fourni par l'éditeur du logiciel) invite l'utilisateur à spécifier les disques sur lesquels le système d'exploitation sera installé, la configuration du partitionnement, etc. Une fois l’OS installé, il est possible de modifier la disposition du partitionnement mais cela peut s’avérer très délicat et risqué, notamment pour les partitions qui sont actuellement utilisées par le système. Pour cette raison, la configuration du stockage est un sujet très important qui doit être pris en compte avant d'installer un système d'exploitation.
Outre la simplicité de l'API, le principal avantage est la possibilité de personnaliser totalement les disques et partitions sur lesquels sera installé l’OS.
Dans cette page, nous nous focaliserons seulement sur la sous-hash storage de l'appel API utilisé pour réinstaller un OS sur un serveur dédié. Pour les personnalisations de réinstallation OS non liées au stockage, veuillez vous référer à la page API OVHcloud et installation d'un OS pour plus de détails.
Grappes de disques
Certains serveurs dédiés possèdent plusieurs grappes ou groupes de disques. Par exemple, une grappe avec des disques SATA et une grappe avec des disques SSD. Nous appelons ces types de serveurs des serveurs hybrides.
Pour lister les grappes et leurs disques, vous pouvez utiliser l'appel suivant afin de déterminer le groupe de disques sur lequel vous souhaitez effectuer votre réinstallation OS :
Exemple de retour :
Dans cet exemple, vous avez 2 grappes :
- la première (diskGroupId=1) contient 2 disques de 480 Go chacun,
- la seconde (diskGroupId=2) contient 2 disques de 1,9 To chacun.
Exemple d'installation de Debian 12 (Bookworm) sur le diskGroupId 2 :
Par défaut, le système d’exploitation est installé sur le diskGroupId 1.
Pour l'instant, l'API ne supporte que l'installation OS et la personnalisation du stockage sur 1 seule grappe de disques. Vous pouvez impliquer de 1 à tous les disques de la grappe choisie dans la personnalisation du stockage. Cependant, tous les autres disques seront effacés mais seront visibles par l'OS installé, et peuvent être utilisés/configurés ultérieurement pour stocker des données.
RAID Hardware
Cette section est seulement applicable pour les serveurs qui ont au moins un contrôleur RAID matériel dans l'une de leurs grappes de disques.
Serveur & Compatibilité du RAID matériel
Vous pouvez utiliser l'appel API suivant afin de savoir si votre serveur dédié est compatible :
Si votre serveur dédié n'a pas de contrôleur RAID matériel, l'appel répond avec une erreur HTTP 403 (Forbidden) et le message suivant :
Exemple de réponse pour un serveur qui possède un RAID matériel :
Vous pouvez aussi obtenir cette information à la valeur de l'attribut raidController de l'appel API décrit dans la section Grappes de disques.
API & RAID Matériel
Pour l'instant, l'API ne supporte que la personnalisation du RAID matériel pour 1 seul contrôleur de RAID matériel. Si votre serveur possède plusieurs contrôleurs de RAID matériel sur lesquels vous souhaitez personnaliser leurs configurations, vous pouvez configurer le(s) autre(s) contrôleur(s) que celui de la grappe de disques choisie pour la réinstallation OS avant la réinstallation OS (vous pouvez aussi le faire une fois la réinstallation OS terminée, mais nous vous recommandons de le faire avant, afin d'éviter tout risque de mauvaise manipulation qui aurait pour conséquence une perte de données).
Exemple d'une installation OS avec un RAID 1 matériel entre les 2 premiers disques de la grappe de disques :
Si disks n'est pas spécifié, alors tous les disques de la grappe de disques seront impliqués dans le RAID matériel.
Maintenant supposons que vous avez un serveur dédié avec 1 grappe de disques attachée au contrôleur RAID matériel et 12 disques dans cette grappe. Exemple avec un RAID hardware 10 :
Dans cet exemple : tous les 12 disques seront impliqués dans le RAID matériel de niveau 10. Il y aura 4 groupes de 3 disques, ce qui signifie 4 RAID 1 entre 3 disques et les 4 groupes seront en RAID 0.
Le RAID matériel est à une couche qui n'est pas visible par l'OS. Ainsi, tous les OS sont « compatibles » avec le RAID matériel.
Tous les disques impliqués dans la configuration du RAID matériel seront vus comme 1 seul disque virtuel par l'OS.
Par conséquent, si vous avez impliqué tous les disques de la grappe de disques cible dans une configuration de RAID matériel, configurer un RAID logiciel par dessus ne sera pas applicable, puisque l'OS ne voit qu'1 seul disque virtuel.
Partitionnement
Lorsque l’on parle de schéma de partitionnement, on évoque l’organisation de vos données sur les disques, c’est-à-dire tout ce qui arrive sur votre disque physique (ou disque virtuel, si vous avez configuré un RAID matériel), jusqu’au système de fichiers monté et visible sur l’OS, des couches les plus basses aux plus hautes :
- Disque (disque physique/virtuel, PD)
- Partition (partition physique, PP)
- ZFS : vdev (zgroup, ZG), zpool (ZP), dataset ZFS (ZD), volume ZFS (ZV)
- RAID logiciel (SR)
- LVM : volume physique (VP), groupe de volumes (VG), volume logique (LV)
- Système de fichiers avec point de montage (FS)
Le tableau suivant donne une vue d'ensemble des différents composants de partitionnement et de la manière dont ces couches interagissent :
Dans le tableau ci-dessus, /dev/zd1 représente un volume ZFS (aussi appelé zvol). Il s'agit d'un disque virtuel situé au-dessus d'un ensemble de données ZFS (ZD) et d'un zpool (ZP), qui est considéré comme un disque physique normal (PD) par le système d'exploitation. Cette fonctionnalité n'est pas disponible sur l'API OVHcloud et nous ne prévoyons pas de l'implémenter.
OS & Compatibilité du partitionnement
Puisque la configuration du partitionnement sera visible par l'OS, l'OS choisi pour la réinstallation a un impact sur les possibilités de personnalisation de votre partitionnement.
Dans la section /dedicated/installationTemplate, vous pouvez obtenir les détails tels que la compatibilité LVM, la disponibilité du système de fichiers pour un OS en particulier :
Par exemple :
L'appel API suivant peut être utilisé pour lister les différents schémas de partitionnement d'un système d'exploitation en particulier. La plupart des systèmes d'exploitation supportent la personnalisation du partitionnement et ont par conséquent un seul schéma appelé « default ». Seuls certains d'entre-eux ne supportent pas la personnalisation du partitionnement (noPartitioning vaut true) et peuvent par conséquent avoir plusieurs schémas de partitionnement.
Les appels API suivants peuvent être utilisés pour savoir quel partitionnement sera appliqué par défaut si aucune personnalisation du partitionnement n'est spécifiée ou si elle n'est pas supportée par l'OS.
LVM, niveaux de RAID & compatibilité des systèmes de fichiers
Le tableau suivant donne une vue d'ensemble de la compatibilité des systèmes de fichiers avec les niveaux RAID et LVM dans le contexte OVHcloud :
¹ Pour plus d'informations, reportez-vous au tableau vdevs ZFS vs standard RAID.
² Le niveau de RAID pour swap ne peut être que égal à 1 au sein de l’API OVHcloud. En réalité, les partitions swap n'utiliseront pas de RAID. Lorsqu'une partition swap de taille s est définie sur un serveur avec un nombre n de disques, cela créera n partitions de taille s sur chaque disque sans aucun périphérique RAID logiciel en dessous.
³ Le RAID natif Windows (celui configuré par l'installateur OVHcloud) prend en charge le RAID 1 mais uniquement entre deux disques, alors que les autres implémentations en autorisent plus de deux.
⁴ L'installateur ESXi ne prend pas en charge les schémas de partitionnement personnalisés. Le partitionnement est défini par l'éditeur du logiciel. Néanmoins, l’API OVHcloud peut vous donner une idée de ce à quoi ressemble le partitionnement : pour plus d'informations, consultez OS & Compatibilité du partitionnement.
Ce tableau est fourni uniquement à titre d'information. À noter que la compatibilité LVM et surtout le système de fichiers dépendent également de l’OS (template OVHcloud) installé. Consultez la section OS & Compatibilité du partitionnement pour plus de détails.
Vdevs ZFS vs RAID standard
ZFS ne supporte pas les niveaux RAID standards. Il utilise des périphériques virtuels (vdevs) pour décrire la tolérance aux pannes au sein d'un groupe de périphériques. Consultez la documentation officielle d'OpenZFS en anglais pour plus de détails sur les vdevs.
Afin de rendre l'API OVHcloud la plus simple possible, il est nécessaire que vous définissiez un RAID standard au sein de l'API pour les systèmes de fichiers ZFS. Le niveau RAID standard sera alors traduit par une définition équivalente de vdev. Le tableau suivant illustre la traduction des différents niveaux RAID proposés par l'API OVHcloud ainsi qu'un rappel de leurs caractéristiques respectives.
API & Partitionnement
Exemple d'installation d'OS avec un partitionnement personnalisé :
size 0 signifie que la partition va remplir tout l'espace restant sur les disques concernés.
Au maximum 1 partition peut être configurée pour remplir l'espace restant (taille 0).
Si non spécifié, raidLevel aura pour valeur 1.
Dans cet exemple, seuls les 2 premiers disques de la grappe sont impliqués dans le partitionnement (c'est à dire dans le RAID logiciel).
Le paramètre disks peut être omis si vous souhaitez impliquer tous les disques de la grappe de disques dans le RAID logiciel.
Comme vous pouvez le voir, un schéma de partitionnement est une liste de partitions. Voici un exemple de structure d'une partition :
La sous-hash extras est optionnelle. Pour l'instant, cette dernière peut être utilisée pour spécifier que la partition sera un volume logique (LVM) et préciser le nom de son volume logique. La sous-hash peut aussi être utilisée pour le ZFS :
Dans cet exemple, le point de montage / concerne un dataset ZFS dans un zpool nommé "poule" de type raidz1. Consultez le tableau Vdevs ZFS vs RAID standard pour obtenir la correspondance entre les raidz et les niveaux de RAID standards.
Si aucun nom de zpool n'est spécifié, celui-ci sera généré automatiquement. Par défaut, l'algorithme tente de regrouper les différents datasets au sein d'un même zpool, à l'exception des datasets contenant / ou /boot qui sont placés dans des zpools séparés. Cela permet d'activer sur les autres zpools des fonctionnalités avancées de ZFS incompatibles avec le bootloader.
Utiliser un nom de zpool personnalisé peut être utile dans les cas suivants:
- grouper des datasets avec les mêmes niveaux de RAID : utiliser le même nom de zpool,
- forcer des datasets avec les mêmes niveaux de RAID à être dans des zpools distincts : utiliser des noms différents.
Gestion des erreurs
Les erreurs basiques de données d'entrée client sont directement traitées par l'API OVHcloud. Il s'agit de la situation la plus courante et la plus simple car les clients peuvent voir l'erreur de manière synchrone et réessayer immédiatement.
Les données d'entrée client liées au partitionnement peuvent être trop spécifiques pour être vérifiées par l'API OVHcloud et nécessiter par conséquent un temps de traitement. L'inconvénient est que les clients sont avertis plus tard pendant le processus de réinstallation du système d'exploitation.
Celui-ci est visible via la barre de progression depuis l'espace client OVHcloud. Depuis l'API OVHcloud, cet état peut être obtenu avec l'appel API suivant :
Il y a 2 types d'erreurs :
- erreurs ovh : vous n'êtes pas responsable de l'erreur, vous pouvez réinstaller avec une autre disposition de partitionnement mais OVHcloud devra corriger le défaut.
- erreurs clients: vous avez demandé un schéma de partitionnement qui ne peut pas être réalisé ou qui empêcherait le serveur de démarrer correctement.
Dans la section suivante, nous allons nous concentrer uniquement sur les types d'erreurs client dans l'étape du partitionnement, car cela n'est utile qu'aux clients.
Les erreurs clients fréquentes
Le tableau suivant donne un aperçu des erreurs clients les plus connues et de la manière de les corriger.
Auto-correction des données d'entrée client
Afin d'améliorer l'expérience client, réduire la charge de travail du support OVHcloud et éviter les changements brutaux qui pourraient avoir un impact pour le client, certaines saisies effectuées par le client sont automatiquement corrigées ou modifiées par le backend. Le tableau suivant donne une vue d'ensemble de ce qui est actuellement auto-corrigé / changé :
Aller plus loin
API OVHcloud et installation d'un OS
Remplacement à chaud - RAID logiciel
Configurer votre MegaRAID en RAID 0
Échangez avec notre communauté d'utilisateurs.