Jak wdrożyć bazę danych Open edX MongoDB w celu zapewnienia wysokiej dostępności?

Open edX to platforma, która zapewnia masowo skalowalną technologię oprogramowania do nauki stojącą za edX. Projekt Open edX to internetowa platforma do tworzenia, dostarczania i analizowania kursów online. Jest to oprogramowanie, które obsługuje edx.org i wiele innych internetowych witryn edukacyjnych.

Wcześniej pisaliśmy na blogu o wdrożeniu bazy danych o wysokiej dostępności dla MySQL na platformie Open edX. Jak wspomniano wcześniej, jest to złożona platforma, ponieważ obejmuje wiele komponentów, a część tej ogromnej platformy jest objęta wieloma usługami:

eCommerce:https://github.com/edx/ecommerce
Katalog:https://github.com/edx/course-discovery
LMS / Studio:https://github.com/edx/edx-platform
Poświadczenia:https://github.com/edx/credentials
Informacje:https://github.com/edx/edx-analytics-dashboard
Analytics API:https://github.com/edx/edx-analytics-data-api

Zasadniczo Open Edx jest idealny do kursów online pośród pandemii i szkoleń online, takich jak to, co już mogłeś wypróbować i wziąć, zwłaszcza jeśli uzyskujesz certyfikat produktu.

Krótki przegląd architektury

Centralnym elementem architektury Open edX jest platforma edx, która zawiera aplikacje do zarządzania nauką i tworzenia kursów (odpowiednio LMS i Studio). Oprócz platformy edx, usługi techniczne składające się na całą platformę obejmują różne zaangażowane technologie, które obejmują cały złożony poziom tego oprogramowania. Zobacz poniższy diagram zaczerpnięty z prezentacji zespołu edX w grudniu zeszłego roku.

Masz Snowflake, Amazon RDS, MongoDB, Amazon S3, Elasticsearch, Memcached , a Redis jako technologie ucieleśniające tę bogatą platformę. Mimo to nawet trudno jest zainstalować i skonfigurować Open edX, ale udało mi się stworzyć proste środowisko programistyczne, aby trochę zrozumieć tę platformę.

Choć skupmy się na MongoDB, która służy do przechowywania zawartości forów, struktury kursu i zasobów kursu. Dane każdego uczestnika są przechowywane w MySQL, więc jeśli chcesz wiedzieć i mieć wysoką dostępność dla swojego MySQL z Open edX, przeczytaj je tutaj.

Przechowywanie treści dla MongoDB

MongoDB to baza danych wybierana przez Open edX do przechowywania dużych plików, które są plikami tekstowymi, PDFami, klipami audio/wideo, plikami tar, itp. Jeśli znasz Open edX i używałeś go zwłaszcza jako autor dla LMS lub Studio, dane są przechowywane, jeśli prześlesz zasoby do swojej konfiguracji Open edX. Pliki te są tak zwane „contentstore” i są w zasadzie instancją GridFS wspieraną przez MongoDB. Open edX używa MongoDB GridFS do przechowywania danych plików w porcjach w ramach instancji MongoDB i jest w stanie przechowywać pliki o rozmiarze większym niż 16 MB. Może również wyświetlać fragmenty dużych plików zamiast całego pliku.

Zasób można przesłać jako „zablokowany” lub „odblokowany”. Zablokowany zasób jest dostępny tylko dla studentów biorących udział w konkretnym kursie — platforma edx sprawdza rolę użytkownika przed udostępnieniem pliku. Odblokowane zasoby są udostępniane każdemu użytkownikowi na żądanie. Gdy uczestnik kursu zażąda zasobu, cały zasób jest udostępniany z GridFS.

Konfigurowanie wysokiej dostępności dla bazy danych Open edX MongoDB

Przyznajmy, że instalacja lub konfiguracja platformy Open edX to duże wyzwanie. Jest to trudne, zwłaszcza, że jesteś nowy w tej platformie lub oprogramowaniu, ale ma bardzo świetny projekt architektoniczny. Jednak jest możliwe, że twoja konfiguracja z MongoDB to podstawa z jednym węzłem zestawu replik. Z drugiej strony najlepiej, aby Twój zestaw replik zawierał co najmniej drugorzędne lub wiele drugorzędnych węzłów oprócz głównego. Służy to twojej konfiguracji wysokiej dostępności w przypadku, gdy twój główny zostanie kaput, twój dodatkowy węzeł repliki przejmie rolę podstawową.

Skonfiguruj zestaw replik z replikami drugorzędnymi

W tym celu wystarczy dodać i skonfigurować co najmniej dwie repliki wtórne. Idealnym rozwiązaniem jest to, że przynajmniej w zestawie replik masz 3 węzły, z których jeden jest twoim głównym, a pozostałe dwa węzły są twoimi dodatkowymi replikami do głównego. Dzięki temu zestaw MongoDB Replica może przeprowadzić wybory w przypadku, gdy podstawowa utraci łączność ze swoimi drugorzędnymi. Zapewnia to niezawodność, nadmiarowość i oczywiście wysoką dostępność. Jest to prosta konfiguracja, której możesz potrzebować, aby uzyskać środowisko o wysokiej dostępności za pomocą MongoDB.

Dlaczego zapewnia to wysoką dostępność? Zestaw replik w MongoDB to grupa procesów mongod, które utrzymują ten sam zestaw danych. Zestawy MongoDB Replica wykorzystują wybory do określenia, który element zestawu stanie się głównym w przypadku awarii lub nieprawidłowego zakończenia działania podstawowego lub pewnych zmian w konfiguracji. Zestawy replik mogą wywołać wybory w odpowiedzi na różne zdarzenia, takie jak:

Dodawanie nowego węzła do zestawu replik,
inicjowanie zestawu replik,
wykonywanie konserwacji zestawu replik przy użyciu metod takich jak rs.stepDown() lub rs.reconfig() oraz
drugorzędne elementy członkowskie tracą łączność z podstawowymi dłużej niż skonfigurowany limit czasu (domyślnie 10 sekund).

Weź ten przykładowy diagram, który pokazuje, jak działają wybory.

Zdjęcie dzięki uprzejmości dokumentacji MongoDB

Dodatkowo możesz użyć innych replik pomocniczych jako Twoje preferencje odczytu, ale zależy to od konfiguracji opartej na połączeniu Twojego klienta. Możesz dowiedzieć się więcej, czytając opcje preferencji odczytu dla połączenia lub sprawdź Preferencje odczytu tutaj.

Teraz wygląda to świetnie, ale radzenie sobie z punktem końcowym klienta aplikacji, takim jak zmiana nazwy hosta lub adresu IP, wymaga ręcznej zmiany. Nie jest to idealne rozwiązanie, jeśli masz system równoważenia obciążenia na górze zestawu replik, tak jak HaProxy, ponieważ zestaw MongoDB Replica Set wykonuje wybory wewnętrznie w MongoDB.

Skonfiguruj klaster dzielony

Klaster podzielony na fragmenty jest idealny, jeśli masz do czynienia z dużymi zestawami danych. Chociaż nie oznacza to, że musisz zaprojektować klaster podzielony na fragmenty, musi on mieć do czynienia z dużymi zestawami danych. MongoDB oferuje mongos, czyli narzędzie, które powinno działać jako usługa routingu dla konfiguracji fragmentów MongoDB, która przetwarza zapytania z warstwy aplikacji, a następnie określa lokalizację tych danych w klastrze podzielonym na fragmenty zidentyfikowanym za pomocą klucza fragmentu w celu zakończenia transakcji lub bazy danych operacje. Po prostu pomyśl, że instancje Mongos zachowują się identycznie jak każda inna instancja MongoDB.

Po co więc mieć mongo przed swoją aplikacją? W czasach, gdy Twoja replika ustawia podstawową nazwę hosta lub adres IP zmienia się po wyborach, z perspektywy aplikacji oznacza to, że musisz również zmienić punkt końcowy. W przypadku mongos, po prostu skieruj klienta aplikacji do jednej z naszych instancji mongos. Twój klient aplikacji łączy się tylko z instancją mongos i to wszystko, co ma znaczenie. Mongos będzie tym, który obsłuży Twoje zapytania lub transakcje, wykorzystując swój cel i funkcję w konfiguracji MongoDB Shard. Oznacza to, że w plikach konfiguracyjnych Open edx nie ma żadnych zmian do zrobienia. Nie musisz ponownie uruchamiać serwerów aplikacji, aby nadążyć za zmianami w zestawach replik MongoDB.

Jak skonfigurować wysoką dostępność

Na przykład przy użyciu ClusterControl. Korzystanie z ClusterControl można osiągnąć w prosty i wydajny sposób, ponieważ można to zrobić za pomocą interfejsu użytkownika, unikając ręcznych konfiguracji i instalacji w przypadku bardzo złożonej konfiguracji.

Rozważmy, że masz istniejącą instancję MongoDB z istniejącą bazą danych Open edX,

rs0:PRIMARY> show dbs;

admin                0.000GB

cs_comments_service  0.000GB

edxapp               0.087GB

local                0.118GB



rs0:PRIMARY> rs.status()

{

        "set" : "rs0",

        "date" : ISODate("2021-01-22T14:46:51.398Z"),

        "myState" : 1,

        "term" : NumberLong(17),

        "heartbeatIntervalMillis" : NumberLong(2000),

        "members" : [

                {

                        "_id" : 0,

                        "name" : "192.168.40.10:27017",

                        "health" : 1,

                        "state" : 1,

                        "stateStr" : "PRIMARY",

                        "uptime" : 133,

                        "optime" : {

                                "ts" : Timestamp(1611326680, 1),

                                "t" : NumberLong(17)

                        },

                        "optimeDate" : ISODate("2021-01-22T14:44:40Z"),

                        "electionTime" : Timestamp(1611326679, 1),

                        "electionDate" : ISODate("2021-01-22T14:44:39Z"),

                        "configVersion" : 2,

                        "self" : true

                }

        ],

        "ok" : 1

}

Możesz po prostu zaimportować to jako istniejącą bazę danych do ClusterControl i wykonać kopię zapasową za pomocą funkcji kopii zapasowej ClusterControl. Alternatywnie możesz użyć mongodump lub spróbować użyć Percona Backup for MongoDB.

Teraz w ClusterControl utwórz fragment MongoDB jako nowe wdrożenie. Można to zrobić, wykonując następujące czynności:

Wdróż nowy fragment MongoDB w oknie kreatora wdrażania.

Skonfiguruj ustawienia SSH oraz ich serwery konfiguracji i routery. W tym miejscu twoje instancje mongos powinny znajdować się poza serwerami konfiguracyjnymi.

Zdefiniuj swoje odłamki. To są odłamki zestawu replik. W zależności od potrzeb. Na przykład w tym wdrożeniu wdrożyłem dwa fragmenty, ale możesz po prostu użyć jednego fragmentu na początek, szczególnie w przypadku małych wdrożeń.

Zdefiniuj ustawienia bazy danych

W tym momencie naciśnij naciśnij przycisk wdrażania i po prostu poczekaj, aż zadanie zostanie przetworzone przez ClusterControl.

Po zakończeniu możesz teraz przywrócić kopię zapasową pobraną z mongodump. Na przykład zrobiłem kopię zapasową za pomocą ClusterControl, a następnie użyłem jej jako kopii źródłowej. Korzystając z polecenia mongorestore, upewnij się, że host docelowy jest jedną z twoich instancji mongos. W tym przykładowym wdrożeniu mam hosta 192.168.40.233.

$ mongorestore --host 192.168.40.233 --port 27017 --username <username> --password <password> --gzip  --archive=BACKUP-2/rs0.gz --authenticationDatabase=admin

2021-01-22T11:17:06.335+0000    preparing collections to restore from

2021-01-22T11:17:06.336+0000    don't know what to do with subdirectory "cs_comments_service", skipping...

2021-01-22T11:17:06.336+0000    don't know what to do with subdirectory "edxapp", skipping...

2021-01-22T11:17:06.337+0000    don't know what to do with subdirectory "admin", skipping...

2021-01-22T11:17:06.337+0000    don't know what to do with subdirectory "", skipping...

2021-01-22T11:17:06.372+0000    restoring to existing collection edxapp.modulestore.definitions without dropping

2021-01-22T11:17:06.372+0000    reading metadata for edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'

2021-01-22T11:17:06.373+0000    restoring edxapp.modulestore.definitions from archive 'BACKUP-2/rs0.gz'

2021-01-22T11:17:06.387+0000    restoring to existing collection edxapp.fs.chunks without dropping

2021-01-22T11:17:06.387+0000    reading metadata for edxapp.fs.chunks from archive 'BACKUP-2/rs0.gz'

…

……

Teraz jesteś gotowy i wprowadź zmiany w plikach konfiguracyjnych Open edX . W mojej konfiguracji instalacji możesz zaktualizować /edx/etc/studio.yml i /edx/etc/lms.yml. Być może będziesz musiał zmienić również pliki w plikach /edx/app/edxapp/lms.auth.json i /edx/app/edxapp/cms.auth.json i zastąpić je poprawną nazwą hosta twojej instancji mongos.
Zweryfikuj w swoich mongosach i sprawdź, czy bazy danych są załadowane i czy mogą być dostępne,

[email protected]:~# mongo --host "mongodb://edxapp:[email protected]:27017/?authSource=admin"

MongoDB shell version v4.2.11

connecting to: mongodb://192.168.40.233:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb

Implicit session: session { "id" : UUID("00a3a395-3531-4381-972e-502478af38d1") }

MongoDB server version: 4.2.11

mongos> show dbs

admin                0.000GB

config               0.002GB

cs_comments_service  0.000GB

edxapp               0.104GB

Teraz wszystko gotowe!!!

W widoku sieciowym również ClusterControl, gdy ClusterControl zakończy wdrażanie, będziesz mieć topologię, która będzie wyglądać tak,

Gdy skończysz, możesz już zarządzać swoim Open edX i zarządzać Twoje kursy!