Conceça e implemente uma base de dados oracle em Azure

Aplica-se a: ✔️ Linux VMs

Azure é o lar de todas as cargas de trabalho da Oráculo, incluindo aquelas que precisam continuar a correr da melhor forma em Azure com o Oráculo. Se tiver o Pacote de Diagnóstico ou o Repositório de Carga Automática , pode utilizar estes dados para avaliar a carga de trabalho do Oráculo, dimensionar as necessidades do recurso e emigrá-lo para Azure. As várias métricas fornecidas pela Oracle nestes relatórios podem fornecer uma compreensão de base do desempenho da aplicação e da utilização da plataforma.

Este artigo irá ajudá-lo a entender como dimensionar uma carga de trabalho da Oracle para correr em Azure e explorar as melhores soluções de arquitetura para fornecer o desempenho em nuvem mais ideal. Os dados fornecidos pela Oracle no Statspack e ainda mais no seu descendente, a AWR, irão ajudá-lo a desenvolver expectativas claras sobre os limites da afinação física através da arquitetura, as vantagens da afinação lógica do código de 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 Azure, lembre-se de 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 acelerados com base nos requisitos. Em vez de se concentrar em evitar falhar (por vezes referido como tempo médio entre falhas, ou MTBF), O Azure está mais focado em sobreviver à falha (por vezes referida como tempo médio de recuperação, ou MTTR).

O quadro que se segue enumera algumas das diferenças entre uma implementação no local e uma implementação Azure de uma base de dados oracle.

Implementação no local Implementação do Azure
Redes LAN/WAN SDN (rede definida por software)
Grupo de segurança Ferramentas de restrição IP/porta Grupo de segurança de rede (NSG)
Resiliência MTBF MTTR
Manutenção planeada Remendar/actualizars Conjuntos de disponibilidade (patching/upgrades geridos pelo Azure)
Recurso Dedicada Partilhado com outros clientes
Regiões Datacenters Pares de região
Armazenamento DISCOS SAN/Físicos Armazenamento gerido pelo Azure
Dimensionamento Escala vertical Dimensionamento horizontal

Requisitos

É uma boa ideia considerar os seguintes requisitos antes de iniciar a sua migração:

  • Determine o uso real do CPU. A Oracle é licenciada pelo core, o que significa que o dimensionamento das necessidades do VCPU pode ser um exercício essencial para ajudá-lo a reduzir custos.
  • Determine o tamanho da base de dados, armazenamento de backup e taxa de crescimento.
  • Determine os requisitos de E/O, que pode estimar com base nos relatórios do Oracle Statspack e do Repositório automático de Carga de Trabalho (AWR). Também pode estimar os requisitos das ferramentas de monitorização de armazenamento disponíveis no sistema operativo.

Opções de configuração

É uma boa ideia gerar um relatório de AWR e obter algumas métricas dele que o ajudam a tomar decisões sobre a configuração. Depois, há quatro áreas potenciais que pode sintonizar para melhorar o desempenho num ambiente Azure:

  • Tamanho da máquina virtual
  • Produção de rede
  • Tipos e configurações de discos
  • Definições de cache de disco

Gerar um relatório da AWR

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

Você pode considerar executar o seu relatório de AWR durante cargas de trabalho regulares e máximas, para que possa comparar. Para recolher a carga de trabalho mais precisa, considere um relatório de janela alargado de uma semana, ao contrário de um dia. A AWR fornece médias como parte dos seus cálculos no relatório.

Para uma migração do datacenter, é uma boa ideia recolher relatórios para dimensionamento nos sistemas de produção. Estimar as restantes cópias de base de dados utilizadas para testes, testes e desenvolvimento por percentagens (por exemplo, 50% do tamanho da produção).

Por padrão, o repositório AWR retém 8 dias de dados e tira fotos em intervalos de hora. Para executar um relatório AWR a partir da linha de comando, utilize o seguinte comando:

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

Principais métricas

O relatório solicita-lhe 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 identificações instantâneas.
  • O início SnapshotID da janela do relatório.
  • O final SnapshotID para a janela do relatório.
  • O nome do relatório a ser criado pelo script AWR.

Se estiver a executar o relatório da AWR sobre um Cluster de Aplicação Real (RAC), o relatório da linha de comando é 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 fazer um relatório sobre cada nó RAC.

Pode obter as seguintes métricas no relatório da AWR:

  • Nome da base de dados, nome da instância e nome do anfitrião
  • Versão de base de dados (suportabilidade da Oracle)
  • CPU/Núcleos
  • SGA/PGA (e assessores para informá-lo se subdimensionado)
  • Memória total em GB
  • Percentagem de CPU ocupada
  • DB CPUs
  • IOPs (ler/escrever)
  • MBPs (ler/escrever)
  • Produção de rede
  • Taxa de latência da rede (baixa/alta)
  • Principais eventos de espera
  • Definições de parâmetros para base de dados
  • É a base de dados RAC, Exadata, ou usando funcionalidades ou configurações avançadas

Tamanho da máquina virtual

Aqui estão alguns passos que pode tomar para configurar o tamanho da máquina virtual para um desempenho ideal.

Estimativa do tamanho do VM com base no uso de CPU, memória e I/O do relatório AWR

Veja os cinco primeiros eventos cronometrais 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 que são necessárias antes do escritor de registos escrever o tampão de registo para o ficheiro de registo de redo. Estes resultados indicam que são necessários armazenamento ou discos de melhor desempenho. Além disso, o diagrama também mostra o número de CPU (núcleos) e a quantidade de memória.

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

O diagrama seguinte mostra o total de E/O de ler e escrever. Foram 59 GB lidos e 247,3 GB escritos durante o período do relatório.

Screenshot que mostra o total de E/O de ler e escrever.

Escolha um VM

Com base nas informações recolhidas no relatório da AWR, o próximo passo é escolher um VM de tamanho semelhante que satisfaça os seus requisitos. Pode encontrar uma lista de VMs disponíveis na Memória otimizada.

Afinar o tamanho VM com uma série de VM semelhante baseada na ACU

Depois de ter escolhido o VM, preste atenção à unidade de computação Azure (ACU) para o VM. Você pode escolher um VM diferente com base no valor ACU que melhor se adequa aos seus requisitos. Para mais informações, consulte a unidade de computação Azure.

Screenshot da página das unidades da ACU.

Produção de rede

O diagrama a seguir mostra a relação entre a produção e o IOPS:

Diagrama que mostra a relação entre a produção e o IOPS.

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

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

Screenshot da produção SQL*Net.

Com base nos requisitos de largura de banda da sua rede, existem vários tipos de gateway para escolher. Estes incluem básico, VpnGw, e Azure ExpressRoute. Para mais informações, consulte a página de preços da porta de entrada VPN.

Recomendações

  • A latência da rede é maior em comparação com uma implantação no local. A redução das viagens de ida e volta na rede pode melhorar consideravelmente o desempenho.
  • Para reduzir as viagens de ida e volta, consolidar aplicações que tenham transações elevadas ou aplicações "chatty" na mesma máquina virtual.
  • Utilize máquinas virtuais com rede acelerada para um melhor desempenho da rede.
  • Para certas distribuições do Linux, considere ativar o suporte TRIM/UNMAP.
  • Instale o Oracle Enterprise Manager numa máquina virtual separada.
  • Por defeito, as páginas enormes não são ativadas no Linux. Considere ativar páginas enormes, e definir use_large_pages = ONLY no Oráculo DB. Isto pode ajudar a aumentar o desempenho. Para mais informações, consulte USE_LARGE_PAGES.

Tipos e configurações de discos

Aqui estão algumas dicas para si, como considera os discos.

  • Discos de OS predefinidos: Estes tipos de disco oferecem dados persistentes e cache. São otimizados para o acesso do sistema operativo no arranque, e não são projetados para cargas de trabalho transacionais ou de armazém de dados (analíticos).

  • Discos geridos: O Azure gere as contas de armazenamento que utiliza para os discos VM. Você especifica o tipo de disco (na maioria das vezes, este é OSD premium para cargas de trabalho Oráculos) e o tamanho do disco que você precisa. Azure cria e gere o disco para si. Um disco gerido por SSD premium só está disponível para séries VM otimizadas para memória e especificamente concebidas. Depois de escolher um determinado tamanho VM, o menu mostra apenas os SKUs de armazenamento premium disponíveis que são baseados nesse tamanho VM.

    Screenshot da página de disco gerida.

Depois de configurar o seu armazenamento num VM, é melhor carregar os discos antes de criar uma base de dados. Conhecer a taxa de E/S em termos de latência e produção pode ajudá-lo a determinar se os VMs suportam a produção esperada com alvos de latência. Existem várias ferramentas para testes de carga de aplicação, tais como Oracle Orion, Sysbench, SLOB e Fio.

Faça o teste de carga de novo depois de ter implantado uma base de dados oracle. Inicie as suas cargas de trabalho regulares e máximas, e os resultados mostram-lhe 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 vais correr no VM na realidade.

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

Pode obter a taxa de IOPS no relatório da AWR. É determinado pelo registo de redo, leituras físicas e taxa de escrita. Verifique sempre se a série VM que escolhe também tem a capacidade de lidar com a procura de E/S da carga de trabalho. Se o VM tiver um limite de E/S inferior ao armazenamento, o limite máximo será fixado pelo VM.

Screenshot da página de relatório da AWR.

Por exemplo, o tamanho do redo é de 12.200.000 bytes por segundo, o que equivale a 11,63 MBPs. O IOPS é de 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 que sejam mais adequadas para satisfazer esses requisitos.

Recomendações

  • Para o espaço de tabela de dados, espalhe a carga de trabalho de E/S através de vários discos utilizando o armazenamento gerido ou o Oracle ASM.
  • Utilize a compressão avançada da Oracle para reduzir a E/S (tanto para dados como para índices).
  • Separe os registos de redo, a temperatura e a desação de espaços de mesa em discos de dados separados.
  • Não coloque ficheiros de aplicações em discos do sistema operativo predefinidos. Estes discos não estão otimizados para tempos de arranque rápidos em VM, e podem não proporcionar 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 redo.
  • Considere mover registos de redo com alta latência para o disco ultra.

Definições de cache de disco

Embora tenha três opções para o caching do anfitrião, apenas o caching apenas de leitura é recomendado para uma carga de dados de base de dados numa base de dados oracle. A leitura/escrita pode introduzir vulnerabilidades significativas num ficheiro de dados, porque o objetivo de uma base de dados escrever é gravá-lo no ficheiro de dados, não cache a informação. Com apenas leitura, todos os pedidos são em cache para futuras leituras. Todos os escritos continuam a ser escritos para o disco.

Recomendações

Para maximizar a produção, comece com apenas leitura para o caching do anfitrião sempre que possível. Para um armazenamento premium, tenha em mente que deve desativar as barreiras quando monta o sistema de ficheiros com as opções de leitura. Atualize o ficheiro /etc/fstab com o identificador universalmente único para os discos.

Screenshot da página de disco gerida que mostra a opção apenas de leitura.

  • Para discos do sistema operativo, utilize SSD premium com cache do anfitrião de leitura.
  • Para discos de dados que contenham o seguinte, utilize SSD premium com cache de anfitrião apenas de leitura: ficheiros de dados da Oracle, ficheiros temporários, ficheiros de controlo, ficheiros de rastreio de alterações de blocos, BFILEs, ficheiros para tabelas externas e registos de flashback.
  • Para discos de dados que contenham ficheiros de registo de redo online Oracle, utilize SSD premium ou UltraDisk sem cache de anfitrião (a opção Zero ). Os ficheiros de registo de redo oracle que são arquivados e os conjuntos de backup da Oracle Gestor de Recuperação, também podem residir com os ficheiros de registo de redo online. Note que o caching do anfitrião está limitado a 4095 GiB, por isso não aloque um SSD premium maior que P50 com caching hospedeiro. Se precisar de mais de 4 TiB de armazenamento, listre vários SSDs premium com RAID-0, utilizando o Linux LVM2 ou utilizando a Oracle Automatic Storage Management.

Se as cargas de trabalho variarem muito entre o dia e a noite, e a carga de trabalho de E/S puder apoiá-la, o SSD premium P1-P20 com rebentamento pode fornecer o desempenho necessário durante as cargas de lote noturno ou as exigências limitadas de E/S.

Segurança

Depois de configurar e configurar o seu ambiente Azure, precisa de proteger a sua rede. Aqui estão algumas recomendações:

  • Política do NSG: Pode definir o seu NSG através de uma sub-rede ou de um cartão 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 de força.

  • Caixa de salto: Para um acesso mais seguro, os administradores não devem ligar-se diretamente ao serviço de aplicações ou à base de dados. Utilize uma caixa de salto entre a máquina de administrador e os recursos Azure. Diagrama que mostra a topologia da caixa de salto.

    A máquina de administrador só deve oferecer acesso restrito a IP à caixa de salto. A caixa de salto deve ter acesso à aplicação e à base de dados.

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

Leitura adicional

Passos seguintes