PowerStore: Técnicas eficazes para avaliar o desempenho do storage array

Nota: As análises comparativas só são válidas se tudo estiver configurado de acordo com as práticas recomendadas do PowerStore e se não houver problemas de conectividade ou configuração. Caso contrário, o teste provavelmente produz dados irrelevantes.

• Teste usando variáveis semelhantes ao que será a carga de trabalho/ambiente real. Lembre-se de que a maioria das ferramentas são simuladores e nunca atingem 100% de uma verdadeira carga de trabalho de produção simulada.
• Se a carga de trabalho variar amplamente, considere fazer várias iterações de testes de leitura/gravação com diferentes tamanhos de bloco e padrões de acesso.
• Use operações ou testes com multithread e assíncronos para garantir recursos de desempenho paralelos ou simultâneos e garantir que o potencial geral agregado de throughput esteja sendo exercido. 
• Considere e analise as referências de desempenho padrão do setor para o equipamento que está sendo avaliado em relação à carga de trabalho de produção de sua empresa.
• Evite fazer testes em sistemas de arquivos e/ou volumes vazios ou com pouca utilização de espaço. Se você não pré-alocar espaço nas cargas de trabalho de gravação, poderá ver latência devido à alocação instantânea de espaço durante o teste.
• Não se esqueça de testar a E/S de leitura, pois ela geralmente é a dominante das duas na maioria dos ambientes. Esteja atento à perda de pacotes/quadros na infraestrutura de rede durante o teste.
• Verifique se você está testando em vários dispositivos para simular um ambiente típico com muitos hosts ou clients. Por exemplo, no PowerStore, um bom número é 16 volumes. A contagem de volumes normalmente corresponde aos números de hosts ou clients usados (físicos ou virtuais); É aqui que a simultaneidade é alcançada.

 

Ferramentas e simuladores
de benchmarkingTenha em mente que a maioria das ferramentas são simuladores e provavelmente nunca conseguem simular 100% de uma carga de trabalho de produção verdadeira. Essas ferramentas de benchmarking são usadas para ter uma ideia de como o desempenho poderia, deveria ou seria em determinadas situações. A Dell não possui essas ferramentas e não é responsável por quaisquer problemas ou prejuízos que possam estar associados a elas.

Em qualquer situação de teste de desempenho, certifique-se de que as ferramentas com recursos assíncronos e multithread sejam usadas. Exemplos dessas ferramentas são:

• Testador de E/S flexível (FIO)
• Medidor de I/O
• Vdbench (requer uma conta Oracle)
• Medidor NFSometer (Somente Fedora/NFS)
• Checklist de desempenho do NAS da Intel

 

Evite os seguintes tipos de testes:

• Copiar e colar
• Arrastar e soltar
• Backup de file system único em disco
• Testes DD
• Rlarge
• Wlarge
• Mkfile
• Descompactando, extraindo e compactando

Há certas coisas a ter em conta na maioria dos cenários de marcação. Esta seção não substitui a compreensão do tamanho e das características da carga de trabalho. No entanto, se você não tiver dados anteriores e precisar de uma estimativa aproximada do comportamento de seu aplicativo para avaliar os recursos do PowerStore (e não o desempenho específico da carga de trabalho), considere os seguintes fatores:

 

 

IODepth (tamanho da fila)
Uma profundidade de E/S baixa (ou não alta o suficiente) pode limitar sua taxa de transferência potencial, dependendo da situação. Portanto, sempre verifique se a profundidade de E/S é alta o suficiente para refletir ou emular os requisitos de simultaneidade de uma carga de trabalho. Uma profundidade de E/S muito baixa pode não usar corretamente o dispositivo em todo o seu potencial. Além disso, desconfie de uma profundidade de E/S muito alta, pois isso pode causar algumas filas significativas no dispositivo e, dependendo do tempo de serviço do dispositivo, pode haver tempos de resposta maiores como resultado. Isso pode refletir a aparência de um sistema sobrecarregado.

Para este teste, os números são significativamente menores quando há uma profundidade de E/S de um em comparação com uma profundidade de E/S de algo mais real, como 64. Tenha em mente que isso é com um all-flash-array e, portanto, esse conceito é visto em sua forma extrema, mas cada vez mais comum."

IOdepth=1" é de cerca de ~30.000 operações de entrada e saída por segundo (IOPS) em média para o teste.

 

"IOdepth=64" é de cerca de ~107.000 IOPS médio para o teste.

 

 

"IOdepth=256" tem em torno de ~142.000 IOPS médios para o teste.

 

 

Como mencionado, o desempenho nivela a uma certa profundidade de E/S na maioria das configurações. Aqui, há um tamanho de fila de 512 e há apenas um pequeno aumento no IOPS de um tamanho de E/S de 64."

IOdepth=512" é cerca de ~146.000 IOPS médio para o teste.

 

 


Assíncrono vs Sincronização
Existem dois motores principais distintos que são usados. A mais popular e, de longe, a mais eficiente em termos de desempenho é a "E/S assíncrona". O tipo de mecanismo menos eficiente e menos eficiente é a E/S síncrona e normalmente é usado com aplicativos que têm requisitos rígidos de integridade e garantia de dados. A E/S síncrona também pode ser encontrada em tecnologias de replicação RPO (Recovery Point Objective, objetivo de ponto de recuperação) quase nulo. Em testes e análises comparativas de desempenho, do ponto de vista do host, assíncrono significa que uma confirmação não é necessária para uma única E/S a fim de solicitar a próxima E/S. Em cargas de trabalho síncronas, uma confirmação é necessária para uma E/S antes que a próxima seja emitida e uma confirmação (ACK) para cada E/S subsequente solicitada. Portanto, a E/S síncrona geralmente tem uma fila de 1 ou menos e nunca usa totalmente o recurso em todo o seu potencial. O acoplamento de operações síncronas com uma contagem de threads baixa ou única pode limitar severamente o potencial de desempenho, portanto, sempre verifique se você está fazendo testes assíncronos e, se estiver usando testes síncronos, certifique-se de empregar vários threads, a menos que o ambiente do aplicativo aponte explicitamente para não fazê-lo.

Async (Libaio - Linux nativo async) = 1 thread



Sync (E/S síncrona):  

 

 

Contagem
de threadsOs tópicos são importantes. Os testes sempre devem ser feitos usando vários threads, especialmente em testes/cargas de trabalho síncronos. Isso é para tentar simular várias iterações de um trabalho/teste com base no comportamento do processo de um aplicativo corporativo. Vários threads associados à atividade simultânea são onde o throughput agregado de um sistema é alcançado. A maioria dos mecanismos assíncronos emprega vários threads, portanto, você não precisa se preocupar tanto com a contagem de threads. Sem ter threads suficientes durante cargas de trabalho síncronas, você pode limitar severamente o throughput potencial total de um teste de carga em relação a um sistema."

"Multithreaded" significa vários threads fazendo trabalho em paralelo. Por exemplo, se você tiver um único dispositivo que pode atender a 1.000 IOPS em uma carga de trabalho síncrona, o dispositivo terá um tempo de resposta de 1 ms sem uma fila (portanto, sem fila, tempo de serviço e tempo de resposta devem ser sinônimos). Obviamente, dispositivos com tempos de resposta de 1 ms podem fazer muito mais trabalho do que 1.000 IOPS, e isso é obtido empilhando vários threads ou fluxos paralelos da mesma carga de trabalho. Então, se você aumentar os threads (ou "coisas que fazem esse trabalho específico") para 10, agora você tem 10 threads individuais fazendo E/S para um dispositivo a 1 ms. Cada thread de carga de trabalho individual ainda está recebendo 1 ms, o que significa que cada thread ainda está atingindo apenas 1.000 IOPS, mas agora todo o "processo" ou "trabalho" que está sendo executado por esses vários threads está recebendo 10.000 IOPS.

Existem ferramentas e cargas de trabalho que podem atingir adequadamente os limites de um dispositivo com um único thread, e algumas precisam de mais. Em resumo, ao simular uma carga síncrona, você deseja ter o máximo possível de threads/trabalhadores/fluxos sem afetar o tempo de resposta geral. Há um ponto em que o aumento da contagem de threads deixa de ter um efeito positivo (quando o dispositivo fica 100% ocupado). Geralmente, com cargas de trabalho assíncronas, a contagem de threads é cuidada por padrão. Por exemplo, abaixo você ainda pode ver uma diferença entre 1 thread e 10 para uma carga de trabalho assíncrona, embora não significativa. A moral da história é que, com cargas de trabalho assíncronas, você não deve se preocupar tanto com threads. 

Um único thread aqui pode alcançar 68.000 IOPS usando o mecanismo "libaio" (assíncrono). 

 

Se você aumentar os threads (numjobs) para 10, ainda poderá ver um aumento no IOPS.

 

Quando se trata de cargas de trabalho síncronas, embora este seja um caso extremo, você pode ter dois fatores principais que tornam este um teste de mau desempenho, sendo a natureza síncrona. 

enviar I/O-1, aguardar ACK, enviar I/O-2, aguardar ACK etc.

 E não ser capaz de empilhar vários threads para a mesma finalidade. 

job1=enviar E/S-1 - job2=enviar E/S-1 - job3=enviar E/S-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 etc.

Sinalizador direto

Com algumas ferramentas, especialmente ferramentas/SO baseados em *nix, você pode ver uma opção de "Direct I/O". Isso pode ser usado com mecanismos "assíncronos" e não deve ser confundido com E/S "síncrona". Em algumas ferramentas sem esse indicador especificado, você pode estar gravando no cache do servidor e não diretamente no disco. O que o host deseja fazer é ignorar seu próprio cache e gravar diretamente no disco. Esse é um fator essencial ao testar o armazenamento. Quando você tem o indicador "direct" definido, você está tecnicamente gravando no disco, embora "disk", neste caso, seja realmente cache de armazenamento. Isso ainda é aceitável para fins de teste, pois, mesmo com a carga de trabalho correta, você ainda está simulando e imitando com precisão como essa carga de trabalho se comporta em um ambiente real, já que a carga de produção também atingirá o cache antes de enviar de volta a confirmação. (Não se sinta enganado apenas porque você está recebendo números de desempenho de cache envolvidos e não apenas os spindles de back-end.)

 

Largura de banda (MB/s) vs. throughput (IOPS)

Há duas perspectivas principais que você pode testar. O throughput no mundo do sistema de rede e do desempenho geralmente se refere à transferência de dados; no entanto, no ambiente SAN/bloco, é comum usar "throughput" para representar o IOPS. Portanto, você deve primeiro entender as características da carga de trabalho para as quais você está testando.

Largura de banda (MB/s) — largura de banda é a medida de dados que você pode ajustar de uma só vez (ou dentro do intervalo X, geralmente "por segundo") em um tubo ou sistema. Isso significa que ele está medindo a quantidade de dados que você transferiu durante um período de tempo. Embora a largura de banda e o IOPS não sejam mutuamente exclusivos, você pode ter números maiores ou menores de largura de banda com a mesma quantidade de IOPS, tudo depende do tamanho do bloco. Lembre-se de que você não está medindo a velocidade com largura de banda, a velocidade é algo totalmente diferente e, embora afete a largura de banda, geralmente é algo que você não pode controlar com cargas de trabalho de largura de banda pesada. Portanto, se estiver testando a largura de banda, sempre use blocos maiores (dentro do razoável) para que seus dados por E/S sejam maiores do que se você estivesse testando IOPS, já que blocos maiores naturalmente levarão mais tempo para funcionar. Se, por exemplo, você quiser atingir 1 MB/s, mas estiver usando tamanhos de bloco de 8 KB, deverá enviar cerca de 125 IOPS para conseguir isso. No entanto, se você estivesse usando blocos de 512 KB, seriam necessárias apenas duas (2) IOPS.
(Se você mantivesse os 125 IOPS e ainda aumentasse o tamanho do bloco de 8 KB para 512 KB, agora você está enviando 64 MB/s!)

No entanto, como há mais dados em uma única E/S, geralmente leva mais tempo para "empacotar" essa E/S (localizar, agrupar e assim por diante). Portanto, os tempos de atendimento podem ser naturalmente maiores. Às vezes, você tem uma fila menor, então seus tempos de resposta, embora naturalmente mais altos, devem ser bastante próximos. Lembre-se de que, embora o tempo de resposta tenha um papel na largura de banda que você pode alcançar, o aumento na quantidade de dados que há por E/S geralmente supera qualquer ligeiro aumento no tempo de resposta (RT) por esse tipo de E/S. Como os tempos de resposta são maiores, você não quer que as cargas de trabalho de blocos grandes precisem ser aleatórias. Portanto, as cargas de trabalho de largura de banda tendem a ser sequenciais. Quando você introduz uma natureza aleatória em uma carga de trabalho de bloco grande, sua taxa de transferência de dados estável é consistentemente interrompida e você começa a sentir os efeitos dos tempos de resposta ligeiramente mais altos por E/S.

Throughput (IOPS) — o throughput/IOPS é a perspectiva mais comum com cargas de trabalho de blocos pequenos, especialmente à medida que se tornam mais aleatórias. Qualquer coisa acima de 32 KB-64 KB pode ser considerada um bloco grande. Com o throughput, os fatores mencionados acima são mais importantes (coisas como contagem de threads, sincronização ou assíncrona, tamanho da fila e assim por diante). Aqui você está tentando medir não quantos dados gerais você pode transferir durante o intervalo X, mas sim quantos pacotes individuais (solicitações de E/S) carregando esses dados você está tentando atender (a cada intervalo X). Ambientes como o OLTP (serviços bancários) pouco se importam com a quantidade de dados que podem transferir, pois o espaço ocupado pelos dados geralmente é pequeno. No entanto, esses pequenos conjuntos de dados podem estar ocupados e normalmente estão ocupados. Esses conjuntos de dados têm uma alta distorção (uma pequena quantidade de espaço é referenciada, mas variam agressiva e consistentemente). Os pacotes pequenos de dados geralmente contêm apenas solicitações para alterar/atualizar blocos com valores de string numéricos ou menores e, portanto, grandes pacotes de E/S não são necessários. No entanto, devido à natureza das transações e porque há muitas delas, queremos verificar se podemos acompanhar cada demanda individual. Normalmente, quanto menor o tamanho do bloco, mais IOPS você pode alcançar em um determinado cenário e, embora as cargas de trabalho de bloco pequeno estejam principalmente associadas ao acesso aleatório, você pode obter ainda mais throughput com cargas de trabalho sequenciais de blocos pequenos. No entanto, as cargas de trabalho sequenciais de blocos pequenos são específicas e não são tão comuns, portanto, teste esses cenários somente se seu ambiente exigir.