Open edX е платформа за онлайн образователни дейности. Предвид ситуацията, в която се намира светът, всички подобни платформи се сблъскват с по-високи натоварвания и тяхното значение значително се е увеличило. Това не са само „помощни“ платформи, но често се превръщат в основен начин за извършване на образователни дейности. Това води до по-високи изисквания по отношение на натоварването, което могат да издържат, или наличността на платформата.
Open edX е сложен продукт, който се състои от множество елементи. Една от тях е базата данни MySQL. В този кратък блог бихме искали да обсъдим как можете да подобрите високата наличност на платформата Open edX.
Очевидно, единичната база данни на MySQL е единична точка на отказ и като такава не е подход, подходящ за производствените внедрявания. Има няколко начина, по които можете да подобрите наличността на MySQL база данни.
За начало можете да стартирате настройката главен - подчинен, като използвате асинхронна или полусинхронна репликация. Предимството му е, че когато главният е недостъпен, можете да повишите един от подчинените и да продължите с операцията. Основният недостатък на такава настройка е, че преминаването при отказ трябва да се извърши или ръчно, което увеличава времето на престой, или трябва да използвате някакъв външен софтуер (например ClusterControl), но отново може да отнеме малко време. И накрая, всеки вид асинхронна или полусинхронна репликация е обект на забавяне на репликацията. Това може сериозно да повлияе на сценариите четене след запис, при които приложението изпълнява запис на главния и след това незабавно се опитва да прочете тези данни от подчинения.
Друг подход би бил използването на клъстер Galera за съхраняване на данните от платформата Open edX. Можем да започнем с три клъстера на възли - такива клъстери могат автоматично да се справят с повредата на един възел. Останалите два възела ще продължат да работят и ще отговарят на заявки, идващи от приложението. Друго предимство на Galera е, че въпреки че е „виртуално“ синхронна (което до голяма степен означава, че е почти синхронна), има начин да се наложат проверки на причинно-следствената връзка и да се принудят клъстери в синхронен режим (дори ако плащате за това с намалена производителност).
И двата сценария ще изискват някакво средство за балансиране на натоварването пред тях, което ще обработва трафика и ще го пренасочи към правилна дестинация.
Нека видим как ClusterControl може да ви помогне да внедрите Galera Cluster с набор от балансиращи устройства, които можете да използвате за вашата Open edX платформа.
Разгръщане на MariaDB клъстер
Този път ще се опитаме да използваме MariaDB Cluster като наш бекенд. Отново, първата стъпка е същата, трябва да изберем “Deploy” от съветника:
След като направите това, трябва да дефинираме SSH свързаност, без парола, ключ -базиран SSH достъп е изискване за ClusterControl, в противен случай той няма да може да управлява инфраструктурата на базата данни.
След това трябва да вземем решение за доставчика, версията, паролата, хостовете и някои допълнителни настройки:
С попълнените всички тези подробности е добре да продължим с внедряването.
Разгръщане на ProxySQL
Самата база данни не е единственият елемент, който искаме да разположим. Нуждаем се и от балансьор на натоварване, който ще използваме за насочване на трафика към възлите, които са налични в дадения момент. Също така ще го използваме, за да осигурим разделяне на четене/запис, насочвайки всички записи към един възел на MariaDB Galera. Това ще ни помогне да избегнем конфликти между записвания, изпълнени на различни възли на Galera.
За ProxySQL ClusterControl също изисква попълване на информация - трябва да изберете хост, на който да го инсталирате, вземете решение за версията на ProxySQL, идентификационни данни за административните и наблюдаващи потребители. Тези потребители ще бъдат използвани за управление на ProxySQL и наблюдение на състоянието на вашия клъстер Galera. Трябва също да импортирате съществуващи потребители на база данни или да създадете нов за вашето приложение. И накрая, от вас зависи да решите кои възли на базата данни искате да използвате с ProxySQL и да решите дали да използвате неявни транзакции.
Внедряване на Keepalived
Като следващата стъпка ще внедрим Keepalived. Идеята тук е да имате виртуален IP, който ще сочи към работещия ProxySQL екземпляр. След това такъв VIP може да се използва в приложението като крайна точка за свързване на базата данни MySQL.
След предаване на подробности като ProxySQL екземпляри, които трябва да бъдат наблюдавани, виртуален IP и интерфейс VIP трябва да се обвърже с ние сме готови за внедряване. След няколко минути всичко трябва да е готово и топологията трябва да изглежда така:
Това е почти всичко, когато става въпрос за внедряването. Можете да насочите вашата Open edX платформа към VIP и порт 6033, това би трябвало да е достатъчно, за да получите свързаността към вашата бекенд база данни. Последният оставащ бит, ако сметнете за необходимо, би бил да конфигурирате проверки за причинно-следствена връзка. Има променлива wsrep_sync_wait, която може да направи точно това. Той може да активира тестове за няколко модела на достъп:четене, актуализиране, вмъкване, изтриване, заместване и команди SHOW. Ако се интересуваме само от заявките SELECT, ще зададем тази променлива на „1“, използвайки управление на конфигурацията на ClusterControl.
Това ще извърши тази промяна на всички възли на MariaDB Cluster.
Това е почти всичко. Ако искате да споделите част от опита си с Open edX, можете да ни оставите коментар.
