Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Informações

Os links a seguir são referências para a montagem deste documento.

Performance Best Practices for VMware vSphere® 6.0

Performance Best Practices for VMware vSphere 6.7 

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árioNã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
titleFórmula para cálculo do percentual

(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
titleNota

O uso do armazenamento SAN VAAI-capable (descrito em "Considerações no armazenamento de hardware", na página 13) pode  pode acelerar a criação do disco "thick" eager-zeroed ao descarregar operações para zerar o array do armazenamento. Isto pode ser conferido no white paper de Melhores práticas de performance para o VMSphere (link em inglês para a versão 6.0; link em inglês para a versão 6.7), na página 13.

Nota
As vantagens de performance dos discos "thick" eager-zeroed são verdadeiras apenas para discos virtuais indpendentes independentes 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.

Image Modified

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
titleFontesInformações

Em caso de dúvidas, confira Confira a página 33 do documento do white paper de Melhores práticas de performance para o VMSphere (link em inglês para a versão 6.0, e página 32 do documento ; link em inglês 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
titlePossíveis causas

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
titleObservação
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:

  1. Desabilite o TCP chimney, AutoTuning, Congestion Provider, Task Offloading e o ECN Capability:
Bloco de código
languagepowershell
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
languagepowershell
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
languagepowershell
Disable-NetAdapterRsc *

2. Para desabilitar em um adaptador de rede específico:

Bloco de código
languagepowershell
Disable-NetAdapterRsc -Name Ethernetx //(verificar o nome da interface)

3. Para desativar RSC globalmente:

Bloco de código
languagepowershell
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
languagepowershell
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
languagepowershell
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
languagepowershell
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
languagepowershell
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
titleAtenção

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.