Fundamentos de Storage: Parte 1

 

A idéia dessa série de posts é cobrir esses conceitos e entender de forma simples o que cada um deles significam e tentar pautar do ponto de vista do SQL Server a melhor forma de analisarmos esses conceitos.

Quando mencionamos características fundamentais de Storage na verdade estamos pensando em certos conceitos extremamente importantes e que devem sempre ser bem entendidos.

Pensando no SQL Server, sabemos que o sistema de banco de dados normalmente faz interface com muitos recursos de hardware do servidor, e com base nisso muitas vezes percebemos que o SQL Server consome muito CPU, quando está recompilando ou um índice é mal utilizado... ou muita memória dependendo da complexidade das queries que são executadas. Dependendo da quantidade de batches ou mesmo da característica da aplicação podemos consumir muita banda de rede, só para citar alguns possíveis casos de “gargalos” de hardware em nossos bancos de dados, porém quando pensamos em problemas de performance no SQL Server do ponto de vista de recursos físicos, normalmente disco é o primeiro ou o maior gargalo…

Vamos então entender um pouco mais das operações básicas de um sistema de armazenamento ou simplesmente da Storage, de forma a facilitar um pouco nosso entendimento sobre como a Storage funciona.

IOPS: (I/O por Segundo) representa o número de operações de I / O , individuais que ocorrem em um segundo. O número de IOPS pode ser muito útil, mas só quando você sabe um pouco sobre a natureza do I / O, tais como o seu tamanho e tipo (que pode ser randômico ou seqüencial) . O número de IOPS está relacionado pela velocidade do disco e se pensarmos numa infra estrutura de Storage como um todo, na quantidade do conjunto de discos e dos níveis de RAID que estão configurados.

Latência: A latência é uma medição do tempo total em que uma operação de IO leva para ser respondida pôr um subsistema de disco, ou seja, o tempo entre a aplicação solicitar a leitura ou escrita de um dado que está em disco, o dado ser encontrado no disco, trafegar pelo meio físico e ter a reposta, Valores de latência de disco são geralmente medido em milissegundos; Em caso de discos flash (famosos SSD) a unidade de medição mais comum de medição seria microssegundos

Banda: Também conhecida como Throughput é efetivamente a quantidade de dados que você pode enviar ou receber através de seu sistema. Trabalhando com os conceitos acima é a quantidade de dados que uma única operação de IO carrega.

Fila: Essas operações de IO trafegam através de um meio físico entre a placa mãe do servidor até o disco, se pensarmos em uma infra estrutura SAN, por exemplo após essa requisição ser “emitida” ela trafega através da HBA, via fibra ou rede até chegar a Storage, porém existe uma quantidade máxima de operações de IO que podem ser liberadas no meio físico... em ambientes com grandes quantidade de IOPS, pode acontecer um enfileiramento dessas operações e aqui entra o conceito de fila, uma vez que essas operações esperam em uma fila para trafegar no meio físico.

A imagem abaixo tenta demonstrar exatamente essas operações:

 

Depois de discutirmos esse conceito percebemos que claramente esses conceitos estão estritamente ligados entre si quando tentamos entender um subsistema de disco, agora imaginando nosso sistema de banco de dados, e os medidores que o Windows utiliza posso mencionar alguns contadores do Perfmon que nos indicam exatamente cada um desses conceitos:

Esses contadores são os que normalmente analisamos quando em campo queremos estimar qual a performance dos discos de SQL. Você pode ser perguntar porque não usamos o Physical Disk do Perfmon, e normalmente escolhemos o Logical Disk porque dependendo da infra-estrutura de Storage pode ser um conjunto de discos ou LUNS.

A imagem abaixo (apenas para referência) mostra a tela do Perfmon onde selecionamos esses contadores, percebam que logo abaixo temos uma breve descrição do que cada contador faz… isso pode ser útil em caso de dúvidas.

Além disso você vai perceber que separei propositalmente operações de leitura e escrita nos gráficos… Isso foi feito porque é importante entender que devido a RAID levels e a características dos discos essas operações podem ter grande diferença de performance e por isso é MUITO importante entende-las de forma separada.

Vendo isso na prática, na imagem abaixo percebemos a variação de operações de IO no servidor, abaixo percebemos uma carga homogênea, bem característica de sistemas OLTP, com operações de leitura e escrita, as imagens mostram picos pouco superiores a 300 operações de leitura, na média ficando sempre abaixo de 50, percebemos que o mesmo é válido para operações de escrita.

Vejamos agora como se comportam esses IOPS, ou seja quanto de latência essas operações levaram.. devida a quantidade baixa de operações de IO, podemos claramente perceber que essas operações não são significativamente lentas, atendendo em média as requisições em menos de 5 milissegundos. Vale mencionar que nossa recomendação como referência, é um tempo de resposta abaixo de 20ms, e uma tempo bom abaixo de 08ms, mas é importante mencionar que isso são valores de referência e cada workload precisa ser entendido de forma particular.

 

Após essas duas analises vamos verificar o quanto de dados trafegou no meio físico analisando o throughput dos discos, sendo que nos gráficos podemos perceber que a  média das operações de IO com tempo médio de  resposta médio  de 5 milissegundos trafegaram aproximadamente 64Kb.

 

Conclusão.

O subsistema de disco é realmente muito importante para o ambiente de banco de dados, entender como ele funciona é extremamente importante para que possamos extrair a melhor performance do nosso SQL Server...

Esse post é a primeira parte desse universo que é o subsistema de disco, nos posteriores considero falar mais sobre os RAID Levels e suas implicações para o SQL Server, os tipos de disco como SSD versus HDD, Explicar mais o funcionamento de discos HDD e prosseguir em mais ferramentas de avaliação de performance e de troubleshooting falando inclusive sobre algumas DMVS e WAITS que podem nos ajudar quando enfrentarmos problemas de disco.

Grande Abraço.

Comments

• Anonymous
  September 19, 2014
  The comment has been removed

• Anonymous
  September 20, 2014
  Cada post é um flash... Muito bom Freddie... Super interessante estes assuntos mais Deep relacionados ao SQL Server... Keep Calm And "Never Stop Writing" =)

• Anonymous
  September 20, 2014
  Muito bom, parabéns.

• Anonymous
  September 22, 2014
  Muito bom artigo Freddie. Só fiquei em dúvida no ponto abaixo, na verdade não sei se entendi o argumento que você usou: "...normalmente escolhemos o Logical Disk porque dependendo da infra-estrutura de Storage pode ser um conjunto de discos ou LUNS." Entendo a parte de o disco físico poder ser (e na maioria dos casos é) um conjunto de discos, mas o que você quis "defender" ao citar que se deve analisar o disco lógico? Não sei se entendi direito o seu argumento. Abraço, Vladimir

• Anonymous
  September 22, 2014
  Vladimir, obrigado pelo comentário... A idéia na verdade é que quando falamos de analise de disco em ambientes que onde o SQL Server está, temos que seguir como Windows "vê" a infra-estrutura de discos e isso ocorre de duas formas fundamentais: Mount Points ou Unidades Lógicas (C:, D:...). Quando monitoramos o LOGICAL DISK queremos na verdade saber como esses "discos" se comportam, porque efetivamente é como podemos ter uma indicativo de problema de performance... Por exemplo quais discos de TEMPDB, ou os discos de LOG. Dada as tecnologias de Storage atuais, como virtualização, cache entre outros, trabalhar com o conceito de Physical disk acaba sendo mais complexo e pouco efetivo. Claro que estou pensando em uma infra baseada em SAN, mas também pode ser estendida em caso de DAS ou discos locais... Não sei se era essa sua dúvida... Grande Abraço.

• Anonymous
  September 22, 2014
  Olá Freddie. Não, era isso mesmo, não tinha ficado claro para mim se era essa questão de "isolar" a análise que tinha motivado o uso do disco lógico ou se havia algum outro motivo. Abraço Vladimir

• Anonymous
  October 02, 2014
  Valeu pela dica, muito bom!!!

• Anonymous
  October 06, 2014
  Excelente, Parabéns !!!

• Anonymous
  May 28, 2015
  Fred, Excelente post. Muito bem explicado e evidenciado com os gráficos que disponibilizou. Grande abraço.