Perfmon: Monitorando o Storage

O principal recurso de um banco de dados é o storage, pois é lá onde os dados ficam armazenados. Antigamente o storage eram discos SCSI conectados ao servidor. Hoje os discos ficam escondidos atrás de várias camadas de virtualização:

  • Discos SCSI/SAS/FC estão associados a um Arrays de Disco
  • Arrays de disco ficam conectados a uma Controladora de Disco
  • Controladora de Disco cria uma redundância dos discos (RAID1/5)
  • Controladora de Disco permite criar Discos Lógicos (LUN) sobre as redundâncias de disco
  • Disco Lógico (LUN) é gerenciado pelo Frontend do Storage
  • Disco Lógico (LUN) possui um Cache de Escrita para agilizar escritas pequenas e aleatórias
  • Frontend do Storage estão conectados com os Switches de Fiber Channel
  • Switches de Fiber Channel estão conectados com os Hosts (Servidor) pela HBA
  • Servidor (Hosts) monta as unidades lógicas (LUN) como discos locais
  • Discos locais são gerenciados pelo Partition Manager e Volume Manager
  • Discos locais recebem a formatação NTFS do Windows
  • SQL Server cria os arquivos MDF e LDF nos discos locais

Portanto, o processo de comunicação com o storage pode enfrentar uma série de problemas ao longo do seu caminho. A forma mais fácil de determinar a causa do problema é monitorando com o Performance Monitor.

São apenas 3 etapas:

  1. Calculamos a carga no storage em relação a IOPS
  2. Calculamos a carga no storage em relação a MB
  3. Calculamos o tempo de resposta do storage

Primeiro verificamos a quantidade de IOPS que o servidor está exercendo contra o storage:

  • Disk Reads/sec
  • Disk Writes/sec
  • Disk Transfers/sec (corresponde a Reads + Writes)

Aqui temos um exemplo de um servidor com uma taxa variando de 1000-2000 IOPS. Como referência, um único disco SCSI pode executar aproximadamente 150 IOPS. Portanto, essa carga equivale de 7 a 13 discos SCSI.

image

Em seguida, medimos a a taxa de transferência. Observamos que a taxa fica em torno de 100MB/s. Como referência, uma HBA de 2Gbit consegue transferir aproximadamente 200MB/s.

image

Por fim, medimos o tempo de resposta do storage e verificamos que os tempos ultrapassam 100ms. Adicionalmente podemos comparar com o “outstanding I/O”, que mostra o enfileiramento na HBA. Como referência, o tempo de serviço de um disco SCSI costuma ser de 5ms e discos SSD possuem latência de apenas 0,1ms.

image

Análise: Observamos que o tempo de resposta não é compatível com o tempo de disco usual (5ms). Recomendamos que o storage tenha uma performance de pelo menos 10 discos SCSI dedicados para a LUN.

Servidor com Carga Pesada

Vamos ao segundo exemplo. Dessa vez, vou colocar tudo no mesmo gráfico para analisar a carga:

  • IOPS: variando de 2000 a 6000 com picos chegando a 10000
  • Banda: média de 200MB/s com picos de 400, 1000 e 1600MB/s

image

Comentários: estamos lidando com alta carga contra o storage.

  • 10000 IOPS é praticamente um storage dedicado para o servidor
  • 1000MB/s é suficiente para causar gargalo em HBA de 8Gbit
  • 1000MB/s normalmente requer um Switch FC dedicado

O tempo de resposta: encontra-se abaixo de 10ms com algumas variações próximas a 20ms. Adicionando o enfileiramento de disco, observamos que a fila aumenta rapidamente.

image

Análise: O tempo de resposta do disco está excelente. A carga é extremamente alta (praticamente um storage dedicado) e com tempo de resposta de 10ms. O enfileiramento não deve ser encarado como problema.

Disco de Log de um Servidor com Baixa Carga

Começamos novamente analisando os contadores relacionados a carga IOPS e Transferência (MB/s). Aqui temos uma carga praticamente nula com menos de 50 IOPS e inferior a 10 MB/s. Como referência, podemos usar um disco SCSI realizando 150 IOPS e uma Fiber Channel transmitindo 200  MB/s.

image

No tempo de resposta, vamos analisar somente a latência de escrita. Para isso, ajustamos o gráfico para 0 a 20 milissegundos. Observamos que a latência varia bruscamente entre 2 a 15ms.

image

Análise: Esse disco de log apresenta uma taxa de escrita muito baixa. Entretanto, ele apresenta indícios de que existem gargalos com o storage devido às variações bruscas nos tempos de latência. Se o desempenho estivesse adequado, a latência seria praticamente constante. Embora não haja impacto no sistema atual, esse problema poderá se manifestar quando houver aumento de carga no sistema.

Como esse problema afeta uma LUN com disco de log (escritas pequenas e sequenciais), a carga deveria ser absorvida pelo cache do frontend do storage. Portanto, as variações bruscas de tempo indicam um gargalo no Volume Manager do Windows, Switch FC ou no Frontend do Storage.

Após investigação, determinamos que havia problema no Frontend do Storage (fan-out ratio), ou seja, a porta do frontend estava sobrecarregada com um número muito alto de hosts. A solução foi rebalancear os hosts entre as demais portas do storage.

 

Conclusão

Performance Monitor é a melhor ferramenta para analisar o tempo de resposta do storage, pois permite determinar a carga do sistema (IOPS e MB/s) e medir o tempo de resposta.