"¿Podemos actualizar nuestros servidores EL5 de producción existentes a EL6?"

Una solicitud simple de dos clientes con entornos completamente diferentes provocó mi respuesta habitual de mejores prácticas de "sí, pero requerirá una reconstrucción coordinada de todos sus sistemas " ...

Ambos clientes sienten que una reconstrucción completa de sus sistemas es una opción inaceptable por razones de tiempo de inactividad y recursos ... Cuando se me preguntó por qué era necesario reinstalar completamente los sistemas, no tuve una buena respuesta más allá, "esa es la forma en que es ... "

No estoy tratando de obtener respuestas sobre la gestión de la configuración ("Hacer títeres todo " no siempre se aplica ) o cómo los clientes deberían haber planeado mejor. Este es un ejemplo del mundo real de entornos que han crecido y prosperado en una capacidad de producción, pero no ven una ruta limpia para pasar a la próxima versión de su sistema operativo.

Entorno A:
organización sin fines de lucro con 40 x Red Hat Enterprise Linux 5.4 y 5.5 web, servidores de bases de datos y servidores de correo, ejecutando una pila de aplicaciones web Java, equilibradores de carga de software y bases de datos Postgres. Todos los sistemas están virtualizados en dos clústeres VMWare vSphere en diferentes ubicaciones, cada uno con HA, DRS, etc.

Entorno B:
empresa de comercio financiero de alta frecuencia con 200 sistemas CentOS 5.x en múltiples instalaciones de ubicación conjunta que ejecutan operaciones de comercio de producción, apoyando el desarrollo interno y las funciones administrativas. Los servidores comerciales se ejecutan en hardware de servidor básico. Tienen numerosas sysctl.conf, rtctl, interrumpen la unión y ajustes del controlador en lugar de reducir la latencia de mensajería. Algunos tienen núcleos personalizados y / o en tiempo real. Las estaciones de trabajo para desarrolladores también están ejecutando una versión similar de CentOS.

En ambos casos, los entornos funcionan bien como están. El deseo de actualizar proviene de la necesidad de una nueva aplicación o característica disponible en EL6.

• Para la empresa sin fines de lucro, está vinculada a Apache, el kernel y algunas cosas que harán felices a los desarrolladores.
• En la empresa comercial, se trata de algunas mejoras en el kernel, la pila de redes y GLIBC, que harán felices a los desarrolladores.

Ambas son cosas que no se pueden empaquetar o actualizar fácilmente sin alterar drásticamente el sistema operativo .

Como ingeniero de sistemas, agradezco que Red Hat recomiende reconstrucciones completas al pasar de una versión principal a otra. Un inicio limpio te obliga a refactorizar y prestar atención a las configuraciones en el camino.

Siendo sensible a las necesidades comerciales de los clientes, me pregunto por qué esto debe ser una tarea tan onerosa . El sistema de empaquetado RPM es más que capaz de manejar actualizaciones en el lugar, pero son los pequeños detalles los que le /bootbrindan : requiere más espacio, nuevos sistemas de archivos predeterminados, RPM que posiblemente rompa los paquetes de actualización media, obsoletos y obsoletos ...

¿Cuál es la respuesta aquí? Otras distribuciones (basadas en .deb, Arch y Gentoo) parecen tener esta capacidad o un mejor camino. Digamos que encontramos el tiempo de inactividad para realizar esta tarea de la manera correcta :

• ¿Qué deben hacer estos clientes para evitar el mismo problema cuando EL7 se libera y se estabiliza?
• ¿O es este un caso en el que las personas necesitan resignarse a reconstrucciones completas cada pocos años?
• Esto parece haber empeorado a medida que Enterprise Linux ha evolucionado ... ¿O solo me lo estoy imaginando?
• ¿Esto ha disuadido a alguien de usar Red Hat y sistemas operativos derivados?

Supongo que existe el ángulo de gestión de la configuración, pero la mayoría de las instalaciones de Puppet que veo no se traducen bien en entornos con servidores de aplicaciones altamente personalizados (el entorno B podría tener un solo servidor cuya ifconfigsalida se vea así ). Sin embargo, me interesaría escuchar sugerencias sobre cómo se puede usar la administración de la configuración para ayudar a las organizaciones a superar el problema de la versión principal de RHEL.

(Nota del autor: esta respuesta se refiere a RHEL 6 y versiones anteriores. RHEL 7 ahora tiene una ruta de actualización totalmente compatible desde RHEL 6, cuyos detalles se encuentran al final).

Para comenzar, debo tener en cuenta que hay dos formas de hacer la actualización en el lugar:

1. Coloque el DVD de instalación (o use la imagen del DVD a través de iLO / iDRAC), inicie desde él y elija Actualizar, por ejemplo linux upgradeany.
2. Actualice el redhat-releaseRPM manualmente, ejecute yum distro-sync(esto se simplifica demasiado) y reinicie.

El método 1 simplemente no es compatible. El método 2 es para vaqueros reales. Además de las nuevas instalaciones recomendadas, he realizado ambos ...

¿Necesito apoyo?

El apoyo tiene dos significados complementarios en nuestro mundo. La primera es que un producto tiene una característica dada (por ejemplo, "Postfix admite SMTP"). El segundo es que el vendedor le hablará al respecto. La definición que se entiende no siempre es clara por el contexto.

Para realizar una tarea, obviamente necesita apoyo en el primer sentido. El lugar donde entra el soporte del proveedor es para ayudarlo a resolver problemas y brindarle comentarios sobre las características que deben existir o mejorar. Muchos sitios pagan una fortuna por el apoyo del proveedor cuando tienen la experiencia interna para resolver cualquier problema que pueda surgir, más rápido e incluso más barato que el proveedor. Si comprar soporte de proveedores es, en última instancia, una decisión comercial que tendrá que tomar (o asesorar a la gerencia).

¿Por qué no hacer una actualización en el lugar?

Esto es lo que dice Red Hat al respecto :

Red Hat no admite actualizaciones in situ entre las principales versiones de Red Hat Enterprise Linux. Una versión principal se denota mediante un cambio de versión de número entero. Por ejemplo, Red Hat Enterprise Linux 5 y Red Hat Enterprise Linux 6 son versiones principales de Red Hat Enterprise Linux.

Las actualizaciones locales en las versiones principales no conservan todas las configuraciones del sistema, servicios o configuraciones personalizadas. En consecuencia, Red Hat recomienda encarecidamente las nuevas instalaciones al actualizar de una versión principal a otra.

Advierten además:

Sin embargo, tenga en cuenta las siguientes limitaciones antes de elegir actualizar su sistema:

• Los archivos de configuración de paquetes individuales pueden o no funcionar después de realizar una actualización debido a cambios en varios formatos o diseños de archivos de configuración.
• Si tiene instalado uno de los productos en capas de Red Hat (como Cluster Suite), es posible que deba actualizarse manualmente después de que se haya completado la actualización de Red Hat Enterprise Linux.
• Las aplicaciones de terceros o ISV pueden no funcionar correctamente después de la actualización.

Por supuesto, luego describen cómo hacer una actualización in situ a través del método 1, en caso de que realmente quiera hacerlo. La característica existe y Red Hat dedica tiempo de desarrollo, por lo que se admite que la característica existe. Pero si algo sale mal, Red Hat le dirá que instale fresh; no proporcionarán soporte de proveedor para cosas que se rompen como resultado de la actualización.

Para el registro, nunca tuve un problema con una actualización en el lugar de un sistema RHEL / CentOS o Fedora que no pude resolver por mí mismo. Los problemas típicos provienen de paquetes renombrados, repositorios de terceros y la discrepancia ocasional de versiones entre las arquitecturas i386 y x86_64 de un paquete. El instalador es un poco mejor en el manejo de estos que yum, creo.

¿Cómo debo actualizar?

En general, advierto a las personas que deben planificar una ventana de mantenimiento cada 3-4 años para actualizar los sistemas RHEL de una versión principal a la siguiente. Si bien las actualizaciones generalmente se realizan sin problemas, lo inesperado siempre puede suceder.

Para ambos entornos, espero que funcione una actualización en el lugar, aunque recomiendo probarlo a fondo primero. P2V es una muestra representativa de los servidores y ejecuta la actualización en el lugar en los sistemas virtuales para ver con qué problemas te encontrarás. Luego puede planificar la actualización de producción real en función de un mejor conocimiento de lo que sucederá.

Para una implementación grande como la que tiene aquí, considere usar el enfoque de "uno a muchos" de Limoncelli. Actualice una máquina, vea qué problemas ocurren, resuélvalos, luego use las lecciones aprendidas al actualizar un pequeño lote de máquinas, repita las lecciones aprendidas, luego, cuando crea que tiene todos los problemas resueltos, actualice grandes lotes de ellos.

En un momento como este, también recomiendo que analicemos detenidamente el proceso de implementación de su aplicación. Si no está lo suficientemente automatizado como para poder iniciarlo con un solo comando y estar razonablemente seguro de que la aplicación se implementará correctamente, entonces quizás los desarrolladores deban trabajar en eso. Tener un proceso de implementación de este tipo facilitaría mucho hacer una nueva instalación de la versión más nueva de EL y luego implementarla en ella.

¿Ayudará el cambio de distribuciones?

Las distribuciones basadas en Debian tienen un método de actualización in situ compatible, y funciona principalmente, pero no es inmune a los problemas. Por ejemplo, se rompieron muchas cosas para las personas que actualizaban Ubuntu 10.04 LTS a 12.04 LTS a través del método compatible. No está claro que Debian o Canonical estén dedicando una cantidad suficiente de tiempo de desarrollo a "soportar" esta característica, es decir, asegurándose de que funcione. Y todavía tiene que comprar soporte de proveedores para esta distribución si desea que alguien lo tome de la mano. Así que dudo que gane mucho al cambiar a una distribución de este tipo.

Puede ganar cambiando a una distribución de lanzamiento continuo como Gentoo o Arch. Sin embargo, esto tampoco te hace inmune a los problemas; solo significa que tiene que lidiar con los problemas de actualización continuamente durante la vida útil del servidor (por ejemplo, cada vez que usted o los desarrolladores decidan actualizar algo en el sistema), en lugar de hacerlo todo a la vez en un momento de actualización de distribución bien planificado. Tampoco tiene un proveedor que brinde soporte.

¿Qué depara el futuro?

El Proyecto Fedora está trabajando en una herramienta para mejorar las actualizaciones en el lugar. Tenían una herramienta llamada preupgradeque fue abandonada y reemplazada por una nueva herramienta llamada fedup que comenzó con Fedora 18 . Esto se agregó a RHEL7 y ahora las actualizaciones en el lugar tienen soporte completo , al menos de RHEL 6 a RHEL 7 . Desde mi propia experiencia, puedo decir que aunque feduptodavía tiene algunos problemas , se perfila como una herramienta muy útil.

CentOS también está experimentando con un tipo de repositorio de lanzamiento continuo , pero solo se aplica entre versiones menores (por ejemplo, 6.3-6.4).

Mi opinión sobre tu último párrafo:

Supongo que existe el ángulo de gestión de la configuración, pero la mayoría de las instalaciones de Puppet que veo no se traducen bien en entornos con servidores de aplicaciones altamente personalizados (el entorno B podría tener un solo servidor cuya salida ifconfig se vea así). Sin embargo, me interesaría escuchar sugerencias sobre cómo se puede usar la administración de la configuración para ayudar a las organizaciones a superar el problema de la versión principal de RHEL.

Creo que el valor real de los sistemas de gestión de configuración, especialmente en el contexto del entorno B, es que proporcionan las herramientas para construir un servicio independientemente de los servidores que lo ejecutan. Si no se utilizó un CMS para crear los servicios existentes, entonces probablemente no ayudará mucho en la recreación de los servicios.

Sé que esto no resuelve su problema inmediato, pero para mí se deriva de que la organización piensa en términos de servidores en lugar de servicios. En el pensamiento centrado en el servicio, no es necesario mantener la personalidad de los servidores individuales mientras el servicio continúe funcionando. Si se usa un CMS de manera disciplinada para construir todo el servicio, entonces mover ese servicio a otro sistema debería ser relativamente sencillo, porque toda la personalidad de la máquina será construida por el CMS.

PD: No estoy exactamente seguro de qué es lo importante de la salida de ifconfig en este contexto: es producida por un archivo de configuración y algunos scripts (de lo contrario, no estaría allí en el arranque), y esos pueden ser gestionados por un CMS, si es necesario.