Architecture de référence pour une base de données Oracle autogérée

Cette architecture de référence fournit un cadre conceptuel pour déployer et exploiter des bases de données Oracle autogérées sur Google Distributed Cloud (GDC) sous air gap. Cette solution vous permet de gérer les charges de travail de base de données critiques à l'aide de l'opérateur officiel Oracle Database Operator for Kubernetes sur des clusters standards.

L'architecture est axée sur l'activation d'un modèle BYOL (Bring-Your-Own-License, utilisation de votre propre licence), qui vous permet de déployer des bases de données standardisées, sécurisées et disponibilité élevée dans des environnements isolés. Elle couvre l'ensemble du cycle de vie, du provisionnement et de la mise en réseau aux opérations de niveau 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 :

  • Gestion automatisée du cycle de vie : utilisez Oracle Database Operator pour automatiser le provisionnement, le clonage, l'application de correctifs et la configuration des bases de données à instance unique (SIDB).
  • Haute disponibilité : prise en charge intégrée d'Oracle Data Guard pour fournir une réplication synchrone ou asynchrone et des fonctionnalités de basculement automatisées. La haute disponibilité est prise en charge dans une seule zone.
  • Intégration du stockage persistant : utilisez de manière transparente les classes de stockage standard-rwo GDC existantes pour les fichiers de base de données afin de garantir la durabilité des données.
  • Gestion sécurisée des images : prise en charge de la mise en miroir des images de conteneur Oracle depuis Oracle Container Registry vers les registres Harbor locaux, y compris l'analyse intégrée des failles de sécurité.
  • Observabilité unifiée : mécanismes intégrés pour exporter les métriques de base de données vers Prometheus et transférer les journaux d'alerte à l'aide de modèles side-car.
  • Mise en réseau flexible : prise en charge des équilibreurs de charge L4 internes et externes pour exposer les points de terminaison de la base de données de manière sécurisée.

Principes architecturaux

  • Approche autogérée : fournit le cadre architectural pour déployer et gérer les charges de travail Oracle.
  • Opérations cloud natives : utilise le modèle d'opérateur pour gérer les charges de travail avec état, en garantissant la cohérence entre les différents environnements.
  • Résilience adaptée aux bases de données : donne la priorité à la réplication au niveau de la base de données (Data Guard) plutôt qu'à la réplication au niveau de l'infrastructure pour garantir la cohérence logique et une récupération plus rapide.
  • Conception axée sur la sécurité : respecte les exigences d'air gap en utilisant des registres locaux , une analyse obligatoire des images et des règles réseau explicites pour tout le trafic de la base de données.

Architecture

L'architecture illustre la relation entre le cluster standard GDC, Oracle Database Operator, les ressources SIDB et l'infrastructure de prise en charge, comme Harbor.

Schéma de l'architecture d'une base de données Oracle autogérée.

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

  • Cluster standard GDC : environnement de calcul principal où résident l'opérateur Oracle et les pods de base de données.
  • Registre Harbor : source d'informations vérifiées locale et sécurisée pour toutes les images de conteneur. Il fournit une analyse automatisée pour s'assurer que les images ne présentent pas de failles connues.
  • Stockage persistant : les classes de stockage standard-rwo GDC fournissent le stockage de blocs sous-jacent requis pour les fichiers de données Oracle, les journaux de restauration et les fichiers de contrôle à l'aide d'un PersistentVolumeClaim.

Services et logique

  • Oracle Database Operator : contrôleur chargé de surveiller les ressources personnalisées telles que SingleInstanceDatabase et DataguardBroker. Il les réconcilie en objets Kubernetes standards, y compris les StatefulSets pour les pods de base de données et les services pour la mise en réseau.
  • Base de données à instance unique (SIDB) : déploiement en conteneur utilisant l'architecture mutualisée Oracle (CDB/PDB). Vous pouvez déployer plusieurs instances SIDB distinctes ou consolider les charges de travail en créant plusieurs bases de données connectables (PDB) dans une seule SIDB.
  • Data Guard Broker : orchestre les transitions de rôle entre les instances principales et de secours. Il gère les libellés de rôle de la base de données, par exemple database.oracle.com/role: primary, utilisés par les services Kubernetes pour acheminer correctement le trafic après un basculement.
  • Équilibreur de charge L4 : fournit des adresses IP stables pour la connectivité de la base de données.

Flux de données et interfaces

  • SQL*Net (port 1521) : protocole principal pour la connectivité des applications.
  • Exportateur d'observabilité : expose un point de terminaison /metrics pour Prometheus.
  • Journaux d'alerte : les journaux d'alerte de base de données standards sont envoyés à stdout pour être collectés par l'agent de journalisation GDC.
  • Canaux RMAN : utilisés par les ressources CronJob pour diffuser des sauvegardes vers un stockage d'objets compatible S3.

Remarques

  • Évolutivité et performances:
    • Les nœuds de calcul doivent être dimensionnés avec au moins 8 processeurs virtuels et 32 Gio de RAM pour les charges de travail de production.
    • L'utilisation de nodeSelector ou de taints et de tolérances est une bonne pratique pour dédier des nœuds spécifiques aux charges de travail de base de données.
    • Les performances dépendent fortement du stockage sous-jacent. Il est recommandé d'utiliser standard-rwo avec des IOPS élevées.
  • Gestion des ressources et licences:
    • Cette solution suit un modèle BYOL (Bring-Your-Own-License, utilisation de votre propre licence).
    • Les fonctionnalités avancées telles que le chiffrement transparent des données (TDE), la compression avancée et Active Data Guard (veille en lecture seule) nécessitent des licences Enterprise Edition spécifiques.
    • L'édition sans frais d'Oracle Database peut être utilisée pour le développement et les tests.
  • Disponibilité et fiabilité:
    • La haute disponibilité est obtenue grâce à des configurations Data Guard à zone unique où les instances principales et de secours résident dans le même espace de noms.
    • L'utilisation d'un service avec un sélecteur pour le libellé de rôle primary garantit une redirection fluide du client lors du basculement sans modification côté client.
    • Pour la protection des données, la solution utilise RMAN pour les sauvegardes dans un bucket compatible S3.
  • Gestion opérationnelle:
    • Bien que l'opérateur simplifie le déploiement, les opérations quotidiennes telles que l'optimisation et les restaurations complexes bénéficient toujours de l'expertise en administration de base de données.
    • L'utilisation d'un conteneur side-car est recommandée pour transférer les journaux d'audit et de trace détaillés qui ne sont pas envoyés à stdout.

Décision de conception

Les principaux choix architecturaux de cette solution visent à équilibrer l'automatisation et les contraintes d'un environnement sous air gap.

Comparaison entre Data Guard et la réplication au niveau du stockage

Data Guard est le mécanisme de haute disponibilité, car il est adapté aux bases de données. Cette approche protège contre la corruption logique et garantit l'absence de perte de données en mode de disponibilité maximale en validant les blocs avant qu'ils ne soient écrits dans la veille. Bien que cela nécessite une licence supplémentaire pour Enterprise Edition et une surcharge de configuration plus importante que les instantanés de volume, cela fournit la cohérence requise pour les charges de travail d'affinage.

Gestion des services pour les équilibreurs de charge

Par défaut, la définition du paramètre loadBalancer: true dans la spécification SingleInstanceDatabase crée automatiquement un service d'équilibreur de charge externe. Pour un équilibreur de charge interne, une ressource de service distincte doit être créée manuellement pour inclure l'annotation nécessaire networking.gke.io/load-balancer-type: "Internal". Cette approche manuelle fournit un contrôle déclaratif sur les annotations et les libellés que le service géré par l'opérateur par défaut peut ne pas exposer.

Stratégie d'observabilité des side-cars pour les journaux

La solution recommande d'utiliser des conteneurs side-car pour le transfert des journaux. Cela dissocie la collecte des journaux du processus de base de données principal, ce qui garantit que le volume de journalisation élevé n'a pas d'incidence sur les performances de la base de données. Bien que cela augmente l'empreinte des ressources par pod de base de données, cela garantit une collecte de télémétrie fiable sans affecter la stabilité de la base de données.

Hypothèses et limites

Hypothèses

  • L'environnement dispose d'une instance Harbor préconfigurée et accessible pour l'hébergement d'images.
  • Cert-manager est préinstallé sur le cluster standard pour gérer les certificats de webhook de l'opérateur.
  • Un magasin d'objets compatible S3 est disponible pour les cibles de sauvegarde RMAN.

Limites

  • HA à zone unique : les configurations à haute disponibilité sont compatibles dans une seule zone.
  • Pas d'Oracle RAC : la prise en charge des clusters d'applications réelles (RAC) n'est pas incluse. La solution se concentre sur l'instance unique et Data Guard.
  • Clusters standards uniquement : la solution est validée pour les clusters standards GDC et n'est pas compatible avec les clusters d'utilisateur partagés.

Étape suivante