Utilizando Ceph como almacenamiento de red en proyectos con diferentes cargas, podemos encontrarnos con diversas tareas que a primera vista no parecen sencillas ni triviales. Por ejemplo:
- migración de datos del antiguo Ceph al nuevo con uso parcial de los servidores anteriores en el nuevo clúster;
- solución al problema de asignación de espacio en disco en Ceph.
Al afrontar este tipo de problemas, nos enfrentamos a la necesidad de eliminar correctamente el OSD sin perder datos, lo cual es especialmente importante cuando se trata de grandes cantidades de datos. Esto se discutirá en el artículo.
Los métodos que se describen a continuación son relevantes para cualquier versión de Ceph. Además, se tendrá en cuenta el hecho de que Ceph puede almacenar una gran cantidad de datos: para evitar la pérdida de datos y otros problemas, algunas acciones se “dividirán” en varias otras.
Prefacio sobre OSD
Dado que dos de las tres recetas comentadas están dedicadas a OSD (), antes de sumergirnos en la parte práctica: brevemente sobre qué es Ceph y por qué es tan importante.
En primer lugar, hay que decir que todo el clúster de Ceph consta de muchos OSD. Cuantos más haya, mayor será el volumen de datos gratuitos en Ceph. Es fácil de entender desde aquí. función OSD principal: Almacena datos de objetos Ceph en los sistemas de archivos de todos los nodos del clúster y proporciona acceso a la red (para lectura, escritura 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, cuyas soluciones se analizarán a continuación.
Caso No. 1. Elimine OSD de forma segura del clúster Ceph sin perder datos
La necesidad de eliminar el OSD puede deberse a la eliminación del servidor del clúster, por ejemplo, para reemplazarlo con otro servidor, que es lo que nos sucedió y motivó la redacción de este artículo. Por lo tanto, el objetivo final de la manipulación es extraer todos los OSD y mons de un servidor determinado para poder detenerlo.
Por conveniencia y para evitar una situación en la que cometamos un error al especificar el OSD requerido mientras ejecutamos comandos, estableceremos una variable separada, cuyo valor será el número del OSD que se eliminará. llamémosla ${ID} — aquí y abajo, dicha variable reemplaza el número del OSD con el que estamos trabajando.
Veamos la condición antes de comenzar a trabajar:
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 de OSD, deberá realizar sin problemas reweight a cero. De esta manera reducimos la cantidad de datos en el OSD equilibrándolos con otros OSD. Para hacer esto, ejecute 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í hasta cero.
Se requiere un equilibrio suavepara no perder datos. Esto es especialmente cierto si el OSD contiene una gran cantidad de datos. Para asegurarse de que después de ejecutar los comandos reweight Todo salió bien, puedes completarlo. ceph -s o en una ventana de terminal separada, ejecute ceph -w para observar los cambios en tiempo real.
Cuando el OSD esté "vaciado", puede continuar con la operación estándar para eliminarlo. Para hacer esto, transfiera el OSD deseado al estado down:
ceph osd down osd.${ID}"Saquemos" el OSD del clúster:
ceph osd out osd.${ID}Detengamos el servicio OSD y desmontemos su partición en el FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Quitar OSD de :
ceph osd crush remove osd.${ID}Eliminemos el usuario de OSD:
ceph auth del osd.${ID}Y finalmente, eliminemos el OSD en sí:
ceph osd rm osd.${ID}Nota: Si está utilizando la versión Ceph Luminous o superior, los pasos de eliminación de OSD anteriores se pueden reducir a dos comandos:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Si, después de completar los pasos descritos anteriormente, ejecuta el comando ceph osd tree, entonces debe quedar claro que en el servidor donde se realizó el trabajo ya no hay OSD para los cuales se realizaron las operaciones 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
En el camino, tenga en cuenta que el estado del clúster Ceph pasará a HEALTH_WARN, y también veremos una disminución en la cantidad de OSD y la cantidad de espacio disponible en disco.
A continuación se describirán los pasos que serán necesarios 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 eliminar todos los OSD en este servidor.
Si no quedan más OSD en este servidor, después de eliminarlos, deberá excluir el servidor del mapa OSD. hv-2ejecutando el siguiente comando:
ceph osd crush rm hv-2
Eliminar mon desde el servidor hv-2ejecutando el siguiente comando en otro servidor (es decir, en este caso, en hv-1):
ceph-deploy mon destroy hv-2Después de esto, puede detener el servidor y comenzar acciones posteriores (volver a implementarlo, etc.).
Caso No. 2. Distribución de espacio en disco en un clúster Ceph ya creado
Comenzaré la segunda historia con un prefacio sobre PG (). La función principal de PG en Ceph es principalmente agregar objetos Ceph y replicarlos en OSD. La fórmula con la que puedes calcular la cantidad requerida de PG se encuentra en Documentación Ceph. Esta cuestión también se analiza allí con ejemplos específicos.
Entonces: uno de los problemas comunes al usar Ceph es el número desequilibrado de OSD y PG entre grupos en Ceph.
En primer lugar, debido a esto, puede surgir una situación en la que se especifican demasiadas PG en un grupo pequeño, lo que es esencialmente un uso irracional del espacio en disco del clúster. En segundo lugar, en la práctica surge un problema más grave: el desbordamiento de datos en uno de los OSD. Esto implica que el grupo primero haga la transición al estado HEALTH_WARNy luego HEALTH_ERR. La razón de esto es que Ceph, al calcular la cantidad de datos disponibles (puede averiguarlo MAX AVAIL en la salida del comando ceph df para cada grupo por separado) se basa en la cantidad de datos disponibles en el OSD. Si no hay suficiente espacio en al menos un OSD, no se podrán escribir más datos hasta que se distribuyan correctamente entre todos los OSD.
Vale aclarar que estos problemas se deciden en gran medida en la etapa de configuración del clúster Ceph. Una de las herramientas que puedes utilizar es . Con su ayuda, se calcula claramente la cantidad necesaria de PG. Sin embargo, también puede recurrir a él en una situación en la que el clúster Ceph ya configurado incorrectamente. Vale la pena aclarar aquí que, como parte del trabajo de reparación, lo más probable es que necesite reducir la cantidad de PG y esta función no está disponible en versiones anteriores de Ceph (solo apareció en la versión ).
Entonces, imaginemos la siguiente imagen: el clúster tiene un estado HEALTH_WARN debido a que uno de los OSD se está quedando sin espacio. Esto se indicará con un error. HEALTH_WARN: 1 near full osd. A continuación se muestra un algoritmo para salir de esta situación.
En primer lugar, debe distribuir los datos disponibles entre los OSD restantes. Ya realizamos una operación similar en el primer caso, cuando "drenamos" el nodo, con la única diferencia de que ahora necesitaremos reducir ligeramente reweight. Por ejemplo, hasta 0.95:
ceph osd reweight osd.${ID} 0.95Esto libera espacio en disco en el OSD y corrige el error en el estado de ceph. Sin embargo, como ya se mencionó, este problema ocurre principalmente debido a una configuración incorrecta de Ceph en las etapas iniciales: es muy importante realizar una reconfiguración para que no aparezca en el futuro.
En nuestro caso particular, todo se redujo a:
- valor demasiado alto
replication_counten una de las piscinas, - demasiado PG en un grupo y muy poco en otro.
Usemos la calculadora ya mencionada. Muestra claramente lo que hay que introducir y, en principio, no hay nada complicado. Habiendo configurado los parámetros necesarios, obtenemos las siguientes recomendaciones:
Nota: Si está configurando un clúster Ceph desde cero, otra función útil de la calculadora es la generación de comandos que crearán grupos desde cero con los parámetros especificados en la tabla.
La última columna le ayuda a navegar: Recuento de PG sugerido. En nuestro caso también es útil el segundo, donde se indica el parámetro de replicación, ya que decidimos cambiar el multiplicador de replicación.
Entonces, primero debe cambiar los parámetros de replicación; vale la pena hacerlo primero, ya que al reducir el multiplicador, liberaremos espacio en el disco. A medida que se ejecuta el comando, notará que el espacio disponible en disco aumentará:
ceph osd pool $pool_name set $replication_size
Y una vez completado, cambiamos los valores de los parámetros. pg_num и pgp_num следующим обрахом:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberEs importante: debemos cambiar la cantidad de PG secuencialmente en cada pool y no cambiar los valores en otros pools hasta que desaparezcan las advertencias "Redundancia de datos degradada" и "n-número de páginas degradadas".
También puedes comprobar que todo salió bien usando las salidas del comando. ceph health detail и ceph -s.
Caso No. 3. Migración de una máquina virtual de LVM a Ceph RBD
En una situación en la que un proyecto utiliza máquinas virtuales instaladas en servidores bare-metal alquilados, a menudo surge el problema del almacenamiento tolerante a fallos. 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 es necesario expandir el disco, pero no hay adónde ir, porque no hay espacio libre en disco que queda en el servidor.
El problema se puede resolver de diferentes maneras, por ejemplo, migrando a otro servidor (si lo hay) o agregando nuevos discos al servidor. Pero no siempre es posible hacer esto, por lo que migrar de LVM a Ceph puede ser una excelente solución a este problema. Al elegir esta opción, también simplificamos el proceso posterior 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ás que detener la VM mientras se realiza el trabajo.
La siguiente receta está tomada de , cuyas instrucciones han sido probadas en acción. Por cierto, el método de migración sin problemas también se describe allí, sin embargo, en nuestro caso simplemente no era necesario, por lo que no lo comprobamos. Si esto es fundamental para su proyecto, estaremos encantados de conocer 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 de Ceph al que se migrarán los datos esté conectado a libvirt:
virsh pool-dumpxml $ceph_poolLa descripción del grupo debe contener datos de conexión a 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_nameDespués de la conversión, quedará una imagen LVM, lo que será útil si falla la migración de la VM a RBD y debe revertir los cambios. Además, para poder revertir rápidamente los cambios, hagamos 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 editar el original (vm_name.xml). Busquemos un bloque con una descripción del disco (comienza con la línea <disk type='file' device='disk'> y termina con </disk>) y reducirlo a la siguiente forma:
<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>Veamos algunos detalles:
- al protocolo
sourceSe indica la dirección del almacenamiento en Ceph RBD (esta es la dirección que indica el nombre del grupo de Ceph y la imagen de RBD, que se determinó en la primera etapa). - En el bloque
secretse indica el tipoceph, así como el UUID del secreto para conectarse. Su uuid se puede encontrar usando el comandovirsh secret-list. - En el bloque
hostSe 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, 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 comprobar que la máquina virtual se inició correctamente: puede averiguarlo, por ejemplo, conectándose a ella mediante SSH o mediante virsh.
Si la máquina virtual está funcionando correctamente y no ha encontrado ningún otro problema, entonces puede eliminar la imagen LVM que ya no se utiliza:
lvremove main/$vm_image_nameConclusió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 su experiencia con Ceph, ¡estaremos encantados de verlos en los comentarios!
PS
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com