Arquiteturas para Oracle Database Enterprise Edition no Azure

Artigo
10/03/2024

Aplica-se a: ✔️ Linux VMs

O Azure é o lar de todas as cargas de trabalho Oracle, incluindo cargas de trabalho que precisam continuar a ser executadas de forma otimizada no Azure com Oracle. Se você tiver o Oracle Diagnostic Pack ou o Automatic Workload Repository (AWR), poderá coletar dados sobre suas cargas de trabalho. Use esses dados para avaliar a carga de trabalho do Oracle, dimensionar as necessidades de recursos e migrar a carga de trabalho para o Azure. As várias métricas fornecidas pela Oracle nesses relatórios podem fornecer uma compreensão do desempenho do aplicativo e do uso da plataforma.

Este artigo ajuda você a preparar uma carga de trabalho Oracle para ser executada no Azure e explorar as melhores soluções de arquitetura para fornecer um desempenho ideal na nuvem. Os dados fornecidos pela Oracle no Statspack e ainda mais no seu descendente, o AWR, ajudam-no a desenvolver expectativas claras. Essas expectativas incluem os limites do ajuste físico através da arquitetura, as vantagens do ajuste lógico do código do banco de dados e o design geral do banco de dados.

Diferenças entre os dois ambientes

Ao migrar aplicativos locais para o Azure, lembre-se de algumas diferenças importantes entre os dois ambientes.

Uma diferença importante é que, em uma implementação do Azure, recursos como VMs, discos e redes virtuais são compartilhados entre outros clientes. Além disso, os recursos podem ser limitados com base nos requisitos. Em vez de se concentrar em evitar falhas, o Azure se concentra mais em sobreviver à falha. A primeira abordagem tenta aumentar o tempo médio entre falhas (MTBF) e a segunda tenta diminuir o tempo médio de recuperação (MTTR).

A tabela a seguir lista algumas das diferenças entre uma implementação local e uma implementação do Azure de um banco de dados Oracle.

	Implementação local	Implementação do Azure
Rede	LAN/WAN	Rede definida pelo software (SDN)
Grupo de segurança	Ferramentas de restrição de IP/porta	Grupo de segurança de rede (NSG)
Resiliência	MTBF	MTTR
Manutenção planeada	Patching/upgrades	Conjuntos de disponibilidade com patching/upgrades gerenciados pelo Azure
Recurso	Dedicada	Partilhado com outros clientes
Regiões	Datacenters	Pares de regiões
Armazenamento	SAN/discos físicos	Armazenamento gerenciado pelo Azure
Escala	Escala vertical	Dimensionamento horizontal

Requisitos

Considere os seguintes requisitos antes de iniciar a migração:

Determine o uso real da CPU. Licenças Oracle por núcleo, o que significa que dimensionar suas necessidades de vCPU pode ser essencial para ajudá-lo a reduzir custos.
Determine o tamanho do banco de dados, o armazenamento de backup e a taxa de crescimento.
Determine os requisitos de E/S, que você pode estimar com base no Oracle Statspack e nos relatórios AWR. Também é possível estimar os requisitos a partir das ferramentas de monitoramento de armazenamento disponíveis no sistema operacional.

Opções de configuração

É uma boa ideia gerar um relatório AWR e obter algumas métricas dele para ajudá-lo a tomar decisões sobre configuração. Em seguida, há quatro áreas potenciais que você pode ajustar para melhorar o desempenho em um ambiente do Azure:

Tamanho da máquina virtual
Taxa de transferência da rede
Tipos e configurações de disco
Configurações de cache de disco

Gerar um relatório AWR

Se você tiver um banco de dados Oracle Enterprise Edition existente e estiver planejando migrar para o Azure, terá várias opções. Se você tiver o Diagnostics Pack para suas instâncias Oracle, poderá executar o relatório Oracle AWR para obter as métricas, como IOPS, Mbps e GiBs. Para os bancos de dados sem a licença do Diagnostics Pack ou para um banco de dados Oracle Standard Edition, você pode coletar as mesmas métricas importantes com um relatório Statspack depois de coletar instantâneos manuais. As principais diferenças entre esses dois métodos de relatório são que o AWR é coletado automaticamente e que ele fornece mais informações sobre o banco de dados do que o Statspack.

Considere executar seu relatório AWR durante cargas de trabalho regulares e de pico, para que você possa comparar. Para coletar a carga de trabalho mais precisa, considere um relatório de janela estendida de uma semana, em vez de um dia. O AWR fornece médias como parte de seus cálculos no relatório. Por padrão, o repositório AWR retém oito dias de dados e tira instantâneos em intervalos horários.

Para uma migração de datacenter, você deve reunir relatórios para dimensionamento nos sistemas de produção. Estime as cópias de banco de dados restantes usadas para teste, teste e desenvolvimento do usuário por porcentagens. Por exemplo, estime 50% do dimensionamento da produção.

Para executar um relatório AWR a partir da linha de comando, use o seguinte comando:

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Principais métricas

O relatório solicita as seguintes informações:

Tipo de relatório: HTML ou TEXT. O tipo HTML fornece mais informações.
O número de dias de instantâneos a serem exibidos. Por exemplo, para intervalos de uma hora, um relatório de uma semana produz 168 IDs de instantâneo.
O início SnapshotID da janela de relatório.
O final SnapshotID da janela de relatório.
O nome do relatório que o script AWR cria.

Se você estiver executando o relatório AWR em um Real Application Cluster (RAC), o relatório de linha de comando será o arquivo awrgrpt.sql , em vez de awrrpt.sql. O g relatório cria um relatório para todos os nós no banco de dados RAC em um único relatório. Este relatório elimina a necessidade de executar um relatório em cada nó RAC.

Você pode obter as seguintes métricas do relatório AWR:

Nome do banco de dados, nome da instância e nome do host
Versão do banco de dados para suporte pela Oracle
CPU/Núcleos
SGA/PGA, e consultores para informá-lo se subdimensionado
Total de memória em GB
Percentagem de CPU ocupada
CPUs de banco de dados
IOPs (leitura/gravação)
MBPs (leitura/gravação)
Taxa de transferência da rede
Taxa de latência da rede (baixa/alta)
Principais eventos de espera
Configurações de parâmetros para banco de dados
Se o banco de dados é RAC, Exadata ou usando recursos ou configurações avançadas

Tamanho da máquina virtual

Aqui estão algumas etapas que você pode executar para configurar o tamanho da máquina virtual para um desempenho ideal.

Estimar o tamanho da VM com base no uso de CPU, memória e E/S do relatório AWR

Observe os cinco principais eventos de primeiro plano cronometrados que indicam onde estão os gargalos do sistema. Por exemplo, no diagrama a seguir, a sincronização do arquivo de log está na parte superior. Ele indica o número de esperas necessárias antes que o gravador de log grave o buffer de log no arquivo de log de refazer. Esses resultados indicam que são necessários discos ou armazenamento com melhor desempenho. Além disso, o diagrama também mostra o número de núcleos de CPU e a quantidade de memória.

Captura de ecrã que mostra a sincronização do ficheiro de registo na parte superior da tabela.

O diagrama a seguir mostra a E/S total de leitura e gravação. Havia 59 GB lidos e 247,3 GB escritos durante o tempo do relatório.

Escolha uma VM

Com base nas informações coletadas do relatório AWR, a próxima etapa é escolher uma VM de tamanho semelhante que atenda às suas necessidades. Para obter mais informações sobre VMs disponíveis, consulte Tamanhos de máquina virtual otimizados para memória.

Ajuste o dimensionamento da VM com uma série de VM semelhante baseada na ACU

Depois de escolher a VM, preste atenção à unidade de computação do Azure (ACU) para a VM. Você pode escolher uma VM diferente com base no valor da ACU que melhor se adapte às suas necessidades. Para obter mais informações, consulte Unidade de computação do Azure.

Captura de ecrã da página de unidades ACU.

Taxa de transferência da rede

O diagrama a seguir mostra a relação entre taxa de transferência e IOPS:

Diagrama que mostra a relação entre taxa de transferência e IOPS, que é IOPS vezes que o tamanho de E/S é igual à taxa de transferência.

A taxa de transferência total da rede é estimada com base nas seguintes informações:

Tráfego SQL*Net
MBps vezes o número de servidores (fluxo de saída, como o Oracle Data Guard)
Outros fatores, como replicação de aplicativos

Captura de tela da taxa de transferência SQL*Net.

Com base nos seus requisitos de largura de banda de rede, existem vários tipos de gateway para você escolher. Esses tipos incluem basic, VpnGw e Azure ExpressRoute. Para obter mais informações, consulte Preços do gateway VPN.

Recomendações

A latência da rede é maior em comparação com uma implantação local. Reduzir as viagens de ida e volta da rede pode melhorar muito o desempenho.
Para reduzir as viagens de ida e volta, consolide aplicativos com transações altas ou aplicativos de conversa na mesma máquina virtual.
Use máquinas virtuais com rede acelerada para um melhor desempenho de rede.
Para determinadas distribuições Linux, considere ativar o suporte a TRIM/UNMAP.
Instale o Oracle Enterprise Manager em uma máquina virtual separada.
Páginas enormes não são ativadas no Linux por padrão. Considere habilitar páginas enormes e definir use_large_pages = ONLY no banco de dados Oracle. Esta abordagem pode ajudar a aumentar o desempenho. Para obter mais informações, consulte USE_LARGE_PAGES.

Tipos e configurações de disco

Aqui estão algumas dicas ao considerar os discos.

Discos de SO predefinidos: estes tipos de disco oferecem dados persistentes e cache. Eles são otimizados para acesso ao sistema operacional na inicialização e não foram projetados para cargas de trabalho transacionais ou de data warehouse (analítico).
Discos gerenciados: o Azure gerencia as contas de armazenamento que você usa para seus discos VM. Você especifica o tipo de disco e o tamanho do disco que você precisa. O tipo é mais frequentemente Premium (SSD) para cargas de trabalho Oracle. O Azure cria e gerencia o disco para você. Um disco gerenciado por SSD premium só está disponível para séries de VMs otimizadas para memória e projetadas. Depois de escolher um tamanho de VM específico, o menu mostra apenas as SKUs de armazenamento premium disponíveis baseadas nesse tamanho de VM.

Depois de configurar o armazenamento em uma VM, convém carregar o teste dos discos antes de criar um banco de dados. Conhecer a taxa de E/S em termos de latência e taxa de transferência pode ajudá-lo a determinar se as VMs suportam a taxa de transferência esperada com destinos de latência. Existem várias ferramentas para testes de carga de aplicativos, como Oracle Orion, Sysbench, SLOB e Fio.

Execute o teste de carga novamente depois de implantar um banco de dados Oracle. Inicie suas cargas de trabalho regulares e de pico, e os resultados mostram a linha de base do seu ambiente. Seja realista no teste de carga de trabalho. Não faz sentido executar uma carga de trabalho que não é nada parecida com o que você executa na VM na realidade.

Como o Oracle pode ser um banco de dados intensivo de E/S, é importante dimensionar o armazenamento com base na taxa de IOPS e não no tamanho do armazenamento. Por exemplo, se o valor de IOPS necessário for 5.000, mas você precisar apenas de 200 GB, ainda poderá obter o disco premium da classe P30, mesmo que ele venha com mais de 200 GB de armazenamento.

Você pode obter a taxa IOPS do relatório AWR. O log de refazer, as leituras físicas e a taxa de gravação determinam a taxa de IOPS. Sempre verifique se a série de VMs escolhida tem a capacidade de lidar com a demanda de E/S da carga de trabalho. Se a VM tiver um limite de E/S inferior ao armazenamento, a VM definirá o limite máximo.

Captura de tela da página de relatório AWR.

Por exemplo, o tamanho de refazer é 12.200.000 bytes por segundo, o que é igual a 11,63 MBPs. O valor IOPS é 12.200.000 / 2.358 = 5.174.

Depois de ter uma imagem clara dos requisitos de E/S, você pode escolher uma combinação de drives mais adequados para atender a esses requisitos.

Recomendações de tipo de disco

Para espaço de tabela de dados, distribua a carga de trabalho de E/S por vários discos usando armazenamento gerenciado ou Oracle Automatic Storage Management (ASM).
Use a compactação avançada Oracle para reduzir a E/S de dados e índices.
Separe logs de refazer, temp e desfazer espaços de tabela em discos de dados separados.
Não coloque nenhum arquivo de aplicativo em discos padrão do sistema operacional. Esses discos não são otimizados para tempos de inicialização de VM rápidos e podem não fornecer um bom desempenho para seu aplicativo.
Quando você estiver usando VMs da série M no armazenamento premium, habilite o acelerador de gravação no disco de logs de refazer.
Considere mover logs de refazer com alta latência para o disco ultra.

Configurações de cache de disco

Embora você tenha três opções para cache de host, somente cache somente leitura é recomendado para uma carga de trabalho de banco de dados em um banco de dados Oracle. A leitura/gravação pode introduzir vulnerabilidades significativas em um arquivo de dados, porque o objetivo de uma gravação de banco de dados é registrá-lo no arquivo de dados, não armazenar as informações em cache. Com somente leitura, todas as solicitações são armazenadas em cache para leituras futuras. Todas as gravações continuam a ser gravadas no disco.

Recomendações de cache de disco

Para maximizar a taxa de transferência, comece com somente leitura para cache de host sempre que possível. Para armazenamento premium, lembre-se de que você deve desativar as barreiras ao montar o sistema de arquivos com as opções somente leitura. Atualize o arquivo /etc/fstab com o identificador universalmente exclusivo para os discos.

Para discos do sistema operacional, use SSD premium com cache de host de leitura-gravação.
Para discos de dados que contenham o seguinte, use SSD premium com cache de host somente leitura: arquivos de dados Oracle, arquivos temporários, arquivos de controle, arquivos de controle de alterações de bloco, BFILEs, arquivos para tabelas externas e logs de flashback.
Para discos de dados que contêm arquivos de log de refazer on-line da Oracle, use SSD premium ou UltraDisk sem cache de host, a opção Nenhum . Os arquivos de log de refazer Oracle arquivados e os conjuntos de backup do Oracle Recovery Manager também podem residir com os arquivos de log de refazer on-line. O cache de host é limitado a 4.095 GiB, portanto, não aloque um SSD premium maior que P50 com cache de host. Se você precisar de mais de 4 TiB de armazenamento, distribua vários SSDs premium com RAID-0. Use Linux LVM2 ou Oracle Automatic Storage Management.

Se as cargas de trabalho variam muito entre o dia e a noite, e a carga de trabalho de E/S pode suportá-la, o SSD premium P1-P20 com bursting pode fornecer o desempenho necessário durante cargas em lote noturnas ou demandas limitadas de E/S.

Segurança

Depois de instalar e configurar seu ambiente do Azure, você precisa proteger sua rede. Veja a seguir algumas recomendações:

Política NSG: Você pode definir seu NSG por uma sub-rede ou uma placa de interface de rede. É mais simples controlar o acesso no nível da sub-rede, tanto para segurança quanto para firewalls de aplicativos de roteamento forçado.
Jumpbox: para um acesso mais seguro, os administradores não devem se conectar diretamente ao serviço de aplicativo ou banco de dados. Use uma jumpbox entre a máquina do administrador e os recursos do Azure.

A máquina do administrador só deve oferecer acesso restrito por IP à jumpbox. O jumpbox deve ter acesso ao aplicativo e banco de dados.
Rede privada (sub-redes): é uma boa ideia ter o serviço de aplicativo e o banco de dados em sub-redes separadas, para que a política NSG possa definir um melhor controle.

Partilhar via