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

20 Solución de problemas

En este capítulo se describen varios de los problemas que pueden aparecer cuando se trabaja en un clúster de Ceph.

20.1 Notificación de problemas de software

Si encuentra un problema al ejecutar SUSE Enterprise Storage relacionado con alguno de sus componentes, como Ceph u Object Gateway, informe al servicio de asistencia técnica de SUSE. La forma recomendada de hacerlo es mediante la utilidad supportconfig.

Sugerencia
Sugerencia

Dado que supportconfig es un software modular, asegúrese de que el paquete supportutils-plugin-ses está instalado.

rpm -q supportutils-plugin-ses

Si no está en el servidor de Ceph, instálelo con:

zypper ref && zypper in supportutils-plugin-ses

Aunque puede utilizar supportconfig en la línea de comandos, se recomienda utilizar el módulo de YaST relacionado. Encontrará más información sobre supportconfig en https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig.

20.2 El envío de objetos de gran tamaño con rados falla con OSD lleno

rados es una utilidad de línea de comandos para gestionar el almacenamiento de objetos RADOS. Para obtener más información, consulte la página man 8 rados.

Si envía un objeto de gran tamaño a un clúster de Ceph con la utilidad rados, por ejemplo,

rados -p mypool put myobject /file/to/send

puede llenar todo el espacio dedicado al OSD y causar problemas graves en el rendimiento del clúster.

20.3 Sistema de archivos XFS dañado

En algunas raras circunstancias, como si se producen errores del kernel o si hay hardware dañado o mal configurado, el sistema de archivos subyacente (XFS) en el que el OSD almacena los datos puede estar dañado o ser imposible de montar.

Si está seguro de que no hay ningún problema con el hardware y de que el sistema está configurado correctamente, emita un informe de error para el subsistema XFS del kernel de SUSE Linux Enterprise Server y marque el OSD concreto como inactivo:

ceph osd down OSD identification
Aviso
Aviso: no formatee ni modifique de ninguna otra forma el dispositivo dañado

Aunque utilizar xfs_repair para corregir el problema del sistema de archivos pueda parecer una opción razonable, no la utilice, ya que el comando modifica el sistema de archivos. El OSD podría iniciarse, pero podría afectar a su correcto funcionamiento.

Borre la tabla de particiones del disco subyacente y vuelva a crear el OSD ejecutando:

ceph-disk prepare --zap $OSD_DISK_DEVICE $OSD_JOURNAL_DEVICE"

por ejemplo:

ceph-disk prepare --zap /dev/sdb /dev/sdd2

20.4 Mensaje de estado "Too Many PGs per OSD" (Hay demasiados grupos de colocación por OSD)

Si recibe el mensaje Too Many PGs per OSD (Hay demasiados grupos de colocación por OSD) después de ejecutar ceph status, significa que el valor mon_pg_warn_max_per_osd (300 por defecto) se ha superado. Este valor se compara con la proporción entre el número de grupos de colocación por OSD. Esto significa que la configuración del clúster no es óptima.

El número de grupos de colocación no se puede reducir después de crear el repositorio. Los repositorios que aún no contienen ningún dato se pueden suprimir con seguridad y volver a crearse con un número inferior de grupos de colocación. Si los repositorios ya contienen datos, la única solución es añadir nuevos OSD al clúster para que la proporción de grupos de colocación por OSD se reduzca.

20.5 Mensaje de estado "nn pg stuck inactive" (grupo de colocación nn atascado inactivo)

Si recibe un mensaje de estado de tipo stuck inactive (grupo de colocación atascado inactivo) después de ejecutar ceph status, significa que Ceph no sabe dónde replicar los datos almacenados para cumplir las reglas de réplica. Puede producirse poco después de la configuración inicial de Ceph y se corrige automáticamente. En otros casos, puede hacer falta intervención manual; por ejemplo, habrá que reparar un OSD dañado o añadir un OSD nuevo al clúster. En muy raras ocasiones, reducir el nivel de réplica podría ser de utilidad.

Si los grupos de colocación se atascan perpetuamente, debe comprobar el resultado de ceph osd tree. El resultado debe tener una estructura de árbol similar a la del ejemplo de la Sección 20.7, “El OSD está apagado”.

Si el resultado de ceph osd tree es plano, como en el ejemplo siguiente:

ceph osd tree
ID WEIGHT TYPE NAME    UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1      0 root default
 0      0 osd.0             up  1.00000          1.00000
 1      0 osd.1             up  1.00000          1.00000
 2      0 osd.2             up  1.00000          1.00000

debe comprobar que el mapa de CRUSH relacionado tenga una estructura de árbol. Si también es plano, o si no tiene ningún host como en el ejemplo anterior, puede significar que la resolución del nombre de host no funcione correctamente en el clúster.

Si la jerarquía no es correcta, por ejemplo, la raíz contiene hosts pero los OSD están en el nivel superior y no están asignados a hosts, debe mover los OSD a la ubicación correcta en la jerarquía. Esto puede realizarse mediante los comandos ceph osd crush move o ceph osd crush set. Para obtener más información, consulte la Sección 6.4, “Manipulación del mapa de CRUSH”.

20.6 El peso del OSD es 0

Cuando se inicia el OSD, se le asigna un peso. Cuanto mayor sea el peso, mayor será la posibilidad de que el clúster escriba datos en el OSD. El peso se especifica en un mapa de CRUSH o se calcula mediante el guión de inicio de los OSD.

En algunos casos, el valor calculado para el peso de los OSD puede redondearse a cero. Eso significa que el OSD no está programado para almacenar datos y, por lo tanto, no se escriben datos en él. Esto suele deberse a que el disco es demasiado pequeño (inferior a 15 GB) y debe sustituirse por uno mayor.

20.7 El OSD está apagado

El daemon OSD está en ejecución o detenido/apagado. Hay 3 razones por las qué un OSD puede estar apagado:

  • Un fallo del disco duro.

  • El OSD se ha detenido por fallo.

  • El servidor se ha detenido por fallo.

Puede ver el estado detallado del OSD ejecutando:

ceph osd tree
# id  weight  type name up/down reweight
 -1    0.02998  root default
 -2    0.009995   host doc-ceph1
 0     0.009995      osd.0 up  1
 -3    0.009995   host doc-ceph2
 1     0.009995      osd.1 up  1
 -4    0.009995   host doc-ceph3
 2     0.009995      osd.2 down  1

El ejemplo muestra que osd.2 está apagado. Puede comprobar si el disco donde está ubicado el OSD está montado:

lsblk -f
 [...]
 vdb
 ├─vdb1               /var/lib/ceph/osd/ceph-2
 └─vdb2

Para averiguar el motivo por el que el OSD está apagado, inspeccione su archivo de registro /var/log/ceph/ceph-osd.2.log. Cuando encuentre y solucione el motivo por el que el OSD no se está ejecutando, inícielo con:

sudo systemctl start ceph-osd@2.service

No olvide sustituir 2 por el número real del OSD que se ha detenido.

20.8 Búsqueda de OSD lentos

Al ajustar el rendimiento del clúster, es muy importante identificar los OSD o los sistemas de almacenamiento lentos. La razón es que si los datos se escriben en el disco más lento, la operación de escritura se ralentiza por completo, ya que siempre se espera hasta que la operación termina en todos los discos relacionados.

Localizar los cuellos de botella de almacenamiento no es sencillo. Tendrá que examinar cada OSD para averiguar cuáles son los que ralentizan el proceso de escritura. Para llevar a cabo una evaluación comparativa de un único OSD, ejecute:

ceph tell osd.OSD_ID_NUMBER bench

Por ejemplo:

root # ceph tell osd.0 bench
 { "bytes_written": 1073741824,
   "blocksize": 4194304,
   "bytes_per_sec": "19377779.000000"}

A continuación, debe ejecutar este comando en cada OSD y comparar el valor bytes_per_sec para comprobar cuáles son los OSD más lentos.

20.9 Solución de advertencias de diferencias del reloj

La información de hora de todos los nodos del clúster debe estar sincronizada. Si la hora de un nodo no está perfectamente sincronizada, se generarán advertencias de diferencias del reloj cuando se compruebe el estado del clúster.

La sincronización de hora se gestiona con NTP (consulte http://en.wikipedia.org/wiki/Network_Time_Protocol). Defina que cada nodo sincronice la hora con uno o varios servidores NTP; preferentemente en el mismo grupo de servidores NTP. Si aún se produce alguna diferencia de hora en un nodo, siga estos pasos para solucionarlo:

systemctl stop ntpd.service
systemctl stop ceph-mon.target
systemctl start ntpd.service
systemctl start ceph-mon.target

Después puede consultar a los pares de NTP y comprobar la diferencia horaria con sudo ntpq -p.

Los monitores de Ceph deben tener sus relojes sincronizados con una diferencia máxima de 0,05 segundos entre sí. Consulte la Sección 18.3, “Sincronización horaria de nodos” para obtener más información.

20.10 Rendimiento deficiente del clúster debido a problemas de la red

Existen diversas razones por las que el rendimiento del clúster puede ser deficiente. Una de ellas pueden ser los problemas de red. En tal caso, puede observar que el clúster alcanza un quórum, los nodos de OSD y de monitor se desconectan, las transferencias de datos tardan mucho tiempo o que se producen muchos intentos de volver a conectar.

Para comprobar si el rendimiento del clúster está afectado por problemas de red, revise los archivos de registro de Ceph del directorio /var/log/ceph.

Para solucionar problemas de red en el clúster, céntrese en los siguientes puntos:

  • Diagnóstico básico de red. Con el runner de herramientas de diagnóstico de DeepSea, net.ping, realice un ping entre los nodos del clúster para comprobar si la interfaz individual puede contactar con una interfaz específica y el tiempo de respuesta medio. También se indicará cualquier tiempo de respuesta específico mucho más lento que la media. Por ejemplo:

    root@master # salt-run net.ping
      Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

    Intente validar todas las interfaces con JumboFrame. Para ello, habilite:

    root@master # salt-run net.jumbo_ping
      Succeeded: 8 addresses from 7 minions average rtt 0.26 ms
  • Evaluación comparativa del rendimiento de la red. Con el runner de rendimiento de red de DeepSea, net.iperf, pruebe el ancho de banda de red del nodo interno. En un nodo de clúster determinado, un número de procesos iperf (según el número de núcleos de CPU) se inician como servidores. Los demás nodos del clúster se utilizan como clientes para generar el tráfico de red. Se indica el ancho de banda acumulado de todos los procesos iperf por nodo. Esto debe reflejar el rendimiento de red máximo que se puede conseguir en todos los nodos del clúster. Por ejemplo:

    root@master # salt-run net.iperf cluster=ceph output=full
    192.168.128.1:
        8644.0 Mbits/sec
    192.168.128.2:
        10360.0 Mbits/sec
    192.168.128.3:
        9336.0 Mbits/sec
    192.168.128.4:
        9588.56 Mbits/sec
    192.168.128.5:
        10187.0 Mbits/sec
    192.168.128.6:
        10465.0 Mbits/sec
  • Compruebe los valores del cortafuegos en los nodos del clúster. Asegúrese de que no bloquea los protocolos o puertos necesarios para el funcionamiento de Ceph. Consulte la Sección 18.9, “Configuración del cortafuegos para Ceph” para obtener más información sobre los valores del cortafuegos.

  • Compruebe que el hardware de red, como las tarjetas de red, los cables o los conmutadores, funciona correctamente.

Sugerencia
Sugerencia: red independiente

Para garantizar una comunicación de red rápida y segura entre los nodos del clúster, configure una red independiente que usarán exclusivamente los nodos de OSD y monitor del clúster.

20.11 El directorio /var se queda sin espacio

Por defecto, el master de Salt guarda el resultado de todas las tareas de los minions en su caché de tareas. Ese caché se utilizará más adelante para buscar resultados de las tareas anteriores. El directorio de caché es por defecto /var/cache/salt/master/jobs/.

Todos los resultados de tareas de todos los minions se guardan en un único archivo. Con el tiempo, ese directorio puede crecer desmesuradamente, según el número de tareas publicadas y el valor de la opción keep_jobs del archivo /etc/valor salt/master. keep_jobs define el número de horas (24 por defecto) que se debe conservar la información acerca de las tareas de minions pasadas.

keep_jobs: 24
Importante
Importante: no defina el valor keep_jobs: 0

Si define keep_jobs en "0", el limpiador de caché de tareas no se ejecutará nunca; lo que probablemente dé como resultado que la partición se llene.

Si desea inhabilitar el caché de tareas, defina en job_cache el valor "False":

job_cache: False
Sugerencia
Sugerencia: restauración de una partición llena por el caché de tareas

Cuando la partición con el caché de tareas se llena porque se ha definido incorrectamente el valor keep_jobs, siga estos pasos para liberar espacio de disco y mejorar la configuración del caché de tareas:

  1. Detenga el servicio de master de Salt:

    root@master # systemctl stop salt-master
  2. Cambie la configuración del master de Salt relacionada con el caché de tareas mediante /etc/salt/master:

    job_cache: False
    keep_jobs: 1
  3. Borre el caché de tareas del master de Salt:

    rm -rfv /var/cache/salt/master/jobs/*
  4. Inicie el servicio de master de Salt:

    root@master # systemctl start salt-master
Imprimir esta página