70 votos

¿Por qué es tan difícil para actualizar entre versiones de Red Hat y CentOS?

"Podemos aumentar nuestra producción existentes EL5 de servidores para EL6?"

Un simple sonido solicitud de dos clientes con completamente diferentes entornos pida mi habitual mejores prácticas de la respuesta de "sí, pero se requiere una actuación coordinada de reconstrucción de todos los sistemas"...

Tanto los clientes sienten que una regeneración completa de sus sistemas es una opción inaceptable para el tiempo de inactividad y de los recursos razones... Cuando se le preguntó por qué era necesario reinstalar completamente el sistema, no tengo una buena respuesta más allá", que es la manera..."

No estoy tratando de obtener respuestas acerca de la gestión de la configuración ("Puppetize todo lo que" no siempre se aplican) o cómo los clientes deben haber planeado mejor. Este es un ejemplo de la vida real de los entornos en los que han crecido y prosperado en la capacidad de producción, pero no veo un camino limpio para pasar a la siguiente versión de su sistema operativo.

Entorno:
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, la ejecución de una aplicación web de Java pila, equilibradores de carga de software y bases de datos Postgres. Todos los sistemas están virtualizados en dos VMWare vSphere clusters en diferentes lugares, cada uno con HA, DRS, etc.

Medio Ambiente B:
Alta frecuencia de operaciones financieras de la firma con 200 x CentOS 5.x sistemas en múltiples co-ubicación de las instalaciones de producción en ejecución las operaciones comerciales, el apoyo en el desarrollo interno y las funciones de back-office. El comercio de los servidores se están ejecutando en el bare-metal de los productos básicos de hardware de servidor. Tienen numerosos sysctl.conf, rtctl, el enlace de interrupción y el controlador de ajustes en el lugar a la menor latencia de mensajería. Algunos tienen la costumbre y/o en tiempo real de los núcleos. Las estaciones de trabajo de desarrollador también está ejecutando una versión similar(s) de CentOS.


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

  • Para los sin fines de lucro de la firma, está atado a Apache, el kernel y algunas de las cosas que se hacen los desarrolladores feliz.
  • En la firma comercial, se trata de algunas de las mejoras en el kernel, pila de red y GLIBC, lo que hará que los desarrolladores feliz.

Ambas son cosas que no pueden ser fácilmente empaquetado o actualizada sin alterar drásticamente el sistema operativo.

Como ingeniero de sistemas, soy consciente de que Red Hat recomienda completo reconstruye cuando se mueven entre los principales versiones. Un inicio limpio obliga a refactorizar y prestar atención a las configuraciones a lo largo del camino.

Ser sensibles a las necesidades de los clientes, me pregunto por qué esto tiene que ser una tarea costosa. El sistema de paquetes RPM es más que capaz de manejar en el lugar de las actualizaciones, pero es en los pequeños detalles que te: /boot que requieren más espacio, el nuevo valor por defecto de los sistemas de ficheros, RPM, posiblemente, rompiendo mediados de actualización, obsoleto y desaparecida paquetes...

¿Cuál es la respuesta aquí? Otras distribuciones (.deb basada en Arch y Gentoo) parecen tener esta habilidad o un camino mejor. Digamos que encontrar el tiempo de inactividad para realizar esta tarea el derecho forma:

  • ¿Qué debería de estos clientes hacer para evitar el mismo problema cuando EL7 se libera y se estabiliza?
  • O se trata de un caso donde la gente tiene que resignarse a la plena reconstruye cada pocos años?
  • Esto parece haber empeorado como Enterprise Linux ha evolucionado... O me estoy imaginando que?
  • Tiene este disuadido a nadie el uso de Red Hat y derivados de los sistemas operativos?

Supongo que habrá la gestión de la configuración de ángulo, pero la mayoría de los Puppet instalaciones veo que no se traducen bien en entornos altamente personalizados servidores de aplicación (Entorno de B podría tener un solo servidor cuyo ifconfig de salida se parece a esto). Me gustaría ser interesante en la audiencia de sugerencias sobre la forma de gestión de la configuración se puede utilizar para ayudar a las organizaciones a conseguir a través de la RHEL versión mayor relieve, sin embargo.

41voto

Michael Hampton Puntos 88271

(Nota del autor: Esta respuesta se refiere a red hat enterprise linux 6 y las versiones anteriores. RHEL 7 tiene ahora totalmente compatible ruta de actualización de red hat enterprise linux 6, los detalles de los que están en la final.)


Para empezar, debo señalar que hay dos maneras de hacer la actualización en contexto:

  1. Caída en el DVD de instalación (o el uso de la imagen de DVD a través de la oit/iDRAC), arrancar desde él y seleccione Actualizar, por ejemplo linux upgradeany.
  2. Actualización de la redhat-release RPM manualmente, ejecute yum distro-sync (esto es demasiado simplista un poco) y reiniciar el sistema.

El método 1 es simplemente incompatible. El método 2 es para Verdaderos Vaqueros. Además de los recomendados en las instalaciones nuevas, me han hecho ambos de estos...


Necesito apoyo?

El soporte tiene dos significados complementarios en nuestro mundo. La primera es que un producto tiene una característica determinada (por ejemplo, "Postfix soporta SMTP"). La segunda es que el vendedor se encargará de hablar con usted acerca de él. La definición que se quiere decir es que no siempre está claro en el contexto.

Para realizar una tarea, obviamente, se necesita apoyo en el primer sentido. Donde el apoyo de proveedores viene es para ayudar en la resolución de problemas y dando el proveedor de retroalimentación en cuanto a qué características deben existir o ser mejorado. Muchos sitios de pagar una fortuna por el apoyo de proveedores cuando tienen la pericia para resolver cualquier problema que pueda surgir, más rápido y más barato que el proveedor podría. Si para comprar el apoyo de proveedores es en última instancia una decisión de negocio, usted tendrá que hacer (o aconsejar a la gerencia).


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

Esto es lo que Red Hat dice al respecto:

Red Hat no admite la actualización entre cualquiera de las principales versiones de Red Hat Enterprise Linux. Una versión principal está representada por un número entero cambio de versión. Por ejemplo, Red Hat Enterprise Linux 5 y Red Hat Enterprise Linux 6 son los dos principales versiones de Red Hat Enterprise Linux.

En lugar de las actualizaciones a través de los grandes lanzamientos que no conservan todos los ajustes del sistema, de los servicios o configuraciones personalizadas. En consecuencia, Red Hat recomienda instalaciones nuevas al actualizar desde una versión mayor a otro.

Además, advierten:

Sin embargo, tenga en cuenta las siguientes limitaciones antes de elegir a la actualización de su sistema:

  • Paquete Individual de los archivos de configuración pueden o no pueden trabajar después de realizar una actualización debido a los cambios en diversos formatos del archivo de configuración o presentación.
  • Si usted tiene uno de Red Hat capas de productos (tales como el Cluster Suite) instalado, puede necesitar ser actualizado manualmente después de la de Red Hat Enterprise Linux actualización se ha completado.
  • De terceros o aplicaciones de ISV puede que no funcione correctamente después de la actualización.

Por supuesto, ellos, a continuación se describe cómo realizar una actualización en contexto mediante el método 1, sólo en caso de que usted realmente quiere hacer. La característica existe y Red Hat pone el tiempo de desarrollo en ella, por lo que se admite en los que la función existe. Pero si algo sale mal, Red Hat le dirá a instalar fresco; no darán soporte a los proveedores de las cosas que se rompen, como resultado de la actualización.

Para el registro, en realidad nunca he tenido un problema con una actualización en contexto de un RHEL/CentOS o Fedora sistema que no podía resolver a mí mismo. Los problemas típicos que vienen de paquetes renombrados, repositorios de terceros y ocasional de la versión de coincidencia 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?

Yo generalmente advertir a la gente que se debe planificar una ventana de mantenimiento cada 3 a 4 años para la actualización de red hat enterprise linux a los sistemas de uno de los principales de la versión a la siguiente. Mientras que las actualizaciones suelen ir sin problemas, lo inesperado siempre puede suceder.

Para ambos entornos, espero una actualización en contexto de trabajo, aunque recomiendo encarecidamente que probarlo a fondo primero. P2V una muestra representativa de los servidores y ejecutar a través de la actualización en contexto en los sistemas virtuales para ver qué problemas se van a ejecutar en. Usted puede, a continuación, el plan de la producción real de actualización basados en un mejor conocimiento de lo que va a suceder.

Para un gran despliegue como el que tenemos aquí, considere el uso de Limoncelli del "uno-algunos-muchos". Actualización de una máquina, a ver qué se producen los problemas, resolverlos, a continuación, utilizar las lecciones aprendidas cuando se actualiza un pequeño lote de máquinas, repetir las lecciones aprendidas cosa, entonces cuando usted cree que usted tiene todos los defectos trabajó en la actualización de lotes grandes de ellos.

En un momento como este, yo también se recomienda tomar una larga y dura mirada en su proceso de implementación de aplicaciones. Si no es lo suficientemente automatizado que se puede poner con un solo comando y estar razonablemente seguro de que la aplicación se implementa correctamente, entonces tal vez los desarrolladores necesitan para empezar a trabajar en eso. Tener un proceso de implementación sería mucho más fácil hacer una nueva instalación de la versión más reciente de EL y, a continuación, implementar sobre ella.


Se conmutación de las distribuciones de ayuda?

Distribuciones basadas en Debian, tiene un apoyo en lugar de un método de actualización, y sobre todo funciona, pero no es inmune a los problemas. Muchas cosas se rompió por la gente de la actualización de Ubuntu 10.04 LTS a 12.04 LTS a través del método compatible, por ejemplo. No está claro que Debian o Canónicos están poniendo una cantidad suficiente de tiempo de desarrollo en "apoyo" de esta característica, es decir, asegurarse de que funciona. Y todavía usted realmente tiene que comprar el apoyo de proveedores para esta distribución, si quieres que alguien te tome su mano. Así que dudo que se beneficiarán mucho de cambiar de dicha distribución.

Usted puede obtener por el cambio a un rolling-release distribución, tales como Gentoo o Arch. Sin embargo, esto no te hace inmune a los problemas; sólo significa que usted tiene que tratar con la actualización de los problemas de forma continua durante la vida del servidor (por ejemplo, cada vez que tú o el que los desarrolladores decidan actualizar algo en el sistema), en lugar de todas a la vez en una bien planeada actualización de la distribución del tiempo. Usted también no tiene ningún proveedor para proporcionar apoyo.


¿Qué depara el futuro?

El Proyecto Fedora está trabajando en una herramienta para mejorar en lugar de las actualizaciones. Tuvieron una herramienta llamada preupgrade que fue abandonado y reemplazado con una nueva herramienta llamada fedup a partir de Fedora 18. Este fue añadido a RHEL7 y ahora en lugar de las actualizaciones tienen soporte completo, al menos a partir de red hat enterprise linux RHEL 6 a 7. Desde mi propia experiencia puedo decir que mientras fedup todavía tiene algunos problemillas, que se perfila a ser una herramienta muy útil.

CentOS también está experimentando con un rolling-release tipo de repositorio, pero sólo se aplica entre versiones menores (por ejemplo 6.3-6.4).

5voto

Paul Gear Puntos 1554

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

Supongo que habrá la gestión de la configuración de ángulo, pero la mayoría de los Puppet instalaciones veo que no se traducen bien en entornos altamente personalizados servidores de aplicación (Entorno de B podría tener un solo servidor, cuya salida de ifconfig este aspecto). Me gustaría ser interesante en la audiencia de sugerencias sobre la forma de gestión de la configuración se puede utilizar para ayudar a las organizaciones a conseguir a través de la RHEL versión mayor relieve, sin embargo.

Creo que el verdadero valor de la configuración de los sistemas de gestión, especialmente en el contexto del Entorno de B, es que proporcionan las herramientas para la construcción de un servicio, independientemente de los servidores que ejecutan. Si un CMS no fue utilizado para crear los servicios existentes, entonces probablemente no va a ayudar mucho en la recreación de los servicios.

Sé que esto no resuelve su problema inmediato, pero a mí me surge a partir de la organización de pensar en términos de servidores en lugar de servicios. En servicio enfocado en el pensamiento, la personalidad de cada uno de los servidores no necesitan ser mantenidos siempre que el servicio sigue funcionando. Si un CMS es usado en una manera disciplinada para construir la totalidad de servicio, luego de pasar ese servicio a otro sistema debería ser relativamente fácil, porque todos los de la máquina de la personalidad será construido por la CMS.

P. S. no estoy exactamente seguro de lo que es significativo acerca de la salida de ifconfig en este contexto - es producido por un archivo de configuración y scripts (de lo contrario no estaría allí en el arranque), y aquellos que pueden ser manejadas por un CMS, si es necesario.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: