Migración de aplicaciones de WebSphere a Azure Virtual Machines

  • Artículo

En esta guía se describe lo que debe tener en cuenta cuando quiera migrar una aplicación tradicional de WebSphere Application Server (WAS) existente para que se ejecute en Azure Virtual Machines. Para obtener información general sobre las soluciones tradicionales WAS disponibles en Azure Marketplace, consulte ¿Qué 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 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.

En la medida de lo posible, es mejor centrarse en un traslado lift-and-shift, teniendo en cuenta los cambios necesarios que se indican en esta guía. Defina lo que quiere decir con "migración completa" para que sepa cuándo ha alcanzado el objetivo. Cuando haya alcanzado la "migración completa", puede tomar una instantánea de las máquinas virtuales, tal como se describe en Creación de una instantánea de un disco duro virtual. Después de comprobar que puede restaurar correctamente desde la instantánea, puede realizar las mejoras sin miedo a perder el progreso de la migración que ha logrado hasta ahora.

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

El primer paso de una migración correcta de una aplicación WAS a Azure es seleccionar el destino de migración más adecuado.

WAS tradicional se ejecuta bien en Azure Virtual Machines. El destino de la máquina virtual (VM) es la opción más sencilla, ya que se parece más a una implementación local. La experiencia administrativa e de implementación de las máquinas virtuales es análoga a lo que tiene en el entorno local.

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

Por lo general, el costo por minuto de una solución basada en máquinas virtuales es mayor en comparación con los contenedores. Aunque una solución basada en contenedores cuesta menos ejecutarse, debe restringir la 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 el esfuerzo de migración, considere la posibilidad de realizar una migración basada en máquinas virtuales. En este caso, consulte Migración de aplicaciones de WebSphere a Azure Virtual Machines.

Si puede tolerar la conversión de la aplicación para que se ejecute dentro de contenedores para reducir el costo en tiempo de ejecución, considere la posibilidad de una migración basada en AKS o basada en Red Hat OpenShift en Azure.

Para la migración basada en AKS, puede empezar a usar el nivel Gratis. Obtenga la administración gratuita de clústeres y pague solo por las máquinas virtuales, el almacenamiento asociado y los recursos de red consumidos. En este caso, consulte Migración de aplicaciones de WebSphere a Azure Kubernetes Service.

Para la migración basada en Red Hat OpenShift de Azure, además de los costos de proceso e infraestructura, los nodos de aplicación tienen otro costo para el componente de licencia de OpenShift. Este costo se factura en función del número de nodos de aplicación y del tipo de instancia. Use los precios a petición o las instancias reservadas, lo que mejor satisfaga la necesidad de la carga de trabajo y la empresa. En este caso, consulte Migración de aplicaciones de WebSphere a Red Hat OpenShift en Azure.

Las guías paso a paso de la documentación de Red Hat OpenShift de Azure tratan 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 de Azure.

Determinar si las ofertas precompiladas de Azure Marketplace son un buen punto de partida

IBM y Microsoft se han asociado para incorporar un conjunto de plantillas de solución de Azure a Azure Marketplace para proporcionar un punto de partida sólido para migrar a Azure. Para obtener la lista de ofertas, consulte Run the WebSphere family of products and Liberty on Microsoft Azure (Ejecutar la familia de productos WebSphere y Liberty en Microsoft Azure) y, a continuación, elija la que mejor coincida con la implementación existente. Puede ver la lista de ofertas en el artículo de información general ¿Qué son las soluciones para ejecutar la familia de productos IBM WebSphere en Azure?

Si ninguna de las ofertas existentes es un buen punto de partida, debe reproducir la implementación manualmente mediante recursos de máquina virtual de Azure. Puede encontrar la guía paso a paso en Tutorial: Instalación manual de IBM WebSphere Application Server Network Deployment tradicional en Azure Virtual Machines. Para más información, consulte ¿Qué es IaaS?

Determinar si la versión tradicional was es compatible

La versión tradicional was existente 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 e ibm WebSphere Application Server Cluster en máquinas virtuales de Azure. Si la versión tradicional was existente no es compatible con esa versión, debe reproducir la implementación manualmente mediante 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 de Cloud Services.

Inventario de 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, hay un conjunto dispar de opciones de configuración que funcionaban de forma eficaz como lo que ahora llamamos "secretos". Con servidores de aplicaciones como WAS, estos secretos se encuentran en muchos archivos de configuración y almacenes de configuración diferentes. Compruebe los secretos y las contraseñas en todas las propiedades y los archivos de configuración de los servidores de producción. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. WAS almacena datos de configuración en varios documentos en una jerarquía en cascada de directorios. La mayoría de los documentos de configuración tienen contenido XML. Para más información, consulte Los documentos de configuración y los 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 Administración de certificados de IBM en SSL.

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

El uso de WAS en Azure Virtual Machines requiere una versión específica de Java, por lo que debe 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 más información, consulte Java SE 8 en WebSphere Application Server tradicional V9.

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

Inventario de los recursos de JNDI

Realice un inventario de todos los recursos de JNDI. Por ejemplo, los orígenes de datos tales como las bases de datos pueden tener un nombre de JNDI asociado que permita a JPA enlazar correctamente instancias de EntityManager con una base de datos determinada. Para obtener más información sobre los recursos y bases de datos JNDI, consulte Orígenes de datos de WebSphere 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 de JMS.

Inspección de la configuración del perfil

La unidad de configuración principal de WAS es el perfil. Por lo tanto, el archivo resources.xml contiene una gran cantidad de configuraciones que debe tener en cuenta cuidadosamente para la migración. El archivo incluye referencias a más archivos XML almacenados en subdirectorios. IBM aconseja que normalmente debe usar ibm Console para configurar los servicios y objetos administrables de WAS y permitir que WAS mantenga la carpeta profiles/profile-name . Para obtener más información, consulte Administración de perfiles en sistemas operativos distribuidos e IBM i.

Dentro de la 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 la aplicación se basa en la replicación de sesión, tiene las siguientes opciones:

  • En el caso de las sesiones HTTP, según el nivel de administración de sesiones, puede usar la memoria o una base de datos para recopilar datos de sesión.
  • En el caso de las sesiones distribuidas, puede guardar sesiones en una base de datos mediante la persistencia de la sesión de base de datos.
  • Para la caché dinámica, puede administrar los datos de sesión en la 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 de estado de sesión HTTP. Para obtener más información, consulte Administración sistering session beans en la documentación de IBM.

Orígenes de datos de documentos

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.

Determinar si WAS se ha personalizado

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

  • ¿Se han cambiado los scripts de inicio? Estos scripts incluyen wsadmin, Administración Control, Administración Config, Administración App y Administración Task.
  • ¿Se han pasado parámetros específicos a JVM?
  • ¿Se han agregado archivos JAR a la ruta de clases del servidor?
  • ¿Se han usado instalaciones de nivel de sistema operativo como systemd para hacer que los componentes WAS se inicien automáticamente después de reiniciar un 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. Elección de una solución para conectar una red local a Azure. También tendrá que refactorizar la aplicación para que use las API disponibles públicamente que exponen los recursos locales.

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

Si la aplicación usa colas o temas de JMS, debe migrarlas a un servidor JMS hospedado externamente. Una estrategia para aquellos que usan JMS es usar Azure Service Bus y advanced Message Queuing Protocol. Para más información, consulte Uso de JMS con Azure Service Bus y AMQP 1.0.

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

Si usa IBM MQ, puede migrar este software a Azure Virtual Machines y usarlo tal cual.

Microsoft tiene una solución para integrar IBM MQ con Logic Apps. Para más información, consulte Conectar a un servidor 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.

Determinación de si se usan agrupaciones OSGi

Si ha usado agrupaciones de OSGi agregadas a WAS, debe agregar los archivos JAR equivalentes directamente a la 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 host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, puede que necesite reemplazar el uso de / o \ en las rutas de acceso del sistema de archivos por File.Separator o Paths.get.

Determinar si IBM Integration Bus está en uso

Si la aplicación usa IBM Integration Bus, debe capturar cómo se configura 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 la 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 capture sus configuraciones. Para obtener más información, consulte Creación del paquete de archivo empresarial (EAR) en WebSphere.

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

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

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 su aplicación actualmente sirve contenido estático, necesitará una ubicación alternativa para él. Quizás quiera considerar la posibilidad de mover el contenido estático a Azure Blob Storage y agregar Azure CDN para tener descargas de alta velocidad globalmente. Para más información, consulte Hospedaje de sitios web estáticos en Azure Storage e Inicio rápido: Integración de una cuenta de una instancia de Azure Storage con Azure CDN. También puede implementar directamente el contenido estático en una aplicación en el plan Enterprise de Azure Spring Apps. Para obtener más información, consulte Implementación de archivos estáticos web.

Contenido estático publicado dinámicamente

Si su aplicación permite que haya contenido estático que la aplicación carga o produce, pero que es inmutable una vez creado, puede usar Azure Blob Storage y Azure CDN con una función de Azure para controlar las cargas y la actualización de la red CDN. Hemos proporcionado una implementación de ejemplo para su uso en Cargar y carga previa en CDN de contenido estático con Azure Functions. También puede implementar directamente el contenido estático en una aplicación en el plan Enterprise de Azure Spring Apps. Para obtener más información, consulte Implementación de archivos estáticos web.

Determinación de la topología de red

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

La topología de red es un tema amplio, pero las siguientes referencias pueden dar alguna dirección a los esfuerzos de migración:

  • La siguiente referencia enumera los temas de alto nivel relevantes para la migración de la topología de red a Azure: topologías de implementación de red de WebSphere Application Server.
  • Dado que los orígenes de datos son servidores independientes en un sistema WAS, debe considerarlos como parte del análisis de topología de red. Para obtener más información, consulte Orígenes de datos de WebSphere Application Server.
  • Los orígenes de mensajería también son servidores independientes. Para obtener más información, consulte Topologías de red: Interoperación mediante el proveedor de mensajería de WebSphere MQ.
  • El equilibrio de carga es un requisito fundamental. La siguiente referencia abarca el lado WAS del equilibrio de carga: agrupación en clústeres de carga equilibrada de implementación de webSphere Application Server Network Deployment.

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

Si la aplicación existente usa adaptadores de JCA u otros adaptadores de recursos para conectarse a otros sistemas empresariales, asegúrese de aplicar la configuración de estos artefactos a was en ejecución en Azure Virtual Machines. Para más información, consulte Adaptadores de recursos relacionales y JCA en la documentación de IBM.

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 Conexión de OpenID con el identificador de Microsoft Entra. Para obtener más información, consulte Autenticación de OpenID Conectar con el identificador de Entra de Microsoft.

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

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

Requisitos del equilibrio de carga

El equilibrio de carga es una parte esencial de la migración del clúster WAS a Azure. La solución más sencilla es usar la compatibilidad integrada para App de Azure lication Gateway o IBM HTTP Server proporcionada en la oferta de Azure Marketplace para el clúster de servidor de aplicaciones web de IBM WebSphere.

Para obtener un resumen de las funcionalidades de App de Azure lication 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 más información, consulte cómo usar los módulos de aplicación de cliente de Java EE.

Migración

Selección de una oferta was tradicional en Azure Virtual Machines

Las siguientes ofertas están disponibles para WAS en Azure Virtual Machines.

Durante la implementación de una oferta, se le pedirá que elija el tamaño de la máquina virtual para los nodos 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 más información, consulte Tamaños de Cloud Services (clásico).

Aprovisionamiento de la oferta

Después de seleccionar la oferta con la que empezar, aprovisione esa oferta siguiendo las instrucciones de Implementación del clúster de WebSphere Application Server (tradicional) en Azure Virtual Machines.

Migración de los perfiles

Después de aprovisionar 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, puede conectar 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 use la aplicación. Para obtener más información, consulte Configuraciones de almacén de claves para SSL en la documentación de IBM.

Conexión de los orígenes de JMS

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

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 Conexión de OpenID con el identificador de Microsoft Entra. Para obtener más información, consulte Autenticación de OpenID Conectar con el identificador de Entra de Microsoft.

Cuenta para el registro

Puede configurar Elastic Stack siguiendo las instrucciones de Análisis de registros de WebSphere Application Server con Elastic Stack en la documentación de IBM. Azure proporciona compatibilidad con Elastic. Para más información, consulte ¿Qué es la integración elástica con Azure? Puede combinar los conocimientos 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 ci/CD muy evolucionada que da como resultado que las aplicaciones se implementan en WebSphere Application Server. En otros casos, el proceso puede ser más manual. Una ventaja de usar Azure Virtual Machines para migrar aplicaciones tradicionales was a la nube es que los procesos existentes siguen funcionando.

Debe configurar el grupo de seguridad de red que la oferta aprovisiona para permitir el acceso desde la canalización de CI/CD o el sistema de implementación manual. Para más información, consulteGrupo de seguridad de red.

Prueba

Debe configurar las pruebas dentro del contenedor en las aplicaciones para acceder 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, consulteGrupo de seguridad de red.

Después de la migración

Una vez alcanzados los objetivos de migración que se han definido antes de la migración, realice pruebas integrales de aceptación para comprobar que todo funciona según lo previsto. Para obtener instrucciones sobre algunas posibles mejoras posteriores a la migración, consulte las siguientes recomendaciones: