Sesión dinamizada junto a Pau Ferrer durante la HackFest de MoodleMoot Spain 2015 celebrada en Palma de Mallorca. Adreça web de la presentació d'origen a Google docs: http://goo.gl/yx9ZH7. La penjada a Slideshare és una exportació en format PDF.

1. Sara Arjona Téllez
Pau Ferrer Ocaña
High Availability
& Clusters
@sara_arjona
@crazyserver
22 de Octubre de 2015

2. Índice
★ ¿Quiénes somos?
★ Alta disponibilidad
○ Arquitectura
○ Despliegues
○ DevOPS
★ Rendimiento
○ Puntos de mejora en función del rol
■ Profesor
■ Administrador de Moodle
■ Administrador de sistemas
■ Desarrollador
○ Pruebas automatizadas
○ Pruebas de carga
2
Notas colaborativas en
http://tinyurl.com/mootes15
¿Os animáis a contribuir?

3. ¿Quiénes somos?
3

4. Algunos datos sobre...
Múltiples instalaciones Moodle
★ Àgora: Centros educativos
○ 1.400 centros (de ~3.800 públicos)
○ 400.000 usuarios
○ Espacio de pruebas que se regenera cada hora
★ Odissea: Formación del profesorado
○ 47.000 usuarios
○ 2.400 cursos
★ Alexandria: Repositorio de materiales educativos
○ 13.000 usuarios
○ 280 cursos Moodle
4
Desarrollando
Moodle desde
2005

5. Infraestructura
5
Àgora Odissea
Un balanceador (BigIP)
13 servidores web
(CentOS) con PHP 5.4
4 servidores web
(CentOS) con PHP 5.4
4 frontales con memcached 1 frontal con memcached
Directorio local en cada frontal para caché en disco
1.600 esquemas Oracle
★ 2 servidores de BBDD Oracle
★ con 4 instancias de 200 esquemas
cada 1 = 1.600 esquemas
1 esquema Oracle
★ 1 servidor de BBDD Oracle
★ compartido con 2 aplicaciones
más.
1 Servidor NAS (moodledata)
¿Oracle? en 2007, cuando se inició
el proyecto, el Departament
d'Ensenyament contaba con
soporte oficial
4xCPU - 2.67GHz
4GB RAM

6. Algunos datos sobre...
Infraestructura
★ 2 balanceadores por software compartidos
★ Cabina de discos compartida
○ Tipos SSD (para BBDD), SAS y SATA.
★ BBDD Oracle v12 en clúster de 5 nodos, todos físicos
5 entornos de producción
★ Virtual: 13 servidores web virtuales (SWV) (1 dedicado exclusivamente a de cron),
base de datos en nodos 1, 2 y 3
★ Obert: 4 SWV (1 dedicado a cron), BBDD en 1, 2 y 3
★ Formación: 2 SWV, BBDD en 1, 2 y 3
★ Innovación: 2 SWV, BBDD en 4 y 5
★ IL3: 4 SWV (1 cron dedicado a cron), BBDD en 4 y 5
En el mismo armario de servidores con comunicaciones directas entre servidores para
evitar latencias. Comunicaciones dentro del armario a 10 GB 6
Caché de disco SSD es
tan rápida que con
memcached se pierde
rendimiento
9.000 cursos anuales
70.000 alumnos
5.000 profesores

7. Algunos datos sobre...
Infraestructura
Moodle 2
★ 2 Balanceadores software (Activo-Pasivo) ldirector
★ 5 servidores web virtuales (uno además se encarga del cron)
★ 2 servidores memcached (Act-Pas.)
★ 2 servidores de bases de datos MySQL (master-slave) cada uno es el pasivo
del otro (en caso de avería puede haber dos MySQL en la misma máquina).
Discos raw en cabina
★ Servidor NFS compartido (proporcionado por cabina Dell) 1TB aprox
OCW en un servidor virtual de hosting compartido
7
10.700 cursos
1.500 categorías
44.000 usuarios

8. Algunos datos sobre...
★ 8 entornos en producción
★ 2 entornos en otra arquitectura distinta, únicamente accesible por personal
del GATE (departamento que gestiona el Moodle-UPM)
★ Entorno para pruebas, últimas versiones, prueba de plugins, estilos, etc. esto
todo en un servidor virtualizado
Infraestructura de Estudios Oficiales
★ 2 Balanceadores hardware
★ 2 servidores web y 1 servidor memcached
★ 1 MySQL compartido (30Gb)
★ Servidor NAS compartido (2 TB)
★ 1 servidor "centinela" que ejecuta los cron
8
36.000 alumnos
3.100 docentes
5.000 cursos
Actualmente al 50% y
estimado que llegue al
80% al final del curso

9. Algunos datos sobre...
Infraestructura de e-UIC
★ 1 Balanceador (master-slave)
★ 5 placas servidor web
★ 1 servidor dedicado con PostgreSQL y disco SSD
★ 1 servidor NAS
9
9.800 usuarios
3.240 cursos

10. Algunos datos sobre...
Moodle
Infraestructura
Entorno virtualizado VMWare con:
★ 1 servidor BBDD Postgres: 16 GB memoria, 2 cpus. 40Gb
★ 1 servidor web: 16 GB memoria, 4 cpus. 900Gb
★ 1 servidor soporte (crons y traspasos): 16 GB memoria, 2 cpus
★ Cabina de discos
10
1.325 categorias
42.134 cursos
42.244 usuarios

11. Algunos datos sobre...
Moodle
Infraestructura
★ Balanceador HW compartido
★ 4 servidores virtuales (uno para los cron)
★ 1 servidor memcached
★ 1 servidor BD Postgresql dedicado
★ 1 servidor NAS dedicado
11
2.000 profesores
25.000 alumnos
5.000 cursos

12. Algunos datos sobre...
Moodle
Infraestructura
★ 2 Balanceadores compartidos con el resto de servicios de la Universidad
★ 3 Web proxy (terminan peticiones HTTPS, HTTP hasta Apaches, activando
flags en cabeceras HTTP)
★ 2 Front-end Apache (Solaris 10)
★ 1 servidor dedicado bases de datos MySQL
○ 3 motores Mysql.
○ 1 dataset compartido para archivos temporales
12
3.500 cursos/año académico
Histórico de 3 años
15.000 estudiantes
2.000 profesores
150-500 usuarios simultáneos
Tiempo de respuesta de
admin/user.php (buscar
usuarios) de 4 a 7 s

13. Algunos datos sobre...
13

14. Algunos datos sobre...
14
Nadav Kavalerchik
(Israel)

15. Alta disponibilidad
15
★ Arquitectura
★ Despliegues
★ DevOPS

16. Arquitectura: componentes
Recomendaciones de Moodle sobre alta disponibilidad
★ Balanceador
★ Servidores web
★ Servidor memcached
★ Base de datos
★ NAS
16
Los componentes de la arquitectura de cada instalación
dependen, entre otros, de la complejidad del sistema y del
volumen de usuarios.

17. Arquitectura: decisiones
★ ¿Hace falta balanceador? ¿software o hardware?
★ Servidores web: cuántos, de qué tipo (virtuales?), con qué
características (RAM, CPU), SO, versión de PHP…
○ Si hay más de un servidor web, hará falta NAS.
★ Servidor memcached dedicado o instalado en los
servidores web
★ Motor de base de datos: MySQL, PostgreSQL, Oracle…
★ NAS
17

18. Despliegues
★ Múltiples entornos para validar aplicaciones y reducir el
riesgo al desplegar en producción:
○ Locales:
■ Desarrollo: Vagrant!
○ Compartidos pero no productivos:
■ Integración (despliega desarrollador)
■ Preproducción (despliega tècnico sistemas). Permite validar
procedimiento y funcionamiento
★ Algunas recomendaciones (DevOps):
○ Alinear los entornos (todos deberían ser iguales)
○ Automatizar los despliegues con herramientas como Puppet
○ Desplegar con mayor frecuencia paquetes más pequeños
18
No os perdáis:
Entorno de desarrollo
rápido con Vagrant
Pau Ferrer Ocaña
(Sábado 10:45)

19. Incidencias más frecuentes
★ Comunicación: cambios en la red afectan a la visibilidad
de servidores y servicios externos:
○ Conexión con Google, Dropbox…
○ Salida a Internet (p. ej. canales RSS)
★ Errores en los permisos de los ficheros durante los
despliegues.
○ Si la MUC no tiene los permisos correctos, Moodle no funciona.
★ Sincronización de los servidores memcache:
○ Si se pierde la configuración de los servidores memcache los
usuarios no ven la información actualizada.
★ Intervenciones manuales desalinean los frontales de un
mismo entorno. 19

20. DevOPS
★ "Metodología que permite reducir la brecha entre los
desarrolladores de software y los profesionales de operaciones"
★ DevOps en 7 pasos:
a. Ingeniería del software.AGILE! Código modular, paquetes pequeños, evitar deuda técnica...
b. Control de versiones. GIT
c. Gestión de la configuración. Reduce errores, da estabilidad y permite reconstruir fácilmente
d. Integración continua. Automatiza ejecución de pruebas unitarias y avanza detección de errores
e. Testing automatizado. Ejecución de todo tipo de tests para asegurar un nivel controlado de riesgo
f. Despliegue continuo. No sólo código, también aplica a hardware.
g. Monitorización. Métricas de los servidores y del uso con herramientas con JMeter o Selenium
20
DevOps termina lo
que comenzó Agile

21. Rendimiento
★ Puntos de mejora en función del rol
○ Profesor
○ Administrador de Moodle
○ Administrador de sistemas
○ Desarrollador
★ Pruebas automatizadas
★ Pruebas de carga
21

22. Profesor
★ Activar los filtros estrictamente necesarios.
★ Redimensionar las imágenes antes de subirlas.
★ Reducir el número de secciones.
○ Seleccionar "Mostrar una sección por página" en el parámetro
del curso "Paginación del curso"
★ Eliminar el bloque de actividades recientes
○ Fijar bloques por defecto al crear cursos
$CFG->defaultblocks_override = 'participants:calendar_month,activity_modules';
★ Deshabilitar todas las funcionalidades que no se usan.
22

23. Administrador de Moodle
★ Si es posible, desactivar "log legacy" (> Moodle 2.8).
★ Reducir número de cursos de página inicial.
★ Revisar Informe de rendimiento de Moodle:
23

24. Administrador de sistemas (1/3)
MUC
★ Optimizar configuración del MUC.
★ Mover datos a caché en memória (ej. memcache)
Memcached
★ Útil para datos de aplicación de la MUC
★ phpmemcachedadmin para controlar carga, hits…
★ Problema con el purgado. MDL-45375
Otras
★ Memcached, MongoDB…
★ De terceros: APC, XCache, WinCache
24
¿Qué sistema de
caché usáis?

25. Administrador de sistemas (2/3)
Opcache (opcode cache)
★ https://docs.moodle.org/29/en/OPcache
★ Integrado con PHP 5.5 (se puede instalar en versiones
anteriores).
★ opcache.php para consultar configuración, hits…
Disponible en GitHub
25

26. Administrador de sistemas (3/3)
★ Moodle QH: Performance comparison
○ Sesión de usuario (base de datos, fichero, memcached):
■ Si la sesión es persistente (por ejemplo a través de cookie) se puede
guardar en un directorio local en cada frontal.
■ Para instalaciones grandes hay que evitar tenerlas en NFS.
Recomendaciones de Moodle sobre rendimiento
26
¿Cómo controláis el
impacto de los
cambios en el
rendimiento?

27. Desarrollador
★ Consultar la guía de desarrollo de Moodle
★ En Depuración activar "DESARROLLADOR"
★ Optimizar las consultas a base de datos:
○ Reducirlas tanto como sea posible.
■ Evitar consultas en bucles (utilizar cláusula IN).
○ Revisar índices y usar join con campos indexados.
○ Usar recordsets para no cargarlo todo en memoria.
★ Code profiling
○ XDebug: MV en GitHub con Vagrant
○ XHProf
27

28. Pruebas automatizadas
★ Sistemas con Integración Contínua:
○ Jenkins
○ Travis CI
★ Test Unitarios:
○ PHPUnit
★ Test de aceptación:
○ Behat
28
¿Programáis los tests
unitarios y de
aceptación?
No os perdáis:
Desarrollo de plugins en entornos de integración continua
Manu Cagigas (Viernes 15:45)
Asistentes para ejecutar pruebas en Travis
github@moodlerooms/moodle-plugin-ci
github@jolicode/JoliCi

29. Pruebas de carga
★ Permiten detectar cuellos de botella y analizar
comportamiento de la arquitectura para optimizar la
configuración.
★ Con jmeter o similar. Fases:
○ Definición, diseño y preparación del plan de pruebas
■ Plan de pruebas simplificado
■ Decidir proporción de participación para cada rol
○ Ejecución del plan de pruebas
○ Análisis de resultados
★ Durante la ejecución, monitorizar también los servidores.
29
¿Hacéis pruebas
de carga? ¿Cómo?

30. Enlaces de interés
★ Tracker de Moodle
○ https://tracker.moodle.org
★ Fórum de soporte "Hardware&Performance"
○ https://moodle.org/mod/forum/view.php?id=596
★ How to improve your Moodle site performance (David
Monllaó)
○ http://www.slideshare.net/dmonllao/how-to-improve-your-
moodle-site-performance
★ MoodleDev
○ https://docs.moodle.org/dev/Main_Page
30

31. Sara Arjona Téllez
Pau Ferrer Ocaña
High Availability
& Clusters
@sara_arjona
@crazyserver
http://goo.
gl/yx9ZH7