Ceph: El maldito deep scrubbing

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!

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *

Aquest lloc utilitza Akismet per reduir els comentaris brossa. Apreneu com es processen les dades dels comentaris.