Uma pequena história sobre fio e etcd
Desempenho do cluster depende em grande parte do desempenho de seu armazenamento. O etcd exporta algumas métricas para para fornecer as informações de desempenho de armazenamento desejadas. Por exemplo, a métrica wal_fsync_duration_seconds. : para que o armazenamento seja considerado rápido o suficiente, o percentil 99 dessa métrica deve ser inferior a 10 ms. Se você planeja executar um cluster etcd em máquinas Linux e deseja avaliar se seu armazenamento é rápido o suficiente (como um SSD), você pode usar é uma ferramenta popular para testar operações de E/S. Execute o seguinte comando, em que 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=mytestVocê só precisa olhar para os resultados e verificar se o percentil 99 da duração menos de 10 ms. Nesse caso, você tem armazenamento razoavelmente rápido. Aqui está um exemplo dos resultados:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (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
- Personalizamos as opções --size e --bs para nosso cenário específico. Para obter um resultado útil do fio, forneça seus próprios valores. Onde obtê-los? Ler .
- Durante o teste, toda a carga de E/S vem do fio. Em um cenário real, provavelmente haverá outras solicitações de gravação entrando no armazenamento além daquelas relacionadas a wal_fsync_duration_seconds. A carga extra aumentará o valor de wal_fsync_duration_seconds. Portanto, se o percentil 99 estiver próximo de 10 ms, seu armazenamento está ficando sem velocidade.
- Pegue a versão não inferior a 3.5 (os anteriores não mostram os percentis de duração do fdatasync).
- Acima está apenas um trecho dos resultados do fio.
Longa história sobre fio e etcd
O que é WAL no etcd
Normalmente, os bancos de dados usam ; O etcd também o usa. Não discutiremos o log write-ahead (WAL) em detalhes aqui. Basta sabermos que cada membro do cluster etcd o mantém em armazenamento persistente. O etcd grava cada operação de valor-chave (como uma atualização) no WAL antes de aplicá-lo à loja. Se um dos membros de armazenamento travar e reiniciar entre os instantâneos, ele poderá restaurar localmente as transações desde o último instantâneo por conteúdo WAL.
Quando um cliente adiciona uma chave ao armazenamento de valor-chave ou atualiza o valor de uma chave existente, o etcd registra a operação no WAL, que é um arquivo regular no armazenamento persistente. O etcd DEVE estar completamente certo de que a entrada WAL realmente ocorreu antes de continuar com o processamento. No Linux, uma chamada de sistema não é suficiente para isso. , pois a gravação real no armazenamento físico pode ser atrasada. Por exemplo, o Linux pode armazenar uma entrada WAL em um cache na memória do kernel (como um cache de página) por algum tempo. E para que os dados sejam gravados com precisão no armazenamento persistente, a chamada do sistema fdatasync é necessária após a gravação e o etcd apenas a usa (como você pode ver no resultado do trabalho , onde 8 é o descritor de arquivo WAL):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Infelizmente, a gravação no armazenamento persistente não acontece instantaneamente. Se a chamada fdatasync for lenta, o desempenho do sistema etcd será prejudicado. que o armazenamento é considerado rápido o suficiente se, no percentil 99, as chamadas fdatasync levarem menos de 10 ms para serem gravadas no arquivo WAL. Existem outras métricas úteis para armazenamento, mas neste post falaremos apenas sobre essa métrica.
Estimando o armazenamento com fio
Se você precisar avaliar se seu armazenamento é adequado para etcd, use fio, uma ferramenta de teste de carga de E/S muito popular. Deve-se lembrar que as operações de disco podem ser muito diferentes: síncronas e assíncronas, muitas classes de chamadas de sistema, etc. Como resultado, o fio é bastante difícil de usar. Ele tem muitos parâmetros e diferentes combinações de seus valores produzem cargas de trabalho de E/S muito diferentes. Para obter números adequados para o etcd, você deve certificar-se de que a carga de gravação de teste do fio esteja o mais próximo possível da carga real do etcd ao gravar arquivos WAL.
Portanto, o fio deve, no mínimo, criar uma carga na forma de uma série de gravações consecutivas no arquivo, cada gravação consistirá em uma chamada do sistema seguido pela chamada de sistema fdatasync. Gravações sequenciais em fio requerem a opção --rw=write. Para que o fio use a chamada do sistema write ao gravar, em vez de , você deve especificar o parâmetro --ioengine=sync. Por fim, para chamar fdatasync após cada gravação, você precisa adicionar o parâmetro --fdatasync=1. As outras duas opções neste exemplo (--size e -bs) são específicas do script. Na próxima seção, mostraremos como configurá-los.
Por que exatamente fio e como aprendemos a configurá-lo
Neste post, descrevemos um caso real. Nós temos um cluster v1.13 que monitoramos com o Prometheus. etcd v3.2.24 foi hospedado em um SSD. As métricas do Etcd mostraram latências fdatasync muito altas, mesmo quando o cluster não estava fazendo nada. As métricas eram estranhas e não sabíamos realmente o que significavam. O cluster era formado por máquinas virtuais, era preciso entender qual era o problema: em SSDs 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 todas as configurações e examinar as métricas do Prometheus, mas isso seria muito trabalhoso. Estávamos procurando uma maneira bastante simples de avaliar uma configuração específica. Queríamos verificar se entendemos as métricas do Prometheus do etcd corretamente.
Mas para isso, dois problemas tiveram que ser resolvidos. Primeiro, como é a carga de E/S que o etcd cria ao gravar no WAL? Quais chamadas de sistema são usadas? Qual o tamanho dos registros? Em segundo lugar, se respondermos a essas perguntas, como reproduzimos uma carga de trabalho semelhante com o fio? Não se esqueça que o fio é uma ferramenta muito flexível com muitas opções. Resolvemos os dois problemas em uma abordagem - usando os comandos и . lsof lista todos os descritores de arquivo usados pelo processo e seus arquivos associados. E com o strace, você pode examinar um processo já em execução ou iniciar um processo e examiná-lo. strace imprime todas as chamadas de sistema do processo que está sendo examinado (e seus processos filhos). O último é muito importante, pois o etcd está apenas adotando uma abordagem semelhante.
Primeiro usamos strace para explorar o servidor etcd para Kubernetes quando não havia carga no cluster. Vimos que quase todos os registros do WAL tinham aproximadamente o mesmo tamanho: 2200 a 2400 bytes. Portanto, no comando do início do post, especificamos o parâmetro -bs=2300 (bs significa o tamanho em bytes para cada entrada de fio). Observe que o tamanho da entrada do etcd depende da versão do etcd, distribuição, valores de parâmetro, etc., e afeta a duração do fdatasync. Se você tiver um cenário semelhante, examine seus processos etcd com strace para descobrir os números exatos.
Então, para ter uma boa ideia do que o sistema de arquivos etcd está fazendo, começamos com strace e as opções -ffttT. Então, tentamos examinar os processos filhos e registrar a saída de cada um deles em um arquivo separado, além de obter relatórios detalhados sobre o início e a duração de cada chamada do sistema. Usamos lsof para confirmar nossa análise da saída do strace e ver qual descritor de arquivo estava sendo usado para qual finalidade. Assim, com a ajuda do strace, foram obtidos os resultados mostrados acima. As estatísticas de tempo de sincronização confirmaram que wal_fsync_duration_seconds do etcd é consistente com chamadas fdatasync com descritores de arquivo WAL.
Analisamos a documentação do fio e escolhemos opções para o nosso script para que o fio gerasse uma carga semelhante ao etcd. Também verificamos as chamadas do sistema e sua duração executando fio a partir do strace, semelhante ao etcd.
Escolhemos cuidadosamente o valor do parâmetro --size para representar toda a carga de I/O do fio. No nosso caso, este é o número total de bytes gravados no armazenamento. Acabou sendo diretamente proporcional ao número de chamadas de sistema de gravação (e fdatasync). Para um determinado valor de bs, o número de chamadas fdatasync = tamanho/bs. Como estávamos interessados no percentil, tínhamos que ter amostras suficientes para ter certeza e calculamos que 10^4 seria o suficiente para nós (são 22 mebibytes). Se --size for menor, podem ocorrer outliers (por exemplo, várias chamadas fdatasync levam mais tempo do que o normal e afetam o 99º percentil).
Experimente você mesmo
Mostramos a você como usar o fio e ver se o armazenamento é rápido o suficiente para que o etcd funcione bem. Agora você pode experimentar usando, por exemplo, máquinas virtuais com armazenamento SSD em .
Fonte: habr.com