Se aplica a SUSE Enterprise Storage 7

19 Repositorios codificados de borrado #

Ceph ofrece una alternativa a la réplica normal de datos en repositorios denominada borrado o repositorio codificado de borrado. Los repositorios de borrado no proporcionan todas las funciones de los repositorios replicados (por ejemplo, no pueden almacenar metadatos para los repositorios RBD), pero requieren menos almacenamiento en bruto. Un repositorio de borrado por defecto capaz de almacenar 1 TB de datos requiere 1,5 TB de almacenamiento en bruto, lo que permite un único fallo del disco. Esto es una ventaja respecto a un repositorio replicado, que necesita 2 TB de almacenamiento en bruto para el mismo propósito.

Para obtener información básica sobre la codificación de borrado, consulte https://en.wikipedia.org/wiki/Erasure_code.

Para obtener una lista de los valores de repositorio relacionados con los repositorios codificados de borrado, consulte Valores de repositorio codificado de borrado.

19.1 Requisitos previos para los repositorios codificados de borrado #

Para hacer uso de la codificación de borrado, debe hacer lo siguiente:

Defina una regla de borrado en el mapa de CRUSH.
Defina un perfil codificado de borrado que especifique el algoritmo de codificación que se debe utilizar.
Cree un repositorio utilizando la regla y el perfil mencionados anteriormente.

Tenga en cuenta que cambiar el perfil y sus detalles no será posible después de que se cree el repositorio y de que tenga datos.

Asegúrese de que las reglas de CRUSH para los repositorios de borrado utilizan indep para step. Para obtener información, consulte la Sección 17.3.2, “firstn e indep”.

19.2 Creación de un repositorio codificado de borrado de ejemplo #

El repositorio codificado de borrado más sencillo es equivalente a RAID5 y requiere al menos tres hosts. Este procedimiento describe cómo crear un repositorio con fines de prueba.

El comando ceph osd pool create se utiliza para crear un repositorio de tipo erasure. El 12 significa el número de grupos de colocación. Con los parámetros por defecto, el repositorio es capaz de gestionar situaciones en las que falle un OSD.
```
cephuser@adm > ceph osd pool create ecpool 12 12 erasure
pool 'ecpool' created
```

La cadena ABCDEFGHI se escribe en un objeto denominado NYAN.

cephuser@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -

Con fines de prueba, los OSD se pueden inhabilitar ahora, por ejemplo, desconectándolos de la red.
Para probar si el repositorio puede gestionar el fallo de dispositivos, se puede acceder al contenido del archivo con el comando rados.
```
cephuser@adm > rados --pool ecpool get NYAN -
ABCDEFGHI
```

19.3 Perfiles de código de borrado #

Cuando se invoca el comando ceph osd pool create para crear un repositorio de borrado, se utiliza el perfil por defecto, a menos que se especifique otro perfil distinto. Los perfiles definen la redundancia de los datos. Para ello se definen dos parámetros, que reciben el nombre arbitrario de k y m. Los parámetros k y m definen en cuántas porciones se divide un dato y cuántas porciones de codificación se crean. Las porciones redundantes se almacenan en diferentes OSD.

Definiciones necesarias para los perfiles de repositorio de borrado:

porción: Cuando se llama a la función de codificación, se devuelven porciones del mismo tamaño: porciones de datos que pueden concatenarse para reconstruir el objeto original y porciones de codificación que se pueden usar para reconstruir una porción perdida.
k: El número de porciones de datos, que es el número de porciones en las que se divide el objeto original. Por ejemplo, si k = 2, un objeto de 10 kB se divide en k objetos de 5 kB. El valor de min_size por defecto en los repositorios codificados de borrado es k + 1. Sin embargo, se recomienda que min_size sea k + 2 o más para evitar la pérdida de escrituras y datos.
m: El número de porciones de codificación, que es el número de porciones adicionales calculadas por las funciones de codificación. Si hay 2 porciones de codificación, significa que pueden fallar dos OSD sin que se pierda ningún dato.
crush-failure-domain: Define a qué dispositivos se distribuyen las porciones. Como valor se debe definir un tipo de depósito. Para ver todos los tipos de depósitos, consulte la Sección 17.2, “Depósitos”. Si el dominio de fallo es rack, las porciones se almacenarán en bastidores diferentes para aumentar la capacidad de recuperación en caso de fallos del bastidor. Tenga en cuenta que esto requiere bastidores k + m.

Con el perfil codificado de borrado por defecto utilizado en la Sección 19.2, “Creación de un repositorio codificado de borrado de ejemplo”, no perderá datos del clúster si se produce un error en un único OSD o host. Por lo tanto, para almacenar 1 TB de datos, necesita otros 0,5 TB de almacenamiento en bruto. Eso significa que se necesitan 1,5 TB de almacenamiento en bruto para 1 TB de datos (dado que k = 2, m = 1). Esto equivale a una configuración RAID5 común. En comparación, un repositorio replicado necesita 2 TB de almacenamiento en bruto para almacenar 1 TB de datos.

Para mostrar los valores del perfil por defecto:

cephuser@adm > ceph osd erasure-code-profile get default
directory=.libs
k=2
m=1
plugin=jerasure
crush-failure-domain=host
technique=reed_sol_van

Es importante elegir el perfil correcto, ya que no se puede modificar después de que se cree el repositorio. Se debe crear un repositorio nuevo con un perfil distinto y todos los objetos del repositorio anterior se deben pasar al nuevo (consulte la Sección 18.6, “Migración de repositorios”).

Los parámetros más importantes del perfil son k, m y crush-failure-domain, ya que definen la sobrecarga de almacenamiento y la duración de los datos. Por ejemplo, si la arquitectura debe aguantar la pérdida de dos bastidores con una sobrecarga de almacenamiento del 66 %, puede definir el perfil siguiente. Tenga en cuenta que esto solo es válido con un mapa de CRUSH que tenga depósitos de tipo "bastidor":

cephuser@adm > ceph osd erasure-code-profile set myprofile \
   k=3 \
   m=2 \
   crush-failure-domain=rack

El ejemplo de la Sección 19.2, “Creación de un repositorio codificado de borrado de ejemplo” se puede repetir con este nuevo perfil:

cephuser@adm > ceph osd pool create ecpool 12 12 erasure myprofile
cephuser@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -
cephuser@adm > rados --pool ecpool get NYAN -
ABCDEFGHI

El objeto NYAN se dividirá en tres (k=3) y se crearán dos porciones adicionales (m=2). El valor de m define cuántos OSD pueden fallar al mismo tiempo sin que se pierda ningún dato. El valor crush-failure-domain=rack crea un conjunto de reglas de CRUSH que garantiza que no se almacenarán dos porciones en el mismo bastidor.

19.3.1 Creación de un nuevo perfil codificado de borrado #

El siguiente comando crea un nuevo perfil codificado de borrado:

root # ceph osd erasure-code-profile set NAME \
 directory=DIRECTORY \
 plugin=PLUGIN \
 stripe_unit=STRIPE_UNIT \
 KEY=VALUE ... \
 --force

DIRECTORY: Opcional. Defina el nombre del directorio desde el que se carga el complemento codificado de borrado. El valor por defecto es /usr/lib/ceph/erasure-code.
PLUGIN: Opcional. Utilice el complemento codificado de borrado para calcular fragmentos de codificación y recuperar fragmentos que falten. Los complementos disponibles son "jerasure", "isa", "lrc" y "shes". El valor por defecto es "jerasure".
STRIPE_UNIT: Opcional. Indica la cantidad de datos de un fragmento de datos, por repartición. Por ejemplo, un perfil con 2 fragmentos de datos y el valor stripe_unit=4K colocaría el rango 0-4K en el fragmento 0, el rango 4K-8K en el fragmento 1 y el rango 8K-12K en el fragmento 0 de nuevo. Debe ser un múltiplo de 4K para obtener el mejor rendimiento. El valor por defecto se toma de la opción de configuración del monitor osd_pool_erasure_code_stripe_unit cuando se crea un repositorio. El valor de "stripe_width" de un repositorio que utilice este perfil será el número de fragmentos de datos multiplicado por este valor de "stripe_unit".
KEY=VALUE: Los pares clave/valor de las opciones específicas del complemento codificado de borrado seleccionado.
‑‑force: Opcional. Sustituye un perfil existente con el mismo nombre y permite definir un valor de stripe_unit no alineado con 4K.

19.3.2 Eliminación de un perfil codificado de borrado #

El comando siguiente elimina un perfil codificado de borrado identificado por el valor de NAME (Nombre):

root # ceph osd erasure-code-profile rm NAME

Importante

Si un repositorio hace referencia al perfil, la supresión fallará.

19.3.3 Visualización de los detalles de un perfil codificado de borrado #

El comando siguiente muestra los detalles de un perfil codificado de borrado identificado por el valor de NAME (Nombre):

root # ceph osd erasure-code-profile get NAME

19.3.4 Listado de perfiles codificados de borrado #

El comando siguiente muestra los nombres de todos los perfiles codificado de borrado:

root # ceph osd erasure-code-profile ls

19.4 Marcado de repositorios codificados de borrado con un dispositivo de bloques RADOS #

Para marcar un repositorio codificado de borrado como un repositorio RBD, etiquételo en consecuencia:

cephuser@adm > ceph osd pool application enable rbd ec_pool_name

RBD puede almacenar datos de imagen en repositorios codificados de borrado. Sin embargo, el encabezado de la imagen y los metadatos deberán almacenarse aún en un repositorio replicado. Suponiendo que el nombre del repositorio sea "rbd":

cephuser@adm > rbd create rbd/image_name --size 1T --data-pool ec_pool_name

Puede utilizar la imagen con normalidad como cualquier otra, excepto por el hecho de que todos los datos se almacenarán en el repositorio ec_pool_name, en lugar de en el repositorio "rbd".