Spotkania twarzą w twarz są w dzisiejszych czasach ograniczone do absolutnego minimum, aktywność online przejęła rolę głównego sposobu interakcji między nauczycielem a uczniem. Zwiększyło to nacisk na istniejące internetowe platformy „spotkań” (czy jest ktoś, kto nie wie, czym jest obecnie Zoom?), ale także na internetowe platformy edukacyjne. Wysoka dostępność narzędzi online jest ważniejsza niż kiedykolwiek, a zespoły operacyjne spieszą się z tworzeniem trwałych, wysokodostępnych architektur dla swoich środowisk.
Najprawdopodobniej przynajmniej część z Was korzystała z Moodle — jest to samodzielna internetowa platforma edukacyjna, którą można wdrożyć lokalnie i używać jej do prowadzenia szkoleń online dla swojej organizacji. Jak wspomnieliśmy, równie ważne jak zawsze jest, aby działała w sposób trwały i wysoce dostępny. Chcielibyśmy zaproponować wysoce dostępne rozwiązanie, które wykorzystuje MariaDB jako bazę danych zaplecza - zarówno replikację asynchroniczną, jak i klaster Galera.
Proces projektowania środowiska
Chcielibyśmy zacząć od procesu, w którym wyjaśnimy proces myślowy stojący za projektowaniem środowiska dla Moodle. Chcemy wysokiej dostępności, dlatego pojedynczy węzeł bazy danych nie działa dla nas. Chcemy wielu węzłów, a to prowadzi nas do pierwszej decyzji projektowej. Czy powinniśmy używać replikacji asynchronicznej czy Galera Cluster? Drugie pytanie brzmi:jak rozłożymy obciążenie na węzły? Zacznijmy od drugiego.
Najnowsza wersja Moodle w czasie pisania tego bloga (3.9) wprowadziła fajną funkcję o nazwie bezpieczne odczyty. Problem do rozwiązania tutaj jest czytany po napisaniu. Kiedy używasz jednego węzła, świat jest prostym miejscem. Piszesz, a potem czytasz. Cokolwiek napisałeś, już tam jest. Kiedy jednak dodajesz węzły, wszystko się zmienia. W replikacji asynchronicznej urządzenia podrzędne mogą być opóźnione nawet o kilkadziesiąt sekund lub więcej. Cokolwiek napiszesz na mistrzu, może zająć nawet kilka minut (jeśli nie więcej w bardziej ekstremalnych przypadkach), aby zastosować go do niewolnika. Jeśli wykonasz zapis, a następnie natychmiast spróbujesz odczytać te same dane z jednego z niewolników, możesz spotkać się z niemiłą niespodzianką - danych tam nie będzie. Klaster Galera wykorzystuje „wirtualnie” replikację synchroniczną iw tym konkretnym przypadku „wirtualnie” robi ogromną różnicę – Galera nie jest odporna na problemy z odczytem po zapisie. Zawsze występuje opóźnienie między wykonaniem zapisu w węźle lokalnym a zastosowaniem zestawu zapisu do pozostałych węzłów klastra. Jasne, najprawdopodobniej jest to mierzone w milisekundach, a nie w sekundach, ale nadal może to łamać założenie, że możesz od razu przeczytać to, co napisałeś. Jedynym miejscem, w którym możesz bezpiecznie czytać po zapisaniu, jest węzeł, w którym zapisałeś dane.
Ponieważ Moodle w dużym stopniu polega na czytaniu po zapisie, nie możemy łatwo skalować odczytów tylko przez dodanie większej liczby węzłów, z których można czytać. W przypadku Galera Cluster moglibyśmy spróbować złagodzić ten problem, używając ustawienia konfiguracji wsrep-sync-wait, aby zmusić Galera do upewnienia się, że odczyty są bezpieczne. Stwarza to wpływ na wydajność systemu, ponieważ wszystkie odczyty muszą czekać na zastosowanie zapisów, zanim będą mogły zostać wykonane. Jest to również rozwiązanie dla klastra MariaDB (i innych rozwiązań opartych na Galera), a nie do replikacji asynchronicznej. Na szczęście rozwiązanie od Moodle rozwiązuje ten problem. Możesz zdefiniować listę węzłów, które mogą być opóźnione, a Moodle użyje ich tylko do odczytów, które nie wymagają bycia na bieżąco z zapisami. Wszystkie pozostałe odczyty, które wymagają, aby dane były zawsze aktualne, byłyby kierowane do węzła zapisującego. Tak więc skalowalność Moodle jest trochę ograniczona, ponieważ tylko „bezpieczne” odczyty mogą być skalowane. Na pewno będziemy chcieli skorzystać z funkcji 3.9, biorąc pod uwagę, że jest to jedyna bezpieczna metoda określenia, który wybór powinien się znaleźć. Biorąc pod uwagę, że wszystko jest napisane w pliku konfiguracyjnym Moodle, najprawdopodobniej chcielibyśmy użyć load balancera, najlepiej ProxySQL, aby stworzyć logikę, która obsłuży naszą dystrybucję odczytu.
Czy powinniśmy używać klastra MariaDB czy replikacji asynchronicznej? Właściwie pokażemy Ci, jak korzystać z obu. W obu przypadkach konfiguracja Moodle będzie prawie taka sama. W obu przypadkach użyjemy ProxySQL jako loadbalancera. Główną różnicą między tymi rozwiązaniami jest przełączanie awaryjne. Klaster MariaDB jest znacznie łatwiejszy w obsłudze — jeśli jeden węzeł nie działa, ProxySQL po prostu przeniesie ruch zapisu do jednego z pozostałych węzłów. W przypadku replikacji asynchronicznej sytuacja wygląda jednak nieco inaczej. Jeśli master ulegnie awarii, musi nastąpić przełączenie awaryjne. Nie dzieje się to automatycznie, albo musisz to zrobić ręcznie, albo możesz polegać na jakimś oprogramowaniu, aby to osiągnąć. W naszym przypadku użyjemy ClusterControl do zarządzania środowiskiem i przełączenia awaryjnego, dlatego z punktu widzenia użytkownika nie ma dużej różnicy między replikacją asynchroniczną a klastrem MariaDB — w obu przypadkach awaria zapisu zostanie automatycznie obsłużona, a klaster zostanie automatycznie odzyskany .
Ustaliliśmy, że będziemy prezentować replikację zarówno asynchroniczną, jak i wirtualnie synchroniczną. Użyjemy funkcji bezpiecznego zapisu z Moodle 3.9 i użyjemy ProxySQL jako loadbalancer. Aby zapewnić wysoką dostępność, będziemy potrzebować więcej niż jednej instancji ProxySQL, dlatego użyjemy dwóch z nich i aby utworzyć pojedynczy punkt wejścia do warstwy bazy danych, użyjemy Keepalived do utworzenia wirtualnego adresu IP i skierowania go do jednego z dostępnych ProxySQL węzły. Oto jak może wyglądać nasz klaster baz danych:
W przypadku replikacji asynchronicznej może to wyglądać mniej więcej tak:
Wdrażanie zaplecza bazy danych o wysokiej dostępności dla Moodle przy użyciu replikacji MariaDB
Zacznijmy od replikacji MariaDB. Zamierzamy użyć ClusterControl do wdrożenia całego zaplecza bazy danych, w tym systemów równoważenia obciążenia.
Wdrażanie klastra replikacji MariaDB
Najpierw musimy wybrać „Wdrażanie” z kreatora:
Następnie powinniśmy zdefiniować łączność SSH, dostęp przez SSH bez hasła jest wymóg ClusterControl do zarządzania infrastrukturą bazy danych.
Po wypełnieniu tych danych czas wybrać dostawcę i wersję , zdefiniuj hasło superużytkownika i zdecyduj o kilku innych szczegółach.
Na razie będziemy używać MariaDB 10.4. W następnym kroku musimy zdefiniować topologię replikacji:
Powinniśmy przekazać nazwy hostów węzłów i ich związek z każdym inny. Gdy jesteśmy zadowoleni z topologii, możemy wdrożyć. Na potrzeby tego bloga użyjemy mastera i dwóch slave'ów jako naszego backendu.
Mamy nasz pierwszy klaster już gotowy. Teraz wdrożmy ProxySQL i Keepalived.
Wdrażanie ProxySQL
W przypadku ProxySQL należy podać kilka szczegółów - wybierz hosta do zainstalowania włącz, zdecyduj o wersji ProxySQL, poświadczeniach dla użytkowników administracyjnych i monitorujących. Należy również zaimportować istniejących użytkowników bazy danych lub utworzyć nowego dla swojej aplikacji. Na koniec zdecyduj, których węzłów bazy danych chcesz używać z ProxySQL i zdecyduj, czy używasz transakcji niejawnych. W przypadku Moodle nie jest to prawdą.
Wdrażanie funkcji Keepalved
W następnym kroku wdrożymy Keepalived.
Po przekazaniu szczegółów, takich jak instancje ProxySQL, które powinny być monitorowane, wirtualny adres IP i interfejs VIP powinien zostać powiązany z którym jesteśmy gotowi do wdrożenia. Po kilku minutach wszystko powinno być gotowe, a topologia powinna wyglądać jak poniżej:
Skonfiguruj Moodle i ProxySQL dla bezpiecznego skalowania zapisu
Ostatnim krokiem będzie skonfigurowanie Moodle i ProxySQL do bezpiecznego zapisu. Chociaż możliwe jest zakodowanie węzłów bazy danych na sztywno w konfiguracji Moodle, znacznie lepiej byłoby polegać na ProxySQL do obsługi zmian topologii. Możemy stworzyć dodatkowego użytkownika w bazie danych. Ten użytkownik zostanie skonfigurowany w Moodle do wykonywania bezpiecznych odczytów. ProxySQL zostanie skonfigurowany do wysyłania całego ruchu wykonywanego od tego użytkownika do dostępnych węzłów podrzędnych.
Najpierw utwórzmy użytkownika, którego będziemy używać tylko do odczytu.
Przyznajemy tutaj wszystkie uprawnienia, ale powinno być możliwe ograniczenie tej listy .
Użytkownik, który właśnie utworzyliśmy, musi zostać dodany do obu instancji ProxySQL, które mamy w klastrze, aby umożliwić ProxySQL uwierzytelnienie jako ten użytkownik. W interfejsie użytkownika ClusterControl możesz użyć akcji „Importuj użytkownika”.
Możemy wyszukać właśnie utworzonego użytkownika:
ProxySQL wykorzystuje koncepcję hostgroups - grup hostów, które służą temu samemu celowi . W naszej domyślnej konfiguracji istnieją dwie grupy hostów - grupa hostów 10, która zawsze wskazuje na bieżący serwer główny i grupę hostów 20, która wskazuje na węzły podrzędne. Chcemy, aby ten użytkownik wysyłał ruch do węzłów podrzędnych, dlatego przypiszemy HG 20 jako domyślny.
To wszystko, użytkownik zostanie wyświetlony na liście użytkowników:
Teraz powinniśmy powtórzyć ten sam proces na innym węźle ProxySQL lub użyć Opcja „Synchronizuj instancje”. Tak czy inaczej, oba węzły ProxySQL powinny mieć dodanego użytkownika moodle_safereads.
Ostatnim krokiem będzie wdrożenie Moodle. Nie będziemy tutaj przechodzić przez cały proces, ale jest jeden problem, który musimy rozwiązać. ProxySQL prezentuje się jako 5.5.30, a Moodle narzeka, że jest za stary. Możemy go łatwo edytować do dowolnej wersji:
Po wykonaniu tej czynności musimy tymczasowo przesłać cały ruch do mistrz. Można to osiągnąć, usuwając wszystkie reguły zapytań w ProxySQL. Użytkownik „moodle” ma HG10 jako domyślną grupę hostów, co oznacza, że bez reguł zapytań cały ruch od tego użytkownika będzie kierowany do mastera. Drugi, bezpieczny odczyt, użytkownik ma domyślną grupę hostów 20, która jest prawie całą konfiguracją, którą chcemy mieć.
Po wykonaniu tej czynności powinniśmy edytować plik konfiguracyjny Moodle i włączyć sejf czyta funkcja:
<?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!To, co się tutaj wydarzyło, polega na tym, że dodaliśmy połączenie tylko do odczytu do ProxySQL, które będzie używać użytkownika moodle_safereads. Ten użytkownik zawsze wskaże niewolników. To kończy naszą konfigurację Moodle dla replikacji MariaDB.
Wdrażanie zaplecza bazy danych o wysokiej dostępności dla Moodle za pomocą klastra MariaDB
Tym razem spróbujemy użyć MariaDB Cluster jako naszego backendu. Ponownie, pierwszy krok jest taki sam, musimy wybrać „Wdrażanie” z kreatora:
Gdy to zrobisz, powinniśmy zdefiniować łączność SSH, bez hasła, dostęp SSH jest wymagany przez ClusterControl do zarządzania infrastrukturą bazy danych.
Następnie powinniśmy zdecydować się na dostawcę, wersję, hosty haseł i kilka innych ustawienia:
Gdy wypełnimy wszystkie szczegóły, jesteśmy gotowi do wdrożenia.
Moglibyśmy kontynuować tutaj dalej, ale biorąc pod uwagę, że wszystkie dalsze kroki są w zasadzie takie same, jak w przypadku replikacji MariaDB, poprosilibyśmy po prostu o przewinięcie w górę i sprawdzenie sekcji „Wdrażanie ProxySQL” i wszystkiego, co po niej następuje. Musisz wdrożyć ProxySQL, Keepalived, przekonfigurować, zmienić plik konfiguracyjny Moodle i to prawie wszystko. Mamy nadzieję, że ten blog pomoże Ci zbudować wysoce dostępne środowiska dla Moodle wspierane przez klaster MariaDB lub replikację.
