El problema

Actualmente la forma convencional de proveer un un servicio de infomación a gran cantidad de clientes es mediante muchos servidores que comparten datos en una Base de Datos Relacional -que normalmente corre en un servidor dedicado- a la que todos acceden en forma simultánea.

Aún cuando esta arquitectura es simple y eficiente, hay ciertos tipos de problemas para los cuales no es una solución adecuada. Por ejemplo los servicios de Internet masivos -tales como un webmail para millones de usuarios- que corren en un cluster de cientos o miles de servidores, y donde muchos procesos leen y guardan información en forma concurrente.

A medida que la cantidad de escrituras y consultas a la base de datos crece, la calidad de servicio disminuye, ya que todos los clientes dependen de ese recurso común.

Una solución alternativa en muchos casos es tratar de llevar esos datos al File System y sincronizar los cambios entre los distintos nodos que contienen cada una de las copias del File System. Esta solución basada en File System tiene problemas también, dado que los File System existentes no ofrecen servicios necesarios tales como:

. Sincronización de nodos, cuando se producen cambios en más de un nodo a la vez, se hace difícil determinar cuál es el último cambio válido.

. Atomicidad. No es posible hacer transacciones atómicas

. Versionado de archivos

El proyecto JuanjoFS

El proyecto es el diseño y desarrollo de un pseudo File System distribuido (llamado JuanjoFS) que provea servicios de versionado, transaccionalidad atómica y sincronización automática.

Un requerimiento esencial para la escalabilidad es que los archivos sean servidos por más de un nodo a la vez con una infraestructura de sincronización eficiente. Es decir que a diferencia de File Systems distribuidos convencionales como NFS o CIFS, los servicios del JuanjoFS los proveerá más de un nodo a la vez y cada uno de los nodos conservará una copia completa de los archivos que se encuentren bajo su control, incluyendo las revisiones anteriores de cada uno de los archivos.

Esta situación es la que viven todos los días y que han solucionado hace ya algún tiempo los controladores de versiones distribuidos (ej.: Git, Mercurial, Monotone, Darcs, Bazaar, etc.). Por eso, una interfaz de File System con soporte para versionado y sincronización automática, montada sobre un controlador de versiones distribuido resolvería de manera simple y eficaz un problema que hoy es muy complicado y crítico para cualquier servicio que apunte a gran cantidad de clientes.

El JuanjoFS implementará un interfaz capaz de proveer:

a. funciones tradicionales de un File System (ej.: abrir, leer, escribir, moverse y cerrar un archivo).

b.una interfaz transaccional (no anidable) para manejo de archivos y directorios (ej.: crear un archivo, modificar otro, confirmar los cambios -commit- o cancelarlos -rollback-).

c. funciones para consulta de versiones previas de los archivos (ej.: obtener lista de revisiones que son ancestros de una revisión dada, obtener una copia de los archivos a una fecha o revisión determinada, etc.)

d. funciones de sincronización con otros nodos (ej.: obtener cambios efectuados en otro nodo, enviar cambios del nodo local a uno remoto, etc.)

Justificación y originalidad del proyecto

La arquitectura en capas con n servidores de aplicación y 1-n servidores de Base de Datos no escala bien para este tipo de problemas.

La arquitectura basada en File System convencionales tampoco escala bien ya que no permite sincronizar servidores fácilmente ni gestionar versiones.

Los File System distribuidos (NFS, etc.) no son adecuados porque mantienen sincronizados todos los archivos en tiempo real (en el nodo correspondiente a cada archivo) y en consecuencia producen un cuello de botella cada vez más grande a medida que la cantidad de datos y la tasa de usuarios y transacciones concurrentes crece.

En los servicios de Internet, donde la "nube" de servidores atiende a miles de usuarios distribuidos, se busca hacer que el usuario sea atendido por un servidor cercano y de no tener la información requerida el servidor la solicita y sincroniza "on the fly" para la sesión.

No existe un File Sytem que provea los servicios (descritos en 2.) requeridos para este tipo de problemática relativamente nueva.

Quienes podrían beneficiarse con este software

• Servicios de Directorio masivos (tales como webmail, proveedores de telefonía por Internet, menssengers, servicios de web-conference, comunidades on-line, etc.)
• Comunidades y Sistemas de gestión de contenidos on-line con cientos de miles de usuarios que producen y consumen los contenidos.

Implementación

Para simplificar el acceso a este servicio, se desarrollará una librería en C con envoltorios (wrappers) en Erlang y Java. Se incluirán también casos de test automáticos para verificar la corrección de las acciones del Filesystem.

Por último, se implementará en un caso real de un servicio de telefonía por Internet líder para empresas en Estados Unidos.