Histórico da Página
Informações |
---|
Os links a seguir são referências para a montagem deste documento. |
Considerações sobre alocação de vCPUs para VMs
Recomendações de melhores práticas
Comece com máquinas pequenas fazendo o crescimento pela horizontal, respeitando o layout por VM, e aumente a quantidade de VMs conforme necessário. Não aloque mais vCPUs do que o necessário para uma VM, pois isso pode limitar desnecessariamente a disponibilidade de recursos para outras VMs e aumentar o tempo de espera da CPU pronta.
Alocação de CPU
Nos gráficos de performance, a contagem de CPU Ready é feita em milissegundos; porém, no caso da necessidade de um troubleshoot ou uma análise mais aprofundada, será necessário converter esta medida para percentual (%). Após os cálculos necessários, o percentual resultante deve estar abaixo de 5%.
Informações | ||
---|---|---|
| ||
(CPU summation value / (<chart default update interval in seconds> * 1000)) * 100 = CPU ready % |
No exemplo acima, a média está sendo calculada na última semana. Para o cálculo do percentual de CPU Ready, a fórmula necessita que os intervalos padrão de atualização do gráfico sejam conhecidos, que são:
- Realtime (Tempo real): 20 seconds
- Past Day (Último dia): 5 minutes (300 seconds)
- Past Week (Última semana): 30 minutes (1800 seconds)
- Past Month (Último mês): 2 hours (7200 seconds)
- Past Year (Último ano): 1 day (86400 seconds)
Aplicando a fórmula no exemplo, temos:
(6156 / (1800s * 1000)) * 100 = 0,34%
Onde:
- 6156 representa o valor médio de CPU ready calculado no tempo informado;
- 1800s representa o tempo do intervalo padrão de atualização do gráfico
Esta fórmula está documentada no artigo Converting between CPU summation and CPU % ready values (2002181).
Cálculo dos recursos disponíveis da CPU do host físico
O número de núcleos físicos (pCPU) disponíveis em um host é calculado como:
(# Soquetes do processador) X (# núcleos / processador) = # processadores físicos (pCPU)
Se os núcleos usarem hyperthreading, o número de núcleos lógicos será calculado como:
(# pCPU) X (2 threads / processador físico) = # Processadores virtuais (vCPU)
Por exemplo, se você tiver 2 processadores com 6 núcleos cada:
(2 soquetes de processador) X (6 núcleos / processador) = 12 processadores físicos (pCPU)
(12 pCPU) X (2 threads / processador físico) = 24 processadores virtuais (vCPU)
Observe que o hyperthreading, na verdade, não duplica a pCPU disponível. O Hyperthreading funciona como um fornecedor na segunda thread de execução para o núcleo do processador. Quando um segmento está ocioso ou em espera, o outro segmento pode executar instruções; isto pode aumentar a eficiência se houver tempo de inatividade da CPU suficiente para agendar duas junções, mas, na prática, os aumentos de desempenho são de no máximo 30%.
Nota |
---|
É importante respeitar o consumo de CPU. Alocar muitas vCPU em cenários de virtualização pode impactar na performance. |
Recomendações de Discos Para o Protheus em VMWARE
Tipos de discos virtuais
Eager zeroed – Um disco "thick" eager-zeroed tem todo o espaço alocado e zerado no momento de criação. Isto aumenta o tempo que se leva para criar o disco, mas resulta na melhor performance, mesmo na primeira gravação para cada bloco.
Informações |
---|
Um disco independente não faz parte de snapshots de máquinas virtuais. Ou seja, o estado do disco será independente do estado da snapshot; ações feitas no snapshot, como criação, consolidação ou reversão não terão efeito no disco. |
Nota | ||
---|---|---|
| ||
O uso do armazenamento SAN VAAI-capable (descrito em "Considerações no armazenamento de hardware", na página 13) pode acelerar a criação do disco "thick" eager-zeroed ao descarregar operações para zerar o array do armazenamento. |
Nota |
---|
As vantagens de performance dos discos "thick" eager-zeroed são verdadeiras apenas para discos virtuais indpendentes e persistentes, ou para discos virtuais dependentes que não possuem snapshots. Discos virtuais independentes e não persistentes, ou discos virtuais dependentes que possuam snapshots, irão performar como discos "thin" provisionados. |
Nota |
---|
A configuração acima é muito importante pois, caso o disco seja configurado como Thick Provisioning Lazy Zeroed ou Thin Provision, o Protheus apresentará lentidão e vários recursos não irão responder como desejado. |
Informações | ||
---|---|---|
| ||
Confira a página 33 do documento para a versão 6.0, e página 32 do documento para a versão 6.7. |
Configuração da placa de rede do VMWARE
Idealmente, para o host físico, haverão, no mínimo, conexões de 10 gigabits (Gb) em ambientes que utilizem FARM de virtualização com outras aplicações. O ideal é que haja um balanceamento.
Informações |
---|
Para a VM (virtual machine) do Protheus, recomendamos o uso da placa de rede VMXNET3. Não recomendamos o uso do E1000, pois ela apresenta um baixo desempenho para transferência de arquivos fragmentados. |
Para o uso da VMXNET3, recomendamos que sejam configurados os seguintes parâmetros no sistema operacional Windows.
Constatamos, em alguns clientes utilizando VMWARE, que houve um baixo desempenho em cenários onde as configurações estão default; realizando diversas análises em outros ambientes utilizando servidores virtuais Windows server 2012 e 2016.
De acordo com o VMWare, sem essas configurações, os servidores podem ter problemas semelhantes a:
➢ Mau desempenho;
➢ Perda de pacotes;
➢ Latência da rede;
➢ Transferência de dados lenta.
Informações | ||
---|---|---|
| ||
Estes problemas podem ser causados pelo Windows TCP Stack, transferindo o uso da interface de rede para a CPU. Para resolvê-los, é necessário desativar vários recursos que não são suportados pelo driver VMXNET3. |
Recomendamos que as configurações sejam efetivadas em todos os Servidores Virtuais, baseando-se em cenários reais e seguindo o documento "Performance Best Practices for VMWARE vSphere" (confira o documento para a versão 6.7 neste link ou para a versão 6.0 neste link).
Considerações de rede do Hardware
Antes de realizar qualquer esforço de otimização de rede, você deve entender os aspectos físicos desta. Os aspectos a seguir são apenas alguns do layout físico que merecem uma consideração mais próxima:
- Considere usar uma placa de rede de classe de servidor para melhor performance.
- Assegure-se que a infraestrutura entre as placas de rede origem e destino não causem gargalos. Por exemplo, se ambas as placas são de 10 Gb/s, assegure-se que todos os cabos e switches são capazes de prover a mesma velocidade, e que os switches não estão configurados em uma velocidade menor.
Para a melhor performance de rede, recomendamos o uso dos adaptadores que suportem as seguintes features:
- Descarga de Checksum
- Descarga de segmentação de TCP (TSO - TCP Segmentation Offload)
- Capacidade de lidar com high-memory DMA (ou seja, endereços DMA de 64 bits)
- Capacidade de lidar com múltiplos elementos scatter-gather por frame Tx;
- Jumbo frames
- Descarga de recepção grande (LRO - Large Receive Offload)
- Receive Side Scaling (RSS)
Quando utilizando um protocolo de encapsulação de virtualização, tal como VXLAN ou GENEVE:
- As placas de rede devem suportar a descarga dos pacotes encapsulados deste protocolo
- As placas de rede devem suportar NetQueue e, juntamente, a filtragem interna (encapsulada) de MAC e ID de rede VXLAN (VNI - VXLAN Network ID).
Dica | ||
---|---|---|
| ||
Faça a leitura da página 16 do Performance Best Practices for VMWARE vSphere para o término deste item ; |
Desative os recursos não suportados pelo driver “VMXNET3” através de linha de comando no Sistema Operacional. Na sequência, é necessário reiniciar o servidor virtual para efetivar as alterações:
- Desabilite o TCP chimney, AutoTuning, Congestion Provider, Task Offloading e o ECN Capability:
Bloco de código | ||
---|---|---|
| ||
netsh int tcp set global chimney=Disabled netsh int tcp set global autotuninglevel=normal netsh int tcp set supplemental custom congestionprovider=none netsh int tcp set global ecncapability=Disabled netsh int ip set global taskoffload=disabled netsh int tcp set global timestamps=Disabled |
2. Ative a feature RSS no driver VMXNET3:
Bloco de código | ||
---|---|---|
| ||
netsh int tcp set global RSS=Enable |
Existem algumas configurações adicionais que também causam problemas de desempenho. Aqui está o que 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:
Bloco de código | ||
---|---|---|
| ||
Disable-NetAdapterRsc * |
2. Para desabilitar em um adaptador de rede específico:
Bloco de código | ||
---|---|---|
| ||
Disable-NetAdapterRsc -Name Ethernetx //(verificar o nome da interface) |
3. Para desativar RSC globalmente:
Bloco de código | ||
---|---|---|
| ||
netsh int tcp set global rsc=disabled |
Para verificar se o RSC está desabilitado na máquina virtual:
No comando a seguir, o IPv4OperationalState e o IPv6OperationalState devem estar definidos como FALSE.
Bloco de código | ||
---|---|---|
| ||
Get-NetAdapterRsc |
No comando a seguir, o estado de coalescência do segmento de recepção deve ser definido como Disabled.
Bloco de código | ||
---|---|---|
| ||
global netsh int tcp show |
Large Send Offload V2 (IPV4) e Large Send Offload V2 (IPV6):
É um recurso em adaptadores Ethernet modernos que permite que a pilha de rede TCP/IP crie uma mensagem TCP grande de até 64 KB antes de enviar para o adaptador Ethernet. Em seguida, o hardware no adaptador Ethernet (mecanismo LSO) - segmenta- o em pacotes de dados menores (conhecidos como “quadros” na terminologia Ethernet) que podem ser enviados pela rede. Isso é de até 1500 bytes para quadros Ethernet padrão e até 9000 bytes para quadros Ethernet jumbo. Em troca, isso libera a CPU do servidor de ter que manipular a segmentação de grandes mensagens TCP em pacotes menores que caberão dentro do tamanho do quadro suportado.
Bloco de código | ||
---|---|---|
| ||
Set-NetAdapterAdvancedProperty Ethernet -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue "Disabled" -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName "Large Send Offload V2 (IPv6)" -DisplayValue "Disabled" -NoRestart |
TCP Segmentation Offload:
O TSO é usado para descarregar o processamento de pacotes da CPU para a NIC.
Disabled é a configuração recomendada.
Bloco de código | ||
---|---|---|
| ||
Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”IPv4 Checksum Offload” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”IPv4 TSO Offload” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName “Large Send Offload V2 (IPv4)” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName “Large Send Offload V2 (IPv6)” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”Offload IP Options” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”Offload tagged traffic” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName” Offload TCP Options” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”Recv Segment Coalescing(IPV4)” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”Recv Segment Coalescing(IPV6)” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”TCP Checksum Offload (IPv4)” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”TCP Checksum Offload (IPv6)” -DisplayValue “Disabled” -NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”UDP Checksum Offload(IPv4)” -DisplayValue “Disabled” –NoRestart Set-NetAdapterAdvancedProperty Ethernet -DisplayName ”UDP Checksum Offload(IPv6)” -DisplayValue “Disabled” -NoRestart |
Opções de energia
É importante configurar as opções de energia da FARM de virtualização.
Power Profile - Para servidores da linha HP.
Nota | ||
---|---|---|
| ||
Caso o servidor da FARM de virtualização seja da linha HP (Hewlett Packard), é necessário alterar o HP Power Profile para Maximum Performance. |
Altere, na BIOS, o seguinte:
Power Regulator Mode: HP Dynamic Power Savings Mode > (Alterar para) Maximum Performance.
Em caso de dúvidas, consulte a documentação da HP sobre o Power Profile neste link. Você também pode consultar o artigo de Helge Klein sobre os efeitos do Power Profile na performance de vCPUs.
Informações |
---|
A VMWare também possui um artigo sobre problemas de performance com a opção Power Savings habilitada. |
Outros Servidores
Conforme a nota da VMWare, pode ser necessário em outros servidores habilitar o modo high performance, de acordo com o link da categoria Troubleshooting.