Migration cross-cluster
Déplacement d'un backend entre clusters avec downtime de 30 s à 5 min. URL inchangée. Rebalancing, maintenance, DR, changement de région.
Migration cross-cluster
La migration cross-cluster permet de déplacer un backend Pool C d'un cluster vers un autre avec un downtime minimal (30 secondes à 5 minutes selon la taille). Transfert via le réseau privé européen, avec synchronisation incrémentale pour minimiser le downtime. L'URL du projet (wzfbhd.runtime.di2amp.com) reste inchangée — seul le cluster hébergeant change en interne.
Cas d'usage
- Rebalancing de capacité quand un cluster approche de son maximum
- Maintenance planifiée d'un cluster (upgrade firmware, remplacement disque)
- Disaster Recovery en cas de défaillance grave d'un cluster
- Changement de région (e.g.
eu-west-1GRA →eu-central-1SBG) pour réduire la latence
Quand demander — quand pas
OK pour
- Changement de région validé sysops (latence, conformité régionale)
- Disaster recovery (initié par les opérateurs)
- Maintenance planifiée (initié par les opérateurs)
Pas pour
- Test de migration (préférer le branching)
- Backup ponctuel (préférer pg_dump ou snapshot manuel)
Déclenchement
# Demande tenant — changement de région (nécessite approbation sysops)
paas backends migrate wzfbhd --region eu-central-1
# Initié par sysops (administration plateforme)
curl -X POST "https://console.di2amp.com/api/v1/admin/backends/wzfbhd/migrate" \
-H "Authorization: Bearer $SYSOPS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"target_cluster_id":"yzopqr","reason":"rebalance"}'
Workflow en 10 étapes
| Étape | Description | Impact tenant |
|---|---|---|
| 1 — Validation | Capacité cible vérifiée, droits validés, notification tenant | — |
| 2 — Snapshot initial | Snapshot copy-on-write du dataset source (instantané) | — |
| 3 — Transfert initial | Transfert compressé via réseau privé européen | — |
| 4 — Drain connexions | 503 Retry-After: 60, attente terminaison requêtes | début downtime |
| 5 — Snapshot delta | Snapshot des modifications depuis l'étape 2 | downtime |
| 6 — Transfert incrémental | Delta uniquement (quelques Mo typiquement) | downtime |
| 7 — Basculement routing | Update atomique du cluster cible dans le control plane global | downtime |
| 8 — Démarrage cible | Container PostgreSQL démarre sur le nouveau dataset | downtime |
| 9 — Validation | Health check + test SQL — fin downtime si OK | fin downtime |
| 10 — Cleanup source | Destruction dataset source 24 h après validation | — |
Rollback automatique
Si les étapes 7 ou 8 échouent (démarrage Postgres impossible, health check échoue), rollback automatique :
- Routing redirigé immédiatement vers le cluster source
- Dataset cible détruit
- Cluster source reprend le service normalement
Garanties
| Garantie | Détail |
|---|---|
| Durabilité | Aucune donnée perdue — transfert exact octet par octet |
| Cohérence | Point de cohérence garanti par les snapshots copy-on-write |
| URL inchangée | wzfbhd.runtime.di2amp.com identique avant/après |
| Downtime cible | 30 s à 5 min (selon trafic au moment du delta) |
| Rollback | Automatique et immédiat si la validation échoue |
Sécurité du transfert
Transfert exclusivement sur le réseau privé européen 100 GbE entre datacenters OVH, chiffré TLS. Jamais exposé sur Internet public. Compression réduit la bande passante consommée d'environ 40-60 %.
Pour aller plus loin
Tarification associée
Migration initiée sysops : sans surcoût (rebalancing, maintenance, DR). Migration tenant (changement de région) : facturée selon la taille du transfert, voir tarifs.