PowerScale, Isilon OneFS: Teste de desempenho do HBase no Isilon

Introdução

Fizemos uma série de testes de benchmark de desempenho em um cluster do Isilon X410 usando o conjunto de benchmark YCSB e o CDH 5.10.

O ambiente de laboratório de POC da CAE foi configurado com 5 nós isilon x410 executando o OneFS 8.0.0.4 e posterior 8.0.1.1 referência de desempenho de streaming de block grande NFS Devemos esperar 5 gravações de ~700 MB/s (3,5 GB/s) e 5 leituras ~1 GB/s (5 GB/s) para nossos máximos teóricos agregados em qualquer um desses testes.

Os (9) nós de computação são servidores Dell PowerEdge FC630 que executam CentOS 7.3.1611, cada um configurado com 2 CPUs Intel Xeon® E5-2697 v4 a 2,30 GHz com 512 GB de RAM. O armazenamento local é 2 SSDs no RAID 1 formatados como XFS para o sistema operacional e arquivos de espaço/derramamento de arranhões.

Havia também três servidores de borda adicionais que foram usados para impulsionar a carga YCSB.

A rede de back-end entre os nós de computação e o Isilon é de 10 Gbps com jumbo-frames definidos (MTU =9162) para nics e portas de switch.

Teste inicial

A primeira série de testes foi determinar os parâmetros relevantes no lado do HBASE que afetava a saída geral. Usamos a ferramenta YCSB para gerar a carga do HBASE. Esse teste inicial foi executado usando um único client (servidor de borda) usando a fase de "carga" de YCSB e 40 milhões de linhas. Esta tabela foi excluída antes de cada execução.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs — número máximo de arquivos de registro de gravação antecipada (WAL). Esse valor multiplicado pelo tamanho do bloco do HDFS (dfs.blocksize) é o tamanho do WAL que deve ser exibido novamente quando um servidor trava. Esse valor é inversamente proporcional à frequência de flushes no disco.

hbase.wal.regiongrouping.numgroups — ao usar o WAL de vários HDFS como o WALProvider, define quantos registros de gravação antecipada cada RegionServer deve executar. Resulta nesse número de pipelines do HDFS. As gravações de uma determinada região só vão para um único pipeline, distribuindo a carga total do RegionServer.

A filosofia aqui era paralelizar quantas gravações pudéssemos, aumentando o número de WALs e, em seguida, o número de threads (pipeline) por WAL. Os dois gráficos anteriores mostram que, para um determinado número para "maxlogs" 128 ou 256, não vemos nenhuma alteração real indicando que não estamos realmente pressionando esse número do lado do client. Oby variando o número de "pipelines" por arquivo, embora possamos ver a tendência indicando o parâmetro que é sensível à paralelização. A próxima pergunta é: onde o Isilon "fica no caminho" com a E/S de disco, a rede, a CPU ou o OneFS, e podemos analisar o relatório de estatísticas do Isilon.


 
Os gráficos de rede e CPU nos dizem que o cluster do Isilon está subutilizado e tem espaço para mais trabalho. A CPU seria > de 80%, e a largura de banda da rede seria superior a 3 GB/s.



Esses gráficos mostram as estatísticas do protocolo HDFS e como elas são traduzidas pelo OneFS. As operações do HDFS são múltiplos de dfs.blocksize, que tem 256 MB aqui. O interessante aqui é que o gráfico "Heat" mostra as operações de arquivo do OneFS e você pode ver a correlação de gravações e bloqueios. Nesse caso, o HBase está fazendo acréscimos ao WAL, de modo que o OneFS bloqueia o arquivo do WAL para cada gravação acrescentada. É o que esperamos de gravações estáveis em um file system em cluster. Isso parece estar contribuindo para o fator limitando esse conjunto de testes.

Atualizações do HBase

Este próximo teste foi fazer mais testes para descobrir o que acontece em escala, então criei uma tabela de um bilhão de linhas, que levou uma boa hora para ser gerada e, em seguida, executou um YCSB que atualizou 10 milhões das linhas usando as configurações "workloada" (50/50 de leitura/gravação). Isso foi executado em um único client, e eu também estava procurando o máximo de throughput que eu poderia gerar, então executei isso como uma função do número de threads YCSB. Outra observação foi que fizemos alguns ajustes do Isilon e fomos para o OneFS 8.0.1.1, que tem ajustes de desempenho para o serviço de nó de dados. Você pode ver o aumento no desempenho em comparação com o conjunto anterior de execução. Para essas execução, definimos hbase.regionserver.maxlogs = 256 e hbase.wal.regiongrouping.numgroups = 20

Analisando essas etapas, a primeira coisa que fica evidente é a queda em alta contagem de threads. Eu estava curioso se esse era um problema do Isilon ou um problema no lado do cliente. Veremos mais alguns testes relacionados a isso nos próximos parágrafos. Mas posso dizer que impulsionar mais de 200 mil operações < com uma latência de atualização de 3 ms é impressionante. Cada uma dessas atualizações era rápida, e eu poderia fazer uma após a outra, e o gráfico abaixo mostra o equilíbrio uniforme entre os nós do Isilon para essas execução.



Novamente, você pode ver no gráfico heat que as operações de arquivo são gravações e bloqueios correspondentes à natureza acrescentada dos processos do WAL.

Dimensionamento regional do servidor

O próximo teste foi determinar como os nós do Isilon (cinco deles) seriam executados em relação a um número diferente de servidores da região. O mesmo script de atualização executado no teste anterior foi executado aqui. Uma tabela de um bilhão de linhas e 10 milhões de linhas atualizadas usando "workloada" com um único client e threads YCSB em 51, também mantivemos a mesma configuração nos maxlogs e pipelines (256 e 20, respectivamente).

 
Os resultados são informativos, embora não sejam surpreendentes. A natureza de scale-out do HBase combinada com a natureza de scale-out do Isilon e more==better. Este é um teste que eu recomendaria que os clientes executem em seus ambientes como parte de seu próprio exercício de dimensionamento. Pode chegar a um ponto de redução de retornos, mas aqui temos nove servidores de alto desempenho que pressionam cinco nós do Isilon e parece que há espaço para mais.

Mais clientes

A última série de testes vem desse local escuro e profundo que faz com que você queira quebrar o sistema que está testando. Afinal, é um método científico perfeitamente válido para testar até que as coisas se quebrem e liguem, sabendo qual é o limite máximo dos parâmetros que estão sendo testados. Nessa série de testes, eu tinha dois servidores adicionais dos quais eu poderia usar para executar o client. Além disso, executei dois clients YCSB em cada um, permitindo dimensionar verticalmente para seis clients, cada um gerando 512 threads, que seriam 4.096 threads em geral. Eu criei duas tabelas diferentes, uma com 4 bilhões de linhas divididas em 600 regiões e uma com 400 milhões de linhas divididas em 90 regiões.  

 



 

Como você pode ver, o tamanho da tabela é pouco importante neste teste. Analisando os gráficos de calor do Isilon novamente, você pode ver que há algumas diferenças percentuais no número de operações de arquivos, principalmente em linha, com as diferenças de uma tabela de quatro bilhões de linhas para 400 milhões de linhas.

Conclusão

O HBase é um bom candidato para a execução no Isilon, principalmente devido às arquiteturas de scale-out para scale-out. O HBase faz muito de seu próprio armazenamento em cache e está dividindo a tabela em um bom número de regiões em que você obtém o HBase para scale-out com seus dados. Em outras palavras, ele faz um bom trabalho de cuidar de suas próprias necessidades, e o file system está lá para persistência. Não fomos capazes de enviar os testes de carga ao ponto de realmente quebrar coisas, mas se você observar quatro bilhões de linhas em seu design de HBase e esperar 800.000 operações com menos de 3 ms de latência, essa arquitetura oferecerá suporte a ela. Se você observar que eu não mencionei muito mais sobre qualquer um dos muitos outros ajustes no lado do client que você poderia aplicar ao próprio HBase, espero que todos esses ajustes ainda sejam válidos e além do escopo deste teste.