MongoDB bewaken en beveiligen met ClusterControl-adviseurs

Databasebeheer bestaat voor 80% uit het lezen en interpreteren van uw monitoringsystemen. Honderden statistieken kunnen op verschillende manieren worden geïnterpreteerd en gecombineerd om u diepgaand inzicht te geven in uw databasesystemen en hoe u deze kunt optimaliseren. Bij het draaien van meerdere databasesystemen kan het monitoren van deze systemen een hele klus worden. Als de interpretatie en combinatie van statistieken veel tijd kost, zou het dan niet geweldig zijn als dit op de een of andere manier zou kunnen worden geautomatiseerd?

Daarom hebben we in ClusterControl databaseadviseurs gemaakt:kleine scripts die metrics voor je kunnen interpreteren, combineren en waar nodig advies kunnen geven. Voor MySQL hebben we een uitgebreide bibliotheek gemaakt met de meest gebruikte MySQL-controlecontroles. Maar ook voor MongoDB hebben we een brede bibliotheek van adviseurs tot je beschikking. Voor deze blogpost hebben we de negen belangrijkste voor je uitgezocht. We zullen ze allemaal in detail beschrijven.

De negen MongoDB-adviseurs die we in deze blogpost zullen behandelen zijn:

• Controleer opties voor schijfkoppeling
• Numa-check
• Collectievergrendelingspercentage (MMAP)
• Replicatievertraging
• Replicatievenster
• Niet-shard databases en collecties (alleen shard-cluster)
• Verificatie ingeschakeld vinkje
• Verificatie/autorisatie sanity check
• Foutdetectie (nieuwe adviseur)

Advisor Opties voor schijfmontage

Het is erg belangrijk om uw schijven op de meest optimale manier te laten mounten. Met de ClusterControl disk mount options advisor kijken we dagelijks nauwkeuriger naar uw dataschijf. In deze adviseur onderzoeken we het gebruikte bestandssysteem, mount-opties en de io-plannerinstellingen van het besturingssysteem.

We controleren of je schijven zijn gemount met noatime en nodiratime. Als u deze instelt, zullen de prestaties van de schijven afnemen, omdat bij elke toegang tot een bestand of map de toegangstijd naar de schijf moet worden geschreven. Aangezien dit continu gebeurt op databases, is dit een goede prestatie-instelling en verhoogt het ook de duurzaamheid van uw SSD's.

Voor bestandssystemen raden we aan moderne bestandssystemen te gebruiken zoals xfs, zfs, ext4 of btrfs. Deze bestandssystemen zijn gemaakt met het oog op prestaties. De io-planner wordt geadviseerd om ofwel op noop . te staan of deadline. Deadline is al jaren de standaard voor databases, maar dankzij snellere opslag zoals SSD's is de noop planner is tegenwoordig logischer.

Numa Check Adviseur

Voor MongoDB schakelen we onze NUMA . in adviseur controleren. Deze adviseur controleert of NUMA (Non-Uniform Access Memory) is ingeschakeld op uw systeem, en als dit het geval is, om het uit te schakelen.

Wanneer Non-Uniform Access Memory is ingeschakeld, kan de CPU van de server alleen zijn eigen geheugen rechtstreeks aanspreken en niet de andere CPU's in de machine. Op deze manier kan de CPU alleen geheugen toewijzen vanuit zijn eigen geheugenruimte, en het toewijzen van iets dat teveel is, resulteert in swap-gebruik. Deze architectuur heeft een sterk prestatievoordeel op applicaties met meerdere processors die alle CPU's toewijzen, maar aangezien MongoDB geen applicatie met meerdere processors is, zal het de prestaties aanzienlijk verminderen en kan dit leiden tot enorm swap-gebruik.

Collectievergrendelingspercentage (MMAP)

Als MMAP is een op bestanden gebaseerd opslagsysteem, het ondersteunt niet de vergrendeling op documentniveau zoals gevonden in WiredTiger en RocksDB. In plaats daarvan het laagste vergrendelingsniveau voor MMAP is de collectie sloten. Dit betekent dat elke schrijfactie naar een verzameling (invoegen, bijwerken of verwijderen) de hele verzameling vergrendelt. Als het percentage sloten te hoog wordt, geeft dit aan dat u betwistingsproblemen heeft met de collectie. Als dit niet correct wordt geadresseerd, kan dit uw schrijfsnelheid tot stilstand brengen. Daarom is het erg handig om een ​​adviseur te hebben die u vooraf waarschuwt.

MongoDB Replicatie Lag Advisor

Als u MongoDB uitschaalt voor leesbewerkingen via secundaire bestanden, is de replicatievertraging erg belangrijk om in de gaten te houden. De MongoDB-clientstuurprogramma's gebruiken alleen secundairen die niet te ver achterblijven, anders loopt u het risico verouderde gegevens op te leveren.

Binnen MongoDB houdt de primaire de replicatiestatus van zijn secundairen bij. De adviseur haalt de replicatie-informatie op en bewaakt de replicatievertraging. Als de vertraging te hoog wordt, wordt er een waarschuwing of kritieke statusmelding verzonden.

MongoDB Replicatie Venster Adviseur

Naast de replicatievertraging is het replicatievenster een belangrijke statistiek om in de gaten te houden. De MongoDB-oplog is een enkele verzameling, die is beperkt tot een (vooraf ingestelde) grootte. Zodra de oplog het einde bereikt en een nieuwe transactie moet worden opgeslagen, zal deze de oudste transactie verwijderen om ruimte te maken voor de nieuwe transactie. Het replicatievenster geeft het aantal seconden weer tussen de oudste en de nieuwste transactie in de oplog.

Deze statistiek is erg belangrijk omdat u moet weten hoe lang u een secundaire uit de replicaSet kunt halen, voordat deze de master niet langer kan inhalen omdat hij te ver achterloopt bij de replicatie. Ook als een secundaire achterstand begint op te lopen, is het goed om te weten hoe lang we dit kunnen verdragen voordat de secundaire de achterstand niet meer kan inhalen.

In de MongoDB-shell is een functie beschikbaar om het replicatievenster te berekenen. Deze adviseur in ClusterControl gebruikt de functie om dezelfde berekening te maken. Het voordeel zou zijn dat u nu gewaarschuwd kunt worden bij een te korte replicatieperiode.

MongoDB Un-Sharded Databases en Collecties Adviseur

In een shard MongoDB-cluster worden alle niet-shard data bases en verzamelingen toegewezen aan een standaard primaire shard door de MongoDB shard-router. Deze primaire shard kan per database en collectie verschillen, maar over het algemeen is dit de shard met de meeste beschikbare schijfruimte.

Het hebben van een niet-gecodeerde database of verzameling vormt niet meteen een risico voor uw cluster. Als een toepassing of gebruiker echter grote hoeveelheden gegevens naar een van deze begint te schrijven, kan de primaire shard snel vol raken en een storing op deze shard veroorzaken. Omdat de database of verzameling geen shard is, kan deze geen gebruik maken van andere shards.

Om deze reden hebben wij een adviseur in het leven geroepen die dit gaat voorkomen. De adviseur scant alle databases en collecties en waarschuwt u als deze niet zijn geshard.

Verificatie ingeschakeld Controle

Zonder authenticatie in MongoDB in te schakelen, wordt elke gebruiker die inlogt behandeld als een beheerder. Dit is een serieus risico, aangezien normaal gesproken beheertaken, zoals het maken van gebruikers of het maken van back-ups, nu voor iedereen beschikbaar zijn. Dit in combinatie met blootgestelde MongoDB-servers resulteerde in de recente MongoDB-ransomhacks, terwijl een eenvoudige activering van authenticatie de meeste van deze gevallen had voorkomen.

We hebben een adviseur geïmplementeerd die verifieert of op uw MongoDB-servers verificatie is ingeschakeld. Dit kan expliciet worden gedaan door dit in de configuratie in te stellen, of impliciet door het replicatiesleutelbestand in te schakelen. Als deze adviseur niet detecteert dat de authenticatie is ingeschakeld, moet u hier onmiddellijk op reageren, aangezien uw server kwetsbaar is om te worden gecompromitteerd.

Verificatie/autorisatie Sanity Check

Naast de voor authenticatie ingeschakelde adviseur hebben we ook een adviseur gebouwd die een sanity check uitvoert voor zowel authenticatie als autorisatie in MongoDB.

In MongoDB wordt de authenticatie en autorisatie niet op een centrale plek geplaatst, maar op databaseniveau uitgevoerd en opgeslagen. Normaal gesproken zullen gebruikers verbinding maken met de database, waarbij ze authenticeren tegen de database die ze willen gebruiken. Met de juiste subsidies is het echter ook mogelijk om te authenticeren tegen andere (niet-gerelateerde) databases en toch gebruik te maken van een andere database. Normaal gesproken is dit prima, tenzij een gebruiker overmatige rechten heeft (zoals de beheerdersrol) over een andere database.

In deze adviseur gaan we na of deze buitensporige rollen aanwezig zijn en of ze een bedreiging kunnen vormen. We controleren tegelijkertijd ook op zwakke en gemakkelijk te raden wachtwoorden.

Foutdetectie (nieuwe adviseur)

In MongoDB wordt elke opgetreden fout geteld of vastgelegd. Binnen MongoDB is er een grote verscheidenheid aan mogelijke fouten:beweringen van gebruikers, regelmatige beweringen, waarschuwingen en zelfs interne serveruitzonderingen. Als er trends zijn in deze fouten, is er waarschijnlijk een verkeerde configuratie of een toepassingsprobleem.

Deze adviseur zal de statistieken van MongoDB-fouten (assets) bekijken en begrijpt dit. We interpreteren de gevonden trends en geven advies over hoe u fouten in uw MongoDB-omgeving kunt verminderen!