Osobní schůzky jsou v dnešní době omezeny na naprosté minimum, online aktivity se staly hlavním způsobem interakce mezi učitelem a studentem. Zvýšilo to stres na stávajících online platformách pro „setkání“ (je tu někdo, kdo dnes neví, co je Zoom?), ale také na online výukové platformy. Vysoká dostupnost online nástrojů je důležitější než kdy jindy a operační týmy spěchají s budováním odolných a vysoce dostupných architektur pro svá prostředí.
S největší pravděpodobností alespoň někteří z vás používali Moodle – je to samostatná online výuková platforma, kterou můžete nasadit v místě a používat ji k poskytování online školení pro vaši organizaci. Jak jsme zmínili, je stejně důležité jako vždy, aby fungoval trvanlivým a vysoce dostupným způsobem. Rádi bychom navrhli vysoce dostupné řešení, které zahrnuje MariaDB jako backendovou databázi – asynchronní replikaci i Galera Cluster.
Proces návrhu prostředí
Rádi bychom začali procesem, ve kterém bychom vysvětlili myšlenkový proces, který stojí za návrhem prostředí pro Moodle. Chceme vysokou dostupnost, proto nám nefunguje jediný databázový uzel. Chceme více uzlů a to nás vede k prvnímu rozhodnutí o návrhu. Měli bychom použít asynchronní replikaci nebo Galera Cluster? Druhá otázka zní:jak rozložíme pracovní zátěž mezi uzly? Začněme tím druhým.
Nejnovější verze Moodle v době vzniku tohoto blogu (3.9) zavedla příjemnou funkci zvanou bezpečné čtení. Problém k vyřešení se zde čte po zápisu. Když použijete jeden uzel, svět je jednoduché místo. Píšeš a pak čteš. Cokoli jsi napsal, už tam je. Když však přidáte uzly, věci se změní. V asynchronní replikaci mohou být podřízené jednotky zpožďovány i o desítky sekund nebo více. Cokoli napíšete na master, může trvat i minuty (ne-li více v extrémních případech), než se to aplikuje na slave. Pokud provedete zápis a poté se okamžitě pokusíte číst stejná data z jednoho z podřízených zařízení, můžete být nemile překvapeni - data tam nebudou. Klastr Galera používá „virtuálně“ synchronní replikaci a v tomto konkrétním případě „virtuálně“ znamená obrovský rozdíl – Galera není imunní vůči problémům čtení-po-zápisu. Vždy existuje zpoždění mezi provedením zápisu na místním uzlu a aplikací zápisu na zbývající uzly clusteru. Jistě, s největší pravděpodobností se to měří v milisekundách spíše než v sekundách, ale stále to může narušit předpoklad, že si můžete okamžitě přečíst, co jste napsali. Jediným místem, kde můžete po zápisu bezpečně číst, je uzel, na kterém jste zapsali data.
Protože Moodle hodně spoléhá na čtení-po-zápis, nemůžeme snadno škálovat čtení pouze přidáním dalších uzlů, ze kterých bychom mohli číst. Pro Galera Cluster bychom se mohli pokusit problém zmírnit pomocí konfiguračního nastavení wsrep-sync-wait, abychom přinutili Galeru, aby zajistila bezpečné provedení čtení. To má dopad na výkon systému, protože všechna čtení musí čekat na provedení zápisu, než mohou být provedena. Toto je také řešení pro MariaDB Cluster (a další řešení založená na Galera), nikoli pro asynchronní replikaci. Naštěstí řešení od Moodle tento problém řeší. Můžete definovat seznam uzlů, které mohou mít zpoždění a Moodle je použije pouze pro čtení, která nevyžadují aktuální zápisy. Všechna zbývající čtení, která vyžadují, aby byla data vždy aktuální, by byla přesměrována do zapisovacího uzlu. Škálovatelnost Moodle je tedy poněkud omezená, protože lze škálovat pouze „bezpečná“ čtení. Určitě budeme chtít použít funkci 3.9 vzhledem k tomu, že je to jediná bezpečná metoda, jak určit, který výběr by měl kam jít. Vzhledem k tomu, že vše je zapsáno v konfiguračním souboru Moodle, pravděpodobně bychom chtěli použít nástroj pro vyrovnávání zatížení, nejlépe ProxySQL, abychom vytvořili logiku, která by zvládla naši distribuci čtení.
Máme použít MariaDB Cluster nebo asynchronní replikaci? Ve skutečnosti vám ukážeme, jak používat obojí. V obou případech bude konfigurace pro Moodle v podstatě stejná. V obou případech použijeme ProxySQL jako loadbalancer. Hlavním rozdílem mezi těmito řešeními je převzetí služeb při selhání. MariaDB Cluster je mnohem snazší řešit - pokud je jeden uzel mimo provoz, ProxySQL jednoduše přesune provoz zápisu do jednoho ze zbývajících uzlů. S asynchronní replikací jsou věci trochu jiné. Pokud hlavní selže, musí dojít k převzetí služeb při selhání. To se nestane automaticky, musíte to provést ručně nebo se můžete spolehnout na nějaký software, který toho dosáhne. V našem případě použijeme ClusterControl ke správě prostředí a provedeme převzetí služeb při selhání, takže z uživatelského hlediska není velký rozdíl mezi asynchronní replikací a MariaDB Clusterem - v obou případech bude selhání zapisovače automaticky ošetřeno a cluster se automaticky obnoví .
Zjistili jsme, že předvedeme asynchronní i virtuálně synchronní replikaci. Použijeme funkci bezpečného zápisu z Moodle 3.9 a jako loadbalancer použijeme ProxySQL. Pro zajištění vysoké dostupnosti budeme potřebovat více než jednu ProxySQL instanci, proto použijeme dvě z nich a pro vytvoření jediného vstupního bodu do databázové vrstvy použijeme Keepalived k vytvoření virtuální IP a nasměrujeme ji na jednu z dostupných ProxySQL uzly. Náš databázový cluster může vypadat následovně:
Pro asynchronní replikaci by to mohlo vypadat nějak takto:
Nasazení vysoce dostupného databázového backendu pro Moodle pomocí replikace MariaDB
Začněme replikací MariaDB. K nasazení celého databázového backendu včetně load balancerů se chystáme použít ClusterControl.
Nasazení MariaDB Replication Cluster
Nejprve musíme v průvodci vybrat „Deploy“:
Pak bychom měli definovat připojení SSH, přístup SSH bez hesla a klíče je požadavek na ClusterControl pro správu databázové infrastruktury.
Když vyplníte tyto údaje, je čas vybrat dodavatele a verzi , definovat heslo superuživatele a rozhodnout o některých dalších podrobnostech.
Zatím budeme používat MariaDB 10.4. Jako další krok musíme definovat topologii replikace:
Měli bychom předat názvy hostitelů uzlů a jejich vztah ke každému jiný. Jakmile jsme s topologií spokojeni, můžeme nasadit. Pro účely tohoto blogu budeme jako backend používat master a dva slave.
Máme náš první cluster hotový a připravený. Nyní nasadíme ProxySQL a Keepalived.
Nasazení ProxySQL
Pro ProxySQL je nutné vyplnit některé podrobnosti – vybrat hostitele k instalaci na, rozhodnout o verzi ProxySQL, přihlašovací údaje pro administrátory a monitorovací uživatele. Měli byste také importovat stávající uživatele databáze nebo vytvořit nového pro vaši aplikaci. Nakonec se rozhodněte, které databázové uzly chcete používat s ProxySQL, a rozhodněte se, zda používáte implicitní transakce. V případě Moodle to není pravda.
Nasazení Keepalived
Jako další krok nasadíme Keepalived.
Po předání podrobností, jako jsou instance ProxySQL, které by měly být monitorovány, virtuální IP a rozhraní VIP by se mělo vázat na jsme připraveni k nasazení. Po několika minutách by mělo být vše připraveno a topologie by měla vypadat následovně:
Konfigurace Moodle a ProxySQL pro bezpečné škálování zápisů
Posledním krokem bude konfigurace Moodle a ProxySQL pro použití bezpečných zápisů. I když je možné napevno zakódovat databázové uzly v konfiguraci Moodle, bylo by mnohem lepší spolehnout se na ProxySQL, aby zvládl změny topologie. Co můžeme udělat, je vytvořit dalšího uživatele v databázi. Tento uživatel bude v Moodle nakonfigurován tak, aby prováděl bezpečné čtení. ProxySQL bude nakonfigurováno tak, aby odesílalo veškerý provoz prováděný tímto uživatelem na dostupné podřízené uzly.
Nejprve vytvořte uživatele, kterého budeme používat pro přístup pouze pro čtení.
Zde poskytujeme všechna oprávnění, ale mělo by být možné tento seznam omezit .
Uživatel, kterého jsme právě vytvořili, musí být přidán do obou instancí ProxySQL, které máme v clusteru, abychom umožnili ProxySQL autentizovat se jako tento uživatel. V uživatelském rozhraní ClusterControl můžete použít akci „Importovat uživatele“.
Můžeme vyhledat uživatele, kterého jsme právě vytvořili:
ProxySQL používá koncept hostitelských skupin – skupiny hostitelů, které slouží stejnému účelu . V naší výchozí konfiguraci jsou dvě hostitelské skupiny - hostitelská skupina 10, která vždy ukazuje na aktuální hlavní a hostitelská skupina 20, která ukazuje na podřízené uzly. Chceme, aby tento uživatel posílal provoz na podřízené uzly, proto přiřadíme HG 20 jako výchozí.
To je vše, uživatel se zobrazí v seznamu uživatelů:
Nyní bychom měli zopakovat stejný proces na druhém uzlu ProxySQL nebo použít Možnost „Synchronizovat instance“. Tak či onak by do obou uzlů ProxySQL měl být přidán uživatel moodle_safereads.
Posledním krokem bude nasazení Moodle. Nebudeme zde procházet celým procesem, ale je tu jeden problém, který musíme vyřešit. ProxySQL se prezentuje jako 5.5.30 a Moodle si stěžuje, že je příliš starý. Můžeme jej snadno upravit na jakoukoli verzi, kterou chceme:
Jakmile to provedeme, musíme dočasně odeslat veškerý provoz na mistr. Toho lze dosáhnout odstraněním všech pravidel dotazu v ProxySQL. Uživatel „moodle“ má HG10 jako výchozí hostitelskou skupinu, což znamená, že bez pravidel dotazování bude veškerý provoz od tohoto uživatele směrován na hlavní server. Druhý, bezpečný uživatel, má výchozí hostitelskou skupinu 20, což je v podstatě celá konfigurace, kterou chceme mít na místě.
Jakmile to uděláme, měli bychom upravit konfigurační soubor Moodle a povolit trezor funkce čtení:
<?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!Stalo se zde to, že jsme přidali připojení pouze pro čtení k ProxySQL, které bude používat uživatele moodle_safereads. Tento uživatel bude vždy ukazovat na otroky. Tím je naše nastavení Moodle pro replikaci MariaDB ukončeno.
Nasazení vysoce dostupného databázového backendu pro Moodle pomocí MariaDB Cluster
Tentokrát se pokusíme použít MariaDB Cluster jako náš backend. Opět platí, že první krok je stejný, musíme v průvodci vybrat „Deploy“:
Jakmile to uděláte, měli bychom definovat připojení SSH, bez hesla, klíč- přístup založený na SSH je pro ClusterControl podmínkou pro správu databázové infrastruktury.
Pak bychom se měli rozhodnout pro dodavatele, verzi, hostitele hesel a pár dalších nastavení:
Jakmile vyplníme všechny podrobnosti, můžeme nasadit.
Zde bychom mohli pokračovat dále, ale vzhledem k tomu, že všechny další kroky jsou v zásadě stejné jako u replikace MariaDB, požádali bychom vás, abyste se posunuli nahoru a zkontrolovali sekci „Nasazení ProxySQL“ a vše, co po ní následuje. Musíte nasadit ProxySQL, Keepalived, překonfigurovat, změnit konfigurační soubor Moodle a to je skoro vše. Doufáme, že vám tento blog pomůže vytvořit vysoce dostupná prostředí pro Moodle podporovaná MariaDB Clusterem nebo replikací.