knowgateGuía estratégica de migración de WAS a JBoss

Esta presentación contiene la guía estratégica para la migración de IBM WebSphere a JBoss Enterprise.

El cambio de tecnología reporta habitualmente los siguientes beneficios:

1. Menor complejidad, menos tiempo empleado en gestión de servidores.

2. Mayor facilidad de instalación y configuración.

3. Reducción del coste total de propiedad.

4. Mejor productividad en programación gracias a la integración con tecnologías Web 2.0.

5. Configuraciones de alta disponibilidad con balanceo de carga tolerantes a fallos.

6. Uso de estándares Open Source.

Contenido de esta presentación

Factores decisivos para una migración

Cada compañía decide migrar de un servidor de aplicaciones a otro por diferentes motivos.

Los más comunes son los siguientes:

•Reducir el Coste Total de Propiedad

•Reducir el coste del soporte

•Eliminar licencias por CPU

•Poder empaquetar el servidor con otro software para distribuirlo todo junto

•Permitir el uso de hardware más barato

•Permitir el uso de clusters más robustos

•Expandir granjas de servidores

•Adherirse a estándares

•Consolidar el centro de datos

•Adoptar de metodologías de desarrollo rápido

•Ganar Flexibilidad

•Mejorar el Rendimiento

•Aumentar la Escalabilidad

6 pasos esenciales de planificación

1. Examinar todas las funcionalidades utilizadas en WebSphere y determinar su equivalencia en JBoss.

2. Específicamente para las funcionalidades exclusivas de WebSphere definir una forma alternativa de hacer lo mismo con JBoss.

3. Medir el grado de preparación en la empresa para una migración.

4. Estimar el riesgo total de la migración detallando punto por punto.

5. Desarrollar un plan táctico de migración con un roadmap detallado y un cálculo de costes.

6. Definir el servicio y soporte durante y después de la migración.

Módulos de JBoss Enterprise

EJB 3.0 Portal

AOP JGroups

Hibernate MQ

Cache Messaging

IDE Mail Server

jBPM Tomcat

Migración de aplicaciones web básicas.

Migración de Java EE

Migraciones de JSR

Migración de la configuración

Escenarios de Migración

Migración de aplicaciones web básicas

Migrar aplicaciones web básicas que están desarrolladas de acuerdo a las especificaciones de servlets y Java EE es la manera más sencilla y práctica de empezar a experimentar con el cambio a JBoss Enterprise. Suelen dar una buena métrica del esfuerzo requerido. Si la aplicación a migrar está desarrollada con un IDE como Eclipse o Netbeans el cambio normalmente es bastante fácil y rápido. Otros IDEs gestionan las librerías de forma que pueden dar algo más de trabajo hasta resolver todas las dependencias.

El descriptor de despliegue web.xml de cada webapp puede contener tags propietarios que no sean reconocidos por JBoss. Asimismo, los descriptores propietarios adicionales ibm- web- ext.xmi e ibm- web- bnd.xmi deben ser convertidos al jboss-web.xml reconocido por JBoss.

Muchas aplicaciones web se pueden copiar directamente de WebSphere a JBoss sin hacerles absolutamente ningún cambio. Cuando se requieren cambios, los obstáculos más frecuentes suelen ser.

1.En general, hay que copiar archivos .war y no directorios expandidos, pues estos últimos tienen tendencia a dar problemas.

2.Los descriptores .xmi la mayoría de las webs no contienen información relevante para el despliegue, pero cuando sí la contienen, como el context root o restricciones de seguridad, entonces hay que convertirlos a jboss-web.xml.

3.Las webapps pueden usar librerías propias de WebSphere, sobre todo librerías de tags JSP. Aquí la migración se pueden complicar. Dependiendo de la librería en cuestión, no siempre es trivial encontrar un componente Open Source con la que reemplazarla directamente.

Migración de Java EE

En teoría, la migración de Java EE no es más complicada que la de aplicaciones web. No obstante, el propósito de las especificaciones Java EE es facilitar la integración de múltiples frameworks con funcionalidades diversas. Esto suele implicar que en un entorno Java EE existan muchas mini-aplicaciones involucradas. El proyecto MASS de JBoss proporciona una herramienta de análisis de migración llamada MAT que scanea el código fuente de las aplicaciones en busca de librerías propietarias. Este análisis de MAT proporciona información muy valiosa a la hora de estimar el esfuerzo requerido para la migración de aplicaciones Java EE.

Migraciones de JSRJSR es una iniciativa de la comunidad Java para estandarizar áreas cómo: portal, ESB, workflow, inyección, etc.

En JBoss existen diferentes caminos de migración para cada estándar JSR. Dependiendo de lo completa que sea la especificación en cuestión, la migración puede ser muy simple o realmente complicada. En general, las anotaciones son más estándar que las implementaciones XML.

Migración de configuración

A grandes rasgos, un entorno WAS está organizado en una serie de celdas y nodos. Un nodo se define por un repositorio de configuración y un único perfil. Varias instancias WAS pueden pertenecer al mismo nodo, sin embargo, cada instancia sólo puede pertenecer a un solo nodo. Los nodos son gestionados por un agente en el cual el nodo se registra. Pero en otros entornos más sofisticados en gestor de despliegue es usado para administrar y gestionar y provisionar con eficiencia los nodos. Por último, un planificador de tareas puede ser usado para enviar de forma asíncrona tareas administrativas a los gestores de despliegue y a los agentes administrativos.

Servicios configuradosWAS maneja los conceptos de aplicaciones instaladas y servicios configurados, con un ámbito en el nivel aplicable. Los recursos en la terminología WAS pueden incluir fuentes de datos JDBC y destinos JMS, que se consideran artefactos desplegables en JBoss. Esto induce a dos modelos muy diferentes entre WAS y JBoss.

Con WAS, los servicios JDBC y JMS se configuran a través de la consola de administración de WebSphere. Esto es así tanto para desarrollo como para producción, con lo cual el propio desarrollador puede ser el administrador del entorno de producción. Aunque la configuración de los recursos depende en última instancia de las necesidades de cada aplicación, dicha configuración está físicamente separada de la aplicación en sí misma. Los desarrolladores suelen documentar las dependencias de servicios y los administradores siguen dicha documentación para configurar los servicios de manera que las aplicaciones funcionen correctamente.

Por otro lado, con JBoss cada servicio se configura en su propio fichero XML. Dos o más servicios del mismo tipo se pueden configurar en el mismo fichero XML. Esto da a los usuarios flexibilidad en la elección de su configuración. Con Jboss se pueden seguir las mismas prácticas de configuración de servicios que con WAS basadas en leerse la documentación de los desarrolladores. Pero con JBoss también es posible incluir ficheros XML redistribuibles dentro del archivo de distribución, lo cual permite crear aplicaciones autocontenidas que incluyen sus propias dependencias de configuración.

JDBCEn WebSphere cada fuente JDBC se configura en su propio fichero XML correspondiente al perfil y ámbito. El patrón típico es crear un directorio para cada perfil bajo WebSphere/AppServer/profiles/ Este directorio contendrá otro subdirectorio /config/ que a su vez contendrá la jerarquía de subdirectorios correspondientes al ámbito aplicable a la fuente a la fuente de datos. Por ejemplo, si la fuente de datos se aplica a nivel de celda entonces un subdirectorio llamado /cells/ contendrá un subdirectorio para dicha celda el cual tendrá un fichero resource.xml descriptor de la fuente de datos. Una fuente de datos definida bajo un proveedor JDBC estará en el elemento factories del fichero de configuración con tipo resources.jdbc:DataSource bajo resources.jdbc:JDBCProvider. Puede haber también otras propiedades en fichero XML tales como las necesarias para el configurar el pool de conexiones.

En JBoss basta con crear un snippet XML datasource para cada pool de conexiones que figura bien en su propio poolName-ds.xml bien combinado colectivamente en el mismo fichero *-ds.xml. El contenido de dicho fichero XML para la fuente de datos JDBC dependerá del comportamiento transaccional del datasource así cómo de los detalles de su conexión. Todos los detalles sobre la conexión del *-ds.xml en JBoss se encuentran en WebSphere en el correspondiente fichero *-jdbc.xml bajo config/jdbc. La contraseña de la BB.DD. se guarda encriptada y, por consiguiente, no es en general posible automatizar al 100% la migración.

JMSEn WebSphere cada componente JMS se configura separadamente en la consola de administración. Por ejemplo, los proveedores JMS se crean y configuran en una sección separada de los destinos tales como colas y tópicos, aunque en el fichero XML donde se refleja esta configuración los destinos aparecen bajo el proveedor aplicable. Esta información se almacena en un fichero XML correspondiente al perfil en el nivel de ámbito que sea. El patrón típico es es que exista un directorio por perfil bajo WebSphere/AppServer/profiles y que este directorio contenga subdirectorios correspondientes al ámbito al que se dirige el componente JMS. Por ejemplo, si una cola se dirige al nivel de celda, un subdirectorio llamado /cells contendrá un directorio para dicha celda que a su vez tendrá un fichero resources.xml descriptor de la cola JMS. Una cola ligada a un proveedor JMS aparecerá en el elemento j2cAdminObjects bajo el proveedor JMS el cual se describe en el elemento J2CResourceAdapter.

En JBoss las factorías de conexiones JMS se configuran típicamente en deploy/jboss-messaging.sar/connection-factories-service.xml pero, en general, se pueden configurar como parte del fichero de despliegue de cualquier servicio. En JBoss basta con crear un snippet XML de destino JMS para cada cola o tópico el cual puede venir en su propio fichero destination-service.xml o combinado colectivamente en el mismo *-service.xml. El contenido de tal fichero destination-service.xml se parece al de cualquier fichero de despliegue MBean siendo el código Mbean QueueService o TopicService según requiera cada caso. El fichero XML se puede desplegar en el servidor JBoss dejándolo en el directorio /deploy.

ClusteringAunque las funcionalidades son bastante parecidas, existen diferencias significativas en la forma en la que se configura el clustering en WebSphere vs. JBoss. WebSphere proporciona una visión del cluster que es muy estática tanto en lo referente a los miembros como en sus detalles de configuración que son limitados y, básicamente, convierten al cluster en una caja negra. Esto lleva a un nivel de simplicidad que puede ser bueno para algunas instalaciones pero crear quebraderos de cabeza en otras. El cluster en sí mismo se define de forma estática en el servidor de administración con direcciones explícitas para cada miembro.

En JBoss el cluster es un concepto mucho más dinámico. Se define por un nombre de cluster y una dirección unicast o multicast. Cualquier instancia de JBoss que pretenda unirse al cluster puede hacerlo comunicándose con su dirección y dando el nombre del cluster. Esto proporciona una forma muy fluída de definir un cluster que es útil para ir provisionando nuevas instancias. Además, el clustering de JBoss está montado sobre JGroups que es muy configurable. Se soporta una gran variedad de topologías de red y, si se sabe hacer, se puede optimizar mucho más el rendimiento del cluster de lo que es factible en WebSphere.

Cache

En un cluster los caches deben mantenerse sincronizados para evitar problemas de integridad de datos. Los más prominentes son el cache de sesiones HTTP y los caches de entity beans. De nuevo, WebSphere toma un acercamiento de caja negra mientras que JBoss tiene un enfoque más abierto y parametrizable montado sobre una pila de software libre.

JBoss Cache se utiliza para proporcionar un cache distribuido transaccional para entity beans y sesiones HTTP. Algunas características avanzadas tal como la replicación mediante AOP no basada en serialización está disponible en JBoss dentro de las funcionalidades de para POJOs. El protocolo de comunicación también se puede cambiar , así como la replicación síncrona o asíncrona.

JVM y CLASSLOADERS

A pesar de que existen diferencias de implementación entre las diferentes máquinas virtuales, nosotros hasta la fecha no nos hemos encontrado aplicaciones que puedan correr en una pero no en otra, excepto por el propio JBoss que requiere una JVM específica para cada versión. En general, casi siempre montamos Sun Java ya que Open JDK nos ha dado algún problema de compatibilidad en el pasado.

Lo que sí hemos detectado que funciona de forma muy diferente en WbSphere vs. JBoss son los classloaders. Algunas aplicaciones dependen de forma inadvertida del funcionamiento del classloader. WebSphere proporciona un classloader jerárquico cuyo comportamiento estándar es delegar en el padre. Tras la JVM, y las librerías WAS la jerarquía eventualmente llega a la aplicación. Cuando las webapps existen dentro de aplicaciones enterprise se les asigna su propio classloader hijo del classloader del enterprise. JBoss en cambio usa un modelo mucho más simple, en el cual la mayoría de los artefactos residen en un único classloader que es altamente parametrizable y que puede, potencialmente usar un classloader compartido.

Latencia y volumen de peticiones En general, los servidores se optimizan bien para tener bajos tiempos de latencia bien para proporcionar un elevado throughput. La parametrización de timeouts, número máximo de hilos y otras opciones están en el espectro opuesto cuando se trata de minimizar la latencia o de aumentar el throughput.

Cuando se persigue aumentar el throughput la prioridad es el rendimiento global del sistema sin prestar demasiada atención a los tiempos de respuesta a peticiones individuales. Por ejemplo, para un servidor con cuatro núcleos se puede determinar que 200 peticiones concurrentes es el punto óptimo para tener un tiempo medio de respuesta de un segundo. En una configuración orientada a maximizar el throughput se limitaría el número de hilos a 200 y el resto de peticiones concurrentes que llegasen por encima de esa cantidad se encolarían lo cual provocaría que se ralentizase el tiempo de respuesta a determinadas peticiones. Al tratar de maximizar el throughput podría ser que se viole un SLA que diga, pongamos, que el tiempo máximo de respuesta debe ser de 2 segundos. Para reducir la latencia se podría aumentar el número máximo de hilos de 200 a 300, eso podría provocar que el tiempo medio de respuesta fuese de 1,7 segundos y con ello cumplir el SLA, aunque el rendimiento global del sistema habría pasado de 200tps a 176tps.

Separación del servidor webdel servidor de aplicaciones

- Algunas empresas especializadas en middleware recomiendan separar el servidor web del servidor de aplicaciones. En nuestra experiencia, esto puede ser útil en algunos casos, pero en la mayoría de ellos añade un nivel de complejidad innecesario, además de complicar la configuración debido a la proliferación de servidores físicos.

- Si se usan máquinas virtuales de 32 bits suele ser mejor limitar a una las aplicaciones por cada servidor de aplicaciones debido a la restricción a 4Gb de RAM. En 64 bits, sin embargo, se suelen aprovechar mejor los recursos computacionales desplegando varias aplicaciones en cada servidor.

- También es posible instalar varias instancias de JBoss en la misma máquina.

- Respecto de las sesiones HTTP, nosotros recomendamos mantener el mínimo de información en ellas para que los caches funcionen más eficientemente. Lo ideal son aplicaciones web que no mantengan estados, dado que ello hace innecesaria la replicación.

Migración de hardware I

Aunque Java es muy transportable, a veces se encuentran aplicaciones con funcionalidades ligadas al sistema operativo o hasta al hardware.

Los tres escenarios típicos de migración son: consolidación (juntar varios servidores físicos en uno), dispersión o agregación. En principio, un menor número de servidores implica menos esfuerzo de administración, aunque si la consolidación se hace mediante máquinas virtuales en nuestra experiencia pueden producirse sorpresas desagradables con el rendimiento, en especial si las máquinas virtuales están provisionadas mediante un servicio cloud de un ISP.

Migración de hardware II

Si se contempla cambiar el hardware conviene estudiar previamente los siguientes puntos:

1.¿Es la aplicación de misión crítica?

2.¿Cómo son de críticos los datos? ¿Qué redundancia requiere el almacenamiento?

3.¿Qué acuerdos de nivel de servicio (SLA) deben cumplirse?

4.Qué topología de red se adapta mejor a las necesidades de comunicación?

5.¿Cuánto ancho de banda se necesita?

6.¿Qué tipo de cache debe implementarse en JBoss?

7.¿Existe un punto óptimo entre latencia versus throughput?

8.¿Qué otras optimizaciones convendría hacer en JBoss?

El proceso de migración paso a paso

Fase Descripción Entregable Duración

I) Modelo de arquitectura y despliegue

Inventario de servidores, infraestructura de red y aplicaciones. Planificación de capacidad.

Inventario de servidores de aplicaciones, su propósito. Hardware y otros recursos computacionales.

2 semanas

II) Análisis de aplicaciones Análisis de las aplicaciones una por una. Dependencias, librerías, peculiaridades.

Lista priorizada de aplicaciones que se pueden migrar. Inventario de librerías usadas y dependencias. Especificaciones de la migración

De 2 a 8 semanas

III) Estimación de esfuerzo y riesgo.

Detalles de configuración de cada servidor y aplicaciones.

Lista de servicios configurados por servidor. Clusters. Esfuerzo estimado de migración. Identificación de riesgos principales.

4 semanas

IV) Plan de migración Plan de trabajo detallado para la migración. Roadmap. Recursos asignados.

Documentos de instrucciones detalladas para migrar los servidores y las aplicaciones seleccionadas

5 semanas

V) Migración Implementación de cambios Aplicaciones reinstaladas y operativas

Depende de la cantidad de aplicaciones

Fase I:Modelo de arquitectura y despliegue

En esta fase se hace un inventario de los servidores existentes, la infraestructura de red y las apps.

La infraestructura comprende el ecosistema completo:

Centros de datos: Cuántos hay. Cual es su misión. Cómo están interconectados. Cual es la estrategia de tolerancia a fallos.

Hardware: Servidores. Balanceadores de carga. Routers. Almacenamiento en red.

Software base: Servidores web. Servidores de aplicaciones. etc.

Servicios de soporte: Mensajería, portal, AOP, inyección, cache, etc.

Entornos de desarrollo: IDEs, gestión de la configuración, scripts, bug trackers.

Aplicaciones: Listadas por servidor, funcionalidad y grado de criticidad.

Fase II:Análisis de aplicaciones

Con el fin de estar al tanto de todo el ámbito de la migración, es importante evaluar qué tecnologías están siendo utilizadas por las aplicaciones. La típica aplicación hace uso de variastecnologías para la seguridad, el almacenamiento en caché, la inyección, etc. Estas tecnologías están en gran medida ocultas al desarrollador y podrían no ser conscientes de ellas, pero pueden tener un impacto importante en el rendimiento y la escalabilidad.

El no poder planificar la migración de estas tecnologías puede crear graves problemas. Además, estos problemas generalmente surgen al final de un proyecto de migración en las pruebas de rendimiento se llevan a cabo.

Un análisis esencial es la identificación de librerías propietarias usadas por la aplicación. JBoss proporciona el Migration Analysis Tool (MAT) para estimar la cantidad de código propietario que habrá que migrar a alternativas Open Source.

Fase II:Mapeo común de aplicaciones

Componente Funcionalidades JBoss EAPMonitorización y Management Control remoto y configuración,

alertas.Consola de administración JBoss, interfaz JMX, alertas.

Servidor Web Contenedor de servlets, replicación de estado.

Tomcat, replicación.

Mensajería JMS. Persistencia de mensajes. Puentes entre clusters.

JBoss messaging

Cache Transaccional. Distribuido. Grafos. JBoss cache, replicación.

Clustering Replicación transaccional. JBoss cluster, JGroups.

Persistencia BB.DD. Sistemas de ficheros. Almacenamiento no relacional.

JDBC, connection pooling, Hibernate.

Seguridad Autentificación. Single sign-on. JAAS. JACC. Certificados.

JAAS, LDAP, SSO.

AOP Cross-cutting concerns JBoss AOP.

Inyección Soporte estándar de inyección Estándares de inyección JEE.

JSP, JSF, Facelets, tags Compatibilidad y soporrte para los estándares de presentación

Soporte de estándares comunes

Transaction Manager Transacciones fiables, distribuidas JBoss transactions

Fase III:Estimación de esfuerzo y riesgo técnico

Tras estudiar la arquitectura de despliegue y el inventario de aplicaciones y tecnologías a migrar, se está es disposición de estimar el esfuerzo y riesgo de la migración. Factores para los cuales se debe medir tanto la parte técnica como la organizativa. Enfocándose en los siguientes puntos:

1.Análisis Técnico

• Ámbito

• Nº de servidores, centros de datos y aplicaciones a migrar

• Análisis del «technology gap».

• Funcionalidades que no se mapean de forma natural a componentes Open Source

• Requerimientos conflictivos de configuración

• Adhesión a estándares

• Uso de IDEs propietarios que usan librerías propias

• Selección de librerías

Fase III:Estimación de riesgo organizativoCon frecuencia, los factores organizativos son más difíciles de prever que los técnicos. Es relativamente sencillo definir y tratar problemas técnicos. Mas los factores organizativos tienden a ocultarse bajo la superficie de una forma en la que aparentes pequeñeces pueden convertirse en barreras infranqueables. Cuando esto sucede, la empresa acaba más preocupada de los inconvenientes a corto plazo que de los beneficios y oportunidades a largo.

2.Análisis Organizativo

• Necesidades de formación y conocimientos

• Tendencia espontánea del staff a cambiar

• Procesos actuales de desarrollo y despliegue

• Carga de trabajo general con proyectos y soporte

• Capacidad para acometer el sobreesfuerzo de la migración

• Disponibilidad de suficiente hardware para las pruebas y la migración

• Jerarquía y procedimientos para la toma de decisiones

• Consideraciones de calidad versus coste

• Contratos existentes con proveedores

• Métricas financieras: CAPEX, OPEX, TCO, ROI

• Balanza de poderes en la organización

Fase III: DAFO (ejemplo)

DebilidadesDebilidades

OportunidadesOportunidades

AmenazasAmenazas

FortalezasFortalezas

• Bajo presupuesto• Sobrecarga de trabajo• Entornos de desarrollo propietarios• etc.

• Procedimientos complejos de despliegue• Imposibilidad de hacer ningún cambio hardware• Presupuesto cero para formación• etc.

• Staff con mucha experiencia• Fuerte compromiso gerencial• Todas las apps en formato WAR o EAR• etc.

• Reconfiguración dinámica de servidores• Introducción de nuevos estándares• Simplificación de licencias

Fase III: Plan de Contigencia (ejemplo)

Riesgo Probabilidad Impacto Plan

Deficiente Formación Alta Alto Reasignar parte del presupuesto de soporte a horas de formación

Insuficientes servidores para pruebas

Media Medio Sistemas cloud en alquiler por uso

Entornos de trabajo propietarios

Media Alto Emplear todo el tiempo que sea necesario en análisis de librerías y dependencias.

Fase IV: Plan de Migración

Una vez que se ha evaluado el esfuerzo y el riesgo hay que definir los Entornos Operativos Estándar de origen y destino. Debe estar perfectamente definido sin ninguna ambigüedad qué componentes habrá en cada entorno incluyendo la versión exacta de cada uno de ellos. En algunos casos, puede que se requieran más de dos entornos operativos, aunque siempre se debería tratar de mantener la variedad de configuraciones en el mínimo posible.

Una vez que se tienen los Entornos Operativos Estándar hay que definir la configuración de origen y destino para cada aplicación.

Lo siguiente es hacer un cálculo de costes sobre lo siguiente:

•Cuánto cuesta el hardware necesario para la migración y durante cuánto tiempo hará falta.•Cuánto cuesta desarrollar extensiones para reemplazar software privativo que se dejará de usar.•Estimación de las horas hombre necesarias por aplicación, en función sobre todo de si únicamente requieren cambios en la parametrización o por el contrario es preciso tocar también el código fuente.•Cuánto cuesta la formación.•Cuántas horas y personas habrá que emplear en reuniones y revisiones de proyecto.•Quién fijará y controlará los hitos de migración.•Cual será el protocolo de escalado de incidencias.

Fase V: Migración

La migración en sí misma se planifica y gestiona mediante técnicas y herramientas estándar de gestión de proyectos de desarrollo y despliegue de software.

Todas las buenas prácticas de gestión de proyectos son, en general, aplicables, siendo preferibles, por ejemplo, los hitos relativamente cortos con revisiones frecuentes de desviaciones, colocar las tareas más largas y de mayor riesgo al principio del proyecto, llevar el mínimo de proyectos en paralelo asignados a los mismos recursos humanos, ir consiguiendo pequeñas victorias técnicas y organizativas, etc.