Si has llegado aquí es que estás buscando ¿qué coño es esto del deep scrubbing? y es que no hay sólo deep scrubbing, sino que ¡hay también otro! el scrubbing a secas. Si aún no has llegado aquí te lo cuento.
En ceph hay los pg, que vendrían a ser las unidades de datos dentro de ceph. En estas unidades de dados es realmente donde se almacena la información y una forma de verlos sería como ficheros o volúmenes de datos.
Para que los datos sean coherentes entre los distintos servidores, ceph hace scrubbing y deep scrubbing. Aquí lo explican muy bien.
En resumen sería
- scrubbing (a secas). captura los errores del OSD o del sistema de ficheros. Este proceso suele ser ligero y no generar un gran impacto en la lectura y escritura de disco (iout o io)
- deep scrubbing, compara los datos de los objetos PG, bit a bit. Busca sectores defectuosos en los discos. Este proceso genera un I/O alto.
Una cosa que ya he identificado es que un I/O alto afecta al rendimiento de todo el sistema. Hace que todo vaya leeeeentooooo, que mover ficheros de un lugar a otro sea un supliciooooo….
Desde que actualicé de proxmox 6 a proxmox 7 y actualizando la versión del ceph, todo ha ido empeorando con el paso de los días. He comprado un switch mikrotik con 8 puertos de fibra de 10G y a ver si con las tarjetas de red de 10Gb de fibra y los SFP finisar de 4.25Gb consigo mejorar la performance.
Pero justo ahora, otra noche trasnochando mas (de nuevo), me encuentro que de repente uno de los servicios empieza a funcionar terriblemente lento. Coincidencia con el inicio de los backups? ¿pero por qué en otras horas no sucede?, ¿y por qué ahora éste active+clean+scrubbing+deep:1 otra vez!?, ¡si hace un rato todo estaba funcionando de forma bastante ágil!
Investigando he encontrado con el link anterior y este otro en esta página que me ha dado una posible solución (ya para la siguiente noche) haciendo referencia a estos dos parametros:
# ceph config set osd osd_scrub_begin_hour 23 # ceph config set osd osd_scrub_end_hour 6
¡AAAh Hamigo! ¿Me estás diciendo que hay algo que genera un io-wait alto, ejecutándose a la misma hora que se ejecutan los backups? Espera, espera, esto no debería ser así.
Para sacar los valores por defecto de la configuración usaremos (dejo los que nos interesan ahora):
root@planet2A:~# ceph config ls |grep scrub |grep scrub mon_scrub_interval mon_scrub_timeout osd_max_scrubs osd_scrub_begin_hour osd_scrub_end_hour osd_scrub_begin_week_day osd_scrub_end_week_day
Para ver el valor definido para cada una de las configuraciones
root@planet2A:~# ceph config show osd.1 osd_scrub_begin_hour 0 root@planet2A:~# ceph config show osd.1 osd_scrub_end_hour 24 root@planet2A:~# ceph config show osd.1 osd_scrub_begin_week_day 0 root@planet2A:~# ceph config show osd.1 osd_scrub_end_week_day 0
¿Solución?
root@planet2A:~# ceph config set osd osd_scrub_begin_hour 5 root@planet2A:~# ceph config set osd osd_scrub_end_hour 10
Los otros dos parámetros los dejo a 0 que significa “cada día”. Ayuda:
root@planet2A:~# ceph config help osd_scrub_begin_week_day osd_scrub_begin_week_day - Restrict scrubbing to this day of the week or later (int, advanced) Default: 0 Minimum: 0 Maximum: 6 Can update at runtime: true See also: [osd_scrub_end_week_day] 0 = Sunday, 1 = Monday, etc. Use osd_scrub_begin_week_day=0 osd_scrub_end_week_day=0 for the entire week.
Ahora a ver que tal va la cosa 🙂 ¡Muy contenta de haber encontrado esta posible solución a la lentitud de mis sistemas!
Fuente obtenida de: https://blackhold.nusepas.com/2021/11/20/ceph-el-maldito-deep-scrubbing/
