Las versiones recientes de RHEL / CentOS (EL6) trajeron algunos cambios interesantes al sistema de archivos XFS del que he dependido mucho durante más de una década. Pasé parte del verano pasado persiguiendo una situación de archivo XFS escaso como resultado de un backport de kernel mal documentado. Otros han tenido problemas de rendimiento desafortunados o comportamiento inconsistente desde que se mudaron a EL6.
XFS era mi sistema de archivos predeterminado para datos y particiones de crecimiento, ya que ofrecía estabilidad, escalabilidad y un buen aumento del rendimiento sobre los sistemas de archivos ext3 predeterminados.
Hay un problema con XFS en los sistemas EL6 que apareció en noviembre de 2012. Noté que mis servidores mostraban cargas de sistema anormalmente altas, incluso cuando estaban inactivas. En un caso, un sistema descargado mostraría un promedio de carga constante de 3+. En otros, hubo un aumento de 1+ en la carga. El número de sistemas de archivos XFS montados parecía influir en la gravedad del aumento de carga.
El sistema tiene dos sistemas de archivos XFS activos. La carga es +2 después de la actualización del núcleo afectado.
Profundizando, encontré algunos hilos en la lista de correo XFS que apuntaban a una mayor frecuencia del xfsaildproceso en el estado STAT D. Las entradas correspondientes de CentOS Bug Tracker y Red Hat Bugzilla resumen los detalles del problema y concluyen que este no es un problema de rendimiento; solo un error en el informe de carga del sistema en núcleos más nuevos que 2.6.32-279.14.1.el6 .
WTF?!?
En una situación única, entiendo que el informe de carga puede no ser un gran problema. ¡Intente administrar eso con su NMS y cientos o miles de servidores! Esto se identificó en noviembre de 2012 en el kernel 2.6.32-279.14.1.el6 en EL6.3. Los núcleos 2.6.32-279.19.1.el6 y 2.6.32-279.22.1.el6 se lanzaron en los meses siguientes (diciembre de 2012 y febrero de 2013) sin cambios en este comportamiento. Incluso ha habido una nueva versión menor del sistema operativo desde que se identificó este problema. EL6.4 fue lanzado y ahora está en el kernel 2.6.32-358.2.1.el6 , que exhibe el mismo comportamiento.
He tenido una nueva cola de compilación del sistema y he tenido que solucionar el problema, ya sea bloqueando las versiones del kernel en la versión anterior a noviembre de 2012 para EL6.3 o simplemente no usando XFS, optando por ext4 o ZFS , con una severa penalización de rendimiento para la aplicación personalizada específica que se ejecuta encima. La aplicación en cuestión depende en gran medida de algunos de los atributos del sistema de archivos XFS para tener en cuenta las deficiencias en el diseño de la aplicación.
Al ir detrás del sitio de la base de conocimiento de Red Hat , aparece una entrada que dice:
Se observa un alto promedio de carga después de instalar el kernel 2.6.32-279.14.1.el6. El alto promedio de carga se debe a que xfsaild entra en estado D para cada dispositivo con formato XFS.
Actualmente no hay una resolución para este problema. Actualmente se está rastreando a través de Bugzilla # 883905. Solución alternativa Reduzca el paquete del kernel instalado a una versión inferior a 2.6.32-279.14.1.
(excepto la rebaja de kernels no es una opción en RHEL 6.4 ...)
Así que llevamos más de 4 meses en este problema sin una solución real planificada para las versiones del sistema operativo EL6.3 o EL6.4. Hay una solución propuesta para EL6.5 y un parche de fuente del núcleo disponible ... Pero mi pregunta es:
¿En qué punto tiene sentido apartarse de los núcleos y paquetes provistos por el sistema operativo cuando el responsable del mantenimiento ha roto una característica importante?
Red Hat introdujo este error. Ellos deben incorporar una solución en un núcleo de erratas. Una de las ventajas de usar sistemas operativos empresariales es que proporcionan un objetivo de plataforma consistente y predecible . Este error interrumpió los sistemas que ya estaban en producción durante un ciclo de parche y redujo la confianza en la implementación de nuevos sistemas. Si bien podría aplicar uno de los parches propuestos al código fuente , ¿qué tan escalable es eso? Se requeriría cierta vigilancia para mantenerse actualizado a medida que cambia el sistema operativo.
¿Cuál es el movimiento correcto aquí?
- Sabemos que esto podría solucionarse, pero no cuándo.
- Apoyar su propio núcleo en un ecosistema de Red Hat tiene su propio conjunto de advertencias.
- ¿Cuál es el impacto en la elegibilidad de soporte?
- ¿Debería superponer un núcleo EL6.3 que funciona sobre servidores EL6.4 de nueva construcción para obtener la funcionalidad XFS adecuada?
- ¿Debería esperar hasta que esto se arregle oficialmente?
- ¿Qué dice esto sobre la falta de control que tenemos sobre los ciclos empresariales de lanzamiento de Linux?
- ¿Confiar en un sistema de archivos XFS durante tanto tiempo fue un error de planificación / diseño?
Editar:
Este parche se incorporó a la versión más reciente del núcleo CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Estoy probando esto en mis sistemas CentOS, pero esto no ayuda mucho a los servidores basados en Red Hat.
Respuestas:
"En el punto en que el núcleo o los paquetes del proveedor se rompen tan horriblemente que impactan en su negocio" es mi respuesta general (por coincidencia, este también es el punto en el que digo que tiene sentido comenzar a buscar formas de apartarse de la relación con el proveedor) .
Básicamente, como usted y otros han dicho, RedHat parece no querer parchear esto en su núcleo distribuido (por cualquier razón). Eso te deja en la situación de tener que rodar tu propio kernel (mantenerlo actualizado en parches tú mismo, mantener tu propio paquete e instalarlo en tus sistemas con Puppet o similar, o ejecutar un servidor de paquetes que Yum o lo que sea use hoy puede hacer referencia), o tomar sus canicas y volver a casa.
Sí, sé que llevar sus canicas e irse a casa a menudo es una propuesta costosa: cambiar de proveedor de sistemas operativos es un gran problema, especialmente en el mundo de Linux, donde los sabores son radicalmente diferentes desde un punto de vista administrativo.
Otras opciones, como ir totalmente a CentOS, también son poco atractivas (porque pierdes el soporte y todavía obtienes esencialmente el código de RedHat creado por otra persona, por lo que aún tendrás este error).
Desafortunadamente, a menos que suficientes personas (es decir, "grandes compañías) tomen sus canicas y se vayan a casa, al vendedor no le importará tanto molestar a las personas enviando un código incorrecto y no reparándolo.
fuente
Esto fue corregido ( silenciosamente ) por Red Hat el 23 de abril de 2013 en RHEL kernel-2.6.32-358.6.1.el6 como parte de las actualizaciones de erratas 6.4 ...
fuente
Si necesita parchear su núcleo RHEL, puede hacerlo usted mismo y contar con el respaldo oficial de ese núcleo, solo necesitará que lo certifiquen.
Hay disposiciones en el acuerdo de soporte de RHEL para hacerlo: ISTR está restringido a 1 o 2 por trimestre o año, pero no puedo recordarlo con certeza.
fuente