Uma pequena história sobre fio e etcd
O desempenho do cluster etcd depende muito do desempenho de seu armazenamento. O etcd exporta algumas métricas para o Prometheus para fornecer as informações necessárias sobre o desempenho do armazenamento. Por exemplo, a métrica wal_fsync_duration_seconds. A documentação do etcd diz : para que o armazenamento seja considerado rápido o suficiente, o percentil 99 dessa métrica deve ser menor que 10 ms. Se você planeja executar o cluster etcd em máquinas Linux e deseja avaliar se seu armazenamento é rápido o suficiente (como SSDs), você pode usar o fio , uma ferramenta popular para testar operações de E / S. Execute o seguinte comando, em que test-data é o diretório abaixo do ponto de montagem de armazenamento:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Você só precisa examinar os resultados e verificar se o percentil 99 da duração do fdatasync é menor que 10 ms. Nesse caso, você tem um armazenamento bastante 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]
Anotações
- Configuramos as opções --size e --bs para nosso cenário específico. Para obter um resultado útil do fio, insira seus valores. Onde consegui-los? Leia como aprendemos a configurar o fio .
- Durante o teste, toda a carga de E / S vem do fio. Em um cenário real, é provável que outras solicitações de gravação cheguem ao repositório, exceto aquelas relacionadas a wal_fsync_duration_seconds. Carga extra aumentará o valor de wal_fsync_duration_seconds. Portanto, se o percentil 99 atingir quase 10 ms, seu armazenamento não terá velocidade suficiente.
- Pegue a versão do fio não inferior a 3,5 (as anteriores não mostram percentis da duração do fdatasync).
- Acima está apenas um trecho dos resultados do fio.
Uma longa história sobre fio e etcd
O que é o WAL no etcd
Os bancos de dados geralmente usam logs write-ahead ; O etcd também o usa. Aqui não discutiremos em detalhes o log do write-ahead log (WAL). Só precisamos saber que cada membro do cluster etcd o mantém em armazenamento persistente. O etcd grava cada operação de par de valores-chave (por exemplo, atualizando) no WAL antes de aplicá-las ao repositório. Se, entre os instantâneos, um dos membros do armazenamento travar e reiniciar, ele poderá recuperar localmente as transações do último instantâneo usando o conteúdo do WAL.
Quando um cliente adiciona uma chave a um armazenamento de pares de valores-chave ou atualiza o valor de uma chave existente, etcd registra essa operação no WAL, que é um arquivo regular no armazenamento persistente. Antes de prosseguir, o etcd DEVE estar completamente certo de que a gravação no WAL realmente aconteceu. No Linux, uma única chamada do sistema de gravação não é suficiente para isso, pois a gravação no armazenamento físico pode ser atrasada. Por exemplo, o Linux pode armazenar um registro WAL em um cache na memória do kernel por algum tempo (como um cache de página). E para que os dados sejam gravados com precisão no armazenamento persistente, você precisa da chamada do sistema fdatasync após a gravação, e etcd apenas os usa (como você pode ver no strace , 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, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314>
Infelizmente, gravar no armazenamento persistente não é instantâneo. Se a chamada fdatasync for lenta, o desempenho do sistema etcd diminuirá. A documentação do etcd diz que o repositório é considerado bastante rápido se no percentil 99 das chamadas do fdatasync demorar menos de 10 ms para gravar no arquivo WAL. Existem outras métricas úteis para armazenamento, mas nesta postagem estamos falando apenas sobre essa métrica.
Avalie o armazenamento com fio
Se você precisar avaliar se o seu repositório é adequado para o etcd, use fio, uma ferramenta de teste de carga de E / S muito popular. Deve-se lembrar que as operações do disco podem ser muito diferentes: síncronas e assíncronas, muitas classes de chamadas do sistema etc. Como resultado, o fio é muito difícil de usar. Ele possui muitos parâmetros e combinações diferentes de seus valores produzem cargas de trabalho de E / S completamente diferentes. Para obter números adequados para o etcd, certifique-se de que a carga de gravação de teste do fio seja o mais próxima possível da carga real do etcd ao gravar arquivos WAL.
Consequentemente, o fio deve pelo menos criar uma carga na forma de uma série de operações de gravação seqüencial no arquivo, cada registro consistirá em uma chamada do sistema de gravação seguida por uma chamada do sistema fdatasync. Para operações de gravação sequencial, o fio precisa da opção --rw = write. Para que o fio use a chamada do sistema de gravação em vez de escrever durante a gravação, vale a pena especificar o parâmetro --ioengine = sync. Por fim, para que o fdatasync seja chamado após cada entrada, é necessário adicionar o parâmetro --fdatasync = 1. As outras duas opções neste exemplo (--size e --bs) são específicas do cenário. Na próxima seção, mostraremos como configurá-los.
Por que fio e como aprendemos a configurá-lo
Neste post, descrevemos o caso real. Tínhamos um cluster Kubernetes v1.13, que monitoramos usando o Prometheus. O etcd v3.2.24 foi hospedado em um SSD. As métricas do Etcd mostraram latências muito altas para o fdatasync, mesmo quando o cluster não estava fazendo nada. As métricas eram estranhas e nós realmente não sabíamos o que elas significavam. O cluster consistia em máquinas virtuais, era necessário entender qual era o problema: em SSDs físicos ou na camada de virtualização. Além disso, muitas vezes fizemos 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 examinar as métricas do Prometheus, mas isso é muito problemático. Estávamos procurando uma maneira bastante simples de avaliar uma configuração específica. Queríamos verificar se entendemos corretamente as métricas do Prometheus no etcd.
Mas, para isso, foi necessário resolver dois problemas. Primeiro, como é o carregamento 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 reproduzo uma carga de trabalho semelhante com o fio? Não esqueça que o fio é uma ferramenta muito flexível com muitas opções. Resolvemos os dois problemas com uma abordagem - usando os comandos lsof e strace . lsof exibe todos os descritores de arquivo usados pelo processo e seus arquivos associados. E com o strace, você pode estudar um processo já em execução ou iniciar um processo e estudá-lo. O strace exibe todas as chamadas do sistema do processo que está sendo estudado (e seus processos filhos). O último é muito importante, já que o etcd adota uma abordagem semelhante.
Primeiro, usamos o strace para aprender o servidor etcd para o Kubernetes quando não havia carga no cluster. Vimos que quase todos os registros WAL tinham aproximadamente o mesmo tamanho: 2200-2400 bytes. Portanto, no comando no início do post, especificamos o parâmetro --bs = 2300 (bs significa o tamanho em bytes para cada entrada do fio). Observe que o tamanho da entrada etcd depende da versão do etcd, da entrega, dos valores dos parâmetros 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 idéia das ações no sistema de arquivos etcd, iniciamos com strace e com as opções -ffttT. Por isso, 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 a duração de cada chamada do sistema. Usamos lsof para confirmar nossa análise da saída strace e ver qual descritor de arquivo foi usado para qual finalidade. Então, com strace, obtivemos os resultados mostrados acima. As estatísticas do tempo de sincronização confirmaram que o expoente wal_fsync_duration_seconds do etcd corresponde a chamadas fdatasync com descritores de arquivo WAL.
Estudamos a documentação do fio e selecionamos as opções para o nosso script para que o fio gere uma carga semelhante ao etcd. Também checamos as chamadas do sistema e sua duração executando fio from strace, semelhante ao etcd.
Selecionamos cuidadosamente o valor do parâmetro --size, que representa toda a carga de E / S do fio. No nosso caso, esse é o número total de bytes gravados no armazenamento. Acabou sendo diretamente proporcional ao número de chamadas do sistema de gravação (e fdatasync). Para um valor bs específico, o número de chamadas para fdatasync = tamanho / bs. Como estávamos interessados em percentil, deveríamos ter amostras suficientes para garantir a confiabilidade e calculamos que 10 ^ 4 seria suficiente para nós (obtemos 22 mebibytes). Se --size for menor, podem ocorrer outliers (por exemplo, várias chamadas fdatasync funcionam mais que o normal e afetam o 99º percentil).
Experimente você mesmo
Mostramos como usar o fio e descobrimos se o armazenamento tem velocidade suficiente para o alto desempenho, etcd. Agora você pode experimentá-lo por conta própria, usando, por exemplo, máquinas virtuais com armazenamento SSD na nuvem IBM .