Recomendaciones de administración de Oracle SOA Suite 11G. Parte 1 de 2

Desde hace varios años he estado trabajando con la Plataforma de Oracle SOA Suite 11g. Prácticamente desde que Oracle la liberó en 2008. Realmente ha sido una Suite que ha mejorado con cada reléase; cada vez mas estable; cada vez con mayor cantidad de features y mejoras que la hacen única en el mercado y en ocasiones incomparable por sus funcionalidades.

En sistemas en Producción es fundamental entender cómo se debe administrar esta Plataforma. En muchos clientes me ha tocado que , dada la complejidad de su estructura organizacional, hay diferentes áreas que tienen que ver con los ambientes Productivos, pero ninguna de ellas tiene la experiencia para administrarla. O bien, simplemente el cliente requiere de recibir el desarrollo y ellos administrarlo. Por lo que es indispensable poder explicarles la complejidad de la administración y la relevancia de la misma.

Es todo un reto identificar, en esos casos, cómo deben de abordar la administración de SOA Suite.

Lo primero que debemos hacer es entender su Arquitectura, para así identificar a los roles que más se asemejen a las actividades que se hacen en cada capa y así irlas asignando.

En este artículo se identificar varios de estos elementos, así como dar recomendaciones de los puntos más relevantes a administrar y a mantener.

Un diagrama lógico de la Arquitectura de SOA Suite, es el siguiente:

En este diagrama podemos identificar varias capas:

1. OHS
2. Coherence
3. Weblogic Domain
4. SOA-INFRA
5. TLogs de JMS
6. Oracle RAC
7. Capas de Firewall

En efecto, en un ambiente Productivo, todo estos elementos están presentes, y seguramente más, por ejemplo: Un Storage Compartido, probablemente el uso de Service Bus, Oracle Grid Control, Oracle SOA Management Pack. Pero en este artículo nos vamos a orientar a la SOA Suite en sus componentes comunes.

De la lista anterior, podemos comentar lo siguiente:

Para el OHS: Regularmente en cualquier cliente, existe por lo menos un Web Server a administrar. Este no deja de ser un Apache. Obviamente tiene algunos mapeos configurados para las Aplicaciones de la SOA Suite , sin embargo no tiene nada en particular que debamos atender de manera diferente que a otros Apache

• Para el OHS: Regularmente en cualquier cliente, existe por lo menos un Web Server a administrar. Este no deja de ser un Apache. Obviamente tiene algunos mapeos configurados para las Aplicaciones de la SOA Suite , sin embargo no tiene nada en particular que debamos atender de manera diferente que a otros Apache
• Coherence: Este es usado para dos cosas: o Como parte de la infraestructura para lograr el Clúster de SOA Suite. Este elemento nos sirve para propagar despliegues, así como propagar algunos elementos de administración. o Como Caché de los resultados de los Servicios expuestos para Service Bus. Si esto es ampliamente usado en su caso, realmente hay bastante qué revisar en esta capa. De entrada, se recomienda tener un caché por separado de la JVM sobre la cual corre el Service Bus
• Weblogic Domain: Es el dominio sobre el cual estará ejecutándose la SOA Suite y el Service Bus. Pudiera ser uno solo, o bien dos. Dependiendo de cómo se haya diseñado al Sistema. Lo relevante es entender que es un domino de Weblogic. Si en tu caso ya has administrado a Weblogic, entonces no hay mucha diferencia en términos de : Admin Server, Managed Servers, Node Manager. Es importante entender que la SOA Suite es una aplicación sobre Weblogic, por lo que mientras entiendas la administración de éste, estás del otro lado. Esto nos lleva a concluir que subir, detener, poner en pausa los servicios, es equivalente a cualquier Weblogic que hayas utilizado.
• SOA-INFRA: Este sí es un elemento nuevo para alguien que recibirá esta plataforma como parte de sus responsabilidades de administración. LA SOA-INFRA es propiamente la aplicación que representa a la SOA SUITE. Adentro de ella se ejecutan los engines de: Human Workflow, BPEL, Mediator. Como parte de ella, también podemos reconocer a Web Services Manager y sus capacidades de Policy Enforcement. También , parte de ella, tenemos al componente de Business Rules.
• Oracle RAC: Esta es un RAC convencional, sin embargo , la base de datos de la SOA Suite es un elemento super crítico para la plataforma. Una buena cantidad de problemas de performance, de mantenimiento y propiamente de uso de la Suite, están asociados a una mala administración de este elemento. No sé por qué pase, pero regularmente en las organizaciones no le ponen atención a este elemento; siendo que el fundamento para que la gran mayoría de los componentes del a Suite , funcionen, es justamente la base de datos. Mas adelante vamos a ver cuáles son los puntos relevante en relación a la administración de este engine de base de datos
• TLogs de JMS: Aquí hay de dos opciones: Base de datos o bien dejarlos en FileSystem. Esta es configuración, simplemente
• Firewall: Igualmente, este es un punto que en las organizaciones no lo afinan bien, y se dan problemas de múltiples tipos. Para evitarlos, hay que tener claro los puertos a aperturar, los protocolos que se usarán; tener siempre un diagrama de red y de despliegue que soporte lo que se va a instalar.

A continuación se muestra un diagrama de despliegue. Del siguiente diagrama, enfoquémonos a la parte de en medio. La parte de la izquierda, es considerando un despliegue que haga uso de los componentes de Seguridad de Fusion Middleware. Pero el alcance de este artículo está enfocado a los elementos de SOA Suite.

Regularmente sugiero que se realice un diagrama similar a este, pues de esta manera, si es necesario compartir con Oracle lo que se está haciendo, será consistente con lo que el propio fabricante sugiere. Este diagrama es tomado de esta URL: http://docs.oracle.com/cd/E23943_01/core.1111/e12036/intro.htm#CHDCCFCC

En el diagrama podemos identificar los Managed Serves que se generarán, así como los puertos a través de los cuales se comunican las diferentes capas. La sugerencia de Oracle de cómo hacer uso de la seguridad a través de los Firewall, etc.

Una vista lógica de lo que quedará instalado, se puede ver a continuación:

De las tres capas fácilmente identificables en los tres diagramas que hemos venido revisando, podemos ver: Web Tier (OHS), Application Tier(Weblogic Domain) y Metadata Repository (Oracle DB c/s RAC).

Es bueno entender la distribución de las carpetas, pues a partir de ellas, se podrá tener acceso a logs, archivos de configuración, etc.

Es un hecho que en relación de Base de Datos es en donde mas conocimiento debe haber en las organizaciones. Por lo que esa capa es la que debe estar mejor cubierta, de arranque. Solo tener en consideración algunas sugerencias que pondré mas adelante en este artículo.

Sugiero que hagas un diagrama como el anterior y adjuntes la información de dónde quedó instalado el Software: File System, Carpetas , Middleware Home, SOA Home, etc.

El siguiente diagrama debe servir para identificar las IPs y nombres de los managed servers de tus ambientes, por ejemplo:

Siempre busca tener el Admin Server en una máquina separada. Si no tienes una máquina para esto, entonces deberás tener un Fail Over para el Admin Server, en los mismos nodos donde están los managed Servers. En el diagrama vemos a un dominio de SOA Suite (sin OSB), en donde tenemos un clúster de dos nodos. A su vez, vemos que existe un Oracle RAC.

Utiliza un diagrama similar, para representar a tu dominio y coloca los nombrs/IPs de las máquinas, y sus puertos.

El equivalente para Service Bus, es el siguiente:

¿Cómo saber si la plataforma está activa?

Existen varias forma de saber si la infraestructura de SOA está activa. La mas simple, es entrar tanto al Weblogic Console como al Enterprise Manager.

Entrar al Enterprise Manager puede ser lo mas rápido y efectivo. Pues en una sola vista lo podrás saber. Se puede monitorear la infraestructura de SOA en su totalidad, eso hace muy práctica la forma de uso de EM

Entrar al Weblogic Console es también una buena forma, pero hay que revisar más cosas.

Una vista del Enterprise Manager, es la siguiente:

Hay varios puntos a resaltar de la imagen anterior:

1. De la parte a la extrema izquierda, podemos ver que existe una carpeta de nombre SOA. Este es un buen parámetro para validar que la SOA-INFRA está activa. Esto no quiere decir que los Servicios estén ejecutándose bien, pero al menos sabrás que la SOA-INFRA está activa
2. En la parte derecha de la imagen vemos dos Gráficos. El primero te dirá los despliegues activos e inactivos que tiene tu ambiente.
3. La segunda imagen, te dirá el estado de salud de los managed servers de este dominio. Ahí verás al soa_server, bam_server, osb_server . Dependiendo de tu despliegue

Las gráficas pueden ser engañosas, pues la del extremo derecho puede estar toda en verde, y la primera puede tener varios en rojo. Es quiere decir que si bien los servidores están arriba, no así los Servicios/Compuestos que están desplegados encima de ellos.

En el caso del Weblogic Console, tendrás una vista similar a la siguiente:

Esta vista te dejará ver el estado de los Servidores (a la derecha de la imagen). También podrás tener una vista rápida del estado del Sistema, en la gráfica de la parte inferior izquierda. Teniendo esta vista, un administador podrá estar tranquilo de que al menos los managed servers están activos y ejecutándose.

Otra alternativa para validar que la SOA-INFRA está activa, es la siguiente: Entrar a http://maquina:puerto/soa-infra (donde máquina es la IP o nombre donde tu SOA Suite está corriendo, y el puerto es el del Managed Server). Al entrar, te pedirá el user y password de administrador, y te deberá desplegar lo siguiente:

Si ves este mensaje, y además a tus compuestos listados en la parte de abajo, quiere decir que tu SOA- INFRA está activa.

Monitoreo de memoria y threads

Un elemento que es esencial a estar monitoreando en esta plataforma, es el uso de Memoria y la cantidad de Threads que el Servidor esté manejando, siempre buscando que no estén atorados.

Una manera de estar monitoreando el uso de memoria, es entrar al Weblogic Console e irse directo al servidor en cuestión:

Ahí tendrás el Heap que tiene asignado dicho servidor, así como el utilizado, el porcentaje libre. Para los Trheads, es básicamente esa misma pantalla pero el pestaña de Threads:

Una vista rápida es fijarse en la última columna: Health. Ahí verás si todo está bien, o hay algo extraño de lo cual nos debamos preocupar. En condiciones normales, esto siempre debe estar en OK. Si se va a WARNING puede ser que uno o varios hilos hayan llegando al límite de tiempo en el que se les considera como activos y pasen a bloqueados. No debemos de tener threads bloqueados.

Algunos tips adicionales, son:

• Revisar el Enterprise Manager constantemente, y validar el estado de salud del Server
• Revisar el uso de Memoria y Threads de los Servers (sobre todo osb_server1 y 2, soa_server1 y 2, bam_server 1 y 2. Pues si algo se está poniendo crítico en cualquiera de estos, podemos tener problemas.
• No necesariamente si en el Weblogic aparece el soa_server1 ó soa_server2 en RUNNING, quiere decir que la SOA-INFA está corriendo. Hay que validar con el EM, o con la URL mencionada anteriormente.
• Otra forma es tener un Servicio de Estatus. Que se pueda consumir y también así compruebes que el Engine está activo. Este es algo que pudiera llegar a servir, pero desde mi punto de vista es algo conservador.

Cabe resaltar que todo esto que hemos revisado, aplica muy bien a la SOA- INFRA. Si en tu infraestructura tienes a Oracle Service Bus también como parte medular de tu arquitectura, entonces considera lo siguiente:

Para saber si el Server de OSB está activo, revisa el Weblogic Console:

Esta vista nos da el estado de salud de todo el dominio del Service Bus. Podemos ver el estado del Sistema en la parte inferior izquierda. Así como el estado del Admin y del Managed Server.

Ubicación de Logs

• Los logs están abajo del server manejado de Weblogic. En este sentido no hay diferencia con cualquier otro Weblogic que estén administrando.
• También se pueden ver a través del EM. A continuación se mostrará un screen-shot. Pero por facilidad se recomienda usar línea de comando, pues el EM es muy lento en ese sentido.
• Se recomienda revisar el .out y el diagnostic. Esto en cualquier caso: BAM, OSB, SOA.
• También se recomienda revisar el log del dominio.
• Los logs más críticos serán el de OSB y SOA. Cuando BAM tenga carga y realmente se le de uso, ese será también un elemento crítico a monitorear.

Si prefieres hacer uso de un ambiente gráfico para mirar los logs, entonces el Enterprise Manager te puede servir.

Los logs son los mismos que en cualquier dominio de Weblogic. No es que la SOA Suite tenga sus propios logs.

La opción de usar el EM para ver los logs no es mala, pero es lenta. Puede servir en caso de que no tengas acceso a la línea de comando, pero tengas que revisar algo con urgencia. Pero insisto, es una opción relativamente lenta.

Parametros importantes

A continuación se compartirán algunos parámetros que considero importantes revisar, afinar y monitorear en tu ambiente de SOA Suite.

• JVM Memory (Xms1280m -Xmx1280m -XX:MaxPermSize=512m -Xss128k)
• JVM Garbage Collection (-XX:-UseParallelGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing)
• Datasources: MaxOpenConn, MinOpenConn, Timeouts
• Threads. Cantidad de Threads. Tiempo de vida de los Threads
• EJB. Particulares para BPEL:
  o BPELActivityManagerBean
  o BPELDeliveryBean
  o BPELDispatcherBean
  o BPELEngineBean
  o BPELFinderBean
  o BPELInstanceManagerBean
  o BPELProcessManagerBean
  o BPELSensorValuesBean
  o BPELServerManagerBean
• SOA ENGINE: spInvokeThread, dspEngineThreads, dspSystemThreads, synMaxWaitTime
• JTA: 3600

Típicamente esos son los parámetros y elementos a considerar para una afinación particular en un ambiente de este estilo.

En el caso de los parámetros de la JVM, hay que considerar que estos ambientes son muy transaccionales. No es sano mover a cada rato estos parámetros, ni tampoco tratar de afinarlos previo a que realmente compruebes la carga que recibirá tu sistema.

Este es un tema muy relevante, pero que requiere de mucho monitoreo y paciencia. En futuros artículos hablaremos en específico de la JVM. Pero para este artículo, lo importante es lo tradicional: Heap, PermSize, GC alghorythm.

Hablando de los Datasources, los parámetros que se listaron son los que debes de afinar para los datasources que ocupa la plataforma. La lista de Datasources que sugiero revises constantemente, son los siguientes:

• EDNDataSource
• EDNLocalTxDataSource
• mds-owsm
• mds-soa
• OraSDPMDataSource
• SOADataSource
• SOALocalTxDataSource

Existen parámetros particulares de la Plataforma, como los que vienen enlisados en el bullet de SOA ENGINE. Todo esto se configura en el Enterprise Manager. Aquí puedes encontrar una definición de estos parámetros http://docs.oracle.com/cd/E21764_01/core.1111/e10108/bpel.htm

Despliegues a tomar en cuenta

Los despliegues que la SOA Suite dejará disponibles para su uso y que son parte del Engine, son los siguientes:

• DBAdapter
• FTPAdapter
• OracleBAMAdapter
• EM
• Soa-infra
• composer
• Usermessagingdriver-email
• Usermessagingserver
• Wsil-ws
• DMS Application

Son una mezcla de Aplicaciones Web (Enteprise Manager, por ejemplo), con librerías y con adaptadores. De éstos últimos, únicamente listé algunos, pero la plataforma ofrece más.

La intención de mencionar estos despliegues, es que tomes en cuenta que esto también se debe administrar. La mas importante es la SOA-INFRA, esta es la aplicación que representa al Engine, si esta tiene problemas, simplemente la plataforma no funcionará.

En el caso de los Adaptadores, también debes de tener atención, pues si tus compuestos o los compuestos que se ocupen en tu organización hacen uso de algunos de estos adaptadores, entonces el conocer el estado de salud de ellos, se vuelve relevante. Igualmente tener controlados los planes de despliegue es crítico. Sugiero que por cada Adaptador generes su propio plan de despliegue y éste lo tengas siempre respaldado para poder recuperar la configuración en caso de alguna falla.

En caso de que sea un clúster, estos planes ponlos en un storage compartido entre los nodos de tu cluster, pues así no tendrás que estarlos replicando entre ellos.

En el caso del Service Bus, te sugiero tener en cuenta los siguientes despliegues:

Todas aquellas que empiecen con ALSB. Por ejemplo:

• ALSB Logging
• ALSB Publish
• ALSB Transform
• ALSB WSI

Los Adapters que se usen. Por ejemplo:

• DBAdapter
• FTPAdapter
• OracleBAMAdapter

Si estás usando el Service Bus en el mismo dominio de Oracle SOA Suite, entonces los adaptadores serán los mismos. Es decir, serán el mismo despliegue. Pero si están en dominios separados, entonces los tendrás que administrar de manera individual.

Técnicas para levantar los servidores asociados a la plataforma soa

La más fácil es a través del Weblogic Console, siempre y cuando el Node Manager esté funcionando. Esto no es diferente a cualquier otro WL que actualmente administren.

También se puede hacer desde el EM, pero igualmente es necesario el NodeManager

O bien, haciendo uso de la línea de comando. Esto es recomendado para PROD a través del WLST. Se pueden crear scripts para poder levantar y tirar, y no tener que usar la Web.

Todo esto dependerá de las políticas que se tengan en tu organización. Regularmente sucede que en ambientes Productivos, los operadores tienen acceso a línea de comando y desde ahí administran a las plataformas que tienen bajo su cargo. SOA Suite no debe ser la excepción, por lo que el uso del WLST es muy común que se utilice.

En el caso de Weblogic Console y/o Enterprise Manager, sin duda son opciones válidas y regularmente en ambientes de Pruebas, Desarrollo, QA es un mecanismo que se ocupa con regularidad.

Por ejemplo, desde el Enterprise Manager:

Ahí tendrás control por cada uno de los MAnaged Servers.

Desde el Weblogic Console:

Desde línea de comando, pero sin usar WLST, sino los scripts que vienen fuera de la caja con el producto, puedes usar lo siguiente:

nohup ./startWebLogic.sh > weblogic.out nohup ./startWebLogic.sh -Dweblogic.management.username=weblogic -Dweblogic.management.password=welcome1 > weblogic.out & nohup ./startManagedWebLogic.sh soa_server1 http://10.10.10.1:7001 -Dweblogic.management.username=weblogic -Dweblogic.management.password=welcome1 > soabpm.out & nohup ./startManagedWebLogic.sh bam_server1 http:// 10.10.10.1:7001 -Dweblogic.management.username=weblogic -Dweblogic.management.password=welcome1 > bam.out &

La gran desventaja que tiene esto, es que el archive al cual mandes la salida de los scripts , provocará que el archivo crezca desmedidamente.

Usando WLST:

Ir a $FMW_HOME\wlserver_10.3\server\bin . Arrancar WLST con java weblogic.WLST Usar los siguientes comandos: nmConnect('usuarioAdministrador','pwdAdmon','maquina', ‘puertoNodeMngr’,'soa_domain'). Después usar el nmStart('AdminServer') Después usar el nmStart('soa_server1')

NOTA:

Cambiar los datos de Puerto y demás que apliquen al ambiente. Con esto se puede levantar cualquier servido, pero depende del NodeManager

Rolando Carraso (Oracle ACE) es Director de Oracle Fusion Middleware en S&P Solutions (México). Rolando tiene una carrera de mas de 13 años con tecnología Oracle. Toda su carrera profesional la ha dedicado a la ejecución e investigación de tecnologías que permita la integración de Aplicaciones. Especializándose en la Arquitectura Orientada a Servicios (SOA), tanto metodológicamente como técnicamente. Rolando es coordinador del Grupo de Usuarios de Tecnología en México (ORAMEX). Grupo fundado desde 2012, en conjunto con Plinio Arbizu (Oracle ACE Director).