Comparta un problema y una solución de falla en el punto de control de Flink

No te pierdas de pasar

Haga clic en la palabra azul para seguirnos

He estado en contacto con Flink durante un tiempo y he encontrado algunos problemas. Entre ellos, hay un problema de reiniciar el trabajo debido a una falla en el punto de control. Lo he encontrado muchas veces. Después del reinicio, generalmente puede volver a la normalidad. No me importó demasiado. Lo he encontrado con frecuencia en los últimos 2 días. Registre el proceso de solución y análisis.

Nuestro entorno de prueba de flink tiene 3 nodos, la arquitectura de implementación consiste en implementar un nodo HDFS DataNode en cada nodo de flink y hdfs se utiliza para flink checkpoint y savepoint

fenómeno

Mirando el registro, hay 3 nodos de datos activos, la copia del archivo es 1, pero la escritura del archivo falla

There are 3 datanode(s) running and no node(s) are excluded

Busqué en Internet este informe de error, pero no hay una respuesta directa. Miré el registro de namenode y no hay más información directa.

Todo es normal en la interfaz de usuario web 50070, todavía hay mucho espacio libre en el nodo de datos y la tasa de utilización es inferior al 10%

Intenté poner un archivo en hdfs y luego obtenerlo, todo bien, lo que indica que no hay ningún problema con el servicio hdfs y que el nodo de datos también funciona

Fenómeno de registro 1

Continúe hojeando el registro de namenode y observe algunos mensajes de advertencia. En

este momento, sospecho que hay un problema con la estrategia de colocación de bloques.

Siga el mensaje de registro para abrir el interruptor de depuración correspondiente para
modificar

etc/hadoop/log4j.properties

aparecer

log4j.logger.org.apache.hadoop.fs.s3a.S3AFileSystem=WARN

Copie este formato y agregue a continuación

log4j.logger.org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy=DEBUG
log4j.logger.org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor=DEBUG
log4j.logger.org.apache.hadoop.net.NetworkTopology=DEBUG

Reinicie el nodo de nombre y luego vuelva a ejecutar el trabajo de flink

Fenómeno de registro 2

El problema que vemos en este momento es que la estrategia de reconocimiento de racks no puede satisfacerse porque no proporcionamos un script de asignación de racks. El valor predeterminado es el mismo rack, pero no debería importar si lo piensa detenidamente.

Debido a que muchos HDFS en entornos de producción en realidad no configuran scripts de mapeo de racks y el problema de falla en el punto de control no siempre está presente, al menos los archivos put / get son normales.

En este momento, comencé a considerar mirar el código fuente de hdfs. De acuerdo con la pila de llamadas de registro anterior, primero vea BlockPlacementPolicyDefault y DatanodeDescriptor relacionado

Estos códigos fuente significan aproximadamente que al seleccionar un nodo de datos para un bloque, se deben realizar algunas verificaciones en el nodo de datos, como mirar el espacio restante y ver qué tan ocupado está

Cuando nuestro problema se repite, el registro de observación encontrará información clave relacionada con este

Este registro significa que el espacio de almacenamiento es 43G, y el bloque de asignación realmente necesita más de 100M, pero el tamaño programado excede los 43G, por lo que creemos que el nodo de datos normal, el nodo de nombre, cree que no tiene suficiente espacio.

la razón

¿Cuál es el significado de tamaño programado? Según el código, puede ver que el tamaño programado es el tamaño del bloque multiplicado por un contador. El contador en realidad representa un contador del número de bloques de archivos nuevos. HDFS estima el espacio de almacenamiento que puede ser necesario en función de estos dos parámetros, lo que equivale a reservar previamente una cierta cantidad para cada nodo de datos. Espacio, el espacio predeterminado se ajustará nuevamente después de que se calcule el espacio ocupado real después de escribir el archivo.

Después de comprender este principio, se puede juzgar que el nodo de datos se ha reservado demasiado espacio en un período de tiempo.

El mecanismo de punto de control de Flink puede referirse a este artículo https://www.jianshu.com/p/9c587bd491fc
aproximadamente significa que muchos subprocesos de tareas en taskmanager escribirán hdfs

Al observar la estructura de directorios de hdfs, hay una gran cantidad de archivos de puntos de control denominados uuid, y cada archivo es muy pequeño

Cuando nuestro trabajo sea más concurrente, se crearán más archivos de puntos de control en hdfs en consecuencia. Aunque nuestro tamaño de archivo es solo de unos pocos K, el espacio reservado en cada nodo de datos es 128M veces el número de archivos asignados (El archivo es muy pequeño, no más de 128M), entonces, ¿cuántos archivos se pueden reservar para 43G de espacio? Además, hay más de 300 y tres nodos son hasta 900. Tenemos varios trabajos y la concurrencia total es relativamente grande. Este problema es propenso a ocurrir antes de que el espacio reservado se libere por completo.

Sé que hdfs no es adecuado para almacenar archivos pequeños. La razón es que una gran cantidad de archivos pequeños provocará el consumo de inodo y el crecimiento de metadatos de ubicación de bloque, lo que hace que la memoria del nodo de nombre sea apretada. Este ejemplo también muestra que
cuando el tamaño del bloque es grande, el tamaño del archivo es mucho más pequeño que el tamaño del bloque. Estos archivos pequeños harán que el nodo de datos "no esté disponible" directamente.

Solución

El tamaño del bloque no es un atributo de clúster, sino un atributo de archivo, que puede establecer el cliente. En este momento, cada administrador de tareas y administrador de trabajos de flink es el "cliente" de hdfs. Según el documento de flink, podemos hacer la siguiente configuración
1. En conf / flink-conf Especifique una ruta de archivo de configuración hdfs en .yaml

fs.hdfs.hadoopconf: /home/xxxx/flink/conf

Aquí está el mismo directorio que la ruta del archivo de configuración de flink

2. Coloque 2 archivos de configuración, uno es core-site.xml y el otro es hdfs-site.xml

core-site.xml se puede dejar solo, si el punto de control y el punto de guardado especifican direcciones hdfs específicas,

Agregue la configuración blockSize a hdfs-site.xml, por ejemplo, aquí lo configuramos en 1M

Cómo configurar el tamaño de bloque específico, debe observar el estado de su propio trabajo y ajustar el tamaño del archivo de manera flexible.

Reinicie el clúster flink y envíe el trabajo. Puede observar el tamaño de la imagen f de hdfs cuando se ejecuta. Tenga cuidado de no hacer que los metadatos sean demasiado grandes debido a bloques demasiado pequeños y demasiados archivos pequeños.

resumen

Hemos sincronizado este problema con el script de implementación automatizada del clúster y agregaremos específicamente la configuración de tamaño de bloque durante la implementación.

La solución flink checkpoint que se basa en hdfs está ligeramente hinchada para escenarios de computación de transmisión livianos. El almacenamiento distribuido de checkpoint requiere hdfs, ya sea un sistema de archivos directo o rocksDB. De hecho, considerando el principio y el tipo de datos de checkpoint, es también debería ser una buena opción. Desafortunadamente, la comunidad no ofrece dicho programa.

Maravillosas recomendaciones anteriores

Obtenga más información sobre el conocimiento de la arquitectura back-end de Java y el último libro de entrevistas

Todo lo que pides es bonito, me lo tomo en serio.

Fuente del artículo: https://club.perfma.com/article/1733519