Jak skonfigurować replikację MongoDB i automatyczne przełączanie awaryjne

Zestaw replik jest definiowany jako klaster bazy danych składający się z wielu węzłów ze skonfigurowaną między nimi replikacją i automatycznym przełączaniem awaryjnym (failover). Aby upewnić się, że baza danych PRIMARY zostanie wybrana poprawnie, ważne jest, aby mieć nieparzystą liczbę członków w zestawie (włączając lub wykluczając węzeł Arbiter). 

Wybrana baza danych jest odpowiedzialna za wszystkie główne zadania. Przetwarza przychodzące operacje zapisu i przechowuje informacje o nich w oplogu. Informacje te mogą być pobierane i replikowane przez członków repliki SECONDARY w celu zastosowania ich we własnych zbiorach danych. W rezultacie wszystkie serwery w zestawie będą reprezentować tę samą zawartość i zapewniać jej dostępność:

Rozważmy teraz sytuację, w której nieoczekiwany problem (taki jak awaria sprzętu lub połączenia) powoduje przestój głównej bazy danych. W takim przypadku system automatycznie rozpocznie nowy proces wyboru, aby przywrócić normalne funkcjonowanie bez konieczności ręcznej interwencji. Zaletą takiego systemu jest to, że otrzymujesz to, co najlepsze z replikacji, takich jak zwiększona dostępność, nadmiarowość failover i odzyskiwanie po awarii (disaster recovery), bez konieczności martwienia się o oddzielne zarządzanie wieloma bazami danych.

Jeśli chcesz wdrożyć podobny system, ten samouczek pokaże Ci, jak skonfigurować zestaw replik MongoDB za pomocą CloudSigma PaaS. Jak zobaczysz w tym przewodniku, będziemy używać trzech członków, co zazwyczaj wystarcza do zapewnienia dobrego marginesu bezpieczeństwa informacji i wydajności do obsługi operacji we/wy dla większości typowych aplikacji. Oprócz samej konfiguracji replikacji dowiemy się również, jak przygotować środowisko, skonfigurować uwierzytelnianie między węzłami bazy danych oraz jak upewnić się, że nasza praca zakończyła się sukcesem.

Krok 1: Utwórz nowe środowisko

Na początek będziesz potrzebować co najmniej 3 węzłów MongoDB, aby rozpocząć konfigurację zestawu replik. Śmiało utwórz więc nowe środowisko w następujący sposób:

W naszym przykładzie przypisujemy wszystkie instancje MongoDB w wersji 4.0.2 do tego samego środowiska. Możesz zmienić Nazwę środowiska w razie potrzeby w wyznaczonym miejscu i kontynuować proces instalacji.

Kolejnym krokiem w tym procesie będzie zadbanie o bezpieczeństwo komunikacji między tymi węzłami przy użyciu pliku klucza uwierzytelniającego.

Krok 2: Dodaj plik klucza uwierzytelniającego

Uwierzytelnianie jest kluczowym elementem każdej replikacji. Jest to proces zapewniania bezpieczeństwa, który daje dostęp członkowi zestawu replik dopiero po jego poprawnej identyfikacji za pomocą unikalnego pliku klucza uwierzytelniającego. Chroni to Twoje dane przed niepożądanymi osobami trzecimi. Oto jak możesz wygenerować własny plik klucza uwierzytelniającego:

1. Kliknij opcję Web SSH dla jednego z węzłów bazy danych i zaloguj się:

    2. Następnie możesz wprowadzić własny plik klucza lub wygenerować nowy za pomocą openssl przy użyciu następującego polecenia:

W tym poleceniu, 741 reprezentuje rozmiar klucza w bajtach, a my.key to nazwa klucza.

    3. Czas na dystrybucję nowego pliku klucza do wszystkich instancji MongoDB. Oto jak to zrobić:

• Otwórz Menedżer plików klikając przycisk Config obok dowolnego z węzłów bazy danych:

• Zlokalizuj plik my.key w zakładce konfiguracji pod ścieżką: /home/jelastic/my.key. Otwórz go i skopiuj zawartość pliku:

• Pod ścieżką /var/lib/jelastic/keys znajdziesz katalog keys. Utwórz Nowy plik, którego instancje MongoDB będą używać do wzajemnego uwierzytelniania swojej tożsamości. W naszym przypadku utworzymy plik o nazwie mongo-set.key:

• Wklej wcześniej skopiowaną zawartość do tego pliku i zastosuj zmiany, klikając Zapisz dla wszystkich instancji:

W wyniku tego procesu plik mongo-set.key został rozesłany do wszystkich naszych węzłów MongoDB.

Krok 3: Skonfiguruj replikację MongoDB

Nowy, gdy zapewniliśmy bezpieczeństwo instancji, możemy przejść do właściwej konfiguracji zestawu replik. Zaczynajmy:

1. Zacznij od przejścia do zakładki konfiguracji dla węzłów MongoDB i otwarcia pliku mongo.conf w katalogu etc folder. Przewiń w dół, aż znajdziesz sekcję replication. Odkomentuj ją i dodaj następujący ciąg z unikalną nazwą dla swojego zestawu replik. W naszym przykładzie nazwiemy go db-replication:

      2. Następnie dodamy nowy parametr o nazwie keyFile w sekcji security. Posłuży to do określenia ścieżki do pliku klucza, który obecnie znajduje się pod ścieżką: /var/lib/jelastic/keys/mongo-set.key:

      3. Kliknij odpowiedni przycisk, aby zapisać zmiany dla wszystkich instancji w oknie edytora. 

      4. Teraz musisz zrestartować wszystkie swoje węzły bazy danych aby zastosować nowe parametry konfiguracji:

Należy pamiętać, że po zakończeniu konfiguracji zestawu replik i ponownym uruchomieniu wszystkich węzłów lub węzła PRIMARY, podczas restartu rozpocznie się proces wyboru nowej bazy danych PRIMARY.

     5. Wybierz serwer MongoDB, którego chcesz użyć jako PRIMARY, i uzyskaj do niego dostęp za pomocą protokołu SSH:

Pamiętaj: po wybraniu bazy danych PRIMARY, pozostali członkowie zestawu replik nie będą już dostępni dla bezpośrednich operacji zapisu. Oznacza to, że wszystkie zmiany i konfiguracje mogą być wykonywane i stosowane wyłącznie na bieżącym węźle PRIMARY. Dlatego, chyba że skonfigurowano wcześniej priorytety, konieczna będzie zmiana ciągu połączenia (connection string) w aplikacji na nowy węzeł PRIMARY.

     6. Następnie uzyskaj dostęp do replikowanej bazy danych, używając odpowiednich danych uwierzytelniających:

W tym poleceniu:

• {user} –odnosi się do nazwy użytkownika administratora, która zostanie wysłana na Twój e-mail (domyślnie jest to zazwyczaj admin).

• {password} –to hasło wysłane na Twój e-mail wraz z odpowiednią nazwą użytkownika.

• {DB_name}- reprezentuje nazwę bazy danych, którą chcesz replikować w tym zestawie replik (w naszym przykładzie używamy domyślnej bazy admin).

W przypadku nowych wyborów możesz użyć tych samych danych uwierzytelniających użytkownika admin, aby zalogować się do nowej bazy danych PRIMARY.

     7. Po nawiązaniu połączenia należy wykonać następujące linie, aby zdefiniować parametry dla bieżącego węzła MongoDB i zainicjować zestaw replik:

W powyższych liniach zastąpisz wartości w nawiasach własnymi odpowiednimi danymi:

• {replica_set} – to nazwa Twojej replikowanej grupy baz danych, którą określiłeś na początku tej sekcji. W naszym przypadku było to db-replication.

• {current_db_ip} – wskazuje adres IP wybranego kontenera bazy danych:

W naszym przypadku wykonane linie to:

        8. Następnie wykonaj następujące polecenie dla wszystkich pozostałych baz danych:

Tutaj, {db_ip} odnosi się do adresu IP każdej bazy danych:

       9. Po dodaniu wszystkich członków replikacji otrzymasz w pełni funkcjonalny zestaw replik. Na koniec procesu zalecamy upewnienie się, że wszystko zostało poprawnie skonfigurowane. Aby to zrobić, wykonaj polecenie: rs.status(). Spowoduje to wyświetlenie pełnych informacji dotyczących zestawu replik, w następujący sposób:

Krok 4: Skonfiguruj arbiter zestawu replik

W niektórych przypadkach zalecamy użycie węzła Arbiter w określonych przypadkach. Czym jest węzeł Arbiter ? Zazwyczaj replikacja jest bardziej niezawodna, jeśli zestaw replik zawiera nieparzystą liczbę węzłów. Jeśli więc obecnie masz parzystą liczbę węzłów w swoim zestawie, możesz dodać węzeł Arbiter , aby utrzymać kworum, ponieważ odpowiada on na żądania bicia serca (heartbeat) i wyboru od innych członków zestawu. Oto kilka szczegółów na temat węzłów Arbiter węzłów Arbiter:

• Arbiter nie przechowuje żadnych danych; głosuje jedynie w wyborach w przypadku awarii innego węzła.
• Jest bardzo lekki i nie zużywa zbyt wielu zasobów.
• Wymieniał dane uwierzytelniające użytkowników między zaszyfrowanymi replikami.
• Aby utrzymać najwyższą dostępność, spróbuj uruchomić Arbitra na osobnym węźle.

Oto jak możesz dodać węzeł Arbitra do swojego zestawu replik:

1. Najpierw wykonamy skalowanie poziome i dodamy dodatkowy węzeł do klastra:

2. Po dodaniu węzła potrzebujemy nowego pliku klucza. Przejdź do katalogu keys i utwórz plik klucza mongo-set.key. Skopiuj zawartość klucza z dowolnego z wcześniej skonfigurowanych węzłów bazy danych i wklej ją tutaj, tak jak robiliśmy to wcześniej.

3. Przejdź do pliku konfiguracyjnego mongod.conf. Odkomentuj sekcję replikacji i dodaj repISetName (w naszym przypadku jest to db-replication). Przejdź również do sekcji security i dodaj parametr keyFile ( /var/lib/jelastic/keys/mongo-set.key w naszym przypadku).

4. Na koniec zrestartuj nowy węzeł, aby zastosować te nowe parametry konfiguracyjne:

Ważne jest, aby pamiętać, że w tym momencie NIE trzeba restartować wszystkich węzłów w klastrze. Zrestartuj tylko nowo dodany węzeł Arbitra. Zrestartowanie wszystkich węzłów spowoduje ponowne wybory węzła PRIMARY (chyba że określono priorytety w celu wyboru konkretnego węzła bazy danych jako PRIMARY).

 5. Na koniec można dodać Arbitra do zestawu replik. Aby to zrobić, wykonaj następujące polecenie na węźle PRIMARY:

Tutaj, {db_ip} to adres IP nowego węzła:

 6. Teraz możesz sprawdzić, czy nowy węzeł stał się Arbitrem. Możesz to zrobić, logując się na nowy węzeł przez SSH i łącząc się z instancją MongoDB za pomocą danych uwierzytelniających otrzymanych w wiadomości e-mail w momencie tworzenia węzła:

To pokazuje, że nowy węzeł, który właśnie dodaliśmy do klastra, działa jako Arbiter dla db-replication. Zapewnia to kworum w każdej sytuacji, czyniąc zestaw replik bardziej niezawodnym.

Krok 5: Testowanie dostępności klastra bazy danych

Następnie możemy skonfigurować nasz klaster MongoDB do zdalnego łączenia się i wykonywania operacji. W poniższym przykładzie połączymy się i wykonamy kilka poleceń kontrolnych za pomocą prostej aplikacji PHP.

W tym celu będziesz potrzebować serwera aplikacji, takiego jak Apache. Możesz dodać go do swojego środowiska, tak jak my to zrobiliśmy, lub utworzyć nowy w osobnym środowisku.

1. Zacznij od kliknięcia Change Environment Topology i dodania serwera:

    2. Otwórz kartę Configuration Manager dla serwera Apache klikając przycisk Config jak pokazano poniżej:

3. Znajdź i otwórz plik index.php w katalogu /var/www/webroot/ROOT i wklej poniższy kod w miejsce domyślnej zawartości:

Następujące wartości w powyższym kodzie należy zastąpić odpowiednimi danymi:

• {replica_set_name} – wprowadź nazwę swojej grupy replik.
• {db_username} – dodaj użytkownika admin wybranej głównej bazy danych (domyślnie jest to admin).
• {db_password} – wprowadź hasło użytkownika admin.
• {NodeID} – podaj numer identyfikacyjny odpowiedniego węzła. Możesz go znaleźć w panelu CloudSigma PaaS.
• {environment_domain} – dodaj domenę środowiska. Możesz ją również znaleźć w panelu CloudSigma PaaS:

Upewnij się, że określisz identyfikatory każdego węzła w swojej grupie replik w odpowiedniej sekcji mongodbConnectionURI.

Wprowadzenie odpowiednich wartości i uruchomienie kodu spowoduje wyświetlenie zestawu ciągów znaków podobnych do tego:

Upewnij się, że zapiszesz plik w tym momencie!

4. Aby serwer Apache mógł współdziałać z serwerem MongoDB, wymaga specjalnego modułu. Możesz dodać ten moduł w configs. Przejdź do folderu etc i otwórz plik php.ini file. Znajdź sekcję [mongodb] . W tym miejscu wystarczy usunąć średnik przed linią extension=mongodb.so, aby włączyć to rozszerzenie:

      5. Zastosuj nowe konfiguracje, klikając Zapisz w oknie edytora. Jak zawsze, musimy zrestartować węzły, aby zastosować zmiany. Kliknij przycisk Restartuj węzły obok Application Server, aby to zrobić:

    6. Teraz kliknij przycisk Otwórz w przeglądarce , aby to przetestować:

Kliknięcie tej ikony otworzy nową kartę przeglądarki, która pokaże wszystkie informacje o członkach/węzłach Twojej grupy replik i ich dostępności w ten sposób:

Ponieważ użyliśmy polecenia ping (linia 6 pliku index.php ), pierwsza linia wyświetla wynik sprawdzenia dostępności grupy replik:

Oznacza to, że grupa replik została pomyślnie przetestowana. 

Kolejny blok w wynikach pokazuje szczegółowe informacje o hostach grupy replik. Dane te są pozyskiwane dzięki funkcji getServers (linia 11 pliku index.php). Podobnie możesz również sprawdzić niektóre wartości przypisane podczas procesu tworzenia tej grupy replik:

• host – adres IP konkretnej bazy danych.

• port – to jest port bieżącego członka replikacji.

• [“is_primary”] oraz [“is_secondary”] – parametry wskazujące status serwera. Odpowiednie wartości dla wybranego głównego serwera MongoDB to odpowiednio true, false, a dla dwóch pozostałych serwerów MongoDB – false, true.

Dodatkowo możesz w dowolnym momencie uruchamiać i zatrzymywać węzły bazy danych, aby śledzić zmiany. Możesz również odświeżyć stronę, aby zrobić to samo. Pozwala to upewnić się, że Twój klaster MongoDB jest zawsze dostępny i działa zgodnie z Twoją konfiguracją.

CloudSigma PaaS pozwala swoim użytkownikom czerpać korzyści z używania grup replik bez zbytniego martwienia się o konfigurację i kwestie zaplecza. Ten samouczek pokazuje, jak proste może być skonfigurowanie własnego klastra MongoDB w zaledwie kilku prostych krokach. Możesz dowiedzieć się więcej o MongoDB, jak skonfigurować go dla systemu Ubuntu lub publicznych serwerów chmurowych, a także jakie inne zaawansowane funkcje ma do zaoferowania CloudSigma PaaS. Zapraszamy również do wypróbowania wersji próbnej platformy PaaS bezpłatnie, aby zapoznać się z panelem i marketplace oraz ich ofertą. 

Wypróbuj PaaS za darmo przez 7 dni