Unha pequena historia sobre fio e etcd
Rendemento do clúster depende en gran medida do rendemento do seu almacenamento. etcd exporta algunhas métricas a para proporcionar a información de rendemento de almacenamento desexada. Por exemplo, a métrica wal_fsync_duration_seconds. : Para que o almacenamento se considere suficientemente rápido, o percentil 99 desta métrica debe ser inferior a 10 ms. Se planea executar un clúster etcd en máquinas Linux e quere avaliar se o seu almacenamento é o suficientemente rápido (por exemplo, SSD), pode utilizar é unha ferramenta popular para probar as operacións de E/S. Execute o seguinte comando, onde test-data é o directorio baixo o punto de montaxe de almacenamento:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestSó tes que mirar os resultados e comprobar que o percentil 99 da duración menos de 10 ms. Se é así, tes un almacenamento razoablemente rápido. Aquí tes un 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 opcións --size e --bs para o noso escenario particular. Para obter un resultado útil de fio, proporciona os teus propios valores. Onde conseguilos? Ler .
- Durante a proba, toda a carga de E/S procede de fio. Nun escenario da vida real, é probable que haxa outras solicitudes de escritura que cheguen ao almacenamento ademais das relacionadas con wal_fsync_duration_seconds. A carga adicional aumentará o valor de wal_fsync_duration_seconds. Polo tanto, se o percentil 99 está preto dos 10 ms, o teu almacenamento está quedando sen velocidade.
- Toma a versión non inferior a 3.5 (os anteriores non mostran percentiles de duración de fdatasync).
- Arriba hai só un fragmento dos resultados de fio.
Longa historia sobre fio e etcd
Que é WAL en etcd
Normalmente úsanse bases de datos ; etcd tamén o usa. Non discutiremos aquí o rexistro de escritura anticipada (WAL) en detalle. Abonda con saber que cada membro do clúster etcd o mantén nun almacenamento persistente. etcd escribe cada operación de clave-valor (como unha actualización) en WAL antes de aplicala á tenda. Se un dos membros do almacenamento falla e reinicia entre as instantáneas, pode restaurar localmente as transaccións desde a última instantánea do contido de WAL.
Cando un cliente engade unha chave ao almacén de valores clave ou actualiza o valor dunha chave existente, etcd rexistra a operación en WAL, que é un ficheiro normal en almacenamento persistente. etcd DEBE estar completamente seguro de que a entrada WAL ocorreu realmente antes de continuar co procesamento. En Linux, unha chamada ao sistema non é suficiente para iso. , xa que a escritura real no almacenamento físico pode atrasarse. Por exemplo, Linux pode almacenar unha entrada WAL nunha caché na memoria do núcleo (como unha páxina caché) durante algún tempo. E para que os datos se escriban con precisión no almacenamento persistente, é necesaria a chamada ao sistema fdatasync despois da escritura, e etcd só o usa (como podes ver no resultado do traballo). , onde 8 é o descritor do ficheiro 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>Desafortunadamente, a escritura no almacenamento persistente non se produce ao instante. Se a chamada fdatasync é lenta, o rendemento do sistema etcd sufrirá. que o almacenamento considérase o suficientemente rápido se, no percentil 99, as chamadas fdatasync tardan menos de 10 ms en escribir no ficheiro WAL. Hai outras métricas útiles para o almacenamento, pero nesta publicación só falamos desta métrica.
Estimación do almacenamento con fio
Se precisa avaliar se o seu almacenamento é adecuado para etcd, use fio, unha ferramenta de proba de carga de E/S moi popular. Cómpre lembrar que as operacións do disco poden ser moi diferentes: síncronas e asíncronas, moitas clases de chamadas ao sistema, etc. Como resultado, fio é bastante difícil de usar. Ten moitos parámetros e diferentes combinacións dos seus valores producen cargas de traballo de E/S moi diferentes. Para obter cifras adecuadas para etcd, debes asegurarte de que a carga de escritura de proba de fio sexa o máis próxima posible á carga real de etcd ao escribir ficheiros WAL.
Polo tanto, fio debería, como mínimo, crear unha carga dunha serie de escrituras secuenciais no ficheiro, cada escritura consistirá nunha chamada ao sistema seguido da chamada ao sistema fdatasync. As escrituras secuenciais en fio requiren a opción --rw=write. Para que fio use a chamada do sistema de escritura ao escribir, en lugar de , debes especificar o parámetro --ioengine=sync. Finalmente, para chamar a fdatasync despois de cada escritura, cómpre engadir o parámetro --fdatasync=1. As outras dúas opcións deste exemplo (--size e -bs) son específicas do script. Na seguinte sección, mostrarémosche como configuralos.
Por que fio e como aprendemos a configuralo
Neste post, describimos un caso real. Temos un cluster v1.13 que supervisamos con Prometheus. etcd v3.2.24 foi aloxado nun SSD. As métricas de Etcd mostraron latencias de fdatasync demasiado altas, mesmo cando o clúster non estaba facendo nada. As métricas eran estrañas e non sabiamos realmente o que significaban. O clúster estaba formado por máquinas virtuais, había que entender cal era o problema: nos SSD físicos ou na capa de virtualización. Ademais, moitas veces fixemos cambios na configuración de hardware e software, e necesitabamos unha forma de avaliar os seus resultados. Poderíamos executar etcd en todas as configuracións e mirar as métricas de Prometheus, pero iso é demasiado complicado. Buscabamos un xeito bastante sinxelo de avaliar unha configuración específica. Queriamos comprobar se entendemos correctamente as métricas de Prometheus de etcd.
Pero para iso houbo que resolver dous problemas. En primeiro lugar, como é a carga de E/S que crea etcd ao escribir en WAL? Que chamadas de sistema se utilizan? Cal é o tamaño dos rexistros? En segundo lugar, se respondemos a estas preguntas, como reproducimos unha carga de traballo similar con fio? Non esquezas que fio é unha ferramenta moi flexible con moitas opcións. Resolvemos os dous problemas cun enfoque: usando os comandos и . lsof lista todos os descritores de ficheiros utilizados polo proceso e os seus ficheiros asociados. E con strace, pode examinar un proceso que xa está en execución ou iniciar un proceso e examinalo. strace imprime todas as chamadas do sistema do proceso que se está a examinar (e dos seus procesos fillos). Isto último é moi importante, xa que etcd só está adoptando un enfoque similar.
Primeiro usamos strace para explorar o servidor etcd para Kubernetes cando non había carga no clúster. Vimos que case todos os rexistros WAL tiñan aproximadamente o mesmo tamaño: 2200–2400 bytes. Polo tanto, no comando ao comezo da publicación, especificamos o parámetro -bs=2300 (bs significa o tamaño en bytes para cada entrada fio). Teña en conta que o tamaño da entrada etcd depende da versión etcd, da distribución, dos valores dos parámetros, etc., e afecta á duración de fdatasync. Se tes un escenario similar, examina os teus procesos etcd con strace para descubrir os números exactos.
Despois, para ter unha boa idea do que está a facer o sistema de ficheiros etcd, comezamos con strace e as opcións -ffttT. Así que tentamos examinar os procesos fillos e rexistrar a saída de cada un deles nun ficheiro separado e tamén obter informes detallados sobre o inicio e a duración de cada chamada ao sistema. Usamos lsof para confirmar a nosa análise da saída de trace e ver que descritor de ficheiro se estaba a utilizar para que propósito. Así, coa axuda de Strace, obtivéronse os resultados mostrados anteriormente. As estatísticas do tempo de sincronización confirmaron que wal_fsync_duration_seconds de etcd é consistente coas chamadas fdatasync con descritores de ficheiros WAL.
Revisamos a documentación de fio e escollemos opcións para o noso script para que fio xerase unha carga similar a etcd. Tamén comprobamos as chamadas ao sistema e a súa duración executando fio desde strace, de xeito similar a etcd.
Escollemos coidadosamente o valor do parámetro --size para representar toda a carga de E/S de fio. No noso caso, este é o número total de bytes escritos no almacenamento. Resultou ser directamente proporcional ao número de chamadas ao sistema de escritura (e fdatasync). Para un determinado valor de bs, o número de chamadas fdatasync = size/bs. Como nos interesaba o percentil, tiñamos que ter mostras suficientes para estar seguros, e calculamos que 10^4 sería suficiente para nós (é dicir, 22 mebibytes). Se --size é menor, pódense producir valores atípicos (por exemplo, varias chamadas fdatasync tardan máis do habitual e afectan ao percentil 99).
Proba vostede mesmo
Mostrámosche como usar fio e ver se o almacenamento é o suficientemente rápido como para que etcd funcione ben. Agora podes probalo por ti mesmo usando, por exemplo, máquinas virtuais con almacenamento SSD .
Fonte: www.habr.com