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 interfaz web de Alfresco y nos permite acceder al repositorio una interfaz ligera y potente para gestión de contenidos y colaboración. Mediante Share podemos activar sitios favoritos para su posterior acceso por IMAP. Este componente puede estar en una capa diferente al repositorio y escalar de forma separada tanto vertical como horizontalmente.
- 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.
