Translate

jueves, 21 de marzo de 2013

Listar usuarios en Share

Hace poco me han preguntado en un curso como se podia obtener el listado completo de usuarios desde la interfaz de Alfresco Share, que a diferencia del Alfresco Web explorer no tiene un boton del tipo "mostrar todos".

Hasta las versiones 4.1 siempre había recurrido al wildcard '*' ya que el mecanismo de búsqueda obligaba a poner almenos uno. Incluso en algunas búsquedas que exigen almenos 3 carácteres se había podido usar '***'.


En la versión 4.1.3 he podido comprobar como el asterisco '*' ya no devolvía ningún resultado, sin embargo tenemos la posibilidad de utilizar el wildcard '%' ya que las consultas de los usuarios se hacen a la base de datos para evitar problemas de consistencia con SOLR.


miércoles, 20 de marzo de 2013

File System Transfer Reciever


Cuando hablamos de replicación en Alfresco normalmente nos referimos a la replicación de contenidos entre repositorios de Alfresco, pero está no es la única opción que tenemos. En algunos casos por ejemplo podriamos estar ejecutando un sitio web con una tecnología diferente que simplemente requiera una estructura de ficheros en el filesystem, al más puro estilo CMS.

Aunque el transfer service apareció por primera vez en la versión 3.3, no ha sido hasta la versión 4 cuando hemos podido tener una interfaz web que haga uso de este servicio


Algunas características del File System Transfer Reciever o FSTR:

  • Permite transferir carpetas y contenido a un file system remoto a través del Transfer Service.
  • El file system de destino se establece especializando el tipo transfer target a file system transfer.
  • Nos permite establecer un mapeo entre la raíz del file system de origen y de destino.
  • Soporta la sincronización del Replication Service
  • Usa una base de datos derby para mantener el historial de nodos sincronizados (no usa la estructura del contentstore de Alfresco).
  • Se ejecuta bajo una instancia de Tomcat 7 como una aplicación web usando el framework de webscripts
El File System Transfer Reciever que viene empaquetado como un zip que se instala a parte y está disponible tanto para versiones Community como Enterprise. La estructura del fichero zip es la siguiente:

|- classes/
  |   |- 
ftr-custom.properties
  |   |- ftr-custom-context.xml
  |   |- 
ftr-launcher.properties
  |   |- ftr-launcher-context.xml
  |   |- log4j.properties
  |- lib/
  |   |- <various libs>
  |-
webapps/
  |   |- file-transfer-
receiver.war
  |- file-transfer-receiver.jar

En los ficheros properties configuramos:

ftr-launcher.properties

  ftr.tomcat.baseDir=${user.dir}
  ftr.tomcat.portNum=9090
 
ftr-custom.properties
  
  ftr.tomcat.portNum=9090
  fileTransferReceiver.stagingDirectory=./ftr-staging
  fileTransferReceiver.rootDirectory=./ftr-root
  fileTransferReceiver.jdbcUrl=jdbc:derby:./derbyDB;create=true;user=alfresco;password=alfresco
  fileTransferReceiver.username=admin
  fileTransferReceiver.password=admin

El staging directory será el directorio temporal donde se va a realizar la replicación y una vez está haya concluido se moverá al root directory.  Una vez configurado levantaremos el servicio:

java –jar file-transfer-receiver.jar
 
En la interfaz de Share crearemos primero el target, para ello tendremos que crear una carpeta en la ruta siguiente:
La carpeta Default Group tiene una regla que automáticamente especializa las carpetas al tipo trx:transferTarget. Como en este caso lo que necesitamos es una especialización a trx:fileTransferTarget. A día de hoy y con la versión 4.1.3 no podremos realizar este cambio a menos que editmos el ficher share-config-custon.xml y añadamos a la seccion types lo siguiente:

      <types>
         <type name="cm:content">
         </type>

         <type name="cm:folder">
         </type>

         <type name="trx:transferTarget">
               <subtype name="trx:fileTransferTarget" />
         </type>
      </types>

Además deberemos activar la replicación a nivel de configuración en el fichero alfresco-global.properties
 replication.enabled=true
En las acciones del directorio que acabamos de crear (pulsar 2 veces en el directorio creado sobre la barra de navegación) tendremos la accion Change Type y nos aparecerá un desplegable para especializar al tipo fileTransferTarget


Editando las propiedades establecemos la configuración:


Y configuramos el job de replicación a través de la consola de administración

Y ejecutamos o programamos el job. En la consola del fstr veremos un mensaje cuando se finalice la replicación

Status update: COMPLETE

Y podemos comprobar que la estructura de ficheros aparece bajo la ruta configurada:

alfresco@alfresco:/opt/ftr$ ls ftr-root/
Drafts  Effective  In Review


miércoles, 15 de febrero de 2012

Actualizando Alfresco

Muchas instalaciones de Alfresco de las que he visto son bastante estáticas, y quizás uno de los motivos principales es que si las cosas funcionan no se tocan. Otro de los motivos suele ser que hay desarrollos involucrados en la instalación que se deberian validar contra la nueva versión (aunque la experiencia me demuestra que desarrollos hechos para 2.0c han seguido funcionando en versiones 3.4d no está de más asegurarse).

Antes de nada nos deberemos plantear nuestros motivos para hacer actualizar Alfresco. ¿ Hay bugs en nuestra versión que queremos resolver ? (changelog de versiones 3.4.3 en adelante)  ¿ Queremos alguna funcionalidad nueva ? (release notes para community)

Una vez decidida la actualización es la hora de ver sobre que versiones deberemos pasar para llegar a la que queremos. Alfresco suele diferenciar entre versiones menores y mayores y siempre es recomendable pasar a la última versión menor antes de hacer un salto a una mayor aunque el diagrama para la versión 4.0 muestra actualizaciones directas desde 3.1 en adelante:
Una vez tenemos claro nuestro escenario conviene hacerse varias preguntas:
  • ¿ Mis logs estan libres de errores "desconocidos" ? Deberiamos ver que la instalación en funcionamiento no esta dando errores de forma continuada ya que la actualización puede agravar el problema si no lo tenemos controlado.
  • ¿ Tengo algún tipo de personalización que deberia probar? se incluyen modificaciones en apariencia, modelo de datos, desarrollos, ficheros AMP.
  • ¿ Deberia actualizar algún componente ? JDK, Servidor de aplicaciones, conector de base de datos... Intentaremos ir conforme el stack oficial para enterprise ya que son versiones testeadas. Tener muy en cuenta que desde las versiones Community 3.2 se dejó de soportar oficialmente Oracle y SQL Server aunque existen proyectos de la comunidad para darles el soporte.
  • ¿ Voy a disponer de una copia de mi instancia de Alfresco para realizar las copias ? El disponer de una copia con datos, aunque no estén actualizados nos puede ahorrar muchos dolores de cabeza y vueltas atrás en producción.
  • ¿ Mi usuario de base de datos tiene permisos para borrar y crear tablas ?
  • ¿ He tocado algo dentro del directorio de deploy ? Deberia mover toda mi configuración al directorio extension
  • ¿ Estoy en una versión 3.1 o anterior ? Deberé unificar toda mi configuración del fichero custom-repository.properties en el fichero alfresco-global.properties

Alfresco provee de un mecanismo sencillo de actualización que basicamente se centra un leer el nuevo war y parchear la base de datos a la nueva versión. Por este mismo mecanismo no se debe tocar nunca el contenido desplegado de Alfresco y se debe usar el directorio de extension que nos ayuda a tener toda la configuración centralizada en un directorio.

Lo ideal si tenemos tiempo y espacio sería tener una copia con datos y trabajar primero sobre esa ya que será el entorno más parecido al escenario final. Manos a la obra:

  1. Pararemos Alfresco y realizaremos una copia en frio (ver la entrada de Backup)
  2. Instalaremos la nueva versión de Alfresco en una nueva ubicación, con una base de datos límpia y con un nuevo repositorio (directorio alf_data). Yo suelo nombrar a las instalaciones segun la versión, por ejemplo teniendo la versión 3.3g en /opt/alfresco33g y la 4.0 en /opt/alfresco40, lo mismo aplica para las bases de datos
  3. Verificaremos que la instalación limpia funciona correctamente y la pararemos
  4. Revisaremos los ficheros de configuración anteriores y llevaremos la configuración a los de la nueva versión. No se deben reutilizar los ficheros porque pueden aparecer nuevos parámetros que quedarán sin configurar. Además también deberemos incluir en este punto todos los desarrollos y personalizaciones. Esta tarea se puede hacer de manera previa al proceso de actualización y así minizaremos el downtime. Si configuramos en este punto la base de datos db.url  y hibernate.default_schema (Oracle) y el repositorio de la versión anterior dir.root en el próximo reinicio se ejecutará la actualización. Si queremos hacer alguna prueba más dejar estos dos puntos para el final.
  5. Reiniciar alfresco y monitorizar el fichero log
Empezaremos a ver como Alfresco detecta la nueva versión y empieza a aplicar parches. Este proceso es bastante rápido, en mi portátil ha tardado menos de 3 minutos en arrancar (no he reindexado contenido). Tras la actualización el log muestra el siguiente mensaje indicando la versión original y la nueva.

2012-02-15 13:07:45,445 INFO [service.descriptor.DescriptorService] [main] Alfresco started (Community). Current version: 4.0.0 (4003) schema 5.025. Originally installed version: 3.3.0 (g 2860) schema 4.100.

Durante este proceso de actualización puede ser recomendable hacer una reindexación del repositorio estableciendo en alfresco-global.properties el parámetro

index.recovery.mode=FULL

NOTA: en este proceso se ha mantenido la indexación con lucene. Si queremos empezar a usar SOLR primero deberemos actualizar con lucene para que se ejecuten algunos scripts y una vez se haya actualizado se puede migrar a SOLR.

Información obtenida de:
http://wiki.alfresco.com/wiki/General_Upgrade_Process
http://docs.alfresco.com/4.0/index.jsp

viernes, 3 de febrero de 2012

Alfresco 4 ya está aquí

Aunque  la versión  Community 4.0c ya lleva un tiempo entre nosotros ayer se liberaron las versiones 4.0 EE y 4.0d.

Aunque podeis información en la página oficial de Alfresco y la comunidad de blogs sobre las nuevas funcionalidades de Alfresco me ha alegrado encontrar en un PDF referencias a como se compara con la versión 3.4 y que puede ser determinante para los usuarios de Alfresco que lo están usando ya que según Alfresco, en sus tests, gracias sobre todo al sistema de indexado con SOLR que permite separar el contenido de los indices han comprobado:

• 10x consultas más rapidas al  Dashboard  de Alfresco Share
• 3x más rapido en la subida de documentos (hasta 4x más rapido en cargas masivas)
• 25% más rapido cargando la Document Library
• 50% mas rápido cargando los detalles de un Documento
• Búsquedas e indexados significativamente mejorados.

Información obtenida de
http://alfresco.com/products/editions/enterprise/4-0/


martes, 30 de agosto de 2011

Tomcat en modo demonio: jsvc

Es posible ejecutar Tomcat, y por ende Alfresco, en modo demonio. La principal ventaja de este sistema es que nos permite ejecutar Tomcat como usuario no-root y usar puertos privilegiados. Es importante aclarar que según la documentación vamos a poder usar los puertos <1024  pero única y exclusivamente a nivel de tomcat, no de Alfresco. Esto nos va a permitir por ejemplo ejecutar Tomcat en el puerto 80. Sin embargo para poder usar FTP y CIFS desde un usuario no privilegiados deberemos usar puertos alternativos y seguir la guía de la wiki y redireccionar los puertos a nivel de firewall. Esto es debido a que solo se demoniza el proceso de tomcat y no las aplicaciones que ejecuta.

jsvc viene con los binarios de Tomcat con lo que solo necesitaremos compilarlos:

    cd $CATALINA_HOME/bin
    tar xvfz commons-daemon-native.tar.gz
    cd commons-daemon-1.0.x-native-src/unix
    ./configure
    make
    cp jsvc ../..
    cd ../..

Si no tenemos definida la variable de entorno JAVA_HOME tendremos que pasar la ruta en el configure:
./configure --with-java=/usr/java/jdk1.6.0_19/

A continuacion pongo el init script que uso para arrancar/parar Alfresco con jsvc
#!/bin/sh
#
# tomcat           Utilizing the jsvc start and stop the servlet engine.
#
# chkconfig: 345 99 10
# description: Starts and stops the tomcat servlet engine.
# Source function library.
. /etc/rc.d/init.d/functions
JAVA_HOME=/usr/java/jdk1.6.0_15/
CATALINA_HOME=/opt/alfresco/tomcat
DAEMON_HOME=/opt/alfresco/tomcat/bin/
TOMCAT_USER=tomcat
TOMCAT_GROUP=tomcat
TOMCAT_PID=/var/run/jsvc_alfresco.pid
TMP_DIR=/opt/alfresco/tomcat/temp
CATALINA_OPTS=
CLASSPATH=$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
CATALINA_WORK_DIR=$CATALINA_HOME/work
# To get a verbose JVM
#-verbose \
# To get a debug of jsvc.
#-debug \
WAIT_MAX=2
case "$1" in
start)
  #
  # Start Tomcat
  #
echo -n "Starting Tomcat: "
$DAEMON_HOME/jsvc -user $TOMCAT_USER -pidfile $TOMCAT_PID -home $JAVA_HOME -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=196M -Xms512m -Xmx2048m -Dcatalina.home=$CATALINA_HOME -Djava.io.tmpdir=$TMP_DIR -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile '&1' $CATALINA_OPTS -cp $CLASSPATH org.apache.catalina.startup.Bootstrap

sleep 2s
if [ -f $TOMCAT_PID ]; then
             echo_success
else
             echo_failure
fi
echo
;;
stop)
#
# Stop Tomcat
#
echo -n "Stopping Tomcat: "
PID=`cat $TOMCAT_PID`
kill $PID 2>/dev/null 1>/dev/null
if [ `ps -p ${PID} > /dev/null 2>&1` ]; then
             echo_failure
else
             echo_success
             rm -f $TOMCAT_PID > /dev/null 2>&1
fi
echo
;;
flush)
#
# Stop Tomcat
#
   echo -n "Stopping Tomcat: "
   PID=`cat $TOMCAT_PID`
   kill $PID 2>/dev/null 1>/dev/null
   if [ `ps -p ${PID} > /dev/null 2>&1` ]; then
                echo_failure
   else
                echo_success
                rm -f $TOMCAT_PID > /dev/null 2>&1
   fi
   echo
   echo -n "Flushing Tomcat CACHE ($CATALINA_WORK_DIR) : "
   rm -rf $CATALINA_WORK_DIR
   if [ -e $CATALINA_WORK_DIR ]; then
                echo_failure
                echo
                exit 1;
   fi
   mkdir $CATALINA_WORK_DIR
   chown $TOMCAT_USER.$TOMCAT_GROUP $CATALINA_WORK_DIR
   if [ ! -e $CATALINA_WORK_DIR ]; then
                echo_failure
                echo
                exit 1;
   fi
   echo_success
   echo
   ;;
*)
   echo "Usage: $0 {start|stop|flush}"
   exit 1;;
esac
exit 0

Este script además tiene el parámetro flush que nos va a permitir eliminar de una forma fácil el contenido del directorio work.

Hay que tener en cuenta que cuando usamos jsvc ya no estamos invocando a los scripts startup.sh ni shutdown.sh con lo cual no se parará el proceso usando estos ficheros. Todas las variables que tuvieramos definidas en este fichero como en el catalina.sh deberán ser movidas al nuevo script.

Cuando miremos los procesos en ejecución veremos 2 procesos. El primero levanta los puertos y el segundo es el que atiende las peticiones.

root     16126     1  0 12:32 ?        00:00:00 jsvc.exec -user tomcat -pidfile /var/run/jsvc_alfresco.pid -home /usr/java/jdk1.6.0_19/ -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=160M -Xms512m -Xmx1024m -Dcatalina.home=/opt/alfresco/tomcat -Djava.io.tmpdir=/opt/alfresco/tomcat/temp -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile &1 -cp /usr/java/jdk1.6.0_19//lib/tools.jar:/opt/alfresco/tomcat/bin/commons-daemon.jar:/opt/alfresco/tomcat/bin/bootstrap.jar org.apache.catalina.startup.Bootstrap
tomcat   16127 16126 52 12:32 ?        00:01:15 jsvc.exec -user tomcat -pidfile /var/run/jsvc_alfresco.pid -home /usr/java/jdk1.6.0_19/ -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=160M -Xms512m -Xmx2048m -Dcatalina.home=/opt/alfresco/tomcat -Djava.io.tmpdir=/opt/alfresco/tomcat/temp -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile &1 -cp /usr/java/jdk1.6.0_19//lib/tools.jar:/opt/alfresco/tomcat/bin/commons-daemon.jar:/opt/alfrescod/tomcat/bin/bootstrap.jar org.apache.catalina.startup.Bootstrap

Parando Tomcat

Arrancando Tomcat via jsvc,  entra en mono deomnio, lo que significa que no va a escuchar en el puerto 8005 y por tanto no se va a poder detener via catalina.sh (o shutdown.sh).
Lo que se hace es enviar un SIGTERM o SIGINT al proceso que pertenece a root. En nuestro caso se encuentra el pid en $CATALINA_PID.

sábado, 23 de julio de 2011

Receta para Alfresco en Cluster con replicación de sesión

Con la salida de la versión 3.4.3 de Alfresco Enterprise se ha solucionado un bug que arrastraba la configuración en cluster desde 2009. Finalmente se ha solucionado y voy a explicar paso a paso como se debe configurar utilizando el paquete en formato zip.

Alfresco de por si no replica las sesiones del usuario de un nodo a otro y de esto se debe encargar el servidor de alpicaciones. Por tanto debemos establecer el cluster no solo en Alresco si no también a nivel de Tomcat. En mis pruebas he seguido este esquema:

         Balanceador
        192.168.1.122
             |    
          Cluster      
        /         \        
    Tomcat1       Tomcat2  
192.168.1.122   192.168.1.12

  • Balanceador: Apache 2.2 + proxy_balancer + proxy_ajp
  • Cluster: Tomcat configurado mediante BackupManager
  • Tomcat1: Centos 5 con Tomcat 6.0.32
  • Tomcat2: Ubuntu con Tomcat 6.0.32 
En este esquema un nodo hace de servidor NFS y de balanceador. En un entorno en producción estos 2 elementos deberian ser independientes para garantizar que la caida de un nodo no afecte al otro. 
Creamos la estructura de directorios para la instalación
#mkdir -p /opt/alfresco/tomcat
#mkdir -p /opt/alfresco/indices
Tomcat:
#cd /opt/alfresco
#tar zxvf  /tmp/apache-tomcat-6.0.32.tar.gz
#ln -s apache-tomcat-6.0.32 tomcat
Copiamos el contenido del paquete de Alfresco
#unzip alfresco-enterprise-3.4.3.zip -d alfresco
#cp -rp /tmp/alfresco/web-server/* /opt/alfresco/tomcat
En esta copia a parte de los ficheros de Alfresco también se sobreescriben ficheros de configuración de Tomcat. Es necesario editar el fichero context.xml en destino puesto que el valor que tiene impide el funcionamiento del cluster. En el fichero context.xml debemos dejar comentada la línea:
 <!-- Uncomment this to disable session persistence across Tomcat restarts -->
 <!--Manager pathname="" /-->
Activamos el puerto AJP en ambos nodos descomentando en el fichero server.xml la linea
 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Configuramos el nombre de la ruta en la directiva Engine del fichero server.xml de los 2 nodos.  tomcat1:
 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
tomcat2:
 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2">
En este punto también vamos a configurar el Cluster de Tomcat tal como se indica en el manual de Apache Tomcat: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html Editamos el fichero server.xml dentro de la directiva <Engine>
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="6">

          <Manager className="org.apache.catalina.ha.session.BackupManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"
                   mapSendOptions="6"/>
          <!--
          <Manager className="org.apache.catalina.ha.session.DeltaManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"/>
          -->        
          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="5000"
                      selectorTimeout="100"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
Añadimos el tag distributable que permitirá la replicación de sesiones en el fichero web.xml de alfresco.war y share.war en ambos nodos al final del fichero:
.

.
<distributable/>
</web-app>
MySQL
tomcat1:
mysql> create database alfresco343;
mysql> grant all privileges on alfresco343.* to 'alfresco'@'%' identified by 'alfresco';
NFS
tomcat1:
/etc/exports
/opt/alfresco/alf_data 192.168.1.0/24(rw,no_root_squash,no_subtree_check,async) 
tomcat2:
#mount 192.168.1.122:/opt/alfresco/alf_data /opt/alfresco/alf_data
Apache tomcat1:
#a2enmod proxy_ajp proxy_balancer proxy
Configuramos el balanceo con los 2 nodos, incluyendo además el balancer-manager que nos permitirá monitorizar, activar y desactivar cada uno de los nodos para realizar las pruebas. Para ello he configurado 2 grupos diferentes de balanceo, uno para Alfresco y otro para Share, cada uno de manera distinta para ver las 2 posibles configuraciones en el fichero /etc/apache2/conf.d/proxyajp.conf
<Location /balancer-manager>
   SetHandler balancer-manager
</Location>

<Proxy balancer://balancer1>
   BalancerMember ajp://192.168.1.122:8009 route=tomcat1
   BalancerMember ajp://192.168.1.12:8009 route=tomcat2
   ProxySet stickysession=JSESSIONID
</Proxy>
ProxyPass /alfresco balancer://balancer1/alfresco
<Proxy balancer://balancer2>
   BalancerMember ajp://192.168.1.122:8009 route=tomcat1
   BalancerMember ajp://192.168.1.12:8009 route=tomcat2
</Proxy>
<Location /share>
ProxyPass balancer://balancer2/share stickysession=JSESSIONID
</Location>
alfresco-global.properties en tomcat2:
#alf_data compartido por nfs
dir.root=/opt/alfresco343/alf_data
#indices en local
dir.indexes=/opt/alfresco343/indices/lucene-indexes
dir.indexes.backup=/opt/alfresco343/indices/backup-lucene-indexes
dir.indexes.lock=/opt/alfresco343/indices/locks
.
.
alfresco.cluster.name=ALFCLUSTER
alfresco.jgroups.defaultProtocol=TCP
alfresco.tcp.initial_hosts=192.168.1.122[7800],192.168.1.12[7800]
alfresco.jgroups.bind_address=192.168.1.12
En el arranque veremos primero como se forma el cluster de tomcat
22-jul-2011 19:38:47 org.apache.catalina.core.StandardService start
INFO: Arrancando servicio Catalina
22-jul-2011 19:38:47 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
22-jul-2011 19:38:47 org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
22-jul-2011 19:38:47 org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/192.168.1.12:5000
22-jul-2011 19:38:47 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
22-jul-2011 19:38:47 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:4
22-jul-2011 19:38:48 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 1, 122}:5000,{192, 168, 1, 122},5000, alive=10519,id={80 9
4 82 -34 95 106 76 118 -85 119 -121 -44 -79 -105 -125 74 }, payload={}, command={}, domain={}, ]
y una vez arrancado Alfresco, el cluster de este:
19:39:29,778  INFO  [cache.jgroups.JGroupsKeepAliveHeartbeatReceiver]
New cluster view with additional members:
   Last View: null
   New View:  [tomcat1-59540|1] [tomcat1-59540, tomcat2-44982]

Una vez arrancados los 2 nodos y comprobando que Alfresco funciona vamos a abrir una pestaña nueva en el navegador con el balancer manager para poder ver en que nodo estamos y poder deshabilitarlo sin tener que parar ningún nodo:



Accediendo a http://192.168.1.122/share vemos que se ha generado tráfico en el worker del primer nodo, por tanto procedo a deshabilitarlo forzando el paso al segundo nodo.

Durate mis pruebas con Share la sesión se ha mantenido sin mostrarse ningún error. En el caso de Alfresco Explorer ha mostrado una pantalla de error de sesión expirada pero al volver a la aplicación ha recuperado la sesión.

Espero que esto os sirva!

lunes, 20 de junio de 2011

Configuracion con Oracle RAC 10g y 11g

Recientemente he tenido la oportunidad de configurar Alfresco contra un Oracle RAC. Además la suerte ha sido doble porque inicialmente se configuró contra un RAC de 10g y posteriormente se ha migrado a un 11g, con lo cual hemos podido comprobar el funcionamiento en ambas versiones.

De cara a Alfresco el tema del RAC es transparente ya que los cambios de configuración se realizan a nivel del driver de conexión. Vamos a ver la configuración utilizada:


db.name=alfresco
db.username=alfresco
db.password=alfresco
db.driver=oracle.jdbc.OracleDriver
db.url=jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=nodo1-vip.red.dominio.es)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=nodo2-vip.red.dominio.es)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=LAN_APLICACIONES.red.dominio.es)))
db.pool.validate.query=SELECT 1 FROM DUAL
hibernate.default_schema=ALFRESCO
El cambio para Oracle RAC está en la cadena de conexión. Vamos a ver uno a uno los parámetros de esta cadena de conexión:

DESCRIPTION 
contiene el descriptor de conexión, es decir todos los parámetros que se van a usar para conectar. En este caso teniamos el RAC con 2 nodos con lo cual solo teniamos un único descriptor. Sería posible para instalaciones mas complejas tener una lista de descriptores y cada descriptor a su vez con varios servidores. Por ejemplo:

(DESCRIPTION_LIST=
  (DESCRIPTION= 
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (CONNECT_DATA= 
     (SERVICE_NAME=service_name)))
  (DESCRIPTION= 
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (CONNECT_DATA= 
     (SERVICE_NAME=service_name))))

LOAD_BALANCE
Indica si se van a usar las direcciones de forma aleatoria (activo) o de forma secuencial (desactivado). Se puede especificar cualquiera de estos valores que podemos encontrar en diferentes ejemplos:
on | off | yes | no | true | false
ADDRESS contiene el PROTOCOL, ADDRESS, PORT
que se explican por si mismas

CONNECT_DATA contiene la identificación del servicio .

SERVICE_NAME
En este caso no estamos usando un SID, el cual apuntaría solo a uno de los nodos, si no que se define un servicio a nivel de Oracle y se apunta contra este.

Es posible que nos encontremos ejemplos en los que en la cadena de conexión aparece también el parámetro FAILOVER. Este parámetro esta por defecto activado para los descriptores así que no será necesario incluirlo a no ser que queramos desactivarlo.

Desde el servidor podemos ver como las conexiones se empiezan a balancear entre los nodos:


[tomcat]# lsof -nPi |grep 1521
tnslsnr   22544   oracle   11u  IPv6  996133       TCP *:1521 (LISTEN)
jsvc      28316 alfresco  231u  IPv6 1026752       TCP 172.17.1.154:55223->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  232u  IPv6 1026753       TCP 172.17.1.154:55224->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  233u  IPv6 1026754       TCP 172.17.1.154:55667->172.17.31.21:1521 (ESTABLISHED)
jsvc      28316 alfresco  234u  IPv6 1026755       TCP 172.17.1.154:55226->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  235u  IPv6 1026756       TCP 172.17.1.154:55227->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  236u  IPv6 1026757       TCP 172.17.1.154:55228->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  237u  IPv6 1026758       TCP 172.17.1.154:55671->172.17.31.21:1521 (ESTABLISHED)
jsvc      28316 alfresco  238u  IPv6 1026759       TCP 172.17.1.154:55230->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  239u  IPv6 1026760       TCP 172.17.1.154:55231->172.17.31.23:1521 (ESTABLISHED)


Es importante recordar que el esquema para el parámetro hibernate.default_schema se debe incluir siempre en mayúsculas, ya que de otro modo el primer arranque funcionará correctamente pero en el segundo recibiriamos un error de Schema upgrade failed


http://download.oracle.com/docs/cd/B28359_01/network.111/b28317/tnsnames.htm

http://wiki.alfresco.com/wiki/Database_Configuration#Oracle_example