Se aplica a SUSE Enterprise Storage 7.1

20 Dispositivo de bloques RADOS #

Un bloque es una secuencia de bytes, por ejemplo, un bloque de 4 MB de datos. Las interfaces de almacenamiento basadas en bloques son la forma más habitual de almacenar los datos en soportes de uso rotativo, como discos duros, CD o disquetes. La ubicuidad de las interfaces de dispositivos de bloques hacen que un dispositivo de bloques virtual sea el candidato idóneo para interactuar con un sistema de almacenamiento masivo de datos como Ceph.

Los dispositivos de bloques de Ceph permiten compartir recursos físicos y se puede modificar su tamaño. Los datos se almacenan repartidos en varios OSD en un clúster de Ceph. Los dispositivos de bloques de Ceph aprovechan las funciones de RADOS, como la realización de instantáneas, las réplicas y la comprobación de coherencia. Los dispositivos de bloques RADOS (RBD) de Ceph interactúan con los OSD mediante módulos del kernel o la biblioteca librbd.

Figura 20.1: Protocolo RADOS #

Los dispositivos de bloques de Ceph ofrecen un alto rendimiento con infinitas posibilidades de escalabilidad para los módulos de kernel. Son compatibles con soluciones de virtualización como QEMU o sistemas informáticos basados en la nube que dependen de libvirt, como OpenStack. Puede utilizar el mismo clúster para gestionar Object Gateway, CephFS y los dispositivos de bloques RADOS al mismo tiempo.

20.1 Comandos del dispositivo de bloques #

El comando rbd permite crear, enumerar, examinar y eliminar imágenes de los dispositivos de bloques. También se puede emplear, por ejemplo, para clonar imágenes, crear instantáneas, revertir una imagen al estado de una instantánea o ver una instantánea.

20.1.1 Creación de una imagen del dispositivo de bloques en un repositorio replicado #

Antes de poder añadir un dispositivo de bloques a un cliente, debe crear una imagen relacionada en un repositorio existente (consulte el Capítulo 18, Gestión de repositorios de almacenamiento):

cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

Por ejemplo, para crear una imagen de 1 GB denominada "myimage" que almacena información en un repositorio llamado "mypool", ejecute lo siguiente:

cephuser@adm > rbd create --size 1024 mypool/myimage

Sugerencia: unidades de tamaño de imagen

Si omite un acceso directo de unidad de tamaño ("G" o "T"), el tamaño de la imagen se indicará en megabytes. Utilice "G" o "T" después del número de tamaño para especificar gigabytes o terabytes.

20.1.2 Creación de una imagen del dispositivo de bloques en un repositorio codificado de borrado #

Es posible almacenar datos de una imagen de dispositivo de bloques directamente en repositorios codificados de borrado. Una imagen de dispositivo de bloques RADOS está formada por elementos de datos y metadatos. Solo se puede almacenar la parte de datos de una imagen de dispositivo de bloques RADOS en un repositorio codificado de borrado. El repositorio debe tener en el indicador overwrite el valor true definido, y eso solo es posible si todos los OSD donde se almacena el repositorio utilizan BlueStore.

No es posible almacenar la parte de metadatos de la imagen en un repositorio codificado de borrado. Puede especificar el repositorio replicado para almacenar los metadatos de la imagen con la opción --pool= del comando rbd create o especificar pool/ como prefijo del nombre de la imagen.

Cree un repositorio codificado de borrado:

cephuser@adm > ceph osd pool create EC_POOL 12 12 erasure
cephuser@adm > ceph osd pool set EC_POOL allow_ec_overwrites true

Especifique el repositorio replicado para almacenar los metadatos:

cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOL

O bien:

cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL

20.1.3 Listado de imágenes de dispositivos de bloques #

Para mostrar los dispositivos de bloques en un repositorio denominado "mypool", ejecute lo siguiente:

cephuser@adm > rbd ls mypool

20.1.4 Recuperación de información de la imagen #

Para recuperar información de una imagen denominada "myimage" dentro de un repositorio denominado "mypool", ejecute lo siguiente:

cephuser@adm > rbd info mypool/myimage

20.1.5 Cambio de tamaño de la imagen de un dispositivo de bloques #

Las imágenes de los dispositivos de bloques RADOS emplean un sistema de provisión ligera, lo que significa que no emplean espacio físico real hasta que empieza a guardar datos en ellos. No obstante, tienen una capacidad máxima que se define mediante la opción ‑‑size. Si desea aumentar (o reducir) el tamaño máximo de la imagen (o disminuir), ejecute lo siguiente:

cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increase
cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

20.1.6 Eliminación de una imagen de dispositivo de bloques #

Para eliminar un dispositivo de bloques que se corresponde con una imagen llamada "myimage" en un repositorio denominado "mypool", ejecute lo siguiente:

cephuser@adm > rbd rm mypool/myimage

20.2 Montaje y desmontaje #

Después de crear un dispositivo de bloques RADOS, puede usarlo como cualquier otro dispositivo de disco: formatearlo, montarlo para que permita el intercambio de archivos y desmontarlo cuando haya terminado.

El comando rbd accede por defecto al clúster mediante la cuenta de usuario admin de Ceph. Esta cuenta tiene acceso administrativo completo al clúster. Esto aumenta el riesgo de causar daños accidentalmente, como ocurre cuando se entra en una estación de trabajo Linux como usuario root. Por lo tanto, es preferible crear cuentas de usuario con menos privilegios y utilizar estas cuentas para el acceso normal de lectura/escritura a dispositivos de bloques RADOS.

20.2.1 Creación de una cuenta de usuario de Ceph #

Para crear una nueva cuenta de usuario con las capacidades de Ceph Manager, Ceph Monitor y Ceph OSD, utilice el comando ceph con el subcomando auth get-or-create:

cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
  [pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'

Por ejemplo, para crear un usuario llamado qemu con acceso de lectura y escritura al repositorio vms y acceso de solo lectura al repositorio images, ejecute lo siguiente:

ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \
  mgr 'profile rbd pool=images'

El resultado del comando ceph auth get-or-create será el anillo de claves del usuario especificado, que se puede escribir en /etc/ceph/ceph.client.ID.keyring.

Nota

Al utilizar el comando rbd, puede especificar el ID de usuario proporcionando el argumento opcional --id ID.

Para obtener más información sobre la gestión de cuentas de usuario de Ceph, consulte el Capítulo 30, Autenticación con cephx.

20.2.2 Autenticación de usuarios #

Para especificar un nombre de usuario, utilice ‑‑id nombre de usuario. Si utiliza la autenticación de cephx, también debe especificar un secreto. Puede proceder de un anillo de claves o de un archivo que contenga el secreto:

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyring

o bien

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file

20.2.3 Preparación de un dispositivo de bloques RADOS para su uso #

Asegúrese de que el clúster de Ceph incluye un repositorio con la imagen de disco que desea asignar. Supongamos que el repositorio se denomina mypool y la imagen myimage.
```
cephuser@adm > rbd list mypool
```

Asigne la imagen a un nuevo dispositivo de bloques:

cephuser@adm > rbd device map --pool mypool myimage

Enumerar todos los dispositivos asignados:
```
cephuser@adm > rbd device list
id pool   image   snap device
0  mypool myimage -    /dev/rbd0
```
El dispositivo en el que queremos trabajar es /dev/rbd0.
Sugerencia: vía del dispositivo RBD
En lugar de /dev/rbdNÚMERO_DISPOSITIVO, puede utilizar /dev/rbd/NOMBRE_REPOSITORIO/NOMBRE_IMAGEN como vía persistente del dispositivo. Por ejemplo:
```
       /dev/rbd/mypool/myimage
```

Cree un sistema de archivos XFS en el dispositivo /dev/rbd0:

# mkfs.xfs /dev/rbd0
      log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
      log stripe unit adjusted to 32KiB
      meta-data=/dev/rbd0              isize=256    agcount=9, agsize=261120 blks
      =                       sectsz=512   attr=2, projid32bit=1
      =                       crc=0        finobt=0
      data     =                       bsize=4096   blocks=2097152, imaxpct=25
      =                       sunit=1024   swidth=1024 blks
      naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
      log      =internal log           bsize=4096   blocks=2560, version=2
      =                       sectsz=512   sunit=8 blks, lazy-count=1
      realtime =none                   extsz=4096   blocks=0, rtextents=0

Sustituyendo /mnt por el punto de montaje, monte el dispositivo y compruebe que está montado correctamente:
```
# mount /dev/rbd0 /mnt
      # mount | grep rbd0
      /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
```
Ya puede mover datos al dispositivo y desde él como si fuese un directorio local.
Sugerencia: aumento del tamaño del dispositivo RBD
Si descubre que el tamaño del dispositivo RBD es insuficiente, puede aumentarlo con facilidad.
1. Aumente el tamaño de la imagen RBD, por ejemplo, hasta 10 GB.
  cephuser@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.
2. Aumente el sistema de archivos hasta llenar el nuevo tamaño del dispositivo:
  # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
Cuando termine de acceder al dispositivo, puede desasignarlo y desmontarlo.
```
cephuser@adm > rbd device unmap /dev/rbd0
# unmount /mnt
```

Sugerencia: montaje y desmontaje manual

Se proporciona un guion rbdmap y una unidad systemd para facilitar el proceso de asignación y montaje de los RBD después del arranque, así como de desmontarlos antes del apagado. Consulte la Sección 20.2.4, “rbdmap: asignación de dispositivos RBD durante el arranque”.

20.2.4 `rbdmap`: asignación de dispositivos RBD durante el arranque #

rbdmap es un guion de shell que automatiza las operaciones rbd map y rbd device unmap en una o varias imágenes RBD. Aunque es posible ejecutar el guion manualmente en cualquier momento, la ventaja principal consiste en asignar y montar automáticamente las imágenes RBD durante el arranque (y desmontarlas y desasignarlas al apagar el equipo), activándose mediante el sistema Init. Con este fin, el paquete systemd incluye el archivo de unidad rbdmap.serviceceph-common.

El guion solo acepta un argumento, que puede ser map o unmap. En ambos casos, el guion analiza un archivo de configuración. Se utiliza /etc/ceph/rbdmap por defecto, pero se puede anular mediante una variable de entorno RBDMAPFILE. Cada línea del archivo de configuración se corresponde con una imagen RBD que se debe asignar o desasignar.

El archivo de configuración tiene el formato siguiente:

image_specification rbd_options

image_specification

Vía a una imagen dentro de un repositorio. Se debe especificar como nombre_repositorio/nombre_imagen.

rbd_options

Una lista opcional de parámetros que se puedan pasar al comando rbd device map subyacente. Estos parámetros y sus valores se deben especificar como una cadena separada por comas, por ejemplo:

PARAM1=VAL1,PARAM2=VAL2,...

El ejemplo hace que el guion rbdmap ejecute el siguiente comando:

cephuser@adm > rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2

En el ejemplo siguiente puede se explica cómo especificar un nombre de usuario y un anillo de claves con un secreto correspondiente:

cephuser@adm > rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring

Si se ejecuta como rbdmap map, el guion analiza el archivo de configuración y, para cada imagen RBD especificada, primero intenta asignar la imagen (mediante el comando rbd device map) y luego montarla.

Si se ejecuta como rbdmap unmap, las imágenes enumeradas en el archivo de configuración se desmontarán y se desasignarán.

rbdmap unmap-all intenta desmontar y posteriormente desasignar todas las imágenes RBD asignadas actualmente, independientemente de que estén enumeradas o no en el archivo de configuración.

Si la operación se realiza correctamente, rbd device map asigna la imagen a un dispositivo /dev/rbdX, momento en el que se activa una regla udev para crear un enlace simbólico de nombre de dispositivo de confianza /dev/rbd/nombre_repositorio/nombre_imagen que señala al dispositivo real asignado.

Para que las operaciones de montaje y desmontaje se lleven a cabo correctamente, el nombre del dispositivo de confianza debe tener una entrada correspondiente en /etc/fstab. Al escribir entradas /etc/fstab para imágenes RBD, especifique la opción de montaje "noauto" (o "nofail"). Esto impide que el sistema Init intente montar el dispositivo demasiado pronto, antes de que el dispositivo en cuestión aún exista, ya que rbdmap.service normalmente se activa bastante tarde en la secuencia de arranque.

Para una lista completa de opciones de rbd, consulte la página man de rbd (man 8 rbd).

Para consultar ejemplos de uso de rbdmap, consulte la página man de rbdmap (man 8 rbdmap).

20.2.5 Aumento del tamaño de dispositivos RBD #

Si descubre que el tamaño del dispositivo RBD es insuficiente, puede aumentarlo con facilidad.

Aumente el tamaño de la imagen RBD, por ejemplo, hasta 10 GB.

cephuser@adm > rbd resize --size 10000 mypool/myimage
 Resizing image: 100% complete...done.

Aumente el sistema de archivos hasta llenar el nuevo tamaño del dispositivo.
```
# xfs_growfs /mnt
 [...]
 data blocks changed from 2097152 to 2560000
```

20.3 Instantáneas #

Una instantánea RBD es una instantánea de una imagen de dispositivo de bloques RADOS. Las instantáneas permiten conservar un historial de los estados de la imagen. Ceph también es compatible con capas de instantáneas, lo que permite clonar imágenes de máquinas virtuales de forma rápida y sencilla. Ceph admite las instantáneas de dispositivos de bloques mediante el comando rbd y muchas interfaces de alto nivel, incluidas QEMU, libvirt, OpenStack y CloudStack.

Nota

Detenga las operaciones de entrada y salida y vacíe todas las escrituras pendientes antes de tomar una instantánea de una imagen. Si la imagen contiene un sistema de archivos, este debe tener un estado coherente en el momento de realizar la instantánea.

20.3.1 Habilitación y configuración de `cephx` #

Si cephx está habilitado, debe especificar un nombre de usuario o ID y una vía al anillo de claves que contiene la clave correspondiente para el usuario. Consulte el Capítulo 30, Autenticación con cephx para obtener más información. También puede añadir la variable de entorno CEPH_ARGS para evitar la reintroducción de los siguientes parámetros.

cephuser@adm > rbd --id user-ID --keyring=/path/to/secret commands
cephuser@adm > rbd --name username --keyring=/path/to/secret commands

Por ejemplo:

cephuser@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephuser@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

Sugerencia

Añada el usuario y el secreto a la variable de entorno CEPH_ARGS para no tener que introducir estos datos en cada ocasión.

20.3.2 Conceptos básicos sobre instantáneas #

Los procedimientos siguientes muestran cómo crear, enumerar y eliminar instantáneas mediante el comando rbd en la línea de comandos.

20.3.2.1 Creación de instantáneas #

Para crear una instantánea con rbd, especifique la opción snap create, el nombre del repositorio y el nombre de la imagen.

cephuser@adm > rbd --pool pool-name snap create --snap snap-name image-name
cephuser@adm > rbd snap create pool-name/image-name@snap-name

Por ejemplo:

cephuser@adm > rbd --pool rbd snap create --snap snapshot1 image1
cephuser@adm > rbd snap create rbd/image1@snapshot1

20.3.2.2 Listado de instantáneas #

Para enumerar las instantáneas de una imagen, especifique el nombre del repositorio y el de la imagen.

cephuser@adm > rbd --pool pool-name snap ls image-name
cephuser@adm > rbd snap ls pool-name/image-name

Por ejemplo:

cephuser@adm > rbd --pool rbd snap ls image1
cephuser@adm > rbd snap ls rbd/image1

20.3.2.3 Reversión de instantáneas #

Para revertir una instantánea con rbd, especifique la opción snap rollback, el nombre del repositorio, el nombre de la imagen y el nombre de la instantánea.

cephuser@adm > rbd --pool pool-name snap rollback --snap snap-name image-name
cephuser@adm > rbd snap rollback pool-name/image-name@snap-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephuser@adm > rbd snap rollback pool1/image1@snapshot1

Nota

Revertir una imagen a una instantánea significa sobrescribir la versión actual de la imagen con los datos de la instantánea. El tiempo necesario para ejecutar una reversión aumenta según el tamaño de la imagen. Es más rápido clonar una instantánea que revertir una imagen a una instantánea, por lo que es el método preferible para volver a un estado preexistente.

20.3.2.4 Supresión de una instantánea #

Para suprimir una instantánea con rbd, especifique la opción snap rm, el nombre del repositorio, el nombre de la imagen y el nombre de usuario.

cephuser@adm > rbd --pool pool-name snap rm --snap snap-name image-name
cephuser@adm > rbd snap rm pool-name/image-name@snap-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephuser@adm > rbd snap rm pool1/image1@snapshot1

Nota

Los OSD de Ceph suprimen los datos de forma asíncrona, por lo que al suprimir una instantánea, no se libera el espacio de disco inmediatamente.

20.3.2.5 Limpieza de instantáneas #

Para suprimir todas las instantáneas de una imagen con rbd, especifique la opción snap purge y el nombre de la imagen.

cephuser@adm > rbd --pool pool-name snap purge image-name
cephuser@adm > rbd snap purge pool-name/image-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 snap purge image1
cephuser@adm > rbd snap purge pool1/image1

20.3.3 Capas de instantáneas #

Ceph admite la posibilidad de crear varios clones de copia de escritura (COW, por sus siglas en inglés) de una instantánea de dispositivo de bloques. Las capas de instantáneas permiten que los clientes de dispositivos de bloques de Ceph creen imágenes muy rápidamente. Por ejemplo, puede crear una imagen de dispositivo de bloques con una máquina virtual Linux escrita en él y, a continuación, realizar una instantánea de la imagen, protegerla y crear tantos clones de copia de escritura como desee. Las instantáneas son de solo lectura, por lo que clonar una instantánea simplifica la semántica y permite crear clones rápidamente.

Nota

Los términos "parent" (padre) y "child" (hijo) mencionados en los siguientes ejemplos de la línea de comandos hacen referencia a una instantánea de un dispositivo de bloques de Ceph (padre) y la imagen correspondiente clonada de la instantánea (hijo).

Cada imagen clonada (hijo) almacena una referencia a su imagen padre que permite que la imagen clonada abra la instantánea padre y la lea.

Un clon COW de una instantánea se comporta exactamente igual que cualquier otra imagen de dispositivo de bloques de Ceph. Puede leer las imágenes clonadas, escribir en ellas, clonarlas y redimensionarlas. No existen restricciones especiales que afecten a las imágenes clonadas. No obstante, la clonación de copia de escritura de una instantánea hace referencia a la instantánea, por lo que debe proteger la instantánea antes de clonarla.

Nota: ‑‑image-format 1 no se admite

No es posible crear instantáneas de imágenes creadas con la opción obsoleta rbd create ‑‑image-format 1. Ceph solo admite la clonación de las imágenes format 2 por defecto.

20.3.3.1 Procedimientos iniciales con las capas #

La aplicación de capas a un dispositivo de bloques de Ceph es un proceso sencillo. Debe disponer de una imagen. Debe crear una instantánea de la imagen. Debe proteger la instantánea. Una vez realizados estos pasos, puede empezar a clonar la instantánea.

La imagen clonada tendrá una referencia a la instantánea padre e incluirá el ID del repositorio, el ID de la imagen y el ID de la instantánea. La inclusión del ID del repositorio significa que se pueden clonar instantáneas de un repositorio como imágenes en un repositorio distinto.

Plantilla de imagen: un ejemplo de uso habitual para crear capas de dispositivos de bloques es crear una imagen principal y una instantánea que sirva como plantilla para los clones. Por ejemplo, un usuario puede crear una imagen de una distribución de Linux (como SUSE Linux Enterprise Server) y crear una instantánea para ella. El usuario puede actualizar periódicamente la imagen y crear una instantánea nueva (por ejemplo, zypper ref && zypper patch, seguido de rbd snap create). A medida que la imagen crezca, el usuario puede clonar cualquiera de las instantáneas.
Plantilla extendida: un ejemplo de uso más avanzado implica la posibilidad de extender una imagen de plantilla para que proporcione más información que una imagen base. Por ejemplo, un usuario puede clonar una imagen (una plantilla de máquina virtual) e instalar otro software (por ejemplo, una base de datos, un sistema de gestión de contenido o un sistema de análisis) y, a continuación, realizar una instantánea de la imagen extendida, que a su vez se puede actualizar de la misma manera que la imagen base.
Repositorio de plantillas: una manera de utilizar capas de dispositivos de bloques es crear un repositorio que contenga imágenes principales que actúen como plantillas e instantáneas de dichas plantillas. A continuación, puede ampliar los privilegios de solo lectura a los usuarios, de modo que tengan la posibilidad de clonar las instantáneas sin la capacidad de escribir o ejecutar dentro del repositorio.
Migración y recuperación de imágenes: una manera de utilizar capas de dispositivos de bloques consiste en migrar o recuperar datos de un repositorio a otro.

20.3.3.2 Protección de una instantánea #

Los clones acceden a las instantáneas padre. Todos los clones dejarán de funcionar si un usuario suprime por error la instantánea padre. Para evitar la pérdida de datos, debe proteger la instantánea antes de clonarla.

cephuser@adm > rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
cephuser@adm > rbd snap protect pool-name/image-name@snapshot-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1
cephuser@adm > rbd snap protect pool1/image1@snapshot1

Nota

No es posible suprimir una instantánea protegida.

20.3.3.3 Clonación de una instantánea #

Para clonar una instantánea, debe especificar el repositorio padre, la imagen, la instantánea, el repositorio hijo y el nombre de la imagen. Debe proteger la instantánea para poder clonarla.

cephuser@adm > rbd clone --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
cephuser@adm > rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Por ejemplo:

cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2

Nota

Puede clonar una instantánea de un repositorio como una imagen de otro repositorio. Por ejemplo, puede mantener imágenes e instantáneas de solo lectura como plantillas en un repositorio y clones con acceso de escritura en otro.

20.3.3.4 Desprotección de una instantánea #

Para suprimir una instantánea, primero debe desprotegerla. Además, no puede suprimir instantáneas que tengan referencias de clones. Debe aplanar todos los clones de una instantánea para poder eliminarla.

cephuser@adm > rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
cephuser@adm > rbd snap unprotect pool-name/image-name@snapshot-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
cephuser@adm > rbd snap unprotect pool1/image1@snapshot1

20.3.3.5 Listado de los hijos de una instantánea #

Para enumerar los hijos de una instantánea, ejecute lo siguiente:

cephuser@adm > rbd --pool pool-name children --image image-name --snap snap-name
cephuser@adm > rbd children pool-name/image-name@snapshot-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 children --image image1 --snap snapshot1
cephuser@adm > rbd children pool1/image1@snapshot1

20.3.3.6 Aplanamiento de una imagen clonada #

Las imágenes clonadas retienen una referencia a la instantánea padre. Si elimina la referencia del clon a la instantánea padre, la imagen se "aplana" copiando la información de la instantánea en el clon. El tiempo que se tarda en aplanar un clon aumenta según el tamaño de la instantánea. Para suprimir una instantánea, primero debe aplanar las imágenes hijo.

cephuser@adm > rbd --pool pool-name flatten --image image-name
cephuser@adm > rbd flatten pool-name/image-name

Por ejemplo:

cephuser@adm > rbd --pool pool1 flatten --image image1
cephuser@adm > rbd flatten pool1/image1

Nota

Dado que una imagen plana contiene toda la información de la instantánea, ocupará más espacio de almacenamiento que un clon con capas.

20.4 Duplicados de imagen RBD #

Las imágenes RBD se pueden duplicar de forma asincrónica entre dos clústeres de Ceph. Esta capacidad está disponible en dos modos:

Basada en registro: Este modo utiliza las imágenes RBD transaccionales para garantizar la réplica protegida contra bloqueos de un momento concreto entre los clústeres. Cada escritura en la imagen RBD se guarda primero en el registro asociado antes de modificar la imagen real. El clúster remoto leerá el registro y reproducirá las actualizaciones en su copia local de la imagen. Dado que cada escritura en la imagen RBD dará como resultado dos escrituras en el clúster de Ceph, se espera que la latencia de escritura casi se duplique cuando se utiliza la función de imagen RBD transaccional.
Basada en instantáneas: Este modo utiliza instantáneas de duplicación de imágenes RBD creadas de forma programada periódicamente o manualmente para replicar imágenes de RBD protegidas contra bloqueos entre clústeres. El clúster remoto determinará las actualizaciones de datos o metadatos entre dos instantáneas de duplicación y copiará los deltas en su copia local de la imagen. Con la ayuda de la función de imagen fast-diff de RBD, los bloques de datos actualizados se pueden calcular rápidamente sin necesidad de explorar la imagen RBD completa. Dado que este modo no es coherente en un momento determinado, será necesario sincronizar el delta completo de la instantánea antes de utilizarlo durante una situación de failover. Cualquier delta de instantánea aplicado parcialmente se revertirá a la última instantánea totalmente sincronizada antes de su uso.

La duplicación se configura de forma independiente para cada repositorio dentro de los clústeres conectores. Esto se puede configurar en un subconjunto específico de imágenes dentro del repositorio, o para que refleje automáticamente todas las imágenes de un repositorio si se usa únicamente la duplicación transaccional. La duplicación se configura mediante el comando rbd. El daemon rbd-mirror es el responsable de la extracción de actualizaciones de imágenes del clúster conector remoto y de aplicarlos a la imagen en el clúster local.

Dependiendo de las necesidades de réplica, la duplicación del RBD se puede configurar para la réplica unidireccional o bidireccional:

Réplica unidireccional: Cuando los datos solo se duplican desde un clúster primario a un clúster secundario, el daemon rbd-mirror se ejecuta solo en el clúster secundario.
Réplica bidireccional: Cuando los datos se duplican desde imágenes primarias de un clúster a imágenes no primarias de otro clúster (y viceversa), el daemon rbd-mirror se ejecuta en ambos clústeres.

Importante

Cada instancia del daemon rbd-mirror debe poder conectarse a los clústeres de Ceph locales y remotos simultáneamente. Por ejemplo, todos los hosts de monitor y OSD. Además, la red debe tener suficiente ancho de banda entre los dos centros de datos para poder gestionar la carga de trabajo de duplicación.

20.4.1 Configuración del repositorio #

Los siguientes procedimientos demuestran cómo llevar a cabo las tareas administrativas básicas para configurar la duplicación mediante el comando rbd. La duplicación se configura de forma independiente para cada repositorio dentro de los clústeres de Ceph.

Debe llevar a cabo los pasos de configuración del repositorio en ambos clústeres conectores. Para simplificar los ejemplos, en estos procedimientos se presupone que hay dos clústeres, denominados local y remote a los que se puede acceder desde un único host.

Consulte la página man de rbd (man 8 rbd) para obtener información adicional acerca de cómo conectarse a clústeres de Ceph diferentes.

Sugerencia: varios clústeres

En los siguientes ejemplos, el nombre del clúster corresponde a un archivo de configuración de Ceph con el mismo nombre /etc/ceph/remote.conf y a un archivo de anillo de claves de Ceph con el mismo nombre /etc/ceph/remote.client.admin.keyring.

20.4.1.1 Habilitación de la duplicación en un repositorio #

Para habilitar la duplicación en un repositorio, especifique el subcomando mirror pool enable, el nombre del repositorio y el modo de duplicación. El modo de duplicación puede ser de repositorio o de imagen:

pool: Se duplican todas las imágenes del repositorio con el registro transaccional habilitado.
image: La duplicación se debe habilitar explícitamente en cada imagen. Consulte el Sección 20.4.2.1, “Habilitación de la duplicación de imágenes” para obtener más información.

Por ejemplo:

cephuser@adm > rbd --cluster local mirror pool enable POOL_NAME pool
cephuser@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

20.4.1.2 Inhabilitación de la duplicación #

Para inhabilitar la duplicación en un repositorio, especifique el subcomando mirror pool disable y el nombre del repositorio. Cuando se inhabilita la duplicación en un repositorio de esta forma, la duplicación también se inhabilitará en cualquier imagen (dentro del repositorio) para la que se haya habilitado la duplicación explícitamente.

cephuser@adm > rbd --cluster local mirror pool disable POOL_NAME
cephuser@adm > rbd --cluster remote mirror pool disable POOL_NAME

20.4.1.3 Conectores de carga #

Para que el daemon rbd-mirror descubra su clúster conector, el conector debe estar registrado en el repositorio y se debe crear una cuenta de usuario. Este proceso se puede automatizar con rbd y con los comandos mirror pool peer bootstrap create y mirror pool peer bootstrap import.

Para crear manualmente un nuevo testigo de arnque con rbd, especifique el comando mirror pool peer bootstrap create, un nombre de repositorio y un nombre de sitio descriptivo opcional para describir el clúster local:

cephuser@local > rbd mirror pool peer bootstrap create \
 [--site-name LOCAL_SITE_NAME] POOL_NAME

El resultado del comando mirror pool peer bootstrap create será un testigo que se debe proporcionar al comando mirror pool peer bootstrap import. Por ejemplo, en el clúster local:

cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5I \
joiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

Para importar manualmente el testigo de arranque creado por otro clúster con el comando rbd, utilice la siguiente sintaxis:

rbd mirror pool peer bootstrap import \
 [--site-name LOCAL_SITE_NAME] \
 [--direction DIRECTION \
 POOL_NAME TOKEN_PATH

Dónde:

LOCAL_SITE_NAME: Un nombre de sitio descriptivo opcional para describir el clúster local.
DIRECTION: Una dirección de duplicación. El valor por defecto es rx-tx para la duplicación bidireccional, pero también se puede definir como rx-only para la duplicación unidireccional.
POOL_NAME: El nombre del repositorio.
TOKEN_PATH: Una vía de archivo al testigo creado (o - para leerlo desde la entrada estándar).

Por ejemplo, en el clúster remote:

cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF

cephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
 --site-name remote image-pool token

20.4.1.4 Adición manual de un conector de clúster #

Como alternativa al procedimiento descrito en la Sección 20.4.1.3, “Conectores de carga”, puede especificar conectores de forma manual. El daemon remoto rbd-mirror necesitará acceso al clúster local para realizar la duplicación. Cree un nuevo usuario local de Ceph, que utilizará el daemon remoto rbd-mirror; por ejemplo, rbd-mirror-peer:

cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
 mon 'profile rbd' osd 'profile rbd'

Utilice la siguiente sintaxis para añadir un clúster de Ceph conector duplicado con el comando rbd:

rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME

Por ejemplo:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-b
cephuser@adm > rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a

Por defecto, el daemon rbd-mirror debe tener acceso al archivo de configuración de Ceph ubicado en /etc/ceph/.NOMBRE_CLÚSTER.conf. Proporciona las direcciones IP de los MON del clúster conector y un anillo de claves para un cliente denominado NOMBRE_CLIENTE ubicado en las vías de búsqueda por defecto o personalizadas del anillo de claves; por ejemplo /etc/ceph/NOMBRE_CLUSTER.NOMBRE_CLIENTE.keyring.

Como alternativa, el MON del clúster conector o la clave de cliente se pueden almacenar de forma segura en el almacén de claves de configuración de Ceph local. Para especificar los atributos de conexión del clúster conector al añadir un conector de duplicación, utilice las opciones --remote-mon-host y --remote-key-file. Por ejemplo:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool \
 client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \
 --remote-key-file /PATH/TO/KEY_FILE
cephuser@adm > rbd --cluster site-a mirror pool info image-pool --all
Mode: pool
Peers:
  UUID        NAME   CLIENT                 MON_HOST                KEY
  587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...

20.4.1.5 Eliminación de un clúster conector #

Para eliminar un clúster conector duplicado, especifique el subcomando mirror pool peer remove, el nombre del repositorio y el UUID del conector (disponible mediante el comando rbd mirror pool info):

cephuser@adm > rbd --cluster local mirror pool peer remove POOL_NAME \
 55672766-c02b-4729-8567-f13a66893445
cephuser@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \
 60c0e299-b38f-4234-91f6-eed0a367be08

20.4.1.6 Repositorios de datos #

Al crear imágenes en el clúster de destino, rbd-mirror selecciona un repositorio de datos de la siguiente manera:

Si el clúster de destino tiene un repositorio de datos por defecto configurado (con la opción de configuración rbd_default_data_pool), se utilizará.
De lo contrario, si la imagen de origen utiliza un repositorio de datos independiente y existe un repositorio con el mismo nombre en el clúster de destino, se utilizará dicho repositorio.
Si no se cumple ninguna de estas condiciones, no se definirá ningún repositorio de datos.

20.4.2 Configuración de la imagen RBD #

A diferencia de la configuración del repositorio, la configuración de la imagen solo se debe realizar en un único clúster conector duplicado de Ceph.

Las imágenes RBD duplicadas se designan como primary (principal) o non-primary (no principal). Se trata de una propiedad de la imagen, no del repositorio. Las imágenes designadas como no principales no se pueden modificar.

Las imágenes suben de nivel a principal automáticamente cuando la duplicación se habilita por primera vez en una imagen (ya sea implícita, si el modo de duplicación del repositorio es "pool" [repositorio] y la imagen cuenta con la función de imagen transaccional habilitada, o explícita [consulte la Sección 20.4.2.1, “Habilitación de la duplicación de imágenes”], mediante el comando rbd).

20.4.2.1 Habilitación de la duplicación de imágenes #

Si la duplicación está configurada en el modo image, es necesario habilitar explícitamente la duplicación para cada imagen del repositorio. Para habilitar la duplicación de una imagen concreta con rbd, especifique el subcomando mirror image enable junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd --cluster local mirror image enable \
 POOL_NAME/IMAGE_NAME

El modo de imagen duplicada puede ser journal (registro) o snapshot (instantánea):

journal (modo por defecto): Cuando se configura en el modo journal, la duplicación utilizará la función de imagen RBD transaccional para replicar el contenido de la imagen. Si esta función aún no está habilitada en la imagen, se habilitará automáticamente.
snapshot: Cuando se configura en el modo de snapshot, la duplicación utilizará instantáneas de duplicación de la imagen RBD para replicar el contenido de la imagen. Una vez habilitada, se creará automáticamente una instantánea de duplicación inicial. Se pueden crear instantáneas adicionales mediante el comando rbd.

Por ejemplo:

cephuser@adm > rbd --cluster local mirror image enable image-pool/image-1 snapshot
cephuser@adm > rbd --cluster local mirror image enable image-pool/image-2 journal

20.4.2.2 Habilitación de la función transaccional de imágenes #

La duplicación RBD utiliza las imágenes RBD transaccionales para garantizar que la imagen replicada siempre esté protegida contra fallos. Cuando se utiliza el modo de duplicación image, la función transaccional se habilita automáticamente si la duplicación está habilitada en la imagen. Cuando se utiliza el modo de duplicación pool, antes de que una imagen se pueda duplicar en un clúster conector, la función de imagen RBD transaccional debe estar habilitada. Se puede habilitar en el momento de crear la imagen proporcionando la opción ‑‑image-feature exclusive-lock,journaling al comando rbd.

Como alternativa, la función de registro transaccional se puede habilitar de forma dinámica en las imágenes RBD preexistentes. Para habilitar el registro transaccional, especifique el subcomando feature enable, el nombre del repositorio y la imagen y el nombre de la función:

cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lock
cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

Nota: dependencia de opciones

La función journaling (registro transaccional) depende de la función exclusive-lock (bloqueo exclusivo). Si la función exclusive-lock no está habilitada, deberá habilitarla antes que la función journaling.

Sugerencia

Puede habilitar la función transaccional en todas las imágenes nuevas por defecto añadiendo rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling al archivo de configuración de Ceph.

20.4.2.3 Creación de instantáneas de duplicación de la imagen #

Si se utiliza la duplicación basada en instantáneas, será necesario crear instantáneas de duplicación siempre que se desee duplicar el contenido modificado de la imagen RBD. Para crear una instantánea de duplicación manualmente con rbd, especifique el comando mirror image snapshot junto con el nombre del repositorio y la imagen:

cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME

Por ejemplo:

cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1

Por defecto, solo se crearán tres instantáneas de duplicación por imagen. La instantánea de duplicación más reciente se elimina automáticamente si se alcanza el límite. El límite se puede anular mediante la opción de configuración rbd_mirroring_max_mirroring_snapshots si es necesario. Además, las instantáneas de duplicación se suprimen automáticamente cuando se elimina la imagen o cuando se inhabilita la duplicación.

Las instantáneas de duplicación también se pueden crear automáticamente de forma periódica si se programa. La instantánea de duplicación se puede programar a nivel global, por repositorio o por imagen. Se pueden definir varias programaciones de instantáneas de duplicación en cualquier nivel, pero solo se ejecutarán las programaciones más específicas que coincidan con una imagen duplicada individual.

Para crear una programación de instantáneas de duplicación con rbd, especifique el comando mirror snapshot schedule add junto con un nombre de repositorio o imagen opcional, un intervalo y una hora de inicio opcional.

El intervalo se puede especificar en días, horas o minutos mediante los sufijos d, h o m, respectivamente. La hora de inicio opcional se puede especificar mediante el formato de hora ISO 8601. Por ejemplo:

cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00
cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h

Para eliminar una programación de instantáneas de duplicación con rbd, especifique el comando mirror snapshot schedule remove con opciones que coincidan con el comando correspondiente para añadir una programación.

Para todas las programaciones de instantáneas para un nivel específico (global, repositorio o imagen) con rbd, especifique el comando mirror snapshot schedule ls junto con un nombre de repositorio o imagen opcional. Además, se puede especificar la opción --recursive para mostrar todas las programaciones en el nivel especificado e inferior. Por ejemplo:

cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL        NAMESPACE IMAGE  SCHEDULE
image-pool  -         -      every 1d starting at 14:00:00-05:00
image-pool            image1 every 6h

Para saber cuándo se crearán las siguientes instantáneas para las imágenes RBD de duplicación basadas en instantáneas con rbd, especifique el comando mirror snapshot schedule status junto con un nombre de repositorio o imagen opcional. Por ejemplo:

cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME       IMAGE
2020-02-26 18:00:00 image-pool/image1

20.4.2.4 Inhabilitación de la duplicación de imágenes #

Para habilitar la duplicación de una imagen concreta, especifique el subcomando mirror image disable junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

20.4.2.5 Subida y bajada de nivel de imágenes #

En una situación de failover en la que sea necesario mover la designación primara a la imagen del clúster conector, debe detener el acceso a la imagen principal, bajarla de nivel, subir el nivel de la nueva imagen principal y reanudar el acceso a la imagen en el clúster alternativo.

Nota: subida de nivel forzosa

Puede forzar la subida de nivel mediante la opción ‑‑force. Es necesario forzar la subida de nivel cuando la bajada de nivel no se puede propagar al clúster conector (por ejemplo, en caso de fallo del clúster o interrupción de la comunicación). Esto provocará una situación de división entre ambos conectores y la imagen dejará de sincronizarse hasta que se emita un subcomando resync.

Para bajar de nivel una imagen y convertirla en no principal, especifique el subcomando mirror image demote junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

Para bajar de nivel todas las imágenes principales de un repositorio a no principales, especifique el subcomando mirror pool demote junto con el nombre del repositorio:

cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME

Para subir de nivel una imagen y convertirla en principal, especifique el subcomando mirror image promote junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

Para subir de nivel todas las imágenes de un repositorio a principales, especifique el subcomando mirror pool promote junto con el nombre del repositorio:

cephuser@adm > rbd --cluster local mirror pool promote POOL_NAME

Sugerencia: división de la carga de E/S

Puesto que el estado primario o no primario se establece para cada imagen, es posible que haya dos clústeres que dividan la carga de E/S y el failover o failback por fases.

20.4.2.6 Forzado de la resincronización de la imagen #

Si el daemon rbd-mirror detecta un evento dividido, no intentará duplicar la imagen afectada hasta que se corrija. Para reanudar la duplicación de una imagen, primero baje de nivel la imagen considerada obsoleta y, a continuación, realice una petición de resincronización de la imagen principal. Para pedir una resincronización de la imagen, especifique el subcomando mirror image resync junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

20.4.3 Comprobación del estado de la duplicación #

El estado de replicación de clúster conector se almacena para cada imagen principal duplicada. Este estado se puede recuperar mediante los subcomandos mirror image status y mirror pool status:

Para pedir el estado de la imagen duplicada, especifique el subcomando mirror image status junto con el nombre del repositorio y el de la imagen:

cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

Para pedir el estado resumido del repositorio de duplicación, especifique el subcomando mirror pool status junto con el nombre del repositorio:

cephuser@adm > rbd mirror pool status POOL_NAME

Sugerencia:

Si se añade la opción ‑‑verbose al subcomando mirror pool status, también se mostrará la información de estado de todas las imágenes duplicadas del repositorio.

20.5 Ajustes de caché #

La implementación del espacio de usuario del dispositivo de bloques Ceph (librbd) no puede hacer uso del caché de paginación de Linux. Por lo tanto, incluye su propio almacenamiento en caché en memoria. El almacenamiento en caché de RBD tiene un comportamiento similar al almacenamiento en caché del disco duro. Cuando el sistema operativo envía una barrera o una petición de vaciado, todos los datos "sucios" se escriben en los OSD. Esto significa que el uso del almacenamiento en caché en modo write-back es tan seguro como usar un disco duro físico de buen comportamiento con una máquina virtual que envía correctamente los vaciados. La memoria caché utiliza un algoritmo LRU (del inglés Least Recently Used, menos usadas recientemente) y, en el modo write-back, puede combinar peticiones adyacentes para obtener un mejor rendimiento.

Ceph admite el modo write-back de almacenamiento en caché para los RBD. Para habilitarlo, ejecute:

cephuser@adm > ceph config set client rbd_cache true

Por defecto, librbd no realiza ningún almacenamiento en caché. Las escrituras y lecturas van directamente al clúster de almacenamiento. Las escrituras solo se devuelven cuando los datos están en el disco en todas las réplicas. Con el almacenamiento en caché habilitado, las escrituras se devuelven de inmediato, a menos que haya más bytes sin vaciar de los definidos en la opción rbd cache max dirty. En tal caso, la escritura activa la escritura diferida y se bloquea hasta que se vacían suficientes bytes.

Ceph admite el modo write-through de almacenamiento en caché para los RBD. Es posible definir el tamaño de la memoria caché y establecer destinos y límites para cambiar del modo write-back al modo write-through de almacenamiento en caché. Para habilitar el modo write-through, ejecute:

cephuser@adm > ceph config set client rbd_cache_max_dirty 0

Esto significa que las escrituras solo se devuelven cuando los datos están en el disco en todas las réplicas, pero las lecturas pueden provenir de la memoria caché. La memoria caché está en memoria en el cliente y cada imagen RBD tiene su propia memoria caché. Puesto que la memoria caché es local para el cliente, si hay otros usuarios que acceden a la imagen, la coherencia se pierde. Ejecutar GFS u OCFS sobre el RBD no funcionará si el almacenamiento en caché está habilitado.

Los siguientes parámetros afectan al comportamiento de los dispositivos de bloques RADOS. Para definirlos, utilice la categoría client:

cephuser@adm > ceph config set client PARAMETER VALUE

rbd cache: Habilita el almacenamiento en caché para el dispositivo de bloques RADOS (RBD). El valor por defecto es "true" (verdadero).
rbd cache size: El tamaño de la memoria caché del RBD en bytes. El valor por defecto es 32 MB.
rbd cache max dirty: El límite de bytes "sucios" en el que la memoria caché activa el modo write-back. El valor de rbd cache max dirty debe ser menor que el de rbd cache size. Si se define en 0, se utiliza el almacenamiento en caché en modo write-through. El valor por defecto es 24 MB.
rbd cache target dirty: El "destino sucio" antes de que la memoria caché comience a escribir datos en el almacenamiento de datos. No bloquea las escrituras en la memoria caché. El valor por defecto es 16 MB.
rbd cache max dirty age: El número de segundos que los datos sucios están en la memoria caché antes de que se inicie la escritura diferida. El valor por defecto es 1.
rbd cache writethrough until flush: Comienza en modo write-through y cambia al modo write-back después de que se reciba la primera petición de vaciado. Habilitar esta opción es una medida conservadora pero segura en caso de que las máquinas virtuales que se ejecutan en rbd sean demasiado antiguas para enviar vaciados (por ejemplo, el controlador virtio de Linux antes del kernel 2.6.32). El valor por defecto es "true" (verdadero).

20.6 Ajuste de QoS #

Por norma general, la calidad de servicio (QoS) hace referencia a los métodos de priorización del tráfico y de reserva de recursos. Es particularmente importante para el transporte del tráfico con requisitos especiales.

Importante: no es compatible con iSCSI

Los ajustes de QoS siguientes solo se utilizan en la implementación librbd del RBD de espacio de nombres, pero no por la implementación kRBD. Dado que iSCSI utiliza kRBD, no utiliza los valores de QoS. Sin embargo, para iSCSI puede configurar QoS en la capa de dispositivo de bloques del kernel mediante instalaciones del kernel estándar.

rbd qos iops limit: El límite deseado de operaciones de E/S por segundo. El valor por defecto es 0 (sin límite).
rbd qos bps limit: El límite deseado de bytes de E/S por segundo. El valor por defecto es 0 (sin límite).
rbd qos read iops limit: El límite deseado de operaciones de lectura por segundo. El valor por defecto es 0 (sin límite).
rbd qos write iops limit: El límite deseado de operaciones de escritura por segundo. El valor por defecto es 0 (sin límite).
rbd qos read bps limit: El límite deseado de bytes de lectura por segundo. El valor por defecto es 0 (sin límite).
rbd qos write bps limit: El límite deseado de bytes de escritura por segundo. El valor por defecto es 0 (sin límite).
rbd qos iops burst: El límite de ráfaga deseado de operaciones de E/S. El valor por defecto es 0 (sin límite).
rbd qos bps burst: El límite de ráfaga deseado de bytes de E/S. El valor por defecto es 0 (sin límite).
rbd qos read iops burst: El límite de ráfaga deseado de operaciones de lectura. El valor por defecto es 0 (sin límite).
rbd qos write iops burst: El límite de ráfaga deseado de operaciones de escritura. El valor por defecto es 0 (sin límite).
rbd qos read bps burst: El límite de ráfaga deseado de bytes de lectura. El valor por defecto es 0 (sin límite).
rbd qos write bps burst: El límite de ráfaga deseado de bytes de escritura. El valor por defecto es 0 (sin límite).
rbd qos schedule tick min: La pulsación de programación mínima (en milisegundos) para QoS. El valor por defecto es 50.

20.7 Ajustes de lectura anticipada #

El dispositivo de bloques RADOS admite la lectura anticipada y la captura previa para optimizar las lecturas pequeñas y secuenciales. Normalmente, el sistema operativo invitado se encargaría de gestionar esta función en una máquina virtual, pero es posible que los cargadores de arranque no emitan lecturas eficientes. La lectura anticipada se inhabilita automáticamente si el almacenamiento en caché está inhabilitado.

Importante: no es compatible con iSCSI

Los ajustes de lectura anticipada siguientes solo se utilizan en la implementación librbd del RBD de espacio de nombres, pero no por la implementación kRBD. Dado que iSCSI utiliza kRBD, no utiliza los ajustes de lectura anticipada. Sin embargo, para iSCSI puede configurar la lectura anticipada en la capa de dispositivo de bloques del kernel mediante instalaciones del kernel estándar.

rbd readahead trigger requests: El número de peticiones de lectura secuenciales necesarias para activar la lectura anticipada. El valor por defecto es 10.
rbd readahead max bytes: El tamaño máximo de una petición de lectura anticipada. Si se define en 0, la lectura anticipada estará inhabilitada. El valor por defecto es 512 kB.
rbd readahead disable after bytes: Después de que se hayan leído este número de bytes de una imagen RBD, la lectura anticipada se inhabilita para esa imagen hasta que se cierra. Esto permite que el sistema operativo invitado recupere la función de lectura anticipada cuando se arranca. Si se define en 0, la lectura anticipada sigue habilitada. El valor por defecto es 50 MB.

20.8 Funciones avanzadas #

El dispositivo de bloques RADOS admite funciones avanzadas que mejoran la funcionalidad de las imágenes RBD. Puede especificar las funciones en la línea de comandos cuando se crea una imagen RBD o en el archivo de configuración de Ceph mediante la opción rbd_default_features.

Es posible especificar los valores de la opción rbd_default_features de dos maneras:

Como una suma de los valores internos de las funciones. Cada función tiene su propio valor interno; por ejemplo, la "layering" tiene 1 y "fast-diff" tiene 16. Por lo tanto, para activar estas dos funciones por defecto, incluya lo siguiente:
```
rbd_default_features = 17
```
Como una lista separada por comas de funciones. El ejemplo anterior tendrá el siguiente aspecto:
```
rbd_default_features = layering,fast-diff
```

Nota: funciones no compatibles con iSCSI

Las imágenes RBD con las siguientes funciones no son compatibles con iSCSI: deep-flatten, object-map, journaling, fast-diff y striping

A continuación se muestra una lista de funciones avanzadas de RBD:

layering

La disposición en capas permite utilizar la clonación.

El valor interno es 1, el valor por defecto es "sí".

striping

La repartición striping distribuye los datos entre varios objetos y ayuda a las cargas de trabajo de lectura y escritura secuenciales mediante paralelismo. Evita los cuellos de botella en un solo nodo en dispositivos de bloques RADOS de gran volumen u ocupación.

El valor interno es 2, el valor por defecto es "sí".

exclusive-lock

Si está habilitado, requiere que un cliente obtenga un bloqueo en un objeto antes de realizar una escritura. Habilita el bloqueo exclusivo solo si un único cliente accede a una imagen al mismo tiempo. El valor interno es 4. El valor por defecto es "sí".

object-map

La compatibilidad con el mapa de objetos depende de la compatibilidad con el bloqueo exclusivo. Los dispositivos de bloque son de provisión ligera, lo que significa que solo almacenan datos que realmente existen. La compatibilidad con el mapa de objetos ayuda a realizar un seguimiento de los objetos que realmente existen (que tienen datos almacenados en una unidad). Al habilitar la compatibilidad con el mapa de objetos, se aceleran las operaciones de E/S para clonar, importar y exportar una imagen escasamente poblada y suprimirla.

El valor interno es 8, el valor por defecto es "sí".

fast-diff

La compatibilidad con diff rápida depende de la compatibilidad con el mapa de objetos y con el bloqueo exclusivo. Añade otra propiedad al mapa de objetos, lo que hace que sea mucho más rápido generar diffs entre las instantáneas de una imagen y el uso de datos real de una instantánea.

El valor interno es 16, el valor por defecto es "sí".

deep-flatten

El aplanamiento profundo hace que rbd flatten (consulte la Sección 20.3.3.6, “Aplanamiento de una imagen clonada”) funcione en todas las instantáneas de una imagen, además de en la propia imagen. Sin él, las instantáneas de una imagen seguirían dependiendo de la imagen padre y, por lo tanto, no se podría suprimir la imagen padre hasta que se eliminaran las instantáneas. El aplanamiento profundo provoca que una imagen padre sea independiente de sus clones, incluso si tienen instantáneas.

El valor interno es 32, el valor por defecto es "sí".

journaling

La compatibilidad con el registro transaccional depende de la compatibilidad con el bloqueo exclusivo. El registro transaccional guarda todas las modificaciones en una imagen en el orden en el que se producen. La duplicación del RBD (consulte la Sección 20.4, “Duplicados de imagen RBD”) utiliza el diario para replicar una imagen coherente con la detención por fallo en un clúster remoto.

El valor interno es 64 y el valor por defecto es "no".

20.9 Asignación del RBD utilizando clientes de kernel antiguos #

Es posible que los clientes antiguos (por ejemplo, SLE11 SP4) no puedan asignar imágenes RBD porque un clúster distribuido con SUSE Enterprise Storage 7.1 aplica algunas funciones (tanto funciones de nivel de imagen RBD como funciones de nivel de RADOS) que estos clientes antiguos no admiten. Si esto sucede, los registros del OSD mostrarán mensajes similares a los siguientes:

2019-05-17 16:11:33.739133 7fcb83a2e700  0 -- 192.168.122.221:0/1006830 >> \
192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \
protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000

Aviso: el cambio de tipos de depósito del mapa de CRUSH provoca un reequilibrio masivo

Si tiene previsto cambiar los tipos de depósito del mapa de CRUSH entre "straw" y "straw2", hágalo de una manera planificada. Tenga previsto que el impacto en la carga del clúster será significativo, ya que provocará un reequilibrio masivo del clúster.

Inhabilite las funciones de la imagen RBD que no sean compatibles. Por ejemplo:

cephuser@adm > rbd feature disable pool1/image1 object-map
cephuser@adm > rbd feature disable pool1/image1 exclusive-lock

Cambie los tipos de depósito del mapa de CRUSH de "straw2" a "straw":
1. Guarde el mapa de CRUSH:
```
cephuser@adm > ceph osd getcrushmap -o crushmap.original
```
2. Descompile el mapa de CRUSH.
```
cephuser@adm > crushtool -d crushmap.original -o crushmap.txt
```
3. Edite el mapa de CRUSH y sustituya "straw2" por "straw".
4. Vuelva a compilar el mapa de CRUSH:
```
cephuser@adm > crushtool -c crushmap.txt -o crushmap.new
```
5. Defina el nuevo mapa de CRUSH:
```
cephuser@adm > ceph osd setcrushmap -i crushmap.new
```

20.10 Habilitación de dispositivos de bloques y Kubernetes #

Puede usar RBD de Ceph con Kubernetes 1.13 y versiones posteriores mediante el controlador ceph-csi. Este controlador proporciona imágenes RBD de forma dinámica para respaldar los volúmenes de Kubernetes y asigna estas imágenes RBD como dispositivos de bloques (montando opcionalmente un sistema de archivos incluido en la imagen) en nodos de trabajo que ejecutan pods que hacen referencia a un volumen respaldado por RBD.

Para utilizar dispositivos de bloques de Ceph con Kubernetes, debe instalar y configurar ceph-csi en el entorno de Kubernetes.

Importante

ceph-csi utiliza los módulos del kernel de RBD por defecto, que quizás no admitan todos los elementos ajustables de Ceph CRUSH o las funciones de imagen RBD.

Por defecto, los dispositivos de bloques de Ceph utilizan el repositorio de RBD. Cree un repositorio para el almacenamiento de volúmenes de Kubernetes. Asegúrese de que el clúster de Ceph se está ejecutando y, a continuación, cree el repositorio:
```
cephuser@adm > ceph osd pool create kubernetes
```
Utilice la herramienta RBD para inicializar el repositorio:
```
cephuser@adm > rbd pool init kubernetes
```

Cree un nuevo usuario para Kubernetes y ceph-csi. Ejecute lo siguiente y guarde la clave generada:

cephuser@adm > ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'
[client.kubernetes]
    key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==

ceph-csi requiere un objeto ConfigMap almacenado en Kubernetes para definir las direcciones del monitor de Ceph para el clúster de Ceph. Recopile tanto el fsid exclusivo del clúster de Ceph como las direcciones del monitor:

cephuser@adm > ceph mon dump
<...>
fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8
<...>
0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a
1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b
2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c

Genere un archivo csi-config-map.yaml similar al ejemplo siguiente, sustituyendo el FSID por clusterID y las direcciones de monitor por monitors.

kubectl@adm > cat <<EOF > csi-config-map.yaml
---
apiVersion: v1
kind: ConfigMap
data:
  config.json: |-
    [
      {
        "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8",
        "monitors": [
          "192.168.1.1:6789",
          "192.168.1.2:6789",
          "192.168.1.3:6789"
        ]
      }
    ]
metadata:
  name: ceph-csi-config
EOF

Cuando se genere, almacene el nuevo objeto ConfigMap en Kubernetes:
```
kubectl@adm > kubectl apply -f csi-config-map.yaml
```
ceph-csi requiere las credenciales de cephx para comunicarse con el clúster de Ceph. Genere un archivo csi-rbd-secret.yaml similar al ejemplo siguiente, utilizando el ID de usuario de Kubernetes y la clave de cephx recién creados:
```
kubectl@adm > cat <<EOF > csi-rbd-secret.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: default
stringData:
  userID: kubernetes
  userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==
EOF
```
Cuando se genere, guarde el nuevo objeto de secreto en Kubernetes:
```
kubectl@adm > kubectl apply -f csi-rbd-secret.yaml
```
Cree los objetos ServiceAccount y RBAC ClusterRole/ClusterRoleBinding necesarios de Kubernetes. No es obligatorio personalizar estos objetos para el entorno de Kubernetes y, por lo tanto, se pueden utilizar directamente desde los archivos YAML de distribución de ceph-csi:
```
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
```

Cree el aprovisionador ceph-csi y los complementos de nodo:

kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin-provisioner.yaml
kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin.yaml

Importante

Por defecto, los archivos YAML del aprovisionador y del complemento de nodo extraerán la versión de desarrollo del contenedor de ceph-csi. Los archivos YAML deben actualizarse para utilizar una versión de lanzamiento.

20.10.1 Uso de dispositivos de bloques de Ceph en Kubernetes #

Kubernetes StorageClass define una clase de almacenamiento. Se pueden crear varios objetos StorageClass para asignarlos a diferentes niveles y funciones de calidad de servicio. Por ejemplo, NVMe frente a los repositorios basados en discos duros.

Para crear un objeto StorageClass de ceph-csi que se asigne al repositorio de Kubernetes creado anteriormente, se puede usar el siguiente archivo YAML, después de asegurarse de que la propiedad clusterID coincide con el FSID del clúster de Ceph:

kubectl@adm > cat <<EOF > csi-rbd-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8
   pool: kubernetes
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: default
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete
mountOptions:
   - discard
EOF
kubectl@adm > kubectl apply -f csi-rbd-sc.yaml

Una PersistentVolumeClaim es una petición de recursos de almacenamiento abstractos por parte de un usuario. La PersistentVolumeClaim se asociará a un recurso de pod para aprovisionar un PersistentVolume, que estaría respaldado por una imagen de bloque de Ceph. Se puede incluir un volumeMode opcional para seleccionar entre un sistema de archivos montado (por defecto) o un volumen basado en dispositivos de bloques en bruto.

Con ceph-csi, especificando Filesystem para volumeMode puede admitir peticiones tanto ReadWriteOnce como ReadOnlyMany accessMode; y especificando Block para volumeMode puede admitir peticiones ReadWriteOnce, ReadWriteMany y ReadOnlyMany accessMode.

Por ejemplo, para crear una petición PersistentVolumeClaim basada en bloques que utilice la ceph-csi-based StorageClass creada anteriormente, se puede utilizar el siguiente archivo YAML para pedir almacenamiento de bloques en bruto desde csi-rbd-sc StorageClass:

kubectl@adm > cat <<EOF > raw-block-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: raw-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f raw-block-pvc.yaml

A continuación, se muestra un ejemplo de asociación de la PersistentVolumeClaim anterior a un recurso de pod como dispositivo de bloques en bruto:

kubectl@adm > cat <<EOF > raw-block-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-raw-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: ["tail -f /dev/null"]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: raw-block-pvc
EOF
kubectl@adm > kubectl apply -f raw-block-pod.yaml

Para crear una PersistentVolumeClaim basad en un sistema de archivos que utilice la clase cceph-csi-based StorageClass creada anteriormente, se puede utilizar el siguiente archivo YAML para pedir un sistema de archivos montado (respaldado por una imagen RBD) desde la clase csi-rbd-sc StorageClass:

kubectl@adm > cat <<EOF > pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f pvc.yaml

A continuación, se muestra un ejemplo de asociación de la PersistentVolumeClaim anterior a un recurso de pod como sistema de archivos montado:

kubectl@adm > cat <<EOF > pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: mypvc
          mountPath: /var/lib/www/html
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false
EOF
kubectl@adm > kubectl apply -f pod.yaml

20 Dispositivo de bloques RADOS #

20.1 Comandos del dispositivo de bloques #

20.1.1 Creación de una imagen del dispositivo de bloques en un repositorio replicado #

20.1.2 Creación de una imagen del dispositivo de bloques en un repositorio codificado de borrado #

20.1.3 Listado de imágenes de dispositivos de bloques #

20.1.4 Recuperación de información de la imagen #

20.1.5 Cambio de tamaño de la imagen de un dispositivo de bloques #

20.1.6 Eliminación de una imagen de dispositivo de bloques #

20.2 Montaje y desmontaje #

20.2.1 Creación de una cuenta de usuario de Ceph #

20.2.2 Autenticación de usuarios #

20.2.3 Preparación de un dispositivo de bloques RADOS para su uso #

20.2.4 rbdmap: asignación de dispositivos RBD durante el arranque #

20.2.5 Aumento del tamaño de dispositivos RBD #

20.3 Instantáneas #

20.3.1 Habilitación y configuración de cephx #

20.3.2 Conceptos básicos sobre instantáneas #

20.3.2.1 Creación de instantáneas #

20.3.2.2 Listado de instantáneas #

20.3.2.3 Reversión de instantáneas #

20.3.2.4 Supresión de una instantánea #

20.3.2.5 Limpieza de instantáneas #

20.3.3 Capas de instantáneas #

20.3.3.1 Procedimientos iniciales con las capas #

20.3.3.2 Protección de una instantánea #

20.3.3.3 Clonación de una instantánea #

20.3.3.4 Desprotección de una instantánea #

20.3.3.5 Listado de los hijos de una instantánea #

20.3.3.6 Aplanamiento de una imagen clonada #

20.4 Duplicados de imagen RBD #

20.4.1 Configuración del repositorio #

20.4.1.1 Habilitación de la duplicación en un repositorio #

20.4.1.2 Inhabilitación de la duplicación #

20.4.1.3 Conectores de carga #

20.4.1.4 Adición manual de un conector de clúster #

20.4.1.5 Eliminación de un clúster conector #

20.4.1.6 Repositorios de datos #

20.4.2 Configuración de la imagen RBD #

20.4.2.1 Habilitación de la duplicación de imágenes #

20.4.2.2 Habilitación de la función transaccional de imágenes #

20.4.2.3 Creación de instantáneas de duplicación de la imagen #

20.4.2.4 Inhabilitación de la duplicación de imágenes #

20.4.2.5 Subida y bajada de nivel de imágenes #

20.4.2.6 Forzado de la resincronización de la imagen #

20.4.3 Comprobación del estado de la duplicación #

20.5 Ajustes de caché #

20.6 Ajuste de QoS #

20.7 Ajustes de lectura anticipada #

20.8 Funciones avanzadas #

20.9 Asignación del RBD utilizando clientes de kernel antiguos #

20.10 Habilitación de dispositivos de bloques y Kubernetes #

20.10.1 Uso de dispositivos de bloques de Ceph en Kubernetes #

20.2.4 `rbdmap`: asignación de dispositivos RBD durante el arranque #

20.3.1 Habilitación y configuración de `cephx` #