El mecanismo OSDMap es una parte muy importante de la arquitectura Ceph. La distribución y el monitoreo de PG en el OSD se realiza mediante el mecanismo OSDMap. El mecanismo OSDMap y el algoritmo CRUSH juntos forman la piedra angular de la arquitectura distribuida de Ceph.
El mecanismo OSDMap incluye principalmente los siguientes tres aspectos:
1. Monitor supervisa los datos de OSDMap, incluida la recopilación de agrupaciones, el número de copias, el número de PG, la recopilación de OSD y el estado de OSD.
2. La OSD informa su estado al Monitor, y supervisa e informa el estado de la OSD de igual.
3. El OSD supervisa los PG asignados a él, incluida la creación de nuevos PG, la migración de PG y la eliminación de PG.
En todo el mecanismo de OSDMap, OSD confía completamente en Monitor y cree que los datos de OSDMap que mantiene son absolutamente correctos. Todas las acciones tomadas por el OSD en el PG se basan en los datos de OSDMap, lo que significa que el Monitor dirige al OSD cómo distribuir el PG.
En los datos de OSDMap, el personal de operación y mantenimiento especifica la recopilación de la agrupación, el número de copias, el número de PG y la recopilación de OSD.Aunque el personal de operación y mantenimiento también puede cambiar el estado del OSD, la operación real del grupo Ceph A se distribuye de vez en cuando. Se puede ver que el personal de operación y mantenimiento tiene un porcentaje muy pequeño de tiempo involucrado en el clúster Ceph, por lo que la falla del OSD (estado OSD) es el objetivo principal del monitoreo del Monitor.
El monitoreo de fallas de OSD se realiza conjuntamente por Monitor y OSD. En el lado de Monitor, el subproceso de PaxosService llamado OSDMonitor se usa para monitorear los datos de informe enviados por el OSD en tiempo real (por supuesto, también monitorea las operaciones realizadas por el personal de operación y mantenimiento en los datos de OSDMap). En el lado de OSD, ejecute un subproceso de Tick, por un lado, informe periódicamente su estado al Monitor; por otro lado, el OSD realiza la monitorización de Heartbeat en el OSD de pares, y si se encuentra una falla de OSD de pares, envíe comentarios oportunos al Monitor. Los detalles específicos de monitoreo de fallas de OSD no se analizan en este artículo.
Los puntos primero y segundo del mecanismo OSDMap son relativamente fáciles de entender. El siguiente artículo analiza principalmente el tercer punto en detalle.
image.png
Como se muestra en la figura anterior, en el grupo Ceph de 3 OSD, el número de copias del Pool es 3, y el OSD primario de un PG es OSD 0. Cuando el Monitor detecta cualquier falla de OSD de los 3 OSD, envía los últimos datos de OSDMap Vaya a los 2 OSD restantes y notifíqueles que tomen las medidas correspondientes.
image.png
Como se muestra en la figura anterior, después de que OSD recibe MOSDMap, se ocupa principalmente de tres aspectos
ObjectStore :: Transaction :: write (coll_t :: meta ()) Actualice OSDMap al disco y guárdelo en el directorio / var / lib / ceph / OSD / ceph- <id> / current / meta / para hacer persistentes los datos de OSDMap A un rol similar al de log.
OSD :: consume_map () realiza el procesamiento de PG, incluida la eliminación de PG que no existen en Pool; actualiza PG epoch (OSDmap epoch) al disco (LevelDB); genera eventos AdvMap y ActMap, activando la máquina de estado PG state_machine para actualizar el estado.
OSD :: enable_map () decide si iniciar el grupo de subprocesos recovery_tp para la recuperación de PG según sea necesario.
En el lado de OSD, PG es responsable del procesamiento de E / S, por lo que el estado de PG afecta directamente a E / S, y pgstate_machine es el mecanismo de control del estado de PG, pero la transición de estado en el interior es muy complicada, y aquí no se realizará ningún análisis específico.
Lo siguiente comienza a analizar la creación, eliminación, migración de PG
El personal de operación y mantenimiento desencadena la creación de PG. Especifique el número de PG al crear un nuevo grupo o aumente el número de PG existentes. En este momento, OSDMonitor monitorea el cambio de OSDMap y envía el último MOSDMap a todos los OSD.
En un grupo de OSD correspondientes a PG, la función OSD :: handle_pg_create () crea directorios PG en el disco, escribe metadatos PG y actualiza Heartbeat Peers y otras operaciones.
La eliminación de PG también es activada por el personal de operación y mantenimiento. OSDMonitor envía MOSDMap a OSD. En un grupo de OSD correspondientes a PG, la función OSD :: handle_PG _remove () es responsable de eliminar el directorio donde se encuentra la PG del disco y eliminar la PG de PGMap. Eliminar metadatos PG y otras operaciones.
La migración de PG es más complicada e implica el procesamiento colaborativo de dos OSD y monitores. Por ejemplo, agregar OSD3 a un clúster con 3 OSD existentes hace que CRUSH redistribuya los PG. El resultado de un cambio de asignación de PG es [0, 1, 2] -> [3, 1, 2]. Por supuesto, la distribución de CRUSH es aleatoria. En diferentes PG, OSD3 puede convertirse en OSD Primario o en OSD Replicado. Aquí tomamos OSD3 como OSD Primario como ejemplo.
El OSD3 recién agregado reemplaza al OSD0 original para convertirse en el OSD primario. Dado que el PG no se crea en el OSD3 y no hay datos, no se puede realizar la E / S en el PG. Por lo tanto, el mecanismo PG Temp se introduce aquí, es decir, el OSD3 envía MOSDPG Temp al Monitor , Designe OSD primario como OSD1, debido a que los datos de PG se guardan en OSD1, las solicitudes enviadas por el Cliente a PG se reenvían a OSD1; al mismo tiempo, OSD1 envía los datos de PG a OSD3, hasta que se complete la copia de datos de PG, OSD1 será primario El rol de OSD se devuelve a OSD3 y la solicitud de E / S del cliente se envía directamente a OSD3, completando así la migración de PG. Todo el proceso se muestra en la figura a continuación.
image.png
Otro escenario de migración PG es que cuando OSD3 se usa como OSD replicado, la migración de datos PG de Primay OSD a OSD3 es más simple que el proceso de migración PG anterior, y no se describirá en detalle aquí.
Este artículo explica los principios básicos del mecanismo OSDMap desde la perspectiva de PG, y describe la relación entre Monitor, OSD y PG. En la operación y mantenimiento reales, a menudo estamos confundidos sobre el cambio de estado de PG causado por el cambio de estado y cantidad de OSD, y esperamos que este artículo pueda inspirarnos para resolver el problema de estado de PG.
Autor: Lucien_168
enlace: https: //www.jianshu.com/p/8ecd6028f5ff
Fuente: libros de Jane
tienen derechos de autor por el autor. Para reproducción comercial, por favor contacte al autor para autorización, y para reproducción no comercial, por favor indique la fuente.
