Monitorowanie i zabezpieczanie MongoDB za pomocą ClusterControl Advisors

Zarządzanie operacjami baz danych składa się w 80% z odczytywania i interpretowania Twoich systemów monitorowania. Setki metryk można interpretować i łączyć na różne sposoby, aby zapewnić głęboki wgląd w systemy baz danych i sposoby ich optymalizacji. W przypadku korzystania z wielu systemów baz danych monitorowanie tych systemów może stać się dość uciążliwym obowiązkiem. Jeśli interpretacja i łączenie metryk zajmuje dużo czasu, czy nie byłoby wspaniale, gdyby można było to w jakiś sposób zautomatyzować?

Właśnie dlatego stworzyliśmy doradców baz danych w ClusterControl:małe skrypty, które mogą interpretować i łączyć metryki za Ciebie i udzielać porad, gdy ma to zastosowanie. Dla MySQL stworzyliśmy obszerną bibliotekę najczęściej używanych kontroli monitorowania MySQL. Ale także dla MongoDB mamy do Twojej dyspozycji szeroką bibliotekę doradców. W tym poście wybraliśmy dla Ciebie dziewięć najważniejszych. Opiszemy szczegółowo każdy z nich.

Dziewięciu doradców MongoDB, których omówimy w tym poście na blogu, to:

• Sprawdź opcje montowania dysku
• Sprawdź Numę
• Procent blokady kolekcji (MMAP)
• Opóźnienie replikacji
• Okno replikacji
• Bazy danych i kolekcje bez fragmentów (tylko klaster z fragmentami)
• Sprawdzenie włączonej uwierzytelniania
• Sprawdzenie poprawności uwierzytelniania/autoryzacji
• Wykrywanie błędów (nowy doradca)

Doradca opcji montażu na dysku

Bardzo ważne jest, aby Twoje dyski były zamontowane w najbardziej optymalny sposób. Dzięki doradcy ds. opcji montowania dysku ClusterControl codziennie dokładniej przyglądamy się Twojemu dyskowi z danymi. W tym poradniku zbadamy używany system plików, opcje montowania i ustawienia harmonogramu io systemu operacyjnego.

Sprawdzamy, czy Twoje dyski zostały zamontowane za pomocą noatime i nodiratime. Ustawienie ich zmniejszy wydajność dysków, ponieważ przy każdym dostępie do pliku lub katalogu czas dostępu musi być zapisany na dysku. Ponieważ dzieje się to stale w bazach danych, jest to dobre ustawienie wydajności, a także zwiększa trwałość dysków SSD.

W przypadku systemów plików zalecamy korzystanie z nowoczesnych systemów plików, takich jak xfs, zfs, ext4 lub btrfs. Te systemy plików są tworzone z myślą o wydajności. Zaleca się, aby harmonogram io był na nie lub termin. Termin od lat jest domyślnym rozwiązaniem dla baz danych, ale dzięki szybszej pamięci masowej, takiej jak dyski SSD, nie harmonogram ma obecnie więcej sensu.

Doradca Numa Check

W przypadku MongoDB włączamy nasze NUMA sprawdź doradcę. Ten doradca sprawdzi, czy NUMA (Non-Uniform Access Memory) została włączona w twoim systemie, a jeśli tak jest, aby ją wyłączyć.

Gdy włączona jest funkcja Non-Uniform Access Memory, procesor serwera może bezpośrednio adresować tylko własną pamięć, a nie inne procesory w maszynie. W ten sposób procesor może alokować pamięć tylko z własnego obszaru pamięci, a alokowanie wszystkiego, co jest w nadmiarze, spowoduje użycie wymiany. Ta architektura ma znaczną przewagę wydajności w aplikacjach wieloprocesorowych, które przydzielają wszystkie procesory, ale ponieważ MongoDB nie jest aplikacją wieloprocesorową, znacznie zmniejszy wydajność i może prowadzić do ogromnego zużycia wymiany.

Procent blokady kolekcji (MMAP)

Jako MMAP to system przechowywania oparty na plikach, nie obsługuje blokowania na poziomie dokumentu, jak w WiredTiger i RocksDB. Zamiast tego najniższy poziom blokowania dla MMAP jest kolekcja zamków. Oznacza to, że wszelkie zapisy do kolekcji (wstawianie, aktualizowanie lub usuwanie) zablokują całą kolekcję. Jeśli procent blokad staje się zbyt wysoki, oznacza to, że masz problemy z rywalizacją w kolekcji. Jeśli nie zostanie odpowiednio zaadresowany, może to spowodować zatrzymanie przepustowości zapisu. Dlatego bardzo pomocne jest posiadanie ostrzeżenia doradcy z góry.

Doradca opóźnień replikacji MongoDB

Jeśli skalujesz MongoDB pod kątem odczytów przez wtórne, bardzo ważne jest, aby mieć na oku opóźnienie replikacji. Sterowniki klienta MongoDB będą używać tylko części pomocniczych, które nie pozostają zbyt daleko w tyle, w przeciwnym razie możesz ryzykować udostępnianie nieaktualnych danych.

Wewnątrz MongoDB baza podstawowa będzie śledzić stan replikacji jej drugorzędnych. Doradca pobierze informacje o replikacji i strzeże opóźnienia replikacji. Jeśli opóźnienie stanie się zbyt duże, wyśle ​​ostrzeżenie lub krytyczny komunikat o stanie.

Doradca okna replikacji MongoDB

Oprócz opóźnienia replikacji ważnym wskaźnikiem do obserwacji jest okno replikacji. Oplog MongoDB to pojedyncza kolekcja, która została ograniczona do (wstępnie ustawionego) rozmiaru. Gdy oplog dobiegnie końca i trzeba będzie zapisać nową transakcję, usunie najstarszą transakcję, aby zrobić miejsce na nową transakcję. Okno replikacji odzwierciedla liczbę sekund między najstarszą a najnowszą transakcją w oplogu.

Ta metryka jest bardzo ważna, ponieważ musisz wiedzieć, jak długo możesz usunąć element pomocniczy z zestawu replik, zanim nie będzie już w stanie dogonić wzorca z powodu zbyt dużego opóźnienia w replikacji. Również jeśli drugorzędny zaczyna pozostawać w tyle, dobrze byłoby wiedzieć, jak długo możemy to tolerować, zanim drugorzędny nie będzie już w stanie nadrobić zaległości.

W powłoce MongoDB dostępna jest funkcja obliczania okna replikacji. Ten doradca w ClusterControl wykorzystuje tę funkcję do wykonania tych samych obliczeń. Korzyścią byłoby to, że teraz możesz zostać ostrzeżony o zbyt krótkim oknie replikacji.

MongoDB Un-sharded Databases and Collections Advisor

W klastrze MongoDB podzielonego na fragmenty wszystkie bazy danych i kolekcje nie podzielone na fragmenty są przypisywane do domyślnego fragmentu podstawowego przez router fragmentu MongoDB. Ten podstawowy fragment może się różnić w zależności od bazy danych i kolekcji, ale ogólnie byłby to fragment z największą dostępną przestrzenią dyskową.

Posiadanie bazy danych lub kolekcji bez fragmentów nie stanowi natychmiastowego zagrożenia dla klastra. Jeśli jednak aplikacja lub użytkownik zacznie zapisywać duże ilości danych w jednym z nich, fragment podstawowy może szybko się zapełnić i spowodować awarię tego fragmentu. Ponieważ baza danych lub kolekcja nie jest podzielona na fragmenty, nie będzie mogła korzystać z innych fragmentów.

Z tego powodu stworzyliśmy doradcę, który temu zapobiegnie. Doradca przeskanuje wszystkie bazy danych i kolekcje oraz ostrzeże Cię, jeśli nie zostały one podzielone.

Sprawdzenie włączonej autoryzacji

Bez włączenia uwierzytelniania w MongoDB każdy logujący się użytkownik będzie traktowany jako administrator. Jest to poważne ryzyko, ponieważ zwykle zadania administracyjne, takie jak tworzenie użytkowników lub tworzenie kopii zapasowych, są teraz dostępne dla każdego. W połączeniu z ujawnionymi serwerami MongoDB doprowadziło to do niedawnych ataków na okup MongoDB, podczas gdy proste włączenie uwierzytelniania zapobiegłoby większości takich przypadków.

Wdrożyliśmy doradcę, który weryfikuje, czy Twoje serwery MongoDB mają włączone uwierzytelnianie. Można to zrobić jawnie, ustawiając to w konfiguracji, lub niejawnie, włączając plik klucza replikacji. Jeśli ten doradca nie wykryje, że uwierzytelnianie zostało włączone, należy natychmiast podjąć odpowiednie działania, ponieważ serwer jest podatny na włamanie.

Sprawdzenie poprawności uwierzytelniania/autoryzacji

Oprócz doradcy z włączonym uwierzytelnianiem zbudowaliśmy również doradcę, który przeprowadza kontrolę poprawności zarówno uwierzytelniania, jak i autoryzacji w MongoDB.

W MongoDB uwierzytelnianie i autoryzacja nie są umieszczane w centralnej lokalizacji, ale są wykonywane i przechowywane na poziomie bazy danych. Zwykle użytkownicy będą łączyć się z bazą danych, uwierzytelniając się w bazie danych, z której zamierzają korzystać. Jednak przy poprawnych dotacjach możliwe jest również uwierzytelnianie w innych (niepowiązanych) bazach danych i nadal korzystanie z innej bazy danych. Zwykle jest to w porządku, chyba że użytkownik ma nadmierne uprawnienia (takie jak rola administratora) do innej bazy danych.

W tym doradcy weryfikujemy, czy te nadmierne role są obecne i czy mogą stanowić zagrożenie. Jednocześnie sprawdzamy, czy hasła są słabe i łatwe do odgadnięcia.

Wykrywanie błędów (nowy Doradca)

W MongoDB każdy napotkany błąd zostanie zliczony lub zarejestrowany. W MongoDB istnieje wiele różnych możliwych błędów:potwierdzenia użytkownika, potwierdzenia regularne, ostrzeżenia, a nawet wyjątki serwera wewnętrznego. Jeśli występują trendy w tych błędach, prawdopodobnie jest to błędna konfiguracja lub problem z aplikacją.

Ten doradca przyjrzy się statystykom błędów MongoDB (asert) i zrozumie to. Interpretujemy znalezione trendy i doradzamy, jak zmniejszyć błędy w środowisku MongoDB!