SUPFile — conception d'une architecture multi-datacenter résiliente

Objectif

Projet d’architecture réalisé en équipe de quatre autour d’une plateforme de stockage de fichiers répartie sur plusieurs datacenters. Le travail portait principalement sur la conception, le dimensionnement, les choix technologiques, la résilience, les sauvegardes, les coûts et le plan d’exploitation. Un PoC distinct a ensuite validé une partie de la faisabilité technique.

Cette fiche décrit donc d’abord une architecture cible : elle n’a pas été déployée dans son ensemble.

Ma contribution

Mon rôle dans l’équipe était celui d’architecte données, stockage et sauvegarde. Au-delà de ce périmètre, j’ai pris une grande part de la conception globale et de la documentation : le dimensionnement et le matériel envisagé, le budget, les choix technologiques et la fiabilité. Les décisions d’architecture et les schémas ont été confrontés en continu avec l’architecte principal du projet.

Concevoir une architecture multi-datacenter

L’architecture cible répartit la plateforme sur trois sites. Paris et New York sont actifs et servent tous deux les utilisateurs, avec une répartition géographique du trafic (GSLB / GeoDNS). Toronto n’est pas exposé : il est réservé à la sauvegarde, à la rétention et à la reprise après sinistre.

Une décision structurante : ne pas étirer un cluster entre les continents. Chaque site actif dispose de son propre cluster Kubernetes et de son propre stockage. La latence intercontinentale rendrait un cluster étiré fragile, et des sites indépendants limitent le domaine de panne : la perte d’un site n’entraîne pas l’autre. Les données circulent entre les sites par réplication asynchrone, au travers de liaisons chiffrées et filtrées.

Données, stockage et résilience

PostgreSQL est conçu pour être hautement disponible sur chaque site, avec Patroni. Pour que les deux sites actifs puissent écrire sans conflit, les données sont partitionnées : chaque utilisateur a un site de rattachement, seul autorisé à écrire ses données, qui sont ensuite répliquées vers l’autre site.

Le stockage sépare deux besoins. Les fichiers des utilisateurs sont confiés à CephFS, un système de fichiers distribué local à chaque site. Les volumes bloc critiques — notamment ceux de PostgreSQL — reposent sur un SAN iSCSI dédié. Chaque type de donnée reçoit ainsi le stockage adapté à son usage, et une défaillance de l’un ne touche pas l’autre.

Sauvegarde et PRA

La réplication ne remplace pas la sauvegarde : une suppression ou une corruption se réplique aussi vite qu’une donnée saine. La stratégie de sauvegarde est donc conçue indépendamment. Toronto reçoit chaque jour les sauvegardes de PostgreSQL, des fichiers et des volumes critiques. Pour PostgreSQL, l’archivage continu des journaux (WAL) permet une restauration à un instant précis (PITR). Des snapshots locaux réguliers accélèrent les restaurations courantes, et l’archivage longue durée sur bandes LTO-9 complète la rétention. Le plan de reprise s’appuie sur une zone de restauration à Toronto et sur des procédures de restauration documentées.

Dimensionnement et budget

Le projet ne se limitait pas à un schéma : chaque site a été dimensionné, le matériel envisagé détaillé, et le coût estimé en investissement (CAPEX) et en fonctionnement (OPEX), avec ses hypothèses. Le budget faisait partie des contraintes de l’architecture, au même titre que la résilience ou la sécurité.

Validation par un PoC limité

Pour confronter certaines hypothèses à une implémentation réelle, l’équipe a réalisé un PoC limité, mené principalement par un autre membre de l’équipe. Il reproduit les trois sites avec trois machines virtuelles Debian, chacune portant un cluster k3s à un seul nœud. PostgreSQL y est géré par l’opérateur CloudNativePG : une instance principale à Paris, des répliques en lecture seule à New York et à Toronto, en réplication asynchrone. Une application de démonstration tourne sur les deux sites actifs, derrière un répartiteur Nginx.

Ce que le PoC valide — et ce qu’il ne valide pas

La réplication PostgreSQL entre sites a été implémentée et testée : une donnée insérée à Paris est lue à New York et à Toronto. La répartition de charge entre les deux sites actifs a également été démontrée pendant la soutenance.

Le PoC ne valide pas le reste de l’architecture cible : ni CephFS, ni le SAN iSCSI, ni Patroni ou l’écriture partitionnée sur deux sites, ni la haute disponibilité de Kubernetes, ni la répartition géographique du trafic, ni le chiffrement entre datacenters ou les protections de sécurité prévues, ni la sauvegarde vers Toronto, le PITR, les bandes ou le plan de reprise. Sa réplication circule d’ailleurs sans chiffrement, sur un réseau de laboratoire : il ne constitue pas une preuve de la sécurité de la cible.