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. Com essa solução, é possível 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 de computadores 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 operador do Oracle Database para automatizar o provisionamento, a clonagem, a aplicação de patch e a configuração de bancos de dados de instância única (SIDB).
  • Alta disponibilidade: suporte integrado para o Oracle Data Guard, que oferece 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: use sem problemas as classes de armazenamento standard-rwo atuais do GDC para arquivos de banco de dados e garanta a durabilidade dos dados.
  • Gerenciamento seguro de imagens: suporte para espelhamento de imagens de contêiner do Oracle do Oracle Container Registry para registros locais do Harbor, incluindo verificação de vulnerabilidades integrada.
  • Observabilidade unificada: mecanismos integrados para exportar métricas de banco de dados para o Prometheus e encaminhar registros de alerta usando padrões de arquivo secundário.
  • Rede flexível: compatibilidade com balanceadores de carga L4 internos e externos para expor endpoints de banco de dados com segurança.

Princípios de arquitetura

  • Abordagem autogerenciada: fornece a estrutura arquitetônica 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 (DataGuard) 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 focado na segurança: adere aos requisitos de isolamento físico usando registros locais, verificação obrigatória de imagens 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 operador do Oracle Database, os recursos do SIDB e a infraestrutura de suporte, como o Harbor.

Diagrama de 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, registros redo e arquivos de controle do Oracle usando um PersistentVolumeClaim.

Serviços e lógica

  • Operador do Oracle Database: o controlador responsável por observar recursos personalizados, como SingleInstanceDatabase e DataguardBroker. Ele reconcilia esses recursos em objetos padrão do Kubernetes, incluindo StatefulSets para pods de banco de dados e serviços para rede.
  • Banco de dados de instância única (SIDB): uma implantação em contêineres usando a arquitetura de vários locatários da Oracle (CDB/PDB). É possível implantar várias instâncias SIDB distintas ou consolidar cargas de trabalho criando vários bancos de dados plugáveis (PDBs) em um único SIDB.
  • Data Guard Broker: orquestra as transições de função entre instâncias principais e em 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 da camada 4: 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 padrão do banco de dados são enviados para stdout para coleta pelo agente de geração de registros do GDC.
  • Canais do 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 ter um tamanho mínimo de 8 vCPUs e 32 GiB de RAM para cargas de trabalho de produção.
    • Usar 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. Recomendamos usar standard-rwo com IOPS alto.
  • 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 Active Data Guard (espera somente leitura), exigem licenças específicas do 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 meio de configurações do Data Guard de zona única em que as instâncias primárias e em espera residem no mesmo namespace.
    • Usar um serviço com um seletor para o rótulo de função primary garante o redirecionamento do cliente sem problemas durante o failover, sem mudanças do 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.
    • Recomendamos o uso de um contêiner secundário para encaminhar registros detalhados de trace e auditoria que não são enviados para stdout.

Decisão de design

As principais escolhas de arquitetura 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 do 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 os blocos antes de serem gravados no standby. Embora isso exija licenciamento adicional para a Enterprise Edition e mais overhead de configuração do que snapshots de volume, ele oferece a consistência necessária para cargas de trabalho críticas.

Gerenciamento de serviços para balanceadores de carga

Por padrão, definir o 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 networking.gke.io/load-balancer-type: "Internal" necessária. Essa abordagem manual oferece controle declarativo sobre anotações e rótulos que o serviço padrão gerenciado pelo operador 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 um grande volume de registros não afete a performance do banco de dados. Isso aumenta a pegada de recursos por pod de banco de dados, mas garante uma coleta de telemetria confiável 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 em 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 é indisponível em clusters de usuário compartilhados.

A seguir