🥇Análise de desempenho de VM no VMware vSphere. Parte 3: Storage

Parte 1. Sobre o CPU
Parte 2. Sobre a Memória

Hoje, vamos analisar as métricas do subsistema de disco no vSphere. O problema com o armazenamento é a razão mais comum para o desempenho lento de máquinas virtuais. Enquanto no caso do CPU e RAM a solução de problemas termina no nível do hipervisor, problemas com o disco podem exigir uma análise da rede de dados e do armazenamento.

Vou abordar o tema a partir do exemplo de acesso de bloco ao armazenamento, embora no acesso de arquivos os contadores sejam aproximadamente os mesmos.

Um pouco de teoria

Quando falamos sobre o desempenho do subsistema de disco de máquinas virtuais, normalmente nos concentramos em três parâmetros inter-relacionados:

número de operações de entrada/saída (Input/Output Operations Per Second, IOPS);
largura de banda (Throughput);
latência das operações de entrada/saída (Latency).

O número de IOPS é geralmente importante para cargas de trabalho aleatórias: acesso a blocos no disco que estão localizados em diferentes lugares. Exemplos de tais cargas de trabalho podem incluir bancos de dados, aplicações de negócios (ERP, CRM), etc.

Largura de banda é relevante para cargas de trabalho sequenciais: acesso a blocos localizados um após o outro. Por exemplo, tal carga pode ser gerada por servidores de arquivos (mas nem sempre) e sistemas de vigilância por vídeo.

A largura de banda está relacionada ao número de operações de entrada/saída da seguinte forma:

Throughput = IOPS * Tamanho do bloco, onde Tamanho do bloco é o tamanho do bloco.

O tamanho do bloco é uma característica bastante importante. As versões modernas do ESXi conseguem processar blocos de até 32.767 KB. Se o bloco for ainda maior, ele é dividido em vários. Nem todos os sistemas de armazenamento conseguem trabalhar de forma eficiente com blocos tão grandes, por isso, nas Configurações Avançadas do ESXi, existe um parâmetro DiskMaxIOSize. Com ele, é possível reduzir o tamanho máximo do bloco processado pelo hipervisor (mais detalhes aqui). Recomendo que, antes de alterar esse parâmetro, você consulte o fabricante do sistema de armazenamento ou, pelo menos, teste as mudanças em um ambiente de laboratório.

Um grande tamanho de bloco pode impactar negativamente o desempenho do sistema de armazenamento. Mesmo que o número de IOPS e a largura de banda sejam relativamente baixos, com um grande tamanho de bloco podem ser observadas altas latências. Portanto, fique atento a esse parâmetro.

Latência – o parâmetro de desempenho mais interessante. A latência das operações de entrada/saída para uma máquina virtual é composta por:

latência dentro do hipervisor (KAVG, Average Kernel MilliSec/Read);
latências que são fornecidas pela rede de transmissão de dados e pelo armazenamento em bloco (DAVG, milissegundos médios do driver/comando).

A latência total, visível no sistema operacional convidado (GAVG, milissegundos médios do convidado/comando), é a soma de KAVG e DAVG.

GAVG e DAVG são medidas, enquanto KAVG é calculado: GAVG–DAVG.

Fonte

Vamos detalhar mais sobre KAVG. Durante o funcionamento normal, KAVG deve buscar ser zero ou, pelo menos, ser muito inferior a DAVG. A única situação que conheço em que KAVG é expectavelmente alto é quando há limitações de IOPS no disco da VM. Nesse caso, ao tentar exceder o limite, KAVG aumentará.

A componente mais significativa de KAVG é QAVG – o tempo na fila para processamento dentro do hipervisor. As outras componentes de KAVG são desprezíveis.

As filas no driver do adaptador de disco e as filas para os LUNs têm um tamanho fixo. Para ambientes de alta carga, pode ser útil aumentar esse tamanho. Aqui descreve como aumentar as filas no driver do adaptador (o que aumentará simultaneamente a fila para os LUNs). Essa configuração funciona quando apenas uma VM está acessando um LUN, o que é raro. Se houver várias VMs no LUN, é necessário também aumentar o parâmetro Disk.SchedNumReqOutstanding (instrução aqui). Ao aumentar a fila, você diminui QAVG e KAVG, respectivamente.

Mas, novamente, familiarize-se com a documentação do fornecedor HBA e teste as alterações em um ambiente de laboratório.

O tamanho da fila para o LUN pode ser influenciado pela ativação do mecanismo SIOC (Storage I/O Control). Ele garante acesso equitativo ao LUN por todos os servidores do cluster, ajustando dinamicamente a fila do LUN nos servidores. Ou seja, se em algum dos hosts estiver uma VM que requer desproporcionalmente mais desempenho (VM vizinha barulhenta), o SIOC reduz o comprimento da fila do LUN nesse host (DQLEN). Para mais detalhes aqui.

Entendido sobre KAVG, agora um pouco sobre DAVG. Aqui é simples: DAVG é a latência imposta pelo ambiente externo (rede de transmissão de dados e armazenamento em bloco). Em qualquer armazenamento em bloco moderno, há contadores de desempenho próprios. Para analisar problemas com DAVG, vale a pena verificá-los. Se tudo estiver normal do lado do ESXi e do armazenamento em bloco, verifique a rede de transmissão de dados.

Para evitar problemas de desempenho, escolha a política de seleção de caminho (PSP) correta para o seu armazenamento. Praticamente todos os sistemas de armazenamento modernos suportam a PSP Round-Robin (com ou sem ALUA, Acesso Lógico Assimétrico a Unidades). Essa política permite usar todos os caminhos disponíveis para o armazenamento. No caso de ALUA, apenas os caminhos para o controlador que possui a LUN são utilizados. Nem todos os sistemas de armazenamento no ESXi têm regras padrão que estabelecem a política Round-Robin. Se não houver regras para o seu armazenamento, use o plugin do fabricante para criar a regra correspondente em todos os hosts do cluster ou crie a regra você mesmo. Detalhes aqui.

Além disso, alguns fabricantes de sistemas de armazenamento recomendam alterar o número de IOPS de 1000 (valor padrão) para 1. Em nossa prática, isso permitiu "extrair" mais desempenho do armazenamento e reduziu significativamente o tempo necessário para failover em caso de falha ou atualização dos controladores. Consulte as recomendações do fornecedor e, se não houver contra-indicações, experimente alterar esse parâmetro. Detalhes aqui.

Principais contadores de desempenho do subsistema de disco da máquina virtual

Os contadores de desempenho do subsistema de disco no vCenter estão agrupados nas seções Datastore, Disco, Disco Virtual:

Na seção Datastore estão as métricas dos repositórios de disco do vSphere (datastores), onde estão os discos das VMs. Aqui você encontrará contadores padrão para:

IOPS (Média de solicitações de leitura/gravação por segundo),
largura de banda (Taxa de leitura/gravação),
latências (Latência de leitura/gravação/mais alta).

A partir dos nomes dos contadores, tudo é basicamente claro. Saliento que aqui a estatística não é de uma VM específica (ou disco da VM), mas geral para todo o datastore. Em minha opinião, é mais conveniente observar essa estatística no ESXTOP, pelo menos porque o período mínimo de medição lá é de 2 segundos.

Na seção Disco estão as métricas dos dispositivos de bloco utilizados pela VM. Aqui existem contadores para IOPS do tipo somatório (número de operações de entrada/saída durante o período de medição) e vários contadores relacionados ao acesso em bloco (Comandos abortados, Reinicializações de barramento). Para mim, essa informação também é mais conveniente de se ver no ESXTOP.

Seção Disco Virtual – é o mais útil em termos de busca de problemas de desempenho do subsistema de disco da VM. Aqui você pode visualizar o desempenho de cada disco virtual. Essas informações são necessárias para entender se há um problema em uma máquina virtual específica. Além dos contadores padrão de operações de entrada/saída, volume de leitura/gravação e latências, esta seção apresenta contadores úteis que mostram o tamanho do bloco: Tamanho da solicitação de leitura/gravação.

Na imagem abaixo, o gráfico de desempenho do disco da VM, onde é possível ver a quantidade de IOPS, latências e tamanho do bloco.

As métricas de desempenho também podem ser visualizadas em todo o datastore, se o SIOC estiver habilitado. Aqui estão apresentadas informações básicas sobre a Latência média e IOPS. Por padrão, essas informações podem ser visualizadas apenas em tempo real.

ESXTOP

No ESXTOP, existem várias telas que apresentam informações sobre o subsistema de disco do host como um todo, máquinas virtuais individuais e seus discos.

Começaremos com informações sobre máquinas virtuais. A tela 'Disk VM' é invocada pela tecla 'v':

NVDISK – é a quantidade de discos da VM. Para visualizar informações sobre cada disco, pressione 'e' e digite o GID da VM de interesse.

Os valores dos outros parâmetros nesta tela são compreensíveis a partir de seus nomes.

Mais uma tela útil para a busca de problemas é a do adaptador de disco. É invocada pela tecla 'd' (na imagem abaixo, os campos A,B,C,D,E,G foram selecionados):

NPTH – o número de caminhos para as unidades visíveis a partir deste adaptador. Para obter informações sobre cada caminho no adaptador, pressione 'e' e digite o nome do adaptador:

AQLEN – o tamanho máximo da fila no adaptador.

Também nesta tela estão os contadores de latência que mencionei anteriormente: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Na tela do dispositivo de disco, que é invocada pela tecla 'u', estão apresentadas informações sobre dispositivos de bloco individuais – unidades (na imagem abaixo, os campos A, B, F, G, I foram selecionados). Aqui você pode ver o estado da fila para as unidades.

DQLEN – o tamanho da fila para o dispositivo de bloco.
ACTV – o número de comandos de entrada/saída no núcleo do ESXi.
QUED – o número de comandos de entrada/saída na fila.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Se %USD estiver alto, vale a pena considerar aumentar a fila. Quanto mais comandos na fila, maior QAVG e, consequentemente, KAVG.

Além disso, na tela do dispositivo de disco, é possível verificar se o VAAI (vStorage API for Array Integration) está ativado no armazenamento. Para isso, você deve selecionar os campos A e O.

O mecanismo VAAI permite transferir parte do trabalho do hipervisor diretamente para o armazenamento, como zeragem, cópia de blocos ou bloqueios.

Conforme pode ser visto na imagem acima, o VAAI está funcionando neste armazenamento: os primitivas Zero e ATS estão sendo ativamente utilizados.