Ce guide détaille la réplication entre deux appliances Caelum : la copie régulière de vos partages vers un site secondaire, et la bascule en reprise d'activité (PRA) si le site principal devient indisponible. Il complète le guide d'administration (écran par écran) et le guide des tâches (opérations courantes).
La réplication s'appuie sur le moteur ZFS : Caelum prend un snapshot du
partage et l'envoie vers l'appliance distante (zfs send / zfs receive)
au-dessus d'un canal SSH chiffré. Après le premier envoi complet, les envois
suivants sont incrémentaux : seuls les blocs modifiés depuis le snapshot
précédent transitent sur le réseau.
Table des matières#
- Vue d'ensemble
- Déclarer une cible de réplication
- Appairage (autoriser la réplication)
- Créer un job de réplication
- Fréquences et mode continu
- Fidélité des droits (ACL NTFS)
- Réplications entrantes et reprise d'activité (PRA)
- Suivre l'état et dépanner
- Haute disponibilité en mode réplication (« Option A »)
- Pièges et limites à connaître
1. Vue d'ensemble#
La vue Réplication (barre latérale) s'organise en trois blocs :
- Cibles de réplication : les appliances distantes vers lesquelles vous répliquez (le « où »).
- Jobs de réplication : ce que vous répliquez et à quelle fréquence — un job associe un volume source à une cible (le « quoi » et le « quand »).
- Réplications entrantes : côté destination, la liste des datasets reçus d'autres appliances Caelum, avec l'action Vérifier le réplica.
Cette vue Réplication crée des jobs par volume et sert à tester un réplica (« Vérifier le réplica » / PRA). La haute disponibilité en mode réplication (« Option A ») va plus loin : elle ajoute un rôle Primaire/Secondaire et un failover en un geste (voir la section 9).
Deux canaux réseau sont utilisés, et il est utile de les distinguer :
- Le transfert des données (snapshots ZFS) passe par SSH (port 22 par
défaut, configurable), avec une clé
ed25519propre à l'appliance source. - L'appairage et la réplication de configuration (cible S3, utilisateurs LDAP…) passent par l'API HTTPS de l'appliance distante (port 443), derrière le reverse-proxy intégré. C'est la session admin distante qui autorise la clé SSH côté cible.
2. Déclarer une cible de réplication#
Une cible représente l'appliance distante qui recevra vos snapshots.
- Allez dans Réplication → Nouvelle cible.
- Renseignez :
- Nom : libellé de la cible (ex.
site-secondaire). - Adresse (IP ou nom DNS) : l'adresse de l'appliance distante.
- Utilisateur SSH : le compte SSH utilisé pour
zfs receive(galilopar défaut — ne le changez que si votre environnement l'impose). - Port SSH :
22par défaut.
- Nom : libellé de la cible (ex.
- Cliquez sur Tester & détecter. Caelum vérifie la connectivité SSH et détecte le pool de destination sur l'appliance distante (l'emplacement cible ZFS est déduit automatiquement du pool ; aucun chemin à saisir).
- Options utiles :
- Compression réseau (lien bas-débit / WAN) : active
ssh -Cpendant le transfert. Gain typique 2-3× sur des données texte ou des images de VM ; peu d'intérêt sur du LAN 10G (et consomme du CPU). - IP source (optionnel) : force l'IP/interface source du flux de
réplication (
ssh -b). Utile si l'appliance dispose d'un réseau de réplication dédié. Vide = route système par défaut.
- Compression réseau (lien bas-débit / WAN) : active
- Enregistrez.
Si le Tester & détecter indique que la cible refuse la clé SSH, c'est normal au premier contact : il faut appairer les deux appliances (section suivante).
3. Appairage (autoriser la réplication)#
Au premier contact, l'appliance distante ne connaît pas encore la clé SSH de l'appliance source : elle refuse le transfert. L'appairage autorise cette clé une fois pour toutes.
Quand Tester & détecter détecte ce cas, un sous-bloc d'appairage apparaît dans la modale :
- Saisissez un compte administrateur de l'appliance distante et son mot de passe. Ces identifiants servent uniquement à l'autorisation et ne sont pas stockés : Caelum ouvre une session admin HTTPS vers l'appliance distante (port 443) et lui transmet la clé publique SSH de la source à autoriser.
- Cliquez sur Autoriser & retester.
Une fois la clé publique ajoutée côté cible (à son fichier authorized_keys), le
test SSH passe et la cible est prête à recevoir des réplications. L'appairage est
idempotent : ré-autoriser une clé déjà connue ne fait rien de plus.
L'appairage ne stocke aucun mot de passe. Seule la clé publique de l'appliance source est conservée côté destination. Pour révoquer une source, retirez sa clé de l'appliance distante.
4. Créer un job de réplication#
Un job associe un volume à une cible et fixe la fréquence des envois.
- Dans Réplication, sous Jobs de réplication, créez un Nouveau job.
- Choisissez :
- Cible : l'une des cibles déclarées à l'étape 2.
- Volume à répliquer : le volume envoyé en intégralité (snapshot + données) vers la cible. Le dataset ZFS du volume — et donc tous ses partages — est répliqué. On crée un job par volume.
- Fréquence : voir la section suivante.
- Enregistrez.
Le premier envoi est un full (toutes les données du volume). Les envois
suivants sont incrémentaux : Caelum prend un nouveau snapshot et n'envoie
que les blocs modifiés depuis le dernier snapshot répliqué (zfs send -i). Cela
réduit fortement le volume transféré et la durée de chaque cycle.
Pour lancer un cycle immédiatement (sans attendre la planification), utilisez l'action Exécuter maintenant du job. Pour ajuster la fréquence ou activer/désactiver un job sans le recréer, ouvrez Modifier le job de réplication.
Le débit réel vers une cible peut être mesuré via le Test de débit (transfert de 100 Mio + mesure de latence et des écritures disque source/cible). Il aide à choisir une fréquence réaliste : un cycle incrémental ne doit pas durer plus longtemps que l'intervalle choisi.
5. Fréquences et mode continu#
La fréquence d'un job va du quasi temps réel au hebdomadaire :
- Continu (~15 s — RPO temps réel) : Caelum réplique en continu (cycle d'environ 15 secondes). Pour soutenir ce rythme, la rétention est gérée automatiquement (les 60 derniers snapshots sont conservés) et le RPO mesuré est affiché en direct sur le tableau de bord.
- Toutes les 15 minutes, 30 minutes, toutes les heures, toutes les 2 / 4 / 6 / 12 heures.
- Tous les jours (par défaut).
- Toutes les semaines.
Choisissez la fréquence en fonction de votre RPO (perte de données maximale acceptable) et du débit du lien : sur un WAN lent, un intervalle court peut ne pas laisser le temps au cycle incrémental de se terminer. Le Test de débit et le RPO live du dashboard vous guident.
Le mode continu vise un RPO de quelques secondes. Réservez-le aux partages critiques et à un lien correctement dimensionné ; pour de l'archivage froid, une fréquence horaire ou quotidienne suffit largement.
6. Fidélité des droits (ACL NTFS)#
Lorsque le partage source porte des droits NTFS issus d'un domaine Active Directory, Caelum réplique fidèlement ces droits (descripteurs de sécurité : propriétaire, ACE autoriser/refuser, héritage) vers le partage de destination. Après une bascule en PRA, les utilisateurs du domaine retrouvent donc les mêmes permissions sur le site de secours.
Cette préservation est activée au niveau du job pour les partages concernés. Elle nécessite que l'appliance de destination soit, elle aussi, en mesure de résoudre les identités du domaine (jointe au même AD) pour appliquer les droits.
7. Réplications entrantes et reprise d'activité (PRA)#
Côté destination, les datasets reçus apparaissent dans le bloc Réplications entrantes de la vue Réplication. Tant qu'aucune bascule n'est demandée, ces datasets ne sont pas servis : ils accumulent simplement les snapshots répliqués.
Vérifier un réplica, puis monter en PRA#
Trois actions se succèdent sur un dataset reçu :
- Vérifier le réplica (ex-« Monter en PRA ») : Caelum clone le dernier snapshot reçu et le monte en lecture seule, rattaché à un volume PRA dédié. Cela protège le flux de réplication d'origine et permet de contrôler l'intégrité des données sans rien perturber. Vérifiez d'abord que la dernière réplication reçue est récente.
- Monter en PRA : recrée les vrais partages à partir du réplica, pour servir réellement les utilisateurs depuis le site de secours (cas d'un sinistre sur le site principal).
- Arrêter le test : détruit le clone une fois le contrôle terminé (ou une fois le site principal rétabli).
Le clone peut aussi être rafraîchi (re-cloner depuis un snapshot reçu plus récent) depuis la même vue.
Documentez et testez votre procédure PRA à froid, hors production. La bascule implique des choix d'organisation (lecture seule vs écriture sur le site de secours, retour arrière une fois le site principal rétabli) qui dépendent de votre contexte. Vérifiez régulièrement que les réplications reçues sont à jour : un dataset reçu obsolète signifie un RPO dégradé.
8. Suivre l'état et dépanner#
- Tableau de bord : un widget de réplication montre les flux actifs et, pour les jobs continus, le RPO mesuré en direct.
- Jobs : chaque job affiche son dernier résultat (succès/échec, message, date) et son dernier snapshot envoyé.
- Vue Tâches : les cycles de réplication apparaissent dans la liste des opérations, avec leur statut.
Quelques causes fréquentes d'échec :
- Clé SSH non autorisée côté cible : refaites l'appairage (section 3).
- Lien saturé ou trop lent pour la fréquence choisie : espacez la fréquence, activez la compression réseau, ou utilisez une IP source dédiée. Le Test de débit aide au diagnostic.
- Pool de destination plein : libérez de l'espace côté cible ou réduisez la rétention.
- Versions différentes : pour la PRA et la HA, gardez les deux appliances sur des versions compatibles.
En cas de blocage, générez un support bundle (onglet Maintenance, secrets masqués) et consultez le dépannage.
9. Haute disponibilité en mode réplication (« Option A »)#
La vue Réplication décrite ci-dessus sert à répliquer et à tester un réplica (« Vérifier le réplica » / PRA). La haute disponibilité en mode réplication — appelée « Option A » — s'appuie sur la même mécanique (chaque appliance garde son pool local, une réplication ZFS asynchrone tient le passif en miroir lecture seule) et y ajoute deux choses : un rôle de données par nœud et un failover en un geste.
- Rôle local : Primaire (sert les données en lecture-écriture) ou Secondaire (miroir) (reçoit la réplication, en lecture seule).
- Bascule : le bouton « Basculer (failover) » promeut le Secondaire en Primaire (ses volumes passent en lecture-écriture, ses partages sont servis).
- Inversion automatique : au failover, la réplication s'inverse — le nouveau Primaire réplique désormais vers l'ancien, qui se démote de lui-même.
Assistant Réplication HA — Option A#
Depuis l'onglet Haute disponibilité, choisissez le mode Réplication puis suivez l'assistant en 2 étapes :
- Pair & réplication : désignez l'appliance pair et les volumes à répliquer (le toggle « Répliquer vers le pair HA » est aussi proposé à la création d'un volume).
- Récapitulatif & risques : confirmez les deux acquittements obligatoires — le RPO (perte de données possible = intervalle de réplication) et le risque de split-brain (deux primaires si le réseau se partitionne sans fencing).
Une fois l'Option A active, une bascule se déclenche depuis l'onglet Haute disponibilité (bouton « Basculer (failover) »).
10. Pièges et limites à connaître#
À lire avant de compter sur la reprise d'activité en mode réplication.
- Secret cloud non répliqué (par conception) : les destinations cloud sont répliquées sans leur secret (il ne quitte jamais son nœud). Après une bascule, l'admin doit ressaisir le secret S3 sur le nœud promu, sinon l'archivage et le Cache S3 restent bloqués.
- Prérequis Active Directory : pour que l'authentification des comptes AD fonctionne après bascule, les deux nœuds doivent être joints au domaine. À considérer comme un prérequis de la DR, pas comme un acquis.
- Failover manuel, RPO = intervalle : en mode réplication, la bascule est manuelle et vous pouvez perdre jusqu'à un intervalle de réplication de données. Le RPO nul et la bascule automatique transparente ne concernent que le mode stockage partagé (SAN + fencing requis en prod).
- Split-brain sans fencing : sans mécanisme de fencing, une partition réseau peut aboutir à deux primaires. Les acquittements de l'assistant servent à en prendre conscience.
Pour aller plus loin#
- Opérations courantes : guide des tâches.
- Écran par écran : guide d'administration.
- Résoudre un problème : dépannage et FAQ.