Arquitectura(s) Cluster en Alfresco

Desde un punto de vista más teórico y funcional, dentro de los escenarios de posibles instalaciones en cluster de Alfresco ECM encontramos dos escenarios básicos, uno que utiliza repositorio por cada nodo y estos son sincronizados y la más usada actualmente, en la que se usa un repositorio común así como índices separados por cada nodo.

Dentro del segundo escenario, existe multitud de documentación sobre posibles arquitecturas de Alfresco ECM que podemos encontrar tanto en la documentación oficial de Alfresco (http://docs.alfresco.com) como en otros recursos tanto personales (http://blyx.com), como públicos (Junta de Andalucía, Ministerio de Justicia, etc.)

Pero generalmente, cuando se habla de arquitecturas en cluster para Alfresco, estas se limitan solo al producto en sí, es lógico pues Alfresco ECM es capaz de clusterizarse mediante el uso de EHCache y JGroups sin necesidad de más componentes.

Una posible arquitectura a desarrollar es la siguiente:

Se pueden observar varias capas o niveles en las cuales se pueden introducir de forma intermedia distintos elementos adicionales como nuevos balanceadores (hardware y software), firewalls, etc. según las necesidades de cada entorno.

Existen además varios tipos de usuarios, los usuarios externos o que acceden desde fuera de la organización, estos a su vez pueden ser usuarios “anónimos” o “autenticados” y también usuarios que son trabajadores de la organización y que deben tener los recursos como si estuvieran dentro de esta, incluidos los de administración.

Intranet Network: Es la red de intranet principal a través de la cual se conectan todos los usuarios. Generalmente es la red local de la empresa, bien, sementada, o por el contrario para un solo segmento p.e. 192.168.1.0/24 (Clase C). Los accesos a la mayoría de los protocolos por parte de los usuarios y concretamente a través de HTTP para el Share se realizan dentro de esta red. En algunos casos se puede segmentar esta para el uso de otros protocolos como CIFS pero requiere más complejidad de la que ya hay en sí misma.

Capa de WEB/Balanceo (1): Esta capa está planteada desde un doble punto de vista, por un lado es un servidor web (Apache) y por otro lado también es un balanceador software (Apache+mod_jk o Apache+mod_proxy) si bien también contempla el uso de alta disponibilidad por sí mismo (HA_Proxy) usando una IP “flotante” o virtual (192.168.1.100) a través de lo que se llama un Heartbeat (HB). De esta forma mantenemos la alta disponibilidad y sistema en “failover” para esa capa y usando un único punto de entrada para todos los usuarios.

Como esta capa es de entrada exclusiva por HTTP (Web y WebDAV), los accesos de otros protocolos que no pueden ser accedidos a través de Apache y el balanceo, como CIFS y FTP se realizarán directamente sobre la capa de aplicación.

Capa de presentación o FrontEnd (2): En esta capa se utiliza el servidor de aplicaciones como sistema de acceso al repositorio donde se instala Alfresco Share.

Esta capa puede contener también servidores HTTP como Apache para servir partes estáticas e incluso para balancear también hacia la siguiente capa (repositorio de Alfresco). En este diagrama no viene indicado para no complicar en exceso pero en muchas ocasiones es muy buena idea que también esta capa balancee e incluya un “Heartbeat” para mantener alta disponibilidad también en este punto.

Tampoco viene reflejado pero se da por supuesto que los servidores Tomcat están en cluster a nivel de servidor de aplicaciones, que , aunque esto no afecte directamente a Alfresco es una buena idea tener todas las capas también con sus propios métodos de redundancia y sincronización.

Capa de aplicaciones o repositorio (3): Aquí están localizados los repositorios o Alfresco Explorer, no los repositorios físicos que son más propios de la siguiente capa. Es decir, la instalación de Alfresco (sin Share) estaría en este sitio. Alfresco está configurado por JGroups como cluster y conectado su “Heartbeat” mediante una red propia para este que realiza la sincronización mediante TCP y RMI (EHCache).

Capa de persistencia y repositorio (4): Esta capa es la encargada de almacenar físicamente los ficheros/documentos en el sistema de ficheros así como toda la información asociada en la base de datos. Se da por supuesto que el almacenamiento está redundado mediante cabinas de discos así como de un sistema como Oracle RAC o MySQL Cluster NDB. Cada sistema tiene su propia subred que debería estar conectada por “fibra channel”.

Otros elementos: Como se ve en el diagrama de arquitectura, existen elementos que al no estar directamente conectados mediante HTTP ni tener posibilidad de balanceo además de por sus características de aplicaciones, se conectan directamente a uno de los nodos de Alfresco. Así mismo, algunos accesos (p.e. CIFS, etc.) se realizan al otro nodo en una forma de repartir la carga de estos sistemas que no son balanceables.

Estos elementos son usados en muchas ocasiones para inyección masiva de datos o bien para conectar aplicaciones como SAP, AutoCAD, etc.

Administration & Monitoring Network: Por último, se usa también una red aparte también para los administradores y para monitorización, de esta forma se aíslan estas transmisiones y evita mayor carga en la red.

Más información:

9 replies on “Arquitectura(s) Cluster en Alfresco”

  1. Muy bueno Fer. Solo unos apuntes, la mas usada en general es la segunda opción que comentas y también añadir que los indices los has puesto en la SAN pero como sabes es preferible en local aunque en una SAN es la siguiente opción valida. También se podría usar NAS para el content store.

  2. fegor dice:

    Efectivamente Toni, es deseable en local como tú dices, aunque cada vez más en este tipo de arquitecturas sabes que usan la SAN para todo… 😀

    Igualmente la NAS es una buena opción (tras las anteriores) para el repositorio.

    La verdad es que se han quedado cosas que aclarar, ya sabes, los clusters es lo que tienen 😉

  3. Martin dice:

    Sólo una aclaración, con Haproxy es posible balancear casi todo lo que vaya sobre TCP/IP.
    Mi pregunto si habrá algo para solucionar el tema de la no-corrupción de datos en el content storage ya que este con el tiempo puede llegar a ser muy grande (TBs) y las estrategias convencionales de backup y restore no son suficientes para garantizar su disponibilidad.

  4. fegor dice:

    Efectivamente Martin, existen multitud de escenarios sobre estas arquitecturas. La propuesta no balancea CIFS/SMB y hace uso del otro nodo para la carga o acceso de aplicaciones externas. Por cierto, mírate mi próximo artículo, irá más todavía sobre este tipo de arquitecturas 😉

    Sobre el tema de copias de seguridad, habrá que esperar a que alguien saque algo decente para realizar copias de seguridad incrementales y/o completas de alguna forma que pueda ser compatible con cintas de copias, DVDs, discos duros, etc. Hay algunos proyectos por ahí y por supuesto Alfresco seguro que está desarrollando algo 🙂

  5. Hola Fer, gracias por tu blog, enhorabuena. Te queria preguntar, bueno, va a parte pero es que he cambiado la IP de las maquinas de un cluster en Alfresco, y al volver a arrancar los mismos, parece que no se encuentran. Los nombres de hosts siguen siendo los mismos. Se queda esperando y no terminan de arrancarSabes cual puede ser el problema? Y la solucion? gracias!

  6. fegor dice:

    Tendrías que repasar la configuración, comprobar si con la nueva IP se siguen viendo las máquinas, mira la tabla de hosts, DNS y demás.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *