Piloter des conteneurs LXC manuellement via des scripts lxc-start est souple mais fragile : l’ordre de démarrage, les dépendances inter-services, la supervision et la réplication restent entièrement à la charge de l’administrateur. OpenSVC est un orchestrateur de services léger et open source conçu précisément pour ce cas d’usage : décrire un service comme un ensemble de ressources ordonnées — datasets ZFS, systèmes de fichiers, conteneur, synchronisation — et le piloter de façon déclarative.
Couplé à ZFS, OpenSVC exploite nativement zfs snapshot, zfs send et zfs recv pour garantir des snapshots journaliers et la réplication vers un nœud distant. Le résultat : un conteneur LXC dont le cycle de vie complet — démarrage, arrêt, snapshot, synchronisation, failover — est géré par un seul outil, sans crontab à maintenir ni script de réplication fragile.
Ce guide part d’un serveur Debian 12 (Bookworm) ou Ubuntu 24.04 LTS avec OpenZFS et LXC déjà opérationnels, et couvre l’installation d’OpenSVC 2.1, la préparation du dataset ZFS, la définition complète du service, la planification des snapshots quotidiens et la mise en place de la réplication zfs send/recv vers un nœud DR.
Prérequis système
ZFS et LXC opérationnels
Avant d’installer OpenSVC, vérifiez que les briques de base sont en place :
# Vérifier que ZFS est chargé et qu'un pool existe
zpool status
# Vérifier que lxc-create est disponible
lxc-create --version
# Installer les dépendances si nécessaire
apt install -y zfsutils-linux lxc lxc-templates
Pour la réplication zfs send/recv, un second serveur avec accès SSH depuis root sans mot de passe est requis. Configurez l’échange de clés si nécessaire :
# Depuis node1 : copier la clé publique root vers node2
ssh-copy-id [email protected]
# Tester la connexion sans mot de passe
ssh [email protected] "hostname"
Installation d’OpenSVC 2.1
Téléchargement et installation du paquet
OpenSVC fournit un paquet .deb directement depuis son dépôt officiel. L’installation se fait via dpkg, sans dépôt APT à configurer :
# Télécharger le paquet OpenSVC 2.1 (à répéter sur chaque nœud)
curl -o /tmp/opensvc.latest https://repo.opensvc.com/deb/2.1/current
# Installer le paquet
dpkg -i /tmp/opensvc.latest
# Vérifier la version installée
om node version
Le script de post-installation génère automatiquement une clé RSA 2048 bits pour l’authentification inter-nœuds, crée les répertoires de configuration sous /etc/opensvc/ et active le service systemd.
Démarrage du daemon
# Activer et démarrer le daemon OpenSVC
systemctl enable --now opensvc.service
# Vérifier l'état du daemon
om daemon status
# Afficher le tableau de bord interactif
om mon
La commande om mon affiche en temps réel l’état des nœuds et des services — c’est votre outil de supervision principal au quotidien.
Configuration du cluster deux nœuds (optionnel pour la réplication)
Si vous disposez de deux nœuds pour la réplication, initialisez le cluster :
# Sur node1 : configurer le heartbeat et récupérer le secret
om cluster set --kw hb#1.type=unicast
om cluster get --kw cluster.secret
# Sur node2 : rejoindre le cluster (remplacer SECRET et NODE1)
om daemon join --secret SECRET --node node1.example.com
# Sur node1 : vérifier que les deux nœuds sont visibles
om node ls
Préparation du dataset ZFS
Création du dataset dédié au conteneur
On suppose un pool ZFS existant nommé tank. On crée un dataset hiérarchique pour isoler les données de chaque conteneur :
# Dataset racine pour tous les conteneurs OpenSVC
zfs create tank/lxc
# Dataset spécifique au conteneur "webprod"
zfs create tank/lxc/webprod
# Définir explicitement le point de montage
zfs set mountpoint=/srv/lxc/webprod tank/lxc/webprod
# Activer la compression LZ4 (recommandé avec LXC)
zfs set compression=lz4 tank/lxc/webprod
# Vérifier
zfs list -o name,mountpoint,used,available,compression tank/lxc/webprod
Création du conteneur LXC sur le dataset
On crée le conteneur LXC directement dans le dataset ZFS (voir notre guide LXC pour les détails de configuration réseau) :
# Créer le conteneur LXC dans le répertoire du dataset ZFS
lxc-create -n webprod -t debian -- -r bookworm -a amd64
--rootfs /srv/lxc/webprod/rootfs
# Adapter la configuration LXC pour pointer vers le dataset
cat >> /var/lib/lxc/webprod/config << 'EOF'
lxc.rootfs.path = dir:/srv/lxc/webprod/rootfs
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 10.0.3.100/24
lxc.net.0.ipv4.gateway = 10.0.3.1
EOF
# Tester le démarrage manuel une fois
lxc-start -n webprod && lxc-info -n webprod
# Arrêter : OpenSVC prendra la main ensuite
lxc-stop -n webprod
Définition du service OpenSVC
Création et édition du service
Un service OpenSVC est un fichier INI placé sous /etc/opensvc/. Chaque section est une ressource typée. OpenSVC respecte un ordre de démarrage implicite : disk → fs → container → sync.
# Créer un service vide nommé "webprod"
om webprod create --kw nodes=$(hostname)
# Ouvrir la configuration dans l'éditeur
om webprod edit config
Voici le fichier de configuration complet à saisir — copiez et adaptez les noms de nœuds et de datasets :
# /etc/opensvc/webprod.conf
[DEFAULT]
# Démarrage automatique du service sur le nœud actif
orchestrate = start
nodes = node1.example.com
drpnodes = node2.example.com
[fs#1]
# Dataset ZFS monté avant le démarrage du conteneur
type = zfs
dev = tank/lxc/webprod
mnt = /srv/lxc/webprod
mnt_opt = defaults
# Rester monté sur le nœud standby pour faciliter le failover
standby = true
[container#1]
# Pilotage du conteneur LXC par OpenSVC
type = lxc
name = webprod
cf = /var/lib/lxc/webprod/config
start_timeout = 60
stop_timeout = 30
[sync#1]
# Snapshots ZFS journaliers du dataset conteneur
type = zfssnap
dataset = tank/lxc/webprod
recursive = true
# Conserver 7 snapshots (rétention 1 semaine)
snap_count = 7
# Plage horaire : entre 01h00 et 02h00, une fois par heure max
schedule = 01:00-01:59@60
[sync#2]
# Réplication vers le nœud DR via zfs send/recv
type = zfs
src = tank/lxc/webprod
dst = tank/lxc/webprod
target = drpnodes
recursive = true
# Planifier après les snapshots locaux
schedule = 02:00-03:00@61
Note :
orchestrate = startdémarre le service automatiquement sur le nœud actif. Pour un basculement automatique haute disponibilité, utilisezorchestrate = haen combinant plusieurs entrées dansnodes— OpenSVC décidera seul du nœud maître.
Rôle de chaque ressource
- fs#1 (type zfs) : OpenSVC monte et démonte le dataset automatiquement lors des transitions start/stop.
standby = truemaintient le dataset monté sur le nœud secondaire pour raccourcir le temps de failover. - container#1 (type lxc) : OpenSVC appelle
lxc-start/lxc-stopet surveille l’état du conteneur vialxc-info. Si le processus meurt, OpenSVC peut le redémarrer selon la politique configurée. - sync#1 (type zfssnap) : Crée des snapshots ZFS locaux nommés
@opensvc.webprod.sync#1.YYYY-MM-DD.HHMM. Le paramètresnap_count = 7supprime automatiquement les snapshots excédentaires. - sync#2 (type zfs) : Utilise
zfs send -Ietzfs recvvia SSH pour transférer les deltas incrémentaux vers le nœud DR. Un snapshot@sentsert de référence pour les transferts suivants.
Démarrage et gestion du service
Premières opérations
# Afficher l'état détaillé de toutes les ressources
om webprod print status
# Démarrer le service sur le nœud local
om webprod start --local
# Vérifier que le conteneur est bien démarré
lxc-info -n webprod
# Déclencher une synchronisation manuelle de l'ensemble des syncs
om webprod sync all
# Arrêter proprement le service (conteneur puis démontage ZFS)
om webprod stop --local
Synchronisation initiale vers le nœud DR
Avant la première synchronisation incrémentale, OpenSVC doit envoyer un snapshot complet vers le nœud DR :
# Synchronisation initiale complète vers le nœud DR
om webprod sync nodes
# Vérifier les snapshots créés côté source
zfs list -t snapshot -o name,creation tank/lxc/webprod
# Vérifier la réception côté DR
ssh node2.example.com "zfs list -t snapshot tank/lxc/webprod"
OpenSVC crée automatiquement un snapshot @sent sur la source et la destination pour marquer l’état de synchronisation. Les exécutions planifiées suivantes n’envoient que les deltas entre @sent et le dernier snapshot — ce qui minimise la bande passante réseau.
Surveillance au quotidien
# Tableau de bord interactif (rafraîchissement automatique)
om mon
# Logs du service (toutes les ressources)
om webprod logs
# Prochain passage du scheduler pour chaque ressource sync
om webprod print schedule
# Vérifier la configuration actuelle
om webprod print config
Planification fine des snapshots et de la réplication
La directive schedule d’OpenSVC accepte la syntaxe HH:MM-HH:MM@durée où la durée est en minutes. Exemples courants :
# Snapshot quotidien strictement à 01h00
om webprod set --kw sync#1.schedule="01:00-01:30@30"
# Réplication deux fois par jour (02h et 14h)
om webprod set --kw sync#2.schedule="02:00-02:30@30 14:00-14:30@30"
# Désactiver temporairement la réplication sans supprimer la ressource
om webprod set --kw sync#2.disable=true
# Forcer une synchronisation immédiate hors planning
om webprod sync nodes
Le daemon OpenSVC gère entièrement le scheduler interne — aucune entrée crontab n’est nécessaire. Les exécutions sont tracées dans les logs du service et visibles via om webprod print schedule.
À lire également
- Installation et Configuration des Conteneurs LXC sur Linux — fondamentaux de LXC à maîtriser avant d’intégrer OpenSVC comme orchestrateur
- ZFS sur Linux : snapshots, clones et RAID-Z en pratique — approfondir la gestion des snapshots et des clones ZFS exploités par OpenSVC
- ZFS sur Linux — Installation et gestion avancée — installation d’OpenZFS et concepts de datasets indispensables pour ce tutoriel
- LXD 6.x : orchestration de conteneurs Linux avec profils et clustering — alternative à OpenSVC pour l’orchestration LXC, avec clustering natif LXD
- DRBD : réplication de blocs entre deux serveurs en temps réel — approche complémentaire pour la réplication de données entre nœuds en haute disponibilité