Introdução
Recapitulando: No Blog do Episódio-1, temos coberto RHCS, BlueStore introdução, laboratório de detalhes de hardware, metodologia de benchmarking de desempenho e comparação entre o Padrão Ceph configuração vs Atento Ceph de configuração
Este é o segundo episódio do desempenho série de posts sobre RHCS 3.2 BlueStore em execução no flash cluster. Não há nenhuma regra de ouro para categorizar tamanhos de bloco em uma categoria pequena, média e grande. Como tal, designamos 4K para pequena categoria de tamanho de bloco, 8K-64K para médio e 1M-4M para grande categoria de tamanho de bloco. Neste episódio você vai aprender sobre a caracterização de performance do armazenamento de bloco Ceph para pequenos (4K), médios (8K-32K) e grandes (1M-4M) tamanhos de bloco através de leitura aleatória, escrita aleatória e padrões de carga de trabalho de leitura-escrita aleatória.
resumo
- pequena carga de trabalho do bloco 4K, entregue até 2.2 milhões de leituras aleatórias, 691K leitura-escrita aleatória (70/30) e 463K escrita aleatória IOPS até limitado pela CPU e contenção de mídia.
- Similar à pequena carga de trabalho em bloco, o desempenho em bloco médio foi encontrado para ser limitado pela CPU e contenção de mídia.
- grande bloco 4m volume de trabalho desempenho pico registado a 10.9 GB / s para todos os três padrões de teste, ou seja, leitura aleatória, escrita e leitura-escrita (70/30) mix até ser limitada pela largura de banda da rede Cliente.
Part-1: pequeno tamanho do bloco (4KB) desempenho
Takeaways chave
- carga de trabalho de leitura aleatória mostrou 2.2 milhões de IOPS@3ms latência média até estrangulamento pela saturação dos meios.
- Read-Write aleatória (70/30) a carga de trabalho da mistura mostrou uma latência média de 691K IOPS@6ms até que o bottlenecked by Ceph node CPU resource contention.
- escrita aleatória: 463K IOPS@11ms latência média até estrangulamento por contenção de recursos de CPU do nó Ceph.
Summary
In this part of the testing, Ceph block storage interface was exercised with small block size (4KB) workload across random read, random write, and random read-write (70/30) mix patterns. As métricas chave capturadas durante os testes incluem IOPS, média, latência, CPU de nó Ceph e utilização de mídia.
Graph-1 mostra desempenho de linha superior para 4K tamanho de bloco em diferentes padrões de acesso com 5 nós all-flash. Como tal, o máximo desempenho foi encontrado
- Leitura Aleatória: 2,2 Milhões de IOPS@ 3ms latência média
- Aleatórios de Leitura-Escrita (70/30) Mix: 691K IOPS @6ms latência média
- Gravação Aleatória: 463K IOPS@11ms latência média
a utilização da CPU e da mídia capturada nos gráficos-2 e graph-3 nos ajudou a entender os estrangulamentos para diferentes padrões de carga de trabalho.
- o desempenho de leitura aleatória foi encontrado para ser estrangulado pela contenção de recursos da CPU, no entanto, a utilização da mídia também foi encontrado no lado superior. Como tal, adicionamos nós Ceph adicionais (CPU e mídia) o desempenho de leitura aleatória poderia ter escalado mais alto.
- tanto para escrita aleatória e leitura aleatória (70/30) mix, o desempenho foi gargalo devido ao maior consumo de CPU. Curiosamente, ao mesmo tempo, a mídia tinha recursos suficientes que permaneceram sem uso devido à falta de poder computacional. Como tal, uma maior alocação do núcleo do CPU para os GDS do Ceph poderia ter fornecido maior desempenho para escrita aleatória & leitura-escrita aleatória de cargas de trabalho mix.
the OSD data device (P4500 NVMe) utilization stayed under 50% utilization, the Intel Optane P4800 device which was hosting BlueStore WAL and Rocksdb metadata were found to be very busy@90%. O parâmetro bluestore_min_alloc_size_ssd foi definido para 16KB, daí que todas as escritas abaixo de 16KB foram adiadas, a escrita primeiro vai para o dispositivo WAL e, em seguida, assíncronamente é escrito para os dados OSD, daí que o dispositivo Optane P4800 tinha absorvido as escritas para todos os os OSDs na máquina. Apesar da alta utilização no dispositivo RocksDB/WAL, não vimos quaisquer sinais de contenção no dispositivo de dados OSD P4500. Mas com base nesta experiência, não recomendaríamos colocar mais de 7 x P4500 dispositivos NVMe atrás de uma única Intel Optane P4800 para Wal / RocksDB.
Gráfico 2
Gráfico 3
Outro teste interessante, nós não funcionou foi o cliente de teste de varrimento, onde nós temos a escala linear-até o número de clientes de partida 20 e 140. À medida que aumentamos a carga do cliente, observamos melhorias de desempenho lineares até atingirmos o congestionamento da CPU no Ceph OSD. Com 100 clientes temos observado ~445K somado 4K write IOPS. Após este sistema de pontos, o congestionamento dos recursos resultou em altas latências de cauda. Intel Optane usado como metadados ajudou a absorver a latência do pico com um elevado número de paralelo clientes, como tal, a latência média ficou em 40ms.
G
Parte-2: Desempenho de tamanho médio de bloco
Takeways
- até que o desempenho foi bloqueado pela saturação de CPU e mídia, 5 nós Ceph all-flash entregaram ~1,8 milhões de leituras aleatórias, ~636K leitura aleatória (70/30) e ~410K escrita aleatória IOPS.
- para escalar o desempenho, nós Ceph OSD adicionais tiveram que ser adicionados no cluster Ceph existente.
resumo
nos gráficos seguintes, nós tentamos representar vários pontos de dados diferentes, tais como IOPS, latência média, latência de cauda, CPU do nó Ceph e utilização de mídia. E todos eles em uma gama de tamanho de bloco, ou seja, de 4K até 64K para escrita aleatória, leitura aleatória e leitura-escrita aleatória (70/30) mix.
alguns pontos de dados interessantes incluem
- como esperado, pequenas dimensões de blocos mostraram maior IOPS e menor latência média e cauda, em comparação com tamanhos de blocos Médios. Como tal, observamos ~1.8 milhões, ~636K, ~410K IOPS para leitura aleatória, leitura aleatória Mix e escrita aleatória carga de trabalho, respectivamente.
- alta utilização foi observada em CPU e dispositivos de mídia em nós Ceph OSD. Verificou-se que a utilização foi tão elevada como ~90% e ~80%, respectivamente, para a UCP e para a media. Como tal, o desempenho poderia ter aumentado se adicionássemos nós Ceph OSD ao cluster Ceph existente.
G
Parte 3: o Grande Tamanho do Bloco de Desempenho
Pedidas
- Grande bloco de 4M de desempenho, atingiu um pico de 10.9 GB/s para leitura aleatória, escrita e leitura-escrita (70/30) mix. A rede cliente foi considerada o fator limitante e causando um gargalo de desempenho.
- o desempenho poderia ter sido maior, se tivéssemos mais nós clientes ou maiores tubos de rede.
Summary
All the different patterns that we have tested i.e. random read, write and read-write (70/30) mix for large block size 4m workpled at 10.9 GB/s aggreged throughput. A rede de clientes foi considerada o fator limitante que causou o gargalo de desempenho. Além de rede, o segundo recurso mais utilizado foi a mídia, no entanto, ele tinha suficiente margem de manobra disponível para fornecer mais desempenho, se a rede não era o gargalo.
G
Seguinte
Continuando o benchmarking série de blog, na próxima seção, irá explicar os resultados associados com RHCS 3.2 testes de escalabilidade. Respondendo a algumas perguntas chave como”como o desempenho muda indo de um cluster de 3 nós para 5 nós”. Fiquem Atentos.