Proyecto Migración HOST

Transcripción

1 Proyecto Migración HOST CIMUBISA CIMUBISA Departamentos Ayuntamiento Desarrollo de Bilbao y Sistemas Ayuntamiento de Bilbao 01/01/ /01/2014

2 INDICE 1. Antecedentes 3 Principal problema: el coste 3 Problema adicional: la tecnología 3 Formas de abordar el problema 6 Volumetría 6 Arquitectura técnica 6 Situación Anterior: 7 Situación Actual: 7 Coste de Oportunidad. Escenario de NO migración Objeto del proyecto Implicaciones Las ventajas para el Ayuntamiento Equipo de Desarrollo y Proveedores Valoración económica Plazo de cumplimiento. 13 2

3 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 4

5 El declive del entorno Host en favor de otras plataformas es evidente en las gráficas. 5

6 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 (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

7 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

8 En cuanto al desarrollo de aplicaciones, todas las herramientas de desarrollo del entorno Host han desaparecido en favor del IDE de Visual Studio 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 la diferencia de costes de una y otra plataforma será la que se plasma en la gráfica siguiente: 8

9 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

10 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

11 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 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

12 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 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

13 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 más IVA y una segunda fase con la migración en sí misma cuyo importe fue de más IVA. El coste total del proyecto, por tanto, ascendió a 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