Arquiteturas do Oracle Database Enterprise Edition no Azure

  • Artigo

Aplica-se a: ✔️ VMs do Linux

O Azure é o lar de todas as cargas de trabalho oracle, incluindo cargas de trabalho que precisam de continuar a ser executadas de forma ideal no Azure com o Oracle. Se tiver o Pacote de Diagnóstico Oracle ou o Repositório Automático de Cargas de Trabalho (AWR), pode recolher dados sobre as suas cargas de trabalho. Utilize estes dados para avaliar a carga de trabalho oracle, dimensionar as necessidades dos recursos e migrar a carga de trabalho para o Azure. As várias métricas fornecidas pela Oracle nestes relatórios podem fornecer uma compreensão do desempenho da aplicação e da utilização da plataforma.

Este artigo ajuda-o a preparar uma carga de trabalho oracle para ser executada no Azure e explorar as melhores soluções de arquitetura para proporcionar um desempenho ideal na cloud. Os dados fornecidos pela Oracle no Statspack e ainda mais no seu descendente, o AWR, ajudam-no a desenvolver expectativas claras. Estas expetativas incluem os limites de otimização física através da arquitetura, as vantagens da otimização lógica do código da base de dados e o design geral da base de dados.

Diferenças entre os dois ambientes

Quando estiver a migrar aplicações no local para o Azure, tenha em atenção algumas diferenças importantes entre os dois ambientes.

Uma diferença importante é que numa implementação do Azure, recursos como VMs, discos e redes virtuais são partilhados 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 concentra-se 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 seguinte lista algumas das diferenças entre uma implementação no local e uma implementação do Azure de uma base de dados Oracle.

Implementação no local Implementação do Azure
Redes 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 Aplicação de patches/atualizações Conjuntos de disponibilidade com patches/atualizações geridas pelo Azure
Recurso Dedicada Partilhado com outros clientes
Regiões Datacenters Pares de região
Armazenamento SAN/discos físicos Armazenamento gerido pelo Azure
Dimensionamento Escala vertical Dimensionamento horizontal

Requisitos

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

  • Determine a utilização real da CPU. As licenças oracle por núcleo, o que significa que o dimensionamento das suas necessidades de vCPU pode ser essencial para o ajudar a reduzir os custos.
  • Determine o tamanho da base de dados, o armazenamento de cópias de segurança e a taxa de crescimento.
  • Determine os requisitos de E/S, que pode estimar com base no Oracle Statspack e nos relatórios AWR. Também pode estimar os requisitos das ferramentas de monitorização de armazenamento disponíveis a partir do sistema operativo.

Opções de configuração

É uma boa ideia gerar um relatório da AWR e obter algumas métricas do mesmo para o ajudar a tomar decisões sobre a configuração. Em seguida, existem quatro áreas potenciais que pode otimizar para melhorar o desempenho num ambiente do Azure:

  • Tamanho da máquina virtual
  • Débito de rede
  • Tipos de disco e configurações
  • Definições da cache do disco

Gerar um relatório AWR

Se tiver uma base de dados oracle Enterprise Edition existente e estiver a planear migrar para o Azure, tem várias opções. Se tiver o Pacote de Diagnósticos para as instâncias oracle, pode executar o relatório Oracle AWR para obter as métricas, como IOPS, Mbps e GiBs. Para essas bases de dados sem a licença do Pacote de Diagnósticos ou para uma base de dados oracle Standard Edition, pode recolher as mesmas métricas importantes com um relatório Statspack depois de recolher instantâneos manuais. As principais diferenças entre estes dois métodos de relatório são que a AWR é recolhida automaticamente e que fornece mais informações sobre a base de dados do que o Statspack.

Considere executar o relatório AWR durante as cargas de trabalho regulares e de pico, para que possa comparar. Para recolher a carga de trabalho mais precisa, considere um relatório de janela alargado de uma semana, em vez de um dia. A AWR fornece médias como parte dos cálculos no relatório. Por predefinição, o repositório AWR retém oito dias de dados e tira instantâneos em intervalos de hora a hora.

Para uma migração de datacenter, deve recolher relatórios para dimensionamento nos sistemas de produção. Estimar as cópias restantes da base de dados utilizadas para testes, testes e desenvolvimento de utilizadores por percentagens. Por exemplo, calcule 50% do dimensionamento de produção.

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

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

Principais métricas

O relatório pede-lhe as seguintes informações:

  • Tipo de relatório: HTML ou TEXTO. O tipo HTML fornece mais informações.
  • O número de dias de instantâneos a apresentar. 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 do relatório.
  • O fim SnapshotID da janela do relatório.
  • O nome do relatório que o script AWR cria.

Se estiver a executar o relatório AWR num Cluster de Aplicações Reais (RAC), o relatório da linha de comandos é o ficheiro awrgrpt.sql , em vez de awrrpt.sql. O g relatório cria um relatório para todos os nós na base de dados RAC num único relatório. Este relatório elimina a necessidade de executar um relatório em cada nó RAC.

Pode obter as seguintes métricas a partir do relatório AWR:

  • Nome da base de dados, nome da instância e nome do anfitrião
  • Versão da base de dados para suporte da Oracle
  • CPU/Núcleos
  • SGA/PGA e assistentes para informá-lo se estiver subdimensionado
  • Memória total em GB
  • Percentagem de CPU ocupada
  • CPUs da BD
  • IOPs (leitura/escrita)
  • MBPs (leitura/escrita)
  • Débito de rede
  • Taxa de latência de rede (baixa/alta)
  • Principais eventos de espera
  • Definições de parâmetros para a base de dados
  • Se a base de dados é RAC, Exadata ou utiliza funcionalidades ou configurações avançadas

Tamanho da máquina virtual

Eis alguns passos que pode seguir para configurar o tamanho da máquina virtual para um desempenho ideal.

Estimar o tamanho da VM com base na utilização da CPU, memória e E/S do relatório AWR

Veja os cinco principais eventos de primeiro plano cronometrados que indicam onde estão os estrangulamentos do sistema. Por exemplo, no diagrama seguinte, a sincronização do ficheiro de registo está na parte superior. Indica o número de esperas necessárias antes de o escritor de registos escrever a memória intermédia de registos no ficheiro de registo de refazer. Estes resultados indicam que é necessário um melhor desempenho do armazenamento ou dos discos. 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 seguinte mostra a E/S total de leitura e escrita. Foram lidos 59 GB e 247,3 GB escritos durante a hora do relatório.

Captura de ecrã que mostra a E/S total de leitura e escrita.

Escolher uma VM

Com base nas informações que recolheu do relatório AWR, o próximo passo é escolher uma VM com um tamanho semelhante que cumpra os seus requisitos. Para obter mais informações sobre as VMs disponíveis, veja Tamanhos de máquinas virtuais otimizadas para memória.

Ajustar o dimensionamento da VM com uma série de VM semelhante com base na ACU

Depois de escolher a VM, preste atenção à unidade de computação (ACU) do Azure para a VM. Pode escolher uma VM diferente com base no valor da ACU que melhor se adequa aos seus requisitos. Para obter mais informações, veja Unidade de computação do Azure.

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

Débito de rede

O diagrama seguinte mostra a relação entre débito e IOPS:

Diagrama que mostra a relação entre débito e IOPS, que é IOPS vezes tamanho de E/S igual a débito.

O débito total da rede é estimado com base nas seguintes informações:

  • SQL*Tráfego líquido
  • MBps vezes o número de servidores (fluxo de saída, como Oracle Data Guard)
  • Outros fatores, como a replicação de aplicações

Captura de ecrã do débito SQL*Net.

Com base nos seus requisitos de largura de banda de rede, existem vários tipos de gateway à sua escolha. Estes tipos incluem básico, VpnGw e Azure ExpressRoute. Para obter mais informações, veja Gateway de VPN preços.

Recomendações

  • A latência de rede é maior em comparação com uma implementação no local. A redução das viagens de ida e volta de rede pode melhorar consideravelmente o desempenho.
  • Para reduzir as viagens de ida e volta, consolide aplicações com transações elevadas ou aplicações chatas na mesma máquina virtual.
  • Utilize máquinas virtuais com redes aceleradas para um melhor desempenho de rede.
  • Para determinadas distribuições do Linux, considere ativar o suporte TRIM/UNMAP.
  • Instale o Oracle Enterprise Manager numa máquina virtual separada.
  • Por predefinição, as páginas enormes não estão ativadas no Linux. Considere ativar páginas enormes e definir use_large_pages = ONLY no Oracle DB. Esta abordagem pode ajudar a aumentar o desempenho. Para obter mais informações, veja USE_LARGE_PAGES.

Tipos de disco e configurações

Seguem-se algumas sugestões à medida que considera os discos.

  • Discos de SO predefinidos: Estes tipos de disco oferecem dados persistentes e colocação em cache. Estão otimizados para o acesso ao sistema operativo no arranque e não foram concebidos para cargas de trabalho transacionais ou do armazém de dados (analíticos).

  • Discos geridos: O Azure gere as contas de armazenamento que utiliza para os discos de VM. Especifique o tipo de disco e o tamanho do disco de que precisa. O tipo é, na maioria das vezes, Premium (SSD) para cargas de trabalho Oracle. O Azure cria e gere o disco por si. Um disco gerido por SSD premium só está disponível para séries de VMs otimizadas para memória e concebidas. Depois de escolher um tamanho de VM específico, o menu mostra apenas os SKUs de armazenamento premium disponíveis que se baseiam nesse tamanho de VM.

    Captura de ecrã a mostrar a página do disco gerido.

Depois de configurar o armazenamento numa VM, poderá querer carregar os discos antes de criar uma base de dados. Conhecer a taxa de E/S em termos de latência e débito pode ajudá-lo a determinar se as VMs suportam o débito esperado com destinos de latência. Existem várias ferramentas para testes de carga de aplicações, como Oracle Orion, Sysbench, SLOB e Fio.

Execute novamente o teste de carga depois de implementar uma base de dados Oracle. Inicie as cargas de trabalho regulares e de pico e os resultados mostram-lhe a linha de base do seu ambiente. Seja realista no teste da carga de trabalho. Não faz sentido executar uma carga de trabalho que não seja nada semelhante à que executa na VM na realidade.

Uma vez que o Oracle pode ser uma base de dados intensiva de E/S, é importante dimensionar o armazenamento com base na taxa de IOPS em vez do tamanho do armazenamento. Por exemplo, se o valor de IOPS necessário for 5000, mas apenas precisar de 200 GB, ainda poderá obter o disco premium da classe P30, apesar de ser fornecido com mais de 200 GB de armazenamento.

Pode obter a taxa de IOPS no relatório AWR. O registo de refazer, as leituras físicas e a taxa de escrita determinam a taxa de IOPS. Verifique sempre se a série de VMs que escolher tem a capacidade de lidar com a procura de E/S da carga de trabalho. Se a VM tiver um limite de E/S inferior ao armazenamento, a VM define o limite máximo.

Captura de ecrã a mostrar a página do relatório AWR.

Por exemplo, o tamanho de refazer é de 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, pode escolher uma combinação de unidades mais adequadas para satisfazer esses requisitos.

Recomendações de tipo de disco

  • Para o espaço de tabelas de dados, espalhe a carga de trabalho de E/S em vários discos através do armazenamento gerido ou da Gestão Automática de Armazenamento (ASM) do Oracle.
  • Utilize a compressão avançada oracle para reduzir a E/S para dados e índices.
  • Separe os registos de refazer, temp e anule as áreas de tabela em discos de dados separados.
  • Não coloque ficheiros de aplicação em discos de sistema operativo predefinidos. Estes discos não estão otimizados para tempos de arranque rápidos da VM e podem não fornecer um bom desempenho para a sua aplicação.
  • Quando estiver a utilizar VMs da Série M no armazenamento premium, ative o acelerador de escrita no disco de registos de refazer.
  • Considere mover registos de refazer com latência elevada para o disco ultra.

Definições da cache do disco

Embora tenha três opções para colocação em cache de anfitriões, recomenda-se apenas a colocação em cache só de leitura para uma carga de trabalho de base de dados numa base de dados Oracle. A leitura/escrita pode introduzir vulnerabilidades significativas num ficheiro de dados, uma vez que o objetivo de uma escrita de base de dados é gravá-lo no ficheiro de dados e não colocar as informações em cache. Com só de leitura, todos os pedidos são colocados em cache para leituras futuras. Todas as escritas continuam a ser escritas no disco.

Recomendações de cache de disco

Para maximizar o débito, comece com só de leitura para colocação em cache do anfitrião sempre que possível. Para o armazenamento premium, tenha em atenção que tem de desativar as barreiras quando montar o sistema de ficheiros com as opções só de leitura. Atualize o ficheiro /etc/fstab com o identificador universalmente exclusivo para os discos.

Captura de ecrã da página de disco gerido que mostra a opção só de leitura.

  • Para discos do sistema operativo, utilize o SSD premium com colocação em cache do anfitrião de leitura-escrita.
  • Para discos de dados que contenham o seguinte, utilize o SSD premium com colocação em cache de anfitrião só de leitura: ficheiros de dados Oracle, ficheiros temporários, ficheiros de controlo, ficheiros de controlo de alterações de blocos, BFILEs, ficheiros para tabelas externas e registos de flashback.
  • Para discos de dados que contenham ficheiros de registo de refazer online do Oracle, utilize sSD premium ou UltraDisk sem colocação em cache de anfitriões, a opção Nenhum . Os ficheiros de registo do Oracle que estão arquivados e o Oracle Gestor de Recuperação conjuntos de cópias de segurança também podem residir com os ficheiros de registo de refazer online. A colocação em cache de anfitriões está limitada a 4095 GiB, pelo que não aloque um SSD premium maior do que P50 com colocação em cache de anfitrião. Se precisar de mais de 4 TiB de armazenamento, liste vários SSDs premium com RAID-0. Utilize o Linux LVM2 ou a Gestão Automática de Armazenamento do Oracle.

Se as cargas de trabalho variarem muito entre o dia e a noite e a carga de trabalho de E/S o suportar, o SSD P1-P20 premium com expansão poderá fornecer o desempenho necessário durante cargas de lote noturnas ou exigências de E/S limitadas.

Segurança

Depois de configurar o ambiente do Azure, tem de proteger a sua rede. Veja a seguir algumas recomendações:

  • Política NSG: Pode definir o NSG por uma sub-rede ou uma placa de interface de rede. É mais simples controlar o acesso ao nível da sub-rede, tanto para segurança como para firewalls de aplicações de encaminhamento forçado.

  • Jumpbox: Para um acesso mais seguro, os administradores não devem ligar-se diretamente ao serviço de aplicação ou à base de dados. Utilize uma jumpbox entre o computador administrador e os recursos do Azure.

    Diagrama que mostra a topologia jumpbox.

    O computador administrador só deve oferecer acesso restrito por IP à jumpbox. A jumpbox deve ter acesso à aplicação e à base de dados.

  • Rede privada (sub-redes): É uma boa ideia ter o serviço de aplicação e a base de dados em sub-redes separadas, para que a política do NSG possa definir um melhor controlo.

Recursos

Passos seguintes