Monitorování a zabezpečení MongoDB pomocí ClusterControl Advisors

Správa operací databáze sestává z 80 % čtení a interpretace vašich monitorovacích systémů. Stovky metrik lze interpretovat a různě kombinovat, abyste získali hluboký vhled do vašich databázových systémů a jak je optimalizovat. Při provozu více databázových systémů může být sledování těchto systémů docela oříšek. Pokud interpretace a kombinace metrik zabere hodně času, nebylo by skvělé, kdyby to šlo nějakým způsobem zautomatizovat?

Proto jsme v ClusterControl vytvořili databázové poradce:malé skripty, které za vás dokážou interpretovat a kombinovat metriky a případně vám poskytnout rady. Pro MySQL jsme vytvořili rozsáhlou knihovnu nejčastěji používaných kontrol monitorování MySQL. Ale také pro MongoDB máme k dispozici širokou knihovnu poradců. Pro tento blogový příspěvek jsme pro vás vybrali devět nejdůležitějších. Každý z nich podrobně popíšeme.

Devět MongoDB poradců, kterým se budeme věnovat v tomto blogovém příspěvku, je:

• Kontrola možností připojení k disku
• Kontrola numa
• Procento uzamčení sbírky (MMAP)
• Prodleva replikace
• Okno replikace
• Nesdílené databáze a kolekce (pouze sdílený cluster)
• Kontrola povoleného ověřování
• Autentizace/autorizace Zdravá kontrola
• Detekce chyb (nový poradce)

Poradce pro možnosti připojení disku

Je velmi důležité mít disky namontované tím nejoptimálnějším způsobem. S poradcem možností připojení disku ClusterControl se každý den podrobněji podíváme na váš datový disk. V tomto poradci prozkoumáme použitý souborový systém, možnosti připojení a nastavení plánovače io operačního systému.

Zkontrolujeme, zda byly vaše disky připojeny pomocí noatime a nodiratime. Jejich nastavením se sníží výkon disků, protože při každém přístupu k souboru nebo adresáři musí být čas přístupu zapsán na disk. Protože se to v databázích děje nepřetržitě, je to dobré nastavení výkonu a také zvyšuje odolnost vašich SSD.

Pro souborové systémy doporučujeme používat moderní souborové systémy jako xfs, zfs, ext4 nebo btrfs. Tyto systémy souborů jsou vytvářeny s ohledem na výkon. Plánovač io se doporučuje být buď v režimu noop nebo termín. Termín je výchozí nastavení pro databáze už roky, ale díky rychlejšímu úložišti, jako jsou SSD, noop Plánovač dává v dnešní době větší smysl.

Poradce Numa Check

Pro MongoDB povolujeme naše NUMA zkontrolovat poradce. Tento poradce zkontroluje, zda NUMA (Non-Uniform Access Memory) byla ve vašem systému povolena, a pokud je to váš případ, vypněte ji.

Když byla povolena paměť s nejednotným přístupem, CPU serveru je schopno adresovat přímo svou vlastní paměť a ne ostatní CPU ve stroji. Tímto způsobem je CPU schopen alokovat paměť pouze ze svého vlastního paměťového prostoru a alokace čehokoli navíc bude mít za následek využití swapu. Tato architektura má silnou výkonnostní výhodu u víceprocesorových aplikací, které alokují všechny CPU, ale protože MongoDB není víceprocesorová aplikace, výrazně sníží výkon a může vést k obrovskému využití swapu.

Procento uzamčení sbírky (MMAP)

Jako MMAP je souborový úložný systém, nepodporuje zamykání na úrovni dokumentu, jak je uvedeno v WiredTiger a RocksDB. Místo toho nejnižší úroveň zamykání pro MMAP je sběr zámků. To znamená, že jakékoli zápisy do kolekce (vložení, aktualizace nebo odstranění) uzamknou celou kolekci. Pokud je procento zámků příliš vysoké, znamená to, že máte v kolekci problémy se spory. Když není správně adresováno, může to způsobit zastavení vaší propustnosti zápisu. Proto je velmi užitečné mít poradce, který vás předem upozorní.

Poradce pro zpoždění replikace MongoDB

Pokud rozšiřujete MongoDB pro čtení prostřednictvím sekundárních souborů, je velmi důležité sledovat zpoždění replikace. Klientské ovladače MongoDB budou používat pouze sekundární servery, které příliš nezaostávají, jinak můžete riskovat, že budou obsluhována zastaralá data.

Uvnitř MongoDB bude primární sledovat stav replikace svých sekundárních serverů. Poradce načte informace o replikaci a ochrání zpoždění replikace. Pokud bude zpoždění příliš velké, odešle se varování nebo zpráva o kritickém stavu.

Poradce okna replikace MongoDB

Vedle zpoždění replikace je důležitou metrikou, kterou je třeba sledovat, okno replikace. Oplog MongoDB je jediná kolekce, jejíž (přednastavená) velikost byla omezena. Jakmile oplog dosáhne konce a je třeba uložit novou transakci, vyřadí nejstarší transakci, aby se uvolnilo místo pro novou transakci. Okno replikace odráží počet sekund mezi nejstarší a nejnovější transakcí v oplogu.

Tato metrika je velmi důležitá, protože potřebujete vědět, na jak dlouho můžete vyjmout sekundární ze sady replicaSet, než již nebude moci dohnat hlavní server, protože je příliš pozadu v replikaci. Také pokud sekundární začne zaostávat, bylo by dobré vědět, jak dlouho to můžeme tolerovat, než to sekundární již nebude moci dohnat.

V prostředí MongoDB je k dispozici funkce pro výpočet okna replikace. Tento poradce v ClusterControl používá funkci k provedení stejného výpočtu. Výhodou by bylo, že nyní můžete být upozorněni na příliš krátké okno replikace.

Poradce pro nesdílené databáze a sbírky MongoDB

Ve sdíleném clusteru MongoDB jsou všechny nesdílené databáze a kolekce přiřazeny k výchozímu primárnímu fragmentu směrovačem fragmentů MongoDB. Tento primární fragment se může mezi databázemi a kolekcemi lišit, ale obecně by to byl fragment s největším dostupným místem na disku.

Nerozdělená databáze nebo kolekce nepředstavuje pro váš cluster okamžitě riziko. Pokud však aplikace nebo uživatel začne zapisovat velké objemy dat do jednoho z nich, může se primární fragment rychle zaplnit a způsobit výpadek tohoto datového fragmentu. Vzhledem k tomu, že databáze nebo sbírka není shardována, nebude moci využívat jiné fragmenty.

Z tohoto důvodu jsme vytvořili poradce, který tomu zabrání. Poradce prohledá všechny databáze a kolekce a upozorní vás, pokud nedošlo k rozštěpení.

Kontrola povoleno ověřování

Bez povolení ověřování v MongoDB bude každý přihlášený uživatel považován za správce. Jedná se o vážné riziko, protože běžné úkoly správce, jako je vytváření uživatelů nebo zálohování, jsou nyní dostupné komukoli. To v kombinaci s odhalenými servery MongoDB vedlo k nedávným hackům výkupného MongoDB, zatímco jednoduché povolení autentizace by většině těchto případů zabránilo.

Implementovali jsme poradce, který ověřuje, zda mají vaše servery MongoDB povoleno ověřování. To lze provést explicitně nastavením v konfiguraci nebo implicitně povolením souboru klíčů replikace. Pokud tento poradce nezjistí, že autentizace byla povolena, měli byste okamžitě jednat, protože váš server je zranitelný vůči kompromitaci.

Autentizace/autorizace Zdravá kontrola

Vedle poradce s povolenou autentizací jsme také vytvořili poradce, který provádí kontrolu zdravého rozumu pro autentizaci i autorizaci v MongoDB.

V MongoDB není autentizace a autorizace umístěna na centrálním místě, ale je prováděna a ukládána na úrovni databáze. Normálně se uživatelé připojí k databázi a ověří se proti databázi, kterou zamýšlejí používat. Se správnými udělenými oprávněními je však také možné autentizovat se proti jiným (nesouvisejícím) databázím a přesto využívat jinou databázi. Normálně je to naprosto v pořádku, pokud uživatel nemá nadměrná práva (jako role správce) k jiné databázi.

V tomto poradci ověřujeme, zda jsou tyto nadměrné role přítomny a zda by mohly představovat hrozbu. Zároveň také kontrolujeme slabá a snadno uhodnutelná hesla.

Detekce chyb (nový poradce)

V MongoDB bude jakákoliv zjištěná chyba započítána nebo zaznamenána. V MongoDB existuje velké množství možných chyb:uživatelská tvrzení, běžná tvrzení, varování a dokonce i výjimky interního serveru. Pokud existují trendy v těchto chybách, je pravděpodobné, že došlo buď k nesprávné konfiguraci, nebo k problému s aplikací.

Tento poradce se podívá na statistiky chyb MongoDB (tvrzení) a dává tomu smysl. Interpretujeme nalezené trendy a poradíme, jak snížit chyby ve vašem prostředí MongoDB!