Изграждане на високодостъпна база данни за Moodle с помощта на MariaDB (репликация и MariaDB клъстер)

Срещите лице в лице в днешно време са ограничени до минимума, онлайн дейностите се заеха като основен начин за взаимодействие между учител и ученик. Това увеличи стреса върху съществуващите онлайн платформи за „срещи“ (има ли някой, който не знае какво е Zoom в днешно време?), но също и върху платформите за онлайн обучение. Високата наличност на онлайн инструментите е по-важна от всякога и оперативните екипи бързат да изградят трайни, високодостъпни архитектури за своите среди.

Най-вероятно поне някои от вас са използвали Moodle – това е самостоятелна платформа за онлайн обучение, която можете да внедрите на място и да я използвате за предоставяне на онлайн обучение за вашата организация. Както споменахме, толкова важно е, както винаги, той да работи по издръжлив и високодостъпен начин. Бихме искали да предложим високодостъпно решение, което включва MariaDB като бекенд база данни – както асинхронна репликация, така и Galera Cluster.

Процес на проектиране на средата

Бихме искали да започнем с процес, в който ще обясним мисловния процес зад проектирането на средата за Moodle. Ние искаме висока наличност, затова един възел на базата данни не работи за нас. Искаме множество възли и това ни води до първото дизайнерско решение. Трябва ли да използваме асинхронна репликация или Galera Cluster? Вторият въпрос е:как ще разпределим натоварването между възлите? Да започнем с втория.

Последната версия на Moodle по времето, когато е бил написан този блог (3.9), въведе хубава функция, наречена безопасно четене. Проблемът за решаване тук се чете след запис. Когато използвате един възел, светът е просто място. Пишеш и после четеш. Каквото си написал вече е там. Когато добавите възли обаче, нещата се променят. При асинхронна репликация подчинените може да изостават дори с десетки секунди или повече. Каквото и да напишете на главния, може да отнеме дори минути (ако не и повече в по-екстремните случаи), за да се приложи към подчинения. Ако изпълните запис и след това незабавно се опитате да прочетете същите данни от един от подчинените, може да бъдете до неприятна изненада - данните няма да бъдат там. Клъстерът Galera използва „виртуално“ синхронна репликация и в този конкретен случай „виртуално“ прави огромна разлика - Galera не е имунизирана срещу проблемите при четене след запис. Винаги има забавяне между изпълнението на запис на локалния възел и набора за запис, който се прилага към останалите възли на клъстера. Разбира се, най-вероятно се измерва в милисекунди, а не в секунди, но все пак може да наруши предположението, че можете веднага да прочетете написаното. Единственото място, където можете безопасно да четете след запис, е възелът, на който сте написали данните.

Тъй като Moodle разчита много на четене след запис, не можем лесно да мащабираме четенията само чрез добавяне на още възли, от които да четем. За Galera Cluster бихме могли да се опитаме да смекчим проблема, като използваме конфигурационна настройка wsrep-sync-wait, за да принудим Galera да гарантира, че четенията са безопасни за изпълнение. Това създава въздействие върху производителността на системата, тъй като всички четения трябва да изчакат прилагането на записите, преди да могат да бъдат изпълнени. Това също е решение за MariaDB Cluster (и други базирани на Galera решения), а не за асинхронна репликация. За щастие, решението от Moodle решава този проблем. Можете да дефинирате списък с възли, които е възможно да изостават и Moodle ще ги използва само за четения, които не изискват да са актуални с записите. Всички останали четения, които изискват данните да бъдат винаги актуални, ще бъдат насочени към възела за записване. Така че мащабируемостта на Moodle е ограничена, тъй като само „безопасните“ четения могат да бъдат мащабирани. Определено ще искаме да използваме функцията на 3.9, като се има предвид, че това е единственият безопасен метод за определяне кой избор къде трябва да отиде. Като се има предвид, че всичко е написано в конфигурационния файл на Moodle, най-вероятно бихме искали да използваме балансьор на натоварване, за предпочитане ProxySQL, за да създадем логика, която да се справи с нашето разпределение за четене.

Трябва ли да използваме MariaDB клъстер или асинхронна репликация? Всъщност ще ви покажем как да използвате и двете. И в двата случая конфигурацията за Moodle ще бъде почти същата. И в двата случая ще използваме ProxySQL като loadbalancer. Основната разлика между тези решения е отказът. С MariaDB Cluster се справя много по-лесно - ако един възел не работи, ProxySQL просто ще премести трафика за запис към един от останалите възли. С асинхронната репликация нещата обаче са малко по-различни. Ако главният се повреди, трябва да се случи отказ. Това не се случва автоматично, или трябва да го изпълните на ръка, или можете да разчитате на някакъв софтуер, за да го постигнете. В нашия случай ще използваме ClusterControl за управление на средата и извършване на отказ, следователно, от гледна точка на потребителя, няма голяма разлика между асинхронната репликация и MariaDB Cluster - и в двата случая неизправността на записа ще се обработва автоматично и клъстерът автоматично ще се възстанови .

Това, което установихме, е, че ще демонстрираме както асинхронна, така и практически синхронна репликация. Ще използваме функцията за безопасно записване от Moodle 3.9 и ще използваме ProxySQL като loadbalancer. За да осигурим висока наличност, ще ни трябва повече от един екземпляр на ProxySQL, затова ще продължим с две от тях и за да създадем една точка на влизане в слоя на базата данни, ще използваме Keepalived, за да създадем виртуален IP и да го насочим към един от наличните ProxySQL възли. Ето как може да изглежда нашият клъстер от база данни:

За асинхронна репликация това може да изглежда така:

Разгръщане на високодостъпен бекенд на база данни за Moodle с помощта на MariaDB репликация

Нека започнем с репликацията на MariaDB. Ще използваме ClusterControl за разгръщане на целия бекенд на базата данни, включително балансьори на натоварване.

Разгръщане на клъстер за репликация на MariaDB

Първо трябва да изберем „Внедряване“ от съветника:

След това трябва да дефинираме SSH свързаност, без парола, базиран на ключ SSH достъп е изискване ClusterControl да управлява инфраструктурата на базата данни.

Когато попълните тези данни, е време да изберете доставчик и версия , дефинирайте паролата на суперпотребител и решете някои други подробности.

Засега ще използваме MariaDB 10.4. Като следваща стъпка трябва да дефинираме топологията на репликация:

Трябва да предадем имената на хостовете на възлите и как те трябва да се отнасят към всеки други. След като сме доволни от топологията, можем да разположим. За целите на този блог ще използваме главен и два подчинени като наш бекенд.

Първият ни клъстер е готов и готов. Сега нека внедрим ProxySQL и Keepalived.

Разгръщане на ProxySQL

За ProxySQL е необходимо да попълните някои подробности - изберете хоста, който да инсталирате Включете го, вземете решение за версията на ProxySQL, идентификационните данни за административните и наблюдаващите потребители. Трябва също да импортирате съществуващи потребители на база данни или да създадете нов за вашето приложение. Накрая решете кои възли на базата данни искате да използвате с ProxySQL и решете дали да използвате неявни транзакции. В случая с Moodle това не е вярно.

Внедряване на Keepalived

Като следващата стъпка ще внедрим Keepalived.

След предаване на подробности като ProxySQL екземпляри, които трябва да бъдат наблюдавани, виртуален IP и интерфейс VIP трябва да се обвърже с ние сме готови за внедряване. След няколко минути всичко трябва да е готово и топологията трябва да изглежда така:

Конфигуриране на Moodle и ProxySQL за мащабиране на Safe Writes

Последната стъпка ще бъде да конфигурирате Moodle и ProxySQL да използват безопасно записване. Въпреки че е възможно твърдо да се кодират възли на база данни в конфигурацията на Moodle, би било много по-добре да се разчита на ProxySQL за обработка на промените в топологията. Това, което можем да направим, е да създадем допълнителен потребител в базата данни. Този потребител ще бъде конфигуриран в Moodle да изпълнява безопасно четене. ProxySQL ще бъде конфигуриран да изпраща целия трафик, изпълняван от този потребител, към наличните подчинени възли.

Първо, нека създадем потребител, който ще използваме за достъп само за четене.

Тук предоставяме всички привилегии, но трябва да е възможно да ограничим този списък .

Потребителят, който току-що създадохме, трябва да бъде добавен към двата екземпляра на ProxySQL, които имаме в клъстера, за да позволим на ProxySQL да се удостовери като този потребител. В потребителския интерфейс на ClusterControl можете да използвате действието „Импортиране на потребител“.

Можем да търсим потребителя, който току-що създадохме:

ProxySQL използва концепция за групи хостове - групи хостове, които служат на същата цел . В нашата конфигурация по подразбиране има две хостгрупи - хостгрупа 10, която винаги сочи към текущия главен и хостгрупа 20, която сочи към подчинени възли. Искаме този потребител да изпраща трафика към подчинени възли, затова ще присвоим HG 20 като такъв по подразбиране.

Това е, потребителят ще бъде показан в списъка с потребителите:

Сега трябва да повторим същия процес на другия възел на ProxySQL или да използваме Опция „Синхронизиране на екземпляри“. По един или друг начин и двата ProxySQL възела трябва да имат добавен потребител moodle_safereads.

Последната стъпка ще бъде внедряването на Moodle. Няма да преминаваме тук през целия процес, но има един проблем, който трябва да разгледаме. ProxySQL се представя като 5.5.30 и Moodle се оплаква, че е твърде стар. Можем да го редактираме лесно до всяка версия, която искаме:

След като това стане, трябва временно да изпратим целия трафик към господарят. Това може да се постигне чрез изтриване на всички правила за заявка в ProxySQL. Потребителят на „moodle“ има HG10 като хостгрупа по подразбиране, което означава, че без правила за заявка целият трафик от този потребител ще бъде насочен към главната. Второто, безопасно четене, потребителят има хостгрупа по подразбиране 20, което е почти цялата конфигурация, която искаме да имаме.

След като това стане, трябва да редактираме конфигурационния файл на Moodle и да активираме сейфа функция за четене:

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

Това, което се случи тук, е, че добавихме връзка само за четене към ProxySQL, която ще използва потребител moodle_safereads. Този потребител винаги ще сочи към подчинени устройства. Това приключва нашата настройка на Moodle за репликация на MariaDB.

Разгръщане на високодостъпен бекенд на база данни за Moodle с помощта на MariaDB клъстер

Този път ще се опитаме да използваме MariaDB Cluster като наш бекенд. Отново, първата стъпка е същата, трябва да изберем “Deploy” от съветника:

След като направите това, трябва да дефинираме SSH свързаност, без парола, ключ- базираният SSH достъп е изискване за ClusterControl за управление на инфраструктурата на базата данни.

След това трябва да вземем решение за доставчика, версията, хостовете за пароли и още няколко настройки:

След като попълним всички подробности, сме готови за внедряване.

Бихме могли да продължим тук по-нататък, но като се има предвид, че всички следващи стъпки са по същество същите като при репликацията на MariaDB, просто бихме ви помолили да превъртите нагоре и да проверите секцията „Разгръщане на ProxySQL“ и всичко, което следва. Трябва да разположите ProxySQL, Keepalived, да го преконфигурирате, да промените конфигурационния файл на Moodle и това е почти всичко. Надяваме се, че този блог ще ви помогне да изградите високодостъпни среди за Moodle, подкрепени от MariaDB Cluster или репликация.