Cuando una instalación Moodle se distribuye entre varios nodos web, moodledata suele convertirse en uno de los elementos compartidos de la arquitectura.

La aproximación más habitual consiste en situarlo sobre algún sistema de almacenamiento accesible desde todos los nodos. NFS sigue siendo una de las soluciones más utilizadas para este propósito, aunque también aparecen cabinas NAS, filesystems distribuidos o servicios gestionados en cloud.

La popularidad de NFS no resulta difícil de explicar. Sus limitaciones son conocidas (latencia asociada a determinadas operaciones sobre metadatos, dependencia de un punto central de almacenamiento o dificultades para escalar ciertos patrones de carga) y han sido ampliamente discutidas durante años. Al mismo tiempo, ofrece una combinación difícil de ignorar de simplicidad, compatibilidad y facilidad operativa. En muchos entornos resuelve adecuadamente el problema sin introducir una complejidad adicional significativa.

A partir de ese momento, parte del comportamiento de la plataforma queda condicionado por las características de ese almacenamiento compartido.

Moodledata no es un único problema

Resulta habitual hablar de moodledata como si fuera una única entidad. Sin embargo, dentro conviven componentes con comportamientos muy distintos:

  • ficheros gestionados por la File API,
  • cachés,
  • sesiones,
  • directorios temporales,
  • copias de seguridad,
  • datos generados por plugins.

Cada uno presenta requisitos diferentes en términos de persistencia, coherencia y rendimiento.

Desde una perspectiva arquitectónica, separar estos comportamientos permite identificar qué información necesita visibilidad global entre nodos y cuál puede permanecer local sin afectar al funcionamiento de la plataforma.

Qué suele compartirse y qué puede permanecer local

Los contenidos almacenados mediante la File API constituyen el caso más evidente.

Un fichero subido desde cualquier nodo debe estar disponible para el resto de la plataforma independientemente del servidor que atienda la siguiente petición.

Otros elementos presentan requisitos distintos.

Las sesiones pueden externalizarse a Redis u otros sistemas especializados. Redis también aparece con frecuencia como backend de caché para la MUC y como soporte para distintos mecanismos de coordinación dentro de la plataforma, reduciendo la necesidad de resolver determinados problemas mediante filesystem compartido.

Parte de las definiciones de caché pueden mantenerse localmente en cada nodo. Algunos directorios temporales únicamente tienen sentido durante la ejecución de un proceso concreto.

Las copias de seguridad merecen una consideración específica. Aunque el resultado final suele formar parte del estado persistente de la plataforma, durante su generación aparecen patrones de lectura, escritura y procesamiento muy distintos de los que predominan durante el uso habitual del sistema. La generación de backups, restauraciones o importaciones masivas puede ejercer una presión considerable sobre el almacenamiento y modificar temporalmente el perfil de carga de la plataforma.

La propia arquitectura de Moodle ya contempla varios de estos escenarios mediante la MUC, el sistema de sesiones y distintos mecanismos de almacenamiento local.

Por este motivo, una arquitectura distribuida no implica necesariamente que todo el contenido asociado a moodledata deba tratarse de la misma manera.

Moodle y el filesystem

La forma en la que Moodle utiliza el almacenamiento merece cierta atención.

La File API genera una cantidad considerable de accesos sobre ficheros pequeños, consultas sobre metadatos y operaciones de lectura distribuidas a lo largo de la estructura de almacenamiento. A esto se añaden tareas programadas, procesos de copia de seguridad, restauraciones, generación de contenido derivado y otras operaciones que interactúan continuamente con el filesystem.

Este comportamiento hace que métricas como el throughput secuencial no siempre sean buenos predictores del comportamiento real de la plataforma.

En muchos casos, la latencia asociada a operaciones sobre metadatos, bloqueos o accesos concurrentes termina teniendo más impacto que la velocidad máxima de transferencia que puede mostrar un benchmark sintético.

Por este motivo, soluciones técnicamente muy capaces pueden ofrecer resultados menos favorables de lo esperado cuando se enfrentan a determinados patrones de acceso generados por Moodle.

Sobre benchmarks y resultados inesperados

Hace años realicé distintas pruebas comparando varias tecnologías de almacenamiento compartido sobre una maqueta Moodle.

Entre las soluciones evaluadas estaban NFS, Samba, CephFS y GlusterFS.

El resultado más llamativo fue que Samba obtuvo los mejores resultados en aquel entorno concreto.

No he repetido esas pruebas recientemente y no asumiría que las conclusiones siguen siendo válidas hoy. Todas esas tecnologías han evolucionado durante la última década. Tampoco asumiría que esos resultados serían reproducibles en otra instalación distinta.

Lo que sí sigue siendo válido es la observación que surgió durante aquellas pruebas. El resultado dependía mucho más de la carga utilizada que de la tecnología evaluada.

Una plataforma Moodle no representa necesariamente a otra

Dos instalaciones pueden compartir versión, infraestructura e incluso un número similar de personas usuarias y, aun así, generar patrones de acceso completamente distintos.

Una plataforma basada principalmente en cuestionarios puede concentrar buena parte de su actividad sobre la base de datos.

Otra puede almacenar grandes volúmenes de contenido SCORM.

Otra puede utilizar repositorios externos o herramientas integradas mediante LTI para la mayor parte de sus contenidos.

También existen diferencias derivadas de plugins propios, integraciones corporativas, procesos batch o sistemas de generación documental.

Cada uno de estos escenarios genera una combinación distinta de accesos a base de datos, caché, red y almacenamiento.

Por este motivo, extrapolar resultados obtenidos en otras organizaciones tiene un valor limitado si no se entiende primero qué comportamiento representa realmente esa prueba.

La importancia de una carga representativa

Cuando se evalúa almacenamiento para Moodle, la calidad de la prueba suele depender en gran medida de la carga utilizada.

Una maqueta que no reproduzca el comportamiento real de la plataforma puede llevar a conclusiones técnicamente correctas sobre esa maqueta y poco útiles para producción.

El volumen de personas usuarias concurrentes, el tipo de contenidos, los procesos programados, las integraciones externas o la distribución de lecturas y escrituras influyen directamente en los resultados obtenidos.

La representatividad de la carga termina siendo tan importante como la propia tecnología evaluada.

La operación también forma parte de la decisión

La elección del almacenamiento no afecta únicamente al rendimiento. También condiciona la operación diaria de la plataforma.

NFS suele ofrecer una aproximación relativamente sencilla de desplegar, monitorizar y mantener. Otras alternativas pueden aportar ventajas relacionadas con disponibilidad, distribución de carga o tolerancia a fallos, pero también incorporan nuevos componentes, procedimientos de recuperación más complejos y requisitos operativos adicionales.

Los servicios gestionados en cloud desplazan parte de esa responsabilidad hacia el proveedor, reduciendo determinadas tareas de administración a cambio de introducir nuevas dependencias y limitaciones.

Estas diferencias forman parte de la decisión arquitectónica.

Las características técnicas de una solución constituyen una parte de la evaluación. La capacidad del equipo para desplegarla, operarla, diagnosticar incidencias y recuperarse ante fallos constituye otra parte igualmente relevante.

El almacenamiento elegido hoy también condiciona futuras decisiones de escalado, alta disponibilidad, recuperación ante desastres o migración hacia otros entornos.

Algunas soluciones ofrecen un punto de partida sencillo y una operación relativamente contenida. Otras introducen mayor complejidad inicial a cambio de aportar más margen en determinados escenarios de crecimiento o distribución.

La decisión final suele apoyarse en un equilibrio entre estos factores y no únicamente en métricas de rendimiento.

Una decisión que rara vez pertenece a una única disciplina

En entornos con cierto tamaño, este tipo de decisiones rara vez dependen de una única persona o equipo.

Infraestructura, operación, desarrollo, seguridad y responsables de la plataforma suelen aportar perspectivas distintas sobre disponibilidad, costes, riesgos, mantenimiento o evolución futura.

La evaluación técnica de una solución constituye una parte importante del proceso, aunque normalmente convive con otros factores relacionados con la organización y con la forma en la que la plataforma va a ser operada durante los próximos años.

Por este motivo, la decisión final suele beneficiarse de una visión multidisciplinar capaz de equilibrar necesidades técnicas, operativas y organizativas dentro de un mismo marco.

Almacenamiento compartido como decisión arquitectónica

No existe una solución universal para compartir almacenamiento en Moodle.

Sin embargo, tampoco todas las alternativas presentan el mismo grado de madurez, complejidad operativa o recorrido dentro del ecosistema.

NFS, las cabinas NAS tradicionales y distintos servicios gestionados han demostrado su viabilidad durante años en un gran número de instalaciones. Otras aproximaciones pueden resultar igualmente válidas cuando los requisitos del entorno las justifican.

La validación mediante cargas representativas permite evaluar cómo responde cada alternativa dentro del contexto real de la plataforma y aporta información útil para valorar no solo su comportamiento actual, sino también su encaje dentro de la evolución prevista del entorno.

En este contexto, el objetivo no consiste tanto en encontrar una tecnología ganadora como en comprender qué comportamiento necesita soportar la instalación y evaluar las distintas alternativas bajo condiciones que se parezcan razonablemente a las de producción.