Se aplica a SUSE Enterprise Storage 7.1

12 Determinación del estado del clúster #

Si dispone de un clúster en ejecución, puede utilizar la herramienta ceph para supervisarlo. Normalmente, determinar el estado del clúster implica el estado de los daemons Ceph OSD, los monitores Ceph Monitor, los grupos de colocación y los servidores de metadatos.

Sugerencia: modo interactivo

Para ejecutar la herramienta ceph en el modo interactivo, escriba ceph en la línea de comandos sin ningún argumento. El modo interactivo es más cómodo si se van a introducir más comandos ceph en una fila. Por ejemplo:

cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat

12.1 Comprobación del estado de un clúster #

Puede averiguar el estado inmediato del clúster mediante ceph status o ceph -s:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

La salida proporciona la siguiente información:

ID del clúster
Estado del clúster
Valor epoch de la asignación de monitores y estado del quórum de monitores
Valor epoch de asignación de OSD y estado de los OSD
El estado de las instancias de Ceph Manager
El estado de las pasarelas Object Gateway
La versión de asignación del grupo de colocación
El número de grupos de colocación y de repositorios
La cantidad teórica de datos almacenados y el número de objetos almacenados
La cantidad total de datos almacenados

Sugerencia: cómo calcula Ceph el uso de datos

El valor used (utilizado) refleja la cantidad real de almacenamiento en bruto utilizado. El número menor del valor xxx GB / xxx GB indica la cantidad disponible de la capacidad de almacenamiento global del clúster. El número teórico refleja el tamaño de los datos almacenados antes de que se repliquen, se clonen o se capturen en una instantánea. Por lo tanto, la cantidad de datos que se almacena realmente suele superar el almacenamiento teórico, dado que Ceph crea réplicas de los datos y también puede utilizar la capacidad de almacenamiento para tareas de clonación y de captura de instantáneas.

Otros comandos que muestran la información de estado inmediato son los siguientes:

ceph pg stat
ceph osd pool stats
ceph df
ceph df detail

Para obtener la información actualizada en tiempo real, coloque cualquiera de estos comandos (incluyendo ceph -s) como argumento del comando watch:

# watch -n 10 'ceph -s'

Pulse Control–C cuando quiera detener la visualización.

12.2 Comprobación del estado del clúster #

Una vez iniciado el clúster y antes de empezar a leer o escribir datos, compruebe su estado:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Sugerencia

Si ha especificado ubicaciones distintas de las establecidas por defecto para la configuración o el anillo de claves, puede indicarlas:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

El clúster de Ceph devolverá uno de los siguientes códigos de estado:

OSD_DOWN

Uno o varios OSD están señalados como inactivos. Se ha detenido el daemon OSD o los pares OSD no pueden acceder al OSD a través de la red. Algunas de las causas pueden ser un daemon detenido o bloqueado, un host caído o una interrupción de la red.

Compruebe que el host está en buen estado, el daemon se inicia y la red está funcionando. Si el daemon se ha bloqueado, el archivo de registro de daemon (/var/log/ceph/ceph-osd.*) puede contener información de depuración.

OSD_tipo de bloqueo_DOWN; por ejemplo: OSD_HOST_DOWN

Todos los OSD con un determinado subárbol CRUSH se marcan como inactivos, por ejemplo, todos los OSD de un host.

OSD_ORPHAN

Se hace referencia a un OSD en la jerarquía de asignaciones CRUSH, pero no existe. El OSD se puede quitar de la jerarquía CRUSH con:

cephuser@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Los umbrales de uso para backfillfull (el valor por defecto es 0,90), nearfull (por defecto, 0,85), full (por defecto, 0,95) o failsafe_full no son ascendentes. En concreto, esperamos backfillfull < nearfull, nearfull < full y full < failsafe_full.

Para leer los valores actuales, ejecute:

cephuser@adm > ceph health detail
HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)
osd.3 is full at 97%
osd.4 is backfill full at 91%
osd.2 is near full at 87%

Los umbrales se pueden ajustar con los comandos siguientes:

cephuser@adm > ceph osd set-backfillfull-ratio ratio
cephuser@adm > ceph osd set-nearfull-ratio ratio
cephuser@adm > ceph osd set-full-ratio ratio

OSD_FULL

Uno o varios OSD han excedido el umbral full, lo que impide que el clúster de servicio a las operaciones de escritura. El uso del repositorio se puede comprobar con:

cephuser@adm > ceph df

La proporción de full definida actualmente se puede consultar con:

cephuser@adm > ceph osd dump | grep full_ratio

Una solución a corto plazo para restaurar la disponibilidad de las operaciones de escritura es aumentar el umbral "full" en una pequeña cantidad:

cephuser@adm > ceph osd set-full-ratio ratio

Añada nuevo espacio de almacenamiento al clúster mediante la implantación de más OSD o suprima datos existentes para liberar espacio.

OSD_BACKFILLFULL

Uno o varios OSD han excedido el umbral backfillfull, lo que impide que los datos se puedan reequilibrar en este dispositivo. Se trata de una advertencia previa de que podría resultar imposible completar el reequilibrio y de que el clúster está casi lleno. El uso del repositorio se puede comprobar con:

cephuser@adm > ceph df

OSD_NEARFULL

Uno o varios OSD han excedido el umbral nearfull. Se trata de una advertencia previa de que el clúster está casi lleno. El uso del repositorio se puede comprobar con:

cephuser@adm > ceph df

OSDMAP_FLAGS

Se han definido uno o varios indicadores de interés en el clúster. Con la excepción de full, estos indicadores se pueden establecer o borrar con:

cephuser@adm > ceph osd set flag
cephuser@adm > ceph osd unset flag

Los indicadores son los siguientes:

full: El clúster se marca como lleno y no permite realizar operaciones de escritura.
pauserd, pausewr: Operaciones de lectura o de escritura en pausa.
noup: No se pueden iniciar los OSD.
nodown: Se omiten los informes de fallo de los OSD, de modo que los monitores no marquen los OSD como caídos (down).
noin: Los OSD que se hayan marcado como out (fuera) no se volverán a marcar como in (dentro) cuando se inicien.
noout: Los OSD caídos (down) no se marcarán automáticamente como out (fuera) después del intervalo configurado.
nobackfill, norecover, norebalance: Las operaciones de recuperación o de reequilibrio de datos están suspendidas.
noscrub, nodeep_scrub: Las operaciones de borrado seguro (consulte la Sección 17.6, “Depuración de grupos de colocación”) están inhabilitadas.
notieragent: Las actividades de niveles de caché están suspendidas.

OSD_FLAGS

Uno o varios OSD tienen establecido un indicador de interés por OSD. Los indicadores son los siguientes:

noup: El OSD no se puede iniciar.
nodown: Se omitirán los informes de errores para este OSD.
noin: Si este OSD se ha marcado anteriormente como out (fuera) tras un fallo, no se marcará como in (dentro) cuando se inicie.
noout: Si este OSD está apagado, no se marcará automáticamente como out (fuera) después del intervalo configurado.

Los indicadores por OSD se pueden definir y desactivar con:

cephuser@adm > ceph osd add-flag osd-ID
cephuser@adm > ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

La asignación CRUSH utiliza una configuración muy antigua y se debe actualizar. Los tunables más antiguos que se pueden utilizar (es decir, es la versión más antigua del cliente que se puede conectar al clúster) sin que se active esta advertencia de estado está determinada por la opción de configuración mon_crush_min_required_version.

OLD_CRUSH_STRAW_CALC_VERSION

La asignación CRUSH utiliza un método más antiguo y no óptimo para calcular los valores de peso intermedio para el ordenamiento por casilleros. La asignación CRUSH debe actualizarse para utilizar el método más reciente (straw_calc_version=1).

CACHE_POOL_NO_HIT_SET

Uno o varios repositorios de caché no están configurados con un conjunto de resultados para realizar el seguimiento del uso, lo que impide que el agente de niveles de caché identifique los objetos fríos que debe limpiar y expulsar del caché. Los conjuntos de resultados se pueden configurar en el repositorio de caché con:

cephuser@adm > ceph osd pool set poolname hit_set_type type
cephuser@adm > ceph osd pool set poolname hit_set_period period-in-seconds
cephuser@adm > ceph osd pool set poolname hit_set_count number-of-hitsets
cephuser@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

No hay ningún OSD anterior a Luminous versión 12 en ejecución, pero no se ha definido el indicador sortbitwise. Debe definir el indicador sortbitwise para que se puedan iniciar los OSD de Luminous 12 o versiones más recientes:

cephuser@adm > ceph osd set sortbitwise

POOL_FULL

Uno o varios repositorios han alcanzado su cuota y ya no permiten más operaciones de escritura. Es posible definir cuotas de repositorio y límites de uso con:

cephuser@adm > ceph df detail

Puede aumentar la cuota de repositorio con

cephuser@adm > ceph osd pool set-quota poolname max_objects num-objects
cephuser@adm > ceph osd pool set-quota poolname max_bytes num-bytes

o suprimir algunos datos para reducir el uso.

PG_AVAILABILITY

Hay una disponibilidad reducida de los datos, lo que significa que el clúster no puede responder a posibles peticiones de lectura o escritura de algunos de los datos del clúster. En particular, uno o varios grupos de colocación se encuentran en un estado que no permite atender las peticiones de E/S. Los estados de los grupos de colocación afectados son peering (emparejando), stale (detenido), incomplete (incompleto) y la ausencia de active (activo) (si dichos estados no desaparecen rápidamente). Encontrará información detallada sobre los grupos de colocación afectados en:

cephuser@adm > ceph health detail

En la mayoría de los casos, la causa raíz es que uno o varios OSD están caídos. Se puede consultar el estado de los grupos de colocación afectados específicos con:

cephuser@adm > ceph tell pgid query

PG_DEGRADED

Se reduce la redundancia de algunos datos, lo que significa que el clúster no tiene el número deseado de réplicas de todos los datos (para los repositorios replicados) o fragmentos de código de borrado (para los repositorios codificados de borrado). En concreto, uno o varios grupos de colocación tienen establecido el indicador degraded (degradado) o undersized (tamaño insuficiente) (no hay suficientes instancias de ese grupo de colocación en el clúster), o bien hace tiempo que no cuenta con el indicador clean (limpio). Encontrará información detallada sobre los grupos de colocación afectados en:

cephuser@adm > ceph health detail

En la mayoría de los casos, la causa raíz es que uno o varios OSD están caídos. Se puede consultar el estado de los grupos de colocación afectados específicos con:

cephuser@adm > ceph tell pgid query

PG_DEGRADED_FULL

La redundancia de datos se puede reducir o estar en peligro para algunos datos debido a la falta de espacio disponible en el clúster. En concreto, uno o varios grupos de colocación tienen establecidos los indicadores backfill_toofull o recovery_toofull, lo que significa que el clúster no puede migrar o recuperar datos debido a que uno o varios OSD superan el umbral backfillfull.

PG_DAMAGED

El proceso de borrado seguro de datos (consulte la Sección 17.6, “Depuración de grupos de colocación”) ha detectado problemas con la coherencia de los datos en el clúster. Específicamente, hay uno o varios grupos de colocación con el indicador inconsistent o snaptrim_error, que indican que una operación anterior de borrado seguro ha detectado un problema, o bien se ha establecido el indicador repair, lo que significa que hay una reparación de dicha incoherencia en curso.

OSD_SCRUB_ERRORS

Los procesos de borrado seguro de OSD recientes han revelado incoherencias.

CACHE_POOL_NEAR_FULL

Un repositorio de nivel de caché está casi lleno. La capacidad en este contexto está determinada por las propiedades target_max_bytes y target_max_objects que aparecen en el repositorio de caché. Cuando el repositorio alcanza el umbral objetivo, las peticiones de escritura para el repositorio podrían bloquearse hasta que los datos se limpien y se expulsen del caché, un estado que suele producir latencias muy altas y un rendimiento deficiente. El objetivo de tamaño del repositorio de caché se puede ajustar con:

cephuser@adm > ceph osd pool set cache-pool-name target_max_bytes bytes
cephuser@adm > ceph osd pool set cache-pool-name target_max_objects objects

Las actividades normales de limpieza y expulsión del caché también se pueden atascar por una reducción de la disponibilidad o el rendimiento del nivel base o por la carga global del clúster.

TOO_FEW_PGS

El número de grupos de colocación en uso está por debajo del umbral configurable de grupos de colocación por OSD (mon_pg_warn_min_per_osd). Esto puede producir una distribución y reequilibrio de datos subóptimo entre los OSD del clúster y reducir el rendimiento general.

TOO_MANY_PGS

El número de grupos de colocación en uso está por encima del umbral configurable de grupos de colocación por OSD (mon_pg_warn_max_per_osd). Esto puede dar lugar a un uso más elevado de memoria para los daemons de OSD, un emparejamiento más lento después de cambios de estado del clúster (por ejemplo, reinicios, incorporaciones o eliminaciones de OSD) y una mayor carga mayor en los gestores y monitores de Ceph.

Aunque no es posible reducir el valor de pg_num para los repositorios existentes, sí se puede reducir el valor de pgp_num. A efectos prácticos, esto sitúa algunos grupos de colocación en los mismos conjuntos de OSD, mitigando algunos de los impactos negativos descritos anteriormente. El valor pgp_num se puede ajustar con:

cephuser@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

Uno o varios repositorios tienen un valor pgp_num inferior a pg_num. Por lo general, esto suele indicar que se ha aumentado el número de grupos de colocación sin aumentar al mismo tiempo el comportamiento de colocación. Normalmente, el problema se resuelve definiendo pgp_num para que coincida con pg_num, lo que activa la migración de datos:

cephuser@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Uno o varios repositorios tienen un número medio de objetos por grupo de colocación significativamente superior al promedio general del clúster. El umbral específico se controla mediante el valor de configuración mon_pg_warn_max_object_skew. Esto suele indicar que los repositorios que contienen la mayoría de los datos del clúster disponen de muy pocos grupos de colocación o que los demás repositorios, que no contienen tantos datos, tienen demasiados grupos de colocación. Se puede elevar el umbral para silenciar la advertencia de estado; para ello, ajuste la opción de configuración mon_pg_warn_max_object_skew en los monitores.

POOL_APP_NOT_ENABLED

Existe un repositorio que contiene uno o varios objetos, pero no se ha etiquetado para su uso por parte de una aplicación determinada. Para resolver esta advertencia, etiquete el repositorio para su uso por parte de una aplicación. Por ejemplo, si el repositorio lo utiliza RBD:

cephuser@adm > rbd pool init pool_name

Si el repositorio está siendo utilizado por una aplicación personalizada "foo", también se puede etiquetar mediante el comando de bajo nivel:

cephuser@adm > ceph osd pool application enable foo

POOL_FULL

Uno o varios repositorios han alcanzado su cuota (o van a alcanzarla muy pronto). El umbral para que se active esta situación de error depende de la opción de configuración mon_pool_quota_crit_threshold. Las cuotas del repositorio se pueden aumentar, reducir o eliminar con:

cephuser@adm > ceph osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd pool set-quota pool max_objects objects

Si define el valor de la cuota como 0, la cuota se inhabilitará.

POOL_NEAR_FULL

Uno o varios repositorios se están aproximando a su cuota. El umbral para que se active esta situación de advertencia depende de la opción de configuración mon_pool_quota_warn_threshold. Las cuotas del repositorio se pueden aumentar, reducir o eliminar con:

cephuser@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd osd pool set-quota pool max_objects objects

Si define el valor de la cuota como 0, la cuota se inhabilitará.

OBJECT_MISPLACED

Uno o varios objetos del clúster no se almacenan en el nodo en el que clúster pretende hacerlo. Esto indica que una migración de datos debida a algunos cambios recientes del clúster aún no se ha completado. El almacenamiento de datos en el lugar equivocado no es una situación peligrosa por sí misma. La coherencia de los datos nunca corre peligro y las copias antiguas de los objetos no se eliminan hasta que se alcanza el número de copias nuevas deseadas (en las ubicaciones correctas).

OBJECT_UNFOUND

No es posible encontrar uno o más objetos en el clúster. En concreto, los OSD saben que debe existir una copia nueva o actualizada de un objeto, pero no se ha encontrado ninguna copia de esa versión del objeto en los OSD que están actualmente activos. Las peticiones de lectura o escritura a los objetos "unfound" (no encontrados) se bloquean. Idealmente, el OSD inactivo que tiene la copia más reciente del objeto no encontrado se puede volver a activar. Los OSD candidatos se pueden identificar a partir del estado de emparejamiento de los grupos de colocación responsables del objeto no encontrado:

cephuser@adm > ceph tell pgid query

REQUEST_SLOW

Una o varias peticiones de OSD tardan mucho tiempo en procesarse. Esto puede indicar un nivel de carga extremo, un dispositivo de almacenamiento lento o un fallo de software. Puede consultar la cola de peticiones de los OSD en cuestión ejecutando el siguiente comando desde el host OSD:

cephuser@adm > cephadm enter --name osd.ID -- ceph daemon osd.ID ops

Puede consultar un resumen de las peticiones más lentas realizadas recientemente:

cephuser@adm > cephadm enter --name osd.ID -- ceph daemon osd.ID dump_historic_ops

Puede consultar la ubicación de un OSD con:

cephuser@adm > ceph osd find osd.id

REQUEST_STUCK

Una o más peticiones de OSD se han bloqueado durante un tiempo relativamente largo, por ejemplo 4096 segundos. Esto indica que el clúster lleva un periodo prolongado de tiempo en un estado incorrecto (por ejemplo, no hay suficientes OSD en ejecución o grupos de colocación inactivos) o que hay algún problema interno con el OSD.

PG_NOT_SCRUBBED

A uno o varios de los grupos de colocación no se les ha aplicado el borrado seguro (consulte la Sección 17.6, “Depuración de grupos de colocación”) recientemente. Normalmente, a los grupos de colocación se les aplica el borrado seguro cuando transcurre el número de segundos indicado en mon_scrub_interval; esta advertencia se activa cuando transcurren los intervalos indicados en mon_warn_not_scrubbed sin que se realice un borrado seguro. A los grupos de colocación no se les aplicará el borrado seguro si no están marcados como limpios; esto puede ocurrir si se extravían o se degradan (consulte PG_AVAILABILITY y PG_DEGRADED más arriba). Puede iniciar manualmente el borrado seguro de un grupo de colocación limpio con:

cephuser@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Uno o varios grupos de colocación no se han sometido a un borrado seguro profundo (consulte la Sección 17.6, “Depuración de grupos de colocación”) recientemente. Normalmente, a los grupos de colocación se les aplica un borrado seguro profundo cuando transcurre el número de segundos indicado en osd_deep_mon_scrub_interval; esta advertencia se activa cuando transcurren los segundos indicados en mon_warn_not_deep_scrubbed sin que se realice un borrado seguro profundo. A los grupos de colocación no se les aplicará el borrado seguro profundo si no están marcados como limpios; esto puede ocurrir si se extravían o se degradan (consulte PG_AVAILABILITY y PG_DEGRADED más arriba). Puede iniciar manualmente el borrado seguro de un grupo de colocación limpio con:

cephuser@adm > ceph pg deep-scrub pgid

Sugerencia

Si ha especificado ubicaciones distintas de las establecidas por defecto para la configuración o el anillo de claves, puede indicarlas:

# ceph -c /path/to/conf -k /path/to/keyring health

12.3 Comprobación de las estadísticas de uso de un clúster #

Para comprobar el uso de datos de un clúster y la distribución de datos entre los repositorios, utilice el comando ceph df. Para obtener más detalles, utilice ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

La sección RAW STORAGE del resultado proporciona una descripción general de la cantidad de almacenamiento que utiliza el clúster para los datos.

CLASS: la clase de almacenamiento del dispositivo. Consulte la Sección 17.1.1, “Clases de dispositivos” para obtener más información sobre las clases de dispositivos.
SIZE: capacidad de almacenamiento global del clúster.
AVAIL: cantidad de espacio disponible en el clúster.
USED: el espacio (acumulado en todos los OSD) asignado exclusivamente para objetos de datos conservados en el dispositivo de bloques.
RAW USED: la suma del espacio "USED" y el espacio asignado/reservado en el dispositivo de bloques para propósitos de Ceph, por ejemplo la parte BlueFS para BlueStore.
% RAW USED: porcentaje de almacenamiento en bruto utilizado. Utilice este número junto con full ratio (lleno) y near full ratio (casi lleno) para asegurarse de que no se alcanza la capacidad de su clúster. Consulte la Sección 12.8, “Capacidad de almacenamiento” para obtener más información.
Nota: nivel de llenado de clúster
Cuando un nivel de llenado de almacenamiento en bruto se acerca al 100 %, debe añadir nuevo almacenamiento al clúster. Un nivel de uso más elevado puede provocar que algunos OSD se llenen y se produzcan problemas de estado del clúster.
Utilice el comando ceph osd df tree para que se muestre el nivel de llenado de todos los OSD.

La sección POOLS de la salida proporciona una lista de los repositorios y el uso teórico de cada uno de ellos. La salida de esta sección no refleja las réplicas, las clonaciones ni las instantáneas. Por ejemplo, si almacena un objeto con 1 MB de datos, el uso teórico es de 1 MB, pero el uso real puede ser de 2 MB o más, según el número de réplicas, clonaciones e instantáneas.

POOL: el nombre del repositorio.
ID: ID del repositorio.
STORED: la cantidad de datos almacenados por el usuario.
OBJECTS: el número teórico de objetos almacenados por repositorio.
USED: la cantidad de espacio asignado exclusivamente para los datos por todos los nodos de OSD, en kB.
%USED: el porcentaje teórico del almacenamiento utilizado por repositorio.
MAX AVAIL: el espacio máximo disponible en el repositorio especificado.

Nota

Las cifras de la sección POOLS son teóricas. No incluyen el número de réplicas, clonaciones o instantáneas. Por lo tanto, la suma de las cantidades de USED y %USED no se sumará a las cantidades de RAW USED y %RAW USED de la sección RAW STORAGE del resultado.

12.4 Comprobación del estado de los OSD #

Para comprobar los OSD y asegurarse de que estén activos y conectados, ejecute:

cephuser@adm > ceph osd stat

o bien

cephuser@adm > ceph osd dump

También puede ver los OSD según su posición en la asignación de CRUSH.

ceph osd tree imprime un árbol de CRUSH con un host, sus OSD, su estado de funcionamiento y su peso:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

12.5 Comprobación de OSD llenos #

Ceph impide escribir en un OSD lleno para que no se pierden datos. En un clúster en funcionamiento, debería aparecer una advertencia cuando el clúster se esté aproximando al máximo de su capacidad. El valor por defecto de mon osd full ratio es de 0,95 o un 95 % de capacidad para impedir la escritura de datos a los clientes. El valor por defecto de mon osd nearfull ratio es de 0,85 o 85 % de capacidad para generar una advertencia de estado.

El comando ceph health informa de los nodos de OSD llenos:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

o bien

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

La mejor forma de ocuparse de un clúster lleno es añadir hosts de OSD o discos para que el clúster redistribuya los datos en el nuevo espacio de almacenamiento disponible.

Sugerencia: cómo evitar que los OSD se llenen

Si un OSD se llena (usa el 100 % de su espacio de disco), normalmente se bloqueará de inmediato y sin previo aviso. A continuación indicamos algunos consejos que conviene recordar al administrar nodos de OSD.

El espacio de disco de cada OSD (normalmente montado en /var/lib/ceph/osd/osd-{1,2..}) debe colocarse en un disco o en una partición de uso dedicado.
Compruebe los archivos de configuración de Ceph y asegúrese de que Ceph no almacena el archivo de registro en las particiones o los discos cuyo uso esté dedicado a los OSD.
Asegúrese de que ningún otro proceso escribe en los discos o en las particiones de uso dedicado de los OSD.

12.6 Comprobación del estado del monitor #

Después de iniciar el clúster y antes de leer o escribir datos por primera vez, compruebe el estado de quórum de los monitores Ceph Monitor. Si el clúster ya está sirviendo peticiones, compruebe periódicamente el estado de los monitores Ceph Monitor para asegurarse de que se están ejecutando.

Para ver la asignación de monitores, ejecute lo siguiente:

cephuser@adm > ceph mon stat

o bien

cephuser@adm > ceph mon dump

Para comprobar el estado de quórum del clúster de monitores, ejecute lo siguiente:

cephuser@adm > ceph quorum_status

Ceph devolverá el estado de quórum. Por ejemplo, un clúster de Ceph que consta de tres monitores podría devolver lo siguiente:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

12.7 Comprobación del estado de los grupos de colocación #

Los grupos de colocación asignan objetos a los OSD. Al supervisar los grupos de colocación, es conveniente que tengan los estados active (activo) y clean (limpio). Para obtener información detallada, consulte la Sección 12.9, “Supervisión de los OSD y los grupos de colocación”.

12.8 Capacidad de almacenamiento #

Cuando un clúster de almacenamiento de Ceph se acerca a su capacidad máxima, Ceph impide escribir o leer desde los Ceph OSD como medida de seguridad para evitar la pérdida de datos. Por lo tanto, permitir que un clúster de producción se acerque a su máximo de capacidad no es una buena práctica, ya que se sacrifica la alta disponibilidad. El máximo de capacidad por defecto se define en .95, lo que significa el 95 % de la capacidad. Se trata de un valor muy agresivo para un clúster de pruebas con un número pequeño de OSD.

Sugerencia: aumento de la capacidad de almacenamiento

Al supervisar el clúster, esté alerta a las advertencias relacionadas con la proporción de nearfull (casi lleno). Significa que un error de algunos OSD podría dar lugar a una interrupción temporal del servicio si se produce un error en uno o más OSD. Considere la posibilidad de añadir más OSD para aumentar la capacidad de almacenamiento.

Un escenario habitual para los clústeres de prueba es la de un administrador del sistema que elimina un Ceph OSD del clúster de almacenamiento de Ceph para observar el reequilibrio del clúster. A continuación, quita otro Ceph OSD, y así sucesivamente hasta que el clúster finalmente alcanza su máxima capacidad y se bloquea. Se recomienda cierta planificación de la capacidad incluso en el caso de un clúster de pruebas. La planificación permite estimar la capacidad de repuesto que se necesitará para poder mantener la alta disponibilidad. En una situación ideal, desea planear una serie de errores del Ceph OSD en los que el clúster puede recuperarse a un estado activo + limpio sin tener que sustituir esos Ceph OSD de inmediato. Puede ejecutar un clúster en un estado activo + degradado, pero no es lo ideal para condiciones de funcionamiento normales.

En el diagrama siguiente se muestra un clúster de almacenamiento de Ceph simplificado que contiene 33 nodos Ceph con un Ceph OSD por host. Cada uno de ellos lee y escribe en una unidad de 3 TB. Este clúster de ejemplo tiene una capacidad real máxima de 99 TB. La opción mon osd full ratio se define en 0,95. Si el clúster cae por debajo de los 5 TB de capacidad restante, no permitirá que los clientes lean y escriban datos. Por lo tanto, la capacidad operativa del clúster de almacenamiento es de 95 TB, no de 99 TB.

Figura 12.1: Clúster de Ceph #

En este tipo de clúster, es normal que uno o dos OSD fallen. Un escenario menos frecuente, aunque razonable, implica que el router o la fuente de alimentación de un bastidor falle, lo que desactiva varios OSD simultáneamente (por ejemplo, los OSD del 7 al 12). En esa situación, debe seguir intentando que un clúster pueda permanecer operativo y logre un estado activo + limpio, incluso si eso significa añadir algunos hosts con OSD adicionales a corto plazo. Si el uso de la capacidad es demasiado alto, es posible que no pierda datos. Sin embargo, aún podría sacrificar la disponibilidad de los datos y resolver al mismo tiempo una interrupción dentro de un dominio de error si el uso de capacidad del clúster supera el máximo. Por este motivo, se recomienda que se realice al menos una planificación aproximada de la capacidad.

Identifique dos valores para el clúster:

El número de OSD.
La capacidad total del clúster.

Si divide la capacidad total del clúster por el número de OSD del clúster, encontrará la capacidad media de un OSD dentro del clúster. También puede multiplicar ese número por el número de OSD que espera que fallen simultáneamente durante las operaciones normales (un número relativamente pequeño). Por último, multiplique la capacidad del clúster por la capacidad máxima para descubrir la capacidad operativa máxima. A continuación, reste la cantidad de datos de los OSD que espera que no lleguen al máximo de capacidad razonable. Repita el proceso anterior con un mayor número de errores de OSD (un bastidor de OSD) para llegar a un número razonable capacidad casi máxima.

Los valores siguiente solo se aplica durante la creación del clúster y, después, se almacena en el mapa de OSD:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Sugerencia

Estos valores solo se aplican durante la creación del clúster. Después deben cambiarse en el mapa de OSD utilizando los comandos ceph osd set-nearfull-ratio y ceph osd set-full-ratio.

mon osd full ratio: El porcentaje de espacio en disco utilizado antes de un OSD se considera que está lleno. El valor por defecto es .95.
mon osd backfillfull ratio: El porcentaje de espacio en disco utilizado antes de un OSD se considera que está demasiado lleno para la reposición. El valor por defecto es .90.
mon osd nearfull ratio: El porcentaje de espacio en disco utilizado antes de un OSD se considera que está casi lleno. El valor por defecto es .85.

Sugerencia: comprobación del peso del OSD

Si algunos OSD están casi llenos, pero otros tienen mucha capacidad, es posible que tenga un problema con el peso de CRUSH para los OSD casi llenos.

12.9 Supervisión de los OSD y los grupos de colocación #

La alta disponibilidad y la alta confiabilidad requieren un enfoque tolerante a fallos para gestionar problemas de hardware y software. Ceph no tiene un único punto de error y puede atender peticiones de datos en un modo "degradado". La colocación de datos de Ceph introduce una capa de direccionamiento indirecto para garantizar que los datos no se enlacen directamente a determinadas direcciones de OSD. Eso significa que para el seguimiento de los errores del sistema es necesario buscar el grupo de colocación y los OSD subyacentes en la raíz del problema.

Sugerencia: acceso en caso de fallo

Un error en una parte del clúster puede impedir que se acceda a un objeto determinado. Eso no significa que no se pueda acceder a otros objetos. Si encuentra un error, siga los pasos para supervisar los OSD y los grupos de colocación. A continuación, comience el proceso de solución de problemas.

Ceph, generalmente, se puede autorreparar. Sin embargo, si los problemas persisten, la supervisión de los OSD y los grupos de colocación ayudará a identificar el problema.

12.9.1 Supervisión de OSD #

El estado de un OSD se encuentra en el clúster ("in") o fuera del clúster ("out"). Al mismo tiempo, está en activo y en ejecución ("up") o desactivado y sin ejecutarse ("down"). Si un OSD está "up", puede estar en el clúster (es posible leer y escribir datos) o fuera del clúster. Si estaba en el clúster y se movió recientemente fuera del clúster, Ceph migrará los grupos de colocación a otros OSD. Si un OSD está fuera del clúster, CRUSH no le asignará grupos de colocación. Si un OSD está "down", también debe estar "out".

Nota: estado incorrecto

Si un OSD está "down" e "in", hay un problema y el clúster no estará en un estado correcto.

Si ejecuta un comando como ceph health, ceph -s o ceph -w, puede darse el caso de que el clúster no siempre devuelva el estado HEALTH OK. Con respecto a los OSD, debe esperar que el clúster no devuelva HEALTH OK en las siguientes circunstancias:

Todavía no ha iniciado el clúster (no responderá).
Ha iniciado o reiniciado el clúster y aún no está listo, ya que se están creando los grupos de colocación y los OSD están en proceso de emparejamiento.
Ha añadido o eliminado un OSD.
Ha modificado el mapa del clúster.

Un aspecto importante de la supervisión de los OSD es asegurarse de que cuando el clúster está activo y en ejecución, todos los OSD del clúster también lo estén. Para comprobar si todos los OSD se están ejecutando, ejecute:

# ceph osd stat
x osds: y up, z in; epoch: eNNNN

El resultado debería indicarle el número total de OSD (x), cuántos están "up" (y), cuántos están "in" (z) y la época del mapa (eNNNN). Si el número de OSD que están "in" en el clúster es mayor que el número de OSD que están "up", ejecute el comando siguiente para identificar los daemons ceph-osd que no se están ejecutando:

# ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Por ejemplo, si un OSD con ID 1 está inactivo, para iniciarlo:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Consulte el Section 4.3, “OSDs not running” para consultar los problemas asociados con los OSD que se han detenido o que no se reinician.

12.9.2 Asignación de conjuntos de grupos de colocación #

Cuando CRUSH asigna grupos de colocación a los OSD, examina el número de réplicas del repositorio y asigna el grupo de colocación a los OSD de forma que cada réplica del grupo de colocación se asigne a un OSD diferente. Por ejemplo, si el repositorio requiere tres réplicas de un grupo de colocación, CRUSH puede asignarlas a osd.1, osd.2 y osd.3 respectivamente. CRUSH en realidad intenta realizar una colocación seudoaleatoria que tenga en cuenta los dominios de error que establezca en su mapa de CRUSH, por lo que rara vez verá grupos de colocación asignados a los OSD vecinos más cercanos en un clúster grande. El conjunto de OSD que deben contener las réplicas de un grupo de colocación determinado se conoce como conjunto que actúa. En algunos casos, un OSD del conjunto que actúa está inactivo o no puede atender las peticiones de objetos del grupo de colocación. Si se da ese caso, puede deberse a uno de los siguientes escenarios:

Ha añadido o eliminado un OSD. En tal caso, CRUSH reasignó el grupo de colocación a otros OSD y, por lo tanto, cambió la composición del conjunto que actúa, lo que provocó la migración de datos con un proceso de "reposición".
Un OSD con el estado "down", se ha reiniciado y ahora se está recuperando.
Un OSD del conjunto que actúa tiene el estado "down" o no puede atender peticiones, y otro OSD ha asumido temporalmente sus funciones.
Ceph procesa la petición de un cliente con conjunto activo, que es el conjunto de OSD que realmente controlarán las peticiones. En la mayoría de los casos, el conjunto activo y el conjunto que actúa son prácticamente idénticos. Cuando no lo son, puede indicar que Ceph está migrando datos, que un OSD se está recuperando o que hay un problema (por ejemplo, Ceph suele responde a un estado HEALTH WARN con un mensaje "bloqueo obsoleto" en tales casos).

Para recuperar una lista de grupos de colocación, ejecute:

cephuser@adm > ceph pg dump

Para ver qué OSD están dentro del conjunto que actúa o del conjunto activo para un grupo de colocación determinado, ejecute:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

El resultado debe indicar la época de osdmap (eNNN), el número del grupo de colocación (PG_NUM), los OSD del conjunto activo ("up") y los OSD del conjunto que actúa ("acting"):

Sugerencia: indicador de problema del clúster

Si el conjunto activo y el conjunto que actúa no coinciden, puede ser un indicador de que el clúster se está reequilibrando o de que hay un posible problema con el clúster.

12.9.3 Emparejamiento #

Para poder escribir datos en un grupo de colocación, este debe estar en un estado activo y es recomendable que esté en un estado limpio. Para que Ceph determine el estado actual de un grupo de colocación, el OSD primario del grupo de colocación (el primer OSD del conjunto que actúa) se empareja con los OSD secundario y terciario para establecer un acuerdo sobre el estado actual del grupo de colocación (suponiendo que el repositorio tenga tres réplicas del grupo de colocación).

Figura 12.2: Esquema de emparejamiento #

12.9.4 Supervisión de los estados del grupo de colocación #

Si ejecuta un comando como ceph health, ceph -s o ceph -w, puede darse el caso de que el clúster no siempre devuelva el mensaje HEALTH OK. Después de comprobar si los OSD se están ejecutando, también debe comprobar los estados del grupo de colocación.

Es previsible que el clúster no devuelva HEALTH OK en varias circunstancias relacionadas con el emparejamiento del grupo de colocación:

Ha creado un repositorio y los grupos de colocación aún no se han emparejado.
Los grupos de colocación se están recuperando.
Ha añadido o ha eliminado un OSD del clúster.
Ha modificado el mapa de CRUSH y los grupos de colocación están migrando.
Hay datos incoherentes en diferentes réplicas de un grupo de colocación.
Ceph está borrando de forma segura las réplicas de un grupo de colocación.
Ceph no tiene suficiente capacidad de almacenamiento para completar las operaciones de reposición.

Si una de las circunstancias mencionadas hace que Ceph devuelva el estado HEALTH WARN, no se preocupe. En muchos casos, el clúster se recuperará por sí solo. En algunos casos, es posible que deba tomar alguna medida. Un aspecto importante a la hora de supervisar los grupos de colocación es que debe asegurarse de que cuando el clúster esté activo y en funcionamiento, todos los grupos de colocación deben estar "activos" y, preferiblemente, en un "estado limpio". Para ver el estado de todos los grupos de colocación, ejecute:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

El resultado debe indicar el número total de grupos de colocación (x); cuántos grupos de colocación están en un estado determinado, como "activo+limpio" (y) y la cantidad de datos almacenados (z).

Además de los estados del grupo de colocación, Ceph también devolverá la cantidad de capacidad de almacenamiento utilizada (aa), la cantidad de capacidad de almacenamiento restante (bb) y la capacidad de almacenamiento total para el grupo de colocación. Estos valores pueden ser importantes en algunos casos:

Cuando se está alcanzando la capacidad casi máxima o la capacidad máxima.
Cuando los datos no se están distribuyendo por el clúster debido a un error en la configuración de CRUSH.

Sugerencia: ID de grupos de colocación

Los ID de grupo de colocación constan del número de repositorio (no el nombre del repositorio ) seguido de un punto (.) y el ID del grupo de colocación (un número hexadecimal). Puede ver los números de repositorio y sus nombres en el resultado de ceph osd lspools. Por ejemplo, el repositorio por defecto rbd corresponde al número de repositorio 0. Un ID de grupo de colocación completo tiene el siguiente formato:

POOL_NUM.PG_ID

Y, normalmente, este aspecto:

0.1f

Para recuperar una lista de grupos de colocación, ejecute lo siguiente:

cephuser@adm > ceph pg dump

También puede dar al resultado formato JSON y guardarlo en un archivo:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Para consultar un grupo de colocación determinado, ejecute lo siguiente:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

En la lista siguiente se describen en detalle los estados habituales del grupo de colocación.

CREATING (CREACIÓN)

Cuando se crea un repositorio, se crea el número de grupos de colocación especificados. Ceph devolverá el mensaje "creating" cuando está creando uno o más grupos de colocación. Cuando se creen, los OSD que formen parte del conjunto que actúa del grupo de colocación se emparejarán. Cuando el emparejamiento se haya completado, el estado del grupo de colocación debe ser "activo+limpio", lo que significa que un cliente de Ceph puede comenzar a escribir en el grupo de colocación.

Figura 12.3: Estado de los grupos de colocación #

PEERING (EMPAREJAMIENTO)

Cuando Ceph empareja un grupo de colocación, está poniendo de acuerdo los OSD donde se almacenan las réplicas del grupo de colocación sobre el estado de los objetos y los metadatos del grupo de colocación. Cuando Ceph completa el emparejamiento, significa que los OSD donde se almacenan el grupo de colocación están de acuerdo sobre el estado actual de dicho grupo. Sin embargo, que el proceso de emparejamiento haya finalizado no significa que cada réplica tenga el contenido más reciente.

Nota: historial oficial

Ceph no reconocerá una operación de escritura a un cliente hasta que todos los OSD del conjunto que actúa persistan en la operación de escritura. Esta práctica garantiza que al menos un miembro del conjunto que actúa tendrá un registro de cada operación de escritura reconocida desde la última operación de emparejamiento correcta.

Con un registro preciso de cada operación de escritura reconocida, Ceph puede construir y ampliar un nuevo historial oficial del grupo de colocación: un conjunto completo y completamente ordenado de operaciones que, si se realiza, actualizaría una copia del OSD de un grupo de colocación.

ACTIVE (ACTIVO)

Cuando Ceph completa el proceso de emparejamiento, un grupo de colocación puede convertirse en activo. El estado activo significa que los datos del grupo de colocación están generalmente disponibles en el grupo de colocación primario y en las réplicas para las operaciones de lectura y escritura.

CLEAN (LIMPIO)

Cuando un grupo de colocación está en estado limpio, el OSD primario y los OSD de réplica se han emparejado correctamente y no hay réplicas perdidas para el grupo de colocación. Ceph ha replicado todos los objetos del grupo de colocación el número correcto de veces.

DEGRADED (DEGRADADO)

Si un cliente escribe un objeto en el OSD primario, este es responsable de escribir las réplicas en los OSD de réplica. Después de que el OSD primario escriba el objeto en el almacenamiento, el grupo de colocación permanecerá en un estado "degradado" hasta que el OSD primario haya recibido una confirmación de los OSD de réplica de que Ceph ha creado los objetos de réplica correctamente.

La razón por la que un grupo de colocación puede tener el estado "activo+degradado" es que un OSD puede estar "activo" aunque aún no contenga todos los objetos. Si un OSD deja de estar activo, Ceph marca cada grupo de colocación asignado al OSD como "degradado". Los OSD deben emparejarse de nuevo cuando el OSD vuelva a funcionar. Sin embargo, un cliente todavía puede escribir un objeto nuevo en un grupo de colocación degradado si su estado es "activo".

Si un OSD está "inactivo" y la condición "degradado" persiste, Ceph puede marcar el OSD inactivo como "externo" al clúster y volver a asignar los datos del OSD "inactivo" a otro OSD. El tiempo que transcurre entre que se marca como "inactivo" y se marca como "externo" se controla mediante la opción mon osd out interval, que se establece en 600 segundos por defecto.

Un grupo de colocación también puede estar "degradado" porque Ceph no pueda encontrar uno o varios objetos que deberían estar en el grupo de colocación. Aunque no puede leer ni escribir en objetos no encontrados, puede acceder a todos los demás objetos del grupo de colocación "degradado".

RECOVERING (EN RECUPERACIÓN)

Ceph se ha diseñado para la tolerancia a fallos a una escala en la que los problemas de hardware y software son continuos. Cuando un OSD está "inactivo", su contenido puede quedar obsoleto respecto al de otras réplicas de los grupos de colocación. Cuando el OSD vuelve a estar "activo", el contenido de los grupos de colocación debe actualizarse para reflejar el estado actual. Durante ese período de tiempo, el OSD puede mostrar el estado de "en recuperación".

La recuperación no siempre es sencilla, ya que un error de hardware puede provocar un error en cascada de varios OSD. Por ejemplo, puede fallar un conmutador de red de un bastidor o un archivador, lo que puede provocar que el estado actual de los OSD de varias máquinas host quede retrasado respecto al clúster. Cada uno de los OSD debe recuperarse cuando se resuelva el error.

Ceph proporciona varios ajustes para equilibrar la contención de los recursos entre las peticiones de servicio nuevas y la necesidad de recuperar objetos de datos y restaurar los grupos de colocación al estado actual. El valor osd recovery delay start permite que un OSD se reinicie, vuelva a emparejarse e, incluso, que procese algunas peticiones de respuesta antes de iniciar el proceso de recuperación. El valor osd recovery thread timeout define un tiempo límite del hilo, ya que varios OSD pueden fallar, reiniciarse y volver a emparejarse escalonadamente. El valor osd recovery max active limita el número de peticiones de recuperación que un OSD procesará simultáneamente para evitar que el OSD no pueda atender las peticiones. El valor osd recovery max chunk limita el tamaño de los fragmentos de datos recuperados para evitar la congestión de la red.

BACK FILLING (EN REPOSICIÓN)

Cuando un nuevo OSD se une al clúster, CRUSH reasignará los grupos de colocación de los OSD del clúster al OSD recién añadido. Forzar al nuevo OSD a aceptar los grupos de colocación reasignados de inmediato, podría suponer una carga excesiva en el OSD nuevo. Al reponer los grupos de colocación en el OSD, este proceso puede comenzar en segundo plano. Una vez completado la reposición, el nuevo OSD comenzará a atender las peticiones cuando esté listo.

Durante las operaciones de reposición, es posible que vea uno de estos estados: "backfill_wait" indica que una operación de reposición está pendiente, pero aún no está en curso; "backfill" indica que una operación de reposición está en curso; "backfill_too_full" indica que se ha solicitado una operación de reposición, pero no se ha podido completar debido a que no hay capacidad de almacenamiento suficiente. Si no se puede realizar la reposición de un grupo de colocación, puede considerarse como "incompleto".

Ceph proporciona varios ajustes para gestionar la carga asociada con la reasignación de grupos de colocación a un OSD (especialmente un OSD nuevo). Por defecto, osd max backfills define que el número máximo de reposiciones simultáneas hacia o desde un OSD sea de 10. El valor backfill full ratio permite que un OSD rechace una petición de reposición si el OSD se acerca a su capacidad máxima (90 %, por defecto), que se cambia con ceph osd set-backfillfull-ratio. Si un OSD rechaza una petición de reposición, el valor osd backfill retry interval permite que un OSD vuelva a intentar la petición (después de 10 segundos, por defecto). También es posible definir en los OSD los valores osd backfill scan min y osd backfill scan max para gestionar los intervalos de escaneo (64 y 512, por defecto).

REMAPPED (REASIGNADO)

Cuando cambia el conjunto que actúa que atiende a un grupo de colocación, los datos migran del conjunto que actúa antiguo al nuevo. El nuevo OSD primario puede tardar algún tiempo en atender las peticiones de servicio. Por lo tanto, puede pedir al OSD primario antiguo que continúe atendiendo las peticiones hasta que se complete la migración del grupo de colocación. Cuando se completa la migración de los datos, la asignación utiliza el OSD primario del conjunto que actúa nuevo.

STALE (OBSOLETO)

Mientras Ceph utiliza subejecución de réplica para asegurarse de que los hosts y los daemons se están ejecutando, los daemons ceph-osd también pueden entrar en estado "bloqueo", en el que no informan sobre las estadísticas a tiempo (por ejemplo, si se produce un error temporal de la red). Por defecto, los daemons de OSD informan de las estadísticas de su grupo de colocación, del arranque y de los errores cada medio segundo (0,5), que es una frecuencia mayor a la de los umbrales de subejecución de réplica. Si el OSD primario del conjunto que actúa de un grupo de colocación no informa al monitor, o si otros OSD han informado de que el OSD primario está "inactivo", los monitores marcarán el grupo de colocación como "obsoleto".

Al iniciar el clúster, es común ver el estado "obsoleto" hasta que se completa el proceso de emparejamiento. Después de que el clúster se haya estado ejecutando durante un tiempo, ver grupos de colocación con el estado "obsoleto" indica que el OSD primario para esos grupos de colocación está inactivo o no informa sobre las estadísticas del grupo de colocación al monitor.

12.9.5 Búsqueda de una ubicación de objeto #

Para almacenar datos de objetos en el almacén de objetos de Ceph, es preciso que un cliente de Ceph defina un nombre de objeto y que especifique un repositorio relacionado. El cliente de Ceph recupera el mapa más reciente del clúster y el algoritmo CRUSH calcula cómo asignar el objeto a un grupo de colocación. A continuación, calcula cómo asignar el grupo de colocación a un OSD dinámicamente. Para localizar la ubicación del objeto, solo se necesita el nombre del objeto y el nombre del repositorio. Por ejemplo:

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

Ejemplo 12.1: Localización de un objeto #

Como ejemplo, vamos a crear un objeto. Especifique el nombre de objeto "test-object-1", una vía al archivo de ejemplo "testfile.txt" que contiene algunos datos de objeto y el nombre de repositorio "data". Para ellos utilizaremos el comando rados put en la línea de comandos:

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

Para verificar que el almacén de objetos de Ceph ha almacenado el objeto, ejecute lo siguiente:

cephuser@adm > rados -p data ls

Ahora, identifique la ubicación del objeto. Ceph generará la ubicación del objeto:

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

Para eliminar el objeto de ejemplo, basta con eliminarlo usando el comando rados rm:

cephuser@adm > rados rm test-object-1 --pool=data