Quantas IOPS eu preciso? Meu gargalo de carga de trabalho é o armazenamento

3

Como posso saber quantas IOPS eu preciso do meu armazenamento para entregar para o meu servidor Linux sobrecarregado?

Eu tenho um servidor e sei que ele tem armazenamento como gargalo. Eu gostaria que o gargalo não fosse armazenamento, portanto, preciso dimensionar o desempenho do storage array. Ou seja, compre uma matriz que ofereça mais IOPS do que eu preciso.

Como posso saber, dadas algumas estatísticas de E / S do sistema, ou outras informações, como dimensionar meu desempenho de armazenamento (o que comprar) para atender mais do que preciso (considerando o pior cenário - contenção IO) como referência.

Por exemplo, o utilitário iostat pode fornecer algumas estatísticas interessantes sobre o uso de IO. Posso usar essa informação para saber qual o desempenho de hardware que preciso? Como?

Esta é uma questão geral, o tipo de carga de trabalho real ou software não importa (poderia ser um banco de dados por exemplo), eu só preciso ser capaz de tomar uma decisão baseada em estatísticas e uso de IO atual. em>

    
por Totor 27.02.2014 / 19:16

3 respostas

4

Se você sabe que está vinculado ao armazenamento, os comparativos de mercado em seu servidor não lhe informarão o quanto você precisa. Eles só podem dizer o quão rápido você pode ir enquanto sujeito ao armazenamento limitado. Para obter a resposta que você está procurando, você precisa, se possível, isolar as diferentes maneiras de controlar o armazenamento e testá-las de forma independente.

IOPS é, naturalmente, o limite fácil que todos falam, porque os discos são ruins em busca e os bancos de dados gostam de procurar. Hoje em dia, com cache e SSD, as leituras de busca aleatória de bloco pequeno IO são muito mais fáceis do que costumavam ser. Uma pequena camada de SSD e um grande cache provavelmente garantirão que, se realmente for IOPS (para o tipo de "busca" de bloco pequeno, esse é o seu gargalo, você não estará mais sujeito a isso. Tenha cuidado com esses benchmarks, no entanto, você lerá todos os tipos de números irreais, já que as pessoas medem o número de OIs que podem fazer diretamente para o cache não espelhado. Isso não vai ajudar o seu servidor linux.

Outro tipo de limite de armazenamento é a largura de banda ou a taxa de transferência. Este é difícil de isolar, mas se você sabe quantos dados está tentando ler ou escrever e sabe quanto tempo leva agora, escolha um novo alvo de tempo, e esse será seu novo número. Por exemplo: se você observar seu aplicativo gastando 4 horas para fazer um backup grande ou algo assim, e no final dele, ele é movido 9 TB, que informa seu limite atual de transferência: cerca de 650 MB / s. Se você quiser mover 18 TB nesse tempo, precisará de 1300 MB / s. Na maioria das vezes, ethernet, fibra e SAS podem ser configurados para serem mais rápidos que o hardware de armazenamento. A capacidade do armazenamento de manter essa camada de transferência cheia geralmente é o verdadeiro gargalo. Você deseja examinar o número de portas front-end e os números de referência com o espelhamento de cache ativado (para garantir que não haja afunilamento entre os controladores espelhando as gravações em cache).

Por último, você pode ser limitado pela configuração de armazenamento ruim em termos de filas SCSI. Isso não é ridiculamente comum, mas é definido por não conseguir empurrar seu hardware de armazenamento tão rápido quanto deveria. Se você estiver vendo uma latência de 500 ms em gravações do host, mas seu armazenamento relatar um total de 3ms em cache de 100%, isso pode ser um problema com filas SCSI insuficientes no destino. Basicamente, o iniciador SCSI está aguardando até 500 ms para liberar um slot na fila que pode usar para receber solicitações. Você deseja perguntar ao seu fornecedor de armazenamento as melhores práticas sobre as configurações de profundidade da fila do host e a taxa de difusão para isso.

Espero que isso ajude, sei que não é uma resposta tão simples quanto você esperava.

    
por 28.02.2014 / 05:39
3
O comando

iostat mostrará as informações desejadas. Basta executar:

iostat 1

A saída será algo assim:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              42.00       128.00        84.00        128         84

O tps é transactions per second , que é o mesmo que ops.

Isso fará com que seja atualizado a cada segundo.

Você geralmente precisa ter o pacote systat instalado em sua distribuição Linux para ter o iostat disponível.

    
por 27.02.2014 / 19:28
0

Se você puder variar a carga da aplicação de 1 TPS para bem além do ponto de estrangulamento, você pode construir um modelo da relação entre TPS e taxa de operação de E / S e largura de banda.

Vamos dizer:

  1 TPS causes   6 IOs and   2 KB of transfer, per second
 10 TPS causes  16 IOs and  11 KB
100 TPS causes 106 IOs and 101 KB
  but
200 TPS causes 107 IOs and 102 KB
300 TPS causes 107 IOs and 102 KB

1) Então você tem um gargalo em 100 TPS oferecidos, mais

2) há uma sobrecarga de 5 IOs e 1 KB, após o que cada transação usa 1 IO e 1 KB de transferência

Agora:

  1. é o limite do seu dispositivo existente,
  2. é o seu orçamento, que você usa para calcular quanto deve provisionar para cada TPS que você deseja gerenciar

Se diz que é bom para

10,000 IOPs and 100 KB/S , somente este último é significativo para você. Se diz que é bom para 100 IOPS and 10,000 KB/S , apenas o primeiro é significativo. Às vezes, o gargalo no IPS inicialmente, a largura de banda em grandes configurações

Para medir isso, faça muitos testes individuais, com repetições e tramas os resultados em um gráfico: seus olhos são melhores em fotos do que em tabelas de números.

O gráfico de taxa de transferência deve começar como um declive, algo como / , depois abruptamente nivelar e ir horizontal ou às vezes de volta para baixo novamente. Se você traçar o tempo de resposta, será parecido com _/ As dobras serão alinhadas, em torno da carga de gargalo.

E sim, será um gráfico de dispersão de pontos que se aproxima dessas curvas, e não linhas retas agradáveis (; -))

- dave

    
por 28.02.2014 / 21:13