Usando Ceph como almacenamiento de red en diferentes proyectos de carga de trabajo, podemos encontrar varias tareas que a primera vista no parecen simples o triviales. Por ejemplo:- migración de datos de Ceph antiguo a nuevo con uso parcial de servidores anteriores en el nuevo clúster;
- solución del problema de distribución de espacio en disco en Ceph.
Enfrentando tales tareas, nos enfrentamos a la necesidad de extraer correctamente el OSD sin pérdida de datos, lo cual es especialmente cierto para grandes cantidades de datos. Esto se discutirá en el artículo.Los métodos descritos a continuación son relevantes para cualquier versión de Ceph. Además, se tendrá en cuenta el hecho de que se puede almacenar una gran cantidad de datos en Ceph: para evitar la pérdida de datos y otros problemas, algunas acciones se "dividirán" en varias otras.Prefacio de OSD
Dado que dos de las tres recetas en consideración están dedicadas a OSD ( Object Storage Daemon ), antes de sumergirse en la parte práctica, brevemente sobre qué es en Ceph y por qué es tan importante.En primer lugar, debe decirse que todo el clúster Ceph consta de muchos OSD. Cuantos más haya, mayor será el volumen de datos libres en Ceph. Desde aquí es fácil comprender la función principal de OSD : guarda los datos de objetos Ceph en los sistemas de archivos de todos los nodos del clúster y les proporciona acceso de red (para leer, escribir y otras solicitudes).En el mismo nivel, los parámetros de replicación se establecen copiando objetos entre diferentes OSD. Y aquí puede encontrar varios problemas, cuya solución se discutirá más adelante.Caso No. 1. Recupere OSD de forma segura del clúster Ceph sin pérdida de datos
La necesidad de eliminar el OSD puede deberse a la retirada del servidor del clúster, por ejemplo, para reemplazarlo por otro servidor, lo que sucedió con nosotros y dio lugar a la redacción del artículo. Por lo tanto, el objetivo final de la manipulación es extraer todos los OSD y mones en un servidor determinado para que pueda detenerse.Por conveniencia y eliminación de la situación en la que, en el proceso de ejecución de comandos, cometemos un error al indicar la OSD necesaria, estableceremos una variable separada, cuyo valor será el número de OSD que se eliminará. Lo llamaremos ${ID}, en adelante, dicha variable reemplaza el número OSD con el que trabajamos.Veamos la condición antes de comenzar a trabajar:root@hv-1 ~
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 de OSD, deberá ejecutarlo sin problemas reweighten cero. Por lo tanto, reducimos la cantidad de datos en el OSD al equilibrarlo con otros OSD. Para hacer 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 a cero.ACTUALIZADO : Los comentarios sobre el artículo hablaron sobre el método con norebalance+ backfill. La solución es correcta, pero antes que nada debe analizar la situación, porque la norebalanceusamos cuando no queremos que ningún OSD provoque una carga en la red. osd_max_backfillusado en casos donde es necesario limitar la velocidad del reequilibrio. Como resultado, el reequilibrio será más lento y causará menos carga de red.Un equilibrio suave es necesario para no perder datos. Esto es especialmente cierto si el OSD contiene una gran cantidad de datos. Para asegurarse de que reweighttodo fue exitoso después de ejecutar los comandos , puede ejecutarlo ceph -so ejecutarlo en una ventana de terminal separadaceph -wpara observar cambios en tiempo real.Cuando el OSD está "vacío", puede comenzar la operación estándar para eliminarlo. Para hacer esto, coloque el OSD deseado en el estado down:ceph osd down osd.${ID}
"Extraer" OSD del clúster:ceph osd out osd.${ID}
Detenga el servicio OSD y desmonte su partición en el FS:systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}
Elimine la OSD del mapa CRUSH :ceph osd crush remove osd.${ID}
Eliminar el usuario OSD:ceph auth del osd.${ID}
Y finalmente, elimine el OSD en sí:ceph osd rm osd.${ID}
Nota : si está utilizando Ceph Luminous o superior, los pasos anteriores para eliminar OSD se pueden reducir a dos comandos:ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Si, después de realizar los pasos anteriores, se ejecuta el comando ceph osd tree, debería verse que el servidor donde se realizó el trabajo ya no tiene el OSD para el que se realizaron las operaciones anteriores:root@hv-1 ~
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
En el camino, notamos que el estado del clúster Ceph entrará HEALTH_WARN, y también veremos una disminución en el número de OSD y la cantidad de espacio disponible en disco.A continuación, se describirán los pasos que se requerirán si desea detener completamente el servidor y, en consecuencia, eliminarlo de Ceph. En este caso, es importante recordar que antes de apagar el servidor, debe extraer todos los OSD en este servidor.Si no queda más OSD en este servidor, luego de eliminarlos, debe excluir el servidor de la tarjeta OSD hv-2ejecutando el siguiente comando:ceph osd crush rm hv-2
Lo eliminamos mondel servidor hv-2ejecutando el siguiente comando en otro servidor (es decir, en este caso, en hv-1):ceph-deploy mon destroy hv-2
Después de eso, puede detener el servidor y continuar con las acciones posteriores (su redistribución, etc.).Caso No. 2. Asignación de espacio en disco en un clúster Ceph ya creado
La segunda historia comienza con un prefacio sobre PG ( Grupos de ubicación ). El papel principal de PG en Ceph es principalmente en la agregación de objetos Ceph y su posterior replicación en OSD. La fórmula con la que puede calcular el número requerido de PG se puede encontrar en la sección correspondiente de la documentación de Ceph. En el mismo lugar, este problema también se analizó con ejemplos específicos.Entonces: uno de los problemas comunes durante la operación de Ceph es una cantidad desequilibrada de OSD y PG entre grupos en Ceph. En general, un valor correctamente seleccionado de PG es la clave para el funcionamiento confiable del clúster, y luego consideraremos lo que puede suceder en el caso contrario.La dificultad para elegir la cantidad correcta de PG radica en dos cosas:- PG, , , chunk'.
- , , PG, .
En la práctica, se obtiene un problema más grave: desbordamiento de datos en uno de los OSD. La razón de esto es que Ceph, al calcular la cantidad de datos disponibles (puede encontrarlo MAX AVAILen la salida del comando ceph dfpara cada grupo por separado), se basa en la cantidad de datos disponibles en OSD. Si no hay suficiente espacio en al menos un OSD, escribir más datos no funcionará hasta que los datos se distribuyan correctamente entre todos los OSD.Vale la pena aclarar que estos problemas se resuelven en gran medida en la etapa de configuración del clúster Ceph . Una herramienta que puede usar es Ceph PGCalc . Con su ayuda, se calcula visualmente la cantidad necesaria de PG. Sin embargo, puede recurrir a él en una situación en la que el clúster Ceph ya estáno configurado correctamente Aquí vale la pena aclarar que, como parte del trabajo de corrección, lo más probable es que necesite reducir el número de PG, y esta función no está disponible en versiones anteriores de Ceph (apareció solo con la versión Nautilus ).Entonces, imaginemos la siguiente imagen: un clúster tiene un estado HEALTH_WARNdebido al final de un lugar en uno de los OSD. Un error lo atestiguará HEALTH_WARN: 1 near full osd. A continuación se muestra un algoritmo para superar esta situación.En primer lugar, debe distribuir los datos disponibles entre el resto de la OSD. Ya realizamos una operación similar en el primer caso, cuando "drenamos" el nudo, con la única diferencia que ahora tendrá que reducirse ligeramente reweight. Por ejemplo, antes de 0.95:ceph osd reweight osd.${ID} 0.95
Esto libera espacio en disco en el OSD y corrige un error en la salud ceph. Sin embargo, como ya se mencionó, este problema surge principalmente debido a la configuración incorrecta de Ceph en las etapas iniciales: es muy importante reconfigurar para que no aparezca en el futuro.En nuestro caso particular, todo se basaba en:- demasiado importante
replication_counten una de las piscinas, - Demasiados PG en un grupo y demasiado pequeños en otro.
Utilizaremos la calculadora ya mencionada. Muestra claramente lo que debe ingresarse y, en principio, no hay nada complicado. Una vez establecidos los parámetros necesarios, obtenemos las siguientes recomendaciones:Nota : si configura el clúster Ceph desde cero, otra función útil de la calculadora será la generación de comandos que crearán grupos desde cero con los parámetros enumerados en la tabla.La última columna, Cuenta de PG sugerida, lo ayuda a navegar . En nuestro caso, el segundo también es útil, donde se indica el parámetro de replicación, ya que decidimos cambiar el factor de replicación.Entonces, primero debe cambiar la configuración de replicación; vale la pena hacerlo primero, ya que al reducir el multiplicador liberaremos espacio en disco. Durante la ejecución del comando, notará que el valor del espacio disponible en disco aumentará:ceph osd pool $pool_name set $replication_size
Y después de su finalización, cambiamos los valores de los parámetros pg_numy de la pgp_numsiguiente 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 grupo y no cambiar los valores en otros grupos hasta que desaparezcan las advertencias "Redundancia de datos degradada" y "n-número de pgs degradados" .También puede verificar que todo fue exitoso, de acuerdo con las conclusiones de los comandos ceph health detaily ceph -s.Caso No. 3. Migración de máquina virtual de LVM a Ceph RBD
En una situación en la que el proyecto utiliza máquinas virtuales instaladas en servidores alquilados de metal desnudo, a menudo surge la cuestión del almacenamiento tolerante a fallas. Y también es muy deseable que haya suficiente espacio en este almacenamiento ... Otra situación común: hay una máquina virtual con almacenamiento local en el servidor y necesita expandir el disco, pero en ninguna parte, porque no queda espacio libre en el servidor.El problema se puede resolver de diferentes maneras, por ejemplo, migrando a otro servidor (si hay uno) o agregando nuevos discos al servidor. Pero no siempre es posible hacer esto, por lo que la migración de LVM a Ceph puede ser una excelente solución a este problema. Al elegir esta opción, también simplificamos el proceso adicional de migración entre servidores, ya que no será necesario mover el almacenamiento local de un hipervisor a otro. El único inconveniente es que tendrá que detener la VM mientras dure el trabajo.Como se indica en la receta a continuación, se tomó un artículo de este blog , cuyas instrucciones se probaron en acción. Por cierto, el método de migración sin obstáculos también se describe allí.Sin embargo, en nuestro caso, simplemente no era necesario, por lo que no lo verificamos. Si esto es crítico para su proyecto, nos complacerá saber los resultados en los comentarios.Pasemos a la parte práctica. En el ejemplo, usamos virsh y, en consecuencia, libvirt. Primero, asegúrese de que el grupo Ceph al que se migrarán los datos esté conectado a libvirt:virsh pool-dumpxml $ceph_pool
La descripción del grupo debe contener datos de conexión Ceph con datos de autorización.El siguiente paso es convertir la imagen LVM 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, la imagen LVM permanecerá, lo que será útil si no puede migrar la VM a RBD y tiene que revertir los cambios. Además, para poder revertir rápidamente los cambios, realizaremos 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 edite el original ( vm_name.xml). Busque un bloque con una descripción del disco (comienza con una línea <disk type='file' device='disk'>y termina con </disk>) y llévelo al siguiente formulario:<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
Echemos un vistazo a algunos de los detalles:- El protocolo
sourceindica la dirección del almacenamiento en Ceph RBD (esta es la dirección que indica el nombre del grupo Ceph y la imagen RBD, que se determinó en la primera etapa). - El bloque
secretindica el tipo ceph, así como el UUID del secreto para conectarse a él. Su uuid se puede encontrar con el comando virsh secret-list. - En el bloque
hostse indican las direcciones a los monitores Ceph.
Después de editar el archivo de configuración y completar la conversión de LVM a RBD, puede aplicar el archivo de configuración modificado e iniciar la máquina virtual:virsh define $vm_name.xml
virsh start $vm_name
Es hora de verificar que la máquina virtual se inició correctamente: puede averiguarlo, por ejemplo, conectándose a través de SSH o mediante virsh.Si la máquina virtual funciona correctamente y no encontró otros problemas, puede eliminar la imagen LVM que ya no está en uso:lvremove main/$vm_image_name
Conclusión
En la práctica, encontramos todos los casos descritos; esperamos que las instrucciones ayuden a otros administradores a resolver problemas similares. Si tiene comentarios u otras historias similares de la experiencia operativa de Ceph, ¡nos complacerá verlos en los comentarios!PD
Lea también en nuestro blog: