Arquitetura de referência do banco de dados Oracle autogerenciado

Esta arquitetura de referência fornece um framework conceitual para implantar e operar bancos de dados Oracle autogerenciados no Google Distributed Cloud (GDC) com isolamento físico. Essa solução permite manter cargas de trabalho de banco de dados críticas usando o Oracle Database Operator for Kubernetes oficial em clusters padrão.

A arquitetura se concentra em ativar um modelo de licenças adquiridas pelo usuário (BYOL), permitindo implantar bancos de dados padronizados, seguros e altamente disponíveis em ambientes isolados. Ela abrange todo o ciclo de vida, desde o provisionamento e a rede até operações de nível de produção, como alta disponibilidade, backup, restauração e observabilidade.

Recursos e funcionalidades

A solução oferece vários componentes funcionais principais para gerenciamento de banco de dados:

  • Gerenciamento automatizado do ciclo de vida: use o Oracle Database Operator para automatizar o provisionamento, a clonagem, a aplicação de patches e a configuração de bancos de dados de instância única (SIDB).
  • Alta disponibilidade: suporte integrado ao Oracle Data Guard para fornecer replicação síncrona ou assíncrona e recursos de failover automatizados. A alta disponibilidade é compatível com uma única zona.
  • Integração de armazenamento permanente: utilize perfeitamente as classes de armazenamento padrão-rwo existentes do GDC para arquivos de banco de dados, garantindo a durabilidade dos dados.
  • Gerenciamento seguro de imagens: suporte para espelhamento de imagens de contêiner do Oracle Container Registry para registros locais do Harbor, incluindo a verificação de vulnerabilidades integrada.
  • Observabilidade unificada: mecanismos integrados para exportar métricas de banco de dados para o Prometheus e encaminhar registros de alertas usando padrões de sidecar.
  • Rede flexível: suporte para balanceadores de carga L4 internos e externos para expor endpoints de banco de dados com segurança.

Princípios arquitetônicos

  • Abordagem autogerenciada: fornece o framework arquitetônico para implantar e gerenciar cargas de trabalho do Oracle.
  • Operações nativas da nuvem: usa o padrão de operador para gerenciar cargas de trabalho com estado, garantindo a consistência em diferentes ambientes.
  • Resiliência com reconhecimento de banco de dados: prioriza a replicação no nível do banco de dados (Data Guard) em vez da replicação no nível da infraestrutura para garantir a consistência lógica e uma recuperação mais rápida.
  • Design com foco na segurança: adere aos requisitos de isolamento físico usando registros locais , verificação de imagem obrigatória e políticas de rede explícitas para todo o tráfego de banco de dados.

Arquitetura

A arquitetura ilustra a relação entre o cluster padrão do GDC, o Oracle Database Operator, os recursos do SIDB e a infraestrutura de suporte, como o Harbor.

Diagrama da arquitetura do banco de dados Oracle autogerenciado.

Conceitos e tecnologias

Esta seção detalha os componentes funcionais, as responsabilidades deles e como eles se comunicam no sistema.

Infraestrutura e plataforma

  • Cluster padrão do GDC: o ambiente de computação principal em que o operador do Oracle e os pods de banco de dados residem.
  • Registro do Harbor: a fonte de referência local e segura para todas as imagens de contêiner. Ele oferece verificação automatizada para garantir que as imagens estejam livres de vulnerabilidades conhecidas.
  • Armazenamento permanente: as classes de armazenamento padrão-rwo do GDC fornecem o armazenamento em blocos subjacente necessário para arquivos de dados, redo logs e arquivos de controle do Oracle usando um PersistentVolumeClaim.

Serviços e lógica

  • Oracle Database Operator: o controlador responsável por observar recursos personalizados , como SingleInstanceDatabase e DataguardBroker. Ele os reconcilia em objetos padrão do Kubernetes, incluindo StatefulSets para pods e serviços de banco de dados para rede.
  • Banco de dados de instância única (SIDB): uma implantação em contêineres usando a arquitetura de multilocação do Oracle (CDB/PDB). É possível implantar várias instâncias distintas do SIDB ou consolidar cargas de trabalho criando vários bancos de dados plugáveis (PDBs) em um único SIDB.
  • Data Guard Broker: orquestra transições de papéis entre instâncias primárias e de espera. Ele gerencia os rótulos de função do banco de dados, por exemplo, database.oracle.com/role: primary, usados pelos serviços do Kubernetes para rotear o tráfego corretamente após um failover.
  • Balanceador de carga L4: fornece endereços IP estáveis para conectividade de banco de dados.

Fluxo de dados e interfaces

  • SQL*Net (porta 1521): o protocolo principal para conectividade de aplicativos.
  • Exportador de observabilidade: expõe um endpoint /metrics para o Prometheus.
  • Registros de alertas: os registros de alertas de banco de dados padrão são enviados para stdout para coleta pelo agente de geração de registros do GDC.
  • Canais RMAN: usados por recursos CronJob para transmitir backups para armazenamento de objetos compatível com S3.

Considerações

  • Escalonabilidade e desempenho:
    • Os nós de trabalho precisam ser dimensionados com um mínimo de 8 vCPUs e 32 GiB de RAM para cargas de trabalho de produção.
    • O uso de nodeSelector ou taints e tolerâncias é uma prática recomendada para dedicar nós específicos a cargas de trabalho de banco de dados.
    • O desempenho depende muito do armazenamento subjacente. É recomendável usar standard-rwo com IOPS altas.
  • Gerenciamento de recursos e licenciamento:
    • Essa solução segue um modelo de licenças adquiridas pelo usuário (BYOL).
    • Recursos avançados, como criptografia transparente de dados (TDE), compactação avançada e Data Guard ativo (espera somente leitura), exigem licenças específicas da Enterprise Edition.
    • A edição sem custo financeiro do Oracle Database pode ser usada para desenvolvimento e testes.
  • Disponibilidade e confiabilidade:
    • A alta disponibilidade é alcançada por configurações do Data Guard de zona única em que as instâncias primárias e de espera residem no mesmo namespace.
    • O uso de um serviço com um seletor para o rótulo de função primary garante o redirecionamento perfeito do cliente durante o failover sem mudanças no lado do cliente.
    • Para proteção de dados, a solução usa o RMAN para backups em um bucket compatível com S3.
  • Gerenciamento operacional:
    • Embora o operador simplifique a implantação, as operações diárias, como ajuste e restaurações complexas, ainda se beneficiam da experiência em administração de banco de dados.
    • O uso de um contêiner secundário é recomendado para encaminhar registros de auditoria e trace detalhados que não são enviados para stdout.

Decisão de design

As principais opções arquitetônicas para essa solução se concentram em equilibrar a automação com as restrições de um ambiente isolado.

Data Guard x replicação no nível de armazenamento

O Data Guard é o mecanismo de alta disponibilidade porque reconhece o banco de dados. Essa abordagem protege contra corrupção lógica e garante perda zero de dados no modo de disponibilidade máxima, validando blocos antes de serem gravados na espera. Embora isso exija licenciamento adicional para a Enterprise Edition e mais sobrecarga de configuração do que snapshots de volume, ele fornece a consistência necessária para cargas de trabalho de refinamento.

Gerenciamento de serviços para balanceadores de carga

Por padrão, a configuração do parâmetro loadBalancer: true na especificação SingleInstanceDatabase cria automaticamente um serviço de balanceador de carga externo. Para um balanceador de carga interno, um recurso de serviço separado precisa ser criado manualmente para incluir a anotação necessária networking.gke.io/load-balancer-type: "Internal". Essa abordagem manual fornece controle declarativo sobre anotações e rótulos que o serviço gerenciado pelo operador padrão pode não expor.

Estratégia de observabilidade de sidecars para registros

A solução recomenda o uso de contêineres sidecar para encaminhamento de registros. Isso desvincula a coleta de registros do processo principal do banco de dados, garantindo que o volume de registros pesados não afete o desempenho do banco de dados. Embora isso aumente a ocupação de recursos por pod de banco de dados, ele garante a coleta confiável de telemetria sem afetar a estabilidade do banco de dados.

Suposições e limitações

Suposições

  • O ambiente tem uma instância do Harbor pré-configurada e acessível para hospedagem de imagens.
  • O cert-manager vem pré-instalado no cluster padrão para processar os certificados de webhook do operador.
  • Um repositório de objetos compatível com S3 está disponível para destinos de backup do RMAN.

Limitações

  • HA de zona única: as configurações de alta disponibilidade são compatíveis com uma única zona.
  • Sem Oracle RAC: o suporte a clusters de aplicativos reais (RAC) não está incluído. A solução se concentra em instância única e Data Guard.
  • Somente clusters padrão: a solução é validada para clusters padrão do GDC e não tem suporte em clusters de usuários compartilhados.

A seguir