Registros de mantenimiento y operaciones de resolución de problemas de Ceph

1.1 Primero detenga el osd defectuoso y el osd bueno (porque el osd debe detenerse al ejecutar ceph-objectstore-tool) y luego realice la exportación e importación.

Ejemplo de comando: 84 es un buen OSD, 85 es un mal OSD.

ceph-objectstore-tool-op get-OSD map-epoch 145039-data-path/data 1/ceph-OSD/-journal-path/var/log/ceph/ceph-84/journal- escriba el archivo store-file OSD map 145039

ceph-objectstore-tool-op set-OSD map-epoch 145039-data-path/data 2/ceph-OSD/-journal-path/var/log/ ceph/ceph-85/archivo tipo diario mapa OSD del archivo almacenado 145039

PD: 145039 es el número de versión correspondiente, y la ruta de datos y la ruta del diario completan las rutas de sus respectivos OSD.

2. Encuentre la versión de época correcta.

Esto debe verse a través de los registros de OSD que informan errores. Al iniciarse, osd cargará una versión de época A en ejecución, con la versión de época faltante precediéndola. Luego busque la versión B de época y la versión C de ecoch ya ejecutadas en el volcado de eventos recientes. Importe todas las versiones entre max (B, C) y A (también puede importar una versión para comenzar a observar, lo cual es demasiado problemático). En mi registro, A = 145068, B = 145011, C = 145012, puse 145013 en 1438. Mi registro se parece a continuación.

1. Motivo:

Si las dos versiones de osdmap son demasiado diferentes (la diferencia puede ser de aproximadamente 50), la comunicación entre los dos osd se informará al nodo incorrecto. . Si ocasionalmente hay un nodo defectuoso, no es un gran problema porque una operación de osd está bloqueada, luego restaure la última versión de osdmap. Si el registro de osd sigue informando, significa que hay un problema con la sincronización de osd del mapa de osd, lo que provocará que el osd falle, el latido se agotará (posiblemente) e incluso el osd consumirá mucha memoria. provocando que el servidor cuelgue. El registro es el siguiente:

2. Verifique la versión del mapa OSD de osd.

Presione el comando para ver: ceph daemon osd.xx status? -Correspondiente al número osd de la marca xx

Ejemplo de resultado del comando:

{

" cluster_fsid":" df 181181-2154-4816- a2b 7-D6 EAE 79980 FB ",

" OSD_fsid ":" D5 edac 3-CEE 7-45e b-90df-e 381d 8684 DFB ",

"whoami ": 15,

"Status":"Activo",

"Oldest_Map":92570,

"Latest_Map":158146,

" num_pgs": 2105

}

Donde last_map representa el número de la última versión de osd.

3. Verifique el número de versión de osdmap del clúster.

Comando: ceph -s

Aquí: el número de versión más reciente es 178170.

4. Determine si hay algún problema con la versión osd.

Ejecute el comando ceph daemon osd.xx status varias veces a intervalos regulares para verificar el número de versión de osd. El estado correcto es el siguiente:

4.1 El número de versión consultado siempre es coherente con el número de versión del clúster.

4.2. Es menor que el número de versión del clúster, pero seguirá aumentando y eventualmente alcanzará el número de versión del clúster.

5. Solución para que el mapa OSD no se actualice cuando aparece el OSD.

Hasta ahora, no he encontrado la causa raíz de que osd no actualice osdmap. ¿He utilizado ceph daemon osd.xx? Dump_blocked_ops comprueba si hay operaciones bloqueadas y resuelve el bloqueo, pero aún no funciona. Incluso si no se devuelve ningún bloqueo, todavía no se actualiza. Posibles métodos para actualizar osd:

1. Saque el osd correspondiente del clúster (osd o superior) y observe el número de versión después de un tiempo (así es como respondí).

2. Reinicie osd

1, registro de problemas

2. Solución:

1.

2. Compruebe si el conjunto de claves del clúster es coherente con el conjunto de claves del osd local:

Utilice el comando:?

cef? ¿autenticación? La lista obtiene todos los conjuntos de claves OSD de mon,

cat/var/lib/ceph/osd/ceph-xx/key ring para obtener el conjunto de claves OSD local.

3. Elimine la verificación, reinicie todos los mons y osds y modifique los siguientes parámetros en ceph.conf como se muestra a continuación

Clúster autorizado requerido = Ninguno

Autorización requisito de servicio = Ninguno

Requisito de autorización del cliente = Ninguno

1, Registro de problemas

2 Solución

1, Verifique la hora del servidor. y la red del servidor (el mío no es el problema)

2. Generalmente, el tiempo de espera de los latidos se debe a otros problemas. Aquí primero puede aumentar el tiempo de espera de los latidos (ya aumenté el tiempo de espera de los latidos y no habrá tiempo de espera de los latidos después de resolver otros problemas) y modificar los parámetros del archivo de cooperación ceph.conf

mon _ OSD _ informe _ tiempo de espera = 1800

Tiempo de espera de suicidio del subproceso de operación de almacenamiento de archivos = 1800

Tiempo de espera del subproceso de operación de almacenamiento de archivos = 600

osd_heartbeat_grace = 600

osd _ op _ thread _Suicide_timeout=1800

osd_op_thread_timeout=36000

Esta configuración se puede colocar en [Global] primero y luego eliminar después de que se resuelva el problema, o usted Puede ajustar los parámetros usted mismo según la situación real.

1. Consulte el registro para ver la ubicación de la tarjeta osd.

Nivel de ajuste de registro: Modifique los parámetros ceph.conf del archivo de configuración y agregue debug_osd=10 (15/20). Cuanto mayor sea el valor, mayor será la cantidad impresa. Si el osd ya está iniciado y desea cambiar el nivel de registro, puede usar el comando:ceph tell OSD. xx inyecta args-debug-osd5.

2. Resuelva el problema según la información del registro.

Estoy atascado en load_pgs, porque todo el estado del clúster es incorrecto y hay muchas páginas, por lo que la carga es muy lenta. En este momento, debe considerar la presión del servidor. Puede iniciarlos uno por uno lentamente en lugar de iniciarlos todos a la vez.

1. Causa del problema

El estado incompleto significa que no se puede seleccionar el registro autorizado o que la acción seleccionada a través de Choose_acting no es suficiente para completar la recuperación de datos (por ejemplo, para codificación de borrado, el número de réplicas supervivientes es menor que k), lo que hace que el par no pueda completarse normalmente. En otras palabras, los metadatos de la página se pierden y el estado de la página no se puede restaurar.

2. Resuelva el problema

1. Utilice la herramienta ceph-objectstore-tool para marcar la página incompleta.

2. Pasos de la operación:

Requisito previo de la operación: establecer el indicador del clúster: noout nodown noup noin? PD: El propósito aquí es evitar que cambie la distribución de páginas. Debido a que el osd está abierto, solo configuré noout nodown.

Paso 1: pase el comando ceph pg dump_stuck | grep complete >; Inincomplete.txt para exportar todas las páginas en estado de finalización del clúster.

Paso 2: A través del primer paso, sé dónde están los dos osds de pg y los bloqueo.

Paso 3: Utilice el comando para marcar pg en los dos osds. El comando es el siguiente

ceph-objectstore-tool-data-path/data 4/ceph-OSD/. -journal-path/var/log/ceph/ceph-15/journal-type file store-pgid 9 . ea8-op mark-complete

ceph-objectstore-tool-data-path/data 8/. ceph-OSD /-journal-path/var/log/ceph/ceph-91/journal-type file store-pgid 9. ea8-op mark-complete

Paso 4: Inicie estos dos osds (inicie secuencia irrelevante).

Paso 5: Observe si hay alguno incompleto en el clúster.

Paso 6: Repetir la segunda operación y siguientes hasta que esté incompleta.

3. Instrucciones especiales

3.1. El proceso de finalización del marcado puede provocar un aumento de la degradación y de los clusters desalineados, lo cual es normal.

3.2. Motivo: porque me perdí el paso de importar y exportar páginas durante el proceso de marcado. No importé ni exporté aquí porque hay muchos PG. La importación y exportación detendrán los dos OSD durante demasiado tiempo. Creo que es mejor dejar que el clúster se recupere por sí solo.

3.3. Importar y exportar comandos de pg:

ceph-objectstore-tool-data-path/data 3/ceph-OSD/-journal-path/var/log/ceph/ ceph-2/archivo tipo diario store-pgid 4.15 D5-op export-file/data 10/55/pg 4.15 D5

ceph-objectstore-tool-data-path/data 8/ceph-OSD /-ruta-diario/var/log/ceph/ceph-5/archivo tipo diario store-pgid? 4.15d5 - op import - Archivo/Datos 10/55/pg4.15d5

Seleccione un osd como osd principal y otro como osd secundario e importe uno de ellos al otro pg. Es necesario detener OSD al importar y exportar. Lo anterior es para importar 4.15d5 de osd.2 a OSD.5.

1. Sería mejor si se pudiera reiniciar el osd correspondiente a la página y el problema, naturalmente, se resolvería.

2. Si el disco de datos correspondiente al osd está dañado o no se puede iniciar por otros motivos.

Paso 1: Eliminar este osd y comando

ceph osd aplastar reweigh osd.xx 0

ceph osd out osd.xx

ceph osd aplastar eliminar osd.xx

ceph osd rm osd.xx

ceph auth del osd.xx

? Paso 2: limpie el disco duro del osd actual o agregue un disco duro nuevo.

Paso 3: Iniciar un nuevo osd con el mismo número.

? Parte 4: repita las operaciones anteriores para eliminar todos los OSD problemáticos. Si todavía hay una caída, no importa, espere a que el clúster reanude el procesamiento (acabo de iniciar un nuevo osd y pg procesó el ingreso completo+abajo. Después de marcar Incompleto, la caída desapareció por sí sola).

1. Razón

¿PG aún no se encuentra en este estado? ceph-osd? ¿Actualización que indica que todos los nodos que almacenan este PG pueden serlo? ¿Baja? Sí. Es posible que todos los OSD con copias PG fallen. En este caso, esa parte del almacén de objetos no está disponible y el monitor no recibirá actualizaciones de estado para estos PG y estos PG se marcarán como obsoletos.

2. Solución

Primer método: una vez que el OSD está inactivo, puede ser normal y se puede iniciar directamente.

Segundo tipo:

1. Utilice el comando ceph pg dump | grep stale para encontrar la página obsoleta.

2. Utilice el comando ceph pg force _ create _ pg＄pg _ id y el estado de la página cambiará a creando.

3. Reinicie todos los osds del clúster.

3. ¿Instrucciones especiales

? Estoy en el segundo caso y sigo los pasos anteriores. Como resultado, todos los inicios de osd se atascaron. Supongo que la posible razón: en ese momento, el número de mi force_create_pg era 3000, lo cual era demasiado, por lo que el osd se atascaba mucho y el tiempo de inicio era muy largo, tal vez varias horas. Por lo tanto, debe tener cuidado en esta operación. Se recomiendan las siguientes sugerencias.

1. Esta página obsoleta finalmente ha sido solucionada.

2. No tengas demasiados force_create_pg a la vez. Cuando osd se reinicie, después de que un reinicio sea exitoso, reinícielo otra vez.

Esto es relativamente simple, simplemente ejecute el comando directamente: ceph pg reparación $pg_id reparación.

Significa que hay un problema con el osd en el clúster y es necesario resolver el problema del osd. Solo tengo tres problemas de osd. Omití estos tres osds y los dos estados desaparecieron rápidamente.

1. Problemas descubiertos: el proceso ceph -s o mon muere y se ve el registro.

2. Motivo

Se generó una gran cantidad de épocas, lo que provocó que los datos en store.db de mon se expandieran rápidamente. Esto ocurrió solo después de que ocurrió un problema en mi clúster. No tuve este fenómeno antes cuando el grupo era normal. No sé si el grupo volverá a la normalidad después de que se normalice.

3. Solución

Primer método: ¿comprimir datos, usar comando? ceph decir mon .ceph 163 compacto? Ceph163 es el nombre de mi mon.

Segundo: ¿usar ceph-mon? -¿I? ¿anfitrión? -La compresión comienza de forma compacta. Utilizo ceph163 como host y nombre de host aquí.

Nota: No importa cuál uses, debes prestar atención a una cosa: al comprimir, el disco duro primero se expandirá y luego se contraerá, así que deja suficiente espacio. La ventaja del segundo método es que puede modificar el parámetro mon_data =/data 10/ceph 153 en ceph.conf para hacerlo efectivo. Mis datos mon posteriores eran demasiado grandes, así que actualicé la ruta del disco de datos: simplemente guarde los datos mon correspondientes en otro directorio.

Tercer método: cuando el clúster es normal, intente modificar los parámetros de configuración de mon (no verificado, los parámetros se pueden reducir).

mon_min_osdmap_epochs=500

mon_max_pgmap_epochs=500

mon_max_mdsmap_epochs=500

4. Preste especial atención a:

? De forma predeterminada, cuando el almacenamiento donde se encuentra mon está libre en un 5%, el proceso mon se suicidará.

Simplemente configure el nodo osd correspondiente como fuera (el proceso osd aún existe), eliminará automáticamente los datos y eliminará los datos del disco de datos correspondiente. Cuando se eliminan datos, el osd generalmente se cierra y se elimina.

Comando: ceph osd out osd.xx

Cuando es necesario migrar el servidor y cerrar el clúster, ¿establece primero ceph osd set nodown? ceph osd configurar noup? ¿Noout del conjunto ceph osd? ¿ceph osd establece nobackfill? Ceph osd set norecover deja el clúster intacto y luego cierra cada osd, mon y rgw.

ceph osd establece sin equilibrio

-Desactiva la página del clúster del equilibrio esclavo. Se puede configurar para solucionar problemas cuando ocurre un problema.

ceph osd settings nobackfill

-El reabastecimiento de datos de reparación está estrictamente prohibido. Cuando ocurre un problema y no queremos reparar los datos por el momento, podemos usarlos sin relleno.

¿ceph osd configurado sin recuperación?

-La recuperación de datos de reparación está estrictamente prohibida. Cuando ocurre un problema y no queremos reparar los datos por el momento, podemos usarlos sin relleno.

ceph osd set nodown

: cuando hay un problema en el clúster, el osd subirá y bajará durante un período de tiempo, puede usar este comando para desactivar el osd abajo .

ceph osd set noup?

? -Cuando hay un problema con el clúster, el OSD subirá y bajará por un tiempo. Puede usar este comando para desactivar el OSD.

ceph osd set noout?

-¿Prohibir que el osd del clúster se desconecte automáticamente durante un tiempo prolongado y quede fuera de servicio?

¿CEPH OSD no establece una limpieza profunda?

-Cancelar el uso del desarmado correspondiente sin procesamiento adicional, como ceph osd unset noout.

¿ceph osd fuera osd.xx? Establezca el estado de un único osd en out.

Ceph osds en osd.xx establece el estado de un único osd en in.

¿ceph osd inactivo osd.xx? Establezca el estado de un solo osd en inactivo.

¿ceph le dice a osd.xx injectargs? -debug-osd20 modifica el nivel de registro de osd.xx en tiempo real sin reiniciar osd.

ceph decir? mon.xx inyectar args? -mon de depuración? 20? Modificar el nivel de registro del mon en tiempo real sin reiniciar el mon.

cef? ¿Decir? osd. *?Inyecciones? -OSD_RESUME_SLEEP? 1? Unidad dos, inicialmente configurada en 1, por temor a que el servidor esté bajo presión, puede quitarla y configurarla en 0 después de la observación.

cef? ¿Decir? osd. *?Inyecciones? - ¿osd_max_backfills? 1? Ajustar el número de subprocesos de recuperación según la situación real.

cef? ¿Decir? osd. *?Inyecciones? -osd_recovery_op_priority? 60?Ajustar la altura de la línea de reciclaje

ceph daemon osd.xx status? Verifique el estado de osd.xx, principalmente mirando el número de versión de osdmap.

Volcado de página de Ceph para ver toda la información de la página.

Ceph pgdump _sticked stall comprueba los datos cuyo estado de página es estancado.

Ceph pg dump_stuck inactive comprueba los datos cuyo estado de página es inactivo.

Ceph pgdump_stuck datos de vista poco claros, el estado de la página no está limpio.

Ceph -s Ver el clúster.

Árbol osd de Ceph ver árbol de estado de osd

Detalles de salud de Ceph ver detalles de salud del clúster

Consulta Ceph pg pg_id para ver información de página.

Ceph osd getmap -o osdmap.bin para ver el mapa de osdmap.

¿Descodificador ceph? ¿tipo? ¿OSDMap? ¿importar? osdmap_197? ¿descodificación? Dump_json exporta osdmap al formato json.