Architecture de référence de la base de données PostgreSQL sur GDC sous air gap

Cette architecture de référence fournit un cadre conceptuel pour déployer et exploiter des bases de données PostgreSQL gérées par le client sur Google Distributed Cloud (GDC) sous air gap. Cette solution permet aux organisations de maintenir des charges de travail de base de données critiques en tirant parti d'un cluster multizone à haute disponibilité (HA) déployé sur des machines virtuelles.

L'architecture se concentre sur une configuration résiliente à trois nœuds qui garantit la disponibilité de la base de données, même en cas de défaillance d'une seule zone ou infrastructure. Elle couvre l'ensemble du cycle de vie, du provisionnement et de la mise en réseau automatisés aux opérations de qualité production telles que la haute disponibilité, la sauvegarde, la restauration et l'observabilité.

Fonctionnalités et capacités

La solution fournit plusieurs composants fonctionnels de base pour la gestion des bases de données :

  • Haute disponibilité automatisée : utilisez Patroni et etcd pour fournir une élection et un basculement automatiques du leader, ce qui garantit que la base de données reste opérationnelle sans intervention manuelle.
  • Résilience multizone : distribuez les nœuds de base de données sur trois zones de disponibilité distinctes pour vous protéger contre les pannes matérielles ou d'infrastructure localisées.
  • Automatisation standardisée : provisionnez l'ensemble de la pile à l'aide de playbooks basés sur Ansible avec Autobase pour garantir des déploiements reproductibles et cohérents.
  • Regroupement de connexions : service PgBouncer intégré pour gérer un nombre élevé de connexions et stabiliser la consommation de ressources sur les nœuds de base de données.
  • Équilibrage de charge global : utilisez l'équilibreur de charge L4 global géré par la plate-forme pour fournir une adresse IP virtuelle (VIP) unique et stable, accessible dans toutes leszones.
  • Préparation pour l'air gap : workflows spécialisés pour empaqueter toutes les dépendances et tous les binaires de système d'exploitation requis pour le déploiement dans des environnements déconnectés.
  • Protection des données : utilisez des outils standards tels que pg_dump et pg_basebackup, ainsi que des instantanés de stockage GDC pour maintenir une stratégie de sauvegarde et de récupération robuste.

Architecture

L'architecture se compose d'un environnement à trois VM réparti sur trois zones de disponibilité qui exécutent une pile de services colocalisée.

Architecture à trois VM qui exécute une pile de services colocalisés.

Principes architecturaux

  • Consensus basé sur la majorité : utilise un modèle basé sur le quorum dans lequel une majorité de nœuds (2 sur 3) doivent s'accorder sur l'état du cluster, ce qui empêche les scénarios de "split-brain" et garantit l'intégrité des données.
  • Séparation des préoccupations : chaque VM exécute une pile de services colocalisée, mais distincte (base de données, gestionnaire de haute disponibilité, consensus et pooler) pour fournir un nœud autonome et résilient.
  • Basculement compatible avec la base de données : donne la priorité aux métriques d'état de la base de données avec l'API REST de Patroni pour coordonner la redirection du trafic via l'équilibreur de charge de la plate-forme.
  • Infrastructure as code : s'appuie sur des playbooks automatisés pour toutes les tâches de configuration, ce qui réduit le risque d'erreur humaine lors du déploiement et du scaling.

Concepts et technologies

Cette section décrit les composants fonctionnels, leurs responsabilités et la manière dont ils communiquent au sein du système.

Infrastructure et plate-forme

  • Machines virtuelles (VM) : instances de calcul dédiées réparties sur les zones pour héberger la pile de base de données.
  • Équilibreur de charge L4 global : service géré par la plate-forme qui fournit une adresse IP virtuelle (VIP) stable qui achemine le trafic vers le leader de cluster actuel.
  • Stockage persistant : un stockage hautes performances basé sur SSD est requis pour répondre aux exigences strictes de latence des journaux WAL (Write-Ahead Log) de la couche de consensus.

Services et logique

  • PostgreSQL 17 : moteur de base de données relationnelle principal responsable de la persistance des données et de l'exécution des requêtes.
  • Patroni : gestionnaire de haute disponibilité qui surveille le processus PostgreSQL local et coordonne les élections de leader à l'aide d'etcd.
  • etcd : magasin de configuration distribué qui fournit la couche de consensus et contient l'état faisant autorité du cluster.
  • PgBouncer : pooler de connexions léger qui se trouve devant PostgreSQL pour gérer efficacement les connexions d'application entrantes.

Flux de données et interfaces

  • PgBouncer (port 6432) : point d'entrée principal pour le trafic de base de données de l'application.
  • API Patroni (port 8008) : interface REST HTTPS utilisée par l'équilibreur de charge pour effectuer des vérifications d'état et identifier le leader actuel à l'aide du point de terminaison /primary.
  • etcd (port 2379) : canal de communication permettant au cluster de consensus de maintenir l'état et d'effectuer des élections.

Remarques

  • Évolutivité et performances :
    • Les nœuds de base de données doivent être dimensionnés en fonction de la charge de travail, avec un minimum de deux processeurs virtuels et 8 Gio de RAM. Les charges de travail de production commencent généralement à huit processeurs virtuels et 32 Gio.
    • Les performances dépendent d'un stockage à faible latence. Les SSD sont nécessaires pour garantir qu'etcd peut traiter les synchronisations de données en moins de 10 ms.
    • Réplication synchrone : la surcharge de la réplication synchrone dépend directement de la latence du réseau interzone. Pour garantir des performances optimales pour les configurations sans perte de données, une faible latence interzone est requise.
  • Gestion des ressources et licences :
    • Cette solution s'appuie sur des composants de base de données Open Source sans frais.
    • Autobase est utilisé comme outil d'automatisation de référence pour simplifier l'installation et la configuration de la pile HA. Toutefois, l'architecture n'est pas exclusivement liée à Autobase, et les composants Open Source sous-jacents peuvent être gérés à l'aide de pipelines personnalisés.
    • Pour les organisations qui ont besoin d'une assistance formelle pour le package d'automatisation, une assistance payante tierce est disponible.
    • Le regroupement de connexions avec PgBouncer est essentiel pour éviter l'épuisement du processeur et de la mémoire causé par un nombre élevé de connexions utilisateur.
  • Disponibilité et fiabilité :
    • La haute disponibilité est obtenue grâce à un quorum à trois nœuds. La défaillance d'un seul nœud ou d'une seule zone n'interrompt pas le service.
    • Stabilité du cluster : le maintien d'un quorum fiable nécessite une faible latence réseau entre les nœuds. Les temps d'aller-retour moyens doivent idéalement être inférieurs à 10 ms pour éviter les délais d'attente d'élection et l'instabilité du cluster.
  • Gestion opérationnelle :
    • Les tâches de routine telles que l'application de correctifs de version mineure et les mises à niveau majeures restent la responsabilité de l'équipe d'exploitation du client.
    • Les sorties de stdout des VM sont automatiquement ingérées dans la plate-forme de surveillance GDC sous air gap. Un guide sera publié ultérieurement sur l'intégration d'une surveillance plus détaillée pour les composants individuels.
    • Une stratégie de sauvegarde robuste doit être mise en œuvre à l'aide d'outils natifs de la base de données et d'instantanés de la plate-forme. Des guides détaillés pour ces procédures seront publiés séparément.

Décision de conception

Les choix architecturaux de cette solution offrent un chemin résilient pour les déploiements multizones.

Machines virtuelles sur Kubernetes

Une approche basée sur les VM a été sélectionnée pour fournir une haute disponibilité multizone. GDC n'est pas compatible avec les clusters Kubernetes qui s'étendent sur plusieurs zones physiques. Par conséquent, le déploiement de VM dédiées dans des zones distinctes est nécessaire pour obtenir une architecture interzone robuste. Cette configuration peut survivre à la défaillance totale d'une seule zone d'infrastructure.

Équilibrage de charge global natif de la plate-forme

L'architecture exploite l'équilibreur de charge L4 global GDC au lieu de proxys logiciels sur les VM. Cette approche présente plusieurs avantages :

  • Portée mondiale : fournit une adresse IP virtuelle stable accessible dans toutes les zones.
  • Gestion par la plate-forme : l'adresse IP virtuelle est gérée indépendamment par le plan de contrôle de la plate-forme.
  • Basculement simplifié : le basculement est géré via des sondes de vérification d'état standards plutôt que des configurations logicielles locales complexes.
  • Haute disponibilité : la suppression de la dépendance aux proxys locaux garantit que le point d'entrée du trafic de base de données reste résilient.

Hypothèses et limites

Hypothèses

  • L'environnement dispose d'un registre ou d'un mécanisme local pour importer les dépendances et les binaires de système d'exploitation empaquetés.
  • L'accès SSH basé sur des clés est disponible pour toutes les VM cibles pour l'automatisation basée sur Ansible.
  • Le projet dispose d'un quota suffisant pour le provisionnement de VM et d'équilibrage de charge multizones.

Limites

  • Maintenance manuelle : l'application de correctifs au système d'exploitation et les mises à niveau de version de PostgreSQL sont des tâches manuelles et ne sont pas automatisées par la solution.
  • Sensibilité du stockage : la couche de consensus (etcd) est très sensible à la latence du disque. Une contention de stockage élevée et soutenue peut avoir un impact sur la stabilité de la couche de consensus.
  • Stabilité du réseau : le gestionnaire de haute disponibilité s'appuie sur une connectivité réseau cohérente et à faible latence entre les zones. Les retards ou la gigue du réseau peuvent influencer le calendrier de coordination du cluster et les transitions de rôle.

Autres ressources