Gli incontri faccia a faccia, al giorno d'oggi, sono limitati al minimo indispensabile, le attività online sono diventate il modo principale per l'interazione insegnante-studente. Ha aumentato lo stress sulle piattaforme di "riunione" online esistenti (c'è qualcuno che non sa cosa sia Zoom al giorno d'oggi?) ma anche sulle piattaforme di apprendimento online. L'elevata disponibilità degli strumenti online è più importante che mai ei team operativi si affrettano a creare architetture durevoli e ad alta disponibilità per i loro ambienti.
Molto probabilmente almeno alcuni di voi hanno utilizzato Moodle:è una piattaforma di apprendimento online autonoma che è possibile implementare in locale e utilizzarla per fornire formazione online per la propria organizzazione. Come accennato, è importante come sempre farlo funzionare in modo durevole e altamente disponibile. Vorremmo proporre una soluzione ad alta disponibilità che coinvolga MariaDB come database back-end, sia replica asincrona che Galera Cluster.
Processo di progettazione ambientale
Vorremmo iniziare con un processo in cui spiegheremmo il processo di pensiero alla base della progettazione dell'ambiente per Moodle. Vogliamo un'elevata disponibilità, quindi un singolo nodo di database non funziona per noi. Vogliamo più nodi e questo ci porta alla prima decisione progettuale. Dovremmo usare la replica asincrona o il Galera Cluster? La seconda domanda è:come distribuiremo il carico di lavoro tra i nodi? Cominciamo con il secondo.
L'ultima versione di Moodle al momento della stesura di questo blog (3.9) ha introdotto una simpatica funzionalità chiamata letture sicure. Il problema da risolvere qui si legge dopo la scrittura. Quando usi un nodo, il mondo è un posto semplice. Scrivi e poi leggi. Qualunque cosa tu abbia scritto c'è già. Quando aggiungi nodi, però, le cose cambiano. Nella replica asincrona gli slave possono essere in ritardo anche di decine di secondi o più. Qualunque cosa tu scriva sul master potrebbe volerci anche minuti (se non di più nei casi più estremi) per essere applicata allo slave. Se esegui una scrittura e poi tenti immediatamente di leggere gli stessi dati da uno degli slave, potresti avere una brutta sorpresa:i dati non saranno lì. Il cluster Galera utilizza una replica sincrona "virtualmente" e in questo caso particolare "virtualmente" fa un'enorme differenza:Galera non è immune dai problemi di lettura dopo scrittura. C'è sempre un ritardo tra l'esecuzione della scrittura sul nodo locale e il writeset applicato ai nodi rimanenti del cluster. Certo, è molto probabilmente misurato in millisecondi anziché in secondi, ma potrebbe comunque rompere l'ipotesi che tu possa leggere immediatamente ciò che hai scritto. L'unico posto in cui puoi leggere in sicurezza dopo aver scritto è il nodo su cui hai scritto i dati.
Poiché Moodle si basa molto sul read-after-write, non possiamo facilmente ridimensionare le letture solo aggiungendo più nodi da cui leggere. Per Galera Cluster potremmo tentare di mitigare il problema utilizzando l'impostazione di configurazione wsrep-sync-wait per forzare Galera a garantire che le letture siano sicure da eseguire. Ciò crea un impatto sulle prestazioni sul sistema poiché tutte le letture devono attendere l'applicazione delle scritture prima di poter essere eseguite. Questa è anche una soluzione per MariaDB Cluster (e altre soluzioni basate su Galera), non per la replica asincrona. Fortunatamente, la soluzione di Moodle risolve questo problema. Puoi definire un elenco di nodi che potrebbero essere in ritardo e Moodle li utilizzerà solo per letture che non richiedono l'aggiornamento delle scritture. Tutte le letture rimanenti che richiedono che i dati siano sempre aggiornati verrebbero indirizzate al nodo di scrittura. Quindi, la scalabilità di Moodle è in qualche modo limitata poiché solo le letture "sicure" possono essere ridimensionate. Sicuramente vorremo usare la funzione di 3.9 dato che questo è l'unico metodo sicuro per determinare quale selezione dovrebbe andare dove. Dato che tutto è scritto in un file di configurazione di Moodle, molto probabilmente vorremmo utilizzare un bilanciamento del carico, preferibilmente ProxySQL, per creare una logica che gestirebbe la nostra distribuzione di lettura.
Dovremmo usare MariaDB Cluster o la replica asincrona? Ti mostreremo effettivamente come utilizzare entrambi. In entrambi i casi la configurazione per Moodle sarà praticamente la stessa. In entrambi i casi utilizzeremo ProxySQL come loadbalancer. La principale differenza tra queste soluzioni è il failover. Il cluster MariaDB è molto più semplice da gestire:se un nodo è inattivo, ProxySQL sposterà semplicemente il traffico di scrittura su uno dei nodi rimanenti. Tuttavia, con la replica asincrona le cose sono leggermente diverse. Se il master si interrompe, deve verificarsi il failover. Ciò non accade automaticamente, devi eseguirlo a mano o puoi fare affidamento su alcuni software per farlo. Nel nostro caso utilizzeremo ClusterControl per gestire l'ambiente ed eseguire il failover quindi, dal punto di vista dell'utente, non c'è molta differenza tra la replica asincrona e il cluster MariaDB:in entrambi i casi l'errore del writer verrà gestito automaticamente e il cluster verrà ripristinato automaticamente .
Quello che abbiamo stabilito è che presenteremo sia la replica asincrona che virtualmente sincrona. Useremo la funzione di scrittura sicura di Moodle 3.9 e useremo ProxySQL come loadbalancer. Per garantire un'elevata disponibilità avremo bisogno di più di un'istanza ProxySQL quindi ne andremo con due e per creare un unico punto di ingresso nel livello del database utilizzeremo Keepalived per creare un IP virtuale e puntarlo a uno dei ProxySQL disponibili nodi. Ecco come potrebbe apparire il nostro cluster di database:
Per la replica asincrona potrebbe assomigliare a questo:
Distribuzione di un backend di database altamente disponibile per Moodle utilizzando la replica di MariaDB
Iniziamo con la replica di MariaDB. Utilizzeremo ClusterControl per distribuire l'intero back-end del database, inclusi i bilanciatori di carico.
Distribuzione del cluster di replica MariaDB
In primo luogo, dobbiamo selezionare "Distribuisci" dalla procedura guidata:
Quindi dovremmo definire la connettività SSH, l'accesso SSH senza password e basato su chiavi è un requisito per ClusterControl per gestire l'infrastruttura del database.
Quando inserisci questi dettagli, è il momento di scegliere un fornitore e una versione , definisci la password del superutente e decidi altri dettagli.
Per ora utilizzeremo MariaDB 10.4. Come passaggio successivo dobbiamo definire la topologia di replica:
Dovremmo passare i nomi host dei nodi e come dovrebbero relazionarsi a ciascuno Altro. Una volta che siamo soddisfatti della topologia, possiamo eseguire il deployment. Ai fini di questo blog utilizzeremo master e due slave come backend.
Abbiamo il nostro primo cluster pronto e pronto. Ora distribuiamo ProxySQL e Keepalived.
Distribuzione di ProxySQL
Per ProxySQL è necessario inserire alcuni dettagli:selezionare l'host da installare acceso, decidere la versione ProxySQL, le credenziali per gli utenti amministrativi e di monitoraggio. Dovresti anche importare gli utenti del database esistenti o crearne uno nuovo per la tua applicazione. Infine, decidi quali nodi di database desideri utilizzare con ProxySQL e decidi se utilizzare transazioni implicite. Nel caso di Moodle questo non è vero.
Distribuzione di Keepalived
Come passaggio successivo implementeremo Keepalived.
Dopo aver passato dettagli come istanze ProxySQL da monitorare, IP virtuale e l'interfaccia VIP dovrebbe legarsi a noi siamo pronti per la distribuzione. Dopo un paio di minuti tutto dovrebbe essere pronto e la topologia dovrebbe apparire come di seguito:
Configura Moodle e ProxySQL per la scalabilità orizzontale delle scritture sicure
Il passaggio finale sarà configurare Moodle e ProxySQL per utilizzare scritture sicure. Sebbene sia possibile codificare i nodi del database nella configurazione di Moodle, sarebbe molto meglio affidarsi a ProxySQL per gestire le modifiche alla topologia. Quello che possiamo fare è creare un utente aggiuntivo nel database. Quell'utente sarà configurato in Moodle per eseguire letture sicure. ProxySQL sarà configurato per inviare tutto il traffico eseguito da quell'utente ai nodi slave disponibili.
Per prima cosa, creiamo un utente che utilizzeremo per l'accesso in sola lettura.
Stiamo concedendo tutti i privilegi qui, ma dovrebbe essere possibile limitare tale elenco .
L'utente che abbiamo appena creato deve essere aggiunto a entrambe le istanze ProxySQL che abbiamo nel cluster per consentire a ProxySQL di autenticarsi come tale utente. Nell'interfaccia utente di ClusterControl è possibile utilizzare l'azione "Importa utente".
Possiamo cercare l'utente che abbiamo appena creato:
ProxySQL utilizza un concetto di hostgroup - gruppi di host che hanno lo stesso scopo . Nella nostra configurazione predefinita ci sono due hostgroup:hostgroup 10 che punta sempre al master corrente e hostgroup 20 che punta ai nodi slave. Vogliamo che questo utente invii il traffico ai nodi slave, quindi assegneremo HG 20 come predefinito.
Ecco fatto, l'utente verrà mostrato nell'elenco degli utenti:
Ora dovremmo ripetere la stessa procedura sull'altro nodo ProxySQL o utilizzare il Opzione "Sincronizza istanze". In un modo o nell'altro, entrambi i nodi ProxySQL dovrebbero avere l'utente moodle_safereads aggiunto.
L'ultimo passaggio sarà distribuire Moodle. Non andremo qui attraverso l'intero processo, ma c'è un problema che dobbiamo affrontare. ProxySQL si presenta come 5.5.30 e Moodle si lamenta che è troppo vecchio. Possiamo modificarlo facilmente in qualsiasi versione desideriamo:
Una volta fatto, dobbiamo inviare temporaneamente tutto il traffico a Il capo. Questo può essere ottenuto eliminando tutte le regole di query in ProxySQL. L'utente "moodle" ha HG10 come gruppo host predefinito, il che significa che senza regole di query tutto il traffico da quell'utente verrà indirizzato al master. Il secondo utente, per la lettura sicura, ha il gruppo host predefinito 20 che è praticamente tutta la configurazione che vogliamo avere in atto.
Una volta fatto, dovremmo modificare il file di configurazione di Moodle e abilitare la cassaforte legge la funzione:
<?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!Quello che è successo qui è che abbiamo aggiunto la connessione di sola lettura a ProxySQL che utilizzerà l'utente moodle_safereads. Questo utente punterà sempre verso gli slave. Questo conclude la nostra configurazione di Moodle per la replica di MariaDB.
Distribuzione di un backend di database altamente disponibile per Moodle utilizzando il cluster MariaDB
Questa volta proveremo a utilizzare MariaDB Cluster come backend. Anche in questo caso, il primo passaggio è lo stesso, dobbiamo selezionare "Distribuisci" dalla procedura guidata:
Una volta fatto, dovremmo definire la connettività SSH, senza password, chiave- l'accesso SSH basato è un requisito per ClusterControl per gestire l'infrastruttura del database.
Quindi dovremmo decidere il fornitore, la versione, gli host delle password e un paio di altri impostazioni:
Una volta inseriti tutti i dettagli, siamo a posto.
Potremmo continuare qui oltre, ma dato che tutti i passaggi successivi sono sostanzialmente gli stessi della replica di MariaDB, ti chiediamo semplicemente di scorrere verso l'alto e controllare la sezione "Distribuzione di ProxySQL" e tutto ciò che segue. Devi distribuire ProxySQL, Keepalived, riconfigurarlo, cambiare il file di configurazione di Moodle e questo è praticamente tutto. Ci auguriamo che questo blog ti aiuti a creare ambienti ad alta disponibilità per Moodle supportati da MariaDB Cluster o replica.
