Nube privada basada en ownCloud

Lunes, 20 Octubre, 2014

Durante los últimos meses, en CaminsTECH hemos estado trabajando en la implementación de un servicio de compartición de ficheros en la nube. Uno de los requisitos de esta solución debía ser asegurar que el control de los datos se mantuviese dentro de la propia universidad. Finalmente, este proyecto se ha convertido en un servicio llamado CaminsDRIVE que ofrece la posibilidad de utilitzar un aplicativo con las características del conocido sistema Dropbox™ a los usuarios de CaminsTECH.

Arquitectura

La solución escogida se basa en ownCloud  (un software de cloud opensource) sobre máquinas con sistema operativo Linux (Ubuntu 64). La arquitectura del sistema se ha diseñado siguiendo una estructura dividida en tres niveles: balancer, frontend y backend.

  • Primer nivel o balancer es el punto de entrada donde se implementa el balanceo de la carga de peticiones. Sólo se permite el acceso a través del protocolo HTTPS. Estas peticiones son distribuidas entre los diferentes servidores de ownCloud.
  • Segundo nivel o frontend es el nivel donde se ejecutan las instancias de la aplicación ownCloud. El número de instancias puede crecer o decrecer según la demanda. 
  • Tercer nivel o backend es el nivel donde se encuentran los servicios que soportan las diversas instancias del frontend.  

Arquitectura

Balancer

La implementación del balanceador se ha realizado utilizando el servidor web Apache con el módulo proxy_balancer. Actualmente se ha optado por la utilitzación de un sistema de balanceo de la carga basado en el número de peticiones (lbmethod_byrequests).

La utilitzación de diversos servidores de ownCloud puede producir problemas de autenticación a los usuarios. Cuando una petición llega a un ownCloud diferente al que ha realitzado la autenticación, éste vuelve a requerir la autenticación al usuario (este frontend no contiene ninguna sesión del usuario). Para solucionar este problema se debe asegurar que todas las peticiones de una misma sesión se redireccionen a la misma instancia de ownCloud. Este comportamiento se puede conseguir mediante la utilización del atributo stickysession del ProxySet.

<VirtualHost *:443>
   ServerName drive.caminstech.upc.edu
   
   ProxyRequests off
   Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
   <Proxy balancer://cluster>
      BalancerMember http://XXX.XXX.XXX.XXX:80 route=driveX
      BalancerMember http://YYY.YYY.YYY.YYY:80 route=driveY
      BalancerMember ...
      
      ProxySet lbmethod=byrequests
      ProxySet stickysession=ROUTEID
   </Proxy>
   ProxyPass / balancer://cluster/

   SSLEngine on
   SSLCertificateFile /etc/ssl/private/drive.caminstech.upc.edu.crt
   SSLCertificateKeyFile /etc/ssl/private/drive.caminstech.upc.edu_privatekey.pem
   BrowserMatch "MSIE [2-6]" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0
   BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>

 Se podría evaluar la utilización de un balanceador más ligero (por ejemplo HAProxy).

 Se podría evaluar la utilización de un sistema de sesión única (por ejemplo memcached).

Frontend

Las diferentes instancias de ownCloud 6.0.3 corren sobre el servidor web nginx. Tanto el código de la aplicación, los ficheros de usuario como la base de datos se encuentran centralizados en el servidor de backend, por tanto, todas las instancias ejecutan la misma aplicación.

Para la configuración del servidor web se han seguido las instrucciones del manual de configuración de ownCloud sobre nginx.

upstream php-handler {
        server 127.0.0.1:9000;
}

server {
        listen 80;
        server_name drive.caminstech.upc.edu;

        root /caminsDRIVE/owncloud;

        client_max_body_size 2G;
        fastcgi_buffers 64 4K;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        index index.php;
        error_page 403 /core/templates/403.php;
        error_page 404 /core/templates/404.php;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
                deny all;
        }

        location / {
                # The following 2 rules are only needed with webfinger
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

                rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

                try_files $uri $uri/ index.php;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                try_files $1 = 404;

                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$1;
                fastcgi_param PATH_INFO $2;
                fastcgi_param HTTPS on;
                fastcgi_pass php-handler;
        }

        # Optional: set long EXPIRES header on static assets
        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires 30d;
                # Optional: Don't log access to assets
                access_log off;
        }
}

El tamaño máximo de los ficheros de subida también hay que definirlo en el fichero de configuración del PHP (/etc/php5/fpm/php.ini).

  upload_max_filesize = 2G
  post_max_size = 2G

Backend

Durante la creación de la base de datos es necesario dar acceso a las diferentes instancias de los frontends (ex. frontend1, frontend2).

mysql> create database owncloud;
mysql> grant usage on *.* to username@frontend1 identified by 'password';
mysql> grant all privileges on owncloud.* to username@frontend1;
mysql> grant usage on *.* to username@frontend2 identified by 'password';
mysql> grant all privileges on owncloud.* to username@frontend2;

Por último, debemos dar acceso a los directorios compartidos por NFS añadiendo las siguientes líneas al fichero /etc/exports

/caminsDRIVE/files <frontend1>(rw,sync,root_squash,no_subtree_check)
/caminsDRIVE/owncloud <frontend1>(rw,sync,root_squash,no_subtree_check)

 En caso que el número de grupos del servidor LDAP sea grande (>1000), las herramientas de administración de 'ownCloud sufren tiempos de espera elevados. Por dicha razón, en esta solución se optó por implementar un servidor OpenLDAP dedicado. Este servidor sólo contiene los usuarios y grupos necessarios para el funcionamiento del servicio.

Desarrollo a medida de plugins

En nuestro caso, la herramienta de consulta del espacio usado por los usuarios no cubría nuestras necesidades. Por esta razón, hemos implementado un plugin de administración que permite consultar el espacio en disco utilizado por cada usuario. Este plugin está disponible en bitbucket.

Enlaces de interés

Añadir nuevo comentario

Image CAPTCHA