Oracle Database de instância única no OpenShift Virtualization

Este artigo detalha os esforços de engenharia da Red Hat para viabilizar a execução de uma instância única do Oracle Database 19c no Red Hat OpenShift Virtualization. A solução oferece uma ampla arquitetura de referência, resultados de validação que abrangem funcionalidade, desempenho, escalabilidade e migração ao vivo, além de links para artefatos de teste hospedados no GitHub.

Demonstraremos que o OpenShift Virtualization oferece desempenho robusto para cargas de trabalho de produção exigentes, como bancos de dados Oracle, fornecendo uma alternativa de virtualização viável sem sacrificar o desempenho. Feito especialmente para líderes de tecnologia, arquitetos, equipes de engenharia e gerentes de projeto envolvidos na avaliação e adoção do Oracle Database de instância única no OpenShift Virtualization.

Os princípios do design da arquitetura se concentram na alocação de recursos, no particionamento e na otimização da camada de abstração para computação, rede e armazenamento. Os testes de desempenho usando o HammerDB com o benchmark TPC-C provam que o Oracle Database pode ser executado no OpenShift Virtualization com armazenamento NVMe local, superando o desempenho do Red Hat OpenShift Data Foundation. Este artigo também destaca a observabilidade e o monitoramento, usando o Prometheus e o Grafana para obter insights específicos do Oracle e da infraestrutura.

Contexto

Muitos clientes estão buscando alternativas de virtualização sem sacrificar o desempenho. O OpenShift Virtualization oferece desempenho robusto para cargas de trabalho de produção exigentes, como bancos de dados empresariais.

Um dos componentes mais essenciais na arquitetura de software tradicional é o Oracle Database. Para auxiliar os clientes interessados em avaliar e adotar o Oracle Database no OpenShift Virtualization, a Red Hat conta com recursos de engenharia dedicados para oferecer uma experiência otimizada de operação desse componente no OpenShift Virtualization.

Este artigo pressupõe que os leitores já conheçam o Red Hat OpenShift Container Platform. Não pretendemos discutir a arquitetura genérica do Oracle Database nem o ajuste de desempenho. Em vez disso, explicaremos as opções de arquitetura para instalar e configurar o OpenShift Virtualization para permitir que o Oracle Database tenha o melhor desempenho.

Esta publicação é destinada aos seguintes profissionais que avaliam, validam e decidem sobre a adoção do Oracle Database de instância única no OpenShift Virtualization:

• Líderes de tecnologia (como vice-presidentes e CTOs): stakeholders responsáveis por otimizar o ROI (retorno sobre investimento) e o TCO (custo total de propriedade) das operações diárias de cargas de trabalho em execução do Oracle Database em nuvens híbridas ou on-premise.
• Arquitetos: os arquitetos de clientes podem analisar a arquitetura de referência e os resultados dos testes para avaliar se o OpenShift Virtualization é uma plataforma viável para hospedar cargas de trabalho do Oracle Database na organização. Este artigo fornece requisitos de arquitetura e permite que arquitetos executem validações independentes.
• Equipes de engenharia: as equipes de engenharia podem aproveitar os testes de desempenho usados pela Red Hat durante a avaliação, além de artefatos reutilizáveis disponíveis no GitHub, para acelerar a configuração e a automação dos testes, simplificando o processo de validação.
• Gerentes de projeto: os gerentes de projeto podem usar as arquiteturas de referência para identificar os componentes afetados e as equipes responsáveis. Eles também podem usar os testes padronizados. 

Visão geral da arquitetura do OpenShift Virtualization

O OpenShift Virtualization é a implementação da Red Hat do projeto open source KubeVirt. Ele é baseado na plataforma padrão do OpenShift. Uma máquina virtual (VM) é executada em um pod em containers. O OpenShift Container Platform gerencia as VMs como faz com qualquer pod, onde uma instância de VM tem acesso aos mesmos serviços da plataforma, como segurança, rede e armazenamento, como uma aplicação de containers comum. A única diferença é que a VM é gerenciada diretamente no nível do pod, ao contrário das aplicações de carga de trabalho comuns executadas em containers.

Componentes da arquitetura:

• Máquina virtual baseada em Kernel (KVM): o hipervisor de VMs no OpenShift faz parte do kernel do Linux.
• Instância de máquina virtual (VMI): cada VM representada por uma VMI é criada pelo QEMU usando KVM para emular o hardware. O QEMU cria um isolamento no nível do espaço do usuário.
• KubeVirt: complemento do Kubernetes para gerenciar VMs como recursos do Kubernetes, fazendo com que elas pareçam um pod.
  • virt-operator: gerencia a instalação e as atualizações dos componentes do KubeVirt.
  • virt-controller: lida com o gerenciamento do ciclo de vida da VM (por exemplo, reinicialização em caso de falha, escala).
  • virt-handler: um daemon em um nó habilitado para KubeVirt para gerenciar VMs em hosts usando KVM/QEMU.
  • virt-launcher: um por pod de VM; atua como o orquestrador que gerencia o processo de máquina virtual QEMU/KVM dentro do pod.
  • Recursos personalizados (CRs): representa uma definição de VM, a execução de uma instância de VM e agendamento/políticas.
• Wrapper do pod: serve como um wrapper para o processo do QEMU. A VMI é executada no pod como um sistema operacional de guest virtual.
• Armazenamento: o OpenShift Virtualization é compatível com várias soluções de armazenamento, inclusive opções nativas do Kubernetes, como OpenShift Data Foundation, Portworx e soluções empresariais mais tradicionais, como iSCSI, armazenamento SAN do Fibre Channel (FC), entre outras. A solução de armazenamento nativo do Kubernetes, o OpenShift Data Foundation, baseada no projeto open source Ceph, oferece armazenamento redundante e escalável com uma camada de abstração otimizada para ambientes do Kubernetes. O OpenShift Data Foundation também é compatível com o provisionamento dinâmico de volumes persistentes (PVs) e solicitações de volume persistente (PVCs), simplificando o gerenciamento do armazenamento.

Para este projeto de validação do Oracle Database, consideraremos várias alternativas de armazenamento. No entanto, o OpenShift Data Foundation será o foco principal no escopo deste documento devido à sua integração fluida com o Kubernetes. Ao implantar cargas de trabalho do Oracle Database, é importante avaliar e escolher a solução de armazenamento que melhor atenda a seus requisitos de desempenho e necessidades operacionais.

Rede: as VMs acessam a rede pelo Multus (metaplugin da CNI) ou pela virtualização de E/S de raiz única (SR-IOV), onde o Multus é definido no nível do pod.

Princípios de design do Oracle Database

Quando um Oracle Database é executado em um sistema operacional virtualizado, a VM é responsável por garantir que o banco de dados receba os recursos do sistema adequados para operar com eficiência e permanecer resiliente. Como os recursos de infraestrutura no mundo real são limitados, a arquitetura da infraestrutura deve ser cuidadosamente projetada para equilibrar a alocação de recursos e acomodar as diversas demandas de diferentes cargas de trabalho.

Uma abordagem de arquitetura essencial para impulsionar o desempenho do Oracle Database no nível da infraestrutura inclui os seguintes princípios:

• Localização dos recursos: aloque recursos suficientes em termos de computação, armazenamento e rede para eliminar obstáculos.
• Particionamento de recursos: quando os recursos são limitados, particione os requisitos dos recursos e implemente soluções personalizadas para atender a necessidades específicas.
• Otimização da camada de abstração: evite camadas de abstração desnecessárias ou de baixo valor em troca de flexibilidade para ganhos de desempenho.

O Oracle Database depende fortemente de três tipos principais de recursos do sistema:

• Computação: inclui vCPUs, linhas de E/S, memória e a capacidade de escalar em nós.
• Rede: o Oracle Database é altamente sensível ao desempenho de E/S. O acesso de clientes e o acesso ao armazenamento têm requisitos distintos de taxa de transferência e latência. Como resultado, as arquiteturas do Oracle Database geralmente usam redes separadas para diferentes tipos de tráfego.
• Armazenamento: redo logs, tabelas de bancos de dados e backups têm diferentes necessidades de desempenho de leitura/gravação. Sempre que possível, coloque-os em um armazenamento físico separado para garantir o desempenho ideal de E/S.

O OpenShift Virtualization oferece as funcionalidades e a flexibilidade necessárias para dar suporte a várias abordagens de alocação de recursos com base nas necessidades de particionamento do sistema.

Arquitetura de referência

Esta seção aborda considerações de arquitetura e opções de soluções no design do Oracle Database no OpenShift Virtualization.

Computação

Garanta que o Oracle Database tenha recursos de computação suficientes, a ponto de a plataforma do OpenShift Virtualization fornecer controle direto sobre:

• A configuração da alocação de vCPUs e RAM para escalonamento vertical de recursos.
• A extensibilidade do cluster do OpenShift Virtualization para escalabilidade horizontal.
• Controle da alocação da contagem de linhas de E/S da VM para eliminar obstáculos de E/S no nível do pod.
• Evite a superalocação de recursos em máquinas virtuais que hospedam cargas de trabalho do Oracle Database, alocando mais CPUs virtualizadas ou memória do que a capacidade de recursos físicos no sistema.

Rede

O tráfego do Oracle Database tem diferentes requisitos de desempenho em termos de latência de rede, taxa de transferência e confiabilidade. O pod Multus do OpenShift Container Platform é um recurso para particionar o tráfego e mediar vários protocolos de rede. Considere o seguinte:

• Implementação de diferentes caminhos de rede para SDN, armazenamento e máquinas virtuais do OpenShift.
• Para instalações do Oracle RAC Database, segregarem ainda mais o tráfego de rede para promover a comunicação entre instâncias do RAC e a comunicação de rede "pública".
• Para cargas de trabalho essenciais sensíveis à latência e taxa de transferência, considere aproveitar o SR-IOV para interfaces de rede virtuais, criando um caminho direto da VM aos recursos físicos subjacentes.

Armazenamento

Como já mencionado, o OpenShift Virtualization é compatível com uma grande variedade de soluções de armazenamento, desde opções nativas em Kubernetes, como OpenShift Data Foundation e Portworx, até sistemas empresariais tradicionais, como iSCSI e SAN do Fibre Channel (FC). Com essa flexibilidade, os usuários podem escolher o armazenamento que melhor atenda às necessidades operacionais e de desempenho deles.

Embora não exista uma regra universal para selecionar a opção de armazenamento apropriada, os seguintes princípios podem ser usados como diretrizes:

• Equilíbrio entre a necessidade de flexibilidade operacional (facilidade de provisionamento, integração com a plataforma) e os requisitos de desempenho (latência de E/S, taxa de transferência).
• Suporte para gravação múltipla (volume compartilhado entre duas ou mais VMs) que pode ser exigido para o Oracle RAC Database.

Configuração de hardware

O design dos testes de desempenho iniciais foi definido como um conjunto de recursos de hardware disponíveis hoje. 

Especificações do cluster:

• 4 servidores Dell R660
  • 128 linhas de CPU (2 soquetes do Intel Xeon Gold 6430)
  • 256 GB de memória
  • Disco raiz de 1 TB
  • 4 unidades NVME de 1,5 TB
  • 4 NICs Broadcom de 25 Gbps
  • 2 NICs Intel 810 de 25 Gbps

Configuração do OpenShift Virtualization

Embora a configuração padrão de armazenamento do OpenShift Virtualization e do OpenShift Data Foundation ofereça um desempenho razoável, outras alterações de configuração foram feitas para otimizar a plataforma de teste para cargas de trabalho com uso intenso de E/S típicas de bancos de dados:

• OpenShift Data Foundation configurado para usar um perfil de desempenho.
• OpenShift Data Foundation e OpenShift Virtualization configurados para separar o tráfego de armazenamento do OpenShift Data Foundation do tráfego geral da rede definida por software (SDN do OpenShift Container Platform). (Capítulo 8. Requisitos de rede | Planejando sua implantação | Red Hat OpenShift Data Foundation | 4.18)
• Tráfego segregado para máquinas virtuais (Oracle Database e conjunto de testes do HammerDB) do armazenamento do OpenShift Data Foundation e do SDN do OpenShift Container Platform usando interfaces de rede físicas separadas. Para reduzir a latência e aumentar a taxa de transferência, as interfaces de rede foram introduzidas nas máquinas virtuais afetadas usando a virtualização de E/S de raiz única (SR-IOV) (Figura 2).

Especificações do cluster:

• Versão do OpenShift: 4.18.9
• OpenShift Virtualization: habilitado pelo OperatorHub
• Nós:
  • 3 nós híbridos (Control Plane/Worker/Armazenamento)
  • 1 nó Worker
• Rede (específico para VMs do Oracle Database):
  • Vínculo de LACP com 4 NICs Broadcom de 25 Gbps particionadas para segregar o tráfego da SDN do OpenShift, o cliente de armazenamento do OpenShift Data Foundation e o tráfego de replicação de armazenamento do OpenShift Data Foundation.
  • Duas NICs Intel 810 de 25 GB para tráfego de máquinas virtuais com duas sub-redes diferentes (pública e privada) configuradas para serem apresentadas a máquinas virtuais usando SR-IOV.
• Armazenamento (específico para VMs do Oracle Database): armazenamento do OpenShift Data Foundation (apoiado por 4 unidades NVMe de 1,5 TB) configurado com perfil de desempenho e usando rede de armazenamento separada.

Configuração do Oracle Database

A máquina virtual que hospedará o Oracle Database tem tamanho moderado para evitar a superalocação de recursos e para comparar os resultados dos testes em diferentes opções de hardware. O Oracle Database não foi ajustado especificamente para o teste do Transaction Processing Performance Council Benchmark C (TPC-C) e faz amplo uso de uma configuração padrão, com exceção das poucas alterações de ajuste comuns baseadas em práticas recomendadas.

Selecionamos os parâmetros de ajuste com base na dimensão da máquina virtual, nas especificidades da carga de trabalho de teste de referência e nas informações de monitoramento. Para avaliar a eficácia de cada mudança, comparamos os resultados dos testes com números de linha de base. A configuração do Oracle Database foi ainda mais otimizada com as recomendações do guia para ajuste de desempenho de banco de dados.

A Figura 3 mostra que os acessos de clientes do Oracle Database e do HammerDB estavam na mesma rede. Os volumes de dados para máquinas virtuais são configurados para pré-alocar espaço em disco para melhorar as operações de gravação. 

Realizamos testes ad-hoc separados para avaliar o impacto do armazenamento no desempenho do banco de dados, adicionando armazenamento NVMe por um operador de armazenamento local.

Especificações da máquina virtual:

• Sistema operacional: RHEL 8.10
• Contagem de VMs: 1
• vCPU: 16
• Memória: 48 GB
• Armazenamento: 250 GB (dados raiz e de banco de dados no mesmo volume) como dispositivo de blocos do ODF da RH
• DataVolume: criado usando "preallocation: true" (provisionamento thick).
• Rede: conectada à sub-rede pública usando SR-IOV.

Configuração de instância única do Oracle Database:

Versão do Oracle Database: 19c Enterprise Edition com atualização 26 (versão 19.26)

• O banco de dados configurado com um sistema de arquivos como destino para arquivos de dados (volume raiz com armazenamento com suporte do OpenShift Data Foundation) usando OMF (Oracle Managed Files).
• Para garantir a compatibilidade do teste com versões futuras do Oracle Database, o banco de dados foi criado usando a arquitetura Container Database (CDB).
• A alocação de memória usou memória total de 32 GB como entrada para o assistente de criação de banco de dados, permitindo que a instalação do Oracle Database avaliasse automaticamente a divisão SGA/PGA.
• Parâmetros de ajuste adicionais:
  • 4 arquivos de dados estendidos manualmente para 32 GB
  • Tamanho do REDO log ajustado para 4 GB
  • 4 grupos de discos de REDO log
  • FILESYSTEMIO_OPTIONS: SETALL (permitindo E/S assíncrona e E/S direta)
  • USE_LARGE_PAGES: AUTO (para otimizar o uso da CPU para um tamanho grande de SGA)

Observação: para os testes de desempenho com armazenamento com suporte NVME, um sistema de arquivos separado foi montado usando o dispositivo NVME e atribuído como destino dos arquivos de dados.

Observabilidade e monitoramento

O OpenShift oferece uma plataforma de observabilidade avançada e integrada que consolida o monitoramento nas camadas de infraestrutura e aplicação. Ele oferece suporte nativo à coleta de métricas, geração de logs e alertas, além de poder ser estendido para incluir dados de observabilidade de aplicações externas, como Oracle Databases. Essa abordagem unificada reduz a complexidade operacional e permite visibilidade de ponta a ponta.

A observabilidade do OpenShift Virtualization é integrada à mesma plataforma, assim você pode monitorar máquinas virtuais, recursos do sistema e cargas de trabalho (ou seja, Oracle Databases em um único stack de monitoramento consistente).

O Oracle Database Observability Exporter, implantado no OpenShift, coleta métricas e metadados de desempenho do Oracle Database, expostos ao Prometheus. O Grafana visualiza essas métricas, disponibilizando dashboards em tempo real para detectar padrões anormais, pressão de recursos e problemas de desempenho nas camadas do Oracle Database e da VM.

Para aprimorar a análise no nível do banco de dados, você pode usar o HammerDB durante os testes de desempenho para capturar snapshots e gerar relatórios do AWR (Automatic Workload Repository). Quando combinados com métricas do Prometheus e do Grafana, esses relatórios fornecem uma compreensão multidimensional e mais rica do comportamento das cargas de trabalho e de possíveis obstáculos.

Além disso, o Oracle Database Enterprise Manager funciona como uma ferramenta complementar, oferecendo diagnósticos detalhados e recursos de monitoramento especializados adaptados aos Oracle Databases. Usado com a plataforma de observabilidade unificada do OpenShift, ele garante uma cobertura abrangente para insights operacionais específicos do Oracle Database e da infraestrutura.

A Figura 5 mostra um exemplo de dashboard do Grafana implantado como parte da configuração de observabilidade e monitoramento da plataforma do OpenShift Virtualization.

A Figura 6 mostra um exemplo de dashboard do Oracle Database no Grafana implantado na plataforma do OpenShift Virtualization.

Avaliação do desempenho do sistema

O teste de desempenho foi projetado para medir a taxa de transferência de transações do banco de dados e a latência de consulta para cargas de trabalho de OLTP (processamento de transações online). Usamos o HammerDB, um software de teste de desempenho de banco de dados open source para simular cargas de trabalho de OLTP usando o benchmark TPC-C em relação ao Oracle Database de instância única com os detalhes do sistema mencionados anteriormente. O teste do TPC-C simula um sistema de gerenciamento de solicitações real, com uma mistura de 80% de operações de gravação e 20% de operações de leitura, inclusive solicitações de clientes de alta frequência, pagamentos, verificações de inventário e entregas em lote. A execução do teste envolve o HammerDB gerando cargas de trabalho TPC-C no Oracle Database dentro do OpenShift Virtualization.

Resumo da cobertura do teste

Com o conjunto de testes do HammerDB, o perfil de execução em escala foi configurado para simular cargas de trabalho significativas com contagens de usuários virtuais começando em 20 e aumentando até 100, usando 500 warehouses com cada teste por 20 minutos. Projetamos essa configuração para refletir cenários de produção realistas e avaliar o desempenho do sistema em cargas transacionais em escala.

Com base na configuração da arquitetura de referência, os resultados do teste comprovaram fortes métricas de novos pedidos por minuto (NOPM) e transações por minuto (TPM) para o Oracle Database de instância única com armazenamento do OpenShift Data Foundation. No entanto, o Oracle Database de instância única com armazenamento NVMe local apresentou melhor desempenho em relação à configuração do OpenShift Data Foundation. Embora a latência média tenha permanecido relativamente estável, observamos picos ocasionais.

Considerações finais

O OpenShift Virtualization é uma plataforma viável para implantar cargas de trabalho do Oracle Database 19c. A facilidade de configurar o OpenShift Virtualization oferece suporte robusto para a criação de máquinas virtuais. Considerando esses fatores, o OpenShift Virtualization se destaca como um importante competidor e uma alternativa às ofertas de tecnologias de virtualização concorrentes. A validação de desempenho atual do Oracle Database 19c demonstra um desempenho de nível empresarial na plataforma do OpenShift Virtualization.

Pela realização de testes ad-hoc com armazenamento NVMe local, avaliamos o impacto das opções de armazenamento de alto desempenho e encontramos fortes indícios de que fazer o upgrade para essas soluções, como o SAN do FC, pode melhorar significativamente o desempenho geral.

Para cargas de trabalho de alto desempenho, considere:

• Opções de armazenamento de alto desempenho, como o SAN do FC, para logs redo e arquivos de dados do Oracle Database para otimizar o desempenho.
• Segmentação de rede para máquinas virtuais, SDN do OpenShift e rede de armazenamento, de preferência usando dispositivos físicos separados nos nós do OpenShift Virtualization.
• SR-IOV (virtualização de E/S de raiz única), se compatível com o hardware para otimizar o desempenho das interfaces de rede virtuais das máquinas virtuais que hospedam a carga de trabalho do Oracle Database.
• HugePages com a configuração USE_LARGE_PAGES do Oracle Database com base nos seus requisitos de carga de trabalho: essa configuração ajusta o tamanho da página de memória, recomendado para melhorar o desempenho, especialmente ao trabalhar com SGAs maiores do que as configurações padrão.

Você encontrará scripts de teste do HammerDB neste repositório do GitHub.

O projeto oracle-db-appdev-monitoring do GitHub visa oferecer observabilidade ao Oracle Database. Assim, os usuários podem entender o desempenho e diagnosticar problemas com facilidade em aplicações e bancos de dados. Leia as instruções para configurar o projeto na plataforma do OpenShift.