Introducción al entorno Mainframe HOST (z/OS y COBOL/CISC/DB2) y la actualidad de los Data Centers

Habitualmente, en las grandes empresas propias de sectores como Banca, Seguros, Telecos, Administración Pública, etc., encontramos entornos HOST de IBM (los conocidos Mainframe), grandes servidores con tecnologías propietarias de IBM sobre los que corren sus aplicaciones de negocio o aplicaciones de misión crítica (habitualmente basadas en COBOL/CISC/DB2 y/o Natural ADABAS), es decir, sus principales aplicaciones transaccionales (OLTP). Esto es algo evidente, ya que se trata de empresas que se informatizaron hace muchos años (varias décadas), y en aquel momento de la historia la única alternativa real era IBM, tanto por el Hardware como por el Software.

Hoy en día, todo esto ha cambiado notablemente. Microsoft junto con sus alianzas con diversos fabricantes de Hardware (HP, Intel, AMD, DELL, BULL, etc.) y Software se presenta como la principal alternativa a las antiguas tecnologías propietarias de IBM, tanto por rendimiento como por coste (algo que los consultores y partners de entornos HOST se niegan a admitir, o bien, les cuesta mucho admitirlo), y lo mismo ocurre con los entornos UNIX, como es el caso de HP/UX (el UNIX de HP) sobre grandes servidores de HP como la gama HP SuperDome con procesadores Itanium de 64-bit (donde también corren ediones Windows de 64-bit, como Windows Server 2003 o Windows Server 2008). Además, partiendo de la premisa de que el principal factor limitante del rendimiento es el acceso a disco, y dado que en la actualidad el subsistema de disco (en la práctica, Redes de Almacenamiento SAN con discos rápidos) es el mismo tanto para entornos Host como para entornos distribuidos (UNIX/Windows), cuesta mucho demostrar de forma empírica que los grandes servidores de IBM (como a ellos les gusta que les llamen) ofrecen mejor rendimiento que las alternativas UNIX/Windows de 64-bit. Ni que hablar, de los costes del Hardware y Software de IBM y Software AG (el fabricante del lenguaje Natural y la base de datos ADABAS) en entornos HOST. Dícese, que se caga la perra ;-)

Por desgracia, el coste y el riesgo (o quizás el temor) de realizar una migración tecnológica de dicha envergadura de los entornos operacionales (los entornos HOST/Mainframe de IBM) de los principales Bancos, empresas aseguradoras, administraciones, etc., son el principal motivo por el que finalmente se mantienen este tipo de sistemas (dios mío !! si aún mantienen aplicaciones funcionando sobre ficheros VSAM - Virtual Storage Access Method!! sacrilegioooo). En consecuencia, actualmente (y por mucho tiempo) sobreviven los entornos HOST de IBM, con su Sistema Operativo z/OS (evolución de MVS, os/390, etc.), sus conexiones de terminal 3270 (actualmente basados en TCP/IP, que modernos !!), su subsistema de trabajos basado en el leguaje JCL (Job Control Language), su entorno de paneles conocido como TSO (Time Sharing Option), su lenguaje de Script denominado REXX (REstructured eXtended eXecutor), su subsistema UNIX (basado en AIX, el UNIX de IBM) conocido como OpenMVS ó USS (Unix System Services), su sistema de seguridad propietario conocido como RACF (Resource Access Control Facility - tiembla Kerberos, tiembla Active Directory... jeje ;-), su tecnología de Cluster conocida como Sysplex Paralelo (lo más bueno, es que en más de un sitio te montan un cluster o Sysplex Paralelo sobre dos particiones de LA MISMA MAQUINA... manda webs, eso sí que es Alta Disponibilidad !! ), etc.

Sin embargo, del mismo modo que la actual supervivencia de los entornos HOST (s/390 y z/OS) en grandes compañías es una realidad, de forma paralela se está produciendo la necesidad de instalar sistemas operativos Linux sobre estas máquinas con procesadores IBM zSeries (es decir, zLinux), ya que la estabilidad y rendimiento que ha conseguido IBM con sus aplicaciones COBOL/CISC/DB2, no ha sido capaz de conseguirla (ni de cerca) en otros entornos como aplicaciones Web sobre z/OS, Data Warehousing y OLAP sobre z/OS, etc. Veáse el caso de WAS (Websphere Application Server) for z/OS (y hablo con conocimiento de causa, ya que he trabajado con él, además de tener colegas que lo han administrado, migrado, optimizado, etc), o también véase el caso de DB2 OLAP for z/OS (y también hablo con conocimiento de causa, pudiendo afirmar, que se trata de una mala migración de Hyperion Essbase sobre AIX para que se ejecute sobre OpenMVS ó USS - Unix System Services, muy malamente). Y no es por joder, pero finalmente IBM dejó de dar continuidad a DB2 OLAP for z/OS (también tengo que admitir, que un tiempo después me entero que ORACLE compra Hyperion Essbase... estos de Essbase, es que van de cama en cama ;-).

Llegados a este punto, vale la pena recordar que estas máquinas (los servidores zSeries de IBM) se pueden particionar por hardware, pudiendo definir diferentes particiones lógicas (LPAR ó Logical Partition) a las que asignar capacidades de Procesamiento (es decir, CPU), Memoria, Disco, etc., pudiendo instalar sobre cada partición (LPAR) un sistema operativo diferente y totalmente independiente. Es como tener un Virtual Server o un Hyper-V por Hardware (por supuesto, los grandes servidores Windows como la gama HP Superdome también permite particionamiento, los zSeries no son los únicos !!). Así, el particionamiento en los entornos HOST (zSeries) ofrece como ventaja:

• Utilizar una o variar particiones (LPARs) para la explotación de las antiguas aplicaciones de misión crítica basadas en COBOS/CISC/DB2 y/o Natural/ADABAS sobre Sistema Operativo IBM z/OS en procesadores zSeries (z/Architecture). Habitualmente, se utilizan varias particiones (LPARs) conforme al ciclo de vida del software (Desarrollo, Pruebas Integradas, Pre-Producción, Calidad, Producción, etc.).
• Utilizar una o variar particiones (LPARs) sobre las que instalar Sistemas Operativos zLinux para la explotación de nuevas tecnologías, como aplicaciones Web que se ejecuten sobre WAS (IBM Websphere Application Server) for zLinux, DB2 for zLinuz, etc. Igualmente recomendable, varias particiones conforme el ciclo de vida (las pruebas, con gaseosa).

De este modo, se consigue mantener las aplicaciones y sistemas existentes junto a las nuevas aplicaciones en la misma máquina, eso sí, bajo sistemas operativos distintos (bajo diferentes particiones - LPAR).

También quería aprovecha para incluir una foto de un servidor IBM zSeries. En particular, se trata de un servidor IBM eServer zSeries 990 (conocido como IBM z990 o simplemente z990). El aspecto de este servidor, es muy similar a otros servidores de la gama zSeries, como pueda ser el IBM z900, etc. Para hacernos una idea, los servidores IBM zSeries (como el z990, z900, etc.) tienen una altura de casi 2 metros y un peso de entre 1,2 y 2 toneladas, características que implican serios problemas para introducir el servidor en un ascensor (no todos los CPDs son sótanos o plantas bajas, y no todos los ascensores permiten introducir objetos de dicha embergadura y peso, y ojo que con el embalaje el tamaño es mayor), y que además implica que la zona en la que se ubica el servidor debe tener el falso suelo reforzado para poder soportar su peso, y en consecuencia, también debe reforzarse el falso suelo que sirva de zona de paso para la entrada y salida del servidor (en caso de instalaciones, migraciones, reparaciones, etc. este falso suelo puede tener que soportar grandes pesos puntualmente). La potencia eléctrica de entrada varía entre los 6 y 18 kw, por comentar otra característica de interés.

Actualmente existen varias distribuciones de Linux para zLinux, principalmente SUSE Linux y Red Hat Enterprise.

En el presente artículo describo el proceso de instalación de la edición de zLinux Red Hat Linux 7.2 s390 sobre el emulador Hercules (emulador de arquitectura s390 para procesadores Intel/AMD), debido a que en el momento de redacción del presente artículo (hace varios años, aunque no lo he publicado hasta el 2008) fué la única edición zLinux que pude descargar de forma gratuita. Aunque en su momento participé en un Workshop de IBM (en sus oficinas de Avenida de América), donde pude instalar (con mis manitas) SUSE zLinux sobre una máquina zSeries (eso sí, bajo zVM, el entorno de Virtualización por Software de HOST... el Hyper-V de la pantalla negra ;-), y aún siendo mi objetivo inicial la redacción de un artículo sobre la instalación de SUSE zLinux, ni pude conseguir un SUSE zLinux para mis pruebas de laboratorio, ni nadie me dejó un HOST para las mismas (que ratas !!), por lo que al final instalé zLinux Red Hat 7.2 s390 sobre el emulador Hercules, lo cual, didácticamente resulta igual de interesante (aunque ojo, que hay diferencias).

Descripción del Entorno de Laboratorio

A continuación paso a describir el entorno de laboratio en el que realicé la instalación aquí descrita, en particular utilicé un PC de sobremesa con Sistema Operativo Linux para procesadores Intel de 32-bit, sobre el cual instalé el emulador Hercules, para sobre dicho emulador realizar una instalación de zLinux (Linux on Linux ;-). Detallo:

• Microprocesador: Intel Pentium IV
• Memoria: 1GB
• Disco 1: 20GB (19GB Datos montado como / y 1GB Swap)
• Disco 2: 8GB (8GB Datos montado como /mnt/hdc1)
• Sistema Operativo: Linux RedHat 9 (kernel 2.4.20-8)
• Dirección IP: 10.99.59.87
• Nombre Host: hercules

Así que, como podréis empezar a evidenciar, SI es posible instalar zOS sobre un PC de Sobremesa (que no es broma, que lo he visto). Es más, también es posible instalar zVM u otros sistemas operativos para máquinas zSeries, sobre un PC de Sobremesa, utilizando el emulador Hercules. De hecho, en su momento, un compañero (consultor de zOS) me enseñó una copia de un HOST de una de las principales empresas aseguradoras españolas, ejecutándose sobre un disco externo USB en su Portátil, con su DB2, su CISC, su ISPF, sus JCLs, su todo... quiero pensar, que no había datos sensibles... quiero pensar...

Instalación y puesta en marcha de Hércules s390

A continuación, se describen los distintos pasos a seguir para instalar y configurar Hércules s390 sobre una máquina Linux i386.

Descargamos el paquete de instalación de Hercules. Yo en mi caso (y en su día), descargué hercules-3.01-1.i386.rpm desde http://www.conmicro.cx/hercules.

A continuación, instalamos el paquete ejecutando un comando como el siguiente:

Creamos dos discos DASD tipo 3390, uno de 7791 cilindros y otros de 1113 cilindros (así es como llamaban a los disco del HOST los técnicos de sistemas: discos DASD). El primero almacenará datos, y el segundo hará las funciones de paginación (swap). Para la creación de los discos, ejecutamos los siguientes comandos:

Con esto, habremos creado dos ficheros, denominados linux.120 y linux.121, en la ruta actual, que emularán dos discos 3390 con el número de cilindros indicados anteriormente. El tamaño de los ficheros ha sido elegido a propósito, cumpliendo los siguientes requisitos:

• Ser mayor de 4GB, para permitir la instalación de zLinux (con soporte para X11), DB2 y WebSphere.
• Caber dentro del disco de 8GB, permitiendo hacer una copia de seguridad al disco de 20GB.

Para la instalación de zLinux en modo nativo o sobre una LPAR, se precisa disponer de un cartucho con un pequeño sistema Linux (si... el HOST aún funciona con cartuchos, manda webs, si cada vez que IBM te envía la última versión de DB2, parece que te envían la serie completa de Falcon Crest en formato VHS), denominado Starter Linux, sobre el cual poder hacer IPL para iniciar el programa de instalación de Linux. Lo de hacer IPL, es otra de las frasecitas frikis de los técnicos de sistemas de HOST (es cómo llaman a reiniciar una máquina o una LPAR). Ellos no reinician una máquina, ellos hacen IPL... que es más fashion ;-)

El Starter Linux está formado por los siguientes tres ficheros:

• Kernel para Linux s390. En nuestro caso tapekrnl.img.
• RAM Disk. En nuestro caso tapeinrd.img.
• Fichero de Parámetros. En nuestro caso parmline.

Para emular una cinta o cartucho, se precisa disponer de los tres ficheros anteriores, así como un cuarto en el que se referencian dichos ficheros, y que habitualmente tiene la extensión tdf.

Seguidamente, necesitamos crear un fichero de configuración para nuestro sistema Hércules s390. Lo más fácil, obtener un fichero de configuración de ejemplo y modificarlo con los siguientes valores (habría que adecuarlos en función de cada instalación):

Dicho fichero de configuración lo denominaremos con cualquier nombre, por ejemplo hercules.cnf.

Para permitir que exista conectividad TCP/IP entre el propio PC y la máquina virtual instalada sobre Hércules s390, modificaremos el fichero /etc/modules.conf añadiendo la siguiente línea:

Además, puede ser interesante acceder a la máquina virtual a través de la red, para lo cual necesitaremos habilitar el enrutamiento IP en el Linux del PC. Para conseguir esto, disponemos de distintos caminos:

• Para activar el enrutamiento IP en un sistema RedHat basta añadir al fichero /etc/sysctl.conf una línea que ponga net.ipv4.ip_forward=1.
• Para activar el enrutamiento IP en un sistema SuSE basta añadir al fichero /etc/rc.config una línea que ponga IP_FORWARD="yes".
• En cualquier otro caso, y siempre que se trabaje con un kernel 2.X, podremos ejecutar el siguiente comando: echo "1" > /proc/sys/net/ipv4/ip_forward.

Para poder acceder a la máquina virtual desde cualquier otro equipo de la red, dicho equipo debe disponer de una ruta para acceder a la red 192.168.200.0/24. Esto se corrige utilizando el comando route, tanto el Linux como en Windows, para añadir una ruta estática, pero requiere hacer este paso una vez en cada máquina que necesite acceder a nuestra máquina virtual. Otra opción, consiste en alterar la configuración de enrutamiento del router que haga las funciones de Gateway en la red, añadiendo en éste dicha ruta. Esta segunda opción, es un poco más delicada.

Llegados a este punto, podremos arrancar nuestro emulador hercules, para lo cual, deberemos especificarle la ruta completa del fichero de configuración que se desea utilizar. A continuación se muestra un ejemplo del comando necesario:

Se iniciará la consola de Hércules s390, dónde se mostrarán diferentes mensajes que ayudarán a conocer si se han reconocido correctamente los dispositivos hardware indicados en el fichero de configuración.

Además, si desde otra sesión Linux contra el PC, ejecutamos el comando ifconfig, deberemos observar que disponemos de un nuevo dispositivo de red denominado tun0, creado al iniciar el Hércules s390, debido a la configuración del adaptador IBM Channel-To-Channel en el archivo hercules.cnf. Este adaptador, es el que proporciona conectividad TCP/IP entre nuestro PC y el Linux que instalaremos sobre Hércules s390.

Finalmente, podremos ejecutar cualquier comando, teniendo en cuenta que los comandos Hércules se escriben directamente (ej: ipl 581), y los comando que deseen enviarse al sistema operativo hospedado se prefijarán con un punto (ej: .ls -la)

Instalación y puesta en marcha de Linux RedHat 7.2 para s390

A continuación, se describen los distintos pasos a seguir para instalar y configurar Linux Redhat 7.2 para s390 sobre una máquina virtual Hércules s390.

Iniciaremos Hércules s390 como se indicó en el apartado anterior.

Para empezar la instalación, realizaremos IPL sobre el cartucho que dispone del Starter Linux, que hemos configurado en la dirección 581. Esto se consigue ejecutando el comando IPL 581 en la consola de Hércules s390. Durante el proceso de arranque, se nos solicitará la siguiente información, que debe ir en consecuencia al fichero de configuración utilizado para arrancar Hércules s390:

• Nombre Completo FQDN: s390.redhat.com
• Adaptador de Red: ctc0
• Parámetros adicionales Adaptador Red: ctc0,0x600,0x601
• IP de la máquina virtual: 192.168.200.1
• IP del otro extremo del CTC: 192.168.200.2
• Servidores DNS: 0.0.0.0
• Nombres de Dominio de Búsqueda: none
• Dirección discos DASD: 120

Tras este proceso, la consola de Hércules s390 nos mostrará el prompt de Linux.

A continuación, para iniciar el programa de instalación, iniciaremos una sesión telnet con el usuario root contra la máquina virtual. Esto puede hacerse desde otra sesión del Linux del PC, ejecutando un comando como el siguiente:

Otra alternativa, sería conectarnos desde un PC Windows, utilizando cualquier cliente Telnet, siendo muy aconsejable la utilización del programa PuTTY, disponible de forma gratuita en Internet. Este programa, además soporta conexiones ssh, lo cual será de utilidad después de la instalación.

Así, iniciada una conexión con la máquina virtual, ejecutaremos el comando rhsetup:

Este programa, basado en pantallas en modo texto, consiste en un asistente que nos guiará a través de los distintos pasos de la instalación. Los pasos a seguir son los siguientes:

• Seleccionar discos DASD y punto de montaje. Seleccionaremos /dev/dasda (lo marcaremos con un asterisco) seleccionando como punto de montaje el directorio raíz (/).
  
  
• Formatearemos el disco en modo CDL, compatible con z/OS. Este paso tarda bastante tiempo.
  
  
• Introducir información de red: Nombre completo (FQDN), Nombres de Dominio de Búsqueda, y Direcciones IP de los Servidores DNS.
  
  
• Indicar el origen de los paquetes. Debe indicarse la ruta a la ubicación de los ficheros de instalación. Existen varias formas de hacer esto (FTP, HTTP, y NFS principalmente). En nuestro caso, lo realizaremos mediante NFS.
  
  
• Selección de Paquetes. Aconsejamos tomar la opción por defecto.
  
  
• Copia de Ficheros. A partir de estos momentos, se realiza la copia de ficheros. Este proceso tardará varias horas.
  
  
• Introducir contraseña del Administrador (usuario root).
  
  

Llegados a este punto, hemos finalizado la instalación de RedHat Linux 7.2 para s390. Sin embargo, es muy aconsejable realizar un par de cosas más, antes de dar por finalizado el proceso de instalación. Esto se detalla a continuación:

• Eliminar del nivel de ejecución 3, el inicio de servicios no deseados. Basta eliminar los ficheros correspondientes de /etc/rd3.d.
  
  
• Modificar el fichero de parámetros del disco, para que contemple los parámetros propios de la instalación, principalmente los discos y los adaptadores de red. Basta modificar el fichero /etc/zipl.conf con una línea de parámetros como la siguiente:
  
  parameters="root=/dev/dasda1 dasd=120,121 chandev=ctc0,0x600,0x601"
  
  A continuación, ejecutaremos el comando zipl a través del comando chroot (ej: [root@s390]# chroot /mnt/dasda1 /sbin/zipl).
  
  
• Desmontar Sistemas de Ficheros. Comprobaremos con el comando mount, qué sistemas de ficheros están montados, desmontando aquellos que no sean necesarios (comando umount), para que no halla problemas con estos al parar Hércules s390.
  
  
• Parar Hércules s390. Desde la consola de Hércules s390, ejecutaremos el comando STOP, parando totalmente la máquina virtual. A continuación ejecutaremos el comando EXIT para cerrar la consola Hércules s390 y volver al Sistema Operativo del PC.
  
  
• Realizar Copia de Seguridad. Para realizar la copia de seguridad, basta copiar los ficheros que emulan los discos 3390, ya que la reinstalación de Hércules s390 y su configuración, no tienen gran complejidad.
  
  

Customización de la instalación de zLinux y Operaciones

Una vez finalizada la instalación de zLinux, disponemos de un sistema sobre el que poder arrancar (IPL), y sobre el cual tenemos que configurar qué servicios deseamos arrancar al inicio, configuración de discos y sistemas de ficheros, configuración de swap, etc. A continuación, se describen varias de estas tareas.

• Configuración de Servicios para su Inicio Automático. Para configurar un servicio para que se inicie automáticamente en un determinado nivel de ejecución, instalaremos el o los correspondientes paquetes, y a continuación ejecutaremos el comando chkconfig. Así, por ejemplo, para configurar el servicio iptables para que se inicie automáticamente en los niveles de ejecución 3, 4, y 5, ejecutaremos el siguiente comando:

Del mismo modo, si deseamos saber qué servicios están configurados para su inicio automático en qué niveles de ejecución, ejecutaremos un comando como el siguiente:

• Configuración de Nuevos Discos.Si añadimos un nuevo disco de datos a nuestro sistema, deberemos seguir los siguientes pasos antes de poder utilizarlo.
  
  
  • Comprobar si el disco ha sido reconocido por Linux. Para ello, comprobaremos que aparece dentro del fichero /proc/dasd/devices. Para esto, el disco debe estar definido en el fichero de parámetros.
  • Formatear el espacio del disco DASD. Esto se realiza mediante el comando dasdfmt, el cual borrará la etiqueta del volumen, la VTOC, y los datos (ej: [root@s390]# dasdfmt -b 4096 -f /dev/dasdb). Este comando tarda bastante tiempo en ejecutarse, aproximadamente 20 minutos para formatear un disco 3390-3, por poner una referencia.
  • Crear una Partición. Ahora podemos crear una partición en el disco, utilizando el comando fdisk. Es aconsejable crear una única partición en cada disco DASD.
  • Crear un Sistema de Ficheros. La creación de un sistema de ficheros se realiza mediante el comando mkfs (ej: [root@s390]# mkfs -t ext3 /dev/dasdb1).
  • Montar el Sistema de Ficheros. En este momento, podemos montar el sistema de ficheros recién creado sobre un punto de montaje, para así poder acceder a éste. Si deseamos que esta información sea persistente, es decir, que siempre que se inicie el sistema monte automáticamente dicho sistema de ficheros, modificaremos en consecuencia el fichero /etc/fstab. Si deseamos realizarlo esporádicamente, ejecutaremos el comando mount.
  
  
  Si el disco que estamos añadiendo realizará funciones de paginación (swapping), ejecutaremos los dos primeros pasos como en el caso anterior, sin embargo, al crear la partición la crearemos del tipo Linux Swap, para seguidamente preparar la partición con el comando mkswap (ej: mkswap /dev/dasdb1), y finalmente activarla con el comando swapon (ej: swapon /dev/dasdb1). Para que los cambios sean persistentes, y cuando arranque el sistema se active automáticamente el disco de swap, modificaremos en consecuencia el fichero /etc/fstab.
  
  NOTA: La adición de un nuevo disco al sistema no puede realizarse en Tiempo de Ejecución, al menos de momento, debido a que hay que modificar el fichero de parámetros del código de arranque, y botar de nuevo el sistema (IPL), para que Linux reconozca los nuevos dispositivos. Es muy aconsejable entrar en el nivel de ejecución 1 para realizar labores de este tipo, evitando los problemas que pudieran producirse por las conexiones de usuarios, la ejecución de servicios, etc.

• Parar o Reiniciar el Sistema. Antes de parar o reiniciar el sistema, es recomendable desmontar los discos que estén montados, para evitar problemas con estos. Seguidamente, ejecutaremos el comando shutdown.

• Separación del Sistema de Archivos en Particiones. Habitualmente, el Sistema de Archivos suele separarse en diferentes particiones por diversos motivos, siendo la siguiente un modelo apropiado a seguir:

• Comprobar Espacio Libre y Ocupado en Discos y Directorios. Para comprobar el espacio libre y ocupado de los distintos volúmenes del sistema local, debe utilizarse el comando df, como se muestra en el siguiente ejemplo:

Para obtener una estimación del tamaño de los subdirectorios de una carpeta en múltiplos de byte, se utiliza un comando como:

Si se quieren ver dos niveles de profundidad, se ejecutaría: