Estrategias de migración de aplicaciones del sistema central
Cuando la mayoría de los equipos migran aplicaciones desde entornos del sistema central a Azure, generalmente siguen un enfoque pragmático: reutilizar siempre y cuando sea posible. Posteriormente, inician una implementación por fases en la que las aplicaciones se vuelven a escribir o se reemplazan.
Normalmente, la migración de aplicaciones implica una o varias de las estrategias siguientes:
Rehospedaje: Consiste en trasladar el código, los programas y las aplicaciones existentes desde el sistema central. Recompile el código para que se ejecute en un emulador del sistema central hospedado en una instancia en la nube. Normalmente, este enfoque comienza con el traslado de las aplicaciones a un emulador basado en la nube y, después, se migra la base de datos a una base de datos en la nube. Esta estrategia requiere algunos trabajos de ingeniería y refactorización, además de las conversiones de datos y archivos.
Como alternativa, puede rehospedar mediante un proveedor de hospedaje tradicional. Una de las principales ventajas de la nube es la subcontratación de la administración de la infraestructura. Encuentre un proveedor de centro de datos que hospede sus cargas de trabajo del sistema central. Este modelo puede darle algo de tiempo, reducir el bloqueo de los proveedores y producir un ahorro de los costos intermedios.
Retirada: todas las aplicaciones que ya no son necesarias deberán retirarse antes de la migración.
Recompilación: algunas organizaciones deciden volver a escribir los programas usando técnicas modernas. Dado el costo adicional y la complejidad de este enfoque, no es tan común como una migración mediante lift-and-shift. Después de este tipo de migración, suele ser conveniente reemplazar los módulos y el código mediante motores de transformación de código.
Reemplazo: este método reemplaza la funcionalidad del sistema central por las características en la nube equivalentes. El software como servicio (SaaS) es una opción. Con Saas, va a usar una solución creada específicamente para abordar una cuestión empresarial como, por ejemplo, finanzas, recursos humanos, producción o planeamiento de recursos empresariales. Además, ahora hay disponibles muchas aplicaciones específicas del sector para resolver los problemas que antes solían resolver las soluciones personalizadas del sistema central.
Empiece por planear las cargas de trabajo que desea migrar inicialmente y, después, determine los requisitos para trasladar las aplicaciones, bases de código heredado y bases de datos asociadas.
Emulación de sistema central en Azure
Los servicios de Azure pueden emular entornos del sistema central tradicionales. Después, puede reutilizar el código y las aplicaciones del sistema central existentes. Puede emular componentes comunes del servidor, como el procesamiento de transacciones en línea (OLTP), el procesamiento por lotes y los sistemas de ingesta de datos.
Sistemas OLTP
Muchos sistemas centrales tienen sistemas OLTP que procesan miles o millones de actualizaciones para una gran cantidad de usuarios. Con frecuencia, estas aplicaciones utilizan software de procesamiento de transacciones, entrada de formularios y control de la pantalla, como los sistemas de control de información del cliente (CICS), sistemas de administración de la información (IMS) y procesadores de interfaz de terminal (TIP).
Cuando se trasladan aplicaciones de OLTP a Azure, hay disponibles emuladores de supervisión de procesamiento de transacciones (TP) de sistema central que se pueden ejecutar como infraestructura como servicio (IaaS) con máquinas virtuales en Azure. Los servidores web también pueden implementar el control de pantalla y la funcionalidad del formulario. Combine este enfoque con las API de base de datos, como los objetos de datos ActiveX (ADO), conectividad abierta de bases de datos (ODBC) y conectividad de base de datos de Java (JDBC) para las transacciones y el acceso a los datos.
Actualizaciones por lotes con restricciones de tiempo
Muchos sistemas centrales realizan actualizaciones mensuales o anuales de millones de registros de cuentas, por ejemplo, las que se utilizan en banca, seguros y administraciones públicas. Los sistemas centrales pueden trabajar con estos tipos de cargas de trabajo mediante sistemas de control de datos con alta capacidad de procesamiento. Por su diseño, los trabajos por lotes de los sistemas centrales suelen procesarse en serie y su rendimiento depende de las operaciones de entrada y salida por segundo (IOPS) que proporcione la red troncal del sistema central.
Los entornos de procesamiento por lotes en la nube usan recursos de proceso en paralelo y redes de alta velocidad para obtener un mayor rendimiento. Si necesita optimizar el rendimiento del procesamiento por lotes, Azure dispone de varias opciones de red, almacenamiento y proceso.
Sistemas de ingesta de datos
Los sistemas centrales ingieren grandes lotes de datos de soluciones de venta minorista, servicios financieros y fabricación, entre otras, para su procesamiento. Con Azure, puede usar utilidades de línea de comandos tales como AzCopy para copiar los datos en la ubicación de almacenamiento y desde esta. También puede usar el servicio Azure Data Factory para ingerir datos de diferentes almacenes de datos y para crear y programar flujos de trabajo controlados por datos.
Además de los entornos de emulación, Azure proporciona servicios de análisis y de plataforma como servicio (PaaS) que pueden mejorar los entornos de sistema central existentes.
Migración de cargas de trabajo OLTP a Azure
La migración mediante lift-and-shift permite migrar rápidamente las aplicaciones existentes a Azure sin tener que codificar. Cada aplicación se migra tal cual, lo que ofrece las ventajas de la nube sin el riesgo ni los costos que conlleva la modificación del código. Este enfoque es compatible con el uso de un emulador de supervisión de procesamiento de transacciones (TP) de sistema central en Azure.
Hay disponibles monitores de procesamiento de transacciones de varios proveedores que se ejecutan en máquinas virtuales, una opción de infraestructura como servicio (IaaS) de Azure. Los siguientes diagramas muestran el antes y después de una aplicación en línea basada en IBM DB2, un sistema de administración de bases de datos relacionales (DBMS), en un sistema central IBM z/OS. DB2 para z/OS usa archivos de método de acceso a almacenamiento virtual (VSAM) para almacenar los datos, y el método de acceso secuencial indexado (ISAM) para archivos planos. Esta arquitectura también utiliza CICS para la supervisión de transacciones.
En Azure, los entornos de emulación ejecutan el administrador de TP y los trabajos por lotes que usan JCL. En la capa de datos, DB2 se reemplaza por Azure SQL Database, aunque también se puede usar Microsoft SQL Server, DB2 LUW u Oracle Database. Un emulador admite IMS, VSAM y SEQ. Las herramientas de administración del sistema central se reemplazan por los servicios de Azure y software de otros proveedores que se ejecutan en máquinas virtuales.
Los servidores web son, normalmente, los encargados de implementar las funcionalidades de control de la pantalla y de entrada de formularios, las cuales se pueden combinar con API de base de datos tales como ADO, ODBC y JDBC para el acceso a los datos y las transacciones. La gama exacta de componentes de IaaS de Azure que usará dependerá del sistema operativo que prefiera. Por ejemplo:
Máquinas virtuales basadas en Windows: Internet Information Server (IIS) junto con ASP.NET para el control de la pantalla y la lógica de negocios. Use ADO.NET para las transacciones y el acceso a los datos.
Máquinas virtuales basadas en Linux: los servidores de aplicaciones basados en Java, como Apache Tomcat para el control de la pantalla y la funcionalidad empresarial basada en Java. Use JDBC para las transacciones y el acceso a los datos.
Migración de cargas de trabajo por lotes a Azure
En Azure, las operaciones por lotes difieren del entorno típico de procesamiento por lotes de los sistemas centrales. Por su diseño, los trabajos por lotes de los sistemas centrales suelen procesarse en serie y su rendimiento depende del valor de IOPS que proporcione la red troncal del sistema central. Los entornos de procesamiento por lotes en la nube usan recursos de proceso en paralelo y redes de alta velocidad para obtener un mayor rendimiento.
Para optimizar el rendimiento del procesamiento por lotes con Azure, considere las siguientes opciones de proceso, almacenamiento, red y supervisión.
Proceso
Uso:
Máquinas virtuales con la mayor velocidad de reloj. Las aplicaciones del sistema central suelen ser de un único subproceso y las CPU de los sistemas centrales tienen una velocidad de reloj alta.
Máquinas virtuales con gran capacidad de memoria para permitir el almacenamiento en caché de los datos y las áreas de trabajo de las aplicaciones.
Máquinas virtuales con CPU virtuales de mayor densidad para aprovechar las ventajas del procesamiento multiproceso si la aplicación lo admite.
Procesamiento paralelo, porque Azure se escala horizontalmente para el procesamiento paralelo y ofrece más capacidad de proceso para una ejecución por lotes.
Storage
Uso:
Discos SSD prémium de Azure o Almacenamiento en disco Ultra de Azure para tener el número máximo de IOPS disponible.
Creación de particiones con varios discos para tener más E/S por segundo en cada tamaño de almacenamiento.
Creación de particiones de almacenamiento, para distribuir la E/S entre varios dispositivos de Azure Storage.
Redes
- Use redes aceleradas de Azure para minimizar la latencia.
Supervisión
- Use herramientas de supervisión, Azure Monitor, Application Insights y registros de Azure. Estas herramientas le ayudan a supervisar las ejecuciones por lotes de rendimiento excesivo y a reducir los cuellos de botella.
Migración de entornos de desarrollo
Las arquitecturas de nube distribuidas se basan en un conjunto de herramientas de desarrollo diferente que aportan las ventajas que ofrecen los procedimientos y lenguajes de programación modernos. Para facilitar esta transición, use un entorno de desarrollo con otras herramientas que estén diseñadas para emular los entornos de IBM z/OS. La siguiente lista muestra las opciones de Microsoft y otros proveedores:
| Componente | Opciones de Azure |
|---|---|
| z/OS | Windows, Linux o Unix |
| CICS | Servicios de Azure ofrecidos por Micro Focus, Oracle, GT Software (Fujitsu), TmaxSoft, Raincode y NTT Data, o reescribir con Kubernetes |
| IMS | Servicios de Azure ofrecidos por Micro Focus y Oracle |
| Assembler | Servicios de Azure ofrecidos por Raincode y TmaxSoft; o COBOL, C o Java; o asignación a las funciones del sistema operativo |
| JCL | JCL, PowerShell u otras herramientas de scripting |
| COBOL | COBOL, C o Java |
| Natural | Natural, COBOL, C o Java |
| Fortran y PL/I | FORTRAN, PL/I, COBOL, C o Java |
| REXX y PL/I | REXX, PowerShell u otras herramientas de scripting |
Migración de bases de datos y datos
Normalmente, la migración de aplicaciones implica el rehospedaje de la capa de datos. Puede migrar bases de datos de SQL Server, de código abierto y otras bases de datos relacionales a soluciones totalmente administradas en Azure. Puede usar Azure SQL Managed Instance, Azure Database for PostgreSQL y Azure Database for MySQL con Azure Database Migration Service.
Por ejemplo, puede migrar si la capa de datos del sistema central usa:
IBM DB2 o una base de datos IMS; use Azure SQL Database, SQL Server, DB2 LUW u Oracle Database en Azure.
VSAM y otros archivos sin formato; use archivos planos de método de acceso secuencial indexado (ISAM) para Azure SQL Database, SQL Server, DB2 LUW u Oracle.
Grupos de fechas de generación (GDG); migre a archivos de Azure que usen una convención de nomenclatura y extensiones de nombre de archivo que proporcionen una funcionalidad similar a los GDG.
La capa de datos de IBM incluye varios componentes clave que se deben migrar también. Por ejemplo, al migrar una base de datos, migre también una colección de los datos contenidos en grupos, cada uno de los cuales contiene dbextents, que son conjuntos de datos VSAM de z/OS. La migración debe incluir el directorio que identifica las ubicaciones de los datos en los grupos de almacenamiento. Además, el plan de migración debe tener en cuenta el registro de base de datos, que contiene un registro de las operaciones realizadas en la base de datos. Una base de datos puede tener uno, dos (doble o alternativo) o cuatro (dobles y alternativos) registros.
La migración de la base de datos también incluye los siguientes componentes:
- Administrador de base de datos: proporciona acceso a los datos de la base de datos. El administrador de base de datos se ejecuta en su propia partición en un entorno de z/OS.
- Solicitante de aplicaciones: acepta las solicitudes de aplicaciones antes de pasarlas a un servidor de aplicaciones.
- Adaptador de recursos en línea: incluye componentes de solicitante de aplicaciones para su uso en transacciones CICS.
- Adaptador de recursos de procesamiento por lotes: implementa componentes de solicitante de aplicaciones para aplicaciones de procesamiento por lotes en z/OS.
- SQL interactivo (ISQL): se ejecuta como una aplicación e interfaz de CICS que permite a los usuarios escribir instrucciones SQL o comandos de operador.
- Aplicación CICS: se ejecuta bajo el control de CICS, y usa los orígenes de datos y los recursos disponibles en CICS.
- Aplicación de procesamiento por lotes: ejecuta lógica de proceso sin comunicación interactiva con los usuarios, por ejemplo, crear actualizaciones masivas de datos o generar informes de una base de datos.
Optimización de la escala y la capacidad de proceso de Azure
Por lo general, los sistemas centrales se escalan verticalmente, mientras que la nube se escala horizontalmente. Para optimizar el escalado y el rendimiento de las aplicaciones del estilo de sistema central que se ejecutan en Azure, es importante que comprenda cómo los sistemas centrales separan y aíslan las aplicaciones. Un sistema central z/OS usa una característica llamada particiones lógicas (LPAR) para aislar y administrar los recursos para una aplicación específica en una sola instancia.
Por ejemplo, un sistema central puede usar una partición LPAR para una región CICS con programas COBOL asociados y una partición LPAR independiente para DB2. A menudo se usan otros LPAR para los entornos de desarrollo, pruebas y ensayo.
En Azure, es más habitual utilizar máquinas virtuales independientes con este propósito. Normalmente, las arquitecturas de Azure implementan máquinas virtuales para la capa de aplicación, un conjunto independiente de máquinas virtuales para la capa de datos, otro conjunto para el desarrollo, y así sucesivamente. Cada nivel de procesamiento se puede optimizar con el tipo de máquinas virtuales y las características más apropiadas para ese entorno.
Además, cada nivel también puede proporcionar también los servicios de recuperación ante desastres adecuados. Por ejemplo, las máquinas virtuales de producción y base de datos pueden requerir una recuperación activa o semiactiva, mientras que las máquinas virtuales de desarrollo y pruebas permiten una recuperación pasiva.
En la siguiente ilustración se muestra una posible implementación de Azure con un sitio principal y uno secundario. En el sitio principal, las máquinas virtuales de producción, almacenamiento provisional y pruebas se implementan con alta disponibilidad. El sitio secundario es para recuperación ante desastres y copia de seguridad.
Realización de una migración preconfigurada a Azure
El traslado de soluciones de un sistema central a Azure podría implicar una migración por fases. Primero se mueven algunas aplicaciones, mientras que otras permanecen en el sistema central de forma temporal o permanente. Normalmente, este enfoque requiere sistemas que permitan que las aplicaciones y las bases de datos interactúen entre el sistema central y Azure.
Un escenario común es trasladar una aplicación a Azure y mantener en el sistema central los datos que la aplicación utiliza. Un software específico permite que las aplicaciones que se encuentran en Azure puedan acceder a los datos del sistema central. Afortunadamente, existe una amplia gama de soluciones que proporcionan la integración entre Azure y los entornos de sistema central existentes, compatibilidad con escenarios híbridos y migración con el tiempo. Los partners de Microsoft, proveedores de software independientes e integradores pueden ayudarle en camino.
Una opción es Microsoft Host Integration Server. Esta solución proporciona la arquitectura de base de datos relacional distribuida (DRDA) necesaria para las aplicaciones de Azure. Permite que las aplicaciones accedan a los datos de DB2 que permanecen en el sistema central. Otras opciones para la integración entre el sistema central y Azure son algunas soluciones de IBM, Attunity, Codit u otros proveedores, y opciones de código abierto.
Soluciones de socios
Si está considerando una migración del sistema central, el ecosistema de asociados puede ayudarle.
Azure es una infraestructura probada que ofrece alta disponibilidad y escalabilidad para los sistemas que actualmente se ejecutan en sistemas centrales. Algunas cargas de trabajo se pueden migrar con relativa facilidad. Puede volver a hospedar otras cargas de trabajo que dependen del software del sistema heredado, como CICS y IMS. Use soluciones de asociados y mígrelas a Azure con el tiempo. Independientemente de la opción que elija, Microsoft y nuestros asociados le ayudarán a optimizar su implementación en Azure, manteniendo la funcionalidad del software en el sistema central.
Más información
Para obtener más información, consulte los siguientes recursos: