Editar

Compartir vía


Refactorización de sistemas centrales que ejecutan Adabas y Natural

Azure Kubernetes Service (AKS)
Azure ExpressRoute
Azure Managed Disks
Azure NetApp Files

Software AG proporciona una popular plataforma de sistema central 4GL basada en el lenguaje de programación Natural y la base de datos Adabas. En este artículo se proporciona una arquitectura para las organizaciones que usan sistemas centrales que ejecutan Adabas & Natural y que buscan formas de modernizar estas cargas de trabajo y moverlas a la nube.

Arquitectura de sistema central

En este diagrama se muestra un ejemplo de un sistema central con los módulos de Adabas & Natural de Software AG instalados, antes de la migración a Azure. En este ejemplo se muestra una arquitectura IBM z/OS.

Diagrama que muestra una arquitectura de sistema central que usa Adabas & Natural de Software AG, antes de la migración a Azure.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

A. La entrada se produce a través de TCP/IP, incluidos TN3270 y HTTP(S). La entrada en el sistema central usa protocolos de sistema central estándar.

B. Las aplicaciones receptoras pueden ser sistemas por lotes o en línea.

C. Natural, COBOL, PL/I, Assembler y otros lenguajes compatibles se ejecutan en un entorno habilitado.

D. Los servicios de datos y bases de datos que se usan normalmente son sistemas jerárquicos o de base de datos de red y tipos de bases de datos relacionales.

E. Entre los servicios comunes se incluyen la ejecución de programas, las operaciones de E/S, la detección de errores y la protección dentro del entorno.

F. El middleware y las utilidades administran servicios como el almacenamiento en cinta, la puesta en cola, la salida y los servicios web dentro del entorno.

G. Los sistemas operativos proporcionan la interfaz entre el motor y el software que ejecuta.

H. Se necesitan particiones para ejecutar cargas de trabajo independientes y para separar los tipos de trabajo dentro del entorno.

Arquitectura de Azure

En este diagrama se muestra cómo puede migrar la arquitectura heredada a Azure mediante un enfoque de refactorización para modernizar el sistema:

Diagrama que muestra la arquitectura heredada tras la migración a Azure.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  1. Entrada. Normalmente, la entrada se produce a través de Azure ExpressRoute desde clientes remotos o mediante otras aplicaciones que ejecutan actualmente Azure. En cualquiera de los casos, las conexiones TCP/IP son la forma principal de conectarse al sistema. El puerto TLS 443 proporciona acceso a las aplicaciones basadas en web. Puede dejar la capa de presentación de las aplicaciones basadas en web prácticamente sin cambios para minimizar el reentrenamiento de los usuarios. Como alternativa, puede actualizar esta capa con marcos de experiencia de usuario modernos según sus necesidades. Para el acceso de administrador a las máquinas virtuales, puede usar los hosts de Azure Bastion para maximizar la seguridad reduciendo el número de puertos abiertos.

  2. Acceso en Azure. En Azure, el acceso a los clústeres de proceso de aplicaciones se produce a través de un equilibrador de carga de Azure. Este enfoque permite escalar horizontalmente los recursos de proceso para procesar el trabajo de entrada. Puede usar los equilibradores de carga de nivel 7 (nivel de aplicación) o de nivel 4 (nivel de protocolo de red). Sin embargo, el tipo de equilibrador de carga que use dependerá de cómo la entrada de la aplicación alcance el punto de entrada del clúster de proceso. Se recomienda usar Azure Application Gateway con funcionalidades de firewall de aplicaciones web para el tráfico de nivel 7.

  3. Clústeres de proceso de aplicaciones. La arquitectura admite aplicaciones que se ejecutan en un contenedor que se pueden implementar en Azure Kubernetes Service (AKS). Los componentes de Adabas & Natural se pueden ejecutar dentro de contenedores basados en Linux. Puede volver a diseñar las aplicaciones heredadas como arquitecturas modernas basadas en contenedores y trabajar sobre AKS.

  4. Emulación del terminal de ApplinX (Software AG). ApplinX es una tecnología basada en servidor que proporciona conectividad web e integración en aplicaciones principales del sistema sin necesidad de cambios en las aplicaciones. Natural Online permite a los usuarios en línea conectarse a aplicaciones de Natural mediante un explorador web. Sin ApplinX, los usuarios deben conectarse con el software de emulación de terminal mediante SSH. Ambos sistemas se ejecutan en contenedores.

  5. EntireX (Software AG). EntireX permite conectar fácilmente servicios que se ejecutan en Integration Server a programas críticos escritos en lenguajes como COBOL y Natural. Natural Business Services permite el acceso mediante API a funciones empresariales programadas en Natural. Ambos sistemas se ejecutan en contenedores.

  6. Adabas (Software AG). Adabas es un sistema de administración de bases de datos NoSQL de alto rendimiento. Natural Batch (Software AG) es un componente dedicado para ejecutar trabajos por lotes. Los trabajos por lotes de Natural, programados por el sistema de programación de trabajos por lotes que elija, deben ejecutarse en el mismo nodo que la base de datos de Adabas para evitar que el rendimiento se vea afectado.

  7. Almacenamiento. Los servicios de datos usan una combinación de almacenamiento de alto rendimiento (SSD Ultra/Premium), almacenamiento de archivos (NetApp) y almacenamiento estándar (blob, archivo, copia de seguridad) que puede tener redundancia local o redundancia geográfica, en función del uso. Los sistemas operativos de nodo usan almacenamiento en disco administrado. Todos los datos persistentes, como archivos de base de datos, registros de protección, datos de aplicación y copia de seguridad, usan Azure NetApp Files. AKS administra los volúmenes del sistema operativo que se almacenan en discos administrados. Todos los datos críticos para la empresa de las bases de datos, incluidos los archivos ASSO, DATA y WORK, y los registros de protección de Adabas, deben escribirse en distintos volúmenes en Azure NetApp Files.

  8. CONNX. El módulo CONNX para Adabas proporciona acceso de lectura y escritura en tiempo real muy seguro a los orígenes de datos de Adabas en OS/390, z/OS, VSE, Linux, Solaris, HP-UX, AIX y Windows a través de .NET, ODBC, OLE DB y JDBC. CONNX proporciona una capa de virtualización de datos que utiliza conectores a Adabas y otros orígenes de datos como Azure SQL Database, Azure Database for PosgreSQL y Azure Database for MySQL.

Componentes

  • Azure ExpressRoute amplía las redes locales a la nube de Microsoft a través de una conexión privada que facilita un proveedor de conectividad. Puede usar ExpressRoute para establecer conexiones con servicios en la nube de Microsoft, como Azure y Office 365. Como alternativa, o como copia de seguridad, puede establecer conexiones con Azure VPN Gateway. Sin embargo, se recomienda usar ExpressRoute para que pueda conectarse al entorno de Azure a través de una conexión privada de alta velocidad de seguridad mejorada.

  • AKS es un servicio de Kubernetes totalmente administrado para la implementación y la administración de aplicaciones contenedorizadas. AKS proporciona Kubernetes sin servidor, integración continua y entrega continua (CI/CD) integradas, así como seguridad y gobernanza de nivel empresarial. En este escenario, los contenedores de Adabas & Natural se implementan en AKS.

  • Los discos administrados de Azure son volúmenes de almacenamiento de nivel de bloque que administra Azure y que se usan con Azure Virtual Machines. Hay varios tipos disponibles: discos Ultra, SSD Premium, SSD estándar y HDD estándar. En esta arquitectura se usan discos SSD. En este escenario, todos los volúmenes del sistema operativo se almacenan en discos administrados de Azure.

  • Azure NetApp Files proporciona recursos compartidos de archivos de Azure de nivel empresarial con tecnología de NetApp. Azure NetApp Files facilita la migración y la ejecución de aplicaciones complejas basadas en archivos sin cambios en el código. En este escenario, todos los datos persistentes, como archivos de base de datos, registros de protección, datos de aplicación y archivos de copia de seguridad, usan Azure NetApp Files.

Detalles del escenario

Las aplicaciones que se ejecutan en sistemas centrales han sido el núcleo de la mayoría de las operaciones empresariales durante casi 50 años. Aunque estos sistemas centrales han proporcionado una confiabilidad notable a lo largo de los años, se han vuelto un poco problemáticos porque son rígidos y, en algunos casos, difíciles de mantener y costosos de operar.

Muchas organizaciones buscan formas de modernizar estos sistemas. Persiguen maneras de liberar los recursos restringidos que son necesarios para mantener estos sistemas, controlar sus costos y adquirir una mayor flexibilidad en las interacciones con los sistemas.

Software AG proporciona una popular plataforma de sistema central 4GL basada en el lenguaje de programación Natural y la base de datos Adabas.

Hay dos patrones de racionalización de la nube que le permiten ejecutar aplicaciones de Adabas & Natural en Azure: rehospedaje y refactorización. En este artículo se describe cómo refactorizar una aplicación mediante contenedores administrados en AKS. Para más información, consulte Enfoque basado en contenedores más adelante en este artículo.

Posibles casos de uso

Esta arquitectura se aplica a cualquier organización que use sistemas centrales que ejecuten Adabas & Natural y que planee modernizar estas cargas de trabajo y moverlas a la nube.

Consideraciones

Enfoque basado en contenedores

Para aprovechar al máximo la flexibilidad, la confiabilidad y las funcionalidades de Azure, es necesario rediseñar las aplicaciones de sistema central. Se recomienda volver a escribir aplicaciones monolíticas como microservicios y usar un enfoque basado en contenedores para la implementación. Un contenedor agrupa todo el software necesario para la ejecución en un paquete ejecutable. Incluye el código de una aplicación junto con los archivos de configuración, las bibliotecas y las dependencias relacionados necesarios para ejecutar la aplicación. Las aplicaciones contenedorizadas son rápidas de implementar y admiten prácticas DevOps conocidas, como la integración continua (CI) y la implementación continua (CD).

Los contenedores de Adabas & Natural se ejecutan en pods, cada uno de los cuales realiza una tarea específica. Los pods son unidades de uno o varios contenedores que permanecen juntos en el mismo nodo y comparten recursos como el nombre de host y la dirección IP. Dado que están desacoplados de la plataforma subyacente, los componentes de los pods se escalan de forma independiente y admiten una mayor disponibilidad. Una aplicación contenedorizada también es portátil: se ejecuta de forma uniforme y sistemática en cualquier infraestructura.

Los servicios contenedorizados y sus componentes de red y almacenamiento asociados deben estar orquestados y administrados. Se recomienda AKS, un servicio de Kubernetes administrado que automatiza la administración de clústeres y recursos. Designe el número de nodos que necesita y AKS ajustará los contenedores a los nodos adecuados para hacer el mejor uso de los recursos. AKS también admite lanzamientos y reversiones automatizados, detección de servicios, equilibrio de carga y orquestación del almacenamiento. Además, AKS admite la recuperación automática: si se produce un error en un contenedor, AKS inicia uno nuevo. Además, puede almacenar secretos y opciones de configuración fuera de los contenedores de forma segura.

En el diagrama de arquitectura de este artículo se muestra una implementación basada en contenedores de Adabas & Natural. Al configurar AKS, se especifica el tamaño de máquina virtual de Azure para los nodos, que define las CPU de almacenamiento, la memoria y el tipo, como las unidades de estado sólido (SSD) de alto rendimiento o las unidades de disco duro normales (HDD). Natural debe ejecutarse en tres o más instancias de máquina virtual (nodos) para aumentar la escalabilidad y la disponibilidad de la interfaz de usuario (Natural Online más ApplinX) y la capa de API (servicios de Natural más EntireX).

En la capa de datos, Adabas se ejecuta en el clúster de AKS, que se escala y reduce horizontalmente de forma automática en función del uso de recursos. Puede ejecutar varios componentes de Adabas en el mismo pod o, para mayor escala, AKS puede distribuirlos entre varios nodos del clúster. Adabas usa Azure NetApp Files, un servicio de almacenamiento de archivos de uso medido y alto rendimiento, para todos los datos persistentes, como archivos de base de datos, registros de protección, datos de aplicaciones y copias de seguridad.

Coloque pods por lotes de Natural en la misma zona de disponibilidad (centro de datos) que los pods de Adabas. Debe usar grupos de selección de ubicación de proximidad para colocar los pods por lote de Adabas y Natural en el mismo grupo de nodos dentro de la misma zona de disponibilidad.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Esta arquitectura se basa principalmente en Kubernetes, que incluye componentes de seguridad, como estándares de seguridad de pod y secretos. Azure proporciona características adicionales, como Microsoft Entra ID, Microsoft Defender para contenedores, Azure Policy, Azure Key Vault, grupos de seguridad de red y actualizaciones de clústeres orquestadas. Los contenedores refactorizados se deben implementar en un clúster de AKS privado con acceso entrante a través de un servidor de API privado y direcciones IP internas. Todo el tráfico saliente debe enrutarse a través de una capa de firewall de salida.

Optimización de costos

La optimización de costes trata de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

La refactorización admite una adopción más rápida de la nube. También promueve la adopción de DevOps y los principios de trabajo de Agile. Usted dispone de total flexibilidad en las opciones de implementación de desarrollo y producción.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Kubernetes proporciona escalabilidad automática de clústeres. Esta funcionalidad ajusta el número de nodos según los recursos de proceso solicitados en el grupo de nodos. Cada 10 segundos supervisa el servidor de API de métricas por si fuera necesario cambiar el número de nodos. Si la escalabilidad automática del clúster determina que es necesario un cambio, el número de nodos del clúster de AKS aumenta o disminuye en consecuencia. 

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

  • Marlon Johnson | TPM sénior

Colaborador:

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.

Estos son algunos recursos adicionales: