Como comprobar os discos con fio para o rendemento suficiente para etcd

Nota. transl.: Este artigo é o resultado dunha mini-investigación realizada por enxeñeiros de IBM Cloud na procura dunha solución a un problema real relacionado co funcionamento da base de datos etcd. Unha tarefa semellante foi relevante para nós, non obstante, o curso das reflexións e accións dos autores pode resultar interesante nun contexto máis amplo.

Breve resumo de todo o artigo: fio e etcd

O rendemento dun clúster etcd depende moito da velocidade do almacenamento subxacente. etcd exporta varias métricas de Prometheus para supervisar o rendemento. Un deles é wal_fsync_duration_seconds. Na documentación de etcd diese almacenamento pódese considerar o suficientemente rápido se o percentil 99 desta métrica non supera os 10 ms...

Se estás considerando configurar un clúster etcd en máquinas Linux e queres comprobar se as unidades (como as SSD) son o suficientemente rápidas, recomendamos usar o popular probador de E/S chamado fio. É suficiente executar o seguinte comando (directorio test-data debe estar situado na partición montada da unidade probada):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Só queda mirar a saída e comprobar se o percentil 99 encaixa fdatasync en 10 ms. Se é así, entón a túa unidade funciona o suficientemente rápido. Aquí tes un exemplo de saída:

fsync/fdatasync/sync_file_range:
  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]

Algunhas notas:

1. No exemplo anterior, axustamos os parámetros --size и --bs para un caso concreto. Para obter un resultado significativo fio, especifique os valores apropiados para o seu caso de uso. Como elixilos comentarase a continuación.
2. Só durante a proba fio carga o subsistema de disco. Na vida real, é probable que outros procesos escriban no disco (ademais dos relacionados con wal_fsync_duration_seconds). Esta carga adicional pode aumentar wal_fsync_duration_seconds. Noutras palabras, se o percentil 99 das probas con fio, só un pouco menos de 10 ms, hai unha boa probabilidade de que o rendemento do almacenamento non sexa suficiente.
3. Para a proba necesitará a versión fio non inferior a 3.5, porque as versións antigas non agregan resultados fdatasync en forma de percentiles.
4. A conclusión anterior é só un pequeno extracto da conclusión xeral fio.

Máis información sobre fio e etcd

Algunhas palabras sobre WALs etcd

Xeralmente, úsanse bases de datos rexistro proactivo (rexistro de escritura anticipada, WAL). etcd tamén se ve afectado. Unha discusión sobre WAL está fóra do alcance deste artigo, pero para os nosos propósitos, o que cómpre saber é que cada membro do clúster de etcd almacena WAL nun almacenamento persistente. etcd escribe algunhas operacións de almacenamento de clave-valor (como actualizacións) en WAL antes de executalas. Se un nodo falla e reinicia entre as instantáneas, etcd pode recuperar transaccións desde a instantánea anterior en función do contido do WAL.

Así, cada vez que un cliente engade unha clave á tenda KV ou actualiza o valor dunha clave existente, etcd engade a descrición da operación ao WAL, que é un ficheiro normal da tenda persistente. etcd DEBE estar seguro ao 100% de que a entrada WAL se gardou realmente antes de continuar. Para logralo en Linux, non abonda con usar a chamada ao sistema write, xa que a propia operación de escritura no medio físico pode atrasarse. Por exemplo, Linux pode manter unha entrada WAL nunha caché do núcleo en memoria (por exemplo, na caché da páxina) durante algún tempo. Para garantir que os datos se escriben no soporte, débese invocar unha chamada ao sistema despois da escritura fdatasync - isto é exactamente o que fai etcd (como podes ver na seguinte saída strace; Aquí 8 - Descriptor de ficheiro WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Desafortunadamente, escribir no almacenamento persistente leva algún tempo. A execución prolongada de chamadas fdatasync pode afectar o rendemento de etcd. Na documentación do repositorio indicado, que para o desempeño suficiente é necesario que o percentil 99 da duración de todas as convocatorias fdatasync ao escribir nun ficheiro WAL foi inferior a 10 ms. Hai outras métricas relacionadas co almacenamento, pero este artigo centrarase nesa.

Valoración do almacenamento con fio

Podes avaliar se un determinado almacenamento é axeitado para usar con etcd usando a utilidade fio - un popular probador de E/S. Teña en conta que a E/S do disco pode ocorrer de moitas formas diferentes: sincronización/async, moitas clases de syscall diferentes, etc. A outra cara da moeda é esa fio extremadamente difícil de usar. A utilidade ten moitos parámetros, e diferentes combinacións dos seus valores levan a resultados completamente diferentes. Para obter unha estimación razoable de etcd, cómpre asegurarse de que a carga de escritura xerada por fio sexa o máis próxima posible á carga de escritura do ficheiro WAL de etcd:

• Isto significa que o xerado fio a carga debe ser polo menos unha serie de escrituras consecutivas no ficheiro, onde cada escritura consiste nunha chamada ao sistema writeseguido por fdatasync.
• Para habilitar a escritura secuencial, debes especificar a marca --rw=write.
• Que fio escribiu usando chamadas write (en lugar de outras chamadas ao sistema, por exemplo, pwrite), use a bandeira --ioengine=sync.
• Por último, a bandeira --fdatasync=1 garante que cada write debe ser fdatasync.
• Os outros dous parámetros do noso exemplo son: --size и --bs - pode variar segundo o caso de uso específico. A seguinte sección describirá a súa configuración.

Por que escollemos fio e como aprendemos a configuralo

Esta nota provén dun caso real que atopamos. Tivemos un clúster en Kubernetes v1.13 con monitorización en Prometheus. Os SSD usáronse como almacenamento para etcd v3.2.24. As métricas de Etcd mostraron latencias demasiado altas fdatasync, mesmo cando o clúster estaba inactivo. Para nós, estas métricas parecían moi dubidosas e non estabamos seguros de que representaban exactamente. Ademais, o clúster estaba formado por máquinas virtuais, polo que non era posible dicir se o atraso se debía á virtualización ou a culpa da SSD.

Ademais, consideramos varios cambios na configuración de hardware e software, polo que necesitabamos unha forma de avalialos. Por suposto, sería posible executar etcd en cada configuración e mirar as métricas de Prometheus correspondentes, pero iso requiriría un esforzo importante. O que necesitabamos era un xeito sinxelo de avaliar unha configuración específica. Queriamos probar a nosa comprensión das métricas de Prometheus procedentes de etcd.

Isto requiriu resolver dous problemas:

• En primeiro lugar, como é a carga de E/S xerada por etcd ao escribir en ficheiros WAL? Que chamadas de sistema se utilizan? Cal é o tamaño dos bloques de rexistro?
• En segundo lugar, digamos que temos respostas ás preguntas anteriores. Como reproducir a carga correspondente con fio? Despois de todo fio — Utilidade extremadamente flexible cunha abundancia de parámetros (isto é fácil de verificar, por exemplo, aquí - aprox. transl.).

Resolvemos ambos problemas co mesmo enfoque baseado en comandos lsof и strace:

• Con lsof pode ver todos os descritores de ficheiros utilizados polo proceso, así como os ficheiros aos que se refiren.
• Con strace pode analizar un proceso que xa está en execución ou executalo e velo. O comando mostra todas as chamadas ao sistema realizadas por este proceso e, se é necesario, os seus descendentes. Este último é importante para procesos que se bifurcan, e etcd é un destes procesos.

O primeiro que fixemos foi usar strace para examinar o servidor etcd no clúster de Kubernetes mentres estaba inactivo.

Así, descubriuse que os bloques de rexistros WAL están moi densamente agrupados, o tamaño da maioría estaba no rango de 2200-2400 bytes. É por iso que o comando ao comezo deste artigo usa a bandeira --bs=2300 (bs é o tamaño en bytes de cada bloque de escritura fio).

Teña en conta que o tamaño dos bloques de escritura etcd pode variar dependendo da versión, a implantación, os valores dos parámetros, etc. - afecta á duración fdatasync. Se tes un caso de uso similar, analiza con strace seus procesos etcd para obter valores actualizados.

Entón, para ter unha idea clara e completa de como funciona etcd co sistema de ficheiros, comezamos desde abaixo. strace con bandeiras -ffttT. Isto fixo posible capturar procesos fillos e escribir a saída de cada un nun ficheiro separado. Ademais, obtívose información detallada sobre a hora de inicio e a duración de cada chamada ao sistema.

Tamén usamos o comando lsofpara confirmar a súa comprensión da saída strace en canto a que descritor de ficheiro se utilizou para que propósito. Tiven a conclusión strace, semellante ao anterior. As manipulacións estatísticas con tempos de sincronización confirmaron que a métrica wal_fsync_duration_seconds de etcd coincide con chamadas fdatasync con descritores de ficheiros WAL.

Para xerar con fio unha carga de traballo similar á de etcd, estudouse a documentación da utilidade e seleccionáronse os parámetros axeitados para a nosa tarefa. Verificamos que as chamadas correctas do sistema están en curso e confirmamos a súa duración executando fio de strace (como se fixo no caso de etcd).

Prestouse especial atención á determinación do valor do parámetro --size. Representa a carga total de E/S xerada pola utilidade fio. No noso caso, este é o número total de bytes escritos no medio. É directamente proporcional ao número de chamadas write (e fdatasync). Para un específico bs número de chamadas fdatasync é igual size / bs.

Dado que nos interesaba o percentil, queriamos que o número de mostras fose o suficientemente grande como para ser estatisticamente significativo. E decidiu iso 10^4 (que corresponde a un tamaño de 22 MB) será suficiente. Valores de parámetros máis pequenos --size produciu un ruído máis pronunciado (por exemplo, as chamadas fdatasync, que tardan moito máis do habitual e afectan ao percentil 99).

É cousa túa

O artigo mostra como usar fio pódese xulgar se o medio destinado a usar con etcd é o suficientemente rápido. Agora tócalle a ti! Podes explorar máquinas virtuais con almacenamento baseado en SSD no servizo IBM Cloud.

PS do tradutor

Con casos de uso preparados fio Para outras tarefas, consulte documentación ou directamente a repositorios de proxectos (hai moitos máis dos que se mencionan na documentación).

PPS do tradutor

Lea tamén no noso blog:

• «etcd 3.4.3: estudo de fiabilidade e seguridade do almacenamento»;
• «A nosa experiencia con datos no clúster de etcd Kubernetes directamente (sen API K8s)»;
• «6 entretidos erros do sistema no funcionamento de Kubernetes [e a súa solución]».

Fonte: www.habr.com