Arquiteturas do Oracle Database Enterprise Edition no Azure

Artigo
10/14/2024

Aplica-se a: ✔️ VMs do Linux

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

Este artigo ajuda a preparar uma carga de trabalho do Oracle para executar no Azure e explorar as melhores soluções de arquitetura para fornecer o desempenho ideal na nuvem. Os dados fornecidos pelo Oracle no Statspack e ainda mais em seu descendente, o AWR, ajuda 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, tenha em mente 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 de acordo com os requisitos. Em vez de focar em evitar falhas, o Azure foca mais em sobreviver a elas. 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 no Azure
Rede	LAN/WAN	SDN (rede definida pelo software)
Grupo de segurança	Ferramentas de restrições de IP/porta	NSG (Grupo de segurança de rede)
Resiliência	MTBF	MTTR
Manutenção planejada	Aplicação de patch/upgrades	Conjuntos de disponibilidade com aplicação de patch/atualizações gerenciados pelo Azure
Recurso	Dedicado	Compartilhado com outros clientes
Regiões	Datacenters	Pares de regiões
Storage	SAN/discos físicos	Armazenamento gerenciado pelo Azure
Escala	Escala vertical	Escala horizontal

Requisitos

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

Determine o uso real da CPU. O Oracle é licenciado por núcleo, o que significa que o dimensionamento das necessidades de vCPU pode ser um exercício essencial para ajudar 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 podem ser estimados com base nos relatórios do Oracle Statspack e do AWR. Você também pode estimar os requisitos 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 que ajudam a tomar decisões sobre a configuração. E há quatro áreas possíveis que você pode ajustar para melhorar o desempenho em um ambiente do Azure:

Tamanho da máquina virtual
Taxa de transferência de 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 a migração para o Azure, terá várias opções. Se você tiver o Diagnostics Pack para suas instâncias do Oracle, poderá executar o relatório do Oracle AWR para obter as métricas, como IOPS, Mbps e GiBs. Para esses bancos de dados sem a licença do Diagnostics Pack, ou para um banco de dados do Oracle Standard Edition, você pode coletar as mesmas métricas importantes com um relatório do 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 a execução do relatório AWR durante cargas de trabalho regulares e de pico para poder compará-las. 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 do AWR retém oito dias de dados e tira instantâneos em intervalos de hora.

Para uma migração de datacenter, colete relatórios para dimensionamento nos sistemas de produção. Estime o restante de cópias do banco de dados usadas para testes de usuário, testes e desenvolvimento em porcentagens. Por exemplo, estime 50% do dimensionamento de produção.

Para executar um relatório do AWR na linha de comando, use o seguinte comando:

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

Métricas-chave

O relatório solicitará 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 exibir. Por exemplo, para intervalos de uma hora, um relatório de uma semana produz 168 IDs de instantâneo.
O SnapshotID inicial da janela de relatório.
O SnapshotID final da janela de relatório.
O nome do relatório criado pelo script AWR.

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

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

Nome do banco de dados, nome da instância e nome do host
Versão do banco de dados para suporte do Oracle
CPU/núcleos
SGA/PGA e consultores para informar se ele for subdimensionado
Memória total em GB
Percentual ocupado de CPU
CPUs de BD
IOPs (leitura/gravação)
MBPs (leitura/gravação)
Taxa de transferência de rede
Taxa de latência de rede (baixa/alta)
Principais eventos de espera
Configurações de parâmetro para o banco de dados
Se o banco de dados for RAC, Exadata ou usa recursos ou configurações avançadas

Tamanho da máquina virtual

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

Estimativa do tamanho da VM é baseada no uso de CPU, memória e E/S do relatório AWR

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

Captura de tela que mostra a sincronização do arquivo de log na parte superior da tabela.

O diagrama a seguir mostra o total de E/S de leitura e gravação. 59 GB de leitura e 247,3 GB de gravação ocorreram durante o período do relatório.

Escolher uma VM

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

Ajustar o dimensionamento da VM com uma série de VM parecida baseada na ACU

Depois de escolher a VM, verifique a ACU (unidade de computação do Azure) da VM. Você pode escolher uma VM diferente com base no valor da ACU que atender melhor às suas necessidades. Para saber mais, confira Unidade de computação do Azure.

Captura de tela da página de unidades de ACU.

Taxa de transferência de rede

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

Diagrama que mostra a relação entre a taxa de transferência e o IOPS, onde o IOPS multiplicado pelo tamanho de E/S resulta na taxa de transferência.

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

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

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

Com base nos requisitos de largura de banda de sua rede, há vários tipos de gateway para escolher. Esses tipos incluem basic, VpnGw e Azure ExpressRoute. Para saber mais, veja Preços do Gateway de VPN.

Recomendações

A latência de rede é maior em comparação com uma implantação local. Reduzir as viagens de ida e volta da rede pode melhorar significativamente o desempenho.
Para reduzir as viagens de ida e volta, consolide os aplicativos que têm transações alta ou aplicativos comunicativos na mesma máquina virtual.
Use máquinas virtuais do Microsoft Azure com rede acelerada para melhorar o desempenho da rede.
Para determinadas distribuições do Linux, considere habilitar o suporte a TRIM/UNMAP.
Instale o Oracle Enterprise Manager em uma máquina virtual separada.
Páginas enormes não são habilitadas no Linux por padrão. Considere habilitar páginas enormes e definir use_large_pages = ONLY no Oracle DB. Essa abordagem pode ajudar a aumentar o desempenho. Para saber mais, confira USE_LARGE_PAGES.

Tipos e configurações de disco

Veja algumas dicas ao considerar os discos.

Discos padrão do SO: esses tipos de disco oferecem dados persistentes e cache. Eles são otimizados para acesso do sistema operacional na inicialização, e não foram projetados para cargas de trabalho transacionais ou de data warehouse (analíticas).
Discos gerenciados: o Azure gerencia contas de armazenamento que podem ser usadas para seus discos de VM. Especifique o tipo e o tamanho do disco de que você precisa. O tipo geralmente é 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 VM otimizadas e designadas para memória. Depois de escolher um tamanho de VM específico, o menu mostrará apenas os SKUs de armazenamento premium disponíveis com base no tamanho da VM.

Depois de configurar o armazenamento em uma VM, realize um teste de carga nos discos antes de criar um banco de dados. Saber a taxa de E/S em termos de latência e taxa de transferência pode ajudar a determinar se as VMs dão suporte às metas de taxa de transferência e latência esperadas. Há diversas ferramentas para realizar o teste de carga do aplicativo, 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 de pico e regulares, e os resultados mostram a linha de base de seu ambiente. Seja realista no teste de carga de trabalho. Não faz sentido executar uma carga de trabalho que não se parece nada com o que você realmente executa na VM.

Como o Oracle pode ser um banco de dados com uso intensivo de E/S, é muito importante dimensionar o armazenamento com base na taxa de E/S em vez do tamanho do armazenamento. Por exemplo, se o valor de E/S necessário for 5.000, mas você só precisa de 200 GB, ainda poderá obter o disco premium de classe P30, mesmo que ele venha com mais de 200 GB de armazenamento.

Você pode obter a taxa de IOPS do relatório do AWR. O log de refazer, as leituras físicas e a taxa de gravações determinam a taxa de E/S. Sempre verifique se a série de VM que você escolheu consegue lidar com a demanda de E/S da carga de trabalho. Se a VM tiver um limite de E/S menor do que o armazenamento, a VM definirá o limite máximo.

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

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

Quando você tiver uma visão clara dos requisitos de E/S, poderá escolher a combinação de unidades mais adequada para atender a esses requisitos.

Recomendações de tipo de disco

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

Configurações de cache de disco

Embora você tenha três opções de cache de host, somente o cache ReadOnly é recomendado para uma carga de trabalho de banco de dados em um banco de dados Oracle. Leitura/gravação pode introduzir vulnerabilidades significativas em um arquivo de dados, pois o objetivo de uma gravação de banco de dados é registrá-lo no arquivo de informações, não armazenar em cache a informação. 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 o cache de host sempre que possível. Para o armazenamento premium, lembre-se de que você deve desabilitar as barreiras ao montar o sistema de arquivos com as opções somente leitura. Atualize o arquivo /etc/fstab com o identificador universal exclusivo para os discos.

Para discos do sistema operacional, use o SSD premium com cache de host de leitura-gravação.
Para discos de dados que contêm o seguinte, use SSD premium com cache de host de leitura-gravação: arquivos de dados Oracle, arquivos temporários, arquivos de controle, bloquear arquivos de acompanhamento de alterações, BFILEs, arquivos para tabelas externas e logs de flashback.
Para discos de dados que contêm arquivos de log de refazer online do Oracle, use SSD premium ou UltraDisk sem cache de host, a opção Nenhum. Os arquivos de log refazer do Oracle que são arquivados e os conjuntos de backup do Gerenciador de Recuperação do Oracle, também podem residir com os arquivos de log de refazer online. 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 o Linux LVM2 ou o 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 dar suporte a ela, o SSD premium P1-P20 com intermitência pode fornecer o desempenho necessário durante cargas de lote noturnas ou demandas de E/S limitadas.

Segurança

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

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

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

Compartilhar via