Una historia corta sobre fio y etcd
El rendimiento del clúster etcd depende en gran medida del rendimiento de su almacenamiento. etcd exporta algunas métricas a Prometheus para proporcionar la información necesaria sobre el rendimiento del almacenamiento. Por ejemplo, la métrica wal_fsync_duration_seconds. La documentación de etcd dice : 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 el clúster etcd en máquinas Linux y desea evaluar si su almacenamiento es lo suficientemente rápido (como SSD), puede usar fio , una herramienta popular para probar las operaciones de E / S. Ejecute el siguiente comando, donde test-data es el directorio debajo del punto de montaje de almacenamiento:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Solo necesita mirar los resultados y verificar que el percentil 99 de la duración de fdatasync sea inferior a 10 ms. Si es así, tiene un almacenamiento bastante 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 configurado las opciones --size y --bs para nuestro escenario específico. Para obtener un resultado útil de fio, ingrese sus valores. ¿Dónde conseguirlos? Lea cómo aprendimos a configurar fio .
- Durante las pruebas, toda la carga de E / S proviene de fio. En un escenario real, es probable que otras solicitudes de escritura lleguen al repositorio, excepto las relacionadas con wal_fsync_duration_seconds. La carga adicional aumentará el valor de wal_fsync_duration_seconds. Entonces, si el percentil 99 casi alcanza los 10 ms, su almacenamiento no tendrá suficiente velocidad.
- Tome la versión fio no inferior a 3.5 (las anteriores no muestran percentiles de duración de fdatasync).
- Lo anterior es solo un fragmento de los resultados de fio.
Una larga historia sobre fio y etcd
¿Qué es WAL en etcd?
Las bases de datos suelen utilizar registros de escritura anticipada ; etcd también lo usa. Aquí no discutiremos en detalle el registro de escritura anticipada (WAL). Solo necesitamos saber que cada miembro del clúster etcd lo mantiene en un almacenamiento persistente. etcd escribe cada operación de par clave-valor (por ejemplo, actualización) en el WAL antes de aplicarlas al repositorio. Si entre las instantáneas uno de los miembros de almacenamiento falla y se reinicia, puede recuperar localmente las transacciones de la última instantánea utilizando el contenido de WAL.
Cuando un cliente agrega una clave a un almacén de pares clave-valor o actualiza el valor de una clave existente, etcd registra esta operación en el WAL, que es un archivo regular en almacenamiento persistente. Antes de continuar, etcd DEBE estar completamente seguro de que la escritura al WAL realmente sucedió. En Linux, una sola llamada al sistema de escritura no es suficiente para esto, ya que la escritura en el almacenamiento físico puede retrasarse. Por ejemplo, Linux puede almacenar un registro WAL en un caché en la memoria del kernel durante algún tiempo (por ejemplo, un caché de página). Y para que los datos se escriban con precisión en el almacenamiento persistente, necesita la llamada al sistema fdatasync después de la escritura, y etcd simplemente los usa (como puede ver desde strace , donde 8 es el descriptor de archivo 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>
Desafortunadamente, escribir en el almacenamiento persistente no funciona al instante. Si la llamada fdatasync es lenta, el rendimiento del sistema etc.d cae. La documentación para etcd dice que el repositorio se considera lo suficientemente rápido si en el percentil 99 de las llamadas fdatasync se tarda menos de 10 ms en escribir en el archivo WAL. Hay otras métricas útiles para el almacenamiento, pero en esta publicación solo hablamos de esta métrica.
Evaluar el almacenamiento con fio
Si necesita evaluar si su repositorio 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íncrono y asíncrono, muchas clases de llamadas al sistema, etc. Como resultado, fio es muy difícil de usar. Tiene muchos parámetros, y diferentes combinaciones de sus valores producen cargas de trabajo de E / S completamente diferentes. Para obtener números adecuados para etcd, debe asegurarse de que la carga de grabación de prueba de fio esté lo más cerca posible de la carga real de etcd al escribir archivos WAL.
En consecuencia, fio debería al menos crear una carga en forma de una serie de operaciones de escritura secuencial en el archivo, cada registro consistirá en una llamada al sistema de escritura seguida de una llamada al sistema fdatasync. Para operaciones de escritura secuencial, fio necesita la opción --rw = write. Para que fio use la llamada al sistema de escritura en lugar de pwrite al grabar, vale la pena especificar el parámetro --ioengine = sync. Finalmente, para que se llame a fdatasync después de cada entrada, debe agregar el parámetro --fdatasync = 1. Las otras dos opciones en este ejemplo (--size y --bs) son específicas del escenario. En la siguiente sección, le mostraremos cómo configurarlos.
Por qué fio y cómo aprendimos a configurarlo
En esta publicación describimos el caso real. Teníamos un clúster Kubernetes v1.13 , que monitoreamos usando Prometheus. etcd v3.2.24 fue alojado en un SSD. Las métricas de Etcd mostraron latencias demasiado altas para fdatasync, 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 consistía en máquinas virtuales, había que entender cuál era el problema: en SSD físicos o en la capa de virtualización. Además, a menudo realizamos cambios en la configuración de hardware y software, y necesitábamos una forma de evaluar sus resultados. Podríamos ejecutar etcd en cada configuración y ver las métricas de Prometheus, pero esto es demasiado problemático. Estábamos buscando una forma bastante simple de evaluar una configuración específica. Queríamos verificar si entendíamos las métricas de Prometheus de etcd correctamente.
Pero para esto era necesario resolver dos problemas. Primero, ¿cómo se ve la carga de E / S que etcd crea al escribir en el 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 reproduzco una carga de trabajo similar con fio? No olvides que fio es una herramienta muy flexible con muchas opciones. Resolvimos ambos problemas con un enfoque: usar los comandos lsof y strace . lsof muestra todos los descriptores de archivo utilizados por el proceso y sus archivos asociados. Y con strace, puede estudiar un proceso que ya se está ejecutando o iniciar un proceso y estudiarlo. strace muestra todas las llamadas al sistema del proceso que se está estudiando (y sus procesos secundarios). Esto último es muy importante, ya que etcd simplemente adopta un enfoque similar.
En primer lugar, usamos strace para aprender 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 de fio). Tenga en cuenta que el tamaño de la entrada etcd depende de la versión de etcd, la entrega, los valores de los parámetros, etc., y afecta la duración de fdatasync. Si tiene un escenario similar, examine sus procesos etcd con strace para encontrar los números exactos.
Luego, para tener una buena idea de las acciones en el sistema de archivos etcd, comenzamos con strace y con las opciones -ffttT. Así que tratamos de estudiar los procesos secundarios y escribir 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 salida de strace y ver qué descriptor de archivo se usó para qué propósito. Entonces con strace obtuvimos los resultados que se muestran arriba. Las estadísticas sobre el tiempo de sincronización confirmaron que el indicador wal_fsync_duration_seconds de etcd corresponde a llamadas fdatasync con descriptores de archivo WAL.
Estudiamos la documentación de fio y seleccionamos las 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.
Seleccionamos cuidadosamente el valor del parámetro --size, que representa la carga de E / S completa 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 de escritura (y fdatasync) del sistema. Para un valor bs específico, el número de llamadas a fdatasync = size / bs. Como estábamos interesados en el percentil, deberíamos haber tenido suficientes muestras para la confiabilidad, y calculamos que 10 ^ 4 serían suficientes para nosotros (obtenemos 22 mebibytes). Si --size es más pequeño, pueden ocurrir valores atípicos (por ejemplo, varias llamadas fdatasync funcionan más de lo habitual y afectan el percentil 99).
Pruébalo tú mismo
Mostramos cómo usar fio y averiguar si el almacenamiento tiene suficiente velocidad para un alto rendimiento, etc. Ahora puede probarlo en la práctica por su cuenta, utilizando, por ejemplo, máquinas virtuales con almacenamiento SSD en IBM Cloud .