Isso\u00a0levou a desconfiar de um vil\u00e3o muitas vezes esquecido o IOPS. O c\u00e1lculo de IOPS leva a conta de quantas opera\u00e7\u00f5es de entrada e sa\u00eddas (I\/O) s\u00e3o feitas por segundo. Muitas vezes ele passa despercebido e nem \u00e9 computado, nos preocupamos somente com quantidade (MB) e velocidade (MB\/s). Infelizmente no ambiente em quest\u00e3o n\u00e3o tinha uma forma direta de calcular os IOPS, nenhum gr\u00e1fico do VMware entrega esta informa\u00e7\u00e3o. Felizmente algumas pesquisas no Google\u00a0levaram a uma forma de gerar a contagem de IOPS atrav\u00e9s do VMware.<\/p>\n
Para isso precisamos criar um gr\u00e1fico novo atrav\u00e9s da op\u00e7\u00e3o \u201cChard Options…<\/em>\u201d da aba \u201cPerformance<\/em>\u201d do VMware. Ao clicarmos somos direcionados a uma tela com diversas op\u00e7\u00f5es que podem ser medidas, ali encontramos no menu \u201cChard Options<\/em>\u201d a informa\u00e7\u00e3o \u201cDisk<\/em>\u201d e depois \u201cReal-Time<\/em>\u201d. A imagem abaixo reflete isso:<\/p>\n Aqui temos \u201cReal-Time<\/em>\u201d selecionado e em \u201cObjects<\/em>\u201d podemos escolher as luns ou discos para an\u00e1lise (caso esteja na aba de Performace de uma m\u00e1quina virtual aparecer\u00e3o somente as lus que esta acessa, para o host aparecem todas). Para gerar o gr\u00e1fico de IOPS temos que selecionar as op\u00e7\u00f5es corretas em \u201cCounters<\/em>\u201d, ali devemos deixar marcados 3 op\u00e7\u00f5es: Write requests<\/strong>, Read requests<\/strong> e Commands issued<\/strong>. Todas as outras op\u00e7\u00f5es devem ficar desmarcadas. Se optarmos por salvarmos (o que eu recomendo) basta clicar em \u201cSave Chart Settings<\/em>\u201d e escolhemos o nome.<\/p>\n Assim teremos um gr\u00e1fico de IOPS com a quantidade de escrita e leitura que foram enviadas pelo VMware, tamb\u00e9m teremos a quantidade total (Commands Issued<\/em>, somat\u00f3rio de escrita e leitura) dada pelo pr\u00f3prio VMware. Podemos fazer isso para cada m\u00e1quina virtual, e recomendo caso voc\u00ea tenha suspeita em uma espec\u00edfica.<\/p>\n Com este gr\u00e1fico em m\u00e3o podemos voltar ao problema e identificar o que estava acontecendo.\u00a0Existia um\u00a0relatado\u00a0de\u00a0evento aleat\u00f3rio, n\u00e3o tinha hor\u00e1rio definido e a dura\u00e7\u00e3o variava tamb\u00e9m. Como citado acima, os gr\u00e1ficos de CPU e disco n\u00e3o revelavam muito, s\u00f3 a lat\u00eancia indicava o problema. Colocando o gr\u00e1fico de IOPS tudo come\u00e7ou a se encaixar.<\/p>\n Antes temos que interpretar o gr\u00e1fico, na figura abaixo podemos identificar alguns pontos importantes, ela nos mostra que para este servidor as 10:39:20 ele estava fazendo pr\u00f3ximo de 100MB\/s. Duas informa\u00e7\u00f5es importantes aqui, a primeira \u00e9 em rala\u00e7\u00e3o a unidade de medida, ela est\u00e1 em KBps e isso quer dizer KB\/s, n\u00e3o devemos confundir com Kbps (isso est\u00e1 definido no manual do VMware). A segunda informa\u00e7\u00e3o \u00e9 com o per\u00edodo do gr\u00e1fico, ele \u00e9 gerado a cada 20 segundos<\/em>.<\/p>\n Na imagem abaixo podemos observar que o mesmo hor\u00e1rio gerou um total de 6806 requisi\u00e7\u00f5es (marcado em vermelho). Aqui o detalhe, como ele \u00e9 uma sumariza\u00e7\u00e3o isso que dizer que em 20 segundos ele gerou essa quantidade e dividindo 6860 por 20 chegamos a 343 IOPS (agora sim, por segundo). \u00c9 imprescind\u00edvel que voc\u00ea saiba as luns ou os discos que voc\u00ea quer analisar, os gr\u00e1ficos para o host f\u00edsico s\u00e3o mais confusos por apresentarem todas as luns. Al\u00e9m disso, sempre verifique como o gr\u00e1fico apresenta os resultados, se forem sumarizados divida pelo tempo de exposi\u00e7\u00e3o (20 segundos). O pico de quase 30000 requisi\u00e7\u00f5es que aparece na mesma imagem explicarei mais abaixo.<\/p>\n Conseguindo interpretar o gr\u00e1fico podemos investigar mais a raiz do problema. Na imagem abaixo observe o pico de 521ms de lat\u00eancia no acesso a disco (observe que isso \u00e9 m\u00e9dis em 20 segundos) proveniente do host (chamado de Host A<\/strong>).<\/p>\n Indo atr\u00e1s do vil\u00e3o, no mesmo momento em outro host (o Host B<\/strong>) existia uma m\u00e1quina virtual (chamada de M\u00e1quina X<\/strong>) que estava gerando uma grande quantidade de requisi\u00e7\u00f5es. Na imagem abaixo temos picos de requisi\u00e7\u00f5es, chegando a um valor superior a 11000 (9000 de escrita e 2000 de leitura) sumarizados a cada 20 segundos (11000\/20=550 IOPS). Infelizmente na imagem a hora dos dois hosts estava fora de sincronia, mas elas foram retiradas no mesmo momento. No ponto selecionado ela estava fazendo aproximadamente uma m\u00e9dia 9000 I\/O e isso nos d\u00e1 450 IOPS.<\/p>\n Sobrepondo as duas imagens observa-se que elas ocorrem no mesmo momento, quando a M\u00e1quina X fez o pico de I\/O selecionado na imagem o Host A detectou a lat\u00eancia. Isso nos mostra que os eventos estavam relacionados. Um detalhe interessante, observe que mesmo a M\u00e1quina\u00a0X tendo gerado v\u00e1rios picos de IOPS somente um deles causou lat\u00eancia, isso ocorre porque nos outros picos n\u00e3o havia concorr\u00eancia entre os hosts. Nenhuma outra m\u00e1quina virtual do Host A tentou fazer escritas ou leituras pesadas no disco, s\u00f3 quando alguma m\u00e1quina virtual do Host A precisou acessar o disco ela concorreu com a M\u00e1quina X.<\/p>\n Infelizmente essa n\u00e3o era a origem do problema, existiam outros hosts e maquinas virtuais fazendo o dobro de requisi\u00e7\u00f5es sem qualquer concorr\u00eancia ou lat\u00eancia. Observe na imagem abaixo que para o mesmo momento que a M\u00e1quina\u00a0X fez 550 IOPS ele estava consumindo somente 5MB\/s. Esta imagem foi retirada alguns minutos antes das anteriores, mas observe no gr\u00e1fico o momento pr\u00f3ximo as 11:05 que est\u00e1 marcado em vermelho.<\/p>\n Abaixo outras imagens do mesmo problema que ocorreram em outros momentos (observe o nome dos hosts). Nas duas primeiras o mesmo host estava consumindo em torno de 140MB\/s e aproximadamente 7600 IOPS (7600\/20=380). Enquanto isso, na terceira imagem pode ser observado que outro host detectou lentid\u00e3o de acesso.<\/p>\n O que intrigou um pouco foi que tanto o Host A e a M\u00e1quina\u00a0X do Host B n\u00e3o compartilhavam o datastore do VMware. As luns apresentadas do storage ao VMware eram diferentes, assim os datastores n\u00e3o eram compartilhados entre os servidores em quest\u00e3o. Analisando um pouco mais, percebemos que o compartilhamento estava em n\u00edvel de Raid Group do Storage.<\/p>\n Quando trabalhamos com Storage algumas escolhas podem levar a problemas que n\u00e3o foram imaginados na concep\u00e7\u00e3o do ambiente. Neste caso em espec\u00edfico, ambos os Host A e a M\u00e1quina\u00a0X estavam apoiados sobre um Raid Group 5 formados por 6 discos SATA de 2TB de 7,200rpm. E esse era o problema, nada de VMware ou storage e sim discos. A op\u00e7\u00e3o de utilizar discos SATA de 7,200 rpm era o problema. Aqui est\u00e1 a pe\u00e7a que faltava e juntava o quebra-cabe\u00e7a.<\/p>\n Discos SATA de 7,200 rpm nos d\u00e3o no m\u00e1ximo 80 IOPS, existem diversos links na Internet comentando sobre isso, com f\u00f3rmulas para calcular o IOPS de cada disco. Das diversas existentes eu recomendo a leitura da s\u00e9rie de artigos do Joshua Townsend sobre IOPS e Storage, aqui<\/a>, aqui<\/a> e aqui<\/a><\/p>\n Como um disco SATA entrega aproximadamente 80 IOPS, um Raid Group com 6 discos disponibilizar\u00e1 aproximadamente 500 IOPS. Aqui n\u00e3o estamos considerando algumas informa\u00e7\u00f5es relativas ao RAID, como penalidade de escrita e caches de leitura do storage, s\u00f3 uma conta b\u00e1sica para facilitar e n\u00e3o prolongar ainda mais o texto.<\/p>\n Voltando ao problema, agora temos a sua origem detectada. A M\u00e1quina X estava consumindo todo o IOPS do Raid Group. Se voc\u00ea observar ir\u00e1 perceber que a M\u00e1quina\u00a0X fez mais IOPS que o Raid Group consegue entregar, temos que levar em considera\u00e7\u00e3o que IOPS de leitura geralmente s\u00e3o otimizados pelos cach\u00eas que temos nesta pilha (Storage\/Controladora\/VMware).<\/p>\n Assim, quando qualquer outra m\u00e1quina virtual fosse tentar qualquer I\/O sobre alguma lun deste Raid Group iria ter lat\u00eancia no acesso. Mesmo as m\u00e1quinas virtuais n\u00e3o compartilhando o datastore elas concorrem pelo mesmo disco, suas luns podem apontar\u00a0para o mesmo Raid Group no Storage. E isso n\u00e3o \u00e9 um problema do Storage, aqui foi um escolha no momento de adquirir os discos SATA de baixa performance. Provavelmente a equipe no momento de adquirir o Storage n\u00e3o levou em considera\u00e7\u00e3o IOPS, somente se preocupou com MB\/s e espa\u00e7o dispon\u00edvel.<\/p>\n As 30000 requisi\u00e7\u00f5es em 20 segundos de algumas imagens acima (30000\/20=1500 IOPS), elas foram alcan\u00e7adas pois a sua lun estava apoiada sobre um Raid Group de discos SAS de alta capacidade (aproximadamente 200 IOPS cada disco). Repare na mesma imagem que o consumo (MB\/s) \u00e9 praticamente o mesmo nos dois momentos. Discos diferentes, desempenhos diferentes.<\/p>\n![\"Criando](\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2013\/06\/VMware-IOPS-07.png\")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n