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 permitir um modelo de licenças adquiridas pelo usuário (BYOL), permitindo que você implante bancos de dados padronizados, seguros e altamente disponíveis em ambientes isolados. Ele 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 o gerenciamento de bancos de dados:

  • Gerenciamento automatizado do ciclo de vida: use o operador do Oracle Database para automatizar o provisionamento, a clonagem, a aplicação de patches e a configuração de bancos de dados de instância única (SIDB, na sigla em inglês).
  • Alta disponibilidade: suporte integrado ao Oracle Data Guard para fornecer recursos de replicação síncrona ou assíncrona e failover automatizado. A alta disponibilidade é compatível com uma única zona.
  • Integração de armazenamento permanente: use as classes de armazenamento standard-rwo atuais do GDC para arquivos de banco de dados para garantir a durabilidade dos dados.
  • Gerenciamento seguro de imagens: suporte para espelhamento de imagens de contêiner da 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: suporte a balanceadores de carga L4 internos e externos para expor endpoints de banco de dados com segurança.

Princípios de arquitetura

  • Abordagem autogerenciada: fornece o framework de arquitetura para implantar e gerenciar cargas de trabalho da Oracle.
  • Operações nativas da nuvem: usa o padrão de operador para gerenciar cargas de trabalho com estado, garantindo 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 focado em segurança: segue os 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 do 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 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 Oracle e os pods de banco de dados residem.
  • Harbor Registry: a fonte de verdade local e segura para todas as imagens de contêiner. Ele oferece verificação automatizada para garantir que as imagens não tenham vulnerabilidades conhecidas.
  • Armazenamento permanente: as classes de armazenamento standard-rwo do GDC fornecem o armazenamento em blocos necessário para arquivos de dados, redo logs e arquivos de controle do Oracle usando um PersistentVolumeClaim.

Serviços e lógica

  • Operador do banco de dados Oracle: o controlador responsável por monitorar recursos personalizados, como SingleInstanceDatabase e DataguardBroker. Ele os reconcilia em objetos padrão do Kubernetes, incluindo StatefulSets para pods de banco de dados e serviços de rede.
  • Banco de dados de instância única (SIDB, na sigla em inglês): uma implantação em contêiner que usa a arquitetura multilocatária da Oracle (CDB/PDB). É possível implantar várias instâncias distintas de SIDB ou consolidar cargas de trabalho criando vários bancos de dados conectáveis (PDBs) em um único SIDB.
  • Data Guard Broker: organiza as transições de papéis entre as instâncias principal e em espera. Ele gerencia os rótulos de papel 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 alerta: os registros de alerta padrão do banco de dados são enviados para stdout para coleta pelo agente do Logging do GDC.
  • Canais do RMAN: usados por recursos do CronJob para transmitir backups para o repositório de objetos compatível com S3.

Considerações

  • Escalabilidade e desempenho:
    • Os nós de trabalho precisam ser dimensionados com no mínimo 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 alto.
  • Gerenciamento de recursos e licenciamento:
    • Esta solução segue um modelo de licenças adquiridas pelo usuário (BYOL).
    • Recursos avançados, como Transparent Data Encryption (TDE), Advanced Compression e Active Data Guard (espera somente leitura), exigem licenças específicas da Enterprise Edition.
    • A edição Oracle Database Free 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ária e em espera residem no mesmo namespace.
    • O uso de um serviço com um seletor para o rótulo de papel primary garante o redirecionamento contínuo do cliente durante o failover sem alterações 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 ajustes e restaurações complexas, ainda se beneficiam da experiência em administração de bancos de dados.
    • O uso de um contêiner secundário é recomendado para encaminhar registros detalhados de rastreamento e auditoria que não são enviados para o stdout.

Decisão de design

As principais escolhas arquitetônicas para essa solução se concentram em equilibrar a automação com as restrições de um ambiente com isolamento físico.

Data Guard versus 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 zero perda de dados no modo de disponibilidade máxima, validando os blocos antes que eles sejam gravados no modo de espera. Embora isso exija licenciamento adicional para a Enterprise Edition e mais sobrecarga de configuração do que os 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, 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 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 secundários para o encaminhamento de registros. Isso desassocia a coleta de registros do processo principal do banco de dados, garantindo que um grande volume de registros não afete o desempenho do banco de dados. Embora isso aumente o uso de recursos por pod de banco de dados, 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

  • Alta disponibilidade de zona única: as configurações de alta disponibilidade são compatíveis com uma única zona.
  • Sem Oracle RAC: não há suporte para Real Application Clusters (RAC). A solução se concentra em Single Instance e Data Guard.
  • Somente clusters padrão: a solução é validada para clusters padrão do GDC e não é compatível com clusters de usuários compartilhados.

A seguir