El sistema central definido por software (SDM) de LzLabs reduce significativamente el riesgo y la complejidad del rehospedaje de las cargas de trabajo heredadas al eliminar la necesidad de encontrar, modificar y recompilar el código fuente de las aplicaciones heredadas. Este enfoque permite que los programas ejecutables binarios de z/Architecture funcionen a velocidades nativas en ordenadores de arquitectura x86_64 que ejecutan una pila de software de sistemas abiertos, lo que abre el camino a la modernización del legado.
Arquitectura
Descargue un archivo SVG de esta arquitectura.
Flujo de trabajo
- Se accede a las aplicaciones de LzLabs SDM igual que a las aplicaciones comunes del sistema central, a través de un terminal 3270. Puede usar cualquier emulador de terminal que quiera. Para administración y otras actividades, se usa el cliente LzWorkbench. El componente del servidor se ejecuta en la máquina virtual de SDM.
- El acceso al puerto suele configurarse para adaptarse a los requisitos de seguridad del cliente.
- Para una implementación segura de SDM, se debe implementar un front end de servicios web que consta de:
- Azure Application Gateway, para cualquier API de CICS que acceda a través de la web,
- Azure Bastion, para el acceso seguro a la administración de máquinas virtuales
- y una instancia de Azure Load Balancer.
- El SDM puede configurarse para la conmutación por error con un emparejamiento de la red virtual (VNet) a las regiones de respaldo, de recuperación ante desastres (DR) y a las regiones secundarias de Azure. Esto mejora la disponibilidad de SDM para las cargas de trabajo de producción porque Azure mantiene una réplica coherente en caso de que la máquina virtual inicial se desconecte.
- La máquina virtual de SDM en el entorno de producción se replica y se mantiene sincronizada en la región de conmutación por error mediante Azure Site Recovery. Este servicio mantiene el disco principal del sistema operativo de producción y las imágenes de disco adjuntas sincronizadas con el SDM de la región secundaria. Lo hace para todos los discos conectados, excepto el disco responsable del procesamiento de archivos de índice (consulte el punto 10). La recuperación del sitio también se utiliza para mantener todas las demás imágenes de máquinas virtuales sincronizadas con la región secundaria.
- La base de datos de esta arquitectura es IaaS de PostgreSQL. Actualmente, no se puede utilizar el servicio Azure PostgreSQL y se debe utilizar IaaS de PostgreSQL con SDM en las implementaciones. Esto se debe a una limitación de Azure PostgreSQL para procesar tipos de datos definidos por el usuario (UDT). La instancia de la base de datos en la región secundaria se mantiene al día con el registro de transacciones de escritura anticipada. Esto permite la conmutación por error entre regiones. Cuando se produce la conmutación por error, el modo se establecerá en activo. El mismo proceso se utiliza para mantener la coherencia transaccional de la base de datos de conmutación por error de producción dentro de la región de producción. Al utilizar el registro de transacciones de escritura anticipada para mantener estas dos réplicas sincronizadas, el nivel de base de datos tiene una alta disponibilidad. Nota: Para obtener el mejor rendimiento, la máquina virtual de la base de datos y la máquina virtual de SDM deben colocarse en un grupo con ubicación por proximidad de Azure.
- Es necesario implementar un front-end de servicios web para la región de recuperación ante desastres con el fin de mantener un acceso seguro al sistema. Muchas cargas de trabajo de mainframe tienen un nivel de servicios web de API para acceder a las transacciones CICS y a los datos de DB2.
- Para la integración de identidades de RACF y Top Secret mediante extensiones de Active Directory, LzVault proporciona autenticación y autorización en Azure para las reglas de seguridad migradas desde el sistema central.
- El servidor Barman se configura en la capa de datos. Esto proporciona réplicas instantáneas de la base de datos de PostgreSQL para la recuperación a un momento dado tanto en la región de producción como en la región secundaria.
- Como se mencionó en el punto 5, el disco que mantiene el procesamiento de archivos indexados para SDM debe sincronizarse entre las regiones mediante una solución de creación de reflejo de la base de datos. Esto se debe a que Azure Site Recovery no puede garantizar la coherencia de las transacciones necesarias para una base de datos. Dado que el procesamiento de archivos indexados no está dentro de PostgreSQL, se debe utilizar una solución que pueda proporcionar esto.
- Para acomodar la programación del procesamiento de trabajos por lotes, se debe utilizar un programador como Azure Logic Apps o SMA.
- Para proporcionar disponibilidad, hay dos máquinas virtuales de SDM implementadas en un conjunto de disponibilidad de Azure. Azure Load Balancer proporciona servicios de equilibrio de carga a las dos máquinas virtuales. El estado se comparte entre las dos máquinas virtuales mediante un disco compartido de Azure. Esto se replica a través de DRDB en la instancia de recuperación ante desastres.
Componentes
- Las máquinas virtuales de Azure son uno de los varios tipos de recursos informáticos escalables y bajo demanda que ofrece Azure. Una máquina virtual de Azure le ofrece la flexibilidad de la virtualización sin necesidad de adquirir y mantener el hardware físico que la ejecuta.
- Las redes virtuales (VNet) son los bloques de creación básicos de una red privada en Azure Virtual Network. La red virtual permite que muchos tipos de recursos de Azure, incluidas las máquinas virtuales, se comuniquen de forma segura entre sí, con Internet y con las redes locales. La red virtual es similar a una red tradicional de las que usaría en su propio centro de datos, pero aporta las ventajas adicionales de la infraestructura de Azure, como escalado, disponibilidad y aislamiento.
- La interfaz de red virtual de Azure (NIC) es una interfaz de red que permite a una máquina virtual de Azure comunicarse con Internet, con otros recursos de Azure y con recursos locales. Como se muestra en esta arquitectura, puede agregar más tarjetas de interfaz de red a la misma máquina virtual, lo que permite que las máquinas virtuales secundarias Solaris tengan sus propios dispositivos de interfaz de red y direcciones IP dedicados.
- Los discos administrados SSD de Azure son volúmenes de almacenamiento de nivel de bloque que administra Azure y que se utilizan con máquinas virtuales de Azure. Los tipos de discos disponibles son Disco Ultra, SSD prémium, SSD estándar y unidades de disco duro (HDD) estándar. Para esta arquitectura, se recomiendan SSD Premium o SSD Ultra.
- Azure Storage y Azure Files ofrecen recursos compartidos de archivos totalmente administrados en la nube a los que se puede acceder a través del protocolo Bloque de mensajes del servidor (SMB) estándar del sector. Los recursos compartidos de Azure se pueden montar simultáneamente en implementaciones de Windows, Linux y macOS en la nube o locales.
- Azure ExpressRoute permite ampliar las redes locales en la nube de Microsoft a través de una conexión privada que facilita un proveedor de conectividad. Con ExpressRoute, se pueden establecer conexiones con servicios en la nube de Microsoft, como Microsoft Azure y Office 365.
- Azure SQL Database es un motor de base de datos de plataforma como servicio (PaaS) totalmente administrado que se encarga de la mayoría de las funciones de administración de bases de datos sin intervención del usuario, como actualizar, aplicar revisiones, crear copias de seguridad y supervisar. Azure SQL Database se ejecuta siempre en la última versión estable del motor de base de datos de SQL Server y en un sistema operativo revisado con el 99,99 por ciento de disponibilidad. Las capacidades de PaaS que están integradas en Azure SQL Database permiten centrarse en las actividades de administración y optimización de bases de datos específicas del dominio que son críticas para el negocio.
Detalles del escenario
LzLabs Software Defined Mainframe (SDM) es una plataforma de rehospedaje de cargas de trabajo y modernización de aplicaciones del sistema central. SDM permite que las aplicaciones heredadas del sistema central se ejecuten en sistemas abiertos sin necesidad de cambiar el código fuente, recompilar o convertir los tipos de datos. SDM también cuenta con características que permiten modernizar las aplicaciones heredadas a lenguajes e implementaciones contemporáneas, sin comprometer la integridad o el funcionamiento del sistema en su conjunto.
SDM reduce significativamente el riesgo y la complejidad del rehospedaje de las cargas de trabajo heredadas al eliminar la necesidad de encontrar, modificar y recompilar el código fuente de las aplicaciones heredadas. Este enfoque permite que los programas ejecutables binarios de z/Architecture funcionen a velocidades nativas en ordenadores de arquitectura x86_64 que ejecutan una pila de software de sistemas abiertos, lo que abre el camino a la modernización del legado.
Posibles casos de uso
- Sin código fuente LzLabs es una solución para los clientes que tienen cargas de trabajo del sistema central pero no tienen el código fuente de las aplicaciones en ejecución. Esto puede ocurrir si la solución era una solución comercial (COTS) personalizable comprada a un proveedor de software independiente que no tenía el código fuente de la dirección IP. Además, como muchas de estas aplicaciones basadas en COBOL se escribieron hace tiempo, el código fuente podría haberse perdido o extraviado. LzLabs resuelve este problema porque todo lo que se necesita son los módulos de carga (binarios) para su ejecución en SDM.
- El cliente tiene el código fuente y quiere rehospedarlo. Es posible que el cliente siga teniendo el código fuente y simplemente quiera rehospedar sus cargas de trabajo del sistema central para reducir el costo y disfrutar de las ventajas de una plataforma en la nube como Azure. El código COBOL puede mantenerse en SDM en un entorno DevOps moderno.
- Conmutación por error. Para aumentar el tiempo de actividad y evitar posibles interrupciones en la continuidad del negocio, los clientes pueden utilizar LzLabs SDM para un entorno de conmutación por error. En este caso, los módulos de carga se cargan en el SDM y se utilizan como entorno secundario si el entorno de producción no está disponible.
Consideraciones
Las consideraciones siguientes, basadas en el Marco de buena arquitectura de Microsoft Azure, se aplican a esta solución:
Disponibilidad
La disponibilidad para la capa de aplicación se proporciona con Site Recovery, tal como se muestra en el diagrama. Dado que LzLabs SDM aprovecha PostgreSQL para la capa de base de datos, la disponibilidad se proporciona con un registro de transacciones de escritura anticipada. Esto asegura que la base de datos secundaria es transaccionalmente coherente con la base de datos de producción.
Operaciones
El entorno de Azure del diagrama se administra con Azure Portal o los scripts y las plantillas de Azure Resource Manager (ARM). Esto permite administrar los recursos (como el cambio de tamaño) y administrar la seguridad y el acceso. La administración del entorno real de SDM se lleva a cabo mediante la herramienta de administración LzWorkbench. Esto permite la creación y administración de entornos de ejecución en SDM.
Eficiencia del rendimiento
Al migrar cargas de trabajo del sistema central a Azure, tenga en cuenta que la relación de MIPS por vCPU oscila entre 50 y 150 MIPS por vCPU. Esto puede variar en función del tipo de carga de trabajo. Deberá crear perfiles de la carga de trabajo del sistema central para los entornos en línea y por lotes, y después cambiar el tamaño de los recursos en consecuencia.
Escalabilidad
Actualmente, la solución para escalar SDM es escalar verticalmente las máquinas virtuales agregando más vCPU y memoria.
Seguridad
El acceso a los recursos de Azure se administra mediante Azure Portal o Azure Resource Manager. La seguridad de SDM se administra mediante el componente Vault de SDM. Este componente migra la seguridad y los permisos de RACF o Top Secret a un entorno basado en LDAP para su administración en Azure.
Optimización de costos
Para calcular el costo de los productos y configuraciones de Azure, visite la calculadora de precios de Azure.
Para obtener más información sobre los precios de los productos LzLabs Software Defined Mainframe y sus servicios relacionados, visite el sitio web de LzLabs.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Jonathon Frost | Ingeniero principal de software
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Para más información, póngase en contacto con legacy2azure@microsoft.com.
Consulte los siguientes recursos de LzLabs:
- Sitio web de LzLabs
- Introducción al producto LzLabs Software Defined Mainframe
- LzWorkbench
- Biblioteca de vídeos de LzLabs
Consulte la siguiente documentación de Microsoft:
- Máquinas virtuales en Azure
- Documentación de Azure Virtual Network
- Documentación sobre plantillas de Azure Resource Manager
- Documentación de Azure ExpressRoute
- Documento técnico: Desmitificación de la migración de un sistema central a Azure
- Migración del sistema central en Azure Migration Center
- Información general sobre la migración del sistema central
- Cargas de trabajo del sistema central que se admiten en Azure
- Rehospedaje del sistema central en Azure Virtual Machines
Recursos relacionados
Consulte los siguientes artículos relacionados del Centro de arquitectura de Azure: