Archivos mensuales: septiembre 2011

Balanceo de tráfico en Alfresco ECM (escenarios)

—-
(15/09/2011) IMPORTANTE: Tras realizar pruebas concurrentes y aclaraciones por parte de Alfresco, los métodos de balanceo de CIFS/SMB no son recomendables en producción al menos hasta la próxima versión 4.0 debido a un problema con JLan y lo bloqueos en ficheros. No obstante esta información será consistente una vez Alfresco/JLan permita la concurrencia de accesos mediante CIFS/SMB.
Para más información se pueden consultar las entradas en JIRA siguientes así como información en la documentación de Alfresco:

Así pues, sigo recomendando actualmente una estructura más adecuada y ya analizada en el anterior artículo: http://www.fegor.com/2011/09/arquitecturas-cluster-en-alfresco.html
—-
A la hora de elaborar una arquitectura en alta disponibilidad y en la parte de balanceo de carga hacia los nodos podemos usar varios escenarios.

En este primer escenario vamos a usar el siguiente sistema:

Aquí se usan dos balanceadores, por un lado para las comunicaciones en SMB (CIFS) y otra para el acceso a través del cliente web (HTTP).

Para el acceso a través de los protocolos SMB/CIFS y HTTP se utilizará HAProxy, un magnífico programa que es capaz de gestionar comunicaciones en alta disponibilidad y balancear a nivel de protocolo TCP y dentro de este, el HTTP.

En este contexto, un fichero de configuración para HAProxy (/etc/haproxy.conf) podría ser:

global
        maxconn         32000

defaults applications HTTP
        log global
        mode http
        option httplog
        option forwardfor
        option dontlognull
        option httpclose
        balance roundrobin
        clitimeout 20000
        srvtimeout 20000
        contimeout 4000
        retries 3

listen  alfpru_http 192.168.56.150:80
        mode http
        cookie JSESSIONID prefix
        server alfpru1_http alfpru1:8080 cookie alfpru1_server check weight 50
        server alfpru2_http alfpru2:8080 cookie alfpru2_server check weight 50

defaults applications TCP
        log global
        mode tcp
        balance roundrobin
        clitimeout 180000
        srvtimeout 180000
        contimeout 4000
        retries 3
        redispatch

listen alfpru_smb alfpruha:445
        mode tcp
        balance roundrobin
        server alfpru1_smb alfpru1:10445 check weight 50
        server alfpru2_smb alfpru2:10445 check weight 50

De esta forma tenemos un balanceo (round robin) así como una persistencia en las sesiones.

Otro escenario posible es dividir el balanceo por protocolo, es decir, dejar SMB/CIFS para HAProxy y HTTP para Apache. El diagrama sería:

El nuevo fichero de configuración para HAProxy sería el siguiente:

global
        maxconn         32000

defaults applications TCP
        log global
        mode tcp
        balance roundrobin
        clitimeout 180000
        srvtimeout 180000
        contimeout 4000
        retries 3
        redispatch

listen alfpru_smb alfpruha:445
        mode tcp
        balance roundrobin
        server alfpru1_smb alfpru1:10445 check weight 50
        server alfpru2_smb alfpru2:10445 check weight 50

Y a su vez, la configuración de Apache (/etc/httpd/conf.d/proxy_ajp.conf) como sigue:

NameVirtualHost *:80

        ServerName alfpruha.pruebas.local
        ServerAdmin admin@pruebas.local
        ProxyRequests Off
        KeepAlive On

       
          Order deny,allow
          Allow from all
       

        ProxyPass /balancer-manager !

        ProxyPass /alfresco balancer://cluster1 stickysession=JSESSIONID lbmethod=byrequests nofailover=Off
        ProxyPassReverse /alfresco http://alfpru1:8080/alfresco
        ProxyPassReverse /alfresco http://alfpru2:8080/alfresco

       
               BalancerMember http://alfpru1:8080/alfresco route=jvm1
               BalancerMember http://alfpru2:8080/alfresco route=jvm2
       

       ProxyPass /share balancer://cluster2 stickysession=JSESSIONID lbmethod=byrequests nofailover=Off
       ProxyPassReverse /share  http://alfpru1:8080/share
       ProxyPassReverse /share  http://alfpru2:8080/share
       
               BalancerMember http://alfpru1:8080/share route=jvm1
               BalancerMember http://alfpru2:8080/share route=jvm2
       
       
          SetHandler balancer-manager
          Order deny,allow
          Allow from all
       

        ErrorLog /var/log/httpd/alfpru-error_log
        CustomLog /var/log/httpd/alfpru-access_log common
 

En este caso, no hay que olvidarse, que también habrá que configurar Tomcat para que se ajuste a las «rutas» del balanceo, en este caso en el fichero tomcat/conf/server.xml:

y en el segundo nodo:

También podría configurarse mediante mod_jk en lugar de mod_proxy/mod_proxy_balancer.

En ambos escenarios hay que reconfigurar los puertos SMB/CIFS para Alfresco (en este caso solo se usa el 445TCP del SMB ya que las instalaciones están realizadas en Linux CentOS 5) en el fichero ${ALFRESCO_HOME}/tomcat/shared/classes/shared/classes/alfresco/extension/subsystems/fileServers/default/default/custom-file-servers.properties:

cifs.tcpipSMB.port=10445
cifs.netBIOSSMB.sessionPort=10139
cifs.netBIOSSMB.namePort=10137
cifs.netBIOSSMB.datagramPort=10138

Estos son dos ejemplos de balanceo de tráfico para escenarios en alta disponibilidad, además de esta existen multitud de arquitecturas, p.e. un HAProxy que balancee a un Apache que balancee hacia los Tomcat/Alfresco, usar el mismo HAProxy para balancear tráfico TCP para MySQL o para Oracle, etc.

Datos sobre los nodos/hosts:

192.168.56.150  alfpruha
192.168.56.101  alfpru1
192.168.56.102  alfpru2

Donde 192.168.56.150 es la IP flotante o virtual.

HAProxy puede obtenerse de http://haproxy.1wt.eu/ así como toda la documentación para su correcta instalación y todas las opciones de configuración que no son pocas.

Apache mod_proxy_balancer puede descargarse y leer su documentación en el proyecto apache, en concreto en http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

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: