Wprowadzenie do serwera Percona dla MongoDB 4.2

Wybierając technologię baz danych NoSQL należy wziąć pod uwagę ważne kwestie, takie jak wydajność, odporność, niezawodność i bezpieczeństwo. Te kluczowe czynniki również powinny być dostosowane do osiągania celów biznesowych, przynajmniej jeśli chodzi o bazę danych.

Wiele technologii weszło w grę w celu poprawy tych aspektów i wskazane jest, aby organizacja ulepszyła najistotniejsze opcje i spróbowała zintegrować je z systemami baz danych.

Nowe technologie powinny zapewniać maksymalną wydajność, aby poprawić osiąganie celów biznesowych przy przystępnych kosztach operacyjnych, ale z bardziej manipulacyjnymi funkcjami, takimi jak wykrywanie błędów i systemy ostrzegania.

W tym blogu omówimy wersję MongoDB Percona i jak rozszerza ona możliwości MongoDB na różne sposoby.

Co to jest Percona Server dla MongoDB?

Aby baza danych działała dobrze, musi istnieć optymalnie ustanowiony serwer bazowy, który usprawni transakcje odczytu i zapisu. Percona Server for MongoDB jest darmowym zamiennikiem typu drop-in dla MongoDB Community Edition, ale z dodatkową funkcjonalnością klasy korporacyjnej. Został zaprojektowany z kilkoma znaczącymi ulepszeniami domyślnej konfiguracji serwera MongoDB.

Zapewnia wysoką wydajność, ulepszone zabezpieczenia i niezawodność w celu uzyskania optymalnej wydajności przy zmniejszonych nakładach na relacje z dostawcami oprogramowania zastrzeżonego.

Serwer Percona dla najważniejszych funkcji MongoDB

MongoDB Community Edition jest rdzeniem serwera Percona, biorąc pod uwagę, że zawiera już ważne funkcje, takie jak elastyczny schemat, transakcje rozproszone, znajomość dokumentów JSON i natywna wysoka dostępność. Poza tym Percona Server dla MongoDB integruje następujące istotne funkcje, które umożliwiają spełnienie aspektów, o których wspomnieliśmy powyżej:

• Gorące kopie zapasowe
• Szyfrowanie danych w spoczynku
• Rejestrowanie audytu
• Silnik pamięci Percona
• Zewnętrzne uwierzytelnianie LDAP za pomocą SASL
• Integracja z HashiCorp Vault
• Ulepszone profilowanie zapytań

Gorące kopie zapasowe

Serwer Percona dla MongoDB tworzy fizyczną kopię zapasową danych na uruchomionym serwerze w tle bez zauważalnego pogorszenia działania. Można to osiągnąć, uruchamiając polecenie createBackup jako administrator w bazie danych administratora i określając katalog kopii zapasowej.

> use admin

switched to db admin

> db.runCommand({createBackup: 1, backupDir: "/my/backup/data/path"})

{ "ok" : 1 }

Kiedy otrzymasz { "ok" :1 }, kopia zapasowa się powiodła. W przeciwnym razie, jeśli na przykład podasz pustą ścieżkę katalogu kopii zapasowej, możesz otrzymać odpowiedź o błędzie, np.:

{ "ok" : 0, "errmsg" : "Destination path must be absolute" }

Przywrócenie kopii zapasowej wymaga najpierw zatrzymania instancji mongod, wyczyszczenia katalogu danych, skopiowania plików z katalogu, a następnie ponownego uruchomienia usługi mongod. Można to zrobić, uruchamiając poniższe polecenie

$ service mongod stop && rm -rf /var/lib/mongodb/* && cp --recursive /my/backup/data/path /var/lib/mongodb/ && service mongod start

Możesz również przechowywać kopię zapasową w formacie archiwum, jeśli używasz serwera Percona dla MongoDB 4.2.1-1

> use admin

> db.runCommand({createBackup: 1, archive: "path/to/archive.tar" })

Możesz także tworzyć kopie zapasowe bezpośrednio w AWS S3 przy użyciu ustawień domyślnych lub z większą liczbą konfiguracji. W przypadku domyślnej kopii zapasowej zasobnika S3:

> db.runCommand({createBackup:1,  s3:{bucket:"backup", ścieżka:"newBackup"}})

Szyfrowanie danych w spoczynku

MongoDB w wersji 3.2 wprowadziła szyfrowanie danych w spoczynku dla silnika pamięci masowej WiredTiger w celu zapewnienia, że ​​pliki danych mogą być odszyfrowywane i odczytywane tylko przez strony posiadające klucz deszyfrujący. Szyfrowanie danych w spoczynku w Percona Server dla MongoDB zostało wprowadzone w wersji 3.6, aby iść w parze z szyfrowaniem danych w spoczynku w MongoDB. Jednak najnowsza wersja nie obejmuje obsługi usług zarządzania kluczami Amazon AWS i KIMP.

Szyfrowanie można również zastosować do plików przywracania, gdy dane w spoczynku są włączone. Percona Server dla MongoDB używa opcji szyfrowania CipherMode z 2 selektywnymi trybami szyfrowania:

1. AES256-CBC (domyślny tryb szyfrowania)
2. AES256-GCM

Możesz zaszyfrować dane za pomocą poniższego polecenia

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Używamy opcji --ecryptionKeyFile, aby określić ścieżkę do pliku zawierającego klucz szyfrowania.

$ mongod ... --enableEncryption --encryptionKeyFile <fileName>

Rejestrowanie audytu

W przypadku każdego systemu baz danych administratorzy mają mandat do śledzenia prowadzonych działań. W Percona Server for MongoDB, gdy audyt jest włączony, serwer generuje plik dziennika audytu, który zawiera informacje o różnych zdarzeniach użytkownika, takich jak autoryzacja i uwierzytelnianie. Jednak uruchamiając serwer z włączonym audytem, ​​logi nie będą wyświetlane dynamicznie w czasie wykonywania.

Logowanie audytowe w MongoDB Community Edition może przyjmować dwa formaty danych, to znaczy JSON i BSON. Jednak w przypadku Percona Server for MongoDB rejestrowanie kontrolne jest ograniczone tylko do pliku JSON. Serwer rejestruje również tylko ważne polecenia w przeciwieństwie do MongoDB, która rejestruje wszystko. Ponieważ procedura filtrowania w Perconie jest tak niejasna pod względem składni filtrowania, włączenie dziennika audytu bez filtrowania dałoby więcej wpisów, z których można by zawęzić do własnych specyfikacji.

Silnik pamięci Percona

Jest to specjalna konfiguracja mechanizmu przechowywania danych WiredTiger, która nie przechowuje danych użytkownika na dysku. Dane w pełni znajdują się i są łatwo dostępne w pamięci głównej, z wyjątkiem danych diagnostycznych, które są zapisywane na dysku. Sprawia to, że przetwarzanie danych jest znacznie szybsze, ale należy wziąć pod uwagę, że należy zapewnić wystarczającą ilość pamięci do przechowywania zestawu danych, a serwer nie powinien zostać zamknięty. Za pomocą polecenia --storageEngine można wybrać silnik pamięci masowej. Dane utworzone dla jednego aparatu magazynu nie mogą być zgodne z innymi silnikami magazynu, ponieważ każdy aparat magazynu ma swój własny model danych. Na przykład, aby wybrać silnik pamięci masowej. Najpierw zatrzymujesz każdą działającą instancję mongod, a następnie wydajesz polecenia:

$ service mongod stop

$ mongod --storageEngine inMemory --dbpath <newDataDir>

Jeśli masz już jakieś dane w domyślnej edycji MongoDB Community i chcesz przeprowadzić migrację do Percona Memory Engine, po prostu użyj narzędzi mongodumb i mongorestore, wydając polecenie:

$ mongodump --out <dumpDir>

$ service mongod stop

$ rm -rf /var/lib/mongodb/*

$ sed -i '/engine: .*inMemory/s/#//g' /etc/mongod.conf

$ service mongod start

$ mongorestore <dumpDir>

Zewnętrzne uwierzytelnianie LDAP za pomocą SASL

Za każdym razem, gdy klienci wysyłają żądanie odczytu lub zapisu do instancji MongoDB mongod, muszą najpierw uwierzytelnić się w bazie danych użytkowników serwera MongoDB. Uwierzytelnianie zewnętrzne umożliwia serwerowi MongoDB weryfikację poświadczeń klienta (nazwy użytkownika i hasła) względem oddzielnej usługi. Architektura uwierzytelniania zewnętrznego obejmuje:

1. Serwer LDAP, który zdalnie przechowuje wszystkie dane uwierzytelniające użytkownika
2. Demon SASL, który jest używany jako lokalny serwer proxy MongoDB dla zdalnej usługi LDAP.
3. Biblioteka SASL:tworzy niezbędne dane uwierzytelniające dla klienta i serwera MongoDB.

Sekwencja sesji uwierzytelniania

• Klient łączy się z działającą instancją mongod i tworzy żądanie uwierzytelnienia PLAIN przy użyciu biblioteki SASL.
• Żądanie uwierzytelnienia jest następnie wysyłane do serwera jako specjalne polecenie Mongo, które jest następnie odbierane przez serwer mongod wraz z ładunkiem żądania.
• Serwer tworzy kilka sesji SASL uzyskanych z poświadczeń klienta, używając własnego odniesienia do biblioteki SASL.
• Serwer mongod przekazuje ładunek autoryzacji do biblioteki SASL, która przekazuje go demonowi saslauthd. Demon przekazuje go do LDAP i czeka na odpowiedź TAK lub NIE na żądanie uwierzytelnienia, sprawdzając, czy użytkownik istnieje, a podane hasło jest poprawne.
• Saslauthd przekazuje tę odpowiedź do serwera mongod przez bibliotekę SASL, która następnie odpowiednio uwierzytelnia lub odrzuca żądanie.

 Oto ilustracja tego procesu:

Aby dodać użytkownika zewnętrznego do serwera mongod:

> db.getSiblingDB("$external").createUser( {user : username, roles: [ {role: "read", db: "test"} ]} );

Użytkownicy zewnętrzni nie mogą mieć przypisanych ról w bazie danych administratora.

Integracja z HashiCorp Vault

HashCorp Vault to produkt przeznaczony do zarządzania tajemnicami i ochrony poufnych danych poprzez bezpieczne przechowywanie i ścisłą kontrolę dostępu do poufnych informacji. W poprzedniej wersji Percony dane w spoczynku klucza szyfrowania były przechowywane lokalnie na serwerze w pliku klucza. Integracja z HashCorp Vault znacznie lepiej zabezpiecza klucz szyfrowania.

Ulepszone profilowanie zapytań

Profilowanie ma wpływ na pogorszenie wydajności bazy danych, zwłaszcza gdy jest wysyłanych tak wiele zapytań. Serwer Percona dla MongoDB pomaga ograniczyć liczbę zapytań zbieranych przez profiler bazy danych, a tym samym zmniejsza jego wpływ na wydajność.

Wnioski

Percona Server dla MongoDB to ulepszona baza danych o otwartym kodzie źródłowym i wysoce skalowalna, która może działać jako kompatybilny zamiennik dla MongoDB Community Edition, ale z podobną składnią i konfiguracją. Zwiększa rozległe bezpieczeństwo danych, zwłaszcza danych w stanie spoczynku, i poprawioną wydajność bazy danych dzięki zapewnieniu silnika Percona Server, ograniczając między innymi szybkość profilowania.

Percona Server dla MongoDB jest w pełni obsługiwany przez ClusterControl jako opcja wdrożenia.