Cómo ahorrar MIPS en entornos Mainframe

Optimizar el uso de servidores mainframe es vital para mantener a raya los costes de computación. Se trata de máquinas que, generalmente, llevan a cabo procesos vitales para la empresa. Por lo tanto, necesitan de una elevada disponibilidad. Debido a este motivo, es interesante ahorrar MIPS (millones de instrucciones por segundo). Así se consigue tener siempre capacidad de proceso disponible.

Las necesidades de computación han cambiado mucho en los últimos tiempos. Los mainframes no estaban pensados originalmente para aplicaciones de cara al usuario. Ni mucho menos lo estaban para tecnologías como aplicaciones móviles. En la actualidad, el software no es solo más exigente en cuanto a la carga de trabajo que genera al servidor. También lo es en los tiempos de respuesta que requiere. Esto puede llevar a que un servidor bien dimensionado no sea capaz de dar una respuesta lo bastante veloz como para que las aplicaciones funcionen sin excesivo retardo.

Para ahorrar MIPS de una forma efectiva y mantener los mainframes completamente operativos, el primer paso es detectar qué procesos son los que generan cargas de trabajo más elevadas. También hay que identificar en qué momentos lo hacen. De poco sirve optimizar un proceso que no supone un problema para el servidor o que, aunque suponga una elevada carga de trabajo, solo se ejecuta ocasionalmente y en momentos de poca ocupación.

Lo primero a tener en cuenta de cara a ahorrar MIPS es cómo medir la carga que genera cada proceso al sistema. Disponer de buenas herramientas de monitorización puede dar una idea de las tareas de mayor carga o que están poco optimizadas. Además, otras herramientas de análisis de código, como los profilers pueden ayudar a optimizar software que funciona correctamente, pero que en algún punto del código su funcionamiento puede representar una carga mayor de la estrictamente necesaria.

Muchas de estas herramientas darán los resultados en tiempos de ejecución, en vez de en MIPS u otra medida que dé una idea de las instrucciones por segundo necesarias. No obstante, pueden ser muy útiles para detectar dónde se puede llevar a cabo una optimización. En muchas ocasiones, el propio servidor dispone de herramientas que proporcionan información sobre los procesos del sistema. O sobre sus tiempos de ejecución.

Trasladar parte del software para ahorrar MIPS

Una buena estrategia a seguir para los procesos que lo permitan es llevarlos a otras plataformas menos costosas. Las arquitecturas basadas en microservicios permiten trasladar partes de una aplicación a otros servidores sin necesidad de modificar el código. En estos casos, conviene tener en cuenta las implicaciones del traslado. Así, si el proceso se comunica con otros que se ejecutan en la misma máquina, ahora lo hará a través de la red.

Esto llevará, con toda probabilidad, a retardos que antes no existían. En especial si la conexión de red no es lo suficientemente rápida o si la cantidad de datos a intercambiar es elevada. Es posible que estos retardos no afecten significativamente al rendimiento de la aplicación. Pero en ocasiones la red supondrá un cuello de botella que puede afectar a este proceso o a otros que hagan uso de ella. En estos casos, puede que interese trasladar también otras partes de la aplicación o repensar la arquitectura de algún componente para optimizarla.

Entre las opciones para trasladar el software de un mainframe a plataformas de menor coste están los procesadores específicos. En el caso de IBM, se ha hecho popular el z Integrated Information Processor (zIIP), diseñado inicialmente para llevar a cabo tareas específicas en la base de datos db2. A lo largo del tiempo ha ido añadiendo nuevos usos muy diversos. Otros procesadores específicos de los que se puede sacar ventaja, ahorrando MIPS llevando el proceso a sistemas más asequibles, son los zAAP y IFL. Estos descargan al mainframe de la ejecución de aplicaciones escritas en Java. O de las que ejecutan sistemas como Linux fuera de los procesadores principales del mainframe.

Si es posible detectar qué aplicaciones o qué partes de estas pueden funcionar en estos procesadores de propósito especial sin penalizar a su rendimiento, esta inversión puede amortizarse en poco tiempo. Esto se consigue dado que descargan al mainframe de algunas tareas especialmente costosas.

Optimizar el código de las aplicaciones

En otros casos, puede ser preferible mantener la aplicación en el mainframe. Eso sí, migrándola a lenguajes más modernos o rediseñando partes del software para optimizar su funcionamiento. Esto no quiere decir que la aplicación original tenga problemas de diseño. Lo que implica es que fue diseñada bajo los condicionantes impuestos por otros requisitos.

Por ejemplo, una consulta SQL compleja que se llevaba a cabo diariamente para exportar un informe, puede que actualmente se lance bajo demanda por cada usuario del sistema. En el diseño original, es probable que la complejidad de la consulta no fuese una limitación, ya que el usuario podía esperar unos minutos para tener sus informes. En la actualidad, es posible que esos informes los solicite un proceso que, a su vez, procesa los datos recibidos.

El coste en MIPS de estar ejecutando este tipo de tarea de forma continuada puede reducirse notablemente por varias vías. Por ejemplo, optimizando la consulta SQL o creando una nueva específica para estos procesos. Esta debe devolver ya el resultado final o resultados menos complejos, pero suficientes para el procesado posterior.

También es posible que no sea necesario que los datos de la consulta estén actualizados al segundo y se pueda guardar una caché con consultas realizadas cada hora. O, por último, podría utilizarse una base de datos en memoria para agilizar las consultas. En este último caso, no se ahorrarían MIPS, sino tiempos de acceso.

Si los servidores están externalizados y se paga por uso, es posible que el proveedor facture por periodos determinados. Muy habitualmente, de cuatro en cuatro horas. En esos casos, es probable que organizar procesos repetitivos permita redistribuir los MIPS en esos bloques. De esta manera no se superarán ciertos umbrales que implican un mayor coste. Es otra medida que no implica una reducción del cómputo global de MIPS, pero sí una distribución de la carga que optimiza su coste.