Open edX è una piattaforma per attività educative online. Data la situazione in cui si trova il mondo, tutte queste piattaforme stanno incontrando carichi più elevati e la loro importanza è notevolmente aumentata. Queste non sono solo le piattaforme di “helper”, ma spesso diventano il modo principale in cui vengono svolte le attività educative. Ciò porta a requisiti più elevati per quanto riguarda il carico che possono gestire o la disponibilità della piattaforma.
Open edX è un prodotto complesso composto da più elementi. Uno di questi è il database MySQL. In questo breve blog vorremmo discutere di come migliorare l'elevata disponibilità della piattaforma Open edX.
Ovviamente, il singolo database MySQL è un singolo punto di errore e, come tale, non è un approccio adatto alle implementazioni di produzione. Esistono diversi modi per migliorare la disponibilità del database MySQL.
Per cominciare, puoi eseguire la configurazione master - slave utilizzando la replica asincrona o semi-sincrona. Il vantaggio è che, quando il master non è disponibile, puoi promuovere uno degli slave e procedere con l'operazione. Lo svantaggio principale di tale configurazione è che il failover deve essere eseguito manualmente, il che aumenta i tempi di inattività o è necessario utilizzare un software esterno (ad esempio ClusterControl), ma anche in questo caso potrebbe richiedere un po' di tempo. Infine, qualsiasi tipo di replica asincrona o semisincrona è soggetta a ritardo di replica. Ciò può influire seriamente sugli scenari di lettura dopo scrittura in cui l'applicazione esegue una scrittura sul master e quindi tenta immediatamente di leggere i dati dallo slave.
Un altro approccio sarebbe utilizzare un cluster Galera per archiviare i dati dalla piattaforma Open edX. Possiamo iniziare con tre cluster di nodi:tali cluster possono gestire automaticamente l'errore di un singolo nodo. I restanti due nodi continueranno a funzionare e risponderanno alle query provenienti dall'applicazione. Un altro vantaggio di Galera è che, anche se è "virtualmente" sincrono (il che significa praticamente che è quasi sincrono), c'è un modo per imporre controlli di causalità e forzare i cluster nella modalità sincrona (anche se si paga con prestazioni ridotte).
Entrambi gli scenari richiederebbero una sorta di bilanciamento del carico davanti a loro, che gestirebbe il traffico e lo reindirizzerebbe a una destinazione corretta.
Vediamo come ClusterControl può aiutarti a distribuire un Cluster Galera con un set di bilanciatori di carico che puoi utilizzare per la tua piattaforma Open edX.
Distribuzione del 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, dobbiamo definire la connettività SSH, senza password, chiave l'accesso SSH basato su SSH è un requisito per ClusterControl, altrimenti non sarà in grado di gestire l'infrastruttura del database.
Quindi dovremmo decidere il fornitore, la versione, la password, gli host e alcuni impostazioni aggiuntive:
Con tutti questi dettagli inseriti, siamo a posto per procedere con l'implementazione.
Distribuzione di ProxySQL
Il database stesso non è l'unico elemento che vogliamo distribuire. Abbiamo anche bisogno di un sistema di bilanciamento del carico che utilizzeremo per indirizzare il traffico verso i nodi che sono disponibili in un dato momento. Lo useremo anche per fornire una suddivisione in lettura/scrittura, indirizzando tutte le scritture su un singolo nodo MariaDB Galera. Questo ci aiuterà a evitare conflitti tra le scritture eseguite su diversi nodi Galera.
Per ProxySQL ClusterControl richiede anche la compilazione di alcune informazioni:è necessario selezionare il host su cui installarlo, decidere la versione di ProxySQL, le credenziali per gli utenti amministrativi e di monitoraggio. Tali utenti verranno utilizzati per gestire ProxySQL e monitorare lo stato del cluster Galera. Dovresti anche importare gli utenti del database esistenti o crearne uno nuovo per la tua applicazione. Infine, sta a te decidere quali nodi del database vuoi usare con ProxySQL e decidere se usare le transazioni implicite.
Distribuzione di Keepalived
Come passaggio successivo implementeremo Keepalived. L'idea qui è di avere un IP virtuale che punterà all'istanza ProxySQL funzionante. Tale VIP può quindi essere utilizzato nell'applicazione come endpoint per la connettività del database MySQL.
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:
Questo è praticamente tutto quando si tratta di distribuzione. Puoi puntare la tua piattaforma Open edX verso il VIP e la porta 6033, questo dovrebbe essere sufficiente per ottenere la connettività al tuo database di back-end. L'ultimo bit rimanente, se lo ritenessi necessario, sarebbe quello di configurare i controlli di causalità. C'è una variabile wsrep_sync_wait che può fare proprio questo. Può abilitare test su diversi modelli di accesso:letture, aggiornamenti, inserimenti, eliminazioni, sostituzioni e comandi SHOW. Se siamo interessati solo alle query SELECT, imposteremo questa variabile a "1" utilizzando la gestione della configurazione di ClusterControl.
Questo eseguirà questa modifica su tutti i nodi MariaDB Cluster.
Questo è praticamente tutto. Se desideri condividere parte della tua esperienza con Open edX, puoi lasciarci un commento.
