17 Gestión de datos almacenados #

La flexibilidad del mapa de CRUSH para controlar la colocación de los datos es uno de los puntos fuertes de Ceph. También es una de las partes más difíciles de gestionar del clúster. Las clases de dispositivos automatizan los cambios más comunes en los mapas de CRUSH que, antes, el administrador debía realizar manualmente.

17.1.1.1 El problema de la gestión de CRUSH #

 

Los clústeres de Ceph se crean con frecuencia con varios tipos de dispositivos de almacenamiento: discos duros, unidades SSD, NVMe o incluso con combinaciones de estos. Llamamos a estos diferentes tipos de dispositivos de almacenamiento clases de dispositivos, para evitar confusiones entre la propiedad type de las depósitos CRUSH (por ejemplo, host, bastidor o fila; consulte la Sección 17.2, “Depósitos” para obtener detalles). Los Ceph OSD respaldados por unidades SSD son mucho más rápidos que los respaldados por discos giratorios, por lo que son más adecuados para ciertas cargas de trabajo. Ceph facilita la creación de repositorios RADOS para diferentes conjuntos de datos o cargas de trabajo, así como para asignar las diferentes reglas de CRUSH que sirven para controlar la colocación de datos para esos repositorios.

Figura 17.1: OSDs con clases de dispositivos mixtos #

 

Sin embargo, configurar las reglas de CRUSH para colocar datos solo en una determinada clase de dispositivo resulta tedioso. Las reglas funcionan en términos de la jerarquía de CRUSH, pero si los dispositivos se mezclan en los mismos hosts o bastidores (como en la jerarquía de ejemplo anterior), se mezclarán (por defecto) y aparecerán en los mismos subárboles de la jerarquía. Separarlos manualmente en árboles independientes implicaba crear varias versiones de cada nodo intermedio para cada clase de dispositivo en las versiones anteriores de SUSE Enterprise Storage.

cephuser@adm > 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

cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3
done removing class of osd(s): 2,3
cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3
set osd(s) 2,3 to class 'ssd'

cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

cephuser@adm > ceph osd crush rule create-replicated fast default host ssd

cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast

cephuser@adm > ceph osd erasure-code-profile set myprofile \
 k=4 m=2 crush-device-class=ssd crush-failure-domain=host
cephuser@adm > ceph osd pool create mypool 64 erasure myprofile

rule ecpool {
  id 2
  type erasure
  min_size 3
  max_size 6
  step set_chooseleaf_tries 5
  step set_choose_tries 100
  step take default class ssd
  step chooseleaf indep 0 type host
  step emit
}

cephuser@adm > ceph osd crush class ls
[
  "hdd",
  "ssd"
]

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

cephuser@adm > ceph osd crush rule dump fast
{
		"rule_id": 1,
		"rule_name": "fast",
		"ruleset": 1,
		"type": 1,
		"min_size": 1,
		"max_size": 10,
		"steps": [
						{
										"op": "take",
										"item": -21,
										"item_name": "default~ssd"
						},
						{
										"op": "chooseleaf_firstn",
										"num": 0,
										"type": "host"
						},
						{
										"op": "emit"
						}
		]
}

cephuser@adm > ceph osd crush class ls-osd ssd
0
1

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 17.2, “Á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.

Figura 17.2: Á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
}

Una regla de CRUSH define las sustituciones de los nodos o los OSD que fallan (consulte la Sección 17.3, “Conjuntos de reglas”). La palabra clave step requiere el parámetro firstn o indep. En la Figura 17.3, “Métodos de sustitución de nodos” se muestra 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.

Figura 17.3: Métodos de sustitución de nodos #

 

Un grupo de colocación (PG) agrega objetos dentro de un repositorio. La razón principal es que realizar un seguimiento de la ubicación de los objetos y de los metadatos de cada objeto es costoso desde el punto de vista computacional. Por ejemplo, un sistema con millones de objetos no puede realizar directamente un seguimiento de la ubicación de cada uno de esos objetos.

Figura 17.4: Grupos de colocación en un repositorio #

 

El cliente de Ceph calculará a qué grupo de colocación pertenecerá un objeto. Para ello, aplica el hash del ID de objeto y aplica una operación basada en el número grupos de colocación del repositorio definido y el ID del repositorio.

El contenido de un objeto situado dentro de un grupo de colocación se almacena en un conjunto de OSDs. Por ejemplo, en un repositorio replicado con un tamaño de dos, cada grupo de colocación almacenará objetos en dos OSD:

Figura 17.5: Grupos de colocación y OSDs #

 

Si se produce un error en el OSD 2, otro OSD se asignará al grupo de colocación 1 y se rellenará con copias de todos los objetos de OSD 1. Si el tamaño del repositorio cambia de dos a tres, se asignará un OSD adicional al grupo de colocación y recibirá copias de todos los objetos del grupo de colocación.

Los grupos de colocación no son propietarios del OSD; lo comparten con otros grupos de colocación del mismo repositorio, o incluso con otros repositorios. Si se produce un error en el OSD 2, el grupo de colocación 2 también tendrá que restaurar copias de los objetos, mediante el OSD 3.

Cuando aumenta el número de grupos de colocación, se asignan OSD a los nuevos grupos de colocación. El resultado de la función CRUSH también cambia y algunos objetos de los grupos de colocación anteriores se copian en los nuevos grupos de colocación y se eliminan de los antiguos.

Nota

Desde Ceph Nautilus (v14.x), puede utilizar el módulo pg_autoscaler de Ceph Manager para escalar automáticamente los grupos de colocación según sea necesario. Si desea habilitar esta función, consulte el Sección 6.1.1.1, “Default PG and PGP counts”.

Al crear un repositorio nuevo, se puede elegir el valor de PG_NUM manualmente:

root # ceph osd pool create POOL_NAME PG_NUM

El valor de PG_NUM no se puede calcular automáticamente. A continuación se muestran algunos valores de uso común según el número de OSDs del clúster:

A medida que aumenta el número de OSD, seleccionar el valor adecuado para PG_NUM se vuelve cada vez más importante. El valor de PG_NUM afecta considerablemente al comportamiento del clúster, así como a la durabilidad de los datos en caso de error del OSD.

total PGs = (OSDs * 100) / POOL_SIZE

          (200 * 100) / 3 = 6667

Nota

Desde Ceph Nautilus (v14.x), puede utilizar el módulo pg_autoscaler de Ceph Manager para escalar automáticamente los grupos de colocación según sea necesario. Si desea habilitar esta función, consulte el Sección 6.1.1.1, “Default PG and PGP counts”.

Si aún necesita especificar el número de grupos de colocación en un repositorio manualmente, deberá especificarlos en el momento en el que cree el repositorio (consulte la Sección 18.1, “Creación de un repositorio”). Después de haber establecido los grupos de colocación para un repositorio, puede aumentar el número de grupos de colocación ejecutando el comando siguiente:

root # ceph osd pool set POOL_NAME pg_num PG_NUM

Después de aumentar el número de grupos de colocación, también debe aumentar el número de grupos de colocación de la ubicación (PGP_NUM) antes de que el clúster se reequilibre. El valor de PGP_NUM será el número de grupos de colocación que el algoritmo CRUSH tendrá en cuenta para la colocación. Al aumentar el valor de PG_NUM, se dividen los grupos de colocación, pero los datos no se migran a los grupos de colocación más recientes hasta que se aumenta este valor de PG_NUM. El valor de PGP_NUM debe ser igual al de PG_NUM. Para aumentar el número de grupos de colocación de la ubicación, ejecute lo siguiente:

root # ceph osd pool set POOL_NAME pgp_num PGP_NUM

Para averiguar el número de grupos de colocación de un repositorio, ejecute el comando get siguiente:

root # ceph osd pool get POOL_NAME pg_num

Para obtener las estadísticas de los grupos de colocación del clúster, ejecute el comando siguiente:

root # ceph pg dump [--format FORMAT]

Los formatos válidos son "plain" (por defecto) y "json".

Para obtener las estadísticas de todos los grupos de colocación atascados en un estado especificado, ejecute lo siguiente:

root # ceph pg dump_stuck STATE \
 [--format FORMAT] [--threshold THRESHOLD]

El valor de STATE puede ser "inactive" (inactivo, los grupos de colocación no pueden procesar lecturas ni escrituras porque están a la espera de que aparezca un OSD con los datos más actualizados), "unclean" (no limpio, los grupos de colocación contienen objetos que no se replican el número deseado de veces), "stale" (obsoleto, los grupos de colocación están en un estado desconocido: los OSD donde se alojan no han informado al clúster de supervisión en un intervalo de tiempo especificado por la opción mon_osd_report_timeout, "undersized" (tamaño insuficiente) o "degraded" (degradado).

Los formatos válidos son "plain" (por defecto) y "json".

El umbral define el número mínimo de segundos que el grupo de colocación debe estar atascado antes de que se incluya en las estadísticas (300 segundos por defecto).

Para obtener el mapa de un grupo de colocación determinado, ejecute lo siguiente:

root # ceph pg map PG_ID

Ceph devolverá el mapa del grupo de colocación, el grupo de colocación y el estado del OSD:

root # ceph pg map 1.6c
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

Para recuperar estadísticas de un grupo de colocación determinado, ejecute lo siguiente:

root # ceph pg PG_ID query

Para borrar de forma segura un grupo de colocación (Sección 17.6, “Depuración de grupos de colocación”), ejecute lo siguiente:

root # ceph pg scrub PG_ID

Ceph comprueba los nodos primario y de réplica, genera un catálogo de todos los objetos del grupo de colocación y los compara para asegurarse de que no falta ningún objeto, que no coinciden y que su contenido es coherente. Suponiendo que todas las réplicas coincidan, un barrido semántico final garantiza que todos los metadatos de objetos relacionados con instantáneas sean coherentes. Los errores se notifican a través de los registros.

Puede encontrarse con una situación en la que varios grupos de colocación requieran una recuperación o una reposición, y algunos grupos contienen datos más importantes que otros. Por ejemplo, unos grupos de colocación pueden contener datos para las imágenes utilizadas por las máquinas en ejecución, mientras que otros pueden ser utilizados por máquinas inactivas o contener datos menos relevantes. En este caso, es posible que desee dar prioridad a la recuperación de los primeros grupos para que el rendimiento y la disponibilidad de los datos almacenados en aquellos grupos se restaure antes. Para marcar grupos de colocación concretos como prioritarios durante la reposición o la recuperación, ejecute lo siguiente:

root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

Esto hará que Ceph lleve a cabo la recuperación o la reposición en los grupos de colocación especificados, antes que en los demás. No se interrumpen las operaciones de reposición o recuperación que haya en curso, sino que los grupos de colocación especificados se procesan lo antes posible. Si cambia de opinión o se equivoca de grupo para priorizar, puede cancelar la priorización:

root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

Los comandos cancel‑* eliminan el indicador "force" de los grupos de colocación para que se procesen en el orden por defecto. Una vez más, esto no afecta a los grupos de colocación que ya se están procesando, solo a los que todavía están en cola. El indicador "force" se borra automáticamente después de que se realice la recuperación o la reposición del grupo.

Si el clúster ha perdido uno o más objetos y ha decidido abandonar la búsqueda de los datos perdidos, debe marcar los objetos no encontrados como "perdidos".

Si los objetos siguen perdidos después de haber consultado todas las ubicaciones posibles, es posible que deba darlos definitivamente por perdidos. Esto puede ocurrir si se da una combinación inusual de errores en la que se permite al clúster obtener información sobre las escrituras que se realizaron antes de que se recuperaran las escrituras en sí.

Actualmente, la única opción admitida es "revert", que revertirá a una versión anterior del objeto, o que se ignorará por completo en caso de un objeto nuevo. Para marcar los objetos "unfound" (no encontrados) como "lost" (perdidos), ejecute lo siguiente:

  cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete

Los grupos de colocación (PG) son un detalle de implementación interno de cómo Ceph distribuye los datos. Al habilitar pg-autoscaling, puede permitir que el clúster cree o ajuste automáticamente los grupos de colocación en función de cómo se utilice el clúster.

Cada repositorio del sistema tiene una propiedad pg_autoscale_mode que se puede establecer en off, on o warn:

El escalador automático se configura para cada repositorio y se puede ejecutar en tres modos:

Para definir el modo escala automático para los repositorios existentes:

cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode

También puede configurar la propiedad por defecto de pg_autoscale_mode que se aplica a cualquier repositorio que se cree en el futuro con:

cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE

Puede ver cada repositorio, su utilización relativa y los cambios sugeridos en el recuento de grupos de colocación con este comando:

cephuser@adm > ceph osd pool autoscale-status

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

Sugerencia: uso de un sistema de control de versiones

Utilice un sistema de control de versiones, como git o svn, para los archivos de mapa de CRUSH exportados y modificados. Con ellos, una posible reversión es más sencilla.

Sugerencia: prueba del nuevo mapa de CRUSH

Pruebe el nuevo mapa de CRUSH ajustado con el comando crushtool ‑‑test y compárelo con el estado anterior a la aplicación del nuevo mapa de CRUSH. Encontrará útiles los siguientes conmutadores de comandos: ‑‑show‑statistics, ‑‑show‑mappings, ‑‑show‑bad‑mappings, ‑‑show‑utilization, ‑‑show‑utilization‑all, ‑‑show‑choose‑tries.

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

cephuser@adm > ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

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

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

Hay dos comandos similares que cambian el "peso" de un Ceph OSD. El contexto en el que se usan es diferente y puede causar confusión.

17.5.3.1 ceph osd reweight #

 

Uso:

cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

ceph osd reweight define un peso de sustitución en el Ceph OSD. Este valor está en el intervalo entre 0 y 1 e impone a CRUSH que recoloque los datos que de otro modo estarían en esta unidad. No cambia los pesos asignados a los depósitos situados por encima del OSD. Se trata de una medida correctiva en caso de que la distribución normal de CRUSH no funcione del todo bien. Por ejemplo, si uno de los OSD está al 90 % y los demás están al 40 %, podría reducir este peso para tratar de compensarlos.

Nota: el peso del OSD es temporal

Tenga en cuenta que ceph osd reweight no es un ajuste persistente. Cuando un OSD se excluye, su peso se define en 0, y cuando se incluye de nuevo, el peso cambia a 1.

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

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

cephuser@adm > ceph osd crush remove OSD_NAME

Para añadir un depósito al mapa de CRUSH de un clúster en ejecución, ejecute el comando ceph osd crush add-bucket:

cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

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

cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

Por ejemplo:

cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Para eliminar un depósito de la jerarquía del mapa de CRUSH, ejecute lo siguiente:

cephuser@adm > ceph osd crush remove BUCKET_NAME

Nota: solo depósitos vacíos

un depósito debe estar vacío para que se pueda eliminar de la jerarquía de CRUSH.