Pod wpływem pandemii COVID-19 wiele małych i średnich firm/MŚP przechodzi na platformy internetowe. Ta pandemia ma również wpływ na zajęcia stacjonarne lub fizyczne, a wiele szkół i uniwersytetów również przechodzi na tryb online i poszukuje narzędzi, z których można korzystać, aby nadal służyć uczniom lub uczniom, tak jak to miało miejsce w przypadku edukacji. nie przeszkadzać. Jedną ze znanych platform dostępnych do celów edukacyjnych online lub online jest Moodle.
Co to jest Moodle?
Moodle to oprogramowanie typu open source do zarządzania nauczaniem online lub LMS (znane również jako Virtual Learning Environment lub VLE) na licencji GPL. Umożliwia nauczycielom stworzenie własnej, prywatnej strony internetowej wypełnionej dynamicznymi kursami, które poszerzają naukę w dowolnym miejscu i czasie. Moodle ma pełne wsparcie z łatwym dostępem i funkcjami dla nauczycieli, uczniów lub administratorów.
Ponieważ jest to platforma typu open source i platforma wolnego oprogramowania, możesz korzystać z tego oprogramowania bezpłatnie i bez opłat licencyjnych, podobnie jak inne oprogramowanie typu open source. Koszty są naliczane tylko wtedy, gdy to oprogramowanie jest hostowane na płatnej platformie hostingowej lub jeśli hostujesz je za pomocą ich chmury Moodle. Moodle jest również dostępny dla urządzeń przenośnych, takich jak telefony komórkowe lub tablety.
Dlaczego potrzebujesz bazy danych o wysokiej dostępności?
W latach 90. wynaleziono bardzo proste rozwiązanie dla wysokiej dostępności (HA), a mianowicie Heartbeat. Klaster Heartbeat zasadniczo mógł robić dwie rzeczy:monitorował dwa węzły (i nie więcej niż dwa) i został skonfigurowany do uruchamiania jednej lub więcej usług na tych dwóch węzłach. Jeśli węzeł, który aktualnie hostował zasoby, uległ awarii, zrestartował zasoby klastra na pozostałym węźle. Chociaż początkowe wydanie Heartbeat nie monitorowało samych zasobów, zmieniło się to aż do wydania Heartbeat 2.0 na początku 2000 roku, gdzie umożliwiało zarządzanie więcej niż dwoma węzłami w klastrze. Zasadniczo obejmuje to stan klastrowania Linux HA, który jest w dużej mierze oparty na Heartbeat 2.0. Od tego momentu wpłynęło to na wiele rozwiązań HA, które zostały opracowane i stworzone w celu zminimalizowania przestojów, szczególnie w przypadku krytycznych zasobów.
Wysoka dostępność oznacza nie tylko minimalizację przestojów. Obejmuje również stopień odpowiedzialności za możliwość ciągłego działania i utrzymywania usług, które oferujesz i obiecujesz swoim klientom. Bycie dostępnym dla klientów nie oznacza również, że jesteś w stanie odpowiedzieć im w przypadku, gdy potrzebują pomocy. Musi zapewnić pełną funkcjonalność aplikacji i systemu biznesowego, tak jakby zawsze był to normalny stan działania, nawet w przypadku bezprecedensowej katastrofy.
Nie możesz obsługiwać aplikacji VLE za pomocą Moodle, gdy Twoja baza danych jest w trakcie konserwacji. Jeśli masz tylko jeden serwer bazy danych, co jest bardzo powszechne w przypadku prostej i lekkiej konfiguracji aplikacji, po awarii serwera aplikacja zatrzymuje się. Jeśli masz klaster bazy danych korzystający z replikacji master-slave, a następnie napotkasz bezprecedensowy incydent, który z kolei oznacza, że Twoja aplikacja zapisuje na dwóch masterach po incydencie, może to być ogromny bałagan, który z kolei powoduje uszkodzenie danych w całej aplikacji biznesowej i warstwa danych. Jeśli w tym czasie miały miejsce bieżące płatności, może to być ogromna katastrofa i wymaga dużego nakładu pracy podczas odzyskiwania danych.
Dlaczego więc Twoja baza danych musi być wysoce dostępna? To dlatego, że tak musi być,
- Możliwość wykonywania konserwacji lub planowanych przestojów w sposób wykonalny i w dozwolonym oknie konserwacji
- Przestój jest niezbędny i w razie potrzeby należy unikać przestojów
- SLA jest ważne ze względu na wyższy stopień osiągnięcia wysokiej jakości obsługi klienta
- Zapewnij ciągłą obsługę i użyteczność
- Brak pojedynczego punktu awarii
- Możliwość przełączania awaryjnego w przypadku awarii lub awarii urządzenia głównego
- Unikaj scenariusza z rozdwojonym mózgiem, w którym wielu mistrzów działa jednocześnie jako aktywni pisarze
Tworzenie klastra baz danych
Teraz, gdy podkreśliliśmy znaczenie posiadania HA jako planu i rozwiązania dla klastra baz danych, zwłaszcza dla PostgreSQL, skupmy się na budowaniu klastra od góry do dołu, aby osiągnąć wysoki dostępna konfiguracja gotowa do konfiguracji aplikacji Moodle.
Instalacja PostgreSQL
Po pierwsze, dlaczego PostgreSQL? PostgreSQL ma ogromne zalety w porównaniu do innych baz danych obsługiwanych przez Moodle. To kwestia preferencji, jeśli mam podsumować, ponieważ wszystkie bazy danych obsługiwane przez Moodle są w stanie obsłużyć dane i podlegają również optymalizacji. Zależy to od umiejętności i doświadczenia w korzystaniu z bazy danych. Chociaż podsumowując, dlaczego używa się PostgreSQL, jest to niezawodna baza danych i jej wyrafinowane oprogramowanie open source, szczególnie w bazach danych, które można porównać z innymi zastrzeżonymi dostawcami, takimi jak Oracle i MS SQL. Obsługuje równoległość zapytań, jest w stanie zarządzać dużymi lub ogromnymi bazami danych, ma szerokie wsparcie dla JSON i wiele więcej. Możesz to sprawdzić tutaj, aby dowiedzieć się, dlaczego warto wybrać PostgreSQL. Przejdźmy teraz do instalacji PostgreSQL
W tym blogu użyjemy PostgreSQL 12 z Ubuntu 18.04 (Bionic Beaver). Następnie, do konfiguracji wysokiej dostępności, musisz mieć węzeł podstawowy i przynajmniej zapasowy (replikę), dla którego przejmie on zadanie po wyłączeniu mastera.
- Skonfiguruj repozytorium i klucz podpisywania
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Zainstaluj serwer PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Zrób to również w replice docelowej, ale musisz skonfigurować ją jako rezerwową lub replikę. Alternatywnie sugeruję użycie ClusterControl i pobranie go, ponieważ jest bezpłatny. Szybciej i szybciej byłoby zainstalować i skonfigurować konfigurację podstawową/w trybie gotowości. W przypadku mojej konfiguracji za pomocą ClusterControl i karty Widok topologii mam następującą topologię:
Nie oznacza, że jesteś w pełni objęty ochroną klastra bazy danych o wysokiej dostępności. Nie jest jeszcze wysoce dostępny. Gdy główny lub główny ulegnie awarii, nie nastąpi przełączenie awaryjne. Inną rzeczą jest to, że nie ma balansu pomiędzy połączeniami klientów, które trafiają do mastera z slave. Chociaż równoważenie obciążenia między master/slave nie pociąga za sobą konieczności konfiguracji lub zastosowania w celu spełnienia konfiguracji o wysokiej dostępności. Równoważenie obciążenia między urządzeniem nadrzędnym/głównym a podrzędnym/rezerwowym pomaga węzłowi głównemu w nieobciążaniu wydajności przy dużym obciążeniu, zwłaszcza w godzinach bardzo dużego natężenia ruchu.
Konfigurowanie równoważenia obciążenia
Jak wspomniano wcześniej, równoważenie obciążenia między urządzeniem nadrzędnym i podrzędnym pomaga urządzeniu nadrzędnemu w wyodrębnieniu obciążenia. Nie jest to idealne rozwiązanie, jeśli tryb gotowości będzie używany tylko do replikacji lub przejmie kontrolę w przypadku awarii urządzenia głównego. Chociaż może to działać, wiąże się to jednak z przestojem i pracą ręczną w przypadku awarii urządzenia głównego, ponieważ musisz przełączyć rolę węzła rezerwowego na urządzenie główne. To również jest w porządku, ale znowu posiadanie równoważenia obciążenia może pomóc skierować zapisy do urządzenia nadrzędnego, a następnie skierować odczyty między urządzeniem nadrzędnym a podrzędnym. Zasadniczo zapewnia to dzielenie odczytu/zapisu. Aby to zrobić, istnieje wiele opcji, z których możesz wybierać w PostgreSQL. Zasadniczo najpopularniejszą, ale prostą i lekką konfiguracją jest użycie HAProxy.
Chociaż istnieją opcje, takie jak użycie PgBouncer lub pgpool-II. Dla uproszczenia tego bloga użyjmy HAProxy. Instalacja HAProxy jest całkiem prosta, jeśli używasz ClusterControl. Zróbmy to za pomocą ClusterControl. Aby to zrobić, przejdź do zakładki Zarządzaj, wybierz Load Balancer, jak pokazano poniżej,
Ponieważ potrzebujemy wysoce dostępnej konfiguracji dla Twojego klastra bazy danych PostgreSQL, powinniśmy mieć co najmniej dwa węzły. Więc jeśli twój główny węzeł HAProxy ulegnie awarii, pasywny lub oczekujący HAProxy może przejąć kontrolę. Zobaczmy, jak to wygląda po mojej stronie,
Chociaż to wygląda dobrze. Ta konfiguracja jest nadal niewystarczająca. Jeśli uważasz, że jesteśmy dobrzy dla konfiguracji o wysokiej dostępności z tą topologią, nie ma przełączenia awaryjnego w przypadku awarii HAProxy na węźle 192.168.30.222 na porcie 9600 lub awarii 192.168.30.223:9600 i jeśli Twoja aplikacja jest tak skonfigurowana host, nadal występuje przestój, jeśli nie wykonano proaktywnej konfiguracji. Oznacza to, że masz przestój, jeśli trzeba go skonfigurować ręcznie. W takim przypadku użyjemy i skonfigurujemy Keepalive, aby instancje HAProxy były ściśle monitorowane pod kątem ich kondycji i przełączania awaryjnego na wypadek, gdyby inny węzeł napotkał problem.
Utrzymywanie wysokiej dostępności systemów równoważenia obciążenia
Teraz, gdy mamy load balancery nad naszymi bazami danych, ale potrzebujemy, aby nasze HAProxy było zawsze aktywne na wypadek awarii głównego węzła dla punktu końcowego aplikacji. Zasadniczo, co HAProxy może zrobić z konfiguracją, którą mamy z poprzedniej sekcji, aplikacje mogą używać 192.168.30.223 lub 192.168.30.222 odpowiednio z portami 5433 (port do odczytu i zapisu) i 5434 (port tylko do odczytu). Teraz pojawia się problem w przypadku konieczności przełączenia w przypadku awarii innych węzłów, a złą rzeczą jest to, że szkodzisz firmie, ponieważ obejmuje ona przestoje, jeśli nie ma automatycznego przełączania awaryjnego, aby sobie z tym poradzić. Najlepszym sposobem jest unikanie przestojów, chyba że masz bardzo niskie SLA i wysokie RTO i RPO.
W celu złagodzenia takiej katastrofy lub przestoju, sugerujemy ustawienie Keepalive na HAProxy. Zasadniczo HAProxy będzie równoważyć obciążenie między odczytem i zapisem, zapewniając dzielenie odczytu i zapisu, a Keepalived tylko monitoruje kondycję węzłów HAProxy i zdoła wybrać najbardziej zdrowy węzeł zgodnie z pożądaną konfiguracją. Keepalived to narzędzie, za pomocą którego można monitorować węzły HAProxy, chociaż zarządzanie bazami danych nie jest tak skomplikowane. Keepalived używa VIP (wirtualnego adresu IP), który przypisuje do domyślnego podstawowego węzła HAProxy, a następnie ponownie przypisuje ten adres VIP w przypadku awarii głównego węzła HAProxy i kieruje go do kolejnego lub rezerwowego węzła HAProxy.
Teraz skonfigurujmy to za pomocą ClusterControl, ponieważ zarządzanie nim jest szybsze i łatwiejsze. Aby to zrobić, jest to zasadniczo takie samo podejście, jak w przypadku konfiguracji HAProxy, ale zamiast tego wybierz Keepalved, jak pokazano poniżej,
Zasadniczo, jeśli instalujesz Keepalived ręcznie, wybieramy pomocniczy w przypadku awarii podstawowego HAProxy. Zobaczmy, jak wygląda nasz widok topologii,
Może to wyglądać bardzo obiecująco. Zasadniczo klient aplikacji Moodle połączy się z VIP, tj. 192.168.30.201 na portach 5433 (port do odczytu-zapisu) i 5434 (port tylko do odczytu). Na przykład weryfikując go na zewnętrznym hoście, który mam,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)co pokazuje, że tylko węzeł zapisujący, który mam, wskazuje na mój węzeł główny, tj. 192.168.30.22. Następnie mój port tylko do odczytu musi iść zarówno do węzła głównego, jak i podrzędnego, jak pokazano poniżej,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)To pokazuje, że zarówno moje węzły podstawowe, jak i rezerwowe są identyfikowane jako węzły „odczytu bazy danych”.
Teraz wygląda to bardzo obiecująco, jak powiedziałem wcześniej. Jednak brakuje tu jednej części, która jest w rzeczywistości bardzo ważna. Nie istnieje mechanizm przełączania awaryjnego bazy danych, który jest gotowy na tego typu konfigurację. Jednak mamy Keepalived, który monitoruje HAProxy, a następnie wykonuje przełączanie awaryjne, przełączając VIP w przypadku awarii lub śmierci podstawowego HAProxy. Jednak Keepalived nie jest skonfigurowany do obsługi złożonej konfiguracji PostgreSQL. Jest bardzo przyzwoity, który jest dostępny i darmowy. Możesz użyć Slony-I, systemu replikacji innej firmy.
Posiadanie mechanizmu przełączania awaryjnego w klastrze PostgreSQL
Istnieją sposoby na zapewnienie mechanizmu przełączania awaryjnego dla twojego PostgreSQL. Slony-I lub powszechnie nazywany po prostu Slony jest jednym z popularnych narzędzi, które są używane. Chociaż Slony wymaga, aby konfiguracja była logiczną replikacją, ponieważ wymaga konfiguracji wydawcy/subskrybenta, może nie być idealna dla innych konfiguracji korzystających ze standardowej replikacji strumieniowej. Wadą korzystania z Slony jest to, że nie zapewnia on automatycznego wykrywania uszkodzonych systemów ani nie obsługuje ogrodzenia węzłów. Dlatego powszechnie nazywany STONITH (strzelanie drugiego węzła w głowę lub strzelanie do uszkodzonego węzła w głowę), który zasadniczo odrzuca nieudane scenariusze z rozszczepieniem mózgu, w których wiele węzłów głównych (aktywnych węzłów zapisujących) akceptuje zapisy w w tym samym czasie. Chociaż można to odpowiednio skonfigurować, ale nadal może być czasochłonne i skomplikowane, jeśli jest tworzone przy mniejszym doświadczeniu i wglądzie w to, jakie scenariusze muszą się wydarzyć w przypadku PostgreSQL, gdy nastąpi katastrofa. Dla Slony rezygnacja z zatwierdzonych transakcji jest decyzją biznesową, której nie może podjąć system bazy danych. Jeśli ktoś chce umieścić poniższe polecenia w skrypcie wykonywanym automatycznie z systemu monitorowania sieci, pozostawia do własnej dyspozycji, że są to Twoje dane i zasady przełączania awaryjnego.
Alternatywnie, jeśli szukasz opcji korporacyjnych, które mogą kosztować rozsądne pieniądze, ClusterControl oferuje automatyczne odzyskiwanie klastrów PostgreSQL. Zasadniczo automatyczne odzyskiwanie rozwiązuje problemy opisane powyżej w przypadku Slony. Chociaż nasze automatyczne odzyskiwanie jest najlepiej przetestowane z replikacją strumieniową i jest obsługiwane tylko dla typu replikacji strumieniowej w konfiguracji PostgreSQL. Więc jak to działa? Zasadniczo wystarczy włączyć przyciski automatycznego przywracania, tak jak poniżej,
Obsługuje to odgradzanie węzła, co oznacza, że odrzuci uszkodzony węzeł w przypadku węzeł wraca do życia z jakiegoś nieprzewidzianego powodu. Poza tym automatyczne odzyskiwanie przez ClusterControl obsługuje odzyskiwanie węzłów i klastrów, że jeśli węzeł główny lub podrzędny zostanie przypadkowo zamknięty lub zabity, ClusterControl spróbuje przywrócić to, zwłaszcza jeśli nastąpi to poza planowanym przestojem lub oknem konserwacji. Ta funkcja chroni Cię przed wyczerpaniem się obaw związanych z bazami danych, a jednocześnie zapewnia proaktywne monitorowanie, które powiadomi Cię o możliwej katastrofie, zanim będzie za późno na odzyskanie.
Wnioski
Wysoce dostępne konfiguracje klastra bazy danych, zwłaszcza Moodle, mogą się różnić w zależności od rodzaju konfiguracji i wymagań, których potrzebujesz. Niezależnie od tego, czy jest to oparte wyłącznie na technologiach darmowych i open source, czy też istnieją inne opcje, które warto zainwestować w aplikację korporacyjną, o ile budżet może pomieścić, ponieważ może to zapewnić sytuację korzystną dla obu stron, zwłaszcza jeśli chcesz tylko bardziej się skupić po stronie biznesowej niż skupianie się na innych narzędziach, takich jak administracja i praca typu Devops.
