Las reuniones presenciales, hoy en día, se limitan al mínimo indispensable, las actividades en línea se han convertido en la principal vía de interacción docente - alumno. Aumentó el estrés en las plataformas de "reuniones" en línea existentes (¿hay alguien que no sepa qué es Zoom hoy en día?), pero también en las plataformas de aprendizaje en línea. La alta disponibilidad de las herramientas en línea es más importante que nunca y los equipos de operaciones se apresuran a crear arquitecturas duraderas y de alta disponibilidad para sus entornos.
Lo más probable es que al menos algunos de ustedes hayan usado Moodle:es una plataforma de aprendizaje en línea independiente que puede implementar en las instalaciones y usarla para brindar capacitación en línea para su organización. Como mencionamos, es más importante que nunca hacer que funcione de manera duradera y altamente disponible. Nos gustaría proponer una solución de alta disponibilidad que involucre a MariaDB como una base de datos back-end, tanto replicación asíncrona como Galera Cluster.
Proceso de diseño del entorno
Nos gustaría comenzar con un proceso en el que explicaríamos el proceso de pensamiento detrás del diseño del entorno para Moodle. Queremos alta disponibilidad, por lo tanto, un solo nodo de base de datos no funciona para nosotros. Queremos múltiples nodos y esto nos lleva a la primera decisión de diseño. ¿Deberíamos usar replicación asincrónica o Galera Cluster? La segunda pregunta es:¿cómo distribuiremos la carga de trabajo entre los nodos? Comencemos con el segundo.
La última versión de Moodle en el momento en que se escribió este blog (3.9) introdujo una característica agradable llamada lecturas seguras. El problema a resolver aquí es leer después de escribir. Cuando usas un nodo, el mundo es un lugar simple. Escribes y luego lees. Todo lo que escribiste ya está ahí. Sin embargo, cuando agrega nodos, las cosas cambian. En la replicación asíncrona, los esclavos pueden retrasarse incluso decenas de segundos o más. Cualquier cosa que escriba en el maestro puede tardar incluso minutos (si no más en los casos más extremos) en aplicarse al esclavo. Si ejecuta una escritura e inmediatamente intenta leer los mismos datos de uno de los esclavos, puede llevarse una desagradable sorpresa:los datos no estarán allí. El clúster de Galera utiliza una replicación sincrónica "virtualmente" y, en este caso particular, "virtualmente" marca una gran diferencia:Galera no es inmune a los problemas de lectura después de escritura. Siempre hay una demora entre la ejecución de la escritura en el nodo local y la aplicación del conjunto de escritura a los nodos restantes del clúster. Claro, lo más probable es que se mida en milisegundos en lugar de segundos, pero aún puede romper la suposición de que puede leer inmediatamente lo que escribió. El único lugar donde puede leer con seguridad después de escribir es el nodo en el que escribió los datos.
Como Moodle se basa bastante en la lectura después de la escritura, no podemos escalar fácilmente las lecturas solo agregando más nodos para leer. Para Galera Cluster, podríamos intentar mitigar el problema mediante el uso de la opción de configuración wsrep-sync-wait para forzar a Galera a garantizar que las lecturas sean seguras para ejecutar. Esto crea un impacto en el rendimiento del sistema, ya que todas las lecturas tienen que esperar a que se apliquen las escrituras antes de poder ejecutarlas. Esta también es una solución para MariaDB Cluster (y otras soluciones basadas en Galera), no para la replicación asincrónica. Afortunadamente, la solución de Moodle resuelve este problema. Puede definir una lista de nodos que posiblemente estén retrasados y Moodle los usará solo para lecturas que no requieran estar al día con las escrituras. Todas las lecturas restantes que requieren que los datos estén siempre actualizados se dirigirán al nodo de escritura. Por lo tanto, la escalabilidad de Moodle es algo limitada, ya que solo las lecturas "seguras" se pueden escalar horizontalmente. Definitivamente querremos usar la función 3.9 dado que este es el único método seguro para determinar qué selección debe ir a dónde. Dado que todo está escrito en un archivo de configuración de Moodle, lo más probable es que queramos usar un balanceador de carga, preferiblemente ProxySQL, para crear una lógica que maneje nuestra distribución de lectura.
¿Deberíamos usar MariaDB Cluster o replicación asíncrona? De hecho, le mostraremos cómo usar ambos. En ambos casos, la configuración de Moodle será prácticamente la misma. En ambos casos, utilizaremos ProxySQL como equilibrador de carga. La principal diferencia entre esas soluciones es la conmutación por error. MariaDB Cluster es mucho más fácil de manejar:si un nodo está inactivo, ProxySQL simplemente moverá el tráfico de escritura a uno de los nodos restantes. Sin embargo, con la replicación asincrónica las cosas son ligeramente diferentes. Si el maestro deja de funcionar, tiene que ocurrir una conmutación por error. Esto no sucede automáticamente, debe hacerlo a mano o puede confiar en algún software para lograrlo. En nuestro caso, usaremos ClusterControl para administrar el entorno y realizar la conmutación por error; por lo tanto, desde el punto de vista del usuario, no hay mucha diferencia entre la replicación asíncrona y el clúster de MariaDB; en ambos casos, la falla del escritor se manejará automáticamente y el clúster se recuperará automáticamente. .
Lo que hemos establecido es que mostraremos tanto la replicación asincrónica como la virtualmente sincrónica. Usaremos la función de escritura segura de Moodle 3.9 y usaremos ProxySQL como balanceador de carga. Para garantizar una alta disponibilidad, necesitaremos más de una instancia de ProxySQL, por lo tanto, elegiremos dos de ellas y, para crear un único punto de entrada en la capa de la base de datos, usaremos Keepalived para crear una IP virtual y apuntarla a uno de los ProxySQL disponibles. nodos. Así es como puede verse nuestro clúster de base de datos:
Para la replicación asíncrona, esto podría verse así:
Implementación de un backend de base de datos de alta disponibilidad para Moodle mediante la replicación de MariaDB
Comencemos con la replicación de MariaDB. Vamos a usar ClusterControl para implementar todo el backend de la base de datos, incluidos los balanceadores de carga.
Implementación del clúster de replicación de MariaDB
Al principio, debemos elegir "Implementar" en el asistente:
Entonces debemos definir la conectividad SSH, el acceso SSH basado en clave y sin contraseña es un requisito para que ClusterControl gestione la infraestructura de la base de datos.
Cuando complete esos detalles, es hora de elegir un proveedor y una versión , defina la contraseña de superusuario y decida algunos otros detalles.
Vamos a utilizar MariaDB 10.4 por ahora. Como siguiente paso tenemos que definir la topología de replicación:
Deberíamos pasar los nombres de host de los nodos y cómo deben relacionarse entre sí. otro. Una vez que estemos satisfechos con la topología, podemos implementar. A los efectos de este blog, utilizaremos el maestro y dos esclavos como backend.
Tenemos nuestro primer clúster listo. Ahora, implementemos ProxySQL y Keepalived.
Implementación de ProxySQL
Para ProxySQL es necesario completar algunos detalles:elija el host para instalar Enciéndalo, decida la versión de ProxySQL, las credenciales para los usuarios administrativos y de supervisión. También debe importar usuarios de bases de datos existentes o crear uno nuevo para su aplicación. Finalmente, decida qué nodos de base de datos desea usar con ProxySQL y decida si usa transacciones implícitas. En el caso de Moodle esto no es cierto.
Implementación de Keepalived
Como siguiente paso implementaremos Keepalived.
Después de pasar detalles como las instancias de ProxySQL que deben monitorearse, la IP virtual y el La interfaz VIP debe vincularse a Estamos listos para implementar. Después de un par de minutos, todo debería estar listo y la topología debería tener el siguiente aspecto:
Configurar Moodle y ProxySQL para la escalabilidad horizontal de escrituras seguras
El paso final será configurar Moodle y ProxySQL para usar escrituras seguras. Si bien es posible codificar los nodos de la base de datos en la configuración de Moodle, sería mucho mejor confiar en ProxySQL para manejar los cambios de topología. Lo que podemos hacer es crear un usuario adicional en la base de datos. Ese usuario estará configurado en Moodle para ejecutar lecturas seguras. ProxySQL se configurará para enviar todo el tráfico ejecutado desde ese usuario a los nodos esclavos disponibles.
Primero, creemos un usuario que usaremos para acceso de solo lectura.
Otorgamos todos los privilegios aquí, pero debería ser posible limitar esa lista .
El usuario que acabamos de crear debe agregarse a las dos instancias de ProxySQL que tenemos en el clúster para permitir que ProxySQL se autentique como ese usuario. En la interfaz de usuario de ClusterControl, puede utilizar la acción "Importar usuario".
Podemos buscar el usuario que acabamos de crear:
ProxySQL utiliza un concepto de grupos de hosts:grupos de hosts que tienen el mismo propósito . En nuestra configuración predeterminada, hay dos grupos de host:el grupo de host 10 que siempre apunta al maestro actual y el grupo de host 20 que apunta a los nodos esclavos. Queremos que este usuario envíe el tráfico a los nodos esclavos, por lo tanto, asignaremos HG 20 como predeterminado.
Eso es todo, el usuario aparecerá en la lista de usuarios:
Ahora debemos repetir el mismo proceso en el otro nodo ProxySQL o usar el Opción "Sincronizar instancias". De una forma u otra, ambos nodos ProxySQL deben tener agregado el usuario moodle_safereads.
El último paso será implementar Moodle. No repasaremos aquí todo el proceso, pero hay un problema que debemos abordar. ProxySQL se presenta como 5.5.30 y Moodle se queja de que es demasiado antiguo. Podemos editarlo fácilmente a la versión que queramos:
Una vez hecho esto, tenemos que enviar temporalmente todo el tráfico a el maestro. Esto se puede lograr eliminando todas las reglas de consulta en ProxySQL. El usuario de 'moodle' tiene HG10 como el grupo de host predeterminado, lo que significa que sin reglas de consulta, todo el tráfico de ese usuario se dirigirá al maestro. El segundo, lecturas seguras, el usuario tiene el grupo de host predeterminado 20, que es prácticamente toda la configuración que queremos tener en su lugar.
Una vez hecho esto, debemos editar el archivo de configuración de Moodle y habilitar la caja fuerte característica de lectura:
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = '192.168.1.111';
$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.111',
'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!Lo que sucedió aquí es que agregamos la conexión de solo lectura a ProxySQL que usará el usuario moodle_safereads. Este usuario siempre apuntará hacia los esclavos. Esto concluye nuestra configuración de Moodle para la replicación de MariaDB.
Implementación de un back-end de base de datos de alta disponibilidad para Moodle mediante MariaDB Cluster
Esta vez intentaremos usar MariaDB Cluster como nuestro backend. Una vez más, el primer paso es el mismo, debemos elegir "Implementar" en el asistente:
Una vez que haga eso, debemos definir la conectividad SSH, sin contraseña, clave- El acceso SSH basado es un requisito para que ClusterControl administre la infraestructura de la base de datos.
Luego debemos decidir sobre el proveedor, la versión, la contraseña de los hosts y un par más configuración:
Una vez que completamos todos los detalles, estamos listos para implementar.
Podríamos continuar aquí más, pero dado que todos los pasos adicionales son básicamente los mismos que con la replicación de MariaDB, solo le pediríamos que se desplace hacia arriba y verifique la sección "Implementación de ProxySQL" y todo lo que sigue. Tienes que implementar ProxySQL, Keepalived, reconfigurarlo, cambiar el archivo de configuración de Moodle y eso es todo. Esperamos que este blog lo ayude a crear entornos de alta disponibilidad para Moodle respaldados por MariaDB Cluster o replicación.
