Implementación de Shared Application Tier en e-Business Suite R12

Por Francisco Riccio
Publicado en marzo 2013

Introducción

Shared Application Tier es un feature que tenemos en e-Business Suite disponible desde la versión 11i (11.5.10). Este feature nos permite compartir los archivos y directorios de las aplicaciones y de los productos de tecnología en un repositorio centralizado mediante NFS entre diferentes servidores de aplicación, tendiendo la siguiente arquitectura:

Arquitectura de Shared Application Tier
Arquitectura de Shared Application Tier

Se puede apreciar que los módulos de aplicación (APPL_TOP) y los productos de tecnología (Oracle Application Server 10gR2 y 10gR3) están en un repositorio centralizado y en cada servidores solo se aloja los archivos propios de la instancia de EBS que no ocupa mucho espacio.

Esta arquitectura tiene las siguientes ventajas:

  • Reducir el consumo de espacio: Ahorro de espacio al tener un espacio centralizado para todos los servidores de aplicación.
  • Reducir el tiempo de parchado: Solo se aplica el parche en una de las instancias.
  • Simplifica la administración: Solo se revisa en un solo lugar en caso de problemas al no tener diversas copias como se tendría en una configuración por default.

El repositorio centralizado es el único punto de falla de toda la solución, logrando que todos los nodos de aplicación dejen de funcionar automáticamente, esta es un desventaja a considerar.

Cabe mencionar que este feature no está disponible para plataforma Windows asimismo cada nodo de aplicación debe tener la misma versión de sistema operativo.

Implementación

La implementación que mostraré está basado en la versión e-Business Suite R12 (12.1.1) y la base de datos en versión (11.1.0.7) ambos en plataforma Linux x32 bits. La implementación inicial es una solución single node (capa de aplicación y de base de datos en el mismo equipo).

El objetivo final será migrar el escenario actual hacia un ambiente Shared Application Tier donde tendremos 2 servidores de aplicaciones (pcebs1.riccio.com y pcebs2.riccio.com).

El nombre de la instancia de la aplicación y de la base de datos se llama VIS.

Paso 1:

En la capa de aplicación debemos ejecutar el comando:

perl $INST_TOP/admin/scripts/adpreclone.pl appsTier

Ejemplo:

ejecutar comando

Este comando preclona la capa de aplicación para posteriormente poder realizar una clonación.

Paso 2:

Debemos registrar las ubicaciones de los componentes que serán trasladados al repositorio centralizado.

registrar las ubicaciones

Además debemos registrar la ruta del Oracle Application Server 10gR2. En mi implementación es la ruta:

/u01/oracle/VIS/apps/tech_st/10.1.2

Paso 3: Cada servidor debe poder resolver la IP de cualquier de los servidores de aplicaciones que formaran la solución de Shared Application Tier.

Esto lo realizamos registrando cada servidor de aplicación en el archivo /etc/hosts.

Ejemplo:

registrando cada servidor de aplicación

Otra opción es trabajar con un servicio DNS.

Paso 4:

Implementamos el servicio NFS que en mi caso se alojará en el mismo servidor donde se encuentra la solución de e-Business Suite (pcebs1.riccio.com).

a) Configuramos el archivo /etc/exports:

Configuramos el archivo /etc/exports

En mi implementación la carpeta /u01/shared será el repositorio compartido.

Es importante que coloquemos los atributos que tendrá el recurso compartido tal cual como está mostrado en el ejemplo. Oracle requiere esa configuración para un correcto funcionamiento.

b) Levantamos el servicio NFS:

servicio NFS

c) Validamos que el recurso esté publicado:

Validamos

d) Montamos el recurso compartido:

Modificamos el archivo /etc/fstab para registrar el punto de montaje del recurso compartido.

Servidor: pcebs1.riccio.com

pcebs1.riccio.com

Servidor: pcebs2.riccio.com

pcebs2.riccio.com

El atributo: rw,bg,hard,rsize=32768,wsize=32768,vers=3,nointr,timeo=600,tcp en el punto de montaje es obligatorio para un correcto funcionamiento.

Luego en cada servidor ejecutamos el comando: mount -a y debemos ver el punto de montaje con el comando df -h, ejemplo:

ejecutamos el comando

Paso 5: Movemos todas las carpetas que fueron registradas en el paso 2 hacia el repositorio compartido. En mi caso el repositorio compartido es el directorio /u01/shared pero el directorio que monta este recurso en cada servidor de aplicaciones se llama /u01/nfs.

Paso 6: Ejecutamos una post clonación en el servidor de aplicaciones.

Ejecutamos una post clonación en el servidor

En la pantalla adjunta se puede apreciar que las rutas de aplicaciones y los programas de tecnología hacen referencia al directorio que monta el repositorio compartido. Asimismo es importante que el programa de post clone se ejecuta desde su nueva ubicación: /u01/nfs/VIS/comn/clone/bin.

Hasta este punto ya tenemos nuestra solución migrada a Shared Application Tier, los pasos que vienen a continuación agregarán el segundo nodo de aplicación utilizando este feature.

Paso 7: Aquí recomiendo volver a pre clonar la capa de aplicación.

volver a pre clonar la capa de aplicación

Paso 8: Procedemos a copiar el archivo de Contexto ($CONTEXT_FILE) hacia el nuevo servidor de aplicaciones que se sumará a la solución.

En este caso copiamos el archivo $CONTEXT_FILE hacia el segundo servidor.

copiamos el archivo $CONTEXT_FILE

Paso 9: En el nuevo servidor de aplicaciones, ejecutamos el siguiente comando:

perl adclonectx.pl addnode contextfile=<CONTEXT_FILE>

Este script creará un archivo de Contexto con su propia configuración para el nuevo servidor de aplicaciones.

Ejemplo:

configuración para el nuevo servidor de aplicaciones

Paso 10: Debemos validar que el atributo "s_atName" en el archivo de Contexto tenga el mismo valor en todos los servidores de aplicación.

validar el atributo s_atName

Paso 11: Ejecutamos un autoconfig en el nuevo servidor de aplicaciones utilizando el nuevo archivo de Contexto creado en el paso 9.

Ejecutamos autoconfig

Paso 12: Validar que se haya creado la carpeta de la instancia de la aplicación en discos locales. En mi caso se evidencia que la carpeta inst no se encuentra en el repositorio compartido.

Validar que se haya creado la carpeta

Paso 13: Debemos ejecutar el comando de autoconfig en cada nodo que conforma la solución.

En mi caso lo ejecutaré en el servidor pcebs1.riccio.com.

ejecutar servidor

Este paso no es necesario ejecutarlo en el nuevo servidor de aplicaciones añadido ya que este paso se hizo en el paso 9.

Algo que es importante que la carpeta de logs y outs de los concurrentes se encuentren en la misma ruta en cada servidor de aplicaciones.

Paso 14: Probamos los servicios web.

Servidor: pcebs1.riccio.com

Probamos los servicios web

Servidor: pcebs2.riccio.com

Probamos los servicios web

Se evidencia que el servicio de Apache está funcionando en cada servidor.

Posterior a esta configuración podemos realizar otros tipos de configuraciones como:

  • Balanceo de carga del servicio de Apache.
  • Balanceo de carga mediante Oracle Application Server Clustering.
  • Procesamiento de Concurrent requests en diferentes nodos de aplicación.
  • Habilitar en más de un servidor el módulo de administración.

Si estamos en una implementación nueva y deseamos contar con Shared Application Tier desde el inicio, adjunto las pantallas de instalación donde deberá realizarse ciertos cambios:

Paso 1: En la pantalla de configuración de la capa de aplicación debemos ubicar el directorio de las aplicaciones y de los productos de la tecnología en el directorio que monta el repositorio compartido, en mi caso: /u01/nfs

 ubicar el directorio de las aplicaciones

Paso 2:

 Paso 2

 Paso 2

Paso 3: Es importante que cada punto mostrado por el instalador esté con un check de color verde.

 Paso 2

Conclusión

El objetivo de este artículo es mostrar los pasos que se deben realizar para poder implementar una solución de e-Business Suite que tendrá múltiples servidores de aplicación con la finalidad de un balanceo de carga con una configuración Shared Application Tier. Asimismo se ha indicado las ventajas y desventajas que debemos tener en cuenta si optamos por implementarlo.


Publicado por Ing. Francisco Riccio. Es un IT Specialist en IBM Perú e instructor de cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y certificado en productos de Oracle Application & Base de Datos.