Hardware y Conexionado de un Mainframe
En esta nueva entrega, trataré de explicar que se cuece en las tripas de un mainframe (en adelante, Host) y por qué funciona como funciona.En primer lugar, debo comentar que cualquier analogía con un PC es pura coincidencia, un host no se parece ni de lejos a un PC.
Por tanto, preguntas como ¿Cuántas veces es mas potente un host comparado con un PC? y similares no tienen respuesta, debido a que dichas preguntas se deben enfocar como un todo y hay mil y una diferencias con respecto a estas dos plataformas y porque el propósito de cada máquina es bien distinto, de la misma forma que no se pueden mezclar churras con merinas.
Y sin mas preámbulo, paso a explicar el meollo del aparato a nivel hardware:
Procesador IBM ES/9000 9021Una de las particularidades por las que un host es diferente es por la arquitectura hardware. Sin entrar en detalles de la redundabilidad extrema del aparato, y la posibilidad de que el fallo de un componente sea imperceptible de cara a explotación, el host tiene una capacidad de ampliación que abarca un gran numero de componentes.
Por un lado esta el procesador, que es un cajón donde se encuentra la memoria y el (los) procesador(es). Y, por otro lado, se encuentran todos los periféricos.
Lo interesante de estos periféricos es que todos (absolutamente todos) se comunican con el mismo protocolo de comunicaciones, como si de un sistema USB se tratara. Este protocolo de comunicaciones viaja por una conexión llamada “Canal” (Channel), que puede ser de cobre, o de fibra óptica (en la actualidad todas son de fibra).
Y dentro de la tecnología de fibra, existen dos sistemas: ESCON (Enterprise System CONnection), que transmite a 17 MB/seg y lleva desde 1990 dando caña o FICON (FIber CONnection) que lleva desde el año 2000 y transmite a 100MB/seg la primera generación, a 200 MB/seg la segunda -ahora vamos por la cuarta- y se parece mucho al sistema Fiber-Channel de las unidades SAN de almacenamiento.
Además, y al contrario que con los USBs, un dispositivo puede tener más de un canal, por lo que puedes jugar con la ampliación de un componente tanto en capacidad como en ancho de banda ya que el host automáticamente equilibra el ancho de banda entre más de un canal de ese dispositivo si le añades mas conexiones.
Sistemas de Discos IBM 3380Con esta introducción, habréis imaginado que las posibilidades son terribles: Varios procesadores pueden estar conectados a un mismo dispositivo y varios dispositivos se pueden c
onectar a un mismo procesador. Incluso se pueden conectar los dispositivos entre ellos (por ejemplo, entre dos sistemas de discos y montar un PPRC -Peer to Peer Remote Copy- para redundancia de datos).
También entre procesadores, pasándose mensajes entre ellos en una arquitectura Sysplex (Cluster de mainframes) o montando una red TCP/IP virtual encima de ellos de alta velocidad para que se interconecten (este tipo de configuración se denomina Channel-To- Channel o CTC).
La probabilidad de exclusiones por reservas de dispositivos (por ejemplo, dos procesadores quieren acceder a los mismos discos) son casi imposibles, debido a que por un lado los protocolos de canal no se pegan entre sí, y por otro, existen utilidades en los sistemas operativos como colas GRS (Global Resource Serialization) que impiden acceder al mismo dato, del mismo disco en el mismo instante de tiempo.
Bien, hemos hablado de procesadores y periféricos que conforman un host, y también los canales que se utilizan para comunicarse entre ellos. Veamos ahora como los ve un Host.
El host dispone de una utilidad llamada IOCP (Input-Output Configuration Program), donde defines todo lo que se le puede conectar. Tiene 3 partes de configuración:
Procesador z/Series 900. Nótese del portatil con la configuración de IOCPEn la primera parte, se definen el numero de canales que el host va a utilizar contra todos los dispositivos de la instalación. Ojo, un procesador puede tener muchos mas canales instalados, pero aquí solo se definen los que se van a usar. Estos canales vienen en tarjetas que se pinchan sobre el backplane del procesador, y tienes tarjetas de 4, 8 o 16 canales.
¿Qué quiere
s más canales? Pues compra una tarjeta y la pinchas en el procesador, siguiendo unas normas de colocación en el bastidor. Luego, se le dice que dirección hardware tiene cada canal, como pasaba en las antiguas tarjetas de sonido Sound Blaster, que le teníamos que decir en el juego que tenía la dirección 220h, y que en el caso de los canales, a esta dirección se la denomina CHPID (CHannel Path IDentification) y que tipo de canal es (puede ser ESCON, FICON, Paralelo, CTC, etc).
En la segunda parte, se definen las unidades de control donde esos canales están conectados. En un texto anterior comenté que todo dispositivo tiene una unidad de control, con un microcódigo que se encarga de gestionar el periférico y su control de errores (análogamente, es como si fuera la controladora IDE de un PC, al que luego se le conectan discos).
Esas unidades de control a su vez tienen una direccion hardware que debes configurar a priori cuando compras la unidad, llamada CUNUMBR (Control Unit NUMBeR), asi que el IOCP debe tener constancia de ello, por lo que en el IOCP se le debe decir la dirección de la unidad de control y luego a que canales esta conectada (recordad que se pueden conectar a mas de un canal).
Y la tercera y última parte, se configuran los dispositivos periféricos en sí. Cada dispositivo tendrá una dirección hardware llamada IODEVICE (Input-Output DEVICE), que deberá también ser reflejada en el IOCP, así como a la unidad de control a la que está conectada.
Tarjetas de canales ESCON de un procesador IBM S/390 modelo 9672Como os habréis imaginado, en una instalación host muy grande, por ejemplo, con varios procesadores interconectados con cientos de Terabytes repartidos en cientos de discos duros, impresoras, sistemas de comunicaciones, robots de cintas, etc., la lista de configuración puede llegar a ser muy larga, pero existe una utilidad para simplificar las ta
reas de mantenimiento en el sistema operativo, llamada HCD (Hardware
Configuration Dialogs) que ofrece algunos asistentes y ayudas para configurar el sistema (aunque lo he sufrido en mis carnes y hasta que le coges el truco, es jodido de usar).
Afortunádamente, rara vez se cambia la instalación de un host, mas que para ampliarlo, de modo que tampoco se hace un uso muy frecuente de esta herramienta.
Bien, hasta aquí hemos llegado por hoy. En anteriores entregas he explicado la historia, las aplicaciones que manejan y en esta, el hardware y su interconexionado. En las siguientes entregas, a menos que os aburra demasiado, os podría explicar las funcionalidades y utilidades del Sistema Operativo de estos mastodontes. ¿Qué opináis?
En la pasada edicion de la Euskal Encounter 14, lleve una instalación completa mainframe al evento. Dicho mainframe consiste en los siguientes elementos:
Se quedó una tarde en el Yggdrasil HeadQuarters para trasladar estos equipos al Pabellón 5 del BEC, que era donde se montaba la Euskal Encounter. Para ello, utilizamos un camión de grandes dimensiones con grua para poder trasladar los equipos, que cabe decir que pesaban un huevo. Una vez allí, y después de descargar en el pabellón, nos pusimos manos a la obra.
Además, la organización de la Euskal se porto maravillosamente con nosotros y nos regalaron una manguera de cable trifásico larga, y un enchufe del mismo tipo que usan en el BEC, con lo que solucionamos el problema para sucesivas Euskals que llevemos el aparato. Una vez embornado el sistema y comprobado el cruce de fases, nos dispusimos a conectar los diversos aparatos, es decir, el procesador, los discos, las cintas y el armario de comunicaciones. Como era de esperar, todo el sistema arrancá a la primera.
Por otro lado, mi buen compañero Bato me ayudo a configurar los discos RVA, tarea harto dificil porque nos dio un problema de configuración y tuvimos que empezar de cero formateando los discos y generando los arrays.
Por fin, durante el transcurso de la Party, numerosas personas vinieron a hacerse fotos con las máquinas y se conectaron para poder descargar anime de las tripas del mainframe. Lamentablemente, cabe decir que los discos IBM RVA nos dieron numerosos problemas, hasta el punto de que los arrays de discos se iban rompiendo a medida que pasaban los dias, hasta que al final, al finalizar la party, se decidió llevar el sistema de discos a reciclar, ya que no nos iba a servir de nada por los daños que sufrio internamente.
