Monitorowanie i zarządzanie operacjami MongoDB 4.0 z ClusterControl

Chociaż MongoDB spędził prawie dekadę na osiągnięciu dojrzałości (pierwsze wydanie, luty 2009), technologia ta jest nieco zagadką dla tych, którzy mają doświadczenie w konwencjonalnych środowiskach relacyjnych baz danych (RDBMS). Integracja NoSQL z istniejącym środowiskiem bez dogłębnej wiedzy może być trudna. Często zdarza się, że MongoDB działa wzdłuż MySQL lub innej bazy danych RDBMS.

Doświadczenie RDBMS może pomóc w zrozumieniu niektórych procesów, ale musisz wiedzieć, jak przełożyć swoją wiedzę na świat NoSQL. Zarządzanie środowiskami produkcyjnymi obejmuje takie kroki, jak wdrażanie, monitorowanie czasu pracy i wydajności, utrzymywanie bezpieczeństwa systemu, zarządzanie HA, tworzenie kopii zapasowych i tak dalej. Zarówno RDBMS, jak i NoSQL są realnymi opcjami, ale istnieją pewne krytyczne różnice między nimi, o których użytkownicy muszą pamiętać podczas wdrażania lub zarządzania MongoDB. Technologia zmienia się szybko i musimy się szybko dostosować.

Kiedy MongoDB nagle staje się twoją odpowiedzialnością, narzędzia do zarządzania gwarantują, że bazy danych MongoDB, którymi zarządzasz, są stabilne i bezpieczne. Korzystanie z predefiniowanych procesów i automatyzacji może nie tylko zaoszczędzić czas, ale także uchronić się przed typowymi błędami. Platforma zarządzania, która systematycznie zajmuje się wszystkimi różnymi aspektami cyklu życia bazy danych, będzie bardziej niezawodna niż łatanie razem kilku rozwiązań punktowych.

Sercem ClusterControl jest jego funkcja automatyzacji, która pozwala zautomatyzować zadania bazy danych, które musisz wykonywać regularnie, takie jak wdrażanie nowych baz danych, dodawanie i skalowanie nowych węzłów, zarządzanie kopiami zapasowymi, wysoka dostępność i przełączanie awaryjne, zmiany topologii, aktualizacje i inne. ClusterControl zapewnia zaprogramowane zabezpieczenia, zachowując integralność infrastruktury bazy danych. Co więcej, dzięki ClusterControl użytkownicy MongoDB nie są już uzależnieni od dostawcy; coś, co ostatnio było kwestionowane przez wielu. Możesz bezpłatnie wdrażać i importować różne wersje i dostawców MongoDB z jednej konsoli. Użytkownicy MongoDB często muszą używać kombinacji narzędzi i własnych skryptów, aby spełnić swoje wymagania, i dobrze jest wiedzieć, że można je znaleźć w jednym produkcie.

W tym artykule pokażemy, jak wdrożyć i zarządzać MongoDB 4.0 w sposób zautomatyzowany. Tutaj dowiesz się, jak to zrobić:

• Instalacja ClusterControl
• Proces wdrażania MongoDB
  • Wdróż nowy klaster
  • Importuj istniejący klaster
• Skalowanie MongoDB
  • Skalowanie odczytu (zestaw replik)
  • Skalowanie zapisu (sharding)
• Zabezpieczanie MongoDB
• Monitorowanie i trendy
• Tworzenie kopii zapasowych i odzyskiwanie

Instalacja ClusterControl

Aby rozpocząć korzystanie z ClusterControl, potrzebujesz dedykowanej maszyny wirtualnej lub hosta. W tym miejscu opisano wymagania dotyczące maszyny wirtualnej i obsługiwanych systemów. Podstawowa maszyna wirtualna może zaczynać się od 2 GB, 2 rdzeni i przestrzeni dyskowej 20 GB przestrzeni dyskowej, lokalnie lub w chmurze.

Instalacja jest dobrze opisana w dokumentacji, ale zasadniczo sprowadza się do pobrania skryptu instalacyjnego, który przeprowadzi Cię przez kreatora. Skrypt kreatora konfiguruje wewnętrzną bazę danych, instaluje niezbędne pakiety, repozytoria i wykonuje inne niezbędne poprawki. W przypadku blokad internetowych możesz skorzystać z procesu instalacji offline.

ClusterControl wymaga dostępu SSH do hostów bazy danych, a monitorowanie może być oparte na agentach lub bez agentów. Zarządzanie jest bez agentów.

Konfiguracja bezhasłowego SSH dla wszystkich węzłów docelowych (ClusterControl i wszystkich hostów bazy danych) wymaga uruchomienia następujących poleceń na serwerze ClusterControl:

$ ssh-keygen -t rsa # press enter on all prompts
$ ssh-copy-id -i ~/.ssh/id_rsa [ClusterControl IP address]
$ ssh-copy-id -i ~/.ssh/id_rsa [Database nodes IP address] # repeat this to all target database nodes

Wdrażanie i skalowanie MongoDB

Wdróż nowy klaster MongoDB 4.0

Po wejściu do interfejsu ClusterControl pierwszą rzeczą do zrobienia jest wdrożenie nowego klastra lub zaimportowanie istniejącego. Nowa wersja 1.7.1 wprowadza obsługę wersji 4.0. Możesz teraz wdrażać/importować i zarządzać MongoDB v4.0 z obsługą połączeń SSL.

Wybierz opcję „Wdróż klaster bazy danych” i postępuj zgodnie z wyświetlanymi instrukcjami.

Wybierając MongoDB, musimy określić Użytkownika, Klucz lub Hasło oraz port, aby połączyć się przez SSH z naszymi serwerami. Potrzebujemy również nazwy naszego nowego klastra i jeśli chcemy, aby ClusterControl zainstalował dla nas odpowiednie oprogramowanie i konfiguracje.

Po skonfigurowaniu informacji dostępowych SSH, musimy wprowadzić dane, aby uzyskać dostęp do naszej bazy danych. Możemy również określić, którego repozytorium użyć. Konfiguracja repozytorium jest ważnym aspektem dla serwerów baz danych i klastrów. Podczas wdrażania serwera/klastra bazy danych za pomocą ClusterControl możesz mieć trzy typy repozytorium:

• Korzystaj z repozytorium dostawców
  Udostępniaj oprogramowanie, konfigurując i korzystając z preferowanego repozytorium oprogramowania dostawcy bazy danych. ClusterControl zainstaluje najnowszą wersję tego, co jest dostarczane przez repozytorium dostawcy bazy danych.
• Nie konfiguruj repozytoriów dostawców
  Udostępniaj oprogramowanie za pomocą istniejącego repozytorium oprogramowania, które zostało już skonfigurowane w węzłach. Użytkownik musi ręcznie skonfigurować repozytorium oprogramowania w każdym węźle bazy danych, a ClusterControl użyje tego repozytorium do wdrożenia. Jest to dobre, jeśli węzły bazy danych działają bez połączeń internetowych.
• Użyj repozytoriów lustrzanych (utwórz nowe repozytorium)
  Utwórz i zdubluj repozytorium aktualnego dostawcy bazy danych, a następnie wdróż przy użyciu lokalnego repozytorium lustrzanego. Pozwala to na „zamrożenie” aktualnych wersji pakietów oprogramowania.

W kolejnym kroku musimy dodać nasze serwery do klastra, który zamierzamy utworzyć. Dodając nasze serwery możemy podać IP lub nazwę hosta. W tym drugim przypadku musimy mieć serwer DNS lub dodać nasze serwery MongoDB do lokalnego pliku rozpoznawania (/etc/hosts) naszego ClusterControl, aby mógł on rozwiązać odpowiednią nazwę, którą chcesz dodać. W naszym przykładzie wdrożymy zestaw ReplicaSet z trzema serwerami, jednym podstawowym i dwoma dodatkowymi. Możliwe jest wdrożenie tylko 2 węzłów MongoDB (bez arbitra). Zastrzeżeniem tego podejścia nie jest automatyczne przełączanie awaryjne, ponieważ konfiguracja dwuwęzłowa jest podatna na podział mózgu. Jeśli węzeł podstawowy ulegnie awarii, konieczne jest ręczne przełączanie awaryjne, aby drugi serwer stał się podstawowym. Automatyczne przełączanie awaryjne działa dobrze z 3 węzłami i więcej. Zaleca się, aby zestaw replik miał nieparzystą liczbę członków głosujących. Odporność na awarie dla zestawu replik to liczba członków, które mogą stać się niedostępne i nadal pozostawiać wystarczającą liczbę członków w zestawie, aby wybrać podstawowy. Tolerancja błędów dla trzech członków wynosi jeden, dla pięciu to dwa itd.

Na tej samej stronie możesz wybierać spośród różnych wersji MongoDB:

Kiedy wszystko jest ustawione, naciśnij przycisk wdrażania. Możesz monitorować stan tworzenia naszego nowego klastra z monitora aktywności ClusterControl. Po zakończeniu zadania możemy zobaczyć nasz klaster na głównym ekranie ClusterControl oraz w widoku topologii.

Jak widać na obrazku, po utworzeniu naszego klastra możemy wykonać na nim kilka zadań, takich jak konwersja zestawu replik na shard lub dodanie węzłów do klastra.

Importuj nowy klaster

Mamy również możliwość zarządzania istniejącym klastrem poprzez importowanie go do ClusterControl. Takie środowisko można stworzyć za pomocą ClusterControl lub innych metod, takich jak instalacja dockera.

Najpierw musimy wprowadzić poświadczenia dostępu SSH do naszych serwerów. Następnie wprowadzamy poświadczenia dostępu do naszej bazy danych, katalogu danych serwera i wersji. Dodajemy węzły według adresu IP lub nazwy hosta w taki sam sposób, jak podczas wdrażania, i naciskamy Importuj. Po zakończeniu zadania jesteśmy gotowi do zarządzania naszym klastrem z ClusterControl.

Skalowanie MongoDB

Jednym z fundamentów MongoDB jest to, że jest on zbudowany z myślą o wysokiej dostępności i skalowaniu. Skalowanie można wykonać albo w pionie, dodając więcej zasobów do serwera, albo w poziomie z większą liczbą węzłów. Skalowanie poziome jest tym, w czym MongoDB jest dobry i nie jest niczym więcej niż rozłożeniem obciążenia na wiele maszyn. W efekcie korzystamy z wielu niedrogich standardowych zestawów sprzętowych, zamiast uaktualniać do droższego serwera o wysokiej wydajności. MongoDB oferuje skalowanie zarówno odczytu, jak i zapisu, a my odkryjemy dla Ciebie różnice między tymi dwiema strategiami. To, czy wybrać skalowanie odczytu, czy zapisu, wszystko zależy od obciążenia aplikacji:jeśli Twoja aplikacja ma tendencję do czytania częściej niż zapisuje dane, prawdopodobnie będziesz chciał skorzystać z możliwości skalowania odczytu MongoDB.

Dzięki ClusterControl dodanie większej liczby serwerów do klastra jest łatwym krokiem. Możesz to zrobić z GUI lub CLI. Dla bardziej zaawansowanych użytkowników możesz użyć ClusterControl Developer Studio i napisać warunek bazowy zasobów, aby rozwinąć swój klaster w poziomie.

Sharding

Rozwiązanie do fragmentowania MongoDB jest podobne do istniejących struktur fragmentowania dla innych głównych rozwiązań baz danych. Wykorzystuje typowe rozwiązanie wyszukiwania, w którym fragmentacja jest zdefiniowana w kluczu fragmentu, a zakresy są przechowywane w bazie danych konfiguracji. MongoDB współpracuje z trzema komponentami, aby znaleźć odpowiedni fragment danych. Typowe środowisko sharded MongoDB wygląda tak:

Pierwszym użytym komponentem jest router shard zwany mongos. Wszystkie operacje odczytu i zapisu muszą być wysyłane do routera fragmentów, dzięki czemu wszystkie fragmenty działają jako pojedyncza baza danych dla aplikacji klienckiej. Router odłamkowy skieruje zapytania do odpowiednich odłamków, konsultując się z serwerem konfiguracyjnym.

Zarządzanie fragmentami jest naprawdę łatwe w MongoDB. Możesz dodawać i usuwać fragmenty online, a router fragmentów MongoDB automatycznie dostosuje się do tego, co mu powiesz. Jeśli chcesz dowiedzieć się więcej o tym, jak najlepiej zarządzać odłamkami, przeczytaj nasz wpis na blogu o zarządzaniu odłamkami MongoDB.

Zabezpieczanie MongoDB

MongoDB ma bardzo małe zabezpieczenia po wyjęciu z pudełka:na przykład uwierzytelnianie jest domyślnie wyłączone. Innymi słowy:domyślnie każdy ma prawa roota do dowolnej bazy danych. Jedną ze zmian zastosowanych przez MongoDB w celu ograniczenia zagrożeń była zmiana domyślnego wiązania na 127.0.0.1. Zapobiega to powiązaniu go z zewnętrznym adresem IP, ale naturalnie zostanie to cofnięte przez większość osób, które go zainstalują. ClusterControl usuwa błędy ludzkie i zapewnia dostęp do zestawu funkcji bezpieczeństwa, aby automatycznie chronić Twoje bazy danych przed włamaniami i innymi zagrożeniami. Wcześniej opublikowaliśmy krótki film ze wskazówkami dotyczącymi bezpieczeństwa.

Nowa wersja ClusterControl oferuje obsługę SSL dla połączeń MongoDB. Włączenie SSL dodaje kolejny poziom bezpieczeństwa komunikacji między aplikacjami (w tym ClusterControl) a bazą danych. Klienci MongoDB otwierają zaszyfrowane połączenia z serwerami baz danych i weryfikują tożsamość tych serwerów przed przesłaniem jakichkolwiek poufnych informacji.

Aby włączyć połączenie SSL, musisz użyć najnowszego klienta s9s. Możesz go zainstalować za pomocą

wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
chmod 755 install-s9s-tools.sh
./install-s9s-tools.sh

Lub postępuj zgodnie z innymi możliwymi metodami instalacji opisanymi tutaj.

Po zainstalowaniu narzędzi s9s (min. wersja 1.7-93.1) możesz użyć flagi --enable-ssl, aby włączyć połączenie SSL.

Przykład poniżej:

[[email protected] ~]# s9s cluster --cluster-id=3 --enable-ssl --log
This is an RPC V2 job (a job created through RPC V2).
The job owner is 'admin'.
Accessing '/.runtime/jobs/jobExecutor' to execute...
Access ok.
Stopping the cluster
node1:27017: Node is already stopped by the user.
node2:27017: Node is already stopped by the user.
node3:27017: Node is already stopped by the user.
Checking/generating (expire 1000 days) server and CA certificate.
node1:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node1:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node1:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node1:/etc/mongod.conf'.
node1:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
node2:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node2:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node2:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node2:/etc/mongod.conf'.
node2:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
node3:27017: setting up SSL as required way of connection.
Using certificate 'mongodb/cluster_3/server'
node3:27017: installed /etc/ssl/mongodb/cluster_3/server.crt, /etc/ssl/mongodb/cluster_3/server.key and /etc/ssl/mongodb/cluster_3/server_ca.crt
node3:27017: Deploying client certificate 'mongodb/cluster_3/client'
Writing file 'node3:/etc/mongod.conf'.
node3:27017: /etc/mongod.conf [mongod] set: ssl_cert, ssl_key and ssl_ca values.
Starting the cluster
node3:27017: Doing some preparation for starting the node.
node3:27017: Disable transparent huge page and its defrag according to mongo suggestions.
node3:27017: Checking file permissions and ownership.
node3:27017: Starting mongod MongoDb server with command:
ulimit -u 32000 -n 32000 &&  runuser -s /bin/bash mongod '-c mongod -f /etc/mongod.conf'
node3:27017: Verifing that 'mongod' process is started.
SSL setup done.

ClusterControl wykona wszystkie niezbędne kroki, w tym utworzenie certyfikacji na wszystkich węzłach klastra. Takie certyfikaty można przechowywać później w zakładce Zarządzanie kluczami.

Monitorowanie

Podczas pracy z systemami baz danych powinieneś mieć możliwość ich monitorowania. Umożliwi to identyfikowanie trendów, planowanie aktualizacji lub ulepszeń lub skuteczne reagowanie na wszelkie problemy lub błędy, które mogą się pojawić.

Nowy ClusterControl 1.7.1 dodaje monitorowanie w wysokiej rozdzielczości dla MongoDB. Używa Prometheusa jako magazynu danych z językiem zapytań PromQL. Lista pulpitów nawigacyjnych obejmuje MongoDB Server, MongoDB ReplicaSet, Przegląd systemu i Pulpity przeglądowe klastra. ClusterControl instaluje agentów Prometheus, konfiguruje metryki i utrzymuje dostęp do konfiguracji eksporterów Prometheus za pośrednictwem swojego GUI, dzięki czemu można lepiej zarządzać konfiguracją parametrów, takich jak flagi zbierające dla eksporterów (Prometheus). Szczegółowo opisaliśmy, co można ostatnio monitorować w artykule Jak monitorować MongoDB za pomocą Prometheus i ClusterControl.

Alarmy

Jako operator bazy danych musimy być informowani o każdej krytycznej sytuacji w naszej bazie danych. Trzy główne metody uzyskiwania alertu w ClusterControl obejmują:

• powiadomienia e-mail
• integracje
• doradcy

Możesz ustawić powiadomienia e-mail na poziomie użytkownika. Przejdź do Ustawienia> Powiadomienia e-mail. Gdzie możesz wybrać między krytycznością a rodzajem wysyłanego alertu.

Kolejną metodą jest skorzystanie z usług integracyjnych. Ma to na celu przekazanie określonej kategorii wydarzeń do innych usług, takich jak bilety ServiceNow, Slack, PagerDuty itp., dzięki czemu możesz tworzyć zaawansowane metody powiadamiania i integracje w swojej organizacji.

Ostatnim z nich jest włączenie wyrafinowanej analizy metryk w sekcji Advisor, gdzie można budować inteligentne sprawdzenia i wyzwalacze. Przykładem może być przewidywanie wykorzystania miejsca na dysku lub skalowanie klastra poprzez dodawanie węzłów, gdy obciążenie osiągnie ustalony poziom.

Kopia zapasowa i odzyskiwanie

Teraz, gdy masz już skonfigurowaną i uruchomioną replikę MongoDB oraz masz monitoring, nadszedł czas na kolejny krok:upewnij się, że masz kopię zapasową swoich danych.

ClusterControl zapewnia interfejs do zarządzania kopiami zapasowymi MongoDB z obsługą harmonogramów i kreatywnych raportów. Daje dwie opcje metod tworzenia kopii zapasowych.

• Mongodump
• Spójna kopia zapasowa Mongodb

Mongodump zrzuca wszystkie dane w formacie binarnym JSON (BSON) do określonej lokalizacji. Mongorestore może później użyć plików BSON do przywrócenia bazy danych. Spójna kopia zapasowa ClusterControl MongoDB obejmuje transakcje z oploga, które były wykonywane podczas tworzenia kopii zapasowej.

Dobra strategia tworzenia kopii zapasowych jest krytyczną częścią każdego systemu zarządzania bazą danych. ClusterControl oferuje wiele opcji tworzenia kopii zapasowych i odzyskiwania/przywracania.

Możliwość konfiguracji przechowywania kopii zapasowych ClusterControl; możesz zachować kopię zapasową przez dowolny okres czasu lub nigdy nie usuwać kopii zapasowych. Szyfrowanie AES256 służy do zabezpieczenia kopii zapasowych przed nieuczciwymi elementami. W celu szybkiego przywrócenia kopii zapasowych można przywrócić bezpośrednio do klastra kopii zapasowych - ClusterControl obsługuje pełny proces przywracania od uruchomienia do odzyskiwania klastra, usuwając z tego procesu podatne na błędy ręczne kroki.