Moodle è una piattaforma molto popolare per eseguire corsi online. Con la situazione che vediamo nel 2020, Moodle, insieme a comunicatori come Zoom, costituisce la spina dorsale dei servizi che consentono l'apprendimento online e l'istruzione casalinga. La domanda posta sulle piattaforme Moodle è notevolmente aumentata rispetto agli anni precedenti. Sono state costruite nuove piattaforme, è stato messo un carico aggiuntivo sulle piattaforme che, storicamente, fungevano solo da strumento di supporto e ora sono destinate a guidare l'intero sforzo educativo. Come ridimensionare Moodle? Abbiamo un blog su questo argomento. Come ridimensionare il back-end del database per Moodle? Bene, questa è un'altra storia. Diamo un'occhiata perché il ridimensionamento dei database non è la cosa più semplice da fare, soprattutto se Moodle aggiunge la sua piccola svolta.
Come punto di ingresso utilizzeremo l'architettura descritta in uno dei nostri post precedenti. Cluster MariaDB con ProxySQL e Keepalived in cima alle cose.
Come puoi vedere, abbiamo un cluster MariaDB a tre nodi con ProxySQL che divide le letture sicure dal resto del traffico in base all'utente.
<?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!L'utente, come mostrato sopra, è definito nel file di configurazione di Moodle. Questo ci consente di inviare automaticamente e in modo sicuro le scritture e tutte le istruzioni SELECT che richiedono la coerenza dei dati al nodo di scrittura mentre si inviano comunque alcune delle SELECT ai nodi rimanenti nel cluster MariaDB.
Supponiamo che questa particolare configurazione non sia sufficiente per noi. Quali sono le opzioni che abbiamo? Abbiamo due elementi principali nella configurazione:MariaDB Cluster e ProxySQL. Prenderemo in considerazione i problemi da entrambe le parti:
- Cosa si può fare se l'istanza ProxySQL non è in grado di gestire il traffico?
- Cosa si può fare se MariaDB Cluster non è in grado di far fronte al traffico?
Cominciamo con il primo scenario.
L'istanza proxySQL è sovraccaricata
Nell'ambiente corrente solo un'istanza ProxySQL può gestire il traffico, quella a cui punta l'IP virtuale. Questo ci lascia con un'istanza ProxySQL che funge da standby:attiva e funzionante ma non utilizzata per nulla. Se l'istanza ProxySQL attiva si sta avvicinando alla saturazione della CPU, ci sono un paio di cose che potresti voler fare. Innanzitutto, ovviamente, puoi ridimensionare verticalmente:aumentare le dimensioni di un'istanza ProxySQL potrebbe essere il modo più semplice per consentirle di gestire un traffico più elevato. Tieni presente che ProxySQL, per impostazione predefinita, è configurato per utilizzare 4 thread.
Se vuoi essere in grado di utilizzare più core della CPU, questo è il impostazione che devi modificare anche tu.
In alternativa, puoi provare a ridimensionare orizzontalmente. Invece di utilizzare due istanze ProxySQL con VIP, puoi collocare ProxySQL con host Moodle. Quindi vuoi riconfigurare Moodle per connettersi a ProxySQL sull'host locale, idealmente tramite il socket Unix:è il modo più efficiente per connettersi a ProxySQL. Non c'è molta configurazione che usiamo con ProxySQL, quindi l'uso di più istanze di ProxySQL non dovrebbe aggiungere troppo sovraccarico. Se lo desideri, puoi sempre configurare ProxySQL Cluster per aiutarti a mantenere sincronizzate le istanze ProxySQL per quanto riguarda la configurazione.
Il cluster MariaDB è sovraccarico
Ora stiamo parlando di un problema più serio. Ovviamente, aumentare la dimensione delle istanze aiuterà, come al solito. D'altra parte, la scalabilità orizzontale è alquanto limitata a causa della limitazione delle "letture sicure". Certo, puoi aggiungere più nodi al cluster ma puoi usarli solo per le letture sicure. In che misura ciò ti consente di aumentare la scalabilità, dipende dal carico di lavoro. Per puro carico di lavoro di sola lettura (sfogliare i contenuti, i forum, ecc.) sembra abbastanza carino:
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)Questo è più o meno un rapporto di 1:20 - per una query che colpisce lo scrittore abbiamo 20 "letture sicure" che possono essere distribuite sui nodi rimanenti. Quando invece iniziamo a modificare i dati, il rapporto cambia rapidamente.
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)Questo è un output dopo aver assegnato diversi voti, creato argomenti del forum e aggiunto alcuni contenuti del corso. Come puoi vedere, con un tale rapporto di query sicure/non sicure, lo scrittore verrà saturato prima dei lettori, quindi non è adatto lo scale-out aggiungendo più nodi.
Cosa si può fare al riguardo? C'è un'impostazione chiamata "latenza". Secondo il file di configurazione, determina quando è sicuro leggere la tabella dopo la scrittura. Quando avviene la scrittura, la tabella viene contrassegnata come modificata e per il tempo di "latenza" tutte le SELECT verranno inviate al nodo di scrittura. Una volta trascorso il tempo più lungo di "latenza", i SELECT da quella tabella possono essere nuovamente inviati ai nodi di lettura. Tieni presente che con MariaDB Cluster, il tempo necessario per l'applicazione del writeset su tutti i nodi è in genere molto basso, conteggiato in millisecondi. Questo ci permetterebbe di impostare la latenza abbastanza bassa nel file di configurazione di Moodle, ad esempio il valore come 0.1s (100 millisecondi) dovrebbe essere abbastanza ok. Ovviamente, in caso di problemi, puoi sempre aumentare ulteriormente questo valore.
Un'altra opzione da testare sarebbe affidarsi esclusivamente a MariaDB Cluster per dire quando la lettura è sicura e quando non lo è. Esiste una variabile wsrep_sync_wait che può essere configurata per forzare i controlli di causalità su diversi modelli di accesso (lettura, aggiornamento, inserimento, eliminazione, sostituzione e comandi SHOW). Per il nostro scopo sarebbe sufficiente garantire che le letture vengano eseguite con la causalità imposta, quindi imposteremo questa variabile a "1".
Apporteremo questa modifica su tutti i nodi MariaDB Cluster. Avremo anche bisogno di riconfigurare ProxySQL per la suddivisione in lettura/scrittura in base alle regole di query, non solo agli utenti, come in precedenza. Rimuoveremo anche l'utente "moodle_safereads" poiché non è più necessario in questa configurazione.
Impostiamo tre regole di query che distribuiscono il traffico in base alla query. SELECT … FOR UPDATE viene inviato al nodo writer, tutte le query SELECT vengono inviate ai lettori e tutto il resto (INSERT, DELETE, REPLACE, UPDATE, BEGIN, COMMIT e così via) viene inviato anche al nodo writer.
Questo ci consente di garantire che tutte le letture possano essere distribuite tra i nodi di lettura consentendo così la scalabilità orizzontale attraverso l'aggiunta di più nodi al cluster MariaDB.
Ci auguriamo che con questi due suggerimenti sarai in grado di ampliare il backend del tuo database Moodle molto più facilmente e in misura maggiore
