Conforme estudo realizado com o time de arquitetura da Oracle (responsável pela OCI - Oracle Cloud Infrastructure), foram observados cenários computacionais gerando melhores insights dentro de sua arquitetura computacional.
As recomendações desta página são baseadas nos testes de Benchmark realizados pelo time de Engenharia de Dados nos shapes disponíveis da OCI.
Nos testes, utilizamos Windows e Linux; constatamos que o Linux obteve melhor desempenho (em torno de 18% de melhora) quando comparado ao Windows.
Atenção
Em cenários com o dicionário no banco de dados, utilize os volumes com iSCSI attachment para os shapes de VM da aplicação e a última imagem de Sistema Operacional disponível no OCI, respeitando as versões de sistemas operacionais homologados para o Protheus (Application Server e SmartClient). Para a VNIC, utilize a configuração SR-IOV.
A forma de balanceamento recomendada é o Broker; quaisquer outros métodos de balanceamento (como gateway ou load balancer da própria cloud) não estão homologados para uso.
Itens ou funcionalidades não descritos nesta documentação estão fora do escopo de homologação.
Shape recomendado
Em testes realizados de benchmark e nos clientes betas, os processadores AMD.E6 apresentaram melhora de 45% em desempenho em relação ao Intel.2X.
Fluxo da arquitetura
Utilizamos VM.Standard 2.X com distribuição de carga durante a avaliação, devido a arquitetura de baixo custo, onde ocorreu o maior fluxo de teste.
Ponto de atenção
É importante que os discos estejam em modo High Performance. Quanto maior o tamanho do disco, mais performático será o throughput.
- Máquina Primária: Possui a função de gateway, direcionando as conexões para as máquinas Secundárias. Se conecta nas máquinas Secundária, Secundária VIP, WF/WB/SCH/JOB, e Database.
- Máquina Secundária: De 1 a N, recebe as requisições da máquina Primária para processamento. Não é recomendado instalar outros serviços. Elas podem ser escalonadas horizontalmente, conforme a necessidade.
- Máquina Secundária VIP: Para cenários que necessitam de alta disponibilidade, pode ser definido um shape dos pré-desenhados que não será desligado quando o consumo estiver abaixo de 10%. Neste cenário, é importante a configuração de um broker (balanceamento de carga), exclusivo após a escolha do blueprint.
- Máquina WF/WB/SCH/JOB: Este servidor pode servir para Work Flow, WebService, Scheduler ou Jobs.
- Máquina Database: Recomendamos uma máquina específica dedicada ao banco de dados.
- Máquina TSS (SPED): Recomendamos que uma máquina específica seja dedicada ao TSS.
- Volume para o uso do Protheus: Tanto para os discos do sistema operacional como para o volume do Protheus, recomendamos que o ambiente esteja configurado como High Performance em cenários de produção.
Ponto de atenção
É importante que os discos estejam em modo High Performance. Quanto maior o tamanho do disco, mais performático será o throughput.
Para ambientes com Dicionário no banco recomendamos, além do disco estar em high performance, os seguintes shapes (lembrando que, quanto maior o tamanho do disco, mais performático será o throughput):
- Máquina Primária: VM Standard 2.x, com App Broker, App Broker VIP, App Compilação, App Balance (monitor), License Server, DBAccess SPOFless, DBAccess Secundário; Utilizando o BlockStorage, recomendamos o volume de 512GB no C:/ em cenários Windows e no / em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Máquina(s) Secundária(s): VM Standard 2.x, com AppServer Secundários e DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:/ em cenários Windows e no / em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Máquina VM WebService/Job/Workflow: VM Standard 2.x, com Protheus WEBRest, Protheus WEBService, Protheus Workflow, Protheus JOB, Protheus Schedule, Protheus Mobile, e um DBAccess em modo Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:/ em cenários Windows e no / em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Máquina VM TSS: VM Standard 2.x, com Broker (balance), Appserver Secundários e DBAccess (Single). Utilizando o BlockStorage, recomendamos o volume de 512GB no C:/ em cenários Windows e no / em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
Esquemático de uso do subsistema de IO Block Storage para cada VM Protheus deve seguir o recomendado visando aumento significativo da capacidade de IOPs + throughput. O volume x:\ deve ser armado de forma ao acesso ser tripe em 4 volumes diferentes configurados com o modelo High performance 75 IOPs/GB do mesmo tamanho agregados em formato storage pool no Windows ou Volume Group no Linux.
Resultados esperados:
LVM 4x512GB : read: IOPS=85.4k, BW=667MiB/s (699MB/s) (19.5GiB/30008msec)
Como há um grande consumo do C:\ por parte do SO quando da execução do Protheus, recomendamos utilizar boot volumes de 512GB e configuração de IOPs High Performance.
- Passo a passo de como criar o Storage Pool (Windows)
- Passo a passo de como criar o LVM (Linux)
Redes:
Visando segurança e melhores práticas, recomendamos trabalhar, no mínimo, com VCNs para cada tipo de uso (Produção, Homologação e Desenvolvimento) e cada com duas subnets, sendo a primeira privada contendo as Appls e, a segunda, privada contendo os databases. Os acessos devem ocorrer através de VPN ou canal Fastconnect por BGP. Para fins de administração, recomendamos o acesso externo por meio de uma VM Linux (SSH para Linux e VNC para Windows).
Para minimizar a latência, escolha a região mais próxima à sua localização.
Segurança:
- Use Networking Security Group para permitir somente as portas necessárias;
- Siga o modelo de least privileges para grupos e usuários;
- Habilite mfa para usuários administradores;
- Use criptografia em trânsito e em armazenamento (já disponíveis nos serviços DBaaS OCI).
Utilize esta alternativa com três objetivos:
- Agrupar melhor os recursos no OCI;
- Ter melhor controle de custos;
- Ter melhor organização das permissões de segurança.
Sugestão de compartimentos:
Produção Aplicação Database | Homologação Aplicação Database | Desenvolvimento Aplicação Database |
Recomendação
Os Blueprints devem estar no mesmo Availability Domain (AD).
Clientes que utilizam o dicionário no banco de dados podem se beneficiar deste cenário, especialmente quando há necessidade de alto throughput de disco. Nestes casos, recomenda-se o uso de Storage Pool no Windows ou LVM no Linux para otimizar o desempenho de I/O. Mantemos a orientação quanto ao uso de discos de alta performance.
Na Oracle Cloud Infrastructure (OCI), quanto maior o volume provisionado, melhor será o Disk Throughput. No entanto, recomendamos fortemente que a implantação seja precedida de uma análise técnica criteriosa, preferencialmente com o apoio de uma consultoria especializada.
Blueprints recomendadas, de acordo com cada quantidade de usuários simultâneos
Atenção
Estas estimativas são referentes ao uso do produto (Protheus) padrão. Caso alterações sejam necessárias, o cliente pode fazer o scale-up/down (escalonamento vertical, adicionando recursos de processador e memória) ou o scale in/out (escalonamento horizontal, adicionando máquinas Secundárias).
Para os cenários que necessitam de uma máquina secundária VIP é importante ter um serviço do Broker VIP exclusivo para este cenário, após a escolha do Blueprint, conforme a sua demanda. Importante que este Broker VIP seja instalado na máquina Primária (Gateway).
- Para até 35 usuários (ou até 60% de consumo de CPU): VM Standard 2.2, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 256GB no C:\ e 256GB no X:\ em cenários Windows; ou 256GB no / e 256GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 70 usuários (ou até 60% de consumo de CPU): VM Standard 2.4, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:\ e 512GB no X:\ em cenários Windows; ou 512GB no / e 512GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 180 usuários (ou até 60% de consumo de CPU): VM Standard 2.8, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:\ e 512GB no X:\ em cenários Windows; ou 512GB no / e 512GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 50 usuários (ou até 60% de consumo de CPU): VM Standard.E3.FlexO1, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 256GB no C:\ e 256GB no X:\ em cenários Windows; ou 256GB no / e 256GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 100 usuários (ou até 60% de consumo de CPU): VM Standard.E3.FlexO2, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:\ e 512GB no X:\ em cenários Windows; ou 512GB no / e 512GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 200 usuários (ou até 60% de consumo de CPU): VM Standard.E3.FlexO4, com 2 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:\ e 512GB no X:\ em cenários Windows; ou 512GB no / e 512GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
- Para até 400 usuários (ou até 60% de consumo de CPU): VM Standard.E3.FlexO8, com 4 Appserver Secundários e 1 DBAccess Secundário. Utilizando o BlockStorage, recomendamos o volume de 512GB no C:\ e 512GB no X:\ em cenários Windows; ou 512GB no / e 512GB no /protheus em cenários Linux. Em ambas as situações, utilize o disco em High Performance.
Atenção
Estes ajustes se fazem necessários para arquiteturas que utilizem os processadores Intel.
Ajuste de rede
Para Windows, no processador Intel, é necessário ajustar a interface de rede. De acordo com testes realizados em clientes e no teste de estresse junto com o time da OCI, sem estas configurações, os servidores podem apresentar:
➢ baixa eficiência no tráfego de dados de micro pacotes.
➢ Erro: Warning - TOPCONN - NO CONNECTION -2, referente ao tráfego entre Application Server e DBaccess.
O problema pode ser causado pelo Windows TCP Stack, transferindo o uso da interface de rede para a CPU. Para resolver esse problema, há a necessidade de desativar recursos que não são suportados pelo driver broadcom.
Para essa configuração, realize os ajustes por meio do MSDOS em modo Administrador.
Desative o TCP chimney, AutoTuning, Congestion Provider, Task Offloading e ECN Capability:
netsh int tcp set global chimney=disabled |
Ative a feature RSS no driver:
netsh int tcp set global RSS=enable |
Existem algumas configurações adicionais que também causam problemas de desempenho. Veja quais são e como fazer as mudanças necessárias:
Receive Segment Coalescing (RSC)
O RSC é uma tecnologia de descarregamento sem estado, que ajuda a reduzir a utilização da CPU para processamento de rede no lado do recebimento, descarregando tarefas da CPU para um adaptador de rede compatível com RSC. A saturação da CPU, devido ao processamento relacionado à rede, pode limitar a escalabilidade do servidor. Esse problema, por sua vez, reduz a taxa de transação, a taxa de transferência bruta e a eficiência. É semelhante ao problema de descarregamento de TCP, e é recomendável definir como Disabled.
1 Para desabilitar em todos os adaptadores de rede:
Disable-NetAdapterRsc * |
2 Desativar RSC globalmente:
netsh int tcp set global rsc=disabled |
Ajuste através do PowerShell em modo Administrador.
Set-NetAdapterAdvancedProperty Ethernet -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue "Disabled" -NoRestart |
Ajuste de Memória L2 e L3 cache em Windows (para processadores Intel)
Este ajuste é importante para deixar o processamento mais fluido, evitando a sobrecarga de consumo de recursos. Testes realizados em rotinas que realizam o processamento na camada de aplicação obtiveram ganhos de 10% em desempenho na camada de CPU, pois o sistema operacional está mais fluido.
Para fazer a leitura das especificações do computador, primeiro é necessário instalar o programa CPU-Z.
Aplicando os ajustes
Para habilitar o cache L2:
- Tendo em mãos as especificações de seu computador, entre no regedit (na barra de pesquisa do Windows, digite “regedit”).
- Clique na seta à esquerda das respectivas pastas: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager.
- Clique em Memory Management, e dê dois cliques em SecondLevelDataCache.
- Altere a base para Decimal, e substitua o valor 0 pelo tamanho (size) do L2 Cache (que pode ser verificado no programa CPU-Z, na janela Caches, sendo o terceiro bloco de informação).
Abaixo, uma imagem do programa e a localização das informações:
Para habilitar o cache L3:
- No mesmo local de configuração para o L2, no regedit, clique com o botão direito do mouse em um espaço vazio, selecione Novo > Valor DWORD(32 bits).
- Nomeie este novo valor como ThirdLevelDataCache, sem as aspas.
- Dê um duplo clique sobre este novo valor para editá-lo e selecione a base Decimal.
- Se, como no print, seu L3 Cache estiver com um valor em MBytes, multiplique-o por 1024 antes de alterar o valor.
- Adicione este valor em Dados do valor no regedit, e reinicie o computador. Note que no primeiro restart o computador pode estar um pouco mais lento, já que o Windows precisa incorporar estes novos dados, mas no segundo restart o computador deve estar mais rápido que o habitual.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas