Implementación de Shared Application Tier en e-Business Suite R12
Por Francisco Riccio
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
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.
1
• 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.
2
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:
Este comando preclona la capa de aplicación para posteriormente poder realizar una clonación.
3
Paso 2:
Debemos registrar las ubicaciones de los componentes que serán trasladados al repositorio
centralizado.
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:
Otra opción es trabajar con un servicio DNS.
4
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:
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:
c) Validamos que el recurso esté publicado:
d) Montamos el recurso compartido:
Modificamos el archivo /etc/fstab para registrar el punto de montaje del recurso compartido.
Servidor: pcebs1.riccio.com
Servidor: pcebs2.riccio.com
5
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:
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.
6
Paso 6: Ejecutamos una post clonación en el servidor de aplicaciones.
7
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.
8
Paso 7: Aquí recomiendo 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.
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.
9
Ejemplo:
10
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.
Paso 11: Ejecutamos un autoconfig en el nuevo servidor de aplicaciones utilizando el nuevo archivo de
Contexto creado en el paso 9.
11
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.
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.
Este paso no es necesario ejecutarlo en el nuevo servidor de aplicaciones añadido ya que este paso se
hizo en el paso 9.
12
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
Servidor: pcebs2.riccio.com
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.
13
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
14
Paso 2:
15
Paso 3: Es importante que cada punto mostrado por el instalador esté con un check de color verde.
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.
e-mail:
[email protected]
web: www.friccio.com
16
Comentarios de: Implementación de Shared Application Tier en e-Business Suite R12 (0)
No hay comentarios