Asesoramiento +5491133339157
Ventas +5401149032178
[email protected]

Cómo Instalar Moodle Correctamente

Overwhelmed woman at a busy security operations desk with many monitors displaying red warning messages like malware attack warnings.


“Instalar Moodle” suena simple: bajás el paquete, corrés el instalador, listo. En producción, para una instalación que sostenga miles de usuarios concurrentes con SLA real, esa instalación básica es apenas el punto de partida. Lo que sigue es arquitectura de sistemas: tuning de motor de base de datos, gestión de estado distribuido, aislamiento de procesos y una superficie de ataque que hay que cerrar capa por capa.

Con más de 27 años administrando más de 500 instalaciones de Moodle —incluyendo campus corporativos de +10.000 usuarios activos— en Pixelnet trabajamos a diario con los problemas que aparecen recién cuando una instalación “que funciona” se somete a carga real.

1. Stack de servidor: tuning, no solo instalación

      • PHP-FPM con pools dedicados por sitio en instalaciones multi-tenant, ajustando pm.max_children, pm.start_servers y pm.max_requests según el patrón de tráfico real de cada campus — un pool mal dimensionado genera 502/504 bajo carga aunque el servidor tenga recursos disponibles

      • OPcache calibrado con opcache.memory_consumption, opcache.max_accelerated_files y opcache.revalidate_freq ajustado a 0 solo en entornos donde el deploy invalida caché explícitamente, para evitar servir código stale post-actualización

      • InnoDB con innodb_buffer_pool_size dimensionado al 60-70% de la RAM disponible en servidores dedicados a base de datos, innodb_log_file_size ajustado para reducir I/O de checkpoint, y innodb_flush_log_at_trx_commit evaluado según el trade-off entre durabilidad y throughput de escritura

      • Índices compuestos en las tablas de mayor volumen (mdl_logstore_standard_log, mdl_grade_grades_history) que Moodle no crea por defecto y que se vuelven críticos a partir de cierto volumen de registros históricos

    2. Gestión de estado: sesiones, locks y concurrencia

    En instalaciones con más de un nodo de aplicación (balanceo de carga real, no solo redundancia pasiva), el manejo de sesión no puede quedar en archivos locales. Requiere un backend de sesión compartido —típicamente Redis— con session locking configurado correctamente (\core\session\redis) para evitar condiciones de carrera cuando un mismo usuario dispara requests concurrentes (por ejemplo, un quiz con auto-guardado de respuestas via AJAX). Sin locking apropiado, aparecen pérdidas de datos silenciosas que solo se detectan cuando un alumno reporta que perdió una respuesta.

    3. MUC (Moodle Universal Cache): más allá del “activar Redis”

    Configurar Redis como application cache requiere entender que no todos los cache stores de Moodle soportan el mismo mecanismo de autenticación — el store de sesión y el de aplicación tienen comportamientos distintos frente a ACL con usuario/contraseña, y mezclarlos mal produce fallos de conexión intermitentes difíciles de reproducir. En servidores con múltiples instalaciones de Moodle compartiendo la misma instancia de Redis, además, hay que definir prefijos de key por sitio y, en algunos casos, bases de datos lógicas separadas para evitar colisiones de caché entre instalaciones.

    4. Cron distribuido y Task API

    Más allá del cron clásico cada minuto, Moodle moderno separa tareas en ad-hoc tasks y scheduled tasks, cada una con su propia cola. En instalaciones grandes conviene correr workers dedicados (admin/cli/adhoc_task.php) en paralelo al cron principal, con control de concurrencia para que tareas largas (regrado masivo, generación de reportes, procesamiento de backups) no bloqueen tareas críticas de notificación. Mal configurado, un solo proceso cron intentando hacer todo secuencialmente genera colas que se acumulan y notificaciones que llegan con horas de retraso.

    5. Seguridad de superficie completa

      • TLS con ciphers modernos únicamente (deshabilitando TLS 1.0/1.1 y ciphers débiles), HSTS con preload

      • Aislamiento a nivel de proceso (CageFS/CloudLinux o contenedores) para que un compromiso en una instalación no exponga las demás en el mismo host

      • moodledata fuera del document root, con permisos mínimos necesarios y sin ejecución de PHP habilitada dentro de ese directorio (mitiga upload de webshells vía áreas de subida de archivos)

      • Content Security Policy configurada para mitigar XSS en contenido generado por usuarios (foros, tareas, wikis)

      • Rate limiting a nivel de proxy/WAF sobre endpoints de login y API para mitigar fuerza bruta y scraping

    6. Backups: RPO/RTO reales, no solo “hay un backup”

    Definir una estrategia de backup seria implica separar el dump de base de datos (con mysqldump --single-transaction o snapshots a nivel de storage para evitar locks largos en tablas grandes) del contenido de moodledata, versionar ambos de forma sincronizada, y calcular RPO (cuánto dato podés perder) y RTO (cuánto tarda restaurar) reales para el volumen de tu instalación — no asumidos. Un backup de 40GB de moodledata sin snapshot a nivel de filesystem puede tardar horas en restaurar, tiempo que en un incidente real es inaceptable.

    7. Escalado horizontal y observabilidad

    Instalaciones que necesitan sostener crecimiento requieren pensar desde el día uno en balanceo de carga entre múltiples nodos de aplicación, un backend de base de datos que soporte réplicas de lectura para reportes pesados sin afectar el tráfico transaccional, y monitoreo activo de métricas clave (query time, cola de tareas cron, uso de memoria de PHP-FPM) para detectar degradación antes de que se convierta en una caída.

    Por qué esto no es “seguir la documentación oficial”

    Cada punto de esta lista tiene documentación pública. Lo que no está documentado es cómo interactúan entre sí bajo carga real: un pool de PHP-FPM mal dimensionado puede enmascararse como “problema de base de datos”, un cache store mal configurado puede producir errores que parecen bugs de un plugin, y un backup nunca restaurado es, técnicamente, indistinguible de no tener backup. Diagnosticar estas interacciones requiere experiencia acumulada viendo fallar instalaciones reales, no solo haber levantado una que funciona en condiciones ideales.

    En Pixelnet diseñamos infraestructura de Moodle para producción real

    Con 27 años de experiencia y más de 500 instalaciones administradas para empresas como Shell/Puma Energy, Sanofi, Pfizer, BCRA y AFA, dimensionamos cada instalación según su carga real proyectada — no una configuración genérica que “debería andar”.

    Contactanos para una arquitectura de Moodle pensada para escalar 

    CONTACTANOS