Una historia corta sobre fio y etcd
Rendimiento del clúster depende en gran medida del rendimiento de su almacenamiento. etcd exporta algunas métricas a para proporcionar la información de rendimiento de almacenamiento deseada. Por ejemplo, la métrica wal_fsync_duration_seconds. : para que el almacenamiento se considere lo suficientemente rápido, el percentil 99 de esta métrica debe ser inferior a 10 ms. Si planea ejecutar un clúster etcd en máquinas Linux y desea evaluar si su almacenamiento es lo suficientemente rápido (por ejemplo, SSD), puede usar es una herramienta popular para probar operaciones de E/S. Ejecute el siguiente comando, donde test-data es el directorio bajo el punto de montaje de almacenamiento:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestBasta con mirar los resultados y comprobar que el percentil 99 de la duración menos de 10 ms. Si es así, tiene un almacenamiento razonablemente rápido. Aquí hay un ejemplo de los 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
- Hemos personalizado las opciones --size y --bs para nuestro escenario particular. Para obtener un resultado útil de fio, proporcione sus propios valores. ¿Dónde conseguirlos? Leer .
- Durante las pruebas, toda la carga de E/S proviene de fio. En un escenario de la vida real, es probable que haya otras solicitudes de escritura en el almacenamiento además de las relacionadas con wal_fsync_duration_seconds. La carga adicional aumentará el valor de wal_fsync_duration_seconds. Entonces, si el percentil 99 está cerca de los 10 ms, su almacenamiento se está quedando sin velocidad.
- Toma la versión no menos de 3.5 (los anteriores no muestran percentiles de duración de fdatasync).
- Arriba hay solo un fragmento de los resultados de fio.
Larga historia sobre fio y etcd
¿Qué es WAL en etcd?
Por lo general, las bases de datos utilizan ; etcd lo usa también. No discutiremos el registro de escritura anticipada (WAL) en detalle aquí. Nos basta con saber que cada miembro del clúster etcd lo mantiene en almacenamiento persistente. etcd escribe cada operación de clave-valor (como una actualización) en WAL antes de aplicarla a la tienda. Si uno de los miembros de almacenamiento falla y se reinicia entre instantáneas, puede restaurar localmente las transacciones desde la última instantánea por contenido WAL.
Cuando un cliente agrega una clave al almacén de clave-valor o actualiza el valor de una clave existente, etcd registra la operación en WAL, que es un archivo normal en almacenamiento persistente. etcd DEBE estar completamente seguro de que la entrada WAL realmente ocurrió antes de continuar con el procesamiento. En Linux, una llamada al sistema no es suficiente para esto. , ya que la escritura real en el almacenamiento físico puede retrasarse. Por ejemplo, Linux puede almacenar una entrada WAL en un caché en la memoria del kernel (como un caché de página) durante algún tiempo. Y para que los datos se escriban con precisión en el almacenamiento persistente, se necesita la llamada al sistema fdatasync después de la escritura, y etcd simplemente la usa (como puede ver en el resultado del trabajo , donde 8 es el descriptor del archivo 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, escribir en el almacenamiento persistente no ocurre instantáneamente. Si la llamada fdatasync es lenta, el rendimiento del sistema etcd se verá afectado. que el almacenamiento se considera lo suficientemente rápido si, en el percentil 99, las llamadas fdatasync tardan menos de 10 ms en escribirse en el archivo WAL. Hay otras métricas útiles para el almacenamiento, pero en esta publicación solo estamos hablando de esta métrica.
Estimación del almacenamiento con fio
Si necesita evaluar si su almacenamiento es adecuado para etcd, use fio, una herramienta de prueba de carga de E/S muy popular. Debe recordarse que las operaciones de disco pueden ser muy diferentes: síncronas y asíncronas, muchas clases de llamadas al sistema, etc. Como resultado, fio es bastante difícil de usar. Tiene muchos parámetros y diferentes combinaciones de sus valores producen cargas de trabajo de E/S muy diferentes. Para obtener cifras adecuadas para etcd, debe asegurarse de que la carga de escritura de prueba de fio sea lo más parecida posible a la carga real de etcd al escribir archivos WAL.
Por lo tanto, fio debe, como mínimo, crear una carga de una serie de escrituras secuenciales en el archivo, cada escritura consistirá en una llamada al sistema seguido de la llamada al sistema fdatasync. Las escrituras secuenciales en fio requieren la opción --rw=write. Para que fio use la llamada al sistema de escritura al escribir, en lugar de , debe especificar el parámetro --ioengine=sync. Finalmente, para llamar a fdatasync después de cada escritura, debe agregar el parámetro --fdatasync=1. Las otras dos opciones en este ejemplo (--size y -bs) son específicas del script. En la siguiente sección, le mostraremos cómo configurarlos.
¿Por qué exactamente fio y cómo aprendimos a configurarlo?
En este post, describimos un caso real. tenemos un racimo v1.13 que monitoreamos con Prometheus. etcd v3.2.24 estaba alojado en un SSD. Las métricas de Etcd mostraron latencias de fdatasync demasiado altas, incluso cuando el clúster no estaba haciendo nada. Las métricas eran extrañas y realmente no sabíamos lo que significaban. El clúster estaba formado por máquinas virtuales, era necesario entender cuál era el problema: en los SSD físicos o en la capa de virtualización. Además, a menudo realizábamos cambios en la configuración del hardware y el software, y necesitábamos una forma de evaluar sus resultados. Podríamos ejecutar etcd en cada configuración y mirar las métricas de Prometheus, pero eso es demasiado complicado. Estábamos buscando una forma bastante simple de evaluar una configuración específica. Queríamos verificar si entendemos correctamente las métricas de Prometheus de etcd.
Pero para ello había que resolver dos problemas. Primero, ¿cómo se ve la carga de E/S que crea etcd al escribir en WAL? ¿Qué llamadas al sistema se utilizan? ¿Cuál es el tamaño de los registros? En segundo lugar, si respondemos estas preguntas, ¿cómo reproducimos una carga de trabajo similar con fio? No olvides que fio es una herramienta muy flexible con muchas opciones. Resolvimos ambos problemas en un solo enfoque: usando los comandos и . lsof enumera todos los descriptores de archivo utilizados por el proceso y sus archivos asociados. Y con strace, puede examinar un proceso que ya se está ejecutando o iniciar un proceso y examinarlo. strace imprime todas las llamadas al sistema del proceso que se está examinando (y sus procesos secundarios). Esto último es muy importante, ya que etcd simplemente adopta un enfoque similar.
Primero usamos strace para explorar el servidor etcd para Kubernetes cuando no había carga en el clúster. Vimos que casi todos los registros WAL tenían aproximadamente el mismo tamaño: 2200–2400 bytes. Por lo tanto, en el comando al comienzo de la publicación, especificamos el parámetro -bs=2300 (bs significa el tamaño en bytes para cada entrada fio). Tenga en cuenta que el tamaño de la entrada etcd depende de la versión, la distribución, los valores de los parámetros, etc., y afecta la duración de fdatasync. Si tiene un escenario similar, examine sus procesos de etcd con strace para averiguar los números exactos.
Luego, para tener una buena idea de lo que está haciendo el sistema de archivos etcd, lo comenzamos con strace y las opciones -ffttT. Así que tratamos de examinar los procesos secundarios y registrar la salida de cada uno de ellos en un archivo separado, y también obtener informes detallados sobre el inicio y la duración de cada llamada al sistema. Usamos lsof para confirmar nuestro análisis de la salida de strace y ver qué descriptor de archivo se estaba usando para qué propósito. Entonces, con la ayuda de strace, se obtuvieron los resultados que se muestran arriba. Las estadísticas de tiempo de sincronización confirmaron que wal_fsync_duration_seconds de etcd es coherente con las llamadas fdatasync con descriptores de archivos WAL.
Revisamos la documentación de fio y elegimos opciones para nuestro script para que fio generara una carga similar a etcd. También verificamos las llamadas al sistema y su duración ejecutando fio desde strace, similar a etcd.
Hemos elegido cuidadosamente el valor del parámetro --size para representar toda la carga de E/S de fio. En nuestro caso, este es el número total de bytes escritos en el almacenamiento. Resultó ser directamente proporcional al número de llamadas al sistema de escritura (y fdatasync). Para un determinado valor de bs, el número de llamadas fdatasync = tamaño/bs. Como estábamos interesados en el percentil, teníamos que tener suficientes muestras para estar seguros, y calculamos que 10^4 sería suficiente para nosotros (eso es 22 mebibytes). Si --size es menor, pueden ocurrir valores atípicos (por ejemplo, varias llamadas a fdatasync tardan más de lo normal y afectan el percentil 99).
Inténtalo tú mismo
Le mostramos cómo usar fio y ver si el almacenamiento es lo suficientemente rápido para que etcd funcione bien. Ahora puede probarlo usted mismo utilizando, por ejemplo, máquinas virtuales con almacenamiento SSD en .
Fuente: habr.com