API OVHcloud : configurer LVM et ZFS lors d’une réinstallation serveur

Table des matières :

Ce que l’API OVHcloud permet vraiment pendant une réinstallation (et ce qu’elle ne permet pas)
Réinstallation automatisée via l’API : templates, partition schemes, lancement et suivi
LVM : partitionnement compatible OVH + provisioning post‑install (layout maintenable)
ZFS : pool de données après réinstallation (recommandé) vs root sur ZFS (avancé, à vos risques)
Orchestrer la réinstallation + stockage : API OVHcloud + scripts idempotents (Ansible/Terraform)
Check‑list post‑réinstallation : intégrité, perfs, et sécurité (à faire avant de remettre du trafic)

Configurer LVM et ZFS pendant une réinstallation via l’API OVHcloud, ce n’est pas la même chose que « choisir un système de fichiers dans un installeur ». Sur un dédié OVHcloud (gammes Rise/Advance/Scale/High Grade, ex‑So you Start/Kimsufi inclus), l’API d’installation orchestre une image (template) + un schéma de partitions proposé par OVH. Pour du LVM, ça passe souvent « nativement » via ces schémas. Pour ZFS, c’est plus subtil : soit vous créez un pool de données après réinstallation (solution réaliste et maintenable), soit vous tentez un root sur ZFS en mode rescue (solution avancée, peu supportée, très dépendante du matériel).

Les exemples ci‑dessous sont donnés pour Debian 12 (bookworm) et Ubuntu 24.04 LTS, avec un noyau Linux récent (6.1+ côté Debian, 6.8+ côté Ubuntu). Adaptez si vous avez besoin d’un kernel HWE ou d’options ZFS spécifiques.

Un point « terrain » souvent oublié : sur OVHcloud, le comportement « raisonnable » dépend autant du type de contrôleur disque (HBA/JBOD vs RAID matériel) que de l’OS. Deux serveurs « identiques » côté CPU/RAM peuvent se comporter très différemment côté stockage si l’un expose les disques en direct et l’autre les masque derrière des volumes RAID.

Ce que l’API OVHcloud permet vraiment pendant une réinstallation (et ce qu’elle ne permet pas)

Sur un serveur dédié OVHcloud, la réinstallation « officielle » se fait via l’API Bare Metal (/dedicated/server/.../install). Le modèle est toujours le même : vous sélectionnez un template (OS), un partition scheme (schéma de partitions) et vous lancez l’installation. En pratique, cela couvre très bien les cas « classiques » (GPT/MBR, RAID logiciel, LVM sur partition(s) ou sur mdadm), et beaucoup moins bien les cas « ZFS root custom », « chiffrement LUKS fin », ou « boot chain exotique ».

Le point à intégrer : l’API OVHcloud n’est pas un installeur interactif. Elle applique des recettes prédéfinies. Pour le stockage, cela implique une contrainte structurante : vous pouvez choisir un schéma de partitionnement existant, mais vous ne dessinez pas librement votre layout comme dans un kickstart, un preseed, ou un autoinstall cloud‑init. La conséquence directe : si votre objectif est « ZFS partout, y compris / », vous sortez des rails.

Ce que ça veut dire concrètement (et ce que ça évite comme mauvaises surprises) :

Vous contrôlez : OS, langue, quelques options (clé SSH selon template/compte), et un partitionnement « catalogue ».
Vous ne contrôlez pas finement : tailles exactes des LVs (selon scheme), propriétés ZFS, mdadm avancé, chiffrement multi‑volumes, ordre de boot complexe, stratégie de snapshots.
Vous devez prévoir : une phase post‑install (SSH) pour finir le stockage (LV supplémentaires, ZFS datasets, montage, tuning, permissions).

Enfin, le matériel dicte ce qui est raisonnable. Beaucoup de dédiés OVH sont livrés avec un contrôleur RAID matériel. Or ZFS est conçu pour contrôler la pile de stockage de bout en bout (checksums, scrubs, auto‑heal). Si votre contrôleur vous masque les disques (mode RAID uniquement), ZFS perd une partie de son intérêt (vous n’avez plus la « vue disque » ni le même modèle de défaillance). À l’inverse, LVM au‑dessus d’un RAID matériel ou d’un mdadm ne pose pas de problème conceptuel.

Réflexe simple avant de choisir : si vous voyez des disques physiques (/dev/sdX) distincts et stables, ZFS « data pool » est généralement pertinent. Si vous ne voyez qu’un volume logique RAID (un seul gros /dev/sda), ZFS restera possible mais avec moins de bénéfices (et parfois plus de complexité).

Ressource officielle utile pour comprendre la philosophie et les fonctionnalités OpenZFS (sans « recettes » spécifiques OVH) : OpenZFS documentation

Réinstallation automatisée via l’API : templates, partition schemes, lancement et suivi

Prérequis et risques

Perte de données : une réinstallation OVH est destructive. Sauvegardez hors du serveur (object storage, autre machine, NAS, etc.). Si vous avez un besoin de restauration rapide, validez avant l’opération le temps de transfert (réseau) et le temps de restauration (IO).
Accès API : créez une application API OVHcloud (clé / secret + consumer key) via la console : API OVH Console
Fenêtre de maintenance : vous coupez forcément le service. Pour cadrer l’impact e‑commerce, gardez un plan de bascule et une supervision active. Sur ce blog, les runbooks de diagnostic côté serveur sont déjà couverts (ex. 503) : Runbook erreur HTTP 503

Ajoutez deux vérifications « pré‑vol » qui évitent des incidents classiques :

Accès console / rescue : assurez‑vous de pouvoir repasser en rescue si la machine ne boote pas (utile si un montage fstab bloque).
Inventaire stockage : notez ce que voit le système aujourd’hui (lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL, lspci | grep -i raid). Ce « state » sert de référence si, après réinstall, l’ordre des disques change ou si le contrôleur présente les volumes différemment.

Côté outillage, deux approches réalistes : 1) scripts curl signés OVH (pénible mais autonome) ; 2) SDK Python (ovh) ou ovh-cli pour simplifier l’authentification. Pour de l’industrialisation (plusieurs serveurs), vous voulez une étape « discovery » (lister templates/schemes) puis une étape « apply » (lancer install + poll + post‑install).

Un mini‑schéma d’exécution réaliste en prod (staging → prod) :

vous validez un couple template + scheme sur un serveur de test ;
vous scriptiez un provisioning post‑install (LVM/ZFS + services) ;
vous mesurez (TTFB, I/O, saturation) ;
seulement ensuite vous « répliquez » sur le serveur prod.

Discovery : identifier template et schéma de partitions compatibles

Les noms exacts varient selon la gamme, le datacenter et les options. Ne hardcodez pas à l’aveugle : interrogez l’API.

Exemple (Python ovh, pseudo‑code robuste) :

import ovh

client = ovh.Client(endpoint='ovh-eu')
service = "nsXXXXXXX.ip-xx-xx-xx.eu"  # serviceName OVH

# 1) templates compatibles
templates = client.get(f"/dedicated/server/{service}/install/compatibleTemplates")
print(templates)

# 2) schémas de partitions compatibles avec un template
template = "debian12_64"  # exemple
schemes = client.get(
    f"/dedicated/server/{service}/install/compatiblePartitionSchemes",
    templateName=template,
)
print(schemes)

Dans la vraie vie, vous filtrez ensuite les schémas par intention :

LVM : cherchez des schemes contenant lvm, lvm-raid1, lvm-raid10, etc.
ZFS : vous ne trouverez généralement pas de scheme « zfsroot » prêt‑à‑l’emploi. Le pattern le plus sain est d’installer en ext4/xfs « propre », puis de créer un pool ZFS pour /var/lib/mysql, /var/www, /srv, etc.

Deux précautions lors de cette phase :

Ne déduisez pas le layout réel depuis le nom : un scheme « lvm_raid1 » peut correspondre à un RAID logiciel ou à une combinaison qui dépend du serveur. Si vous avez un doute, faites un essai sur un serveur non critique, puis inspectez (lsblk, pvs/vgs/lvs, cat /proc/mdstat).
Anticipez la place nécessaire au système : si vous comptez mettre beaucoup de données sur un pool ZFS secondaire, ne laissez pas le partition scheme « manger » tous les disques. Choisissez un schéma qui laisse un ou plusieurs disques/volumes disponibles (ou une partition data suffisamment grande si vous faites du ZFS sur partition, même si ce n’est pas l’idéal).

Lancement de l’installation et polling

Une fois le couple template/scheme validé, vous lancez l’installation. Là encore, l’API expose un job asynchrone : vous démarrez, puis vous interrogez l’état jusqu’à done (ou error).

payload = {
  "templateName": "debian12_64",
  "partitionSchemeName": "lvm_raid1",  # exemple
  "details": {
    "language": "fr",
    "sshKeyName": "your_ovh_ssh_key"  # si disponible dans votre compte
  }
}

task = client.post(f"/dedicated/server/{service}/install/start", **payload)
print(task)

# Poll
status = client.get(f"/dedicated/server/{service}/install/status")
print(status)

Important : tout ce qui est « configuration fine » (LVM layout exact, ZFS properties, sysctl, tuning MySQL) n’est pas le rôle de l’install OVH. Votre approche doit donc être en deux phases : (1) install via API, (2) provisioning idempotent par SSH (Ansible, scripts shell, cloud‑init‑like si vous le reconstituez).

Astuce opérationnelle : dans votre « polling », prévoyez une stratégie de timeouts et d’alerting (mail/Slack) — pas uniquement un while True. Un install peut prendre plus de temps que prévu (téléchargement d’image, contrôleur lent, vérifs RAID). Le bon pattern : journaliser l’ID de tâche, l’état, et la durée ; si vous dépassez un seuil (ex. 45–60 min), vous passez en investigation.

LVM : partitionnement compatible OVH + provisioning post‑install (layout maintenable)

LVM reste le « choix d’ingénieur pragmatique » sur dédié : simple, prévisible, bien supporté par les templates OVH, et suffisamment flexible pour découper proprement les volumes d’une stack e‑commerce (web, logs, base de données, cache).

Dans un contexte PrestaShop, le découpage utile n’est pas « par esthétique » mais pour isoler les contraintes I/O :

/var/lib/mysql (IOPS + fsync) ;
/var/www (beaucoup de petits fichiers, déploiements, cache applicatif) ;
/var/log (écriture séquentielle, rotation) ;
éventuellement un LV séparé pour /var/lib/redis si vous persistez Redis (souvent inutile en pur cache).

Un exemple de « layout » maintenable (à adapter à votre taille de catalogue et à vos médias) :

Point de montage	FS conseillé	Pourquoi
`/`	ext4	boot simple, support universel
`/var/lib/mysql`	XFS ou ext4	DB : stabilité + options de montage maîtrisées
`/var/www`	ext4	petits fichiers + compatibilité outillage
`/var/log`	ext4	rotations, quota implicite via taille LV
`/srv/backups`	ext4	évite de saturer `/` avec des dumps

Le provisioning typique (si le schéma OVH ne vous a pas déjà créé ce que vous voulez) :

# Exemple : vous avez un disque /dev/sdb (ou un mdadm) réservé aux données
pvcreate /dev/sdb
vgcreate vg_data /dev/sdb

# LV MySQL (taille à ajuster)
lvcreate -n lv_mysql -L 200G vg_data
mkfs.xfs -f /dev/vg_data/lv_mysql

mkdir -p /var/lib/mysql
mount /dev/vg_data/lv_mysql /var/lib/mysql

echo '/dev/vg_data/lv_mysql /var/lib/mysql xfs defaults,noatime 0 2' >> /etc/fstab

Deux ajouts « pro » à ce bloc (souvent négligés) :

Utilisez des identifiants stables dans fstab si possible (UUID= via blkid). C’est particulièrement utile si l’ordre /dev/sdX change après un reboot ou après une intervention hardware.
Validez tout de suite le scénario « redémarrage » : un montage qui échoue peut bloquer le boot (ou dégrader silencieusement, selon options). Un reboot contrôlé après modification de fstab évite de découvrir le problème le jour où vous faites une mise à jour kernel.

Pour les snapshots, ne vous racontez pas d’histoires : les snapshots LVM classiques coûtent cher en écriture dès qu’ils grossissent. Si vous visez des snapshots fréquents, regardez plutôt :

LVM thin‑provisioning (thin pool) + monitoring strict de l’espace (un thin pool plein = incident) ;
ou ZFS si votre priorité est snapshot + réplication.

Mini‑scenario (cas réaliste e‑commerce) : vous déployez un gros module, et vous voulez un point de restauration. Avec LVM « classique », un snapshot de /var/lib/mysql peut être OK si vous le gardez très peu de temps (le temps de valider), puis vous le supprimez. Si vous comptez garder des snapshots pendant des jours sur une DB active, vous paierez en latence disque — et vous finirez par « débugger » la perf applicative au lieu d’identifier la cause (copy‑on‑write qui gonfle).

Sur une boutique qui doit pouvoir revenir en arrière après un déploiement ou une migration, la valeur d’un bon découpage LVM se mesure en temps de restauration, pas en « propreté ». Le runbook « plan de rollback » côté applicatif est un bon complément : Plan de rollback migration PrestaShop

ZFS : pool de données après réinstallation (recommandé) vs root sur ZFS (avancé, à vos risques)

Option A — ZFS comme pool de données (la stratégie qui tient en prod)

Le scénario le plus robuste sur OVH : vous réinstallez via API un OS supporté (ext4/xfs pour /), puis vous ajoutez ZFS sur un second disque ou un ensemble de disques visibles (idéalement JBOD/HBA). Vous obtenez snapshots, checksumming, compression et réplication (zfs send|receive) sans vous battre avec le boot.

Installation Debian/Ubuntu :

# Debian 12
apt update
apt install -y zfsutils-linux

# Ubuntu 24.04
apt update
apt install -y zfsutils-linux

Avant de créer le pool, appliquez deux bonnes pratiques qui évitent des surprises :

Cibler des chemins stables : préférez /dev/disk/by-id/... plutôt que /dev/sdb. Cela limite les dégâts si l’ordre des disques change.
Vérifier qu’aucune signature résiduelle n’existe (ancien RAID, ancienne table) : sinon zpool create peut échouer ou, pire, vous faire hésiter sur le bon disque. Exemple : wipefs -a /dev/sdb (avec une extrême prudence).

Création d’un pool (ex. miroir) :

# Exemple mirror sur deux disques /dev/sdb et /dev/sdc
zpool create -o ashift=12 -O compression=lz4 -O atime=off \
  -O xattr=sa -O acltype=posixacl -O normalization=formD \
  tank mirror /dev/sdb /dev/sdc

zpool set autotrim=on tank

Ensuite, vous découpez en datasets selon les workloads (c’est là que ZFS devient intéressant). Une logique simple et efficace :

tank/mysql → latence + cohérence (recordsize plus petit)
tank/www → nombreux petits fichiers (compression utile)
tank/backups → compression + éventuellement sync=disabled uniquement si ce sont des archives non critiques et si vous acceptez le risque (en général, évitez)

Pour MySQL/MariaDB, des réglages typiques :

zfs create -o mountpoint=/var/lib/mysql \
  -o recordsize=16K -o logbias=latency -o primarycache=all \
  tank/mysql

systemctl stop mariadb
rsync -aHAX /var/lib/mysql/ /var/lib/mysql.bak/
# (copie vers le dataset monté)
rsync -aHAX /var/lib/mysql.bak/ /var/lib/mysql/
systemctl start mariadb

À ajouter côté exploitation (très concret) :

Snapshots : une stratégie simple est « avant déploiement » et « avant migration ». Exemple : zfs snapshot -r tank/mysql@pre-deploy-2026-07-15. Vous pouvez ensuite zfs rollback en cas de régression (à condition de maîtriser l’impact applicatif).
Scrub : planifiez un scrub régulier (mensuel, par exemple) pour détecter des corruptions silencieuses. Commande : zpool scrub tank, puis suivi zpool status.
Alerting : déclenchez une alerte sur DEGRADED, FAULTED, et sur la croissance de l’espace utilisé (un pool plein, c’est une panne applicative).

Ce n’est pas magique : ZFS consomme de la RAM (ARC). Sur un dédié « juste dimensionné », une ARC trop agressive peut concurrencer PHP‑FPM/MySQL. Vous pilotez via zfs_arc_max (paramètre module) et vous observez. Pour cadrer cette partie, mettez une supervision système (Netdata/Grafana) ; le blog a déjà des bases côté monitoring : Netdata monitoring et Grafana sur Ubuntu

Enfin, si votre boutique est majoritairement en France/Belgique/Suisse et que vos clients sont sensibles à la latence, l’emplacement du serveur (datacenter OVH proche) compte souvent plus que des micro‑optimisations de FS. Ne confondez pas « stockage plus sophistiqué » et « meilleure perf perçue » : mesurez TTFB et latences réseau avant/après.

Option B — Root sur ZFS (possible, mais pas « API‑first »)

Le root sur ZFS sur un dédié OVH est faisable, mais ce n’est pas l’API d’installation OVH qui va vous le donner. Le pattern est plutôt : 1) passer en mode rescue (souvent via le Manager ou via API boot) ; 2) partitionner à la main (EFI + éventuellement bpool + rpool) ; 3) zpool create, debootstrap (Debian) ou ubuntu-base + chroot ; 4) installer kernel + zfs-initramfs, configurer GRUB EFI, générer initramfs ; 5) reboot.

Techniquement, vous vous appuyez sur les références Debian plutôt que sur « des recettes de forum ». Point de départ sérieux : Debian ZFS wiki. Sur certains serveurs avec RAID matériel imposé, la chaîne de boot + visibilité des disques rend l’exercice pénible, et surtout difficile à opérer (interventions, remplacement disque, etc.). Dans un contexte e‑commerce, le « possible » n’est pas un critère suffisant : le critère, c’est votre capacité à dépanner à 3h du matin.

Un signal d’alerte : si vous n’avez pas (ou plus) l’habitude de dépanner un bootloader en remote, ou si vous n’avez pas de procédure de remplacement disque testée, évitez le root ZFS sur une machine qui porte du chiffre d’affaires.

Enfin, ZFS root apporte des avantages réels (snapshots bootables, rollback), mais vous devez comparer au coût opérationnel. Si votre objectif principal est la performance applicative, commencez par des optimisations mesurables (PHP‑FPM/OPcache/MySQL/Redis) avant de complexifier le stockage. Sur ce point, la base utile : Performance PrestaShop et, côté cache, Redis PrestaShop

Orchestrer la réinstallation + stockage : API OVHcloud + scripts idempotents (Ansible/Terraform)

Si vous faites ça « à la main » une fois, ça passera. Si vous devez le refaire (incidents disque, rotation infra, staging/prod), vous avez besoin d’un pipeline reproductible. Le découpage sain :

Étape 1 : API OVH pour l’install (template + scheme) ;
Étape 2 : bootstrap SSH (création users, hardening, packages de base) ;
Étape 3 : stockage (LVM/ZFS) ;
Étape 4 : services (MySQL, PHP‑FPM, Nginx/Apache, Redis, HAProxy) ;
Étape 5 : observabilité (logs, métriques, alerting).

L’idempotence est non négociable : votre script doit pouvoir être relancé sans casser l’état. Exemple concret : avant un zpool create, vous vérifiez l’absence de pool ; avant un pvcreate, vous vérifiez la présence d’un PV ; avant de déplacer /var/lib/mysql, vous vérifiez que MySQL est stoppé et que le dataset est monté. Le coût d’un provisioning « semi‑idempotent » se paye lors du premier incident.

Checklist idempotence (simple mais efficace) à intégrer dans vos rôles Ansible/scripts :

Détection : zpool list tank / vgs vg_data → si présent, ne pas recréer.
Montage : si une entrée fstab existe déjà, ne pas la dupliquer.
Données : vérifier que le répertoire cible est vide (ou géré) avant rsync.
Services : stop/start conditionnels + validations (systemctl is-active).
Rollback : conserver un répertoire .bak ou un snapshot avant migration.

Pour intégrer ça à une démarche DevOps, gardez le stockage dans le même niveau d’exigence que le code applicatif : contrôle de version, revue, exécution en CI sur environnement de test, puis déploiement contrôlé. Même si l’article est orienté PrestaShop, les principes CI/CD (SBOM, validation, provenance) restent pertinents : CI PrestaShop & SBOM

Check‑list post‑réinstallation : intégrité, perfs, et sécurité (à faire avant de remettre du trafic)

Commencez par valider l’état bas niveau du stockage, sinon vous allez « déboguer » du PHP alors que c’est votre pool qui est dégradé. Côté LVM : pvs, vgs, lvs -a -o +devices, contrôle des UUID dans /etc/fstab, et un reboot de validation (pour vérifier que vos montages ne dépendent pas d’un ordre aléatoire). Côté ZFS : zpool status -v, zpool get ashift,autotrim, zfs mount, zfs get compression,recordsize,atime.

Ajoutez ces contrôles « à fort ROI » avant remise en prod :

Espace libre réel : sur ZFS, ne vous approchez pas d’un pool plein (dégradations possibles). Sur LVM, gardez une marge dans le VG si vous prévoyez d’étendre.
État disques : si possible, un smartctl -a (selon contrôleur) ou au minimum les logs du contrôleur RAID (si présent).
TRIM/discard : utile sur SSD/NVMe ; côté ZFS, autotrim=on est souvent pertinent (selon matériel).

Ensuite, mesurez. Sans métriques, vous ne faites que déplacer le problème. Quelques tests rapides :

fio sur les chemins critiques (MySQL, logs) ;
latence : ioping -c 10 /var/lib/mysql ;
charge DB : sysbench oltp_read_write (sur une base de test) ;
côté applicatif : TTFB et saturation PHP‑FPM. Pour cadrer la partie perf PrestaShop, vous avez une méthode reproductible : Audit performance PrestaShop et un focus TTFB : Réduire le TTFB

Petit cadrage pratique : faites vos tests I/O au bon endroit. Mesurer fio sur / quand votre DB est sur /var/lib/mysql ne vous apprendra rien. De même, comparez avant/après sur une fenêtre similaire (sinon vous mesurez la charge client, pas le stockage).

Enfin, la sécurité et l’opérationnel : activez la rotation de logs, un firewall cohérent, des clés SSH uniquement, et une supervision d’erreurs. Le stockage (LVM/ZFS) ne compensera jamais une absence de runbooks et d’alerting. Pour l’axe « durcissement OVH/VPS » : Sécurité VPS OVHcloud ; et pour la collecte d’erreurs applicatives : Monitoring erreurs PrestaShop