Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Enterprise Storage 5

9 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, 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. Esto es una ventaja respecto a un repositorio replicado, que necesita 2 TB de almacenamiento en bruto para la misma cantidad de datos.

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

Nota
Nota

Cuando se utiliza FileStore, no es posible acceder a los repositorios codificados de borrado con la interfaz RBD a menos que se tenga un nivel de caché configurado. Consulte la Sección 9.3, “Repositorio codificado de borrado y niveles de caché” para obtener más información sobre cómo utilizar BlueStore.

Nota
Nota

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 6.3.2, “firstn e indep”.

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

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

    root # ceph osd pool create ecpool 12 12 erasure
    pool 'ecpool' created
  2. La cadena ABCDEFGHI se escribe en un objeto denominado NYAN.

    cephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -
  3. Con fines de prueba, los OSD se pueden inhabilitar ahora, por ejemplo, desconectándolos de la red.

  4. Para probar si el repositorio puede gestionar el fallo de dispositivos, se puede acceder al contenido del archivo con el comando rados.

    root # rados --pool ecpool get NYAN -
    ABCDEFGHI

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

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

Con el perfil de código de borrado por defecto utilizado en la Sección 9.1, “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. Por lo tanto, para almacenar 1 TB de datos, necesita otros 0,5 TB de almacenamiento en bruto. Es decir, se necesitan 1,5 TB de almacenamiento en bruto para 1 TB de datos. 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:

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

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:

root # ceph osd erasure-code-profile set myprofile \
   k=3 \
   m=2 \
   crush-failure-domain=rack

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

root # ceph osd pool create ecpool 12 12 erasure myprofile
cephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -
root # 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.

Para obtener más información acerca de los perfiles de código de borrado, consulte http://docs.ceph.com/docs/master/rados/operations/erasure-code-profile.

9.3 Repositorio codificado de borrado y niveles de caché

Los repositorios codificados de borrado requieren más recursos que los repositorios replicados y carecen de algunas funciones, como la escritura parcial. Para superar dichas limitaciones, se recomienda definir un nivel de caché antes de definir el repositorio codificado de borrado.

Por ejemplo, si el repositorio hot-storage está formado por almacenamiento rápido, el valor ecpool creado en la Sección 9.2, “Perfiles de código de borrado” se puede acelerar con:

root # ceph osd tier add ecpool hot-storage
root # ceph osd tier cache-mode hot-storage writeback
root # ceph osd tier set-overlay ecpool hot-storage

Esto colocará el repositorio hot-storage como nivel de ecpool en modo de escritura diferida para que cada operación de escritura y lectura en ecpool utilice en realidad hot-storage y se beneficie de su flexibilidad y velocidad.

Cuando se utiliza FileStore, no es posible crear una imagen RBD en un repositorio codificado de borrado, ya que requiere operaciones de escritura parciales. Sin embargo, resulta posible crear una imagen RBD en un repositorio codificado de borrado si en un nivel de repositorio replicado se establece un nivel de caché:

root # rbd --pool ecpool create --size 10 myvolume

Para obtener más información sobre los niveles de caché, consulte el Capítulo 10, Niveles de caché.

9.4 Repositorio codificado de borrado con dispositivo de bloques RADOS

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

root # 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":

root # 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".

Imprimir esta página