Migración de aplicaciones de WebSphere a máquinas virtuales de Azure

En este artículo se describe lo que hay que tener en cuenta si desea migrar una aplicación de WebSphere Application Server (WAS) tradicional existente para que se ejecute en máquinas virtuales de Azure. Para obtener una introducción a las soluciones tradicionales de WAS disponibles en Azure Marketplace, consulte ¿Cuáles son las soluciones para ejecutar la familia de productos IBM WebSphere en Azure?

Antes de la migración

Para asegurarse de que la migración se realiza correctamente, antes de empezar, complete los pasos de evaluación e inventario descritos en las secciones siguientes.

Definición del significado de "migración completa"

Esta guía, y las ofertas de Azure Marketplace correspondientes, son un punto de partida para acelerar la migración de las cargas de trabajo tradicionales de WAS a Azure. Es importante definir el ámbito del trabajo de migración. Por ejemplo, ¿está realizando una migración lift-and-shift estricta de la infraestructura existente a Azure Virtual Machines? Si es así, es posible que se sienta la tentación de realizar algunas mejoras mientras realiza la migración.

Es mejor mantenerse lo más cerca posible de un «lift and shift» puro, teniendo en cuenta los cambios necesarios, tal como se detallan en esta guía. Defina lo que quiere decir con "migración completa" para que sepa cuándo ha alcanzado el objetivo. Cuando haya completado la migración, puede crear una instantánea de sus máquinas virtuales, como se describe en Crear una instantánea de un disco duro virtual. Una vez que hayas comprobado que puedes restaurar correctamente a partir de la instantánea, podrás introducir las mejoras sin temor a perder el progreso de la migración alcanzado hasta ese momento.

Asegúrese de que el destino es el adecuado para su esfuerzo de migración

El primer paso para migrar una aplicación WAS a Azure con éxito es seleccionar el destino de migración más adecuado.

WAS tradicional funciona bien en máquinas virtuales Azure. El destino de la máquina virtual (VM) es la opción más fácil, ya que se asemeja más a una implementación local. La experiencia administrativa y de implementación de las máquinas virtuales es similar a la de las instalaciones locales.

Otra opción es migrar a contenedores convirtiendo la carga de trabajo tradicional de WAS en contenedores de aplicaciones. Puede ejecutar el destino de contenedor en Azure Kubernetes Service (AKS) y Red Hat OpenShift en Azure. El inconveniente de esta facilidad es el coste económico.

En general, el coste por minuto de una solución basada en VM es mayor en comparación con los contenedores. Mientras que una solución basada en contenedores cuesta menos de ejecutar, debe restringir su aplicación para que se ajuste a los requisitos de la plataforma de orquestación de contenedores.

Si minimizar el cambio es el factor más importante para su esfuerzo de migración, considere una migración basada en máquinas virtuales. En este caso, consulte Migrar aplicaciones de WebSphere a Azure Virtual Machines.

Si puede tolerar convertir su aplicación para que se ejecute dentro de contenedores para reducir el coste del tiempo de ejecución, considere una migración basada en AKS o en Red Hat OpenShift en Azure.

Para la migración basada en AKS, puede empezar utilizando el nivel gratis. Obtenga una gestión de clúster gratuita y pague únicamente por las máquinas virtuales, el almacenamiento asociado y los recursos de conexión de red consumidos. En este caso, consulte Migrar aplicaciones de WebSphere a Azure Kubernetes Service.

Para la migración basada en Red Hat OpenShift en Azure, además de los costes de computación e infraestructura, los nodos de aplicación tienen otro coste por el componente de licencia de OpenShift. Este coste se factura en función del número de nodos de aplicación y del tipo de instancia. Utilice precios bajo demanda o instancias reservadas, según lo que mejor se adapte a las necesidades de su carga de trabajo y su empresa. En este caso, consulte Migrar aplicaciones de WebSphere a Red Hat OpenShift en Azure.

Las guías prácticas de la documentación de Red Hat OpenShift en Azure cubren algunos aspectos relevantes para la migración. Para obtener la lista completa de guías paso a paso, consulte la documentación de Red Hat OpenShift en Azure.

Determinación de si las ofertas de Azure Marketplace preconfiguradas son un buen punto de partida

IBM y Microsoft se han asociado para incorporar a Azure Marketplace un conjunto de plantillas de soluciones de Azure que ofrecen un punto de partida sólido para la migración a Azure. Para ver la lista de ofertas, consulte Ejecute la familia de productos WebSphere y Liberty en Microsoft Azure y, a continuación, elija la que mejor se ajuste a su implementación actual. Puede consultar la lista de ofertas en el artículo de información general ¿Qué soluciones hay para ejecutar la familia de productos IBM WebSphere en Azure?

Si ninguna de las ofertas existentes es un buen punto de partida, tendrá que reproducir la implementación a mano con los recursos de Azure Virtual Machines. Puede encontrar las instrucciones paso a paso en Tutorial: Instalar manualmente IBM WebSphere Application Server Network Deployment tradicional en máquinas virtuales de Azure. Para más información, consulte ¿Qué es IaaS?

Determinación de si la versión de WAS tradicional es compatible

La versión existente de WAS traditional debe ser compatible con la versión de las ofertas de IaaS. Puede encontrar la información de la versión en la página de información general de IBM WebSphere Application Server Single Instance en una máquina virtual de Azure y IBM WebSphere Application Server Cluster en máquinas virtuales de Azure. Si la versión WAS tradicional existente no es compatible con esa versión, tendrá que reproducir la implementación a mano con los recursos de IaaS de Azure. Para más información, consulte ¿Qué es IaaS?

Capacidad del servidor de inventario

Documente el hardware (memoria, CPU, disco) de los servidores de producción actuales, así como el promedio y máximo del número de solicitudes y el uso de recursos. Esta información se utilizará para elegir el tamaño de las máquinas virtuales. Para obtener más información, consulte Tamaños para Cloud Services.

Inventariar todos los secretos

Antes de la llegada de las tecnologías de "configuración como servicio", como Azure Key Vault, no había un concepto bien definido de "secretos". En su lugar, tenías un conjunto heterogéneo de opciones de configuración que, en la práctica, funcionaban como lo que hoy llamamos "secretos". Con los servidores de aplicaciones como WAS, estos secretos se encuentran en muchos archivos y almacenes de configuración diferentes. Revise todos los archivos de propiedades y de configuración del/los servidor(es) de producción en busca de secretos y contraseñas. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. WAS almacena los datos de configuración en varios documentos en una jerarquía de directorios en cascada. La mayoría de los documentos de configuración tienen contenido XML. Para obtener más información, vea Documentos de configuración y Conceptos básicos de Azure Key Vault.

Inventario de todos los certificados

Documente todos los certificados usados para los puntos de conexión SSL públicos. Para ver todos los certificados de los servidores de producción, ejecute el siguiente comando:

keytool -list -v -keystore <path to keystore>

Para obtener más información, consulte el documento de IBM Gestión de certificados en SSL

Comprobación de que la versión compatible de Java funciona correctamente

El uso de WAS en máquinas virtuales de Azure requiere una versión específica de Java, por lo que deberá confirmar que la aplicación se ejecuta correctamente con esa versión compatible.

IBM Java 8 incluye la distribución WAS9. Se recomienda usar java JRE proporcionado por IBM. Para obtener más información, consulte Java SE 8 en WebSphere Application Server traditional V9.

Si desea cambiar a otro SDK de Java, siga el documento de IBM Cambiar el SDK de Java en WebSphere Application Server.

Inventario de los recursos de JNDI

Realice un inventario de todos los recursos de JNDI. Por ejemplo, las fuentes de datos, como las bases de datos, pueden tener un nombre JNDI asociado que permite a JPA vincular correctamente instancias de a una base de datos concreta. Para obtener más información sobre los recursos JNDI y las bases de datos, consulte WebSphere Data Sources en la documentación de IBM. Otros recursos relacionados con JNDI, como los agentes de mensajes JMS, pueden requerir una migración o reconfiguración. Para obtener más información sobre la configuración de JMS, consulte Uso de recursos JMS.

Inspeccione la configuración de su perfil

La principal unidad de configuración en WAS es el perfil. Como tal, el archivo resources.xml contiene una gran cantidad de configuración que debe considerar cuidadosamente para la migración. El archivo incluye referencias a más archivos XML que se almacenan en subdirectorios. IBM aconseja que normalmente use la Consola de IBM para configurar los objetos y servicios administrables de WAS, y permita que WAS mantenga la carpeta profiles/profile-name. Para obtener más información, consulte Gestión de perfiles en sistemas operativos distribuidos e IBM i.

En tu aplicación

Inspeccione el archivo deployment.xml o el archivo WEB-INF/web.xml.

Determinación de si se usa la replicación de sesión

Si su aplicación depende de la replicación de sesiones, dispone de las siguientes opciones:

• Para las sesiones HTTP, en función del nivel de gestión de sesiones, puede utilizar la memoria o una base de datos para almacenar los datos de sesión.
• Para sesiones distribuidas, puede guardar las sesiones en una base de datos mediante la persistencia de sesiones en base de datos.
• Para caché dinámica, puede administrar los datos de sesión mediante replicación de memoria a memoria o en una base de datos.
• Refactorice la aplicación para utilizar una base de datos para la administración de sesiones.
• Refactorice la aplicación para externalizar la sesión en el servicio Azure Redis. Para más información, consulte Azure Cache for Redis.

Para todas estas opciones, es una buena idea dominar cómo WAS realiza la replicación del estado de sesión HTTP. Para obtener más información, consulte Administración de beans de sesión en la documentación de IBM.

Orígenes de datos del documento

Si su aplicación usa bases de datos, debe capturar la siguiente información:

• ¿Cuál es el nombre del origen de datos?
• ¿Cuál es la configuración del grupo de conexiones?
• ¿Dónde puedo encontrar el archivo JAR del controlador JDBC?

Para obtener más información sobre los controladores JDBC en WAS, consulte Uso de controladores JDBC con WebSphere Application Server.

Determine si se ha personalizado WAS

Determine cuáles de las siguientes personalizaciones se han realizado y registre lo que se ha hecho.

• ¿Se han cambiado los scripts de inicio? Estos scripts incluyen wsadmin, AdminControl, AdminConfig, AdminApp y AdminTask.
• ¿Se han pasado parámetros específicos a JVM?
• ¿Se han agregado archivos JAR a la ruta de clases del servidor?
• ¿Se han utilizado mecanismos a nivel del sistema operativo, como , para que los componentes de WAS se inicien automáticamente tras reiniciar el servidor?

Debe tener en cuenta las consideraciones de migración en función de las respuestas a estas preguntas.

Determinación de si se necesita una conexión al entorno local

Si su aplicación necesita acceder a cualquiera de los servicios locales, deberá aprovisionar uno de los servicios de conectividad de Azure. Para obtener más información, consulte Conectar una red local a Azure. Como alternativa, será necesario refactorizar la aplicación para usar las API públicas que exponen sus recursos de la infraestructura local.

Determinación de si las colas o los temas de Java Message Service (JMS) están en uso

Si su aplicación utiliza colas o temas JMS, debe migrarlos a un servidor JMS alojado externamente. Una estrategia para aquellos que utilizan JMS es utilizar Azure Service Bus y el protocolo Advanced Message Queuing Protocol. Para obtener más información, consulte Uso de Java Message Service 1.1 con Azure Service Bus estándar y AMQP 1.0.

Si ha configurado almacenes persistentes JMS, debe capturar su configuración y aplicarla después de la migración.

Si usa IBM MQ, puede migrar este software a máquinas virtuales de Azure y utilizarlo tal cual.

Microsoft dispone de una solución para integrar IBM MQ con Logic Apps. Para obtener más información, consulte Conectarse a un servidor de IBM MQ desde un flujo de trabajo en Azure Logic Apps.

Determinación de si usa sus propias bibliotecas de Java EE compartidas personalizadas

Si utiliza la característica de biblioteca de Java EE compartida, tiene dos opciones:

• Refactorizar el código de la aplicación para quitar todas las dependencias de las bibliotecas y, en su lugar, incorpore la funcionalidad directamente a la aplicación.
• Agregar las bibliotecas a la ruta de clases del servidor.

Determinar si se utilizan bundles OSGi

Si ha utilizado bundles OSGi añadidos al WAS, deberá añadir los archivos JAR equivalentes directamente a su aplicación web.

Determinación de si la aplicación contiene código específico del sistema operativo

Si la aplicación contiene código con dependencias en el sistema operativo del host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, es posible que tenga que reemplazar cualquier uso de o en las rutas del sistema de archivos por o si su aplicación se ejecuta en Windows.

Determine si se está utilizando IBM Integration Bus

Si su aplicación utiliza IBM Integration Bus, debe capturar cómo está configurado IBM Integration Bus. Para obtener más información, consulte la documentación de IBM Integration Bus.

Determinación de si la aplicación se compone de varios WAR

Si la aplicación se compone de varios WAR, debe tratar cada uno como aplicaciones independientes y seguir esta guía para cada una de ellas.

Determinación de si la aplicación está empaquetada como EAR

Si su aplicación está empaquetada como un archivo EAR, asegúrese de examinar los archivos application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi y capturar sus configuraciones. Para obtener más información, consulte Creación del paquete Enterprise Archive (EAR) en WebSphere.

Identifique todos los procesos externos y demonios que se ejecutan en los servidores de producción

Si tiene procesos que se ejecutan fuera del servidor de aplicaciones, como demonios de monitorización, tendrá que eliminarlos o migrarlos a otro entorno.

Determinación de si se usa el sistema de archivos y cómo

Los sistemas de archivos de las máquinas virtuales funcionan de la misma manera que los sistemas de archivos locales en cuanto a la persistencia, el inicio y el apagado. Sin embargo, es importante tener en cuenta las necesidades del sistema de archivos y asegurarse de que las máquinas virtuales tengan el tamaño y la capacidad de almacenamiento adecuados.

Contenido estático de solo lectura

Si la aplicación actualmente sirve contenido estático, necesita una ubicación alternativa para ella. Debe considerar la posibilidad de mover contenido estático a Azure Blob Storage y agregar Azure Front Door para descargas rápidas globalmente. Para más información, consulte hospedaje de sitios web estáticos en Azure Storage y Integración de una cuenta de Azure Storage con Azure Front Door.

Determinación de la topología de red

El conjunto actual de ofertas de Azure Marketplace es un punto de partida para su migración. Si la oferta no cubre aspectos de su arquitectura que necesita migrar, necesita capturar la topología de red de su implementación existente. A continuación, debe reproducir esa topología de red en Azure, incluso después de configurar la oferta básica con una de las plantillas de soluciones.

La topología de red es un tema amplio, pero las siguientes referencias pueden orientar sus esfuerzos de migración:

• Dado que los orígenes de datos son servidores independientes en un sistema WAS, debe incluirlos en el análisis de la topología de red. Para obtener más información, consulte Orígenes de datos de WebSphere Application Server.
• Las fuentes de mensajería también son servidores independientes. Para obtener más información, consulte Topologías de red: Interoperación utilizando el proveedor de mensajería WebSphere MQ.
• El equilibrio de carga es un requisito fundamental. La siguiente referencia abarca la parte de WAS del equilibrio de carga: WebSphere Application Server Network Deployment: agrupación en clústeres con equilibrio de carga.

Tenga en cuenta el uso de adaptadores JCA y adaptadores de recursos

Si su aplicación existente usa adaptadores JCA u otros adaptadores de recursos para conectarse a otros sistemas empresariales, asegúrese de aplicar la configuración para estos artefactos al WAS que se ejecuta en las máquinas virtuales Azure. Para obtener más información, consulte Adaptadores de recursos relacionales y JCA en la documentación de IBM.

Cuenta para autenticación y autorización

La mayoría de las aplicaciones tienen algún tipo de autenticación y autorización. Si usa OpenID para la autenticación, puede configurar la autenticación de OpenID connect con Microsoft Entra ID. Para obtener más información, consulte Autenticación de OpenID Connect con Microsoft Entra ID.

Determinación de si se usa la agrupación en clústeres WAS

Lo más probable es que implemente la aplicación en varios servidores WAS para lograr una alta disponibilidad. Puede migrar estos clústeres directamente desde su instalación local a WAS para que se ejecuten en máquinas virtuales de Azure. Para obtener más información, consulte WebSphere Application Server Network Deployment en la documentación de IBM.

Tenga en cuenta los requisitos de equilibrio de carga

El equilibrio de carga es una parte esencial de la migración del clúster de WAS a Azure. La solución más sencilla es utilizar la compatibilidad integrada con Azure Application Gateway o IBM HTTP Server, incluida en la oferta de Azure Marketplace para IBM WebSphere Application Server Cluster.

Para ver un resumen de las capacidades de Azure Application Gateway en comparación con otras soluciones de equilibrio de carga de Azure, consulte Opciones de equilibrio de carga.

Determinación de si se usa la característica de cliente de aplicación de Java EE

Si su aplicación usa la característica de cliente de aplicación de Java EE, debería continuar funcionando sin cambios después de migrar a Azure Virtual Machines. Para obtener más información, consulte Uso de los módulos de aplicación cliente de Java EE.

Migración

Seleccione una oferta de WAS traditional en máquinas virtuales de Azure

Las siguientes ofertas están disponibles para WAS en máquinas virtuales de Azure.

Durante la implementación de una oferta, se le pedirá que elija el tamaño de máquina virtual para los nodos de WAS. Es importante tener en cuenta todos los aspectos (memoria, procesador y disco) a la hora de elegir el tamaño de la máquina virtual. Para obtener más información, consulte Tamaños de Cloud Services (clásico).

• IBM WebSphere Application Server Single Instance en una máquina virtual de Azure

  Esta oferta automatiza la mayoría de los pasos para aprovisionar una única instancia de WebSphere en una máquina virtual Azure. Crea un perfil de servidor de aplicaciones con la consola de administración de WAS.

• Clúster de IBM WebSphere Application Server en máquinas virtuales de Azure

  Esta oferta automatiza la mayoría de los pasos para aprovisionar un clúster WebSphere en máquinas virtuales Azure. Crea un administrador de implementación con la consola de administración de WAS en una máquina virtual Azure y el número necesario de agentes de nodo en máquinas virtuales Azure separadas.

Aprovisionamiento de la oferta

Una vez que haya seleccionado con qué oferta empezar, aprovisione esa oferta siguiendo las instrucciones de Implementar un clúster de WebSphere Application Server (tradicional) en máquinas virtuales de Azure.

Migración de los perfiles

Una vez aprovisionada la oferta, puede examinar la configuración del perfil. Para obtener más información, consulte Conceptos de perfil en la documentación de IBM.

Conexión de las bases de datos

Después de migrar los perfiles, conecte las bases de datos siguiendo las instrucciones de Configuración del origen de datos de WebSphere Application Server en la documentación de IBM.

Cuenta de almacenes de claves

Debe tener en cuenta la migración de los almacenes de claves SSL que utilice su aplicación. Para obtener más información, consulte Configuración del almacén de claves para SSL en la documentación de IBM.

Conecte las fuentes JMS

Después de conectar las bases de datos, configure JMS siguiendo las instrucciones de Configuración de JMS en IBM WebSphere Application Server en la documentación de IBM.

Cuenta para autenticación y autorización

La mayoría de las aplicaciones tienen algún tipo de autenticación y autorización. Si usa OpenID para la autenticación, puede configurar la autenticación de OpenID connect con Microsoft Entra ID. Para obtener más información, consulte Autenticación de OpenID Connect con Microsoft Entra ID.

Cuenta para el registro

Puede configurar Elastic Stack siguiendo las instrucciones de Análisis de los registros de WebSphere Application Server con Elastic Stack en la documentación de IBM. Azure ofrece un gran soporte para Elastic. Para obtener más información, consulte ¿Qué es la integración de Elastic con Azure? Puede combinar la información de estos dos recursos para lograr una solución de registro optimizada para Azure para WAS en máquinas virtuales.

Migración de las aplicaciones

Las técnicas que se usan para implementar las aplicaciones del equipo de desarrollo en servidores de prueba, de ensayo y de producción varían mucho en cada caso. En algunos casos, hay una plataforma de CI/CD muy evolucionada que permite implementar las aplicaciones en el servidor de WebSphere Application. En otros casos, el proceso puede ser más manual. Una ventaja de usar Azure Virtual Machines para migrar aplicaciones de WAS tradicional a la nube es que los procesos existentes seguirán funcionando.

Tendrá que configurar el grupo de seguridad de red que aprovisiona la oferta para poder acceder desde la canalización de CI/CD o el sistema de implementación manual. Para obtener más información, consulte grupos de seguridad de red.

Prueba

Debe configurar cualquier prueba de las aplicaciones en el contenedor para tener acceso a los nuevos servidores que se ejecutan en Azure. Al igual que en el caso de CI/CD, debe asegurarse de que las reglas de seguridad de red necesarias permiten que las pruebas tengan acceso a las aplicaciones implementadas en Azure. Para más información, consulte grupos de seguridad de red.

Después de la migración

Una vez que haya alcanzado los objetivos de migración que definió en el paso de premigración, realice pruebas de aceptación de extremo a extremo para verificar que todo funciona según lo previsto. Para obtener orientación sobre algunas posibles mejoras posteriores a la migración, consulte las siguientes recomendaciones:

• Uso de Azure Storage para servir el contenido estático montado en las máquinas virtuales. Para obtener más información, consulte Adjuntar o desasociar un disco de datos de una máquina virtual de laboratorio en Azure DevTest Labs.

• Implemente las aplicaciones en el clúster de WAS migrado con Azure DevOps. Para obtener más información, consulte la documentación para empezar a usar Azure DevOps.

• Si implementó WAS tradicional con Azure Application Gateway, es posible que desee realizar más configuraciones en el Application Gateway. Para más información, consulte información general sobre la configuración de Application Gateway.

• Mejorar la topología de red con servicios avanzados de equilibrio de carga. Para más información, consulte Uso de servicios de equilibrio de carga en Azure.

• Usar Azure Managed Identities para gestionar secretos y asignar acceso basado en roles a los recursos de Azure. Para obtener más información, consulta ¿Qué son las identidades administradas para recursos de Azure?

• Integre la autenticación y autorización de WAS Java EE con el Microsoft Entra ID. Para obtener más información, consulte la guía de introducción a la integración de Microsoft Entra ID con aplicaciones.

• Usar Azure Key Vault para almacenar toda la información que funcione como un "secreto". Para más información, consulte Conceptos básicos de Azure Key Vault.