Arquitectura de referencia de la base de datos de Oracle autoadministrada

Esta arquitectura de referencia proporciona un marco conceptual para implementar y operar bases de datos de Oracle autoadministradas en Google Distributed Cloud (GDC) con aislamiento de aire. Esta solución te permite mantener cargas de trabajo de bases de datos críticas mediante el uso del Oracle Database Operator para Kubernetes oficial en clústeres estándar.

La arquitectura se centra en habilitar un modelo de licencia adquirida por el usuario (BYOL), lo que te permite implementar bases de datos estandarizadas, seguras y con alta disponibilidad en entornos aislados. Abarca el ciclo de vida completo, desde el aprovisionamiento y las redes hasta las operaciones de nivel de producción, como la alta disponibilidad, la copia de seguridad, el restablecimiento y la observabilidad.

Características y funciones

La solución proporciona varios componentes funcionales principales para la administración de bases de datos:

  • Administración automatizada del ciclo de vida: Usa Oracle Database Operator para automatizar el aprovisionamiento, la clonación, la aplicación de parches y la configuración de bases de datos de instancia única (SIDB).
  • Alta disponibilidad: Compatibilidad integrada con Oracle Data Guard para proporcionar replicación síncrona o asíncrona y capacidades de conmutación por error automatizada. La alta disponibilidad es compatible con una sola zona.
  • Integración de almacenamiento persistente: Utiliza sin problemas las clases de almacenamiento estándar-rwo existentes de GDC para los archivos de base de datos para garantizar la durabilidad de los datos.
  • Administración segura de imágenes: Compatibilidad con la duplicación de imágenes de contenedores de Oracle desde Oracle Container Registry a registros locales de Harbor, incluido el análisis de vulnerabilidades integrado.
  • Observabilidad unificada: Mecanismos integrados para exportar métricas de bases de datos a Prometheus y reenviar registros de alertas con patrones de sidecar.
  • Redes flexibles: Compatibilidad con balanceadores de cargas L4 internos y externos para exponer extremos de bases de datos de forma segura.

Principios de arquitectura

  • Enfoque autoadministrado: Proporciona el marco arquitectónico para implementar y administrar cargas de trabajo de Oracle.
  • Operaciones nativas de la nube: Usa el patrón de operador para administrar cargas de trabajo con estado, lo que garantiza la coherencia en diferentes entornos.
  • Resiliencia compatible con la base de datos: Prioriza la replicación a nivel de la base de datos (Data Guard) sobre la replicación a nivel de la infraestructura para garantizar la coherencia lógica y una recuperación más rápida.
  • Diseño centrado en la seguridad: Cumple con los requisitos de aislamiento de aire mediante el uso de registros locales , el análisis obligatorio de imágenes y las políticas de red explícitas para todo el tráfico de la base de datos.

Arquitectura

La arquitectura ilustra la relación entre el clúster estándar de GDC, Oracle Database Operator, los recursos de SIDB y la infraestructura de asistencia, como Harbor.

Diagrama de arquitectura de la base de datos de Oracle autoadministrada.

Conceptos y tecnologías

En esta sección, se detallan los componentes funcionales, sus responsabilidades y cómo se comunican dentro del sistema.

Infraestructura y plataforma

  • Clúster estándar de GDC: Es el entorno de procesamiento principal en el que residen el operador de Oracle y los pods de la base de datos.
  • Registro de Harbor: Es la fuente confiable, local y segura para todas las imágenes de contenedores. Proporciona análisis automatizados para garantizar que las imágenes no tengan vulnerabilidades conocidas.
  • Almacenamiento persistente: Las clases de almacenamiento estándar-rwo de GDC proporcionan el almacenamiento en bloque subyacente necesario para los archivos de datos los registros de rehacer y los archivos de control de Oracle con un PersistentVolumeClaim.

Servicios y lógica

  • Oracle Database Operator: Es el controlador responsable de observar los recursos personalizados, como SingleInstanceDatabase y DataguardBroker. Los reconcilia en objetos estándar de Kubernetes, incluidos StatefulSets para pods y servicios de bases de datos para redes.
  • Base de datos de instancia única (SIDB): Es una implementación en contenedores que usa la arquitectura multiusuario de Oracle (CDB/PDB). Puedes implementar varias instancias de SIDB distintas o consolidar cargas de trabajo creando varias bases de datos conectables (PDB) dentro de una sola SIDB.
  • Data Guard Broker: Organiza las transiciones de roles entre instancias principales y en espera. Administra las etiquetas de roles de la base de datos, por ejemplo, database.oracle.com/role: primary, que usan los servicios de Kubernetes para enrutar el tráfico correctamente después de una conmutación por error.
  • Balanceador de cargas L4: Proporciona direcciones IP estables para la conectividad de la base de datos.

Flujo de datos e interfaces

  • SQL*Net (puerto 1521): Es el protocolo principal para la conectividad de aplicaciones.
  • Exportador de observabilidad: Expone un extremo /metrics para Prometheus.
  • Registros de alertas: Los registros de alertas de bases de datos estándar se envían a stdout para que los recopile el agente de Logging de GDC.
  • Canales de RMAN: Los usan los recursos de CronJob para transmitir copias de seguridad al almacenamiento de objetos compatible con S3.

Consideraciones

  • Escalabilidad y rendimiento:
    • Los nodos de trabajo deben tener un tamaño mínimo de 8 vCPU y 32 GiB de RAM para las cargas de trabajo de producción.
    • Usar nodeSelector o taints y tolerancias es una práctica recomendada para dedicar nodos específicos a las cargas de trabajo de la base de datos.
    • El rendimiento depende en gran medida del almacenamiento subyacente; se recomienda usar standard-rwo con IOPS altas.
  • Administración de recursos y licencias:
    • Esta solución sigue un modelo de licencia adquirida por el usuario (BYOL).
    • Las funciones avanzadas, como la encriptación de datos transparente (TDE), la compresión avanzada y Active Data Guard (en espera de solo lectura), requieren licencias específicas de Enterprise Edition.
    • La edición gratuita de Oracle Database se puede usar para el desarrollo y las pruebas.
  • Disponibilidad y confiabilidad:
    • La alta disponibilidad se logra a través de configuraciones de Data Guard de una sola zona en las que las instancias principales y en espera residen en el mismo espacio de nombres.
    • El uso de un servicio con un selector para la etiqueta de rol primary garantiza el redireccionamiento del cliente sin problemas durante la conmutación por error sin cambios del cliente.
    • Para la protección de datos, la solución usa RMAN para las copias de seguridad en un bucket compatible con S3.
  • Administración operativa:
    • Si bien el operador simplifica la implementación, las operaciones diarias, como el ajuste y los restablecimientos complejos, aún se benefician de la experiencia en administración de bases de datos.
    • Se recomienda el uso de un contenedor sidecar para reenviar registros de auditoría y seguimiento detallados que no se envían a stdout.

Decisión de diseño

Las principales opciones de arquitectura para esta solución se centran en equilibrar la automatización con las restricciones de un entorno con aislamiento de aire.

Data Guard en comparación con la replicación a nivel de almacenamiento

Data Guard es el mecanismo de alta disponibilidad porque es compatible con la base de datos. Este enfoque protege contra la corrupción lógica y garantiza la pérdida de datos cero en el modo de disponibilidad máxima mediante la validación de bloques antes de que se escriban en la instancia en espera. Si bien esto requiere licencias adicionales para Enterprise Edition y más sobrecarga de configuración que las instantáneas de volúmenes, proporciona la coherencia necesaria para las cargas de trabajo de refinamiento.

Administración de servicios para balanceadores de cargas

De forma predeterminada, si se establece el parámetro loadBalancer: true en la especificación SingleInstanceDatabase, se crea automáticamente un servicio de balanceador de cargas externo. Para un balanceador de cargas interno, se debe crear manualmente un recurso de servicio independiente para incluir la anotación necesaria networking.gke.io/load-balancer-type: "Internal". Este enfoque manual proporciona control declarativo sobre las anotaciones y las etiquetas que el servicio predeterminado administrado por el operador podría no exponer.

Estrategia de observabilidad de sidecars para registros

La solución recomienda usar contenedores sidecar para el reenvío de registros. Esto desacopla la recopilación de registros del proceso principal de la base de datos, lo que garantiza que el volumen de registro pesado no afecte el rendimiento de la base de datos. Si bien esto aumenta la huella de recursos por pod de base de datos, garantiza la recopilación confiable de telemetría sin afectar la estabilidad de la base de datos.

Suposiciones y limitaciones

Suposiciones

  • El entorno tiene una instancia de Harbor preconfigurada y accesible para el alojamiento de imágenes.
  • Cert-manager viene preinstalado en el clúster estándar para controlar los certificados de webhook del operador.
  • Hay un almacén de objetos compatible con S3 disponible para los destinos de copia de seguridad de RMAN.

Limitaciones

  • HA de una sola zona: Las configuraciones de alta disponibilidad son compatibles con una sola zona.
  • Sin Oracle RAC: No se incluye la compatibilidad con Real Application Clusters (RAC); la solución se centra en la instancia única y Data Guard.
  • Solo clústeres estándar: La solución se valida para clústeres estándar de GDC y no es compatible con clústeres de usuarios compartidos.

¿Qué sigue?