Bygga en mycket tillgänglig databas för Moodle med MariaDB (replikering och MariaDB-kluster)

Ansikte mot ansikte-möten är numera begränsade till ett minimum, onlineaktiviteter har tagit över som det huvudsakliga sättet för interaktion mellan lärare och elever. Det ökade stressen på de befintliga "mötes"-plattformarna online (finns det någon som inte vet vad Zoom är nuförtiden?) men också på online-utbildningsplattformar. Den höga tillgängligheten för onlineverktygen är viktigare än någonsin och driftteamen skyndar sig att bygga hållbara, högt tillgängliga arkitekturer för sina miljöer.

Antagligen har åtminstone några av er använt Moodle - det är en fristående onlineutbildningsplattform som du kan distribuera på plats och använda den för att leverera onlineutbildning för din organisation. Som vi nämnde är det lika viktigt som någonsin att få det att fungera på ett hållbart, mycket tillgängligt sätt. Vi skulle vilja föreslå en mycket tillgänglig lösning som involverar MariaDB som en backend-databas - både asynkron replikering och Galera Cluster.

Process för miljödesign

Vi skulle vilja börja med en process där vi skulle förklara tankeprocessen bakom att designa miljön för Moodle. Vi vill ha hög tillgänglighet därför fungerar inte en enda databasnod för oss. Vi vill ha flera noder och detta leder oss till det första designbeslutet. Ska vi använda asynkron replikering eller Galera Cluster? Den andra frågan är:hur ska vi fördela arbetsbelastningen över noderna? Låt oss börja med den andra.

Den senaste Moodle-versionen vid den tidpunkt då denna blogg skrevs (3.9) introducerade en trevlig funktion som heter säker läsning. Problemet att lösa här är att läsa efter skrivning. När du använder en nod är världen en enkel plats. Du skriver och sedan läser du. Vad du än skrev finns redan där. Men när du lägger till noder förändras saker och ting. I asynkron replikering kan slavar släpa efter till och med tiotals sekunder eller mer. Vad du än skriver på mastern kan ta några minuter (om inte mer i de mer extrema fallen) att tillämpas på slaven. Om du utför en skrivning och sedan omedelbart försöker läsa samma data från en av slavarna kan du få en otäck överraskning - data kommer inte att finnas där. Galera-klustret använder en "nästan" synkron replikering och i det här specifika fallet gör "virtuellt" en enorm skillnad - Galera är inte immun mot läs-efter-skriv-problemen. Det finns alltid en fördröjning mellan skrivexekveringen på den lokala noden och skrivuppsättningen tillämpas på återstående noder i klustret. Visst, det mäts troligen i millisekunder snarare än sekunder men det kan fortfarande bryta antagandet att du omedelbart kan läsa vad du skrev. Det enda stället där du säkert kan läsa efter att ha skrivit är noden som du skrev data på.

Eftersom Moodle förlitar sig på läs-efter-skrivning ganska mycket, kan vi inte lätt skala läsningar endast genom att lägga till fler noder att läsa från. För Galera Cluster skulle vi kunna försöka mildra problemet genom att använda konfigurationsinställningen wsrep-sync-wait för att tvinga Galera att säkerställa att läsningarna är säkra att köra. Detta skapar prestandapåverkan på systemet eftersom alla läsningar måste vänta på att skrivningar ska tillämpas innan de kan köras. Detta är också en lösning för MariaDB Cluster (och andra Galera-baserade lösningar), inte för asynkron replikering. Lyckligtvis löser lösningen från Moodle detta problem. Du kan definiera en lista över noder som eventuellt kan släpa och Moodle kommer att använda dem endast för läsningar som inte kräver att vara uppdaterade med skrivningarna. Alla återstående läsningar som kräver att data alltid är uppdaterade skulle riktas till skribentnoden. Så Moodles skalbarhet är lite begränsad eftersom endast de "säkra" läsningarna kan skalas ut. Vi kommer definitivt att vilja använda 3.9:s funktion med tanke på att detta är den enda säkra metoden för att avgöra vilket val som ska gå vart. Med tanke på att allt är skrivet i en Moodles konfigurationsfil skulle vi med största sannolikhet vilja använda en lastbalanserare, helst ProxySQL, för att skapa logik som skulle hantera vår läsdistribution.

Ska vi använda MariaDB Cluster eller asynkron replikering? Vi kommer faktiskt att visa dig hur du använder båda. I båda fallen kommer konfigurationen för Moodle att vara ungefär densamma. I båda fallen kommer vi att använda ProxySQL som lastbalanserare. Den största skillnaden mellan dessa lösningar är failover. MariaDB Cluster är mycket lättare att hantera - om en nod är nere kommer ProxySQL helt enkelt att flytta skrivtrafiken till en av de återstående noderna. Med asynkron replikering är saker och ting dock något annorlunda. Om mastern går ner måste failover ske. Detta sker inte automatiskt, du måste antingen utföra det för hand eller så kan du lita på någon programvara för att åstadkomma det. I vårt fall kommer vi att använda ClusterControl för att hantera miljön och utföra failover, därför, från användarens synvinkel, är det inte så stor skillnad mellan asynkron replikering och MariaDB Cluster - i båda fallen kommer skrivarfel att hanteras automatiskt och klustret kommer automatiskt att återställas .

Vad vi har etablerat är att vi kommer att visa upp både asynkron och praktiskt taget synkron replikering. Vi kommer att använda funktionen för säker skrivning från Moodle 3.9 och vi kommer att använda ProxySQL som lastbalanserare. För att säkerställa hög tillgänglighet kommer vi att behöva mer än en ProxySQL-instans, därför kommer vi att gå med två av dem och för att skapa en enda ingångspunkt till databaslagret kommer vi att använda Keepalived för att skapa en virtuell IP och peka den till en av de tillgängliga ProxySQL:erna knutpunkter. Så här kan vårt databaskluster se ut:

För asynkron replikering kan detta se ut ungefär så här:

Distribuera en mycket tillgänglig databasbackend för Moodle med hjälp av MariaDB-replikering

Låt oss börja med MariaDB-replikeringen. Vi kommer att använda ClusterControl för att distribuera hela databasens backend inklusive lastbalanserare.

Distribuera MariaDB-replikeringskluster

Först måste vi välja "Deploy" från guiden:

Då bör vi definiera SSH-anslutning, lösenordslös, nyckelbaserad SSH-åtkomst är ett krav för ClusterControl för att hantera databasinfrastruktur.

När du fyller i dessa uppgifter är det dags att välja en leverantör och en version , definiera superanvändarens lösenord och besluta om några andra detaljer.

Vi kommer att använda MariaDB 10.4 för tillfället. Som nästa steg måste vi definiera replikeringstopologin:

Vi bör skicka värdnamnen för noderna och hur de ska förhålla sig till varje Övrig. När vi är nöjda med topologin kan vi distribuera. För syftet med denna blogg kommer vi att använda master och två slavar som vår backend.

Vi har vårt första kluster klart. Låt oss nu distribuera ProxySQL och Keepalived.

Distribuera ProxySQL

För ProxySQL krävs att du fyller i vissa detaljer - välj den värd som ska installeras det på, besluta om ProxySQL-version, referenser för administrativa och övervakande användare. Du bör också importera befintliga databasanvändare eller skapa en ny för din applikation. Bestäm slutligen vilka databasnoder du vill använda med ProxySQL och bestäm om du använder implicita transaktioner. I fallet med Moodle är detta inte sant.

Distribuera Keepalived

Som nästa steg kommer vi att distribuera Keepalived.

Efter att ha skickat detaljer som ProxySQL-instanser som bör övervakas, virtuell IP och gränssnitt VIP ska binda till vi är redo att distribuera. Efter några minuter bör allt vara klart och topologin ska se ut som nedan:

Konfigurera Moodle och ProxySQL för Safe Writes Scale-Out

Det sista steget blir att konfigurera Moodle och ProxySQL för att använda säkra skrivningar. Även om det är möjligt att hårdkoda databasnoder i Moodle-konfigurationen, skulle det vara mycket bättre att lita på ProxySQL för att hantera topologiändringarna. Det vi kan göra är att skapa ytterligare en användare i databasen. Den användaren kommer att konfigureras i Moodle för att utföra säkra läsningar. ProxySQL kommer att konfigureras för att skicka all trafik som körs från den användaren till de tillgängliga slavnoderna.

Låt oss först skapa en användare som vi använder för skrivskyddad åtkomst.

Vi beviljar alla privilegier här men det borde vara möjligt att begränsa den listan .

Användare som vi just skapat måste läggas till i båda ProxySQL-instanserna som vi har i klustret för att ProxySQL ska kunna autentisera sig som den användaren. I ClusterControl UI kan du använda åtgärden "Importera användare".

Vi kan söka efter användaren som vi just skapade:

ProxySQL använder ett koncept med värdgrupper - grupper av värdar som tjänar samma syfte . I vår standardkonfiguration finns det två värdgrupper - värdgrupp 10 som alltid pekar på nuvarande master och värdgrupp 20 som pekar mot slavnoder. Vi vill att denna användare ska skicka trafiken till slavnoder, därför kommer vi att tilldela HG 20 som standard.

Det är allt, användaren kommer att visas i listan över användare:

Nu bör vi upprepa samma process på den andra ProxySQL-noden eller använda Alternativet "Synkronisera instanser". På ett eller annat sätt bör båda ProxySQL-noderna ha moodle_safereads-användaren tillagd.

Det sista steget blir att distribuera Moodle. Vi kommer inte att gå igenom hela processen här, men det finns ett problem vi måste ta itu med. ProxySQL presenterar sig som 5.5.30 och Moodle klagar på att den är för gammal. Vi kan enkelt redigera den till vilken version vi vill:

När detta är gjort måste vi tillfälligt skicka all trafik till mästaren. Detta kan åstadkommas genom att ta bort alla frågeregler i ProxySQL. "Moodle"-användaren har HG10 som standardvärdgrupp vilket innebär att utan frågeregler kommer all trafik från den användaren att dirigeras till mastern. Den andra, säkra läsningen, användaren har standardvärdgruppen 20 som är i stort sett all konfiguration vi vill ha på plats.

När detta är gjort bör vi redigera Moodles konfigurationsfil och aktivera kassaskåpet läser funktion:

<?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!

Vad som hände här är att vi lade till skrivskyddad anslutning till ProxySQL som kommer att använda moodle_safereads-användaren. Denna användare kommer alltid att peka mot slavar. Detta avslutar vår installation av Moodle för MariaDB-replikering.

Distribuera en mycket tillgänglig databasbackend för Moodle med MariaDB Cluster

Den här gången ska vi försöka använda MariaDB Cluster som vår backend. Återigen, det första steget är detsamma, vi måste välja "Deploy" från guiden:

När du har gjort det bör vi definiera SSH-anslutning, lösenordslös, nyckel- baserad SSH-åtkomst är ett krav för att ClusterControl ska kunna hantera databasinfrastruktur.

Då bör vi bestämma oss för leverantör, version, lösenordsvärdar och några fler inställningar:

När vi har fyllt i alla detaljer är vi bra att distribuera.

Vi skulle kunna fortsätta här ytterligare men eftersom alla ytterligare steg i princip är desamma som med MariaDB-replikering, ber vi dig bara att scrolla upp och kontrollera avsnittet "Deploying ProxySQL" och allt som följer efter det. Du måste distribuera ProxySQL, Keepalived, konfigurera om den, ändra Moodles konfigurationsfil och det här är i stort sett det. Vi hoppas att den här bloggen kommer att hjälpa dig att bygga högt tillgängliga miljöer för Moodle med stöd av MariaDB Cluster eller replikering.