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

6 Gestión de datos almacenados

El algoritmo CRUSH determina cómo se deben almacenar y recuperar los datos. Para ello, calcula las ubicaciones de almacenamiento. CRUSH aporta a los clientes de Ceph la capacidad de comunicarse con los OSD directamente, en lugar de hacerlo a través de un servidor centralizado o un intermediario. Con un método de almacenamiento y recuperación de datos determinado mediante un algoritmo, Ceph evita que haya un único punto de fallo, un cuello de botella de rendimiento y un límite físico a su capacidad de ampliación.

CRUSH requiere un mapa del clúster y usa el mapa de CRUSH para almacenar y recuperar de forma pseudoaleatoria los datos de los OSD con una distribución uniforme de los datos por el clúster.

Los mapas de CRUSH contienen una lista de los OSD, una lista de "depósitos" para agregar los dispositivos en ubicaciones físicas, y una lista de reglas que indican a CRUSH cómo se deben replicar los datos en los repositorios del clúster de Ceph. Al reflejar la organización física subyacente de la instalación, CRUSH puede modelar, y por lo tanto solucionar, causas potenciales de errores de dispositivo correlacionados. Las causas habituales suelen ser la proximidad física, una fuente de alimentación compartida y una red compartida. Mediante la codificación de esta información en un mapa del clúster, las directivas de colocación de CRUSH pueden separar las réplicas del objeto en dominios de fallo diferentes, al tiempo que se mantiene la distribución que se desea. Por ejemplo, para prepararse en caso de que se produzcan fallos simultáneos, puede ser conveniente asegurarse de que las réplicas de datos se encuentran en dispositivos que utilizan diferentes estantes, bastidores, fuente de alimentación, controladores o ubicaciones físicas.

Después de distribuir un clúster de Ceph, se genera un mapa de CRUSH por defecto. Resulta adecuado para el entorno de la zona protegida de Ceph. Sin embargo, si se distribuye un clúster de datos a gran escala, debe planificarse concienzudamente cómo desarrollar un mapa de CRUSH personalizado, ya que le ayudará a gestionar el clúster de Ceph, a mejorar el rendimiento y a garantizar la seguridad de los datos.

Por ejemplo, si falla un OSD, un mapa de CRUSH puede ayudarle a localizar el centro de datos físico, la sala, la fila y el bastidor del host donde se encuentra el OSD que ha fallado, en caso de que necesite asistencia técnica in situ o sustituir el hardware.

Del mismo modo, CRUSH puede ayudarle a identificar los errores más rápidamente. Por ejemplo, si todos los OSD en un bastidor determinado fallan al mismo tiempo, el error podría encontrarse en un conmutador de red o en la fuente de alimentación del bastidor, o en el conmutador de red, en lugar de estar en los propios OSD.

Un mapa de CRUSH personalizado también ayuda a identificar las ubicaciones físicas donde Ceph almacena las copias redundantes de los datos si los grupos de colocación asociados con un host que falla se encuentran en un estado degradado.

Hay tres secciones principales en un mapa de CRUSH.

  • Los Dispositivos son cualquier dispositivo de almacenamiento de objetos; es decir, el disco duro correspondiente a un daemon ceph osd.

  • Los Depósitos están formados por una agregación jerárquica de ubicaciones de almacenamiento (por ejemplo, filas, bastidores, hosts, etc.) y sus pesos asignados.

  • Las Conjuntos de reglas son una forma de seleccionar depósitos.

6.1 Dispositivos

Para asignar grupos de colocación a los OSD, un mapa de CRUSH requiere una lista de los dispositivos OSD (el nombre del daemon OSD). La lista de dispositivos aparece primero en el mapa de CRUSH.

#devices
device num osd.name

Por ejemplo:

#devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3

Como regla general, un daemon OSD se asigna a un solo disco.

6.2 Depósitos

Los mapas de CRUSH contienen una lista de los OSD, que se pueden organizar en "depósitos" para agregar los dispositivos en ubicaciones físicas.

0

OSD

Un daemon OSD (osd.1, osd.2, etc).

1

Host

Un nombre de host que contiene uno o varios OSD.

2

Carcasa

Una carcasa compuesta por bastidores.

3

Bastidor

El bastidor de un equipo. El valor por defecto es unknownrack.

4

Fila

Una fila de una serie de bastidores.

5

PDU

La unidad de distribución de alimentación.

6

Pod

7

Sala

Una sala que contiene bastidores y filas de hosts.

8

Centro de datos

Un centro de datos físico que contiene salas.

9

Región

10

Raíz

Sugerencia
Sugerencia

Puede eliminar estos tipos de depósitos y crear los suyos propios.

Las herramientas de distribución de Ceph generan un mapa de CRUSH que contiene un depósito para cada host y un repositorio denominado "default", lo que resulta útil para el repositorio rbd por defecto. El resto de tipos de depósitos ofrecen un medio para almacenar información acerca de la ubicación física de los nodos/depósitos, lo que facilita la administración del clúster cuando los OSD, los hosts, o el hardware de red funcionan erróneamente y el administrador necesita acceder al hardware físico.

Un depósito tiene un tipo, un nombre exclusivo (cadena), un ID único que se expresa como un número entero negativo, un peso relativo a la capacidad total dividida entre la capacidad de sus elementos, el algoritmo de depósito (por defecto, straw) y el hash (0 por defecto, que refleja el hash de CRUSH rjenkins1). Un depósito puede tener uno o varios elementos. Los elementos pueden estar formados por otros depósitos o por OSD. Los elementos pueden tener un peso relativo.

[bucket-type] [bucket-name] {
  id [a unique negative numeric ID]
  weight [the relative capacity/capability of the item(s)]
  alg [the bucket type: uniform | list | tree | straw ]
  hash [the hash type: 0 by default]
  item [item-name] weight [weight]
}

En el siguiente ejemplo se muestra cómo se pueden utilizar depósitos para agregar un repositorio y ubicaciones físicas como un centro de datos, una sala, un bastidor y una fila.

host ceph-osd-server-1 {
        id -17
        alg straw
        hash 0
        item osd.0 weight 1.00
        item osd.1 weight 1.00
}

row rack-1-row-1 {
        id -16
        alg straw
        hash 0
        item ceph-osd-server-1 weight 2.00
}

rack rack-3 {
        id -15
        alg straw
        hash 0
        item rack-3-row-1 weight 2.00
        item rack-3-row-2 weight 2.00
        item rack-3-row-3 weight 2.00
        item rack-3-row-4 weight 2.00
        item rack-3-row-5 weight 2.00
}

rack rack-2 {
        id -14
        alg straw
        hash 0
        item rack-2-row-1 weight 2.00
        item rack-2-row-2 weight 2.00
        item rack-2-row-3 weight 2.00
        item rack-2-row-4 weight 2.00
        item rack-2-row-5 weight 2.00
}

rack rack-1 {
        id -13
        alg straw
        hash 0
        item rack-1-row-1 weight 2.00
        item rack-1-row-2 weight 2.00
        item rack-1-row-3 weight 2.00
        item rack-1-row-4 weight 2.00
        item rack-1-row-5 weight 2.00
}

room server-room-1 {
        id -12
        alg straw
        hash 0
        item rack-1 weight 10.00
        item rack-2 weight 10.00
        item rack-3 weight 10.00
}

datacenter dc-1 {
        id -11
        alg straw
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

pool data {
        id -10
        alg straw
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

6.3 Conjuntos de reglas

Los mapas de CRUSH admiten la noción de "reglas de CRUSH", que son las reglas que determinan la colocación de los datos de un repositorio. En clústeres de gran tamaño, es probable que cree muchos repositorios y que cada uno de ellos tenga sus propios conjuntos de reglas y reglas de CRUSH. El mapa de CRUSH por defecto tiene una regla para cada repositorio y un conjunto de reglas asignado a cada uno de los repositorios por defecto.

Nota
Nota

En la mayoría de los casos, no será necesario modificar las reglas por defecto. Cuando se crea un repositorio nuevo, el conjunto de reglas por defecto es 0.

Una regla tiene el siguiente formato:

rule rulename {

        ruleset ruleset
        type type
        min_size min-size
        max_size max-size
        step step

}
ruleset

Un número entero. Clasifica una regla para que pertenezca a un conjunto de reglas. Se activa definiendo el conjunto de reglas en un repositorio. Esta opción es obligatoria. Por defecto es 0.

Importante
Importante

Debe aumentar el número del conjunto de reglas del valor por defecto 0 continuamente, en caso contrario el monitor relacionado podrían bloquearse.

type

Una cadena. Describe una regla para un disco duro (replicada) o un dispositivo RAID. Esta opción es obligatoria. El valor por defecto es replicated (replicada).

min_size

Un número entero. Si un grupo de colocación realiza un número inferior de réplicas que el indicado pro este número, CRUSH NO selecciona esta regla. Esta opción es obligatoria. Por defecto es 2.

max_size

Un número entero. Si un grupo de colocación realiza un número superior de réplicas que el indicado por este número, CRUSH NO selecciona esta regla. Esta opción es obligatoria. Por defecto es 10.

step take bucket

Toma el nombre de un depósito e inicia una iteración hacia abajo por el árbol. Esta opción es obligatoria. Para obtener una explicación acerca de la iteración por el árbol, consulte la Sección 6.3.1, “Iteración por el árbol de nodos”.

step targetmodenum type bucket-type

target puede ser choose o chooseleaf. Si se define como choose, se seleccionan varios depósitos. chooseleaf selecciona directamente los OSD (nodos hoja) del subárbol de cada depósito en el conjunto de depósitos.

mode puede ser firstn o indep. Consulte la Sección 6.3.2, “firstn e indep”.

Selecciona el número de depósitos del tipo especificado. Donde N es el número de opciones disponibles, si num > 0 && < N, seleccione ese número de depósitos; si num < 0, significa N - num; y si num == 0, selecciona N depósitos (todos los disponibles). Se usa después de step take o a step choose.

step emit

Devuelve el valor actual y vacía la pila. Se suele usar al final de una regla, pero también puede utilizarse para formar árboles diferentes en la misma regla. Se usa después de step choose.

Importante
Importante

Para activar una o varias reglas con un número de conjunto de reglas común en un repositorio, defina el número de conjunto de reglas en el repositorio.

6.3.1 Iteración por el árbol de nodos

La estructura definida con los depósitos se puede ver como un árbol de nodos. Los depósitos son nodos y los OSD son hojas de ese árbol.

Las reglas del mapa de CRUSH definen cómo se seleccionan los OSD del árbol. Una regla empieza con un nodo y se itera hacia abajo por el árbol para devolver un conjunto de OSD. No es posible definir la rama que se debe seleccionar. En su lugar, el algoritmo CRUSH garantiza que el conjunto de OSD cumple los requisitos de réplica y distribuye los datos de forma homogénea.

Con step take bucket, la iteración por el árbol de nodos comienza en el depósito indicado (no en el tipo de depósito). Si se deben devolver OSD de todas las ramas del árbol, se debe indicar el depósito raíz. De lo contrario, la iteración de los pasos siguientes solo se producirá por un subárbol.

Después de step take, se usan una o varias entradas step choose en la definición de la regla. Cada step choose elige un número definido de nodos (o ramas) del nodo superior seleccionado anteriormente.

Al final, los OSD seleccionados se devuelven con step emit.

step chooseleaf es una función de conveniencia que selecciona directamente los OSD de ramas de un depósito determinado.

En la Figura 6.1, “Árbol de ejemplo” se proporciona un ejemplo de cómo se usa step para producir la iteración por un árbol. Las flechas naranjas y los números corresponden a example1a y example1b, mientras que las azules corresponden a example2 en las siguientes definiciones de regla.

Árbol de ejemplo
Figura 6.1: Árbol de ejemplo
# orange arrows
rule example1a {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2)
        step choose firstn 0 host
        # orange (3)
        step choose firstn 1 osd
        step emit
}

rule example1b {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2) + (3)
        step chooseleaf firstn 0 host
        step emit
}

# blue arrows
rule example2 {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # blue (1)
        step take room1
        # blue (2)
        step chooseleaf firstn 0 rack
        step emit
}

6.3.2 firstn e indep

Una regla de CRUSH define las sustituciones de los nodos o los OSD que fallan (consulte la Sección 6.3, “Conjuntos de reglas”). La palabra clave step requiere el parámetro firstn o indep. La Figura 6.2, “Métodos de sustitución del nodo” proporciona un ejemplo.

Con firstn se añaden nodos de sustitución al final de la lista de nodos activos. En el caso de un nodo que ha fallado, los nodos en buen estado siguientes se desplazan a la izquierda para cubrir el hueco del nodo erróneo. Se trata del método por defecto, y el recomendado, para los repositorios replicados, ya que un nodo secundario ya tiene todos los datos y, por lo tanto, puede hacerse cargo de las tareas del nodo principal de inmediato.

Con indep se seleccionan nodos de sustitución fijos para cada nodo activo. La sustitución de un nodo con fallos no cambia el orden de los nodos restantes. Este es el comportamiento recomendado para los repositorios codificados de borrado. En los repositorios codificados de borrado, los datos almacenados en un nodo dependen de su posición en la selección de nodos. Cuando se cambia el orden de los nodos, todos los datos de los nodos afectados deben recolocarse.

Nota
Nota: repositorios de borrado

Asegúrese de que se define una regla que use indep para cada repositorio codificado de borrado.

Métodos de sustitución del nodo
Figura 6.2: Métodos de sustitución del nodo

6.4 Manipulación del mapa de CRUSH

En esta sección se describen formas para manipular de forma básica el mapa de CRUSH: por ejemplo, para editar un mapa de CRUSH; cambiar los parámetros del mapa de CRUSH y añadir, mover o eliminar un OSD.

6.4.1 Edición de un mapa de CRUSH

Para editar un mapa de CRUSH existente, haga lo siguiente:

  1. Obtenga un mapa de CRUSH. Para obtener el mapa de CRUSH de su clúster, ejecute lo siguiente:

    root # ceph osd getcrushmap -o compiled-crushmap-filename

    Ceph da como resultado (-o) un mapa de CRUSH compilado con el nombre de archivo que especifique. Puesto que el mapa de CRUSH está compilado, debe descompilarlo antes de que se pueda editar.

  2. Descompilación de un mapa de CRUSH. Para descompilar un mapa de CRUSH, ejecute lo siguiente:

    cephadm > crushtool -d compiled-crushmap-filename \
     -o decompiled-crushmap-filename

    Ceph descompilará (-d) el mapa de CRUSH compilado y lo obtendrá como resultado (-o) con el nombre de archivo que especifique.

  3. Edite al menos uno de los parámetros de dispositivos, depósitos o reglas.

  4. Compile un mapa de CRUSH. Para hacerlo, ejecute lo siguiente:

    cephadm > crushtool -c decompiled-crush-map-filename \
     -o compiled-crush-map-filename

    Ceph almacenará un mapa de CRUSH compilado con el nombre de archivo que especifique.

  5. Defina un mapa de CRUSH. Para definir el mapa de CRUSH de su clúster, ejecute lo siguiente:

    root # ceph osd setcrushmap -i compiled-crushmap-filename

    Ceph introducirá el mapa de CRUSH compilado con el nombre de archivo que ha especificado como el mapa de CRUSH del clúster.

6.4.2 Adición o traslado de un OSD

Para añadir o trasladar un OSD en el mapa de CRUSH de un clúster en ejecución, ejecute lo siguiente:

root # ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...
id

Un número entero. El ID numérico del OSD. Esta opción es obligatoria.

name

Una cadena. El nombre completo del OSD. Esta opción es obligatoria.

weight

Un valor doble. El peso de CRUSH para el OSD. Esta opción es obligatoria.

pool

Un par de clave y valor. Por defecto, la jerarquía de CRUSH contiene como raíz el repositorio por defecto. Esta opción es obligatoria.

bucket-type

Pares clave-valor. Puede especificar la ubicación del OSD en la jerarquía de CRUSH.

El ejemplo siguiente añade osd.0 a la jerarquía, o traslada el OSD desde una ubicación anterior.

root # ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \
row=foo rack=bar host=foo-bar-1

6.4.3 Ajuste del peso de CRUSH de un OSD

Para ajustar el peso de CRUSH de un OSD en el mapa de CRUSH de un clúster en ejecución, ejecute lo siguiente:

root # ceph osd crush reweight name weight
name

Una cadena. El nombre completo del OSD. Esta opción es obligatoria.

weight

Un valor doble. El peso de CRUSH para el OSD. Esta opción es obligatoria.

6.4.4 Eliminación de un OSD

Para eliminar un OSD del mapa de CRUSH de un clúster en ejecución, ejecute lo siguiente:

root # ceph osd crush remove name
name

Una cadena. Nombre completo del OSD. Esta opción es obligatoria.

6.4.5 Traslado de un depósito

Para trasladar un depósito a una ubicación diferente o colocarlo en la jerarquía del mapa de CRUSH, ejecute lo siguiente:

root # ceph osd crush move bucket-name bucket-type=bucket-name, ...
bucket-name

Una cadena. El nombre del depósito que va a trasladar o cambiar de posición. Esta opción es obligatoria.

bucket-type

Pares clave-valor. Puede especificar la ubicación del depósito en la jerarquía de CRUSH.

6.5 Borrado seguro

Además de realizar varias copias de objetos, Ceph garantiza la integridad de los datos borrando de forma segura los grupos de colocación. El borrado seguro de Ceph es análogo a ejecutar fsck en la capa de almacenamiento de objetos. Para cada grupo de colocación, Ceph genera un catálogo de todos los objetos y compara cada objeto primario y sus réplicas para asegurarse de que no falta ningún objeto o que hay objetos que no coinciden. Un borrado seguro ligero diario comprueba el tamaño y los atributos del objeto, mientras que el borrado seguro profundo semanal lee los datos y utiliza sumas de comprobación para garantizar la integridad de los datos.

El borrado seguro es importante para mantener la integridad de los datos, pero puede reducir el rendimiento. Es posible ajustar los valores siguientes para aumentar o disminuir las operaciones de borrado seguro:

osd max scrubs

El número máximo de operaciones de borrado seguro simultáneas para Ceph OSD. El valor por defecto es 1.

osd scrub begin hour, osd scrub end hour

Las horas del día (de 0 a 24) con las que se define una ventana temporal en la que se puede producir el borrado seguro. Por defecto, empieza a las 0 y termina a las 24.

Importante
Importante

Si el intervalo de borrado seguro del grupo de colocación supera el valor indicado en osd scrub max interval, el borrado seguro se producirá independientemente de la ventana temporal que se defina.

osd scrub during recovery

Permite el borrado seguro durante la recuperación. Si se establece el valor "false" (falso), se inhabilita la programación de borrados seguros nuevos mientras haya una recuperación activa. Los borrados seguros que ya estén en ejecución continuarán. Esta opción resulta útil para reducir la carga en clústeres muy ocupados. El valor por defecto es "true" (verdadero).

osd scrub thread timeout

El tiempo máximo en segundos que debe transcurrir para que un hilo de borrado seguro llegue a su tiempo límite. El valor por defecto es 60.

osd scrub finalize thread timeout

El tiempo máximo en segundos que debe transcurrir para que un hilo de finalización de borrado seguro llegue a su tiempo límite. El valor por defecto es 60*10.

osd scrub load threshold

La carga máxima normalizada. Ceph no llevará a cabo un borrado seguro cuando la carga del sistema (como se define por el coeficiente de getloadavg()/número de CPUs en línea) sea superior a este número. El valor por defecto es 0,5.

osd scrub min interval

El intervalo mínimo en segundos para el borrado seguro de Ceph OSD cuando la carga del clúster de Ceph sea pequeña. Por defecto es 60*60*24 (una vez al día).

osd scrub max interval

El intervalo máximo en segundos para el borrado seguro de Ceph OSD independientemente de la carga del clúster. 7*60*60*24 (una vez a la semana).

osd scrub chunk min

El número mínimo de porciones de almacenamiento de objetos que se deben borrar de forma segura durante una única operación. Ceph bloquea la escritura en una única porción durante el borrado seguro. El valor por defecto es 5.

osd scrub chunk max

El número máximo de porciones de almacenamiento de objetos que se deben borrar de forma segura durante una única operación. El valor por defecto es 25.

osd scrub sleep

El tiempo de reposo antes de realizar el borrado seguro en el siguiente grupo de porciones. Al aumentar este valor, se ralentiza toda la operación de borrado seguro, mientras que las operaciones del cliente se ven menos afectadas. El valor por defecto es 0.

osd deep scrub interval

El intervalo entre borrados seguros "profundos" (con lectura completa de todos los datos). La opción osd scrub load threshold no afecta a este valor. Por defecto es 60*60*24*7 (una vez a la semana).

osd scrub interval randomize ratio

Añade un retraso aleatorio al valor osd scrub min interval cuando se programa la siguiente tarea de borrado seguro para un grupo de colocación. El retraso es un valor aleatorio menor que el resultado de osd scrub min interval * osd scrub interval randomized ratio. Por lo tanto, el valor por defecto difunde de forma prácticamente aleatoria los procesos de borrado seguro durante la ventana temporal permitida de [1, 1,5] * osd scrub min interval. El valor por defecto es 0,5.

osd deep scrub stride

El tamaño de lectura cuando se realiza un borrado seguro profundo. El valor por defecto es 524288 (512 kB).

6.6 Combinación de unidades SSD y discos duros en el mismo nodo

Puede ser conveniente configurar un clúster de Ceph de forma que cada nodo cuente con una mezcla de unidades SSD y discos duros, con un repositorio de almacenamiento en las unidades SSD rápidas y otro en los discos duros más lentos. Para ello, el mapa de CRUSH debe modificarse.

El mapa de CRUSH por defecto tiene una jerarquía sencilla, donde la raíz por defecto contiene hosts, y estos hosts contienen OSD, por ejemplo:

root # ceph osd tree
 ID CLASS WEIGHT   TYPE NAME      STATUS REWEIGHT PRI-AFF
 -1       83.17899 root default
 -4       23.86200     host cpach
 2   hdd  1.81898         osd.2      up  1.00000 1.00000
 3   hdd  1.81898         osd.3      up  1.00000 1.00000
 4   hdd  1.81898         osd.4      up  1.00000 1.00000
 5   hdd  1.81898         osd.5      up  1.00000 1.00000
 6   hdd  1.81898         osd.6      up  1.00000 1.00000
 7   hdd  1.81898         osd.7      up  1.00000 1.00000
 8   hdd  1.81898         osd.8      up  1.00000 1.00000
 15  hdd  1.81898         osd.15     up  1.00000 1.00000
 10  nvme 0.93100         osd.10     up  1.00000 1.00000
 0   ssd  0.93100         osd.0      up  1.00000 1.00000
 9   ssd  0.93100         osd.9      up  1.00000 1.00000

De esta no forma no hay distinción entre los tipos de disco. Para dividir los OSD entre las unidades SSD y los discos duros, es necesario crear una segunda jerarquía en el mapa de CRUSH:

root # ceph osd crush add-bucket ssd root

Después de crear la nueva raíz para las unidades SSD, hay que añadirle hosts. Esto significa crear nuevas entradas de host. Pero puesto que el mismo nombre de host no debe aparecer más de una vez en un mapa de CRUSH, se utilizan nombres de host falsos. No es preciso que DNS pueda resolver estos nombres de host falsos. A CRUSH no le importan los nombres de host: solo necesita crear las jerarquías correctas. Lo único que hay que cambiar para que se admitan los nombres de host falsos es que debe definir

osd crush update on start = false

en el archivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf y, a continuación, ejecutar la fase 3 de DeepSea para distribuir el cambio (consulte la Sección 1.11, “Archivo ceph.conf personalizado” para obtener más información):

root@master # salt-run state.orch ceph.stage.3

De lo contrario, los OSD que traslade se restablecerán más tarde en su ubicación original en la raíz por defecto y el clúster no tendrá el comportamiento previsto.

Después de que se haya cambiado ese valor, añada los nuevos hosts falsos a la raíz de la unidad SSD:

root # ceph osd crush add-bucket node1-ssd host
root # ceph osd crush move node1-ssd root=ssd
root # ceph osd crush add-bucket node2-ssd host
root # ceph osd crush move node2-ssd root=ssd
root # ceph osd crush add-bucket node3-ssd host
root # ceph osd crush move node3-ssd root=ssd

Por último, para cada OSD de SSD, mueva el OSD a la raíz de la unidad SSD. En este ejemplo, se presupone que osd.0, osd.1 y osd.2 están alojados físicamente en unidades SSD:

root # ceph osd crush add osd.0 1 root=ssd
root # ceph osd crush set osd.0 1 root=ssd host=node1-ssd
root # ceph osd crush add osd.1 1 root=ssd
root # ceph osd crush set osd.1 1 root=ssd host=node2-ssd
root # ceph osd crush add osd.2 1 root=ssd
root # ceph osd crush set osd.2 1 root=ssd host=node3-ssd

La jerarquía de CRUSH debería tener un aspecto como este:

root # ceph osd tree
ID WEIGHT  TYPE NAME                   UP/DOWN REWEIGHT PRIMARY-AFFINITY
-5 3.00000 root ssd
-6 1.00000     host node1-ssd
 0 1.00000         osd.0                    up  1.00000          1.00000
-7 1.00000     host node2-ssd
 1 1.00000         osd.1                    up  1.00000          1.00000
-8 1.00000     host node3-ssd
 2 1.00000         osd.2                    up  1.00000          1.00000
-1 0.11096 root default
-2 0.03699     host node1
 3 0.01849         osd.3                    up  1.00000          1.00000
 6 0.01849         osd.6                    up  1.00000          1.00000
-3 0.03699     host node2
 4 0.01849         osd.4                    up  1.00000          1.00000
 7 0.01849         osd.7                    up  1.00000          1.00000
-4 0.03699     host node3
 5 0.01849         osd.5                    up  1.00000          1.00000
 8 0.01849         osd.8                    up  1.00000          1.00000

Ahora, cree una regla de CRUSH dirigida a la raíz de la unidad SSD:

root # ceph osd crush rule create-simple ssd_replicated_ruleset ssd host

La regla replicated_ruleset (con ID 0) original dirigirá a los discos duros La nueva regla ssd_replicated_ruleset (con ID 1) dirigirá a las unidades SSD.

Cualquier repositorio existente seguirá utilizando los discos duros, ya que se encuentran en la jerarquía por defecto en el mapa de CRUSH. Se puede crear un repositorio nuevo que solo use unidades SSD:

root # ceph osd pool create ssd-pool 64 64
root # ceph osd pool set ssd-pool crush_rule ssd_replicated_ruleset
Imprimir esta página