Linux existe desde hace algún tiempo. Inicialmente creado por Linus Torvalds en 1991, se ha convertido en un jugador importante en el panorama de los sistemas operativos (SO) de servidor, junto con Windows y las principales distribuciones de Unix. Si bien Unix no tiene nada inherentemente malo, se ha vuelto bastante "antiguo" y existe una tendencia creciente de migrar de Unix a Linux.
Entonces, ¿por qué migrar?
Si usted es un administrador de un centro de datos existente (ya sea en las instalaciones o en una instalación de ubicación conjunta), particularmente uno que ha existido durante mucho tiempo, es probable que tenga un sabor comercial de Unix en ejecución. Por lo general, requieren hardware propietario y, si bien puede funcionar sin problemas, existen desafíos para mantener dichos entornos heredados. El mayor de estos desafíos que la alta gerencia podría estar considerando son los costos de soporte tanto para el hardware como para el propio sistema operativo. Además, las expansiones pueden ser cada vez más difíciles de hacer, ya que el hardware heredado está desactualizado y las piezas pueden ser difíciles de encontrar y, cuando se encuentran, pueden ser costosas (¡oh, oferta y demanda, eres una amante tan dura!).
Algo que puede surgir durante esta transición es la posibilidad de que descubras una aplicación que no se puede migrar. Tal vez el proveedor cerró o no ha portado la aplicación a Linux. Tal vez lo hayan hecho, pero requeriría la participación directa del proveedor en un compromiso profesional que conlleva un costo demasiado alto. Si esto surge, es posible que deba ver si puede migrar la carga de trabajo a una nueva aplicación que sea compatible con Linux o considerar la posibilidad de mantener ese servidor heredado en particular.
Otro problema de permanecer en los sistemas Unix heredados es la incapacidad de virtualizar. Si bien hay algo de virtualización en algunos entornos de Unix, los hipervisores modernos brindan mucha más funcionalidad y flexibilidad, si puede pasar a un sistema operativo que sea compatible con el hipervisor elegido.
Vale, voy a migrar, ¿cómo empiezo?
El éxito de una migración de Unix a Linux comenzará con una investigación sólida. Hay varias cosas en las que centrarse. Hay dos formas de abordar esto, y he encontrado que un híbrido de ambas puede producir los mejores resultados. Los dos enfoques, tal como los he visto, son "de abajo hacia arriba" y "de arriba hacia abajo". Estas frases son comunes y bastante fáciles de aplicar aquí.
Para el enfoque de abajo hacia arriba, comienza en el nivel del sistema operativo. Comience comprobando el sistema operativo y la versión actuales. Identifique los paquetes, módulos o software adicional instalados del proveedor del sistema operativo. Luego, verifique el software de terceros, capturando el proveedor y la versión que está ejecutando. Lo último es cualquier software de cosecha propia que pueda tener, incluidos no solo los programas escritos en un lenguaje formal como C (o cualquiera de sus descendientes) o Java , pero también scripts escritos en cualquiera de los lenguajes de shell comunes (sh , ksh , csh ) o lenguajes interpretados como PERL , Python y similares.
Otro lugar para buscar es el cron planificador Cualquier cosa programada allí, ya sea proporcionada por un proveedor o de cosecha propia, es algo en lo que desea pasar más tiempo probando.
El enfoque de arriba hacia abajo puede ser más difícil, ya que implica comenzar con los usuarios finales y averiguar qué ejecutan en el sistema. Este enfoque puede ser una experiencia difícil, ya que los usuarios no siempre entienden cómo funciona algo, sino cómo lo usan. Por ejemplo, un usuario puede saber que usa un sitio web, pero no ser consciente de que "debajo del capó" es Apache o Tomcat , tenga o no CGI scripts y, de ser así, en qué idioma están. Sin embargo, se pueden obtener datos adicionales, como descubrir que un servidor que pensaba que era más o menos independiente está estrechamente relacionado con otro, y que deberá migrar ambos en al mismo tiempo.
Mi preferencia es hacer ambas cosas... Intentaré averiguar quién dirige a los usuarios comerciales de un sistema en particular y me reuniré con ellos para averiguar para qué lo usan. También intentaré hacer coincidir las funcionalidades que utilizan con los componentes identificables del sistema. Un ejemplo sería un servidor web. ¿Es un servidor estático o dinámico? Es posible que no lo vea al revisar los paquetes instalados en el servidor. Aún así, una entrevista con un usuario podría decirle que el sitio está basado en WordPress , lo que significa que debe encontrar la base de datos que la controla, ya sea que esté en el mismo servidor o quizás en otro que deba migrar al mismo tiempo.
Bien, ahora sé lo que se está ejecutando, ¿qué sigue?
Debe decidir a qué distribución de Linux se mudará. Muchas cosas influyen en esta decisión, que francamente debería ser una publicación de blog propia. Por ahora, lo que destacaré es que debe observar las funciones que están en juego en el servidor y averiguar qué distribuciones admiten esas mismas funciones. Si, por ejemplo, el servidor es un simple servidor web o FTP, cualquier Linux será suficiente. Si tiene algún software de terceros en ejecución, es posible que el proveedor solo admita ciertas distribuciones, por lo que es posible que desee comenzar con ese software y luego reducirlo a partir de ahí.
Una vez que haya seleccionado su distribución, cree un entorno de desarrollo, instale el sistema operativo base y los paquetes necesarios, el software de terceros y similares. Configure usuarios para realizar pruebas y copie sus programas y scripts, o asegúrese de que puedan hacerlo.
Todo funcionará, ¿verdad?
En un mundo perfecto, eso sería cierto. Sin embargo, todos sabemos que el mundo no es perfecto. Las funciones proporcionadas por el sistema operativo generalmente funcionan de manera inmediata de la manera que usted esperaría. Si está saltando en versiones para algo como Apache, puede haber diferencias en cómo configurarlo para que su sitio web funcione de la misma manera. La documentación generalmente lo ayuda a llegar allí. El software de terceros a veces puede tener más problemas. Si tiene que lidiar con eso, asegúrese de haber confirmado los niveles de versión del sistema operativo. Un proveedor con el que he tratado es compatible con RHEL 6, pero no con RHEL 7. A veces, es posible que solo hayan probado hasta cierto punto de lanzamiento y admitan hasta ese punto, pero no más allá, como RHEL 6.4 pero no RHEL 6.10. También puede haber problemas si instaló una versión de 64 bits del sistema operativo, pero el proveedor externo solo probó una instalación de 32 bits.
El software y los scripts de cosecha propia son otro asunto. Es casi seguro que tendrá problemas allí, dependiendo mucho de quién escribió el código y qué tan complejo es. Los lenguajes formales pueden transferirse más fácilmente, siempre que el sistema operativo Linux tenga las bibliotecas adecuadas para admitir la compilación.
Podría haber problemas si estuviera ejecutando una versión anterior de Unix, ya que las cosas pueden haber cambiado en el idioma. Ciertos valores predeterminados pueden haber cambiado y las opciones para funciones de llamadas, especialmente llamadas al sistema, podrían ser diferentes. La recomendación es hacer las primeras compilaciones de código con la mayor cantidad de depuración que pueda activar y luego, una vez que haya resuelto los problemas, vuelva a compilar con la depuración desactivada para ahorrar en la carga del servidor en el futuro.
Para los guiones, lo mismo es cierto, pero con una mayor posibilidad de cambios extraños. La experiencia personal ha demostrado que el shell estándar (también conocido como sh ) los scripts generalmente se ejecutan bajo Bourne Again Shell (también conocido como bash ). Aún así, puede haber trampas ocultas que en realidad no generarán un error, pero no producirán los resultados esperados. Un ejemplo clave es este fragmento de código que usé mucho en mis días de HPUX:
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
Bajo HPUX, esto funcionó bien. Bajo bash en RHEL, la variable $saved_value estaría en blanco, debido a cómo ese shell estaba haciendo el alcance en comparación con cómo lo hizo HPUX. Tuve que cambiar lo anterior a algo como esto:
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” Por lo tanto, es importante realizar ejecuciones en paralelo entre el sistema antiguo y el nuevo para verificar que la misma entrada en un script crea la misma salida en ambos sistemas.
Ok, probamos todas las cosas, ¿y ahora qué?
El paso real de realizar la transición del sistema antiguo al nuevo puede variar mucho en complejidad, dependiendo de su entorno. Para que el tema realmente se maneje bien, debe tener un blog propio. Una vez que haya realizado su migración, una autopsia es útil, especialmente si tiene migraciones adicionales que realizar. Una revisión sólida de lo que funcionó y lo que no funcionó tan bien puede generar "lecciones aprendidas" útiles para aplicar a su próximo proyecto de migración.
Terminando
Espero que este artículo haya ayudado a resaltar los tipos de cosas que debe buscar, las conversaciones que debe tener, los planes que debe establecer y le brinde una ventaja en su viaje hacia las migraciones de Unix a Linux. Con suerte, con las cosas que sacas de este artículo y un poco de suerte, tendrás una transición relativamente tranquila.
[ ¿Quiere probar Red Hat Enterprise Linux? Descárgalo ahora gratis. ]