Uma breve história sobre fio e etcd
Desempenho do cluster depende em grande parte do desempenho do seu armazenamento. etcd exporta algumas métricas em , para fornecer as informações necessárias sobre o desempenho do armazenamento. Por exemplo, a métrica wal_fsync_duration_seconds. : para que o armazenamento seja considerado suficientemente rápido, o percentil 99 dessa métrica deve ser menor que 10 ms. Se você planeja executar um cluster etcd em máquinas Linux e deseja avaliar se seu armazenamento é rápido o suficiente (por exemplo, SSD), você pode usar — uma ferramenta popular para testar operações de entrada/saída. Execute o seguinte comando, onde test-data é o diretório sob o ponto de montagem do armazenamento:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestBasta olhar os resultados e verificar se o percentil 99 da duração é menor que 10 ms. Se sim, você tem um armazenamento rápido o suficiente. Aqui está um exemplo de resultados:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
percentis de sync (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]Notas
- Nós ajustamos os valores dos parâmetros —size e —bs para o nosso cenário específico. Para obter um resultado útil do fio, insira seus próprios valores. Onde obtê-los? Consulte .
- Durante o teste, toda a carga de entrada/saída é gerada pelo fio. Em um cenário real, provavelmente haverá outras solicitações de gravação no armazenamento, além das relacionadas ao wal_fsync_duration_seconds. Uma carga adicional aumentará o valor do wal_fsync_duration_seconds. Portanto, se o percentil 99 quase atingiu 10 ms, seu armazenamento pode não ter velocidade suficiente.
- Use a versão não inferior a 3.5 (as anteriores não mostram os percentis de duração do fdatasync).
- Acima está apenas um fragmento dos resultados do fio.
Uma longa história sobre fio e etcd
O que é WAL em etcd
Normalmente, os bancos de dados usam ; etcd também o utiliza. Aqui não vamos discutir em detalhes o log de gravação antecipada (write-ahead log, WAL). Basta sabermos que cada membro do cluster etcd o mantém em um armazenamento permanente. O etcd registra cada operação com pares chave-valor (como uma atualização) no WAL antes de aplicá-las ao armazenamento. Se, entre as instantâneas, um dos membros do armazenamento falhar e reiniciar, ele pode recuperar localmente as transações desde a última instantânea com o conteúdo do WAL.
Quando um cliente adiciona uma chave ao armazenamento de pares chave-valor ou atualiza o valor de uma chave existente, o etcd registra essa operação no WAL, que é um arquivo comum em armazenamento permanente. Antes de continuar o processamento, o etcd DEVE estar completamente certo de que a gravação no WAL realmente ocorreu. No Linux, isso não é garantido por uma única chamada de sistema. , uma vez que a gravação no armazenamento físico pode ser adiada. Por exemplo, o Linux pode manter a gravação WAL em cache na memória do kernel (como no cache de páginas) por um tempo. E para que os dados sejam gravados com segurança no armazenamento permanente, é necessária uma chamada de sistema fdatasync após a gravação, e o etcd a utiliza (como pode ser visto no resultado da execução , onde 8 é o descritor do arquivo WAL):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296
21:23:09.895041 fdatasync(8) = 0Infelizmente, a gravação no armazenamento permanente não acontece instantaneamente. Se a chamada fdatasync funciona lentamente, o desempenho do sistema etcd diminui. , que o armazenamento é considerado rápido o suficiente se, no 99º percentil das chamadas fdatasync ao gravar em um arquivo WAL, levar menos de 10 ms. Existem outras métricas úteis para o armazenamento, mas neste post estamos falando apenas dessa métrica.
Avaliação do armazenamento usando fio
Se você precisa avaliar se seu armazenamento é adequado para etcd, utilize fio — uma ferramenta de teste de carga de entrada e saída muito popular. É importante lembrar que as operações de disco podem variar de diversas formas: síncronas e assíncronas, uma série de classes de chamadas de sistema, etc. Como resultado, o fio é bastante complicado de usar. Ele possui muitos parâmetros, e diferentes combinações de seus valores geram cargas de entrada e saída completamente diferentes. Para obter números adequados para etcd, é necessário garantir que a carga de teste de gravação do fio esteja o mais próxima possível da carga real de etcd ao gravar arquivos WAL.
Portanto, o fio deve, no mínimo, gerar uma carga na forma de uma série de operações de gravação sequenciais em um arquivo, onde cada gravação consistirá em uma chamada de sistema , seguida da chamada de sistema fdatasync. Para operações de gravação sequenciais, o fio precisa do parâmetro —rw=write. Para que, ao gravar, o fio utilize a chamada de sistema write, e não , você deve especificar o parâmetro —ioengine=sync. Finalmente, para que após cada gravação o fdatasync seja chamado, é necessário adicionar o parâmetro —fdatasync=1. Os dois outros parâmetros neste exemplo (—size e —bs) dependem do cenário específico. Na próxima seção, vamos explicar como configurá-los.
Por que exatamente o fio e como aprendemos a configurá-lo
Neste post, descrevemos um caso real. Tivemos um cluster v1.13, que monitoramos com o Prometheus. O etcd v3.2.24 estava hospedado em SSD. As métricas do etcd mostravam latências excessivas para fdatasync, mesmo quando o cluster não estava fazendo nada. As métricas eram estranhas e não sabíamos exatamente o que elas significavam. O cluster era composto por máquinas virtuais, e precisávamos entender onde estava o problema: nos SSD físicos ou na camada de virtualização. Além disso, frequentemente fazíamos alterações na configuração de hardware e software, e precisávamos de uma maneira de avaliar seus resultados. Poderíamos executar o etcd em cada configuração e observar as métricas do Prometheus, mas isso era muito trabalhoso. Estávamos procurando uma maneira bastante simples de avaliar uma configuração específica. Queríamos verificar se estávamos interpretando corretamente as métricas do Prometheus do etcd.
Mas para isso, era necessário resolver dois problemas. Primeiro, como é a carga de entrada e saída que o etcd gera ao gravar no WAL? Quais chamadas de sistema são utilizadas? Qual é o tamanho das gravações? Em segundo lugar, se conseguirmos responder a essas perguntas, como reproduzir uma carga de trabalho semelhante com o fio? Não se esqueça de que o fio é uma ferramenta muito flexível com muitos parâmetros. Resolvemos ambos os problemas com uma única abordagem — através de comandos. e . lsof exibe todos os descritores de arquivo utilizados por um processo e os arquivos associados. E com o strace, podemos estudar um processo já em execução ou iniciar um novo processo e analisá-lo. O strace mostra todas as chamadas de sistema do processo em estudo (e de seus processos filhos). Isso é muito importante, pois o etcd aplica precisamente essa abordagem.
Primeiro, usamos o strace para estudar o servidor etcd para Kubernetes, quando não havia carga sobre o cluster. Vimos que quase todas as gravações do WAL tinham tamanhos semelhantes: 2200–2400 bytes. Portanto, na linha de comando no início do post, especificamos o parâmetro —bs=2300 (bs significa tamanho em bytes para cada gravação do fio). Note que o tamanho da gravação do etcd depende da versão do etcd, da distribuição, dos valores dos parâmetros, etc., e afeta a duração do fdatasync. Se você estiver em um cenário semelhante, estude seus processos etcd com o strace para descobrir os números exatos.
Em seguida, para entender bem as ações no sistema de arquivos do etcd, o iniciamos com o strace e com os parâmetros -ffttT. Assim, tentamos estudar os processos filhos e gravar a saída de cada um deles em um arquivo separado, além de obter relatórios detalhados sobre o início e duração de cada chamada de sistema. Usamos o lsof para confirmar nossa análise da saída do strace e ver qual descritor de arquivo era usado para quais propósitos. Assim, com o strace, obtivemos os resultados mostrados acima. As estatísticas de tempo de sincronização confirmaram que o indicador wal_fsync_duration_seconds do etcd corresponde às chamadas de fdatasync com os descritores de arquivo do WAL.
Estudamos a documentação do fio e selecionamos os parâmetros para o nosso cenário, para que o fio gerasse uma carga semelhante à do etcd. Também verificamos as chamadas de sistema e suas durações, executando o fio a partir do strace, análogamente ao que fizemos com o etcd.
Selecionamos cuidadosamente o valor do parâmetro —size, que representa toda a carga de entrada e saída do fio. No nosso caso, este é o total de bytes gravados no armazenamento. Ele se revelou diretamente proporcional ao número de chamadas de sistema write (e fdatasync). Para um determinado valor de bs, o número de chamadas fdatasync = size/bs. Como estávamos interessados no percentil, precisávamos ter amostras suficientes para confiabilidade, e estimamos que 10^4 seria suficiente (totalizando 22 mebibytes). Se —size for menor, podem ocorrer outliers (por exemplo, várias chamadas de fdatasync podem levar mais tempo que o normal e afetar o 99º percentil).
Experimente por conta própria
Mostramos como usar fio e verificar se a velocidade do armazenamento é adequada para alto desempenho do etcd. Agora você pode testar isso na prática, usando, por exemplo, máquinas virtuais com armazenamento SSD em .
Fonte: habr.com
