AlloyDB Omni fournit une plate-forme d'orchestration pour déployer et gérer AlloyDB Omni dans des environnements non Kubernetes, par exemple sur Red Hat Enterprise Linux (RHEL) et les systèmes compatibles qui utilisent des packages Red Hat Package Manager (RPM). L'option de déploiement de l'orchestrateur RPM étend la flexibilité et l'automatisation du cloud à l'infrastructure sur site et de machine virtuelle (VM).
AlloyDB Omni avec l'orchestrateur RPM permet aux entreprises d'installer, de configurer et de gérer des instances AlloyDB Omni à l'aide de packages RPM standards. Cette approche s'adresse aux organisations qui ont investi massivement dans l'infrastructure de VM et qui ont établi des pratiques opérationnelles basées sur des outils d'automatisation, comme Ansible. L'option de déploiement de l'orchestrateur RPM s'exécute directement sur des VM Linux ou des serveurs physiques sans nécessiter de couche de conteneurisation comme Docker ni de système d'orchestration comme Kubernetes.
Cas d'utilisation
L'option de déploiement de l'orchestrateur RPM est compatible avec les cas d'utilisation suivants :
| Cas d'utilisation | Description |
|---|---|
| Entreprises disposant d'une infrastructure de VM | Convient aux entreprises pour lesquelles Kubernetes n'est pas la norme, ou aux environnements conteneurisés avec des dépendances d'application qui préfèrent les déploiements de VM standards ou Bare Metal. |
| Opérations simplifiées | Automatisez le déploiement, la configuration et la gestion du cycle de vie des bases de données à l'aide d'outils connus, comme Ansible. |
| Haute disponibilité (HA) et reprise après sinistre (DR) | Configure des clusters AlloyDB Omni résilients avec des mécanismes de basculement et de récupération automatiques. |
| Environnements hybrides | Assure des opérations de base de données cohérentes dans les centres de données sur site et les VM cloud. |
| Intégration des anciens systèmes | S'intègre aux applications et systèmes existants conçus pour les environnements non conteneurisés. |
Avantages
Voici les avantages de l'option de déploiement de l'orchestrateur RPM :
- Déploiement rapide : automatise l'ensemble du cycle de vie, du provisionnement à la validation, ce qui réduit considérablement le temps et la complexité de la configuration des clusters AlloyDB Omni.
- Intégration fluide : s'intègre de manière native à la gestion des packages Linux standards (RPM) et aux frameworks d'automatisation populaires, par exemple Ansible, ce qui permet aux équipes d'utiliser les compétences et les intégrations d'outils existantes.
- Expérience cohérente : offre une expérience utilisateur et un ensemble de caractéristiques pour la gestion et les opérations comparables à l'opérateur Kubernetes AlloyDB Omni, qui assure la cohérence entre les différents modèles de déploiement.
- Haute disponibilité et reprise après sinistre de niveau Enterprise : prend en charge des configurations flexibles pour la haute disponibilité et la reprise après sinistre afin de répondre aux besoins de continuité des activités.
- Sécurité robuste : facilite l'implémentation de stratégies de sécurité multifacettes, y compris la gestion des utilisateurs, la sécurité du réseau avec des certificats (SSL) et l'intégration aux systèmes, par exemple Microsoft Active Directory.
- Gestion centralisée : utilise le service AlloyDB Omni pour fournir un plan de contrôle unifié permettant de gérer AlloyDB Omni sur les VM.
- Observabilité et audit : permet l'intégration à des serveurs de journalisation externes (par exemple, Elastic Stack) à l'aide de rsyslog pour la gestion, la surveillance et l'audit centralisés des journaux.
- Protection des données : inclut des fonctionnalités permettant de simplifier les configurations et les stratégies de sauvegarde et de restauration.
- Regroupement de connexions : permet de déployer PgBouncer pour optimiser les connexions à la base de données et améliorer les performances.
- Gestion de parc : vous permet de gérer plusieurs clusters AlloyDB Omni à grande échelle.
Architecture
AlloyDB Omni définit une hiérarchie de composants qui offre de la flexibilité. Cette flexibilité vous aide à maximiser la disponibilité des données et à optimiser les performances et le débit des requêtes. Cette approche vous permet de surveiller votre déploiement AlloyDB Omni et d'ajuster son échelle et sa taille en fonction de vos charges de travail.
La figure suivante montre la taxonomie du déploiement AlloyDB Omni dans un environnement bare metal ou de VM.
Fig. 1. Topologie de déploiement de VM AlloyDB Omni
La ressource de premier niveau de la hiérarchie est un déploiement AlloyDB Omni qui comporte un cluster principal et un ou plusieurs clusters secondaires. Un cluster AlloyDB Omni comporte une ou plusieurs instances, qui sont une abstraction des ressources de calcul auxquelles les utilisateurs se connectent. Le cluster inclut une instance principale (lecture et écriture) et une ou plusieurs instances de pool de lecture facultatives (lecture seule). Chaque instance possède son propre point de terminaison d'accès. Vous pouvez éventuellement configurer une instance principale avec un seul nœud pour un déploiement autonome ou plusieurs nœuds pour un déploiement à disponibilité élevée. Tous les nœuds sont déployés avec AlloyDB Omni et d'autres composants associés à l'aide des packages logiciels.
L'instance principale contient un nœud actif (lecture/écriture) conçu pour gérer les charges de travail transactionnelles. Pour les clusters de bases de données qui vont au-delà des tests, des expériences et du développement de base, configurez la haute disponibilité avec des nœuds de secours supplémentaires. Pour éviter toute perte de données (RPO=0) en cas de défaillance entraînant une perte de disponibilité d'un nœud principal qui traite les transactions de lecture et d'écriture, configurez le mode de réplication synchronisé du nœud de secours. RPO est défini comme l'objectif de point de récupération.
Composants
L'option de déploiement de l'orchestrateur RPM inclut un ensemble de composants logiciels, chacun installé en tant que package RPM ou Debian, pour un déploiement AlloyDB Omni complet et à disponibilité élevée. L'architecture de référence s'appuie sur ces composants pour les opérations de base de données.
| Composant | Description |
|---|---|
| Outil d'orchestration | L'orchestration AlloyDB Omni fournit des interfaces de ligne de commande et Ansible pour vous aider à déployer et à gérer un ou plusieurs clusters AlloyDB Omni dans un environnement distribué. |
| alloydbomni | Le cœur d'AlloyDB Omni inclut PostgreSQL et des fonctionnalités de pilote automatique pour améliorer les performances et les capacités permettant de prendre en charge les charges de travail modernes, par exemple le traitement analytique en ligne (OLAP) et l'IA générative. |
| alloydbomni_monitor | Le contrôleur AlloyDB Omni vous permet d'extraire des métriques d'AlloyDB Omni. |
| etcd | etcd fournit un système de configuration distribué que le gestionnaire de cluster utilise pour stocker les informations de configuration et d'état de PostgreSQL. |
| Gestionnaire de cluster | Le plan de contrôle central orchestre les opérations à l'échelle du cluster. Cela inclut l'amorçage du cluster, la gestion de la haute disponibilité, la gestion du basculement, la coordination des mises à niveau et l'exposition des interfaces pour les outils d'automatisation, par exemple Ansible et l'utilitaire de ligne de commande alloydbctl. |
| Gestionnaire de nœuds | Agent qui s'exécute sur chaque nœud du cluster AlloyDB Omni. Il interagit avec le gestionnaire de cluster pour exécuter des tâches sur le nœud, par exemple installer et configurer AlloyDB Omni, gérer le cycle de vie du service de base de données (démarrer et arrêter), surveiller l'état du nœud et collecter les journaux et les métriques. |
| HAProxy | HAProxy fonctionne comme un équilibreur de charge pour les déploiements AlloyDB Omni. Il expose les points de terminaison en lecture-écriture et en lecture seule. Il fonctionne avec le gestionnaire de cluster pour rediriger le trafic vers les nœuds actifs appropriés. |
| keepalived | keepalived peut fournir une haute disponibilité pour les nœuds participants, par exemple HAProxy, à l'aide d'une adresse IP virtuelle flottante. |
| PgBouncer | PgBouncer est un pooler de connexion léger pour les bases de données PostgreSQL. |
| pgBackRest | pgBackRest est un outil Open Source de sauvegarde et de restauration conçu pour PostgreSQL. |
Cette architecture vous permet d'exécuter et d'exploiter AlloyDB Omni de manière efficace dans votre environnement de VM Linux existant, en combinant AlloyDB Omni avec la familiarité de vos pratiques opérationnelles établies.
Configuration requise
La configuration système requise pour la pile de déploiement AlloyDB Omni inclut un ensemble de machines virtuelles préconfigurées pour exécuter différents composants. Chaque machine virtuelle AlloyDB Omni doit disposer d'un disque de données associé configuré avec le système de fichiers ext4/xfs. La taille du disque est estimée à partir de la taille des données. Les caractéristiques de performances du stockage ont un impact sur les performances d'AlloyDB Omni. Le tableau suivant indique les configurations minimales et recommandées de processeur et de mémoire pour les VM.
| Type de VM | Configuration matérielle et système d'exploitation (OS) minimaux | Matériel et OS recommandés |
|---|---|---|
| Nœud de contrôleur |
|
|
| Nœuds d'équilibrage de charge |
|
|
| AlloyDB Omni (autonome) |
|
|
| AlloyDB Omni (disponibilité élevée) |
|
|
| Nœud du dépôt de sauvegarde |
|
|
Architecture de référence pour le déploiement HA
L'architecture haute disponibilité offre une protection renforcée contre les temps d'arrêt au niveau des données par rapport aux configurations de base de données à nœud unique. Cette configuration d'architecture de référence utilise une configuration à trois nœuds, avec un nœud principal actif et les autres nœuds en tant que serveurs de secours répliqués par flux synchrone, déployés dans des zones distinctes. En cas de défaillance d'un nœud principal, l'un des nœuds de secours prend le relais en tant que nœud principal pour traiter les requêtes des clients.
Le composant du gestionnaire de cluster dans la pile logicielle effectue la configuration du cluster. Le gestionnaire de cluster surveille également le serveur AlloyDB Omni et choisit la nouvelle instance principale à l'aide d'un système de configuration distribué, par exemple etcd. Les entreprises utilisent le RPO et le RTO (Recovery Time Objective, objectif de temps de récupération) comme mesures clés de la disponibilité. La configuration de l'architecture HA offre un RPO et un RTO quasi nuls en cas de défaillance au niveau de la zone.
Un nœud supplémentaire déploie un équilibreur de charge basé sur HAProxy, avec des points de terminaison supplémentaires configurés pour les charges de travail en lecture seule. HAProxy fonctionne avec le gestionnaire de cluster pour surveiller le nœud actif actuel et basculer vers le nouveau nœud actif en cas de basculement. Les clients se connectent au nœud HAProxy pour effectuer des opérations sur la base de données. L'image suivante illustre cette architecture de déploiement à haute disponibilité.
Fig. 2 : Architecture de déploiement à haute disponibilité
Orchestrateur RPM
AlloyDB Omni utilisant l'orchestrateur RPM fournit une plate-forme d'automatisation et un plan de contrôle pour installer, configurer et gérer les clusters de bases de données AlloyDB Omni sur un ensemble de VM ou de serveurs bare metal. Cela inclut différentes configurations d'architecture de référence, par exemple, la haute disponibilité (HA) autonome, résiliente et évolutive.
Le gestionnaire de clusters AlloyDB Omni fournit le plan de contrôle. Ce composant est le service principal qui automatise la gestion et la haute disponibilité du cluster AlloyDB Omni pour vous aider à contrôler le cycle de vie complet d'un cluster AlloyDB Omni. Le plan de contrôle lui-même est disponibilité élevée et gère différents scénarios d'échec.
L'option de déploiement de l'orchestrateur RPM est l'interface à distance permettant de communiquer avec le service de gestionnaire de cluster AlloyDB Omni. L'orchestrateur s'exécute sur un nœud dédié, appelé nœud de contrôle. À partir de ce nœud, vous pouvez gérer un ou plusieurs clusters à distance via un canal sécurisé. Plusieurs orchestrateurs AlloyDB Omni sont disponibles pour assurer la compatibilité avec votre environnement. Choisissez un orchestrateur adapté à vos besoins d'automatisation.
- Interface de ligne de commande de l'orchestrateur AlloyDB Omni (disponible au format RPM) : recommandée pour les environnements qui utilisent des scripts shell pour automatiser le déploiement et la gestion des clusters.
- Orchestrateur RPM Ansible (disponible en tant qu'Ansible Collection) : recommandé pour les environnements qui utilisent l'automatisation intégrée basée sur Ansible et qui sont prêts à l'étendre avec des appels à des rôles Ansible supplémentaires. Des exemples de playbooks Ansible sont fournis pour permettre une intégration simple avec les playbooks Ansible existants.
L'orchestrateur AlloyDB Omni facilite les opérations suivantes liées aux clusters AlloyDB Omni. L'orchestrateur basé sur Ansible fournit des rôles Ansible pour chacune de ces opérations. La ligne de commande fournit un ensemble de commandes appelées à l'aide d'une invite shell ou de scripts shell.
Installation: installe différents composants de cluster sur les nœuds respectifs.Bootstrap: configure et amorce tous les composants en fonction de leurs spécifications.Update: mettez à jour les ressources pour les versions plus récentes ou les configurations modifiées.Status: obtenez l'état de tous les composants ou services du cluster.List: obtenez la liste des ressources disponibles déployées dans le cluster.Delete: supprime les ressources du cluster.
Les orchestrateurs prennent en entrée un ensemble de spécifications au format YAML.
- Spécification du déploiement : elle est identique au format de l'inventaire Ansible qui définit la topologie du cluster de VM. Il contient différents groupes de VM, par exemple les suivants, ainsi que leurs configurations.
primary_instance_nodes: nœuds dédiés aux serveurs de bases de données AlloyDB Omni.cluster_manager_nodes: facultatif. Nœuds exécutant les serveurs du gestionnaire de cluster AlloyDB Omni. S'il n'existe aucun nœud de gestionnaire de cluster dédié, vous pouvez déployer le gestionnaire de cluster surprimary_instance_nodes.etcd_nodes: le gestionnaire de cluster stocke les métadonnées sur etcd. etcd peut s'exécuter sur les mêmes nœuds que les nœuds du gestionnaire de cluster s'il n'est pas spécifié explicitement.load_balancer_nodes: il s'agit de nœuds supplémentaires dédiés à un équilibreur de charge basé sur HAProxy.
- Spécification des ressources : un cluster se compose d'une ou de plusieurs ressources de cluster à déployer et à gérer, par exemple des clusters de bases de données et des poolers de connexion. La spécification de ressource est au format YAML et décrit les ressources à déployer dans le cluster.
Limites
- La version Preview n'est compatible qu'avec les éléments suivants :
- AlloyDB Omni PostgreSQL 18
- Packages logiciels compatibles avec RHEL version 9
- Plate-forme Intel x86 64 bits
- Les mises à niveau de versions majeures ne sont pas acceptées.
- Les instructions pour configurer la reprise après sinistre et les instances de pool de lecture ne sont pas incluses.
- La surveillance AlloyDB Omni n'est pas compatible avec les connexions SSL. Vous devez déployer vos serveurs de tableau de bord de surveillance sur le même réseau privé que les nœuds AlloyDB Omni.
- AlloyDB Omni suppose que SELinux, lorsqu'il est présent, est configuré sur l'hôte pour être permissif, y compris l'accès au système de fichiers.
Étapes suivantes
- Choisissez une option de téléchargement et d'installation d'AlloyDB Omni.
- Installez l'orchestrateur AlloyDB Omni.