Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

6 Determinación del estado del clúster Edit source

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
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:

cephadm@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

6.1 Comprobación del estado de un clúster Edit source

Para comprobar el estado de un clúster, ejecute lo siguiente:

cephadm@adm > ceph status

O bien

cephadm@adm > ceph -s

En el modo interactivo, escriba status (estado) y pulse Intro.

ceph> status

Ceph mostrará el estado del clúster. Por ejemplo, un pequeño clúster de Ceph que conste de un monitor y dos OSD puede mostrar lo siguiente:

cluster b370a29d-9287-4ca3-ab57-3d824f65e339
 health HEALTH_OK
 monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1
 osdmap e63: 2 osds: 2 up, 2 in
  pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects
        115 GB used, 167 GB / 297 GB avail
               1 active+clean+scrubbing+deep
             951 active+clean

6.2 Comprobación del estado del clúster Edit source

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

cephadm@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
Sugerencia

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

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > ceph osd set-backfillfull-ratio ratio
cephadm@adm > ceph osd set-nearfull-ratio ratio
cephadm@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:

cephadm@adm > ceph df

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

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > ceph osd set flag
cephadm@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 9.6, “Borrado seguro”) 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:

cephadm@adm > ceph osd add-flag osd-ID
cephadm@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:

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

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

OSD_NO_SORTBITWISE

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

cephadm@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:

cephadm@adm > ceph df detail

Puede aumentar la cuota de repositorio con

cephadm@adm > ceph osd pool set-quota poolname max_objects num-objects
cephadm@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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@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 9.6, “Borrado seguro”) 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:

cephadm@adm > ceph osd pool set cache-pool-name target_max_bytes bytes
cephadm@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.

Obtenga más información sobre los niveles de caché, en el Capítulo 14, Niveles de caché.

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.

No es posible reducir el valor pg_num para los repositorios existentes. Sin embargo, sí se puede reducir el valor pgp_num. A efectos prácticos, esto coloca 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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > ceph osd pool set-quota pool max_bytes bytes
cephadm@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:

cephadm@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephadm@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:

cephadm@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:

cephadm@adm > ceph daemon osd.id ops

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

cephadm@adm > ceph daemon osd.id dump_historic_ops

Puede consultar la ubicación de un OSD con:

cephadm@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 9.6, “Borrado seguro”) 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:

cephadm@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 9.6, “Borrado seguro”) 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:

cephadm@adm > ceph pg deep-scrub pgid
Sugerencia
Sugerencia

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

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

6.3 Visualización de un clúster Edit source

Puede averiguar el estado inmediato de un clúster mediante ceph -s. Por ejemplo, un pequeño clúster de Ceph que conste de un monitor y dos OSD puede mostrar lo siguiente cuando se esté ejecutando una carga de trabajo:

cephadm@adm > ceph -s
cluster:
  id:     ea4cf6ce-80c6-3583-bb5e-95fa303c893f
  health: HEALTH_WARN
          too many PGs per OSD (408 > max 300)

services:
  mon: 3 daemons, quorum ses5min1,ses5min3,ses5min2
  mgr: ses5min1(active), standbys: ses5min3, ses5min2
  mds: cephfs-1/1/1 up  {0=ses5min3=up:active}
  osd: 4 osds: 4 up, 4 in
  rgw: 1 daemon active

data:
  pools:   8 pools, 544 pgs
  objects: 253 objects, 3821 bytes
  usage:   6252 MB used, 13823 MB / 20075 MB avail
  pgs:     544 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
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:

root # watch -n 10 'ceph -s'

Pulse ControlC cuando quiera detener la visualización.

6.4 Comprobación de las estadísticas de uso de un clúster Edit source

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.

cephadm@adm > ceph df
RAW STORAGE:
    CLASS     SIZE       AVAIL      USED        RAW USED     %RAW USED
    hdd       40 GiB     32 GiB     137 MiB      8.1 GiB         20.33
    TOTAL     40 GiB     32 GiB     137 MiB      8.1 GiB         20.33
POOLS:
    POOL             ID     STORED     OBJECTS    USED       %USED    MAX AVAIL
    iscsi-images      1     3.9 KiB          8    769 KiB        0       10 GiB
    cephfs_data       2     1.6 KiB          5    960 KiB        0       10 GiB
    cephfs_metadata   3      54 KiB         22    1.5 MiB        0       10 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 9.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 6.10, “Capacidad de almacenamiento” para obtener más información.

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

6.5 Comprobación del estado de los OSD Edit source

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

cephadm@adm > ceph osd stat

O bien

cephadm@adm > ceph osd dump

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

cephadm@adm > ceph osd tree

Ceph imprimirá un árbol CRUSH con un host, sus OSD, su estado de funcionamiento y su peso.

# id    weight  type name       up/down reweight
-1      3       pool default
-3      3               rack mainrack
-2      3                       host osd-host
0       1                               osd.0   up      1
1       1                               osd.1   up      1
2       1                               osd.2   up      1

6.6 Comprobación de OSD llenos Edit source

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 OSD llenos:

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

O bien

cephadm@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
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 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.

6.7 Comprobación del estado de los monitores Edit source

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:

cephadm@adm > ceph mon stat

O bien

cephadm@adm > ceph mon dump

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

cephadm@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"}
           ]
    }
}

6.8 Comprobación del estado de los grupos de colocación Edit source

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 6.11, “Supervisión de OSD y grupos de colocación”.

6.9 Uso del zócalo de administración Edit source

El zócalo de administración de Ceph permite consultar a un daemon a través de una interfaz de zócalo. Los zócalos de Ceph se encuentran por defecto en /var/run/ceph. Para acceder a un daemon a través del zócalo de administración, entrar a la sesión en el host en el que se ejecuta el daemon y utilice el siguiente comando:

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name

Para ver los comandos disponibles del zócalo de administrador, ejecute el siguiente comando:

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name help

El comando del zócalo de administración permite mostrar y definir la configuración en tiempo de ejecución. Consulte el Sección 16.1, “Configuración de tiempo de ejecución” para obtener más detalles.

Además, puede definir directamente los valores de configuración en tiempo de ejecución (el zócalo de administración omite el monitor, a diferencia del comando injectargs ceph tell tipo de daemon.id, que se basa en el monitor, pero no requiere entrar a la sesión directamente en el host en cuestión).

6.10 Capacidad de almacenamiento Edit source

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

Clúster de Ceph
Figura 6.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:

  1. El número de OSD.

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

6.11 Supervisión de OSD y grupos de colocación Edit source

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

6.11.1 Supervisión de OSD Edit source

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
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á).

  • Acaba de iniciar o reiniciar 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.

  • Acaba de añadir o eliminar un OSD.

  • Acaba de modificar 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:

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

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

Si un OSD con, por ejemplo, el ID 1 está inactivo, inícielo:

cephadm@osd > sudo systemctl start ceph-osd@1.service

Consulte la Sección 6.12, “Un OSD no se está ejecutando” para consultar los problemas asociados con los OSD que se han detenido o que no se reinician.

6.11.2 Conjuntos de grupos de colocación Edit source

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:

cephadm@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:

cephadm@adm > ceph pg mapPG_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
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.

6.11.3 Emparejamiento Edit source

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

Esquema de emparejamiento
Figura 6.2: Esquema de emparejamiento

6.11.4 Supervisión de los estados del grupo de colocación Edit source

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:

  • Acaba de crear un repositorio y los grupos de colocación aún no se han emparejado.

  • Los grupos de colocación se están recuperando.

  • Acaba de añadir o ha eliminado un OSD del clúster.

  • Acaba de modificar 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:

cephadm@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
Sugerencia: IDs de grupo 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:

cephadm@adm > ceph pg dump

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

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

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

cephadm@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.

Estado de los grupos de colocación
Figura 6.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
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.

6.11.5 Identificación de grupos de colocación con problemas Edit source

Como se ha indicado anteriormente, un grupo de colocación no sufre necesariamente problemas porque su estado no sea "activo+limpio". Por lo general, la capacidad de Ceph para autorrepararse puede no funcionar cuando los grupos de colocación se atascan. Los estados de atasco son:

  • Unclean (No limpio): los grupos de colocación contienen objetos que no se replican el número necesario de veces. Deberían estar recuperándose.

  • Inactive (Inactivo): los grupos de colocación no pueden procesar lecturas o escrituras porque están esperando a que se vuelva a crear un OSD con los datos más actualizados.

  • Stale (Obsoleto): los grupos de colocación están en un estado desconocido, porque los OSD donde se alojan no han notificado su estado al clúster de supervisión en un tiempo (este tiempo se configura con la opción mon osd report timeout).

Para identificar grupos de colocación atascados, ejecute lo siguiente:

cephadm@adm > ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]

6.11.6 Búsqueda de una ubicación de objeto Edit source

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:

cephadm@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]
Ejemplo 6.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:

cephadm@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:

cephadm@adm > rados -p data ls

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

cephadm@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:

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

6.12 Un OSD no se está ejecutando Edit source

En circunstancias normales, simplemente al reiniciar el daemon ceph-osd, podrá unirse de nuevo al clúster y recuperarse.

6.12.1 Un OSD no se inicia Edit source

Si inicia el clúster y un OSD no se inicia, compruebe lo siguiente:

  • El archivo de configuración: si no ha podido que los OSD se ejecuten desde una instalación nueva, compruebe el archivo de configuración para asegurarse de que cumple los requisitos (por ejemplo, se usa host y no nombre de host).

  • Compruebe las vía: compruebe las vías de la configuración y las vías reales de los datos y los diarios. Si separa los datos de OSD de los datos del diario y hay errores en el archivo de configuración o en los montajes reales, es posible que tenga problemas para iniciar los OSD. Si desea almacenar el diario en un dispositivo de bloques, debe particionar el disco del diario y asignar una partición por OSD.

  • Compruebe número máximo de hilos: si tiene un nodo con una gran cantidad de OSD, es posible que se haya alcanzado el número máximo por defecto de hilos (normalmente es de 32.000), especialmente durante la recuperación. Puede aumentar el número de hilos con el comando sysctl para comprobar si al aumentar el número máximo de hilos al máximo posible (por ejemplo, 4194303) ayuda:

    root # sysctl -w kernel.pid_max=4194303

    Si al aumentar el número máximo de hilos el problema se resuelve, puede hacer que este cambio sea permanente incluyendo un valor kernel.pid_max en el archivo /etc/sysctl.conf:

    kernel.pid_max = 4194303

6.12.2 Falla un OSD Edit source

Cuando el proceso ceph-osd termina, el monitor obtendrá información sobre el fallo de los daemons ceph-osd supervivientes e informará a través del comando ceph health:

cephadm@adm > ceph health
HEALTH_WARN 1/3 in osds are down

Específicamente, recibirá una advertencia cada vez que haya procesos ceph-osd que estén marcados como "in" y "down". Puede identificar qué daemons ceph-osd están inactivos con:

cephadm@adm > ceph health detail
HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080

Si hay un fallo del disco u otro error que impida que ceph-osd funcione o se reinicie, debe haber un mensaje de error en el archivo de registro en /var/log/ceph.

Si el daemon se ha detenido debido a un fallo de la subejecución de réplica, el sistema de archivos del kernel subyacente podría no responder. Compruebe el resultado del comando dmesg en busca de errores de disco u otros errores del kernel.

6.12.3 No hay espacio libre en disco Edit source

Ceph impide escribir en un OSD lleno para evitar que 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 la opción mon osd full ratio es de 0,95, o un 95% de la capacidad, antes de que se impida a los clientes que escriban datos. El valor por defecto de mon osd backfillfull ratio es de 0,90, o un 90% de la capacidad, para impedir el inicio de las reposiciones. El valor por defecto de la capacidad casi máxima del OSD es de 0,85, o el 85 % de la capacidad, cuando se genera una advertencia de estado. Puede cambiar el valor de "nearfull" con el siguiente comando:

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0

Por lo general, surgen problemas en el clúster completo al probar cómo Ceph gestiona un error de OSD en un clúster pequeño. Si un nodo tiene un porcentaje alto de los datos del clúster, es fácil que la proporción "casi completa" y la "completa" se sucedan casi de inmediato. Si está probando cómo reacciona Ceph a los errores de OSD en un clúster pequeño, debe dejar suficiente espacio libre en disco y estudiar la posibilidad de reducir temporalmente la capacidad máxima del OSD, la capacidad de reposición del OSD y la capacidad casi máxima del OSD utilizando estos comandos:

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0
cephadm@adm > ceph osd set-full-ratio 0.0 to 1.0
cephadm@adm > ceph osd set-backfillfull-ratio 0.0 to 1.0

El comando ceph health informa de los Ceph OSD completos:

cephadm@adm > ceph health
HEALTH_WARN 1 nearfull osd(s)

O bien

cephadm@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%

La mejor forma de ocuparse de un clúster lleno es añadir varios Ceph OSD para que el clúster pueda redistribuir los datos en el nuevo espacio de almacenamiento disponible.

Si no es posible iniciar un OSD porque está lleno, puede eliminar algunos datos suprimiendo directorios de grupo de colocación en el OSD lleno.

Importante
Importante: supresión de un directorio de grupo de colocación

Si decide suprimir un directorio de grupo de colocación en un OSD completo, no suprima el mismo directorio de grupo de colocación en otro OSD completo. o se podrían perder datos. Debe conservar al menos una copia de sus datos en al menos un OSD.

Imprimir esta página