miércoles, 6 de febrero de 2013

WebCenter Portal: Configuración de alta disponibilidad

Las etapas que se siguen en la mayoría de proyectos es la siguiente:
  • Desarrollo en entorno local e integración de los desarrollos en un entorno de desarrollo común. Este entorno normalmente suele ser standalone.
  • Entorno de test o certificación. En algunas ocasiones este entorno es standalone y en otras ocasiones es una simulación real del entorno productivo, por lo que es un entorno en clúster.
  • Entorno productivo. Normalmente suele ser un entorno en clúster.
El motivo de esta entrada no es otro que asegurar, desde el principio del desarrollo, que los desarrollos ADF (Task Flows, WebCenter Portal Application...) estén preparados para ser ejecutados independientemente del entorno.

¿Qué se debe cambiar de la configuración de las aplicaciones ADF desplegadas en entornos en clúster?.
  •   adf-config.xml. En el fichero de configuración de ADF debe habilitarse la posibilidad de que el framework haga un seguimiento y replique los manage beans en el clúster. Esto se consigue añadiendo:
    
      
        true
      
    

    ¿Por qué habilitar la alta disponibilidad de los manage-beans?  
    En ADF existen los siguientes ámbitos de manage bean:
    •  backingBean: Es el más pequeño de todos. Su duración es el de una petición (request) en una página o fragmento. Suele utilizarse para el manejo de componentes ADF de una página. Recordar que los UIComponent de ADF son objetos NO serializables.
    • request: Al igual que en backing bean, la duración es de una petición (request). Sin embargo, a diferencia de backing, los objectos en request scope pueden ser rescatados por Task Flow o fragmentos incluídos en la página.
    • view: Es el primer scope que va más alla de una petición. El ámbito de la viewScope va directamente relacionada con el viewId actual de la página. Hasta que no se cambia de viewId no se destruye el manage-bean perteneciente a este ámbito.
    • pageFlow: Este scope hace que el manage bean se mantenga vivo durante todo el flujo de páginas de un Task Flow (unbouned o bounded). Hay que recordar que cada pageFlowScope es local a cada Task Flow.
    • session: Como su propio nombre indica su periodo es el de una sesión HTTP con la aplicación. Esta información también debe ser serializada.
    • application: Su periodo de vida va relacionado desde que arranca hasta que se para una aplicación. Estos beans comparten la información a todos los usuarios.

    Como se puede comprobar, al menos 4 ámbitos de manage-bean son mayores que la duración de una petición (request). Esto significa que estos manage-bean (view, pageFlow, session y application) deben ser serializables para poder ser replicados en las distintas instancias de un clúster.

    Imaginemos en caso de que no se replicara la información. Si un usuario está interactuando con la página X, servida por la máquina A y por algún motivo la máquina A deja de ofrecer sevicio. El balanceador de carga asignará al usuario algún nodo o máquina que pueda seguir sirviendo las peticiones del usuario. En el caso de no haber serializado la información en el clúster, el usuario percibirá errores puesto que la información no se encuentra actualizada en la máquina B.

    Para serializar un bean basta con que implemente la interfaz java.io.Serializable y que todos sus atributos sean Serializables. Remarco esto último porque, aunque un bean implemente Serializable y se le asigne un serializationUID, si alguno de sus atributos internos NO es Serializable (ya sea un UIComponent o algún otro objeto) entonces hace que este bean no sea realmente Serializable.
  •   public class MiBean implements Serializable {
         // All attributes serializable
         String name;
         ...
      }
    
    
  • weblogic.xml: No basta con únicamente establecer la alta disponibilidad del framework ADF. Se debe configurar también como se va a llevar a cabo la replicación y serialización de información entre entornos. Por defecto viene configurado como MEMORY. Lo que quiere decir que guardará en memoria local los estados de los manage-bean. Esto solo vale para entornos standalone. Para entornos clúster se recomienda la configuración REPLICATED_IF_CLUSTERED. Es un comodín, dado que si se despliega en un servidor standalone, éste actuará como si fuera configurado como MEMORY. Sin embargo, si es desplegado en clúster replicará la información entre todos los nodos del clúster.

    No solo existe la replicación en memoria. También existe la opción de replicación a fichero o base de datos. Debe usarse replicación a base de datos siempre y cuando la memoria de la JVM vaya limitada o sea muy escasa. Sin embargo, este tipo de serialización puede afectar al performance de la aplicación.
      
        /myportal
        REPLICATED_IF_CLUSTERED
      
    
    Nota: Asignar el cookie-path es algo común en las aplicaciones de WebCenter Portal con conexión a WebCenter Content. Si se habilita la edición inline de contenidos (configuración de OHS y conexión a WebCenter Content) normalmente se suele perder la sesión del portal al acceder a UCM. Para ello se introduce una cookie-path con el mismo nombre y path del portal configurado en OHS. (Ampliaré información en post posteriores).

  • web.xml: En la documentación de Apache Trinidad y Oracle se recomienda que el parámetro de contexto org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION se cambie a false para entornos en clúster/productivos. Este parámetro según la documentación puede sobrecargar y a la vez provocar fallos en caso de failover.
      
        If this parameter is true, there will be an automatic check of the modification date of your JSPs, and saved state will be discarded when JSP's change. It will also automatically check if your skinning css files have changed without you having to restart the server. This makes development easier, but adds overhead. For this reason this parameter should be set to false when your application is deployed.
        org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
        false
      
    
  • Servicios WebCenter: La aplicación ya está preparada para entornos de alta disponibilidad. Sin embargo, hay que tener en cuenta ciertos aspectos relacionados con los servicios proporcionados por WebCenter. Por ejemplo, el colector de Analytics debe ser configurado 1-1. No acepta entornos en clúster.
    Por otro lado, Collaboration Server debe modificar su configuración para hacer un enable de entorno en clúster.

    Para más información de como modificar las conexiones y servicios WebCenter para alta disponibilidad leer la documentación oficial de Oracle: 

No hay comentarios:

Publicar un comentario