MongoDB jako klaster wysokiej dostępności
MongoDB to jedna z najpopularniejszych baz danych NoSQL, z której można korzystać na naszej platformie. W niniejszej instrukcji znajdziesz informacje o architekturze, konfiguracji i instalacji.
Last updated
MongoDB to jedna z najpopularniejszych baz danych NoSQL, z której można korzystać na naszej platformie. W niniejszej instrukcji znajdziesz informacje o architekturze, konfiguracji i instalacji.
Last updated
Na Cloudlets.Zone można łatwo uruchomić stos MongoDB w postaci klastra wysokiej dostępności. Architektura oparta jest na mechanizmach replikacji realizowanych zgodnie z zaleceniami producenta. Co daje klaster HA MongoDB:
Redundancja i wysoka dostępność danych - kilka replik danych utrzymywanych na różnych serwerach zapewnia wysoki poziom tolerancji na usterki czy awarie hostów.
Automatyczna skalowalność – nowe węzły, dodane podczas skalowania poziomego, są połączone z klasterem, a wszystkie wymagane reguły są implementowane automatycznie.
Automatyczne przywracanie – węzły baz danych, które są tymczasowo niedostępne lub mają wysokie opóźnienia, są automatycznie wyłączone z klastra i ponownie dodawane, gdy ustąpią przyczyny degradacji klastra.
Większa szybkość odczytu - w niektórych przypadkach, możliwe jest uzyskanie większej szybkości odczytu z bazy danych w architekturze wysokiej dostępności.
Zestaw replik to grupa co najmniej trzech instancji MongoDB, które utrzymują te same dane. Jeden węzeł zestawu jest uważany za podstawowy i jest odpowiedzialny za wszelkie operacje zapisu. Rejestruje też wszystkie zmiany w oplogu, dzięki czemu pozostałe węzły (zapasowe) mogą dokładnie odwzorować dane z węzła podstawowego. Jeżeli węzeł podstawowy stanie się niedostępny, automatycznie zostanie wybrany nowy, spośród węzłów zapasowych. Elekcja węzła podstawowego związana jest z opóźnieniem 10000 ms (parametr: "electionTimeoutMillis").
Poniżej wylistowane są domyślne wartości ustawień klastra MongoDB na Cloudlest.Zone:
“chainingAllowed” : true - pozwala węzłom zapasowym replikować się z innych węzłów;
“heartbeatIntervalMillis” : 2000 ms - częstotliwość dla heartbeats (sprawdzanie dostępności węzłów wchodzących w skład zestawu replik, tzw. puls);
“heartbeatTimeoutSecs” : 10 sec - czas oczekiwania na przywrócenie "pulsu", po którym następuje oznaczenie węzła jako niedostępny;
“electionTimeoutMillis” : 10000 ms - limit czasu potrzebny do wykrycia, że węzeł podstawowy jest nieosiągalny;
“catchUpTimeoutMillis” : -1 - (minus jeden = nieskończony) czas dla nowo wybranego węzła podstawowego na zsynchronizowanie najnowszych zapisów od pozostałych węzłów;
“catchUpTakeoverDelayMillis” : 30000 ms - czas dla węzeł zapasowego, który znajduje się przed obecnym pierwotnym, umożliwiający synchronizację przed elekcją nowego podstawowego.
W razie potrzeby, ustawienia te można zmienić ręcznie po instalacji klastra za pomocą polecenia rs.reconfig(). Sprawdź sekcję poniżej, aby dowiedzieć się, jak możesz połączyć się z klasterem MongoDB za pośrednictwem SSH i wprowadzić wymagane polecenia.
Kolejną ważną kwestią jest bezpieczeństwo i ochrona przed nieautoryzowanym dostępem. Proces uwierzytelniania zmusza każdy węzeł zestawu replik do identyfikowania się podczas komunikacji wewnętrznej za pomocą unikalnego klucza uwierzytelniania. Platforma automatycznie wdraża wymagane konfiguracje (w /etc/mongod.conf) i generuje klucz (przechowywany jest w /home/jelastic/mongodb.key) podczas konfiguracji klastra. Ponadto, aby zapewnić spójność, plik jest dodawany do pliku redeploy.conf, aby pozostał we wszystkich operacjach cyklu życia kontenera.
MongoDB domyślnie korzysta z silnika pamięci WiredTiger, co zapewnia wysoką wydajność (dzięki algorytmom nieblokującym) i optymalizacje w zakresie wykorzystania zasobów, a więc i kosztów. Domyślne opcje WiredTiger są zoptymalizowane do uruchamiania pojedynczej instancji mongod na serwer, która jest również odpowiednia dla kontenerów platformy Cloudlets.Zone. MongoDB wykorzystuje zarówno wewnętrzną pamięć podręczną WiredTiger, jak i pamięć podręczną systemu plików. Wewnętrzna wielkość pamięci podręcznej wynosi 50% całkowitej pamięci RAM minus 1 GB (ale nie mniej niż 256 MB), podczas gdy pamięć podręczna systemu plików obsługuje wolną pamięć, która nie jest używana przez WiredTiger ani inne procesy. Więcej informacji na temat konfiguracji WiredTiger można znaleźć w oficjalnej dokumentacji MongoDB.
Jeszcze jedną unikalną cechą automatycznego klastra MongoDB jest automatyczne wykrywanie nowych węzłów dodanych poprzez skalowanie poziome i włączanie ich do zestawu replik bez żadnych ręcznych działań. Podobnie, węzły są wykluczane z klastra podczas skalowania.
Cały proces tworzenia klastra MongoDB można wykonać za pomocą kilku prostych kliknięć.
Uruchom kreatora topologii za pomocą przycisku Nowe środowisko w górnym menu Panelu Usługi, a następnie w slocie NoSQL (krok 1 na poniższej grafice) wybierz MongoDB w preferowanej wersji. Aktywuj opcję Auto-klastrowanie za pomocą przełącznika (krok 2) i zwiększ limit skalowania pionowego do 32 cloudletów (odpowiednik: 4 GiB i 12,8 GHz). Na koniec kliknij przycisk Utwórz.
Minimalna wymagana liczba węzłów do utworzenia klastra MongoDB wynosi 3. Rekomendowana ilość pamięci operacyjnej dla każdego węzła klastra, gwarantująca prawidłową pracę wynosi 4 GiB.
Po kilku minutach klaster MongoDB zostanie utworzony i otrzymasz wiadomość e-mail z poświadczeniami. Możesz użyć otrzymane poświadczenia, aby uzyskać dostęp do panelu administracyjnego lub do nawiązania połączenia między aplikacją, a węzłem podstawowym zestawu replik.
Admin panel: https://node10524-mongodb.node.cloudlets.zone/ (przykład)
User: admin
Password: 13dEErFFG144f
Jak już wspomniano, w przypadku awarii dowolny węzeł zapasowy może stać się podstawowym. Elekcja zostanie przeprowadzona również w przypadku ponownego uruchomienia klastra. Możliwe jest wówczas, że powstanie nowy węzeł podstawowy. W takim przypadku, parametry połączenia aplikacji staną się nieprawidłowe. Aby uniknąć tych problemów, ciąg połączenia powinien zawierać nazwę zestawu replik, wszystkie nazwy hostów członkowskich i preferencje odczytu (jeśli jest to konieczne, aby zwolnić węzeł podstawowy w celu obsługi odczytów lub w celu zapewnienia wysokiej dostępności klastra i przełączania awaryjnego).
Oto przykład parametrów połączenia dla aplikacji node.js:
Opisane powyżej połączenie aplikacji uważa się za nawiązane w ramach jednej platformy hostingowej. Jeśli jednak zajdzie taka potrzeba, możesz nawiązać połączenie aplikacji zewnętrznej z zestawem replik poprzez SLB. W takim przypadku musisz utrzymywać połączenie z węzłem podstawowym tylko w celu odczytu/zapisu za pośrednictwem węzłów końcowych.
Jeśli chcesz czytać z węzłów zapasowych, konieczne będzie dostosowanie kodu aplikacji, aby czytała z węzłów zapasowych w osobnym wątku, tak jak robi się to w przypadku węzła podstawowego. W takim przypadku, należy usunąć parametr ReplicaSet z ciągu połączenia, by wyglądał następująco:
Domyślnie klaster korzysta z panelu administracyjnego Mongo Express, który zapewnia obsługę zestawów replik.
Możesz także połączyć się z bazą danych za pośrednictwem powłoki mongo bezpośrednio w terminalu (na przykład korzystając z naszego Web SSH).
Gdzie:
„user” – nazwa użytkownika (wysłana w wiadomości e-mail, domyślnie: admin )
„password” – hasło do odpowiedniego użytkownika DB (można znaleźć w tej samej wiadomości)
„DB_name” – nazwa bazy danych, do którego chcesz uzyskać dostęp (użyj domyślnej: admin)
Jeżeli pracujesz ze starszymi wersjami baz danych, użyj polecenia mongo (dla MongoDB 3.x, 4.x) zamiast mongosh (dla MongoDB 6.x, 7.x) z tymi samymi parametrami.
Status zestawu repliki można sprawdzić za pomocą odpowiedniego polecenia:
Jak widać, zestaw repliki (z domyślną nazwą rs0) jest uruchomiona i działa. Inne polecenia zestawu repliki można znaleźć w oficjalnej dokumentacji. Na przykład użyj operacji rs.conf(), jeśli chcesz zobaczyć konfiskaty zestawu repliki.
Historycznie, platforma aplikacyjna Cloudlest.Zone udostępniała stos oprogramowania MongoDB jako certyfikowany kontener bez żadnych dodatkowych opłat licencyjnych. Jednakże ze względu na zmiany licencji wersje MongoDB nowsze niż 3.6.8 i 4.0.2 nie mogą być swobodnie dystrybuowane i wymagają specjalnych umów.
Jeśli chcesz używać najnowszych wersji MongoDB na platformie Cloudles.Zone, automatycznie zostanie naliczona opłata licencyjna. Koszt utrzymania MongoDB możesz sprawdzić za pomocą kreatora topologii (zarówno przed instalacją, jak i dla istniejących środowisk). Po skonfigurowaniu topologii środowiska wybierz szacowany okres kosztów godzinowych/dziennych/miesięcznych i najedź kursorem na cenę w prawej części kreatora:
Cena licencji MongoDB jest skorelowana z liczbą dynamicznych cloudletów (limit skalowania pionowego) udostępnionych dla węzłów MongoDB. Na przykład: dla zestawu replik z 3 węzłami po 32 cloudlety każdy i kosztem licencji 11 $/miesiąc za 8 chmurek (co odpowiada 1 GB pamięci RAM):
3 * 32 = 96 (całkowity limit cloudletów dla MongoDB)
$11 / 8 = $1,375 (koszt licencji dla pojedynczego cloudleta)
96 * 1,375 = $132 (całkowity koszt licencji)
Koszt chmury (pamięć masowa, CPU, RAM, ruch) zależny będzie od rzeczywistego użycia i mieścił się będzie w zakresie 261 - 1253 zł netto.
Przedstawiona przykładowa wycena nie stanowi oferty handlowej. Zawsze sprawdzaj aktualne warunki cenowe w kreatorze usług na Coudlets.Zone, gdyż na ceny licencji wpływają bieżące kursy walut.
>>> Aktywuj konto na Cloudlets.Zone <<<
