Open edX to platforma do działań edukacyjnych online. W sytuacji, w jakiej znajduje się świat, wszystkie takie platformy napotykają na większe obciążenia, a ich znaczenie znacznie wzrosło. Nie są to tylko platformy „pomocnicze”, ale często stają się głównym sposobem realizacji działań edukacyjnych. Prowadzi to do wyższych wymagań dotyczących obciążenia, które mogą obsłużyć lub dostępności platformy.
Open edX to złożony produkt, który składa się z wielu elementów. Jednym z nich jest baza danych MySQL. W tym krótkim blogu chcielibyśmy omówić, w jaki sposób możesz poprawić wysoką dostępność platformy Open edX.
Oczywiście pojedyncza baza danych MySQL jest pojedynczym punktem awarii i jako taka nie jest podejściem odpowiednim do wdrożeń produkcyjnych. Istnieje kilka sposobów na poprawę dostępności bazy danych MySQL.
Na początek możesz uruchomić konfigurację master-slave przy użyciu replikacji asynchronicznej lub półsynchronicznej. Zaletą tego jest to, że gdy mistrz jest niedostępny, możesz awansować jednego z niewolników i kontynuować operację. Główną wadą takiej konfiguracji jest to, że przełączanie awaryjne musi być wykonywane ręcznie, co wydłuża czas przestoju lub trzeba użyć zewnętrznego oprogramowania (na przykład ClusterControl), ale z drugiej strony może to zająć trochę czasu. Wreszcie każdy rodzaj replikacji asynchronicznej lub półsynchronicznej podlega opóźnieniu replikacji. Może to poważnie wpłynąć na scenariusze odczytu po zapisie, w których aplikacja wykonuje zapis na urządzeniu głównym, a następnie natychmiast próbuje odczytać te dane z urządzenia podrzędnego.
Innym podejściem byłoby użycie klastra Galera do przechowywania danych z platformy Open edX. Możemy zacząć od trzech klastrów węzłów - takie klastry potrafią automatycznie obsłużyć awarię pojedynczego węzła. Pozostałe dwa węzły będą nadal działać i reagować na zapytania pochodzące z aplikacji. Kolejną zaletą Galery jest to, że chociaż jest „wirtualnie” synchroniczna (co oznacza w dużej mierze, że jest prawie synchroniczna), istnieje sposób na wymuszenie sprawdzania przyczynowości i wymuszenie przejścia klastrów w tryb synchroniczny (nawet jeśli płacisz za to zmniejszona wydajność).
Oba scenariusze wymagałyby pewnego rodzaju systemu równoważenia obciążenia, który obsługiwałby ruch i przekierowywał go do właściwego miejsca docelowego.
Zobaczmy, jak ClusterControl może pomóc we wdrożeniu klastra Galera z zestawem systemów równoważenia obciążenia, których można używać na platformie Open edX.
Wdrażanie 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, musimy zdefiniować łączność SSH, bez hasła, klucz ClusterControl wymaga dostępu SSH, w przeciwnym razie nie będzie w stanie zarządzać infrastrukturą bazy danych.
Następnie powinniśmy zdecydować się na dostawcę, wersję, hasło, hosty i kilka dodatkowe ustawienia:
Po wypełnieniu wszystkich tych szczegółów możemy kontynuować wdrażanie.
Wdrażanie ProxySQL
Sama baza danych nie jest jedynym elementem, który chcemy wdrożyć. Potrzebujemy również load balancera, za pomocą którego skierujemy ruch do węzłów, które są w danym momencie dostępne. Wykorzystamy go również do zapewnienia podziału odczytu/zapisu, kierując wszystkie zapisy do jednego węzła MariaDB Galera. Pomoże nam to uniknąć konfliktów między zapisami wykonywanymi w różnych węzłach Galera.
W przypadku ProxySQL ClusterControl również wymaga uzupełnienia pewnych informacji - należy wybrać hosta, na którym chcesz go zainstalować, zdecyduj o wersji ProxySQL, poświadczeniach dla użytkowników administracyjnych i monitorujących. Użytkownicy ci będą wykorzystywani do zarządzania ProxySQL i monitorowania stanu Twojego klastra Galera. Należy również zaimportować istniejących użytkowników bazy danych lub utworzyć nowego dla swojej aplikacji. Wreszcie, do Ciebie należy decyzja, których węzłów bazy danych chcesz używać z ProxySQL i czy korzystasz z transakcji niejawnych.
Wdrażanie funkcji Keepalved
W następnym kroku wdrożymy Keepalived. Pomysł polega na tym, aby mieć wirtualny adres IP, który będzie wskazywał na działającą instancję ProxySQL. Taki VIP może być następnie użyty w aplikacji jako punkt końcowy dla połączenia z bazą danych MySQL.
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:
To prawie wszystko, jeśli chodzi o wdrożenie. Możesz skierować swoją platformę Open edX w stronę VIP i portu 6033, to powinno wystarczyć, aby uzyskać połączenie z bazą danych zaplecza. Ostatnim pozostałym bitem, jeśli uznasz to za konieczne, byłoby skonfigurowanie kontroli przyczynowości. Istnieje zmienna wsrep_sync_wait, która może to zrobić. Umożliwia testowanie kilku wzorców dostępu:odczyty, aktualizacje, wstawienia, usunięcia, zamiany i polecenia SHOW. Jeśli interesują nas tylko zapytania SELECT, ustawimy tę zmienną na „1” za pomocą zarządzania konfiguracją ClusterControl.
Spowoduje to wprowadzenie tej zmiany we wszystkich węzłach klastra MariaDB.
To prawie wszystko. Jeśli chcesz podzielić się swoimi doświadczeniami z Open edX, możesz zostawić nam komentarz.
