Moodle es una plataforma muy popular para realizar cursos en línea. Con la situación que vemos en 2020, Moodle, junto con comunicadores como Zoom, forma la columna vertebral de los servicios que permiten el aprendizaje en línea y la educación desde casa. La demanda de plataformas Moodle aumentó significativamente en comparación con años anteriores. Se han construido nuevas plataformas, se ha puesto carga adicional en las plataformas que, históricamente, solo actuaban como una herramienta de ayuda y ahora están destinadas a impulsar todo el esfuerzo educativo. ¿Cómo escalar hacia fuera el Moodle? Tenemos un blog sobre este tema. ¿Cómo escalar el backend de la base de datos para Moodle? Bueno, esa es otra historia. Echémosle un vistazo, ya que escalar las bases de datos no es lo más fácil de hacer, especialmente si Moodle agrega su propio pequeño giro.
Como punto de entrada usaremos la arquitectura descrita en una de nuestras publicaciones anteriores. MariaDB Cluster con ProxySQL y Keepalived encima de todo.
Como puede ver, tenemos un clúster MariaDB de tres nodos con ProxySQL que divide las lecturas seguras del resto del tráfico en función del usuario.
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.222';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'moodle';
$CFG->dbpass = 'pass';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbport' => 6033,
'dbsocket' => '',
'dbcollation' => 'utf8mb4_general_ci',
'readonly' => [
'instance' => [
'dbhost' => '192.168.1.222',
'dbport' => 6033,
'dbuser' => 'moodle_safereads',
'dbpass' => 'pass'
]
]
);
$CFG->wwwroot = 'http://192.168.1.200/moodle';
$CFG->dataroot = '/var/www/moodledata';
$CFG->admin = 'admin';
$CFG->directorypermissions = 0777;
require_once(__DIR__ . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!Usuario, como se muestra arriba, se define en el archivo de configuración de Moodle. Esto nos permite enviar de forma automática y segura escrituras y todas las instrucciones SELECT que requieren consistencia de datos al nodo de escritura mientras aún enviamos algunas de las SELECT a los nodos restantes en MariaDB Cluster.
Supongamos que esta configuración particular no es suficiente para nosotros. ¿Cuáles son las opciones que tenemos? Tenemos dos elementos principales en la configuración:MariaDB Cluster y ProxySQL. Consideraremos los problemas de ambos lados:
- ¿Qué se puede hacer si la instancia de ProxySQL no puede hacer frente al tráfico?
- ¿Qué se puede hacer si MariaDB Cluster no puede hacer frente al tráfico?
Comencemos con el primer escenario.
La instancia de ProxySQL está sobrecargada
En el entorno actual, solo una instancia de ProxySQL puede manejar el tráfico:aquella a la que apunta la IP virtual. Esto nos deja con una instancia de ProxySQL que actúa como un recurso de reserva, en funcionamiento, pero que no se usa para nada. Si la instancia de ProxySQL activa se está acercando a la saturación de la CPU, hay un par de cosas que quizás desee hacer. Primero, obviamente, puede escalar verticalmente:aumentar el tamaño de una instancia de ProxySQL podría ser la forma más fácil de permitir que maneje un mayor tráfico. Tenga en cuenta que ProxySQL, de forma predeterminada, está configurado para usar 4 subprocesos.
Si desea poder utilizar más núcleos de CPU, este es el configuración que también debe cambiar.
Como alternativa, puede intentar escalar horizontalmente. En lugar de usar dos instancias de ProxySQL con VIP, puede colocar ProxySQL con hosts de Moodle. Luego, desea reconfigurar Moodle para conectarse a ProxySQL en el host local, idealmente a través del socket de Unix:es la forma más eficiente de conectarse a ProxySQL. No hay mucha configuración que usemos con ProxySQL, por lo tanto, el uso de varias instancias de ProxySQL no debería agregar demasiada sobrecarga. Si lo desea, siempre puede configurar ProxySQL Cluster para ayudarlo a mantener las instancias de ProxySQL sincronizadas con respecto a la configuración.
El clúster MariaDB está sobrecargado
Ahora estamos hablando de un problema más serio. Por supuesto, aumentar el tamaño de las instancias ayudará, como de costumbre. Por otro lado, el escalado horizontal está algo limitado debido a la limitación de "lecturas seguras". Claro, puede agregar más nodos al clúster, pero puede usarlos solo para las lecturas seguras. Hasta qué punto esto le permite escalar horizontalmente, depende de la carga de trabajo. Para una carga de trabajo pura de solo lectura (navegar por los contenidos, foros, etc.) se ve bastante bien:
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 5683 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 5543 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 553 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.002 sec)Esta es prácticamente una proporción de 1:20:para una consulta que llega al escritor, tenemos 20 "lecturas seguras" que se pueden distribuir entre los nodos restantes. Por otro lado, cuando empezamos a modificar los datos, el ratio cambia rápidamente.
MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';
+-----------+---------------+----------+--------+---------+
| hostgroup | srv_host | srv_port | status | Queries |
+-----------+---------------+----------+--------+---------+
| 20 | 192.168.1.204 | 3306 | ONLINE | 3117 |
| 20 | 192.168.1.205 | 3306 | ONLINE | 3010 |
| 10 | 192.168.1.206 | 3306 | ONLINE | 6807 |
+-----------+---------------+----------+--------+---------+
3 rows in set (0.003 sec)Este es un resultado después de emitir varias calificaciones, crear temas de foro y agregar algún contenido del curso. Como puede ver, con tal proporción de consultas seguras/no seguras, el escritor se saturará antes que los lectores, por lo que no es adecuado escalar agregando más nodos.
¿Qué se puede hacer al respecto? Hay una configuración llamada "latencia". Según el archivo de configuración, determina cuándo es seguro leer la tabla después de la escritura. Cuando ocurre la escritura, la tabla se marca como modificada y durante el tiempo de "latencia" todos los SELECT se enviarán al nodo de escritura. Una vez que pasó el tiempo más largo que la "latencia", los SELECT de esa tabla pueden enviarse nuevamente a los nodos de lectura. Tenga en cuenta que con MariaDB Cluster, el tiempo requerido para que se aplique el conjunto de escritura en todos los nodos suele ser muy bajo, contado en milisegundos. Esto nos permitiría establecer una latencia bastante baja en el archivo de configuración de Moodle, por ejemplo, un valor como 0,1 s (100 milisegundos) debería estar bastante bien. Por supuesto, si tiene algún problema, siempre puede aumentar este valor aún más.
Otra opción para probar sería confiar únicamente en MariaDB Cluster para saber cuándo la lectura es segura y cuándo no. Hay una variable wsrep_sync_wait que se puede configurar para forzar verificaciones de causalidad en varios patrones de acceso (lecturas, actualizaciones, inserciones, eliminaciones, reemplazos y comandos MOSTRAR). Para nuestro propósito, sería suficiente garantizar que las lecturas se ejecuten con la causalidad impuesta, por lo que estableceremos esta variable en '1'.
Haremos este cambio en todos los nodos del clúster de MariaDB. También necesitaremos reconfigurar ProxySQL para la división de lectura/escritura en función de las reglas de consulta, no solo de los usuarios, como lo hicimos anteriormente. También eliminaremos el usuario 'moodle_safereads' ya que ya no es necesario en esta configuración.
Configuramos tres reglas de consulta que distribuyen el tráfico según la consulta. SELECCIONAR... PARA ACTUALIZAR se envía al nodo escritor, todas las consultas SELECT se envían a los lectores y todo lo demás (INSERTAR, ELIMINAR, REEMPLAZAR, ACTUALIZAR, COMENZAR, COMPROMETER, etc.) también se envía al nodo escritor.
Esto nos permite asegurarnos de que todas las lecturas se puedan distribuir entre los nodos lectores, lo que permite escalar horizontalmente mediante la adición de más nodos al clúster de MariaDB.
Esperamos que con estos dos consejos pueda escalar el backend de su base de datos de Moodle mucho más fácilmente y en mayor medida
