Tendência precisa do desempenho de E / S aleatória para planejamento de capacidade

Onde trabalho, temos vários servidores "big iron", usados ​​para hospedar muitas máquinas virtuais usando um Xen Hypervisor. Geralmente, eles são configurados com 32 GB de RAM, processos de núcleo quádruplo e discos rápidos com capacidade de E / S.

Estamos no momento em que a configuração de hardware existente está ficando um pouco mais demorada e é hora de sair e adquirir um hardware novo maior, mais rápido e mais brilhante.

Como mencionado acima, o kit existente foi implantado com 32 GB de RAM e isso limitou efetivamente o número de VMs que podemos implantar em um host.

Porém, ao investigar o hardware mais novo, é evidente que você pode obter mais e mais RAM em uma única máquina com 64, 72 ou mesmo 96 GB em um único chassi. Evidentemente, isso nos permitirá obter mais máquinas para um determinado host, o que é sempre uma vitória. A análise concluída até o momento sugere que o fator limitante será agora transferido para o subsistema de disco.

O problema agora é tentar ter uma idéia de onde estamos ... Em virtude do uso, sabemos que não estamos limitados em termos de largura de banda de E / S, mais ainda, o número de I aleatórios. Operações operacionais que podem ser concluídas. Sabemos que, uma vez atingido esse ponto, o iowait vai disparar foguetes e todo o desempenho da máquina vai para os cães.

Agora, esse é o cerne da pergunta que estou fazendo. Alguém conhece uma maneira de rastrear / tendências com precisão o desempenho de E / S existente, especificamente com relação ao número de operações de E / S aleatórias concluídas?

Na verdade, estou tentando obter uma métrica "essa configuração pode lidar com êxito com um número X de solicitações aleatórias de E / S, e atualmente estamos (em média) realizando operações Y com um pico de operações Z".

Desde já, obrigado!

sarfaz o trabalho bem aqui; ele coletará o número de transações e os setores lidos / gravados por segundo, que podem ser usados ​​para reproduzir sua carga de trabalho de E / S com precisão relativamente razoável (em termos de taxas de leitura / gravação e tamanho da transação, que é o fator determinante de quão "aleatório" é seu IO). Não é perfeito, mas, na minha experiência, ele faz um trabalho bom o suficiente para fazer o tipo de estimativa que você está olhando.

Portanto, isso parece um problema de monitoramento e relatório de capacidade. Se você vai começar a medir as estatísticas de tendências, eu passo em frente, para que você possa comparar, correlacionar etc.

Em termos de ferramentas, você possui gânglios, zenoss, nagios etc. no mundo de código aberto e vários outros produtos de fornecedores.

Você pode configurá-los para rastrear, medir e armazenar os KPIs de seu interesse e, em seguida, reportá-los periodicamente.

Dadas as suas perguntas sobre o uso da RAM, faria sentido incluir também as estatísticas da memória, o uso de swap e a CPU, para que você possa compará-las em geral pelo mesmo período de tempo e ver quais estão sendo limitadas etc.

Depois de capturar dados, você pode armazenar tudo isso em um grande banco de dados para gerar relatórios, possivelmente rarificando dados históricos, por exemplo. armazene cada métrica de 5 segundos por 6 meses, depois por minuto, depois 5 e depois por hora, à medida que você voltar mais. Esse tipo de coisa pode ser script e executado através de cron, autosys etc.

Esses relatórios fornecerão o que a gerência deseja - ou seja. algo com gráficos bonitos.

E para o gerenciamento diário, você pode ver informações em tempo real em um gráfico / figuras no console para ver como está o desempenho a qualquer momento.

Usamos collectl, pois podemos reunir todas as informações necessárias em um único arquivo e reproduzir as estatísticas necessárias. Isso permitirá que você veja o número de IOPS por intervalo de gravação, alternâncias de contexto, estatísticas de memória. Você pode dividir isso por disco ou apenas dar uma olhada geral no sistema. Collectl também suporta brilho.

Essa é uma ótima ferramenta para obter uma visão geral do desempenho total do sistema. Boa sorte, a partir das observações, os discos SATA normalmente atingem entre 200 e 300 IOPS ao acessar aleatoriamente.

Registramos e representamos graficamente as E / S de disco da mesma maneira que fazemos todas as outras métricas:

• Os dados são extraídos dos hosts usando SNMP. Nossas caixas NAS / SAN fazem isso de forma nativa. Usamos o net-snmp em todos os hosts Linux, que fornece essas informações do USB-DISKIO-MIB .

• Os dados são armazenados (no formato RRD) e representados graficamente usando o Cacti . Alguns modelos de E / S de disco fornecem uma contagem e tamanho de transação, exibidos no formato atual, médio e de pico usual.

Essas métricas não são necessariamente tão finitas quanto usar iostat/ dstat/ sarem um host. Mas é só disparar e esquecer, que é configurado automaticamente quando uma nova máquina é comissionada, armazenada centralmente e permanece disponível para referência futura.

Usamos esses dados para nos alertar sobre tendências incomuns em uma base operacional e sempre olhamos para eles sempre que realizamos o planejamento da capacidade.

O que realmente estou tentando obter é uma métrica "essa configuração pode lidar com êxito com um número X de solicitações aleatórias de E / S [..]".

Existem alguns problemas com isso:

• É muito difícil separar e quantificar a E / S aleatória da E / S sequencial. Como a diferença fundamental entre os dois é a localização física dos blocos armazenados no prato de disco. Você pode adivinhar com base no tamanho das transações, com base no fato de que muitas transações pequenas provavelmente se relacionam a arquivos pequenos espalhados pelo disco. Mas não há garantia. Ele pode estar lendo pequenas quantidades de dados em sequência a partir de um único arquivo ou adjacente blocos no disco.

• O registro das métricas fornecerá uma imagem muito boa de quais são seus compromissos hoje, como eles mudam ao longo do tempo e, portanto, como eles mudarão no futuro. O que não vai lhe dizer é qual é o teto. Pelo menos não antes que seja tarde demais. Para determinar isso, você precisa fazer algumas contas (das especificações de seu hardware), fazer comparações (gosto de bonnie++mim mesmo) e é útil ter uma idéia logística do que esses domUs estão fazendo / sendo usados.

Dependendo do seu back-end de armazenamento (IBM SVC / DS8000), você poderá extrair diretamente estatísticas relacionadas aos IOPS aleatórios.

Para obter estatísticas do servidor, você pode usar nmon . É grátis (como na cerveja). Originalmente desenvolvido pela IBM para AIX, também é executado no Linux.

Se as pessoas usam SAR, pelo menos espero que você esteja coletando amostras de seus dados a cada poucos segundos. Quando uso collectl, colho amostras uma vez / segundo. Para medir o desempenho da E / S aleatória, use uma ferramenta como a dt de Robin Miller (google it) e você pode gerar facilmente MUITAS E / Ss aleatórias e depois medir com collectl para ver quantas você pode fazer por segundo. Um disco típico geralmente faz no máximo 200-300 E / S / s, com base na latência rotacional. O tamanho do bloco teve um efeito mínimo, pois esperar meia volta para que o disco estivesse no local certo supera todo o resto.

btw - iowait é uma das medidas mais incompreendidas. Não tem nada a ver com a carga da CPU, apenas significa que a CPU não estava fazendo mais nada enquanto a E / S estava ocorrendo. De fato, se você estiver 100% iowait, isso significa que você estará 100% ocioso!

-marca