Proyecto Migración HOST.

•
2014
•
2014
Proyecto Migración HOST
• CIMUBISA
CIMUBISA
• Departamentos
Desarrollo
y Sistemas
Ayuntamiento
de Bilbao
• Ayuntamiento de Bilbao
01/01/2014
• 01/01/2014
INDICE
1.
Antecedentes
3
3
3
6
6
6
7
7
8
Principal problema: el coste
Problema adicional: la tecnología
Formas de abordar el problema
Volumetría
Arquitectura técnica
Situación Anterior:
Situación Actual:
Coste de Oportunidad. Escenario de NO migración.
9
2.
Objeto del proyecto.
3.
Implicaciones.
12
4.
Las ventajas para el Ayuntamiento.
12
5.
Equipo de Desarrollo y Proveedores.
13
6.
Valoración económica.
13
7.
Plazo de cumplimiento.
13
2
1.
ANTECEDENTES
El Ayuntamiento de Bilbao, y por delegación CIMUBISA, mantenía una significativa parte de sus
sistemas informáticos sobre un entorno IBM System z (Host o Mainframe a partir de ahora).
Estos sistemas presentaban como fortaleza unos muy elevados ratios de disponibilidad (probablemente
los mejores del mercado) pero a la vez planteaban unas importantes debilidades y, sobre todo, grandes
amenazas. Es de ahí de donde surgen las oportunidades de cambio.
La principal fortaleza es la disponibilidad. Probablemente no hay en el mercado ninguna otra plataforma
equivalente en este indicador, tanto a nivel de hardware, a nivel de software de base (sistema operativo)
y a nivel de aplicaciones. El System z tiene internamente todo el hardware duplicado de forma que puede
salir airoso de un gran número de contratiempos que podrían en jaque a cualquier otra plataforma.
Igualmente, su sistema operativo (zOS) tiene casi la mitad de su código dedicado a la auto-corrección de
errores frente a las pantallas azules de la muerte de Windows o los traps de Linux. A su vez, el código
Cobol es tremendamente estable y capaz de funcionar sin cambios durante años, cosa que por unas
razones u otras resulta complejo en las plataformas Java y .NET.
PRINCIPAL PROBLEMA: EL COSTE
Por el contrario, la plataforma System z tiene unos elevados costes de mantenimiento anual. El pago por
consumo hace que muchas instalaciones estén planteando la migración a sistemas abiertos donde se
realiza un único pago (compra de licencia).
Del mismo modo, la plataforma System z va muy rezagada en la lucha por el mercado de Internet. Es
raro encontrar entidades que dispongan de sus sistemas de backend de Internet sobre esta plataforma.
Y la cantidad se reduce a cero cuando se trata de entidades y corporaciones de reciente creación
(menos de 15 años) que no tienen costes de arrastre por desinvertir en estas tecnologías. Y en ese
escenario, en el que ya todo mira a Internet, cabía preguntarse si la plataforma Host sigue siendo la
plataforma ideal.
PROBLEMA ADICIONAL: LA TECNOLOGÍA
Adicionalmente, todos los nuevos desarrollos puestos en producción en los últimos tres años están en
dos líneas bien definidas: SAP para el procesamiento interno de Expedientes y Web para lo que está
cara al público y para las aplicaciones Intranet. Cada vez que aparecía una nueva aplicación se arañaba
un pedacito de terreno al Host.
En esa línea cabe destacar el arranque de aplicaciones SAP como RRHH, Expedientes, Tasas y
Recaudación o Web como Gestión del área de Educación, GeoBilbao y resto de aplicaciones GIS,
Gestión de Bicicletas, Taxis y otros en CyT,… Con ello, el host iba quedando cada vez más aislado de
las nuevas tecnologías dentro del Ayuntamiento. Es significativo que ninguna aplicación nueva
desarrollada en los últimos cinco años se sustente sobre esta tecnología.
En ese escenario, la relación coste/beneficio del entorno mainframe será cada vez más discutible y
criticado porque se mantendrán los costes (hay una parte importante de costes fijos) para un volumen de
aplicaciones cada vez menor.
Los siguientes cuadros muestran los consumos realizados durante los últimos años y en ellos se puede
observar que no hay incrementos, ni en número de procesos batch, ni en transacciones online ni en
minutos de CPU. Esto no ocurre en ninguna otra plataforma municipal (SAP, J2EE, .NET,…) que
presentan incrementos de más del 25% año sobre año.
3
4
El declive del entorno Host en favor de otras plataformas es evidente en las gráficas.
5
FORMAS DE ABORDAR EL PROBLEMA
La estrategia de ir apagando aplicaciones progresivamente no era una opción porque la curva de costes
de consumo en los Host IBM no es lineal. Al principio describe una trayectoria prácticamente asintótica
en el eje de las Ys. Es decir, que el 80% del coste anual de la máquina se repercute con el primer 10%
de consumo. Como referencia, hace cuatro años el consumo de la máquina estaba en el 85% con
tendencia a subir al 95%. Gracias a las optimizaciones llevadas a cabo por el grupo de Sistemas
Centrales se consiguió llegar a una máquina auto-limitada al 65% con tendencia a bajar al 50%. Sin
embargo, el coste de estar al 95% y el de estar al 50% es razonablemente similar ya que la mayor parte
del coste se aplica al primer 10%.
A su vez, el problema de la alta estabilidad del entorno mainframe podía ser compensada con seguridad
mediante la creación de clústeres o entornos en los que el servicio estuviera cubierto por al menos dos
elementos independientes de infraestructura. De este modo, con la disponibilidad combinada de dos
máquinas independientes se llegaba a igualar los niveles de disponibilidad del Host.
Por último, el hecho de que únicamente se dispusiera de un Host en una ubicación imponía un nivel
elevado de riesgo antes fallos de los servicios de base (refrigeración, electricidad, sabotajes,…). Pero
disponer de un segundo mainframe supondría un elevado incremento de la inversión en hardware y el
gasto recurrente. Por tanto, en ese escenario incluso se podría llegar a decir que la seguridad y
estabilidad de la nueva plataforma era mayor que la que facilita un único Host no redundando en un
segundo CPD.
VOLUMETRÍA
En cuanto al número de programas y aplicaciones a migrar, partiendo de la cifra inicial de 43.000
(volumen acumulado a lo largo de 25 años de desarrollo en este entorno), se estimó que existían algo
menos de 25 mil programas activos, en torno a 125 bases de datos y unas cinco mil tablas.
ARQUITECTURA TÉCNICA
A continuación se muestran dos imágenes con la arquitectura técnica anterior y la arquitectura técnica
actual donde se pueden analizar los cambios de tecnologías punto por punto.
Es importante destacar que uno de los pilares del área de conocimiento del equipo de Desarrollo
(COBOL) no se ha visto afectado en modo alguno sino que se potencia con la implementación de nuevas
herramientas de desarrollo del ciclo completo de vida (editores, depuradores, compiladores,
simuladores,…) de este lenguaje.
6
SITUACIÓN ANTERIOR:
SITUACIÓN ACTUAL:
A grandes rasgos, el sistema operativo zOS se ha sustituido por Windows, la base de datos DB2 se ha
sustituido por SQL Server. Por su parte, tanto el monitor transaccional CICS como el JES se han
sustituido por Microfocus Enterprise Server.
7
En cuanto al desarrollo de aplicaciones, todas las herramientas de desarrollo del entorno Host han
desaparecido en favor del IDE de Visual Studio 2012. Toda la programación se ha hecho visual,
incluyendo el diseño de formularios, la depuración de programadas, la gestión del repositorio y control de
versiones, etc.
COSTE DE OPORTUNIDAD. ESCENARIO DE NO MIGRACIÓN.
En el supuesto de no abordar el cambio, el Ayuntamiento (CIMUBISA) se hubiera visto obligado a
abordar un proyecto de evolución de la plataforma mainframe (System z) para alinearlo con las nuevas
tecnologías. Este proyecto hubiera incluido la sustitución del hardware (la propia máquina) así como la
migración de versiones de sistema operativo, base de datos y monitor transaccional (zOS, DB2 y CICS)
entre otros dado que estaban desfasados tecnológicamente en varias versiones. Esta migración no era
banal ni simple al tiempo que era totalmente obligatoria dado que una parte importante de los productos
existentes actualmente en la plataforma Host estaban fuera de soporte.
Esta migración únicamente hubiera servido para mantener la infraestructura en línea dado que no se
hubiera mejorado ningún proceso, no se hubiese aumentado el rendimiento de la máquina, no se
hubieran mejorado las herramientas de Desarrollo ni de Sistemas ni se hubiera abordado la renovación
tecnológica y de conocimientos del personal.
Es decir, tanto si se hubiera abordado la transformación integral de las aplicaciones de CIMUBISA como
si no, CIMUBISA se hubiera visto inmersa en un proyecto de migración.
El siguiente gráfico muestra (en gris claro) los costes de mantenimiento de la infraestructura mainframe,
en rojo los costes de inversión del proyecto de migración (2012 y 2013) y los recurrentes en años
posteriores y en gris oscuro los costes de mantenimiento en el supuesto de que se hubiera continuado
con la plataforma IBM. Estos últimos se deben fundamentalmente a la renovación del hardware y la
consiguiente actualización de potencia en el software facturable anualmente en función del consumo.
Viendo las cifras de forma global se puede concluir que en el periodo 2012-2017 la diferencia de costes
de una y otra plataforma será la que se plasma en la gráfica siguiente:
8
2.
OBJETO DEL PROYECTO.
El objeto de este proyecto ha sido la consultoría, contratación de licencias de software y hardware y la
ejecución y puesta en marcha de un proyecto para la migración de las aplicaciones Cobol sobre
mainframe a un entorno igualmente Cobol pero con niveles de coste recurrente considerablemente
inferiores.
Esto ha incluido el análisis de las aplicaciones, las interconexiones internas de estas aplicaciones dentro
del Host, las conexiones con otros sistemas (Web, AS400, SAP, gráficos, impresión,…), la adquisición
de licencias de software, la migración de programas y bases de datos al nuevo entorno, la fase de
pruebas, la formación y cualquier otro aspecto no expresamente excluido en el pliego, con el objetivo de
poder apagar la máquina System z como conclusión del proyecto.
Este proyecto implicaba un nivel de riesgo tecnológico alto pero, sobre todo, un nivel de riesgo extremo,
tanto a nivel interno (área de Desarrollo de CIMUBISA fundamentalmente) como a nivel externo con los
directores de las áreas municipales y los usuarios. Este último colectivo debía conocer el proyecto,
entenderlo, comprender los motivos que lo provocaban y, sobre todo, tener un espíritu de colaboración,
fundamentalmente en la fase más importante de todas: la fase de pruebas.
Igualmente, se produjo un cambio disruptivo en las formas de hacer de los equipos del área de
Desarrollo, pasando de programar en un entorno 3270 a un entorno de programación integrado como
Visual Studio. El salto es de más de 30 años entre unas formas de hacer y otras y los beneficios serán
rentabilizados rápidamente una vez que los técnicos del equipo de desarrollo se sientan cómodos en el
nuevo entorno.
Los puntos fuertes de la migración se enumeran a continuación.
Inventario de objetos. Este inventario obligaba a detallar programa por programa todos los
objetos que había sido ejecutados en los últimos años y/o aquellos que aun no habiendo sido
ejecutados recientemente debían estar en producción para su utilización en periodos concretos
del tiempo tal que procesos electorales cuya periodicidad está muy distanciada en el tiempo.
Este paso se inició con criterios muy restrictivos obligando por ello a la incorporación constante
de objetos dentro del scope de migración. Gracias a ello se garantizó que no se migraba ningún
objeto que no fuera realmente necesario.
Migración de objetos. Una vez analizado el ámbito de objetos dentro del perímetro de la
migración se procedió al análisis de su sintaxis en busca de patrones de programación que
9
simplificaran el proceso. Esto permitió hacer la práctica totalidad de los cambios de forma
automática. Los mayores problemas en este punto se debieron a varios factores:
o
o
o
Falta de concordancia entre el objeto compilado y el fuente en producción e incluso
múltiples versiones del mismo programa. Esto obligó a la revisión individualizada de
estos programas que afortunadamente fueron muy pocos de entre los 25 mil objetos
a migrar.
El segundo problema fue la conversión ASCII-EBCDIC. El Host IBM utiliza el juego
de caracteres EBCDIC mientras que el resto de arquitecturas se basan
fundamentalmente en ASCII. Este cambio, en principio banal, puso de manifiesto un
grave problema dado que entre ambos juegos de caracteres los pesos de letras y
números están invertidos. Esto provocaba que ciertas instrucciones de comparación,
aun siendo correctas, produjera resultados contrarios a los esperados. Este punto
obligó a la revisión pseudo-manual de los cambios sugeridos por los autómatas de
migración en ciertas instrucciones de comparación que cumplían unos patrones
determinados.
El tercer y último problema fue una mala práctica de programación muy extendida
derivada de utilizar la fecha del sistema como clave única, tanto en tablas como en
procesos de gestión de colas. La mayor rapidez de procesamiento del nuevo sistema
puso de manifiesto que se daban casos en los que varias iteraciones dentro de bucle
podían obtener una fecha del sistema idéntica, incluyendo el segundo hasta con 8
decimales. Esto obligó a la identificación y conversión de estos programas para
utilizar una clave única real (número aleatorio combinado con otros factores para
añadir mayor complejidad) y no una clave basada en la fecha y hora.
Migración de datos. La migración de datos era compleja por múltiples razones. La primera el
volumen y la ventana de tiempo disponible. Era preciso migrar 125 bases de datos y más de
cinco mil tablas y el tiempo para ello no permitía grandes alegrías. Se diseñó un proceso de
migración que permitía el traspaso de datos por múltiples vías dedicando la mayor capacidad de
procesamiento posible paralelizando hilos de ejecución.
o
o
El segundo problema de la conversión eran los campos alfaclave. Existían campos
que ponderaban los nombres de personas y calles generando una especie de valor
numérico asociado al texto fonético. Estos campos permiten al Ayuntamiento la
realización de búsquedas sin importar si los textos reales están escritos con o sin h,
con ch o tx,… Estos campos alfaclave se veían nuevamente afectados por la
conversión ASCII/EBCDIC por lo que hubo que diseñar un proceso específico para
ellos.
El tercer problema derivado de la migración de datos radicaba en la existencia de
textos con diferentes juegos de caracteres dentro de la base de datos. No era lo
mismo un texto introducido desde un terminal 3270 que un texto introducido desde
una aplicación Java mediante conexión con el DB2 ya que hay un diferente soporte
de caracteres ASCII elevados como ñ’s, vocales acentuadas, etc. Hubo que
identificar y realizar procesos post-migración específicos para estos campos.
Integraciones. Como en todos los proyectos actuales, las integraciones fueron uno de los
problemas más complejos de resolver. Existían integraciones internas entre diferentes
aplicaciones municipales e integraciones externas con otras organizaciones.
Las primeras fueron resueltas con el ánimo de simplificar los procesos. Así, se aprovechó el
cambio para alterar los procesos, algunos de forma muy significativa, con objeto de hacerlos
compatibles con los nuevos sistemas. Quizá el más complejo y laborioso fue el de la impresión
ya que obligó al cambio de tecnología para la impresión Host pasando de una herramienta que
generaba informes con tecnología AFP (protocolo propietario de IBM) a una herramienta que era
10
capaz de generar impresos PCL y PDF. Esto obligó al rediseño de todos los listados e informes
del Ayuntamiento lo que fue aprovechado para un lavado de cara estético allí donde procedía.
En total se migraron más de dos mil informes de todo tipo. La impresión mediante PCL y PDF
permitió a su vez dos ventajas añadidas: el ahorro de papel al poder generar PDFs que son
enviados por email al usuario y archivados con la consiguiente no impresión y la generación PCL
de todo lo que debe ir a la impresora no haciendo necesaria la compra de adaptadores AFP para
las impresoras.
Las integraciones externas tenían como complejidad añadida la incapacidad para gestionar el
otro extremo (la entidad con la que se intercambia información). Por ello hubo que rehacer todos
los procesos de transferencia de información con los bancos mediante el estándar Editran.
Los procesos más complejos dentro de este subconjunto fueron, nuevamente, aquellos que
exigían cambio de juego de caracteres dado que la otra entidad esperaba información en
EBCDIC y la nueva plataforma la generaba en ASCII. Las pruebas con las entidades con las que
se compartía información mediante esta vía fueron especialmente complejas al no tener en
muchos casos visibilidad directa de la información que se estaba enviando o recibiendo.
Fase de pruebas. Ha sido, con diferencia, la fase más dura y compleja del proceso dado que ha
habido que construir entornos paralelos al Host que permitieran sincronizar las copias de datos
para permitir comparaciones homogéneas de procesos complejos.Esta fase ha sido muy
exigente para todos los equipos del proyecto al obligar a probar todas las aplicaciones y
programas. Incluso se daba el caso en cada programa que debía ser probado varias veces
provocando diferentes situaciones mediante datos en las BBDD que alteraban su
comportamiento.
Migración. La complejidad del proceso radicaba en que una vez puesta en marcha la nueva
plataforma no había marcha atrás. Durante las fases de análisis del proyecto se analizó la
posibilidad de migraciones parciales de aplicaciones pero tanto a nivel económico como
fundamentalmente a nivel técnico se descartó por la imbricada relación entre las aplicaciones;
migrar una implicaba migrar otras que a su vez implicaban otras más. Y la única alternativa a ello
era construir complejísimos procesos de intercambio entre las dos plataformas.
Por ello, una vez iniciada la andadura de la nueva plataforma con la consiguiente alteración de la base
de datos se hacía muy complejo volver a la plataforma anterior sin pérdida de información.
Todo el proceso debía realizarse durante un fin de semana intentando mantener vivo el sistema a migrar
la mayor cantidad de tiempo posible por necesidades del servicio, fundamentalmente por el Área de
Seguridad que requiere acceso a la información 24x7.
El proceso implicaba la realización de todo lo anterior con una coordinación de pasos perfectamente
establecidos. El plan de arranque contenía más de 50 hitos que debían ser alcanzados progresivamente
en el tiempo y que eran dependientes entre ellos.
La ejecución del plan fue realizada con éxito a principios de Julio tras un intento de arranque abortado a
mitad de proceso al detectar un bug de producto en el motor de base de datos que fue corregido pocos
días después.
En la actualidad, todos los sistemas del Ayuntamiento están funcionando a pleno rendimiento sobre una
máquina estándar x64.
11
3.
IMPLICACIONES.
La migración provoca a nivel interno (CIMUBISA) un cambio en la forma de hacer del personal de
Desarrollo. Pese a que el lenguaje de programación sigue siendo Cobol no cabe duda que hay una
transición para pasar de programar en un entorno 3270 a un entorno de desarrollo integrado y gráfico.
Las ventajas de este último son apabullantes. No ha sido necesario un gran ciclo de formación para
la adaptación al cambio dado que el lenguaje sigue siendo el mismo. La formación viene más ligada al
entorno de programación en sí (Visual Studio) y el manejo de nuevas herramientas gráficas que a la
programación propiamente dicha. Sin duda, permite renovar tecnológicamente los equipos de desarrollo
Cobol haciéndoles entrar en el mundo de la Web y los sistemas abiertos. En cualquier caso, no es
viable comenzar un proyecto de este calibre sin el convencimiento y colaboración decidida de
todo el personal de desarrollo y sistemas.
A nivel municipal no hay cambios significativos. El final del proyecto no ha cambiado nada desde el
punto de vista del usuario. El éxito, por tanto, es conseguir que el usuario no note nada más allá de
incrementos en el rendimiento, todo ello tras una fase de asentamiento inicial.
4.
LAS VENTAJAS PARA EL AYUNTAMIENTO.
Ámbito económico: Se reduce el gasto corriente asociado a la explotación de los sistemas, tanto del
hardware como del software, en un porcentaje en torno al 50% anual. Este cálculo no incluye los
beneficios indirectos derivados de la utilización de protocolos estándar ya que, por ejemplo, se deja de
usar Ficon en favor de FiberChanel lo que permite utilizar cabinas de almacenamiento y librerías de
cintas estándar.
Adicionalmente, hay un menor consumo energético ya que el Ayuntamiento ha obtenido un ahorro
derivado del menor consumo energético de la nueva plataforma. Este ahorro puede cifrarse en 1.200
watios/hora aproximadamente durante las 24 horas del día, los 365 días del año. Es decir, hay una
disminución de la huella de carbono superior a los 10,5 megawatios/año.
En el ámbito tecnológico se prepara la siguiente fase de modernización tecnológica municipal
ubicando todos los sistemas sobre plataformas abiertas. Actualmente ya se tienen muchos problemas
técnicos cuando se plantean actuaciones sobre tecnología Host o DB2. Algunos ejemplos:
Hay muchas aplicaciones que no soportan DB2 sino únicamente Oracle o SQL Server. Ejemplo de
ello son el control de turnos de Qmatic, la gestión bibliotecaria,… Igualmente, se complica sobremanera
cualquier acceso desde los sistemas GIS a datos ubicados a DB2 teniendo que realizar internamente
pasos intermedios desde SQL Server a DB2 para salvar la limitación técnica.
Las integraciones de la web con el Host pasan por un elemento intermedio (Gateway IBM o DB2
Connect, según el caso) que complica la programación. Cuando los sistemas de backend no están
sobre el Host, la programación es mucho más simple y natural.
Los proveedores externos tiene más dificultades técnicas para simular un entorno como el municipal
cuando el backend reside sobre el Host. Los proveedores puede reproducir un sistema Windows o
Linux pero no un zOS. Es una mera cuestión de costes.
12
5.
EQUIPO DE DESARROLLO Y PROVEEDORES.
Un proyecto de migración de estas características conlleva un riesgo tecnológico de primer nivel dado lo
delicado de muchas de sus actuaciones. A esto hay que añadir que son más bien escasas las
referencias en las que Bilbao podía fijarse para plasmar su estrategia.
Debido a ello se ha tenido que dimensionar un equipo de trabajo formado por el personal interno de
CIMUBISA (afecta de lleno a explotación, al equipo de desarrollo y al de técnica de sistemas), ciertos
usuarios clave que actuaban como validadores de las aplicaciones, Microfocus como proveedor de la
tecnología y Hewlett Packard como integrador de todos los procesos y sistemas.
Asimismo, se ha contado con la colaboración puntual de Microsoft para la resolución de incidencias
relacionadas con el motor de base de datos utilizado, Microsoft SQL Server.
6.
VALORACIÓN ECONÓMICA.
El proyecto se ha realizado en dos fases diferenciadas, una primera denominada fase de concepto, cuyo
importe fue de 193.000 € más IVA y una segunda fase con la migración en sí misma cuyo importe fue de
417.000 € más IVA.
El coste total del proyecto, por tanto, ascendió a 610.000 € más IVA.
7.
PLAZO DE CUMPLIMIENTO.
La razón principal de la división en fases del proyecto era el riesgo tecnológico.
Se determinó la existencia de una primera fase en la que se analizaría la viabilidad técnica del proyecto
así como la planificación de su ejecución. Esta primera fase, denominada prueba de concepto, tuvo una
duración de 5 meses. Durante esta fase se analizaron varias aplicaciones y se construyó una maqueta
tecnológica que, en miniatura, contenía la totalidad de los problemas que se habían identificado como
críticos en la fase siguiente. Su finalización fue exitosa llegando a ejecutar transacciones reales sobre el
entorno construido comparando resultados con el entorno Host.
La segunda fue la fase final, la de la construcción completa y migración. Esta fase tuvo una duración de
8 meses y durante la misma se construyó el nuevo sistema, se realizó un inventario detallado a la fecha
de los objetos a migrar, se analizaron y ejecutaron los planes de migración de datos, se analizaron y
ejecutaron los planes de migración de programas, se diseñó el plan de pruebas, se realizaron las
pruebas con las consiguientes correcciones de problemas y el 7 de julio de 2014 se puso en producción
todo el sistema.
13