Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

12 Dispositivo de bloques RADOS Edit source

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.

Protocolo RADOS
Figura 12.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.

12.1 Comandos del dispositivo de bloques Edit source

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.

12.1.1 Creación de una imagen del dispositivo de bloques en un repositorio replicado Edit source

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 11, Gestión de repositorios de almacenamiento):

cephadm@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:

cephadm@adm > rbd create --size 1024 mypool/myimage
Sugerencia
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.

12.1.2 Creación de una imagen del dispositivo de bloques en un repositorio codificado de borrado Edit source

A partir de SUSE Enterprise Storage 5, 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 el valor true definido en el indicador "overwrite", y eso solo es posible si todos los OSD donde se almacena el repositorio utilizan BlueStore.

No se puede almacenar la parte de "metadatos" de la imagen en un repositorio codificado de borrado. Debe especificar el repositorio replicado para almacenar los metadatos de la imagen con la opción ‑‑pool del comando rbd create.

Lleve a cabo los pasos siguientes para crear una imagen RBD en un repositorio codificado de borrado recién creado:

cephadm@adm > ceph osd pool create POOL_NAME 12 12 erasure
cephadm@adm > ceph osd pool set POOL_NAME allow_ec_overwrites true

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"
cephadm@adm > rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

12.1.3 Enumeración de imágenes de dispositivos de bloques Edit source

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

cephadm@adm > rbd ls mypool

12.1.4 Recuperación de información de la imagen Edit source

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

cephadm@adm > rbd info mypool/myimage

12.1.5 Cambio de tamaño de la imagen de un dispositivo de bloques Edit source

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:

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

12.1.6 Eliminación de una imagen de dispositivo de bloques Edit source

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

cephadm@adm > rbd rm mypool/myimage

12.2 Montaje y desmontaje Edit source

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.

  1. 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.

    cephadm@adm > rbd list mypool
  2. Asigne la imagen a un nuevo dispositivo de bloques.

    cephadm@adm > rbd map --pool mypool myimage
    Sugerencia
    Sugerencia: nombre de usuario y autenticación

    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:

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

    O bien

    cephadm@adm > rbd map --pool rbd myimage --id admin --keyfile /path/to/file
  3. Enumerar todos los dispositivos asignados:

    cephadm@adm > rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0

    El dispositivo en el que queremos trabajar es /dev/rbd0.

    Sugerencia
    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
  4. Cree un sistema de archivos XFS en el dispositivo /dev/rbd0.

    root # 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
  5. Monte el dispositivo y compruebe que está montado correctamente. Sustituya /mnt por el punto de montaje.

    root # mount /dev/rbd0 /mnt
    root # 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
    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.

      cephadm@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.

      root # xfs_growfs /mnt
       [...]
       data blocks changed from 2097152 to 2560000
  6. Cuando termine de acceder al dispositivo, puede desasignarlo y desmontarlo.

    cephadm@adm > rbd unmap /dev/rbd0
    root # unmount /mnt
Sugerencia
Sugerencia: montaje o desmontaje manual

Dado que asignar y montar las imágenes RBD manualmente después del arranque y desmontarlas y desasignarlas antes de apagar el equipo puede resultar tedioso, se proporciona un guion rbdmap y una unidad systemd. Consulte la Sección 12.2.1, “rbdmap: asignación de dispositivos RBD durante el arranque”.

12.2.1 rbdmap: asignación de dispositivos RBD durante el arranque Edit source

rbdmap es un guion de shell que automatiza las operaciones rbd map y rbd 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 ceph-common incluye el archivo de unidad systemd rbdmap.service.

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 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:

cephadm@adm > rbd 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:

cephadm@adm > rbdmap 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 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 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).

12.2.2 aumento del tamaño del dispositivo RBD Edit source

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.

    cephadm@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.

    root # xfs_growfs /mnt
     [...]
     data blocks changed from 2097152 to 2560000

12.3 Instantáneas Edit source

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
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.

12.3.1 Notas de cephx Edit source

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 8, 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.

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

Por ejemplo:

cephadm@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephadm@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands
Sugerencia
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.

12.3.2 Conceptos básicos de la instantánea Edit source

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

12.3.2.1 Creación de instantáneas Edit source

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

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

Por ejemplo:

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

12.3.2.2 Enumeración de instantáneas Edit source

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

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

Por ejemplo:

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

12.3.2.3 Reversión de instantáneas Edit source

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.

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

Por ejemplo:

cephadm@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephadm@adm > rbd snap rollback pool1/image1@snapshot1
Nota
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.

12.3.2.4 Supresión de una instantánea Edit source

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.

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

Por ejemplo:

cephadm@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephadm@adm > rbd snap rm pool1/image1@snapshot1
Nota
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.

12.3.2.5 Limpieza de instantáneas Edit source

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

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

Por ejemplo:

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

12.3.3 Capas Edit source

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
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
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.

12.3.3.1 Procedimientos iniciales con las capas Edit source

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.

12.3.3.2 Protección de una instantánea Edit source

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.

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

Por ejemplo:

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

No es posible suprimir una instantánea protegida.

12.3.3.3 Clonación de una instantánea Edit source

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.

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

Por ejemplo:

cephadm@adm > rbd clone pool1/image1@snapshot1 pool1/image2
Nota
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.

12.3.3.4 Desprotección de una instantánea Edit source

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.

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

Por ejemplo:

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

12.3.3.5 Enumeración de los hijos de una instantánea Edit source

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

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

Por ejemplo:

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

12.3.3.6 Aplanamiento de una imagen clonada Edit source

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.

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

Por ejemplo:

cephadm@adm > rbd --pool pool1 flatten --image image1
cephadm@adm > rbd flatten pool1/image1
Nota
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.

12.4 Duplicación Edit source

Las imágenes RBD se pueden duplicar de forma asincrónica entre dos clústeres de Ceph. Esta función utiliza las imágenes RBD transaccionales para garantizar la replicación protegida contra bloqueos entre los clústeres. La duplicación se configura para cada repositorio con clústeres conectores y se puede configurar para que duplique automáticamente todas las imágenes de un repositorio o solo un subconjunto específico de imágenes. 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 en el clúster conector remoto y de aplicarlos a la imagen en el clúster local.

Nota
Nota: daemon rbd-mirror

Para utilizar la duplicación RBD, debe disponer de dos clústeres Ceph con el daemon rbd-mirror en ejecución en ambos.

Importante
Importante: dispositivos de bloques RADOS exportados a través de iSCSI

No es posible duplicar los dispositivos RBD que se exportan a través de iSCSI mediante una pasarela iSCSI Gateway basada en el kernel.

Consulte el Capítulo 18, Ceph iSCSI Gateway para obtener más detalles sobre iSCSI.

12.4.1 Daemon rbd-mirror Edit source

Los dos daemons rbd-mirror son responsables de vigilar los diarios transaccionales de las imágenes en el clúster conector remoto y reproducir los eventos del diario en el clúster local. Las imágenes RBD transaccionales almacenan todas las modificaciones realizadas en la imagen en el orden en que se producen. Esto garantiza que exista localmente una duplicación de la imagen remota protegida contra errores.

El daemon rbd-mirror está disponible en el paquete rbd-mirror. Puede instalar el paquete en nodos OSD, nodos de pasarela o incluso en nodos dedicados. No se recomienda instalar el daemon rbd-mirror en el nodo de administración. Para instalar, habilitar e iniciar rbd-mirror:

root@minion > zypper install rbd-mirror
root@minion > systemctl enable ceph-rbd-mirror@server_name.service
root@minion > systemctl start ceph-rbd-mirror@server_name.service
Importante
Importante

Cada daemon rbd-mirror requiere la capacidad de conectarse a ambos clústeres de forma simultánea.

12.4.2 Configuración del repositorio Edit source

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", accesibles 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
Sugerencia: varios clústeres

En los siguientes ejemplos, el nombre del clúster se corresponde con un archivo de configuración de Ceph con el mismo nombre /etc/ceph/remote.conf.

12.4.2.1 Cómo habilitar la duplicación en un repositorio Edit source

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 la Sección 12.4.3.2, “Cómo habilitar la duplicación de imágenes” para obtener más información.

Por ejemplo:

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

12.4.2.2 Cómo inhabilitar la duplicación Edit source

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.

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

12.4.2.3 Adición de un clúster conector Edit source

Para que el daemon rbd-mirror descubra su clúster conector, el conector debe estar registrado en el repositorio. Para añadir un clúster conector duplicado, especifique el subcomando mirror pool peer add, el nombre del repositorio y una especificación de clúster:

cephadm@adm > rbd --cluster local mirror pool peer add POOL_NAME client.remote@remote
cephadm@adm > rbd --cluster remote mirror pool peer add POOL_NAME client.local@local

12.4.2.4 Eliminación de un clúster conector Edit source

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):

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

12.4.3 Configuración de la imagen Edit source

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 12.4.3.2, “Cómo habilitar la duplicación de imágenes”], mediante el comando rbd).

12.4.3.1 Compatibilidad con imágenes transaccionales Edit source

La duplicación RBD utiliza las imágenes RBD transaccionales para garantizar que la imagen replicada siempre esté protegida contra fallos. Para que una imagen se pueda duplicar en un clúster conector, es necesario habilitar la función de registro transaccional. La función se puede habilitar en el momento de creación de 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:

cephadm@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling
Nota
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.

Aviso
Aviso: registro transaccional en todas las imágenes nuevas

Puede habilitar el registro transaccional en todas las imágenes nuevas por defecto añadiendo el valor journaling al final de la opción rbd default features en el archivo de configuración de Ceph. Por ejemplo:

rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling

Antes de aplicar este cambio, considere cuidadosamente si habilitar el registro transaccional en todas las imágenes nuevas es beneficioso para la distribución, ya que puede afectar negativamente al rendimiento.

12.4.3.2 Cómo habilitar la duplicación de imágenes Edit source

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

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

12.4.3.3 Cómo inhabilitar la duplicación de imágenes Edit source

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:

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

12.4.3.4 Cómo bajar o subir de nivel una imagen Edit source

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
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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > rbd --cluster local mirror pool promote POOL_NAME
Sugerencia
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.

12.4.3.5 Cómo forzar la resincronización de la imagen Edit source

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:

cephadm@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

12.4.4 Estado de la duplicación Edit source

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:

cephadm@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:

cephadm@adm > rbd mirror pool status POOL_NAME
Sugerencia
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.

12.5 Ajustes de caché Edit source

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, añada:

[client]
...
rbd cache = true

a la sección [client] del archivo ceph.conf. 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, defina:

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 valores del archivo ceph.conf para el RBD deben definirse en la sección [client] del archivo de configuración. Algunos de los valores son:

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).

12.6 Configuración de QoS Edit source

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
Importante: no es compatible con iSCSI

Los valores 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.

12.7 Configuración de lectura anticipada Edit source

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.

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.

12.8 Funciones avanzadas Edit source

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
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 12.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 12.4, “Duplicación”) 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".

12.9 Asignación del RBD utilizando clientes de kernel antiguos Edit source

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 6 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
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.

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

    cephadm@adm > rbd feature disable pool1/image1 object-map
    cephadm@adm > rbd feature disable pool1/image1 exclusive-lock
  2. Cambie los tipos de depósito del mapa de CRUSH de "straw2" a "straw":

    1. Guarde el mapa de CRUSH:

      cephadm@adm > ceph osd getcrushmap -o crushmap.original
    2. Descompile el mapa de CRUSH.

      cephadm@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:

      cephadm@adm > crushtool -c crushmap.txt -o crushmap.new
    5. Defina el nuevo mapa de CRUSH:

      cephadm@adm > ceph osd setcrushmap -i crushmap.new
Imprimir esta página