En junio me tocó una de las peores experiencias de mi vida.  Preparar un cluster de dos ordenadores con almacenamiento RAID compartido para que una aplicación Web se pudiese conectar a una base de datos ORACLE.  No estaba fuera de mis habilidades resolver el problema pero desgraciadamente hubo una serie de problemas cuya solución estaba bastante por encima de mis habilidades.  Después de 14 días de trabajo mis responsables en la empresa grande se apiadaron de mi y contrataron un experto en Linux.  Se salvó de esa forma mi cordura.

Nunca en mi vida he estado tan estresado como con este trabajo.  Nada funcionaba.  Nada.  Entre otras cosas el sistema operativo elegido era incompatible con el Hardware.  Esto fue una verdadera pesadilla.  El único punto positivo en estas semanas es que una amiga se apiadó de mi permitiéndome emborracharme hasta tal punto que no dormí esa noche.  Curiosamente el día siguiente fue uno de mis días más productivos.

El trabajo lo realizé para una empresa grande que no ve ningún problema en firmar un contrato de mantenimiento de ordenadores personales para su personal de cinco millones de euros anuales.  Todavía estoy impresionado con el poder de una corporación de ese tamaño.

Bienvenidos a como aprendí a montar el Red Hat Enterprise Linux Advanced Server 2.1 en un cluster de servidores bastante potentes con cabina de almacenimiento compartido y redundante.  Este es el informe del infierno que preparé para la empresa grande.

Proceso de instalación de cluster con RHEL para una empresa grande
Una instalación de un cluster que debía tardar dos días acabó durando casi tres semanas.  Tengo que admitir que por mi falta de conocimiento yo soy responsable por bastante de la tardanza.  Otra gran parte de la tardanza fue debida a las dificultades de obtener asistencia técnica y a las deficiencias del producto RedHat Enterprise Linux Advanced Server 2.1.

Acerca de porque yo fui elegido para hacer el trabajo de instalación no se me ha informado de la razón.  Lo único que se me ocurre es que fue debido a que hice un trabajo razonablemente bueno en el estreno de la multinacional con Linux, montando un servidor apache en un RedHat Linux 9.0 con acceso a una base de datos Oracle.

Problemas con instalación del hardware
Primero se hizo una instalación de RHEL AS 2.1 para probar las herramientas de instalación del sistema operativo proporcionadas por el fabricante.  En cuestión de una hora el sistema operativo estaba instalado, los discos duros formateados, y todo el hardware reconocido por el sistema operativo.  Como tengo poca experiencia con ordenadores de tres tarjetas de red, tardé varias horas en configurar la tarjeta de red.  Ese mismo día se decidió que convenía instalar el RHEL AS 3.0 para ver como funcionaba. Se pusieron a bajar los CDs de la versión 3.  Tuve el primer fallo en el proceso de registrar el software.  Por accidente o por no leer con suficiente detenimiento la pantalla de registro de la página de registro de software de RedHat se registró un ordenador dos veces en vez de los dos ordenadores una vez.  Esto se traducía en que había un ordenador del cluster con seis años de soporte y el segundo ordenador sin soporte.  Desde el comienzo las cosas iban mal con la instalación del cluster.

Una vez descargado el RHEL 3.0 se procedió a instalarlo.  Primer fallo, el CD de instalación de software del fabricante no instalaba correctamente el RHEL AS 3.0.  Por error mío con el software de instalación de Dell se borro la configuración de la cabina RAID.  Hubo otra instancia donde por no haber yo nunca visto una cabina RAID la apagué, desconfigurándola.

Se decidió hacer una instalación manual desde los CDs de RHEL AS 3.0.  Esta se realizó sin mayores problemas.  El principal problema era que el software de instalación insistía en utilizar el disco duro más grande que encontraba para todo: La cabina RAID.  Luego hubo los típicos problemas de configurar las tarjetas de red.  Esto era bastante más complicado que con el RHEL AS 2.1 ya que cada fichero de configuración de las tarjetas de red incluía el identificador único de la tarjeta de red.  Otra vez varias horas intentando conseguir una conectividad adecuada a la red de área local.  Una vez al final cuando se había instalado correctamente se procedió a intentar actualizar el software.  Quitando los típicos problemas que una máquina tenía seis años de soporte y la otra no tenía soporte, la actualización fue sin problemas.  Unas llamadas al servicio técnico de RedHat solucionaron el problema del soporte.

Al día siguiente se decidió instalar el RHEL AS 2.1 ya que la licencia que había contratado la multinacional con el fabricante no incluía las licencias necesarias para operar el cluster. 

Hacia el final del proceso de instalación un experto en linux de una empresa llamada Linalco, confirmó mis sospechas que todo el software de RedHat Enterprise Linux es GPL o software libre.  Si uno se descarga el código fuente y lo compila puede utilizarlo sin ninguna restricción.  Como el soporte técnico proporcionado por RedHat permitía descargarse la versión más actualizada de cualquier paquete, habíamos ya instalado el software de cluster.  Creo firmemente que las licencias ofrecidas por RedHat únicamente sirven para dos cosas: Proporcionar actualizaciones automáticas de software verificado en bastantes equipos y darle a las empresas la impresión que ya que cuesta una cantidad de dinero un poco menor que cualquier otro sistema operativo, se trata de un producto que inspira confianza.  Es un producto extremadamente estable, pero por las formas de licencia que tiene no se pueden cobrar licencias por el software, únicamente por soporte técnico.  En otras palabras es imposible piratear software de RedHat al ser todo su software libre.

Los mismos problemas de siempre configurando las tarjetas de red.  No tengo experiencia suficiente para saber que tarjeta de red está conectada donde a primera vista.  Bastantes horas con ese problema, aunque menos que las dos últimas veces.  Para mi gran alegría descubrí que la herramienta de configuración de las tarjetas de red proporcionada por RHEL AS 2.1 lo único que hacía era borrar la configuración existente.

Luego llegó la actualización del software. Con los datos que conocíamos del proxy fallaba la herramienta para registrar el sistema en los servidores de RedHat, para permitirnos posteriormente bajarnos paquetes automáticamente. La herramienta de registro no concluía satisfactoriamente la transacción.  Registraba la máquina en el RedHat Network, pero el registro no permitía actualizar los paquetes.  Haciendo varios intentos cada una de las maquinas acabó registrada varias veces.  Un fallo de RedHat Network.  No se toma ninguna medida para evitar registros duplicados.  Registros duplicados implican que con dos licencias es bastante fácil que ninguna maquina pueda registrarse, ni actualizarse automáticamente.

Llamamos a RedHat a ver si nos podían solucionar el problema.  RedHat nos dijo que como las licencias se las habíamos comprado al fabricante, no era problema suyo resolvernos nuestras dificultades.  Que nos pusiésemos en contacto con el fabricante.

La instalación del cluster por mi parte fue un desastre sin paliativos.  Hubo problemas con el sistema operativo incluido que el CD de instalación no era capaz de arrancar la máquina, el sistema de actualización por defecto era incompatible con el proxy, una actualización del cluster era incompatible con los discos SCSI principales de los miembros del cluster, sólo reconociendo el disco compartido.

Yo tampoco me libro de culpa.  Hubo problemas con la instalación del mysql en el cluster por elegir yo una localización no estándar para instalarlo.  Hubo problemas con el apache por la razón que el fichero de arranque que yo escribí era incorrecto.  Hubo problemas con el sistema de compartir ficheros con Windows porque no se me ocurrió mirar el fichero de configuración principal.

Memoria de interacciones con el servicio técnico
Antes de estrenar un sistema operativo es imprescindible asegurarse quien es responsable del servicio técnico y contratar un servicio técnico amplio.  En este caso me hizo falta mucha ayuda para conseguir la instalación del sistema operativo y no fue contratado un servicio técnico completo por lo que hizo falta recurrir a canales especiales.

El primer problema solucionado fue por parte de RedHat que gracias a no comprender yo el sistema de registro de las máquinas, registré ambas licencias en una máquina.  Borraron los datos incorrectos del registro.

El siguiente problema era que el sistema de actualización del sistema operativo no funcionaba con el proxy.  Gracias a la insistencia de mi responsable la multinacional fuimos capaces de iniciar una incidencia con Dell para resolver el problema.  El técnico responsable tardó dos días en resolver la incidencia mandándonos un rpm (paquete de instalación) actualizado para la herramienta de registro.  Pudimos registrar ambos servidores y actualizar el software.

Surgió otro problema.  La herramienta de cluster no hacía más que reiniciarse.  Resulta que había un fallo de configuración en el fichero responsable de arrancar el apache que yo escribí.  Para que funcione el cluster es imprescindible que el fichero de arranque informe del estado del servicio.  Se me había olvidado probar esto.  Intenté abrir una incidencia nueva con el técnico que me solucionó la última incidencia.  No fue posible.  Intenté abrir la incidencia con RedHat.  No pudo ser posible.  Intenté abrir la incidencia llamando al fabricantel.  No fue posible.  Cometí el error de mostrar malas formas lo que no ayudó.  Cuando conseguí que el técnico se ocupase de la incidencia me dijo que la versión de apache utilizada no estaba soportada.  Una simple inspección del fichero de arranque del apache hubiese mostrado el problema ahorrándonos un par de días.

El siguiente problema que surgió fue que uno de los servidores no quiso arrancar cuando puse a prueba el cluster.  Ya me había puesto en contacto con otro técnico ya que me mandó un correo por equivocación referente al Samba y yo tenía problemas también con el Samba. 

Uno de los programas que se ejecutan al iniciarse el equipo es incompatible con el hardware.  Ese programa había borrado el fichero que informa donde están montados todos los sistemas de ficheros.  Como el proceso de arranque funcionaba demasiado rápido para que lo arrancase manualmente no se pudo evitar que se ejecutase ese programa.  El CD de RHEL AS 2.1 no era capaz de reconocer el hardware.  El CD de recuperación que traje el día siguiente no era capaz de reconocer el hardware.  Al final el segundo técnico me dio la solución.  Arrancar con el CD de RHEL AS 3.0.  Esto suposo tres días.

El siguiente problema fue que el primer técnico, gracias a la información de sistema recibida nos informó que el núcleo (kernel) del sistema operativo era antiguado y tenía problemas de seguridad.  Le dije al sistema de actualización de software que actualizase el kernel en ambas maquinas.  Ninguna quiso arrancar.  En una de las máquinas se me ocurrió desinstalar el kernel anterior a ver si eso solucionaba el problema.  El resultado es que hizo falta reinstalar una de las maquinas.

Mis responsables en la multinacional metieron tanta presión que consiguieron que el fabricantel mandase un experto de Linux para reinstalar las máquinas.  Mi calvario había acabado.  Al final pasé de estar metido en una situación demasiada complicada para mis conocimientos de Linux a ser mero espectador de cómo un experto de Linux hacía su magia.  Era fabuloso ver al experto en Linux en acción.

Problemas con la compra de software

  • No sé compró la versión mas reciente del sistema operativo RHEL 3.0 con licencia de cluster.  Las versiones más modernas son compatibles con muchas más configuraciones de hardware.  No comprar la licencia de cluster para el RHEL.
  • No comprar el servicio técnico más completo que había.  Se tuvieron que recurrir a canales extraordinarios para conseguir el servicio técnico que hizo falta para poner en funcionamiento la versión de RHEL que instalamos.
  •  No comprar el RedHat Enterprise Linux Advanced Server directamente a RedHat.  Los fabricantes del sistema operativo tienen mucha más habilidad para resolver problemas con la instalación al ser ellos los expertos que lo han fabricado.

Problemas con el servicio técnico

  • No estaba claro quien era el responsable de proporcionar el servicio técnico.  Se tardó muchos días en averiguar que el fabricante era el responsable.  Hizo falta recurrir a canales extraordinarios para conseguir el soporte.
  • En el soporte técnico del fabricante hacía falta abrir una incidencia nueva para cualquier problema que surgiese y surgieron muchos problemas.
  • Como el servicio técnico se consiguió por canales extraordinarios no era posible abrir una incidencia nueva por teléfono.  Hacía falta contar con la bondad de los encargados de una incidencia para que nos abriesen otra.
  • Nos dieron información incorrecta en algunos casos.  La recomendación de actualizar el kernel se tradujo en que hizo falta reinstalar una máquina lo que es un proceso arduo, especialmente porque algunos programas estaban configurados para funcionar en localizaciones no estándar.  Tengo que admitir que mi falta de conocimientos participó en que fuese necesario reinstalar el miembro del cluster.
  • No solucionaron el problema del apache con el programa de arranque.  Una simple inspección visual hubiese mostrado que estaba mal configurado.
  • No fui capaz de conseguir que el soporte técnico me resolviese el problema con compartir ficheros con máquinas windows (samba)
  • No sabían si el hardware estaba certificado para cluster con el sistema operativo en cuestión.

Problemas con el sistema operativo elegido

  • Al elegirse un sistema operativo viejo los programas utilizados eran menos funcionales que los de una versión más actualizada.
  • El sistema de actualización del sistema operativo por defecto no era compatible con el proxy que había en producción.
  • El CD de arranque del RHEL AS 2.1 no era capaz de arrancar las maquina del cluster en modo de recuperación.
  • Una actualización del kernel no era compatible con el hardware que vendió el fabricante.
  • El código fuente del PHP que venía con la máquina no era compatible con la versión de Oracle elegida aunque esa versión de Oracle estaba diseñada para funcionar en esa máquina lo que hacía imprescindible compilar de fuente.
  • El sistema gráfico se configuraba incorrectamente por defecto.  No existía posibilidad de copiar y pegar con el ratón del servidor y la resolución por defecto era incorrecta.
  • Que yo sepa ninguna versión de Linux permite mantener sincronizados dos ordenadores miembros de un cluster sin considerables habilidades de programación.
  • Un programa llamado kudzu, que busca cambios en el hardware borró el fichero que identifica la relación entre directorios y particiones.

Problemas con el Instalador el sistema operativo

  • Mis conocimientos de Linux no eran suficientes para enfrentarme a algo tan intenso como instalar un sistema operativo anticuado en un cluster.
  • No compilé todo el software en el RAID compartido del cluster.  Hacía falta copiar el código fuente de un ordenador a otro cada vez que se reinstalaba.
  • No compilé el MySQL.  Hubiese sido mucho mas simple tener una versión a medida en el espacio de disco compartido. Además puse la base de datos en una localización no estándar lo que dificulta reinstalar un servidor en caso de crisis.
  • No mostré la inteligencia suficiente para saber que con buenas formas se llega más lejos.

Recomendaciones acerca de estrenar sistema operativo

Para utilizar un sistema operativo desconocido para algo tan complejo como un cluster es imprescindible, si se trata de un Linux, elegir la versión más moderna por las mejoras en el interfaz de usuarios y el reconocimiento de hardware y cualquier mejora en el software.

Opiniones personales

Linux tiene la ventaja de ser un sistema operativo gratis que es extremadamente potente.  En el caso del RHEL AS se paga por el derecho de actualizar automáticamente el sistema operativo, por tener garantías que los componentes del sistema operativo funcionan en la gran mayoría de los casos.  Como se descubrió en el RHEL AS 2.1 las garantías que el software funciona en todos los casos no es absoluta al haber incompatibilidades con el hardware.

Todo el software, incluido el software de cluster del RHEL AS 3.0  es libre.   Cómo siempre se paga por las actualizaciones automáticas y por el soporte técnico.  No hay ningún inconveniente en bajarse el software de cluster e instalarlo.  Repito, se paga por el soporte técnico y por las actualizaciones automáticas y las supuestas garantías de calidad. 

Acerca de futuras compras de RHEL AS que se realicen en todos los casos opino que se han de comprar al fabricante del sistema operativo, en este caso RedHat, no al fabricante del ordenador, por sus mayores conocimientos del sistema operativo.  No conviene ahorrar en el soporte técnico ya que puede ocasionar perdidas de tiempo y sufrimiento innecesario.

El Linux, por su flexibilidad y estabilidad es capaz de asumir cualquier tarea de servidor para el cual haya software diseñado para correr con ese sistema operativo.  Es posible que haga falta programar bastante para mantener los dos miembros del cluster sincronizados, pero el sistema operativo es lo suficientemente flexible para automatizar hasta la sincronización del software. 

Linux es perfectamente capaz de servir páginas Web y para ser un servidor de base de datos.  Para que la experiencia sea lo más indolora posible es recomendable instalar la versión estable más moderna dada sus superiores prestaciones.

Por último hace falta no escatimar a la hora de contratar a alguien para instalar algo tan complejo como un cluster.  Yo creía estar lo suficientemente capacitado y si no hubiese sido por los continuos problemas con una versión anticuada del sistema operativo hubiese podido resolverlo.  No tenía conocimientos suficientes para enfrentarme a crisis.  Para mi desgracia ahora estoy capacitado para enfrentarme exitosamente a muchos más problemas que puedan surgir que cuando empecé con la instalación del cluster.  La principal razón por la cual no se debe de escatimar a la hora de instalar software de este tipo es que los catorce días que estuve trabajando con la instalación del cluster lo recordaré mucho tiempo como estar entre los peores días de mi vida.  Si el instalador está lo suficientemente capacitado se le evitará mucho sufrimiento innecesario.

Andreso