🥇Consejos y trucos para trabajar con Ceph en proyectos exigentes

Al utilizar Ceph como almacenamiento en red en proyectos con diferentes niveles de carga, podemos enfrentar diversas tareas que, a primera vista, no parecen simples o triviales. Por ejemplo:

la migración de datos de un Ceph antiguo a uno nuevo con el uso parcial de los servidores anteriores en el nuevo clúster;
la solución al problema de la distribución del espacio en disco en Ceph.

Al abordar estas tareas, nos encontramos con la necesidad de extraer correctamente el OSD sin pérdida de datos, lo cual es especialmente relevante cuando se manejan grandes volúmenes de información. De esto trata el artículo.

Los métodos descritos a continuación son aplicables a todas las versiones de Ceph. Además, se tendrá en cuenta que Ceph puede almacenar grandes volúmenes de datos: para prevenir pérdidas de datos y otros problemas, algunas acciones se dividirán en varias.

Prefacio sobre OSD

Dado que dos de las tres recetas que se consideran están dedicadas al OSD (Object Storage Daemon), antes de profundizar en la parte práctica, daremos un breve resumen de qué es realmente en Ceph y por qué es tan importante.

En primer lugar, es importante decir que todo el clúster de Ceph está compuesto por múltiples OSD. Cuantos más haya, mayor será el volumen de datos libre en Ceph. De aquí se puede entender la función principal del OSD: almacena los datos de los objetos Ceph en los sistemas de archivos de todos los nodos del clúster y proporciona acceso de red a ellos (para lectura, escritura y otras solicitudes).

En este mismo nivel se establecen los parámetros de replicación mediante la copia de objetos entre diferentes OSD. Y aquí se pueden presentar diversos problemas, cuya solución se discutirá a continuación.

Caso No. 1. Extracción segura de OSD del clúster Ceph sin pérdida de datos

La necesidad de extraer un OSD puede ser causada por la retirada de un servidor del clúster — por ejemplo, para sustituirlo por otro servidor — lo que ocurrió en nuestro caso y dio lugar a la redacción de este artículo. Así, el objetivo final de las manipulaciones es extraer todos los OSD y mon's en este servidor para poder detenerlo.

Para comodidad y para evitar la situación en la que cometamos un error al especificar el OSD deseado durante la ejecución de los comandos, definiremos una variable separada cuyo valor será el número del OSD a eliminar. La llamaremos ${ID} — aquí y en adelante, tal variable reemplaza el número del OSD con el que estamos trabajando.

Veamos el estado antes de comenzar los trabajos:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Para iniciar la eliminación del OSD, será necesario hacerlo de manera gradual reweight en él hasta cero. De esta manera, reducimos la cantidad de datos en el OSD mediante el balanceo hacia otros OSD. Para esto se ejecutan los siguientes comandos:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… y así sucesivamente hasta llegar a cero.

El balanceo gradual es necesario, para no perder datos. Esto es especialmente relevante si el OSD contiene una gran cantidad de datos. Para asegurarse de que después de ejecutar los comandos reweight todo haya salido bien, se puede ejecutar ceph -s o abrir en una ventana de terminal separada ceph -w para observar los cambios en tiempo real.

Cuando el OSD está "vacío", se puede proceder a la operación estándar de su eliminación. Para ello, llevemos el OSD necesario al estado down:

ceph osd down osd.${ID}

Sacaremos el OSD del clúster:

ceph osd out osd.${ID}

Detendremos el servicio OSD y desmontaremos su partición en el FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Eliminaremos el OSD de CRUSH map:

ceph osd crush remove osd.${ID}

Eliminaremos el usuario OSD:

ceph auth del osd.${ID}

Y, finalmente, eliminaremos el propio OSD:

ceph osd rm osd.${ID}

Nota: si usas la versión Ceph Luminous o superior, las acciones de eliminación de OSD descritas anteriormente se pueden reducir a dos comandos:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Si después de ejecutar las acciones anteriores se ejecuta el comando ceph osd tree, debería ser visible que en el servidor donde se realizaron las operaciones ya no hay OSD para los que se llevaron a cabo las acciones anteriores:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Aprovechamos para notar que el estado del clúster Ceph pasará a HEALTH_WARN, y también veremos la disminución en el número de OSD y en la cantidad de espacio en disco disponible.

A continuación, se describirán las acciones que serán necesarias si deseas detener completamente el servidor y, por consiguiente, eliminarlo de Ceph. En tal caso, es importante recordar que antes de apagar el servidor, es necesario extraer todos los OSD de este servidor.

Si no quedan más OSD en este servidor, entonces después de eliminarlos hay que excluir del mapa OSD el servidor hv-2, ejecutando el siguiente comando:

ceph osd crush rm hv-2

Eliminamos mon del servidor hv-2, ejecutando el siguiente comando en otro servidor (es decir, en este caso — en hv-1):

ceph-deploy mon destroy hv-2

Después de esto, se puede detener el servidor y proceder con las siguientes acciones (su reimplementación, etc.).

Caso n.º 2. Distribución del espacio en disco en un clúster Ceph ya creado.

Comenzaré la segunda historia con una introducción sobre PG (Grupos de Colocación). El papel principal de PG en Ceph es, primero que nada, agregar los objetos de Ceph y luego replicarlos en OSD. La fórmula que se puede utilizar para calcular la cantidad necesaria de PG se encuentra en la sección correspondiente la documentación de Ceph. Allí también se analiza esta cuestión con ejemplos concretos.

Así que: uno de los problemas comunes durante la operación de Ceph es el número desbalanceado de OSD y PG entre los grupos en Ceph.

En primer lugar, esto puede dar lugar a una situación en la que se especifica un número demasiado grande de PG en un grupo de bajo volumen, lo que en esencia es un uso irracional del espacio en disco en el clúster. En segundo lugar, en la práctica surge un problema más serio: el desbordamiento de datos en uno de los OSD. Esto lleva al clúster primero a un estado HEALTH_WARN, y luego a HEALTH_ERR. La culpa es de que Ceph, al calcular el volumen de datos disponible (se puede averiguar por MAX AVAIL en la salida del comando ceph df para cada grupo por separado) se basa en el volumen de datos disponible en OSD. Si al menos en un OSD no hay suficiente espacio, entonces no se podrá escribir más datos hasta que los datos se distribuyan adecuadamente entre todos los OSD.

Es importante aclarar que estos problemas se resuelven en mayor medida en la etapa de configuración del clúster Ceph.Una de las herramientas que se puede utilizar es Ceph PGCalc. Con su ayuda se calcula de manera visual la cantidad necesaria de PG. Sin embargo, también se puede recurrir a ella en caso de que el clúster Ceph (envío de datos). esté configurado incorrectamente. Aquí vale la pena aclarar que en el marco de los trabajos de corrección, probablemente necesitarás reducir la cantidad de PG, y esta opción no está disponible en las versiones antiguas de Ceph (solo apareció a partir de la versión Nautilus).

Así que, imaginemos la siguiente situación: el clúster tiene un estado HEALTH_WARN debido a que se está quedando sin espacio en uno de los OSD. Esto se indicará con el error HEALTH_WARN: 1 near full osd. A continuación se presenta un algoritmo para salir de esta situación.

Primero se requiere distribuir los datos existentes entre los otros OSD. Una operación similar ya la realizamos en el primer caso, cuando "deshidratamos" el nodo, con la única diferencia de que ahora será necesario reducir ligeramente. reweight. Por ejemplo, a 0.95:

ceph osd reweight osd.${ID} 0.95

De esta manera, se libera espacio en disco en el OSD y se corrige el error en ceph health. Sin embargo, como se mencionó, este problema surge principalmente debido a una configuración incorrecta de Ceph en las etapas iniciales: es muy importante realizar la reconfiguración para que no se manifieste en el futuro.

En nuestro caso específico, todo se reducía a:

un valor demasiado alto replication_count en uno de los pools,
demasiado alto número de PG en un pool y demasiado bajo en otro.

Usaremos la calculadora mencionada anteriormente. En ella se muestra claramente qué se necesita ingresar y, en principio, no hay nada complicado. Al establecer los parámetros necesarios, obtenemos las siguientes recomendaciones:

Nota: si estás configurando un clúster Ceph desde cero, otra función útil de la calculadora será la generación de comandos que crearán pools desde cero con los parámetros indicados en la tabla.

El último columna ayuda a orientarse — Suggested PG Count. En nuestro caso, también es útil la segunda, donde se indica el parámetro de replicación, ya que hemos decidido cambiar el multiplicador de replicación.

Entonces, primero necesitaremos cambiar los parámetros de replicación — esto es lo que se debe hacer primero, ya que, al reducir el multiplicador, liberaremos espacio en disco. Durante la ejecución del comando, se puede notar que el valor del espacio de disco disponible aumentará:

ceph osd pool $pool_name set $replication_size

Y después de que se complete, cambiamos los valores de los parámetros pg_num y pgp_num de la siguiente manera:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Importante: debemos cambiar secuencialmente el número de PG en cada pool y no cambiar los valores en otros pools hasta que desaparezcan las advertencias "Degraded data redundancy" y "n-number of pgs degraded".

Se puede verificar que todo haya salido bien también con la salida de los comandos ceph health detail y ceph -s.

Caso №3. Migración de una máquina virtual de LVM a Ceph RBD

En situaciones donde se utilizan máquinas virtuales instaladas en servidores bare-metal alquilados, a menudo surge la cuestión del almacenamiento tolerante a fallos. Además, es muy deseable que haya suficiente espacio en dicho almacenamiento... Otra situación común es tener una máquina virtual con almacenamiento local en el servidor y necesitar expandir el disco, pero no hay a dónde, ya que no queda espacio en disco disponible en el servidor.

El problema se puede resolver de diferentes maneras, por ejemplo, mediante la migración a otro servidor (si existe) o agregando nuevos discos al servidor. Pero no siempre es posible hacerlo, por lo que la migración de LVM a Ceph puede ser una excelente solución para este problema. Al elegir esta opción, también simplificamos el proceso de migración entre servidores, ya que no será necesario mover el almacenamiento local de un hipervisor a otro. El único inconveniente es que será necesario detener la VM durante el tiempo de trabajo.

Como receta presentada a continuación se toma un artículo de este blog, cuyas instrucciones han sido probadas en acción. Cabe mencionar que también se describe allí un método de migración sin interrupciones, sin embargo, en nuestro caso simplemente no fue necesario, por lo que no lo probamos. Si esto es crítico para su proyecto, estaremos encantados de conocer los resultados en los comentarios.

Pasemos a la parte práctica. En el ejemplo utilizamos virsh y, por lo tanto, libvirt. Primero asegúrese de que el pool de Ceph al que se migrarán los datos esté conectado a libvirt:

virsh pool-dumpxml $ceph_pool

La descripción del pool debe contener los datos de conexión a Ceph junto con los datos de autenticación.

El siguiente paso implica que la imagen de LVM se convierte a Ceph RBD. El tiempo de ejecución depende principalmente del tamaño de la imagen:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Después de la conversión, quedará la imagen de LVM, que será útil en caso de que no se pueda migrar la VM a RBD y sea necesario revertir los cambios. También, para la posibilidad de revertir rápidamente los cambios, haremos una copia de seguridad del archivo de configuración de la máquina virtual:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… y editaremos el original (vm_name.xml). Buscaremos el bloque que describe el disco (comienza con la línea <disk type='file' device='disk'> y termina en </disk>) y lo llevaremos a la siguiente forma:

\n
  \n \n
  \n  \n\n 
\n\n

Analicemos algunos detalles:

En el protocolo source se indica la dirección del almacenamiento en Ceph RBD (esta es la dirección con el nombre del pool Ceph y la imagen RBD definida en la primera etapa).
En el bloque secret se especifica el tipo ceph, así como el UUID del secreto para conectarse a él. Su UUID se puede obtener con el comando virsh secret-list.
En el bloque host se indican las direcciones de los monitores Ceph.

Después de editar el archivo de configuración y completar la conversión de LVM a RBD, se puede aplicar el archivo de configuración modificado y arrancar la máquina virtual:

virsh define $vm_name.xml\nvirsh start $vm_name

Es un buen momento para verificar que la máquina virtual se ha iniciado correctamente: esto se puede saber, por ejemplo, conectándose a ella por SSH o a través de virsh.

Si la máquina virtual funciona correctamente y no ha encontrado otros problemas, se puede eliminar la imagen LVM que ya no se usa:

lvremove main/$vm_image_name

Conclusión

Hemos encontrado todas las situaciones descritas en la práctica; esperamos que las instrucciones ayuden a otros administradores a resolver problemas similares. Si tiene comentarios o historias similares de su experiencia con Ceph, ¡nos encantaría verlas en los comentarios!