Arquitecturas en Alfresco
Toni Mayo 16th, 2010
Con este post me gustaría hacer una pequeña introducción a los diferentes diseños de arquitecturas que podemos llevar a cabo con Alfresco dependiendo del uso, usuarios, rendimiento, concurrencia y almacenamiento requerido.
Alfresco es un producto que acaba de cumplir 5 años, tras pasar por varias etapas con versiones más o menos estables, podemos decir, que desde hace un tiempo contamos con un producto confiable, robusto, estable y escalable. Preparado para pequeños proyectos con decenas de usuarios y unos cuantos miles de contenidos y para entornos con miles de usuarios y millones de contenidos. Y cada vez nos encontramos más y más instalaciones consolidadas.
Algo muy común que veo en las implantaciones de Alfresco, salvo casos muy concretos, es que muchas veces se instala la aplicación, base de datos y content store en la misma máquina, tanto para un piloto, desarrollo, test o producción. Para un piloto y desarrollo o incluso test es válido, o para producción si los requisitos no son demasiado exigentes. Teniendo todas las capas de la aplicación en la misma máquina (física o virtual), cuando el entorno pasa a producción y empieza a crecer considerablemente en número de usuarios y contenidos se suele experimentar un problema de rendimiento. Tiempos de respuesta elevados en el acceso, reglas, workflows, etc.
Vamos a ver, de forma resumida, algunos conceptos a tener en cuenta a la hora de hacer despliegues de Alfresco que nos permita crecer tanto horizontal como verticalmente.
Antes de seguir, para entender bien todo esto, veamos los componentes de la infraestructura que debemos conocer y diferenciar para diseñar una correcta arquitectura:
- Repositorio Alfresco: hablamos de la aplicación principal de Alfresco (alfresco.war) que gestiona todo el repositorio (contenidos) y el core, así como las diferentes interfaces de acceso como CIFS, FTP, WebServices, Alfresco Explorer y muchas otras más.
- Alfresco Share: aplicación (share.war) que es y será la cara web de Alfresco y nos permite acceder al repositorio mediante Share Point Protocol (vti-server.war) y sitios favoritos mediante IMAP. Este componente puede estar en una capa diferente al repositorio.
- Aplicaciones de terceros: nos referimos a las aplicaciones que necesita Alfresco para funcionar al 100% como OpenOffice, ImageMagik y Pdftools. Recuerda que desde la versión 3.2, OpenOffice funciona como un subsistema y podemos instalarlo en una máquina diferente al repositorio.
- Base de datos: será el motor de base de datos a usar por el software, como ya sabemos, pueden ser de varios tipos y “sabores” como MySQL, MS SQL Server, PostgreSQL, Oracle, etc. Alfresco almacena en la base de datos toda la información (metadatos, reglas, permisos… todo) excepto los índices y los ficheros físicos. Dicho esto, podemos adivinar que el uso de base de datos que hace Alfresco es importante.
- Almacén de contenido o content store: será el sistema de ficheros, directorio o directorios del sistema operativo donde Alfresco deposita los ficheros que maneja, los ordena por diferentes niveles de directorios (año/mes/dia/hora/minuto). Por defecto se almacena dentro de alf_data/contentstore. En contentstore.deleted tendremos los ficheros borrados, tras 15 días de ser eliminados, y audit.contentstore que será la información extra que genera la aplicación si activamos las auditorías.
- Índices: hablamos de la información que genera el motor de indexación y búsqueda que incorpora Alfresco, Lucene. Esta información se almacena en un directorio del sistema operativo llamado lucene-indexes dentro de alf_data por defecto. Diariamente a las 3 AM se genera un backup automático de los índices en el directorio alf_data/lucene-indexes.backup. Como decía, ahí se almacenan todos los índices de los contenidos del repositorio y tendrá un puntero a los mismos desde la base de datos. Podemos imaginar que cuanto más rápido sea el disco o discos donde residan los índices, más rápido funcionará nuestro sistema a nivel general.
Dicho lo anterior y conociendo el funcionamiento de Alfresco, podemos averiguar donde tenemos los cuellos de botella en las implantaciones.
Por ejemplo, tener el content store y la base de datos en la misma máquina sobre el mismo disco duro supone que cada vez que subimos un fichero o realizamos alguna acción con el mismo se escribe simultáneamente en base de datos y content store; moraleja: el disco duro debe escribir al mismo tiempo en varios sitios diferentes = sistema lento. Claro está, esto nos pasará si estamos haciendo un uso intensivo del sistema.
Todos esos componentes los podemos implementar de diferentes formas, dependiendo de la ubicación de cada componente hablaremos de diferentes capas o niveles.
- Una capa única: es el despliegue por defecto que podemos realizar con los instaladores bundle de Alfresco. Todos los elementos de la infraestructura los tendríamos en la misma máquina. ¿Para qué es válido este tipo de despliegue? Para pruebas piloto, desarrollos o incluso pequeñas instalaciones orientadas a departamentos. Por supuesto, este tipo de despliegues no se recomiendan para sistemas críticos o con grandes expectativas por razones obvias de escalabilidad y rendimiento.
- Dos capas: en este despliegue podemos empezar a usar una arquitectura realmente empresarial y escalable. Aquí separaremos en capas independientes:
Capa de contenidos: repositorio, Share, índices y aplicaciones de terceros que necesita Alfresco.
Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.
Esta arquitectura permite más escalabilidad y rendimiento, configuración simple y la gestión del crecimiento del contenido es transparente para la aplicación. Si añadimos que en este caso los índices estarán en la capa de contenidos tendremos como resultado un entorno que imprima un rendimiento considerable para entornos de tipo medio que incluso pueden ponerse en alta disponibilidad, pero ojo, si crecen mucho los contenidos también crecerán los índices y en ese casos podríamos necesitar hacer cambios en la infraestructura o en la configuración de los servidores (asignar más almacenamiento, etc.).
- Tres capas distribuidas: en versiones 3.X podemos separar en varias capas componentes de la capa web de Alfresco, es decir, separar Alfresco Share del repositorio. Este caso será el más escalable y nos permitirá implementar entornos con una gran carga y altas exigencias en cuanto a rendimiento. Esta arquitectura añade a la de dos capas la distribución de la capa web. Las capas serían las siguientes:
Capa web: donde tendríamos Alfresco Share o/y otras aplicaciones frontales que podamos tener para trabajar con Alfresco (Liferay, Joomla, Drupal, etc.) u otras hechas desde cero y opcionalmente un servidor web que proteja al servidor de aplicaciones vía mod_proxy, Varnish o similares.
Capa de contenidos: repositorio, índices y aplicaciones de terceros que necesita Alfresco.
Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.
Podríamos añadir una capa extra entre la capa web y capa de contenidos que nos permita hacer caché, control de acceso o balanceo de carga. Como vemos, esta es la mejor forma de ofrecer el máximo rendimiento tanto de lectura como de escritura, que además podemos configurar en alta disponibilidad en todas las capas. Este tipo de arquitectura no es recomendada para pequeños despliegues departamentales y necesita un alto grado de conocimiento de Alfresco, sistemas y redes en general. Salvo uso de software específico, no se recomienda separar cada una de las capas de forma geográfica ya que una alta latencia entre capas puede influir negativamente en el rendimiento.
- FLOSS , administración de sistemas
- Comments(17)
Muy interesante, como siempre
Buenas Toni, el post esta bastante bien explicado… pero solo una cosa… no ves mas que util incluir en la ya clasica arquitectura web multicapa, la capa de autenticación? es decir el repositorio de usuarios dedicado para que resida en un directorio distribuido fuera de la base de datos?
http://vfernandezg.blogspot.com/2009/10/gestion-documental-ecm-en-5-minutos.html
Salu2.
Gracias Paco. Victor si, de hecho lo hemos hablado internamente para ampliar alguna documentación en ese sentido, contemplar los usuarios en otro repositorio. Ya trataré la parte de autenticación y los subsistemas de seguridad más detalladamente.
Gracias!
OK Toni, pero a parte del SSO y demas… recuerdo que las pruebas con OpenDS y Centos DS fueron bastante bien, tanto en formato multimaster como replica simple consummer-supplier.
Por otro lado al margen de la parte de Seguridad (autenticacion mayormente), como ya hemos comentado en mas de una ocasion podriamos hacer lo mismo con la parte de Almacenamiento.
Salu2.
Pues vamos a ponernos manos a la obra
Buenas Toni,
ante todo decir que me parece muy útil este artículo, pero hay una cosa que no tengo clara y es la diferencia entre el repositorio y el almacen de contenidos. No sé si con respecto al content store te refieres al servidor de aplicaciones.
Un saludo y gracias de antemano.
Gracias José María, la verdad es que puede confundir, pero es importante diferenciar los componentes para entender bien a la hora de desacoplarlos. Cuando hablo de repositorio me refiero a la aplicación como tal, es decir, el software que gestiona la información. Y esa información (los ficheros/contenidos) son el almacén de datos o content store. ¿Mejor ahora?
Saludos.
Buenas Toni
Saliendo un poco del tema, te queria preguntar algunas cosas, ya que veo que dominas mucho alfresco, aca te digo mis preguntas.
tengo instalada la version comunity 3.2 corre en linux, autentifica contra un servidor openldap en linux mi pregunta es, como puedo hacer para que puedan acceder por CIFS al repositorio de alfresco, es posible eso?? y si es asi me podrias recomedar alguna web?
la otra pregunta es, sobre el versionamiento de documentos, cuando hago un export del directorio este no contienen el versionamiento, como puedo lograr exportar ese versionamiento.
Un saludo y muchas gracias de antemano
Pedro
Hola Pedro,
Si integras Alfresco con OpenLDAP no hay CIFS. Mira esta tabla: http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems#What_are_the_Authentication_Subsystems.3F
Sobre las versiones, los export de Alfresco no contienen versiones por ahora, es una funcionalidad no implementada.
Saludos.
Gracias por tu ayuda toni
lo del CIFS me quedo muy claro, solo una duda sobre el export
como podria sacar ese version history de los documentos???
hay alguna manera aparte del export??
Me seria de mucha ayuda =)
Un saludo y muchas gracias de antemano
Pedro
Hola Pedro,
Hay varias formas de sacar las versiones de un documento, por Webservices, WebScripts o CMIS (usando ambos). Mira aquí: http://localhost:8080/alfresco/service/index/all y busca por la cadena versions, encontrarás los webscripts necesarios.
También puedes mirar aquí http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/cmr/version/Version.html
Saludos.
Buenas tardes, la información está muy clara, pero donde podríamos encontrar ejemplos de configuración de cada uno de los servicios para adoptar alguna de esas arquitecturas?
Hola Francisco, es configuración de los diferentes componentes, en la wiki de Alfresco puedes encontrar toda esa información. Para arquitecturas complejas de grandes entornos, los clientes Enterprise tiene acceso a guias específicas.
Saludos.
Hola Toni, primero debo felicitarte por el gran aporte que haces al relolver consultas tan puntuales. Eso es muy valorable
Bueno, ahora quisiera consultarte sobre la migración de Alfresco 3.2 de una máquina a otra.
Leyendo por allá y por acá hablan de respaldar la Base de Datos y copiar el directorio alf_data y con eso estaríamos listos, pero tambien habla de los índices (que se encuentran también en alf_data)… corrígeme si me equivoco por favor.
tu me podría explicar un poco esa parte de los índices de Lucene ¿que significa esos index?, ¿qué implica si no están bien configurados? y si hay alguna herramienta para hacer copia de seguridad o tiene que ser todo a manito?
Desde ya muchisimas gracias y saludos cordiales.
Gracias Jose,
En los índices se almacena la información referente a los contenidos (metadatos, nombre, contenido de los ficheros, etc), para poder localizarlos posteriormente haciendo búsquedas. No tener bien configurados los índices pueden hacer que Alfresco no funcione correctamente o que el rendimiento no sea óptimo. Cada noche se hace automáticamente una copia de seguridad de los índices (a las 3AM, hora del servidor), los ficheros que genera ese backup son los que debes copiar en tu copia de seguridad junto a la base de datos y contentstore (alf_data).
Saludos.
Hola Toni.
En primer lugar quería felicitarte no sólo por este post, sino por el blog en sí. Desde mi desconocimiento total sobre instalaciones Alfresco quería hacerte algunas preguntas que me han surgido al leer este post.
1) Ubicación de los índices y el content store
Comentas que un posible cuello de botella puede ser el tener el content store y la base de datos en la misma máquina sobre el mismo disco duro porque eso supone que cada vez que se suba un fichero o realizamos alguna acción sobre algún fichero se escribe simultáneamente en base de datos y content store, por lo que el disco duro debe escribir al mismo tiempo en varios sitios diferentes, lo que repercute en tener un sistema lento.
Sin embargo, en los modelos de dos capas y de tres capas explicas que en la capa de almacenamiento deben ir estos dos elementos (base de datos y content store). ¿Es un error o es que no es posible tenerlos separados?.
2) ¿Hay otras soluciones para mejorar la velocidad o rendimiento de una instalación?. No sé, por ejemplo colocando los índices y la base de datos en el mismo sitio.
Un saludo y muchas gracias.
Hola, gracia a ti por participar.
1) Cuando hablo que la base de datos y el content store están en otra capa por debajo no significa que deban estar en la misma máquina. De hecho, algo muy común puede ser tener el contentstore en una cabina de almacenamiento tipo NAS (NFS, CIFS, etc) o SAN. Y la base de datos en su servidor de base de datos dedicado, que generalmente no es un servidor de bbdd dedicado a Alfresco sino uno corporativo con más bases de datos.
2) Es recomendable tener los índices siempre en local (mismo servidor que el repositorio, es decir, mismo servidor que el alfresco.war) y en los discos más rápidos que tengamos disponibles. También podemos usar content store selector para acelerar la escritura en disco dependiendo del tipo o tamaño de los ficheros. Haciendo tuning de la base de datos y de la JVM, etc.
Saludos.