Aller au contenu principal

Topologies d'hébergement

Cette page décrit où et comment héberger la Navin Platform : serveurs sur site installés par paquets, clusters Kubernetes, topologie de haute disponibilité, plusieurs sites et reprise après sinistre. Chaque topologie indique ce que fournit le dépôt et ce qui reste à la charge de l'équipe d'hébergement.

Serveurs sur site (paquets OS)​

TopologieHôtesQuand
StandaloneUn serveur : Navin Manager, agent, plateforme (API, worker, portail) et PostgreSQL localPilote, petite entité, site isolé
ClusterUn hôte Navin Manager, des nœuds avec l'agent navin-manager-agent ; le Manager installe les services sur les nœudsPlusieurs serveurs sans Kubernetes
Plateforme avec les services de la banqueHôte de la plateforme avec les serveurs PostgreSQL, Keycloak, Redis et OpenBao que la banque exploite déjàInfrastructure partagée, exploitation centrale

Les services écoutent en HTTP clair (8080, 3300) : un proxy inverse TLS de la banque est toujours placé devant eux (TLS). La base se déplace vers un serveur externe avec navin-platform-db external, en TLS (sslmode=verify-full). Installation guidée : paquets OS ; Manager et nœuds : os/install/README.fr.md.

La haute disponibilité des services installés par le Navin Manager (PostgreSQL avec Patroni et etcd, Redis Sentinel, NATS JetStream R3) est décrite dans navin-manager/docs/availability.fr.md, avec les temps de bascule mesurés en local et leurs limites (réplication asynchrone : la perte nulle est mesurée, pas garantie).

Kubernetes​

Un cluster par environnement (dev, staging, prod), chacun enregistré dans Argo CD avec le label eai.io/environment. Les namespaces sont créés par l'amorçage avec leur niveau Pod Security :

NamespaceContenu
enterprise-aiAPI Control Plane, worker, portail, LiteLLM, vLLM, Ollama, workers média
eai-sandboxBacs à sable des outils et de l'interpréteur de code (gVisor, Kata)
eai-dataPostgreSQL, Redis, NATS, Qdrant, Temporal, LiveKit
eai-securityKeycloak, OpenFGA, OPA
openbaoOpenBao (raft)
observability, observability-agentsPrometheus, OpenSearch, Jaeger, Opik, ClickHouse, OpenTelemetry Collector, Alloy
apisixPasserelle d'API
toolhive-system, mcp-<id>ToolHive Operator et les namespaces du Runtime MCP

Installation : Kubernetes avec Helm.

Topologie de haute disponibilité​

Utilisez values-prod.yaml puis values-ha.yaml sur un cluster d'au moins trois nœuds répartis sur trois zones.

ComposantTopologieSource
API Control Plane3 à 20 réplicas (HPA), PDB minAvailable: 2, anti-affinité de zone obligatoire, répartition par nom d'hôte, arrêt gracieux de 60 svalues-prod.yaml, values-ha.yaml
Portail, LiteLLM3 réplicas minimum, PDB minAvailable: 2values-prod.yaml, values-ha.yaml
Worker1 réplica actif par plan, verrou consultatif PostgreSQL ; les réplicas supplémentaires attendent le verrouvalues.yaml (worker)
PostgreSQLCloudNativePG, 3 instances, bascule automatique, archive WAL vers S3deploy/data/postgres/cluster.yaml
NATS JetStream3 réplicasdeploy/data/nats/values.yaml
Qdrant3 nœuds, 3 shards, 2 réplicas par shard : un nœud peut être perdudeploy/data/qdrant/values.yaml, EAI_QDRANT_*
OpenBaoRaft à 3 nœudsdeploy/openbao/values.yaml
Temporal3 réplicasdeploy/data/temporal/values.yaml
RedisRéplication par l'opérateur ; les limites de débit d'APISIX tolèrent une perte passagère ; aucune sauvegarde nécessaire (cache reconstruit depuis PostgreSQL)deploy/data/redis/values.yaml
vLLMRéplicas d'un modèle sur des nœuds GPU distincts avec vllm.antiAffinity: required, PodDisruptionBudgetvalues.yaml (vllm)
remarque

Un manifeste rendu prouve seulement la configuration (HA_CONFIGURED). Une topologie n'est validée (HA_VALIDATED) qu'après un test de bascule enregistré sur un vrai cluster.

Objectifs de reprise​

Objectifs de Haute disponibilité et PRA :

PérimètreRPORTO
PostgreSQL (CloudNativePG, WAL continu)5 min30 min
Archive d'audit WORM (verrouillage d'objet S3, réplication)0 (écriture synchrone)1 h
Configuration Kubernetes (Velero horaire et GitOps)1 h1 h
Index Qdrant (instantanés quotidiens, réindexation possible)24 h4 h
OpenBao (instantané raft quotidien, raft à 3 nœuds)24 h1 h
Inférence vLLM (sans état)sans objet15 min (modèle depuis le cache)

Multi-site et reprise après sinistre​

Le dépôt fournit un site actif par environnement et un site de reprise restauré depuis les sauvegardes. Un déploiement actif-actif sur plusieurs sites n'est pas fourni : le Navin Manager marque MULTI_CLUSTER comme non pris en charge.

  1. Plusieurs clusters, un seul Argo CD. Un Argo CD central gère plusieurs clusters : enregistrez chacun avec argocd cluster add <contexte-kube> --label eai.io/environment=<env> et ajoutez son adresse dans destinations de deploy/argocd/appproject.yaml. Le second site reçoit les mêmes manifestes depuis Git.
  2. Sauvegardes hors du site. CloudNativePG archive le WAL et une sauvegarde de base quotidienne vers s3://eai-backups/cnpg (conservation 30 jours, chiffrée). Velero lance eai-platform-daily (volumes, pg_dumpall, instantané Qdrant, hooks d'instantané raft OpenBao, 30 jours) et eai-config-hourly (configuration, 7 jours). Répliquez ces buckets et le bucket WORM vers le stockage objet du site de reprise.
  3. Reprise. Sur le cluster de reprise : socle et couche infra, OpenBao restauré depuis son instantané raft, PostgreSQL restauré avec un nouveau Cluster CloudNativePG et bootstrap.recovery (instant donné avec recoveryTarget.targetTime), puis velero restore create --from-backup <sauvegarde> et la couche apps.
  4. Exercice chaque trimestre. Restaurez dans des namespaces isolés (deploy/velero/restore-test.yaml, ou --namespace-mappings enterprise-ai:enterprise-ai-drill), lancez GET /v1/audit/verify, consignez le RPO et le RTO mesurés.
  5. Site isolé. Réinstallez depuis le bundle signé vérifié hors ligne (Installation déconnectée).
attention

La procédure de reprise n'a été validée que hors ligne (manifestes rendus et contrôlés contre les schémas épinglés). Faites l'exercice sur un cluster de recette avant de vous fier aux objectifs ci-dessus.

Étapes suivantes​