Crear almacenamiento compartido en clúster Proxmox con Ceph y RBD en hiperconvergencia. Instalación de Ceph, creación de Ceph pool y creación de RBD sobre Ceph. Pruebas de migración de almacenamiento al Pool RBD y pruebas de migración de máquinas virtuales de un nodo a otro, en caliente, con el almacenamiento en RBD/Ceph.

Requisitos para montar un almacenamiento compartido hiperconvergente con Ceph y RBD

En primer lugar, deberemos disponer de un clúster Proxmox con varios nodos. En el siguiente tutorial explicamos cómo montar un clúster Proxmox de varios nodos:

Cada nodo, a modo de recomendación, debería tener los mismos discos duros, del mismo tipo y mismo tamaño, aunque esto no es obligatorio, dado que Ceph permite la hiperconvergencia con distintos discos.

Otra recomendación es disponer de dos redes para el servicio de hiperconvergencia Ceph, para la red pública y para la red del clúster. Todos los nodos deben tener acceso a estas redes. Aunque esto tampoco es un requisito obligatorio.

Los discos duros elegidos para la hiperconvergencia NO podrán estar en un sistema RAID, no es compatible con Ceph.

Montar un almacenamiento compartido hiperconvergente con Ceph y RBD en clúster Proxmox VE

Desde la consola de gestión del clúster Proxmox VE, pulsaremos en «Datacenter (…)» [1] y en «Ceph» [2], nos mostrará una ventana con el botón «Install Ceph» [3], lo pulsaremos:

Si disponemos de suscripción Enterprise, elegiremos en «Repository» la opción «Enterprise», en caso contrario elegiremos «No-Suscription». Elegiremos la versión de Ceph que se instalará, por defecto «reef (18.2)» y pulsaremos en «Start reef installation»:

Se iniciará la descarga de los paquetes, responderemos «Y» e INTRO para continuar:

Pulsando en «Siguiente» una vez finalizada la instalación de Ceph (se habilitará el botón «Next»), seleccionaremos la red pública y la red del clúster. Lo recomendable es tener dos redes separadas para ambos propósitos, que deben ser visibles desde todos los nodos a los que agreguemos el servicio Ceph (habitualmente todos los nodos del clúster Proxmox VE). Para un laboratorio de pruebas, no hay problema en dejar la misma red para ambos usos, pero para un entorno de producción, mejor dos redes diferentes. Dejaremos los valores por defecto para el número de réplicas (3) y el mínimo de réplicas (2). Modificaremos estos valores en función del nivel de HA y disponibilidad que queramos alcanzar y del espacio libre de los discos, dado que a mayor número de réplicas, mayor tolerancia a fallos, pero también mayor consumo de espacio en disco:

El proceso de instalación del servicio de hiperconvergencia Ceph finalizará correctamente:

Repetiremos estos mismos pasos en el resto de nodos del clúster, eligiendo las mismas redes pública y de clúster:

Crearemos los OSD (Ceph Object Storage Daemons) correspondientes a cada disco duro que queramos usar para la hiperconvergencia. OSD se encarga del almacenamiento, la replicación, la recuperación y el reequilibrio de datos. Cada OSD suele corresponder a una unidad de almacenamiento (habitualmente un disco duro) y su diario asociado (base de datos con información del almacenamiento del clúster hiperconvergente) dentro de un nodo. Si un nodo tiene varias unidades de almacenamiento, cada unidad tendrá su propio demonio OSD.

Para agregar un OSD, desde cada nodo, pulsaremos en «Ceph» – «OSD» y en «Crete: OSD»:

En el desplegable de selección de disco, elegiremos el disco duro o almacenamiento que queramos agregar para formar parte del clúster hiperconvergente Ceph. Elegiremos también dónde se ubicará la base de datos con los metadatos y demás información, lo recomendable es almacenar esta BD en un disco de acceso rápido tipo SSD. En el caso de este laboratorio, dejaremos la BD en el mismo disco que estamos agregando, dejando en «BD Disk» y en «WAL Disk» la opción «use OSD disk». Si queremos cifrar los datos, marcaremos «Encrypt OSD». La encriptación es recomendable en entornos donde queramos tener mecanismos de seguridad elevados, aunque puede penalizar en el rendimiento. Para este laboratorio, dejaremos sin marcar la opción «Encrypt OSD».

Ceph nos advertirá de que no es compatible con sistemas de almacenamiento RAID. No podremos desplegar la hiperconvergencia Ceph en discos administrados por controladoras RAID.

Una vez elegido el disco y las opciones, pulsaremos en «Create»:

Repetiremos el proceso para todos los discos que queramos agregar a la hiperconvergencia para este nodo. Ceph agrupará los discos de forma automática por tipo de disco (SSD, HDD, etc.):

Repetiremos el proceso en el resto de discos del resto de nodos que tengan almacenamientos locales, para agregarlos a la hiperconvergencia Ceph. Lo ideal sería tener los mismos tipos de discos y con las mismas capacidades en cada nodo, aunque Ceph permite agregar discos de diferentes formatos y diferentes capacidades en cada nodo:

Como ya hemos indicado, repetiremos el proceso por cada disco y cada nodo:

Quedando, finalmente, una estructura similar a esta:

Como medida de HA (alta disponibilidad), es recomendable añadir el servicio Monitor (es la parte que mantiene y administra el mapa del clúster, una estructura de datos crucial que realiza un seguimiento del estado completo del clúster, incluida la ubicación de los datos, la topología del clúster y el estado de otros daemons en el sistema) en varios nodos. Para ello, seleccionaremos el segundo nodo y pulsaremos en «Ceph», en «Monitor» y en «Create»:

Estableceremos el nombre para el monitor Ceph del nodo 2 y pulsaremos en «Create»:

Quedando los dos nodos como monitores activos de Ceph:

Haremos lo mismo para el Manager, quedando el Manager del nodo 2 en estado stanby, dado que solo puede haber un Manager activo a la vez en el clúster de hiperconvergencia. Pero al agregar un Manager en el segundo nodo, si el primero cae, este se activará automáticamente, consiguiendo la HA (alta disponibilidad) requerida en estos entornos:

Crearemos el pool de Ceph para poder presentar este almacenamiento hiperconvergente a las máquinas virtuales. Para ello, pulsaremos en uno de los nodos, y en «Ceph» – «Pools». Pulsaremos en «Create»:

Introduciremos un nombre para el Ceph Pool, por ejemplo «ceph_pool_1», dejaremos el resto de opciones por defecto:

  • PG Autoscaler Mode: on.
  • Size: 3.
  • Add as Storage: marcado.
  • Min. Size: 2.
  • Target Ratio: 0.0.
  • Crush Rule: replicated_rule.
  • # of PGs: 128.
  • Target Size: 0GiB.

Pulsaremos en «Create»:

El Ceph Pool se habrá desplegado en todos los nodos del clúster de hiperconvergencia:

Migrar almacenamiento de máquina virtual de local al Ceph Pool

Con el paso anterior tendríamos disponible un nuevo almacenamiento para las máquinas virtuales. Por ejemplo, migrando una máquina ya existente en almacenamiento local al pool Ceph. Realizaremos este proceso a modo de prueba, aunque más adelante explicamos cómo desplegar el tipo de almacenamiento RBD sobre el pool Ceph, que es lo recomendable.

Para migrar el almacenamiento de una máquina de local al pool Ceph, seleccionaremos la máquina virtual (el proceso se realizará en caliente, sin tener que detener la máquina virtual), pulsaremos en «Hardware», seleccionaremos el disco duro a migrar y pulsaremos en «Disk Action» y en «Move Storage»:

En «Target Storage» seleccionaremos el pool Ceph, en este caso «ceph_pool_1». Si queremos eliminar el disco en el almacenamiento origen, marcaremos «Delete source». Pulsaremos en «Move disk»:

La tarea de movimiento de almacenamiento finalizará sin que la máquina haya perdido conectividad:

El disco habrá quedado ubicado en el clúster hiperconvergente Ceph, visible y accesible por todos los nodos:

Crear almacenamiento RBD sobre Ceph

Lo recomendable, como hemos comentado, es usar el tipo de almacenamiento RBD sobre Ceph. Este almacenamiento incluye numerosas funciones, como:

  • Aprovisionamiento fino.
  • Volúmenes redimensionables.
  • Distribuido y redundante (distribuido en múltiples OSD).
  • Capacidad completa de instantáneas y clonación.
  • Autorreparación.
  • Sin punto único de fallo.
  • Implementación disponible en kernel y espacio de usuario.

Para crear un almacenamiento RBD sobre Ceph, pulsaremos en el «Datacenter» [1] y el «Storage» [2]. Pulsaremos en «Add» [3] y elegiremos «RBD» [4]:

Como hemos indicado, RBD se despliega sobre Ceph, por lo que elegiremos el pool de Ceph que se asignará a este nuevo almacenamiento (en este caso «ceph_pool_1», introduciremos un nombre para identificar este almacenamiento, por ejemplo «rbd_pool_1» y dejaremos el resto de opciones por defecto:

  • Nodes: All (No restrictions).
  • Enable: marcado.
  • Content: Disk image.
  • KRBD: no marcado.
  • Use Proxmox VE managed hyper-converged ceph pool: marcado.

Pulsaremos «Add»:

El nuevo almacenamiento quedará visible y accesible en todos los nodos del clúster Proxmox VE:

Migrar almacenamiento de máquina virtual a RBD/Ceph

Si teníamos los discos duros de alguna máquina virtual almacenados en el Ceph Pool, conviene moverlos al almacenamiento RBD. Para ello, seleccionaremos la máquina, pulsaremos en «Hardware», seleccionaremos el disco duro a migrar y pulsaremos en «Disk Action» – «Move Storage»:

Elegimos el almacenamiento RBD en «Target Storage» y marcamos, si queremos eliminar el fichero en el almacenamiento origen, «Delete source». Pulsaremos en «Move disk» (el movimiento de disco se realizará en caliente, no será necesario detener la máquina virtual):

Tras la finalización de la tarea de migración, el disco duro quedará en el almacenamiento RBD:

Migrar máquina virtual de un nodo a otro en caliente con almacenamiento hiperconvergente Ceph y RBD

Gracias a que Ceph ha realizado una compartición de los almacenamientos de los distintos nodos, ahora podremos migrar una máquina virtual de un nodo a otro del clúster de virtualización Proxmox VE en caliente y en pocos segundos, sin pérdida de conectividad. Para migrar una máquina pulsaremos en la máquina con el botón derecho del ratón y elegiremos «Migrate»:

Elegiremos el nodo al que queramos migrar la máquina (sólo se migrará el uso de RAM y CPU, el almacenamiento permanecerá en el pool RBD de Ceph):

Realizará la la migración de nodo en cuestión de segundos:

Y sin pérdida de conectividad:

Evitar algunos errores y avisos en almacenamiento compartido Ceph

HEALTH_WARN: Degraded data redundancy

Puesto que hemos indicado tres réplicas de la información, para evitar warning e incumplimiento de esta regla, es muy recomendable disponer de, al menos, tres nodos Proxmox con discos duros con espacio suficiente para almacenar estas tres réplicas de cada bloque de datos. Si no cumplimos esta regla, podríamos recibir avisos del tipo:

Quedando el servicio Ceph en estado HEALTH_WARN:

Estos avisos indican que, o bien falta espacio en algún PG de algún OSD o bien no hay suficiones OSD. En definitiva, que o bien necesitamos más discos duros en algún nodo o bien disponemos de un tercer nodo.

En este caso, lo hemos solucionado agregando un tercer nodo al clúster Proxmox VE, lo que nos ha permitido también evitar errores de quorum cuando se apaga alguno de los dos nodos que teníamos. Con tres nodos, se puede apagar uno sin que recibamos avisos de incumplimiento de reglas del clúster.

HEALTH_WARN: clock skew detected on mon.proxmox

Si se produce el aviso:

En el servicio Ceph, seguiremos las siguientes indicaciones para solucionarlo: