Una de las críticas que más recibe Alfresco es que este no clona/replica las sesiones y variables asociadas, como por ejemplo la variable alf_ticket, por lo que en aplicaciones que llaman a nodos de un clúster de Alfresco se produce un error de autenticación.
Pero ¿es esto cierto?… bueno, creo que en parte si pero en parte no y por eso he realizado unas pruebas.
Una solución realizada hasta ahora era la de configurar en el balanceador lo que se llaman sesiones “sticky” que usan una variable de sesión como JSESSIONID para dirigir todas las peticiones de esa sesión al mismo nodo. De esta forma, al ser siempre el mismo nodo quien recibe las peticiones y tener la información del ticket de validación correcta no hay problemas.
Esta solución es válida para aplicaciones que usan sesiones, pero ¿que ocurre si una aplicación no las usa?, como el balanceador no sabe a donde dirigirlo porque no tiene esta información puede dirigirlo siempre al mismo nodo, lo que sería un mal menor, o redirigir a uno u otro nodo indistintamente, lo que provoca el error.
Bien, vamos a comprobar que Alfresco ECM versión 3.3.4 si clona al menos la información del ticket de autenticación para que cuando se entra en cualquier nodo usando un ticket de validación válido, Alfresco permite la entrada.
Lo primero es configurar correctamente el cluster de Alfresco ECM. En mi caso esta es la información de alfresco-global.properties:
alfresco.cluster.name=alfprucluster
alfresco.jgroups.defaultProtocol=TCP
alfresco.tcp.initial_hosts=alfpru1[7800],alfpru2[7800]
Además de renombrar el fichero ehcache-custom.xml.sample.cluster como ehcache-custom.xml
Creamos el fichero para probar el acceso entre los nodos usando la variable alf_ticket y sin usarla (o usando si quieremos una ficticia no válida)
Fichero: prueba_auth_cluster.sh
#!/bin/bash
ALF_USER=admin
ALF_PASSWD=admin
ALF_NODE1=alfpru1:8080
ALF_NODE2=alfpru2:8080
ALF_SEARCH_TERM=readme.ftl
ALF_ROOT=Company%20Home
echo “AUTENTICACION Y RECOGIDA DEL TICKET EN EL PRIMER NODO.”
ALF_TICKET=`curl “http://${ALF_NODE1}/alfresco/service/api/login?u=${ALF_USER}&pw=${ALF_PASSWD}” | grep TICKET_ | sed ‘s:::g’ | sed ‘s:::g’ | tr -d ‘r’`
echo “BUSCAR EN EL PRIMER NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.”
curl “http://${ALF_NODE1}/alfresco/service/api/search/keyword.text?q=${ALF_SEARCH_TERM}&p=${ALF_ROOT}&c=1&l=es&alf_ticket=${ALF_TICKET}”
echo “BUSCAR EN EL SEGUNDO NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.”
curl “http://${ALF_NODE2}/alfresco/service/api/search/keyword.text?q=${ALF_SEARCH_TERM}&p=${ALF_ROOT}&c=1&l=es&alf_ticket=${ALF_TICKET}”
echo “BUSCAR EN EL SEGUNDO NODO SIN USAR EL TICKET DE AUTENTICACION DEL PRIMER NODO.”
curl “http://${ALF_NODE2}/alfresco/service/api/search/keyword.text?q=${ALF_SEARCH_TERM}&p=${ALF_ROOT}&c=1&l=es”
Una vez configurado todo y arrancados ambos nodos de Alfresco, ejecutamos el script.
La salida en mi caso ha sido la siguiente:
./prueba_auth_cluster.sh
AUTENTICACION Y RECOGIDA DEL TICKET EN EL PRIMER NODO.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 106 0 106 0 0 10 0 –:–:– 0:00:10 –:–:– 31
BUSCAR EN EL PRIMER NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.
readme.ftl
BUSCAR EN EL SEGUNDO NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.
readme.ftl
BUSCAR EN EL SEGUNDO NODO SIN USAR EL TICKET DE AUTENTICACION DEL PRIMER NODO.
Apache Tomcat/6.0.18 – Informe de Error
Estado HTTP 401 –
type Informe de estado
mensaje
descripci�n Este requerimiento requiere autenticaci�n HTTP ().
Apache Tomcat/6.0.18
Que demuestra efectivamente que con el ticket obtenido en la autenticación del primer nodo, nos sirve para usarlo con el segundo. Además se realiza otra llamada sin usar el ticket para afirmar esta prueba ya que de esta forma sí debe salir un error.
Ahora vamos a eliminar el clúster, de forma que no se comuniquen los nodos entre sí y no pasen la información. Para ello quitamos las líneas de configuración del clúster de alfresco-global.properties y volvemos a ejecutar el script, el resultado, obviamente será el siguiente:
./prueba_auth_cluster.sh
AUTENTICACION Y RECOGIDA DEL TICKET EN EL PRIMER NODO.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 106 0 106 0 0 182 0 –:–:– –:–:– –:–:– 0
BUSCAR EN EL PRIMER NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.
readme.ftl
BUSCAR EN EL SEGUNDO NODO USANDO EL TICKET DE AUTENTICACION DEL PRIMER NODO.
Apache Tomcat/6.0.18 – Informe de Error
Estado HTTP 401 –
type Informe de estado
mensaje
descripci�n Este requerimiento requiere autenticaci�n HTTP ().
Apache Tomcat/6.0.18
BUSCAR EN EL SEGUNDO NODO SIN USAR EL TICKET DE AUTENTICACION DEL PRIMER NODO.
Apache Tomcat/6.0.18 – Informe de Error
Estado HTTP 401 –
type Informe de estado
mensaje
descripci�n Este requerimiento requiere autenticaci�n HTTP ().
Apache Tomcat/6.0.18
Por tanto, como puede observarse Alfresco ECM sí funciona correctamente como un clúster. Hay que indicar también que sigue siendo necesario (a mi entender) el uso de las Sticky Sessions para controlar mejor el tráfico a través del balanceador.
También se ha probado a recoger el ticket del primer nodo, parar este nodo y acceder con el resultado del ticket al segundo funcionando correctamente también.
Pero ¿que pasa entonces con las interfaces web?, bien, tanto el Explorer como Share, así como todas las interfaces que se desarrollen deberán controlar al menos el uso de la variable alf_ticket para que ninguno de los nodos reciba un ticket de validación erróneo o no lo reciba ya que de esta forma volverá a solicitar el inicio de sesión. Esto no es un problema del clúster en sí, si no de las interfaces de usuario y como he podido comprobar, en este caso ambas fallan cuando no tienen activadas las Sticky Sessions porque al parecer no pasan entre las peticiones (GET y POST) la variable alf_ticket. Según Alfresco, en la versión 3.4.3 esto estará solucionado.
NOTA: He usado el WebScript de búsqueda y que realiza una salida en texto de mi post http://www.fegor.com/2011/05/calculando-metricas-en-alfresco.html al que he declarado como autenticado mediante usuario “user”.
