Hoy tengo un misterio para ti. Ejecutamos un pequeño clúster Elasticsearch de tres nodos basado en CoreOS (2023.5.0 / Linux 4.19.25-coreos) en Azure. Elasticsearch se ejecuta dentro de un contenedor acoplable en modo de red host. Después de ejecutar casi sin mantenimiento durante más de un año, hemos visto cómo las máquinas entran en un estado muy interesante.
Actualizar
Este problema se resolvió mediante una solución a un controlador en el kernel de Linux . Ver la respuesta a continuación.
Síntomas
Básicamente, la red entre la máquina afectada y los otros dos nodos muere. Todos están en la misma red virtual y la misma subred y pueden comunicarse habitualmente con otros. Todavía se puede llegar al nodo afectado desde otras subredes (puedo ingresar en él) y desde una red virtual diferente. La máquina también tiene una conexión (muy irregular) a Internet, pero la mayoría de las solicitudes solo tienen tiempo de espera.
Hemos observado que en un nodo afectado, el número de "sockets utilizados" reportados /proc/net/sockstates muy alto (~ 4.5k en lugar de ~ 300 en un nodo sano). El monitoreo muestra que este número aumenta rápidamente desde el momento en que el nodo deja de estar disponible.
Lo divertido es que parece que no podemos identificar la fuente de estos enchufes usados:
# cat /proc/net/sockstat
sockets: used 4566
TCP: inuse 2 orphan 0 tw 2 alloc 98 mem 4
UDP: inuse 1 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
# cat /proc/net/sockstat6
TCP6: inuse 98
UDP6: inuse 1
UDPLITE6: inuse 0
RAW6: inuse 1
FRAG6: inuse 0 memory 0
Aparte de eso, la máquina parece estar bien. No hay procesos sospechosos en ejecución, el uso de la CPU es mínimo y hay mucha memoria disponible.
Hacer ping a una máquina virtual "inalcanzable" en la misma subred da como resultado algunas EAGAINrespuestas recvmsgy luego se cruza para ENOBUFSregresar sendmsg. strace salida de ping aquí
Recopilé algunos resultados adicionales (antes de que se hicieran modificaciones al sistema) y los publiqué en este resumen: https://gist.github.com/privatwolke/e7e2e7eb0272787765f5d3726f37107c
Análisis
Intentamos apagar todo lo que se nos ocurre en el servidor, siendo Elasticsearch el primer sospechoso. Pero cerrar el contenedor de búsqueda elástica no libera los enchufes usados. Lo mismo para todos los procesos relacionados con CoreOS (motor de actualización, cerrajero, ...) o incluso todo el tiempo de ejecución de Docker o cosas específicas de Azure. Nada parecía ayudar.
Pero ahora se vuelve aún más extraño: intentamos correr tcpdumpen la máquina para ver qué está pasando. Y he aquí: el problema se resolvió solo, se restableció la conectividad. Nuestra teoría era que tcpdump realiza algún tipo de syscall que lo resuelve. Ejecutamos tcpdump con gdb y establecimos puntos de interrupción en todas las llamadas al sistema. Después de pasar por un montón de puntos de interrupción, finalmente descubrimos que el acto de establecer el modo promisorio en el socket de captura (específicamente esta línea en libpcap ) es lo que restablece el contador de sockets usados y nos devuelve a un estado normal.
Hallazgos adicionales
- Hemos verificado que la ejecución
tcpdumpcon el-p/--no-promiscuous-modeindicador no borra los contadores de sockets usados y devuelve la máquina a un estado utilizable. - La ejecución
ifconfig eth0 txqueuelen 1001restablece el contador de sockets utilizados, pero la conectividad no se restaura. - Establecer el modo de promisc manualmente con
ip link set eth0 promisc ontampoco restaura la conectividad.net.ipv4.xfrm4_gc_threshestá configurado en 32768 y aumentarlo ligeramente no resuelve el problema.
Hemos estado en contacto con Azure, que estamos tan desconcertados como nosotros. Entiendo que probablemente este no sea el problema, sino solo un síntoma. Pero es lo único tangible que encontré hasta ahora. Mi esperanza es que al comprender el síntoma pueda acercarme a la causa raíz. Las interfaces de red en Azure se ejecutan con este controlador de red .
Tal vez CoreOS / Kernel es el culpable?
Desde el punto de vista de la línea de tiempo, los problemas comenzaron el 2019-03-11, que es el día en que CoreOS se actualizó automáticamente a la última versión. De acuerdo con las notas de la versión , esta actualización contenía una actualización del kernel de 4.15.23 a 4.19.25 . Todavía estoy revisando los registros de cambios para ver si algo podría ser un problema allí. Hasta ahora solo he descubierto que el controlador de red Hyperv ha recibido bastantes actualizaciones en los últimos meses , y no todas parecen ser parte de 4.19.25. El conjunto de parches que CoreOS aplicó a 4.19.25 no es tan impresionante , pero el parche que introduce un módulo falso nf_conntrack_ipv4 es nuevo.
Actualización: ¿ Posible parche de kernel entrante relacionado?
¡Ayuda!
Hasta ahora, las preguntas que tenemos son las siguientes:
¿Qué podría causar que esta métrica de "enchufes usados" se dispare? He leído las fuentes del kernel para esta métrica y parece ser solo un contador sin referencia a qué tipo de sockets son realmente o qué los creó.
¿Por qué el número es plano en aproximadamente 4.5k? ¿Qué límite estaría causando esto?
¿Cambió algo significativo entre el kernel 4.14.96 y 4.19.25?
¿Por qué la
setsockopt()llamada en libpcap restablece el estado?
Error relacionado de CoreOS: https://github.com/coreos/bugs/issues/2572