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 RPM (Red Hat Package Manager). L'option de déploiement de l'orchestrateur RPM étend la flexibilité et l'automatisation de type cloud à l'infrastructure sur site et de machines virtuelles (VM).
AlloyDB Omni avec l'outil d'orchestration RPM permet aux entreprises d'installer, de configurer et de gérer des instances AlloyDB Omni à l'aide de packages RPM standards. Cette approche est adaptée 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, par exemple Ansible. L'option de déploiement de l'orchestrateur RPM s'exécute directement sur des VM Linux ou des serveurs bare metal sans nécessiter de couche de conteneurisation comme Docker ni de système d'orchestration comme Kubernetes.
Pour commencer à utiliser cette option de déploiement, demandez l'accès à l'aide du formulaire d'inscription.
Cas d'utilisation
L'option de déploiement de l'outil d'orchestration RPM est compatible avec les cas d'utilisation suivants :
| Cas d'utilisation | Description |
|---|---|
| Entreprises disposant d'une infrastructure de VM | Il est compatible avec les entreprises où Kubernetes n'est pas standard, ou avec les 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 | Automatise le déploiement, la configuration et la gestion du cycle de vie des bases de données à l'aide d'outils familiers, 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 la cohérence des opérations de base de données entre 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'intégralité du cycle de vie, du provisionnement à la vérification, ce qui réduit considérablement le temps et la complexité de la configuration des clusters AlloyDB Omni.
- Intégration parfaite : s'intègre de manière native à la gestion des packages Linux standard (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 : fournit une expérience utilisateur et un ensemble de caractéristiques de gestion et d'exploitation comparables à l'opérateur Kubernetes AlloyDB Omni, ce qui garantit la cohérence entre les différents modèles de déploiement.
- Haute disponibilité et reprise après sinistre de niveau entreprise : accepte 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 la mise en œuvre de stratégies de sécurité à plusieurs facettes, y compris la gestion des utilisateurs, la sécurité du réseau avec des certificats (SSL) et l'intégration à des 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 des 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 pour 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 offrent 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 scaling et sa taille en fonction de vos charges de travail.
La ressource de premier niveau de la hiérarchie est un déploiement AlloyDB Omni qui comprend 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/é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 disposent d'AlloyDB Omni et d'autres composants associés déployés à l'aide des packages logiciels.
L'instance principale contient un nœud actif (en lecture/écriture) conçu pour gérer les charges de travail transactionnelles. Pour les clusters de bases de données au-delà des tests, des tests 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 et atteindre un objectif de point de récupération (RPO) de zéro en cas de défaillance du nœud principal, configurez le mode de réplication synchrone du nœud de secours.
Haute disponibilité résiliente
Une architecture HA résiliente déploie un nœud principal actif et des nœuds de secours dans des zones distinctes, sans nœuds d'équilibreur de charge dédiés.
À la place, le service keepalived s'exécute directement sur les nœuds de base de données pour gérer une adresse IP virtuelle flottante qui expose le point de terminaison en lecture-écriture sur le nœud principal actif.
La figure suivante illustre l'architecture de déploiement de haute disponibilité résiliente dans un environnement bare metal ou de VM :
Fig. 1. Architecture de déploiement de haute disponibilité résiliente d'AlloyDB Omni
Haute disponibilité évolutive
Une architecture HA évolutive déploie un nœud principal actif et des nœuds de secours dans des zones distinctes, associés à des nœuds d'équilibreur de charge HAProxy dédiés. Ces nœuds d'équilibreur de charge exposent les points de terminaison en lecture/écriture et en lecture seule, et acheminent le trafic client.
La figure suivante illustre la taxonomie d'un déploiement AlloyDB Omni à haute disponibilité évolutif dans un environnement bare metal ou de VM :
Fig. 2. Architecture de déploiement de VM à haute disponibilité évolutive AlloyDB Omni
Composants
L'option de déploiement de l'outil d'orchestration RPM inclut un ensemble de composants logiciels, chacun installé en tant que package RPM ou Debian, pour un déploiement AlloyDB Omni full stack à 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 Autopilot pour améliorer les performances et les capacités de prise en charge des charges de travail modernes, par exemple le traitement analytique en ligne (OLAP) et l'IA générative. |
| alloydbomni_monitor | Le moniteur AlloyDB Omni vous permet d'extraire des métriques d'AlloyDB Omni. |
alloydbomni_ui (facultatif) |
L'interface utilisateur Web AlloyDB Omni est une console Web autogérée qui fournit des tableaux de bord d'observabilité pour les instances de cluster, des graphiques de télémétrie système, des tailles de base de données, des indicateurs de base de données actifs, des statistiques sur le moteur de données en colonnes et des insights sur les requêtes. |
| 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œud | Un 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émarrage et arrêt), surveiller l'état du nœud, et collecter des journaux et des 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 outil de regroupement de connexions 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 efficacement dans votre environnement de VM Linux existant, en combinant AlloyDB Omni avec vos pratiques opérationnelles habituelles.
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 divers composants. Chaque machine virtuelle AlloyDB Omni doit être associée à un disque de données 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 une incidence sur les performances d'AlloyDB Omni. Le tableau suivant indique les configurations de processeur et de mémoire minimales et recommandées pour les VM.
| Type de VM | Configuration matérielle et système d'exploitation minimale | 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 de dépôt de sauvegarde |
|
|
Architecture de référence pour un déploiement à haute disponibilité
L'architecture haute disponibilité offre une protection accrue contre les temps d'arrêt au niveau des données par rapport aux configurations de base de données à nœud unique. Les deux architectures de référence haute disponibilité utilisent une configuration de base de données multinœud (groupe primary_instance_nodes) avec un nœud principal actif et des nœuds de secours répliqués en flux synchrone, déployés dans des zones distinctes. En cas de défaillance du nœud principal, un nœud de secours prend le relais en tant que nœud principal pour traiter les requêtes des clients.
Le composant de gestion de cluster de la pile logicielle effectue la configuration du cluster, surveille l'état du serveur AlloyDB Omni et orchestre le basculement automatique en choisissant le nouveau serveur principal à l'aide d'un système de configuration distribué tel qu'etcd. Les entreprises utilisent le RPO et l'objectif de temps de récupération (RTO) comme mesures clés de la disponibilité. Les configurations d'architecture de haute disponibilité offrent un RPO et un RTO quasi nuls en cas de défaillance au niveau de la zone. Vous pouvez également configurer des sauvegardes et des instances de pool de lecture facultatives avec la réplication asynchrone pour décharger les charges de travail en lecture seule.
En fonction de vos exigences de charge de travail et de routage, vous pouvez déployer AlloyDB Omni en utilisant l'architecture HA résiliente, qui fonctionne sans nœuds d'équilibreur de charge dédiés, ou l'architecture HA évolutive, qui inclut des nœuds d'équilibreur de charge dédiés :
Haute disponibilité résiliente
L'architecture de haute disponibilité résiliente déploie les nœuds de base de données (groupe primary_instance_nodes) sans nœuds d'équilibreur de charge dédiés :
- Routage d'adresse IP virtuelle : le service
keepaliveds'exécute directement sur les nœuds de base de données et gère une adresse IP virtuelle flottante qui pointe vers le nœud principal actif. Cette configuration expose le point de terminaison en lecture/écriture directement sur le nœud actif. Les applications clientes se connectent à la base de données à l'aide de l'adresse IP virtuelle. En cas de basculement et si un nœud de secours est promu au rang de nœud principal, le servicekeepalivedbascule automatiquement l'adresse IP virtuelle vers le nouveau nœud principal actif. - Regroupement de connexions : si vous utilisez PgBouncer pour le regroupement de connexions, il s'exécute directement sur les nœuds de base de données.
Haute disponibilité évolutive
L'architecture de haute disponibilité évolutive ajoute des nœuds d'équilibreur de charge dédiés (groupe load_balancer_nodes) au cluster de base de données :
- Équilibrage de charge HAProxy : les nœuds d'équilibrage de charge dédiés exécutent HAProxy, qui expose les points de terminaison en lecture-écriture et en lecture seule. HAProxy fonctionne avec le gestionnaire de cluster pour surveiller l'état des nœuds, acheminer les requêtes de lecture/écriture vers le nœud principal actif et répartir les requêtes en lecture seule entre les nœuds de secours opérationnels ou les instances de pool de lecture facultatives. En cas de basculement, HAProxy bascule automatiquement le trafic en lecture-écriture vers le nouveau nœud actif.
- Haute disponibilité de l'équilibreur de charge : le service
keepaliveds'exécute sur les nœuds de l'équilibreur de charge et gère une adresse IP virtuelle flottante sur ces nœuds. Les clients se connectent à l'équilibreur de charge HAProxy à l'aide de cette adresse IP virtuelle pour effectuer des opérations de base de données. En cas de défaillance du service HAProxy actif ou du nœud d'équilibreur de charge, le servicekeepalivedmigre l'adresse IP virtuelle vers un autre nœud d'équilibreur de charge. - Regroupement de connexions : si vous utilisez PgBouncer pour le regroupement de connexions, il s'exécute sur les nœuds d'équilibreur de charge dédiés, aux côtés de HAProxy et de
keepalived.
L'image suivante illustre l'architecture de déploiement haute disponibilité :
Fig. 3. Architecture de déploiement à haute disponibilité
Outil d'orchestration RPM
AlloyDB Omni avec l'outil d'orchestration RPM fournit une plate-forme d'automatisation et un plan de contrôle pour installer, configurer et gérer des 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, une haute disponibilité (HA) autonome, résiliente et évolutive.
Le gestionnaire de cluster 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 de bout en bout d'un cluster AlloyDB Omni. Le plan de contrôle lui-même est disponibilité élevée et gère différents scénarios de défaillance.
L'option de déploiement de l'outil d'orchestration RPM est l'interface distante permettant de communiquer avec le service de gestion 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é. Pour assurer la compatibilité avec votre environnement, plusieurs outils d'orchestration AlloyDB Omni sont disponibles. Choisissez un outil d'orchestration adapté à vos besoins d'automatisation.
- CLI de l'outil d'orchestration AlloyDB Omni (disponible au format RPM) : cette option est 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 que collection Ansible) : 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 aux playbooks Ansible existants.
L'outil d'orchestration 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 de shell ou de scripts shell.
Installation: installez divers composants de cluster sur les nœuds correspondants.Bootstrap: configurez et amorcez tous les composants conformément à leurs spécifications.Update: mettez à jour les ressources pour les versions plus récentes ou les configurations mises à jour.Status: obtenez l'état de tous les composants ou services du cluster.Delete: supprimez 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 d'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 base de données AlloyDB Omni.cluster_manager_nodes: facultatif. Nœuds exécutant des serveurs de gestion de clusters AlloyDB Omni. S'il n'existe pas de nœuds de gestionnaire de cluster dédiés, vous pouvez déployer le gestionnaire de cluster sur leprimary_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, sauf indication contraire.load_balancer_nodes: facultatif. Nœuds supplémentaires dédiés à un équilibreur de charge basé sur HAProxy dans un déploiement haute disponibilité évolutif. Si ce champ est omis,keepalivedet PgBouncer s'exécutent directement sur les nœuds du groupeprimary_instance_nodesdans un déploiement HA résilient.
- 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 connexions. La spécification de ressource est au format YAML et décrit les ressources à déployer dans le cluster.
Limites
- L'option de déploiement de l'outil d'orchestration RPM 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 version majeure ne sont pas acceptées.
- Les instructions de configuration de la reprise après sinistre et des 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 est compatible avec SELinux en mode permissif et en mode forcé. Vous devez configurer le mode SELinux sélectionné avant d'amorcer le cluster. Il n'est pas possible de passer en mode forcé après l'amorçage.
Étapes suivantes
- Pour commencer à utiliser cette option de déploiement, demandez l'accès à l'aide du formulaire d'inscription.
- Choisissez une option de téléchargement et d'installation d'AlloyDB Omni.
- Installez l'outil d'orchestration AlloyDB Omni.
- Installez l'UI Web.