Dimensionar bien un servidor Moodle no es una decisión que se toma una vez y queda fija para siempre. Un centro que empieza con 200 alumnos y llega a 2.000 en dos años necesita un servidor muy distinto, y la pregunta real no es solo “cuánto necesito ahora”, sino “cómo subo la potencia cuando haga falta, sin tener que planificar una migración completa cada vez que crezco”.
En esta guía vas a ver la diferencia entre escalar en caliente y migrar, cuándo escalar verticalmente frente a horizontalmente, y cómo prepararte con antelación para un pico de matrícula o de examen sin sorpresas.
Escalar en caliente vs migrar: no es lo mismo
Escalar en caliente significa aumentar los recursos (CPU, RAM, disco) de tu servidor actual sin cambiar de máquina ni de proveedor, algo que la mayoría de proveedores cloud permiten hacer en minutos, con una breve reinicialización del servidor, no una migración completa.
Migrar implica mover tu instalación a un servidor distinto, con todo el proceso que eso conlleva (copiar código, base de datos, moodledata, cambiar DNS si aplica). Es lo que hay que hacer cuando el servidor actual, aunque se escale al máximo permitido por su proveedor, ya no da más de sí, o cuando cambias de arquitectura por completo (por ejemplo, pasar de un único servidor a separar base de datos y aplicación).
Para la mayoría de crecimientos progresivos de matrícula, escalar en caliente dentro del mismo proveedor cloud es la vía más rápida y con menos riesgo, reservar la migración completa para cuando de verdad se agote el margen de esa vía.
Antes de añadir hardware: exprime la configuración actual
El error que más vemos entrar por soporte no es un servidor pequeño, sino un servidor bien dimensionado mal configurado. Antes de pagar más CPU, comprueba que ya estás aprovechando la que tienes. Estas palancas no cuestan nada y a menudo dan más margen que duplicar el hardware:
- OPcache activado y bien dimensionado. Sin OPcache, PHP recompila el código de Moodle en cada petición. Con él, se sirve desde memoria. Es la mejora de rendimiento más barata que existe y demasiadas instalaciones la tienen sin ajustar.
- Redis (o al menos una caché en memoria) para la caché de aplicación y de sesión. Sacar la caché de MUC y las sesiones del disco descarga la base de datos y acelera cada carga de página.
- Cron ejecutándose cada minuto y sin tareas atascadas. Un cron mal configurado hace que tareas pesadas se disparen en pleno pico en lugar de por la noche. Revisa que no haya trabajos encolados acumulándose.
- Base de datos afinada: buffers de InnoDB acordes a la RAM, consultas lentas revisadas y estadísticas al día.
Todo esto lo desarrollamos en rendimiento y optimización de Moodle y en requisitos de servidor para Moodle. La regla es sencilla: optimiza primero, escala después. Añadir nodos para tapar una caché apagada es pagar por un problema que se arregla gratis.
Escalado vertical: más recursos en el mismo servidor
Aumentar CPU y RAM del servidor existente es la forma más simple de escalado, y suele bastar hasta varios cientos de usuarios concurrentes. Como vimos en requisitos de servidor para Moodle, más allá de 8-16 vCPU el beneficio proporcional se reduce, por lo que el escalado vertical tiene un techo práctico, no es una solución infinita.
La otra cara del vertical es saber qué recurso te falta, porque subir el que no toca no arregla nada. Si la CPU se satura, el cuello suele estar en el número de procesos PHP-FPM que atienden peticiones en paralelo: más vCPU permiten más workers activos a la vez. Si lo que se dispara es el uso de RAM o el sistema empieza a tirar de swap, el problema es de memoria, no de CPU, y ahí la base de datos y la caché son los primeros sospechosos. Diagnostica antes de comprar: un pico que se resuelve con más RAM no mejora nada si le echas vCPU, y viceversa.
La ventaja del vertical es que no cambia la arquitectura: sigues teniendo un solo servidor, una sola instalación, cero componentes nuevos que administrar. Por eso es la primera opción hasta que el techo aparece de verdad.
Escalado horizontal: varios servidores en paralelo
Cuando el escalado vertical llega a su límite práctico, la alternativa es repartir la carga entre varios servidores web trabajando en paralelo, detrás de un balanceador de carga. El principio es que el estado no puede vivir dentro de cada nodo web: si cada servidor guarda sus propias sesiones, sus propios archivos o su propia caché, los nodos se contradicen entre sí. Todo lo que sea estado compartido tiene que salir de los nodos web y vivir en un servicio común al que todos acceden por igual:
- Sesiones en Redis compartido, no en archivos locales de cada servidor, de lo contrario, un usuario podría perder su sesión si el balanceador lo envía a un servidor distinto en la siguiente petición.
moodledataen almacenamiento compartido (NFS o almacenamiento de objetos), montado idéntico en todos los nodos web. Es donde viven los archivos subidos, las copias de seguridad y buena parte de la caché de disco; si cada nodo tuviera su propiomoodledata, un archivo subido en un servidor no existiría en los demás.- Base de datos centralizada, normalmente ya en su propio servidor dedicado en esta fase de crecimiento, para que todos los nodos lean y escriban contra la misma fuente de verdad.
- Un balanceador de carga delante, que reparte cada petición entrante entre los nodos disponibles y deja de enviar tráfico a un nodo que falle.
El matiz que ahorra dolores de cabeza: con las sesiones en Redis, el balanceador no necesita sticky sessions. Cuando las sesiones viven en archivos locales, estás obligado a “pegar” a cada usuario siempre al mismo nodo (afinidad de sesión), lo que reparte la carga de forma desigual y complica sacar un nodo de rotación. Al centralizar la sesión en Redis, cualquier nodo puede atender cualquier petición de cualquier usuario, y el balanceador puede repartir de verdad y retirar nodos sin cortar a nadie. Este detalle es la mitad de la razón por la que se mete Redis en una arquitectura horizontal, la otra mitad es la caché. Lo explicamos a fondo en Redis para Moodle.
Esta arquitectura es más compleja de montar y de operar que el escalado vertical (hay más piezas que pueden fallar), pero a cambio permite crecer prácticamente sin techo: cuando necesitas más capacidad, añades otro nodo web y el balanceador empieza a mandarle tráfico.
Vertical vs horizontal: cuál y cuándo
| Escalado vertical | Escalado horizontal | |
|---|---|---|
| Cuándo usarlo | Crecimiento moderado, hasta varios cientos de concurrentes | Volumen alto o picos que ya no caben en un solo servidor |
| Ventaja | Simple: misma arquitectura, un solo servidor que administrar | Crece casi sin techo añadiendo nodos; tolera la caída de un nodo |
| Límite | Techo práctico de CPU/RAM del proveedor; rendimiento decreciente | Coste y piezas nuevas: balanceador, Redis, almacenamiento compartido |
| Complejidad | Baja: a menudo un cambio en caliente de minutos | Alta: sesiones, moodledata y BD compartidos, balanceador delante |
La lectura práctica: empieza siempre por vertical y no te compliques hasta que el vertical se quede sin margen. Montar una arquitectura horizontal para 300 alumnos concurrentes es pagar complejidad que no necesitas.
Prueba de carga: dimensiona con datos, no el día de la matrícula
La forma más cara de descubrir que tu servidor no aguanta es descubrirlo el día de la matrícula, con 800 familias intentando entrar a la vez. La prueba de carga es exactamente lo contrario: simular esa concurrencia en un entorno controlado, con antelación, para saber el número real antes de que llegue el pico de verdad.
El objetivo es responder a una pregunta concreta: ¿cuántos usuarios activos simultáneos soporta esta configuración antes de que los tiempos de respuesta se disparen? Ojo con el matiz, porque aquí se confunde mucha gente: no es lo mismo usuarios registrados que usuarios concurrentes, ni concurrentes que activos a la vez. Un centro con 2.000 alumnos rara vez tiene 2.000 peticiones simultáneas; lo que dimensiona el servidor es cuántos están pulsando al mismo tiempo en la ventana crítica (esos 15 minutos en los que se abre la matrícula o empieza el examen), no el total del padrón.
Para simular esa carga se usan herramientas de pruebas de carga como Apache JMeter, k6 o Locust, que lanzan cientos o miles de usuarios virtuales recorriendo un guion realista: entrar, autenticarse, abrir un curso, enviar un cuestionario. Moodle facilita la parte más tediosa: incluye un generador de datos de prueba (admin/tool/generator) capaz de crear cursos de test y un plan de pruebas para JMeter, para no tener que inventar el escenario a mano.
Lo que miras al ejecutarla:
- Tiempo de respuesta conforme sube la concurrencia, el punto en el que empieza a degradarse es tu techo real.
- Errores (timeouts, 5xx): si aparecen, ya has encontrado el límite antes que tus alumnos.
- Dónde está el cuello: CPU saturada, PHP-FPM sin workers libres, la base de datos frenando o el disco. Ese dato es el que te dice qué escalar.
Con ese número en la mano, escalar deja de ser una corazonada. Sabes si tu configuración actual llega, cuánto margen te falta y qué recurso concreto añadir.
Preparar un pico de matrícula o examen con antelación
- Estima la concurrencia esperada con margen: si esperas 500 alumnos simultáneos, planifica para algo más, no exactamente esa cifra.
- Escala los recursos con antelación, no el mismo día del pico, un cambio de última hora no deja margen para verificar que todo funciona correctamente tras el ajuste.
- Haz una prueba de carga tras escalar, simulando el tráfico esperado, para confirmar que la nueva configuración realmente soporta la concurrencia prevista.
- Ten un plan para revertir el escalado después del pico, si el aumento de recursos fue temporal y no necesitas mantenerlo de forma permanente, muchos proveedores cloud facturan por recursos activos, así que reducir tras el pico también tiene sentido económico.
Checklist antes de un pico previsto
Cuando la fecha está en el calendario (matrícula, examen masivo, convocatoria), esto es lo que conviene tener cerrado unos días antes, no la víspera:
- Optimización al día: OPcache activo, Redis sirviendo caché y sesiones, cron sin tareas atascadas.
- Recursos escalados y verificados con una prueba de carga que confirme la concurrencia objetivo, no una estimación de despacho.
- Base de datos revisada: sin consultas lentas conocidas, buffers acordes a la RAM, backup reciente por si acaso.
- Monitorización activa durante la ventana crítica, para ver la carga en tiempo real y reaccionar si algo se tensa.
- Plan de reversión listo si el escalado es temporal, para volver al dimensionamiento normal en cuanto pase el pico.
- Ventana de cambios cerrada: nada de actualizar Moodle, plugins ni el sistema en los días previos al pico. Se congela y punto.
Cuándo escalar de forma permanente vs solo para el pico puntual
| Situación | Estrategia |
|---|---|
| Crecimiento sostenido de matrícula | Escalado permanente, revisando el dimensionamiento cada cierto tiempo |
| Pico puntual (examen final, convocatoria concreta) | Escalado temporal, revertido tras el evento |
| Picos recurrentes y predecibles (cada fin de trimestre) | Automatizar el escalado según calendario, si el proveedor lo permite |
Errores comunes al escalar
- Escalar el mismo día del pico, sin margen para verificar que el cambio funciona correctamente antes de que llegue la demanda real.
- Escalar solo verticalmente sin límite, sin plantearse en qué punto conviene pasar a una arquitectura horizontal.
- No usar Redis compartido al escalar horizontalmente, provocando pérdida de sesiones cuando el balanceador reparte usuarios entre distintos nodos.
- No revertir el escalado tras un pico puntual, pagando de más por recursos que ya no se necesitan mantener activos.
- No hacer una prueba de carga tras escalar, dando por hecho que el cambio funciona sin confirmarlo activamente.
Preguntas frecuentes
¿Puedo escalar mi servidor Moodle sin downtime? El escalado vertical en la mayoría de proveedores cloud implica una breve reinicialización, no una migración completa, el tiempo de inactividad suele ser de minutos, no de horas.
¿Cuándo debería pasar de escalado vertical a horizontal? Cuando el escalado vertical alcanza un techo práctico (más allá de 8-16 vCPU con beneficio proporcional decreciente) o cuando la concurrencia supera varios cientos de usuarios de forma habitual, no solo en picos puntuales.
¿Necesito Redis compartido si tengo varios servidores web? Sí, es imprescindible para que las sesiones de usuario se mantengan correctamente independientemente de a qué servidor los dirija el balanceador de carga en cada petición.
¿Con cuánta antelación debería escalar antes de un examen? Al menos varios días antes, dejando margen para verificar con una prueba de carga que el cambio realmente soporta la concurrencia esperada.
¿Debo mantener el escalado permanente tras un pico puntual? Solo si el crecimiento es sostenido; si fue un pico puntual (un examen concreto), revertir el escalado después ahorra costes de infraestructura que ya no se necesitan.
¿Escalar es lo mismo que migrar de servidor? No, escalar aumenta los recursos del servidor actual sin cambiar de máquina; migrar implica mover la instalación completa a un servidor distinto, un proceso más complejo tratado en migrar Moodle a un nuevo servidor sin perder cursos.
¿Necesito sticky sessions en el balanceador? No si centralizas las sesiones en Redis. Con la sesión fuera de los nodos web, cualquiera puede atender a cualquier usuario y el balanceador reparte libremente. Solo necesitarías afinidad de sesión (sticky sessions) si mantuvieras las sesiones en archivos locales de cada servidor, que es justo lo que conviene evitar al escalar horizontalmente.
¿Cuántos usuarios concurrentes aguanta Moodle? No hay una cifra fija: depende del hardware, de la configuración (caché, base de datos) y de qué estén haciendo los alumnos (no pesa igual leer un tema que enviar un cuestionario con cientos a la vez). Por eso la respuesta seria no sale de una tabla, sino de una prueba de carga sobre tu propia instalación con un escenario realista.
¿Y si el pico llega sin previo aviso? Escalar en caliente permite subir recursos en minutos en la mayoría de proveedores cloud, así que se puede reaccionar. Pero reaccionar siempre sale peor que anticipar: sin tiempo para una prueba de carga, escalas a ciegas. Si tus picos son predecibles (matrículas, exámenes de fin de trimestre), lo rentable es tenerlos en el calendario y prepararlos, no improvisar.
Conclusión
Escalar Moodle antes de un pico de alumnos no debería ser una sorpresa de última hora, con margen de antelación, una prueba de carga previa, y la arquitectura correcta (vertical para crecimiento moderado, horizontal cuando el volumen lo exige), el pico deja de ser un riesgo y se convierte en un procedimiento planificado.
Si prefieres que alguien calcule y ejecute este escalado por ti antes de cada pico previsible, en Avantys lo llevamos como parte del mantenimiento continuo de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Requisitos de servidor para Moodle (CPU, RAM, disco)
- Migrar Moodle a un nuevo servidor sin perder cursos
- Redis para Moodle: caché en memoria explicado
- Qué hacer cuando Moodle se cae durante un examen
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
