Aller au contenu principal

Haute disponibilité et PRA

Objectifs​

PérimètreRPORTO
PostgreSQL (CNPG, WAL continu)5 min30 min
Audit WORM (S3 object lock, réplication)0 (écriture synchrone)1 h
Configuration Kubernetes (Velero horaire + GitOps)1 h1 h
Index vectoriels Qdrant (snapshots quotidiens, réindexation possible)24 h4 h
OpenBao (snapshot raft quotidien + HA raft 3 nœuds)24 h1 h
Inférence vLLM (sans état)n/a15 min (téléchargement du modèle depuis cache)

Multi-AZ​

  • Control plane, portal, LiteLLM : >= 3 réplicas en prod, PDB minAvailable: 2, anti-affinité par zone (values-prod.yaml), topologySpreadConstraints.
  • CNPG : 3 instances, podAntiAffinityType: required sur topology.kubernetes.io/zone, bascule automatique.
  • NATS JetStream et Qdrant : 3 réplicas, facteur de réplication 3.
  • Redis : sentinel ou cluster ; les limites de débit APISIX tolèrent une perte temporaire (mode dégradé local).

Sauvegardes​

  • CNPG : sauvegarde de base quotidienne (ScheduledBackup) + archivage WAL chiffré vers S3, rétention 30 jours. Restauration PITR : nouveau Cluster avec bootstrap.recovery.recoveryTarget.targetTime.
  • Sauvegarde logique vérifiée (format custom) : PGDATABASE=eai PGPASSFILE=/run/secrets/pgpass scripts/pg_backup.sh /backup/eai.dump, restauration dans une base vide : createdb eai_drill && PGDATABASE=eai_drill EAI_PYTHON=.venv/bin/python EAI_DATABASE_URL=... scripts/pg_restore.sh /backup/eai.dump (échoue si une migration est en attente). Testé par tests/test_core_pg_backup.py (données, migrations, RLS FORCE). Détails : postgresql.md.
  • Redis : aucune sauvegarde requise (cache, reconstruit depuis PostgreSQL). Voir redis.md.
  • Velero (deploy/velero/schedules.yaml) : quotidienne (volumes + hooks pg_dumpall, snapshot Qdrant, snapshot raft OpenBao) et horaire (configuration). Les secrets sont restaurés depuis OpenBao.

Exercice de restauration (trimestriel)​

  1. velero restore create --from-backup eai-platform-daily-<date> --namespace-mappings enterprise-ai:enterprise-ai-drill.
  2. Restaurer CNPG en PITR dans un namespace isolé, exécuter GET /v1/audit/verify.
  3. Mesurer RPO/RTO réels et les consigner.

Test de restauration Velero et site isolé (bundle de release)​

  • Manifestes deploy/velero/restore-test.yaml : Backup à la demande eai-restore-test des namespaces enterprise-ai et eai-security, puis Restore vers les namespaces de contrôle eai-restore-check et eai-restore-check-security (sans toucher aux namespaces actifs).
  • Validés hors ligne avec kubeconform et les schémas Velero épinglés (tools/release/fetch-tools.sh), test services/control-plane/tests/test_release_ci.py::test_rendered_platform_manifests_validate.
  • Exécution réelle : uniquement sur le cluster de recette (kubectl apply -f deploy/velero/restore-test.yaml, puis velero restore describe eai-restore-test). Limite : non exécuté ici, aucun cluster de recette disponible.
  • Reprise sur un site isolé : réinstaller depuis le bundle signé vérifié hors ligne (bash tools/release/verify.sh <bundle>), voir installation-handbook.md ; la preuve sans réseau est tools/release/airgap-check.sh (résultat dans release/airgap/<date>.json).

Haute disponibilité gérée par le Platform Manager (addendum 20.4)​

Profil Helm deploy/helm/enterprise-ai/values-ha.yaml (3 réplicas, PDB minAvailable: 2, répartition hostname et zone, anti-affinité, arrêt gracieux 60 s) et groupes HA du manager : voir navin-manager/docs/availability.fr.md (modèle, preuves locales mesurées PostgreSQL, Patroni, Redis Sentinel, NATS JetStream, limites). Sur Kubernetes, la configuration est rendue et validée hors ligne seulement (HA_CONFIGURED).