Een inleiding tot Percona Server voor MongoDB 4.2

Bij het kiezen van een NoSQL-databasetechnologie moet rekening worden gehouden met belangrijke overwegingen, zoals prestaties, veerkracht, betrouwbaarheid en beveiliging. Deze sleutelfactoren moeten ook worden afgestemd op het behalen van bedrijfsdoelen, althans wat de database betreft.

Veel technologieën zijn in het spel gekomen om deze aspecten te verbeteren, en het is aan te raden voor een organisatie om de meest opvallende opties te verbeteren en te proberen deze in de databasesystemen te integreren.

Nieuwe technologieën moeten zorgen voor maximale prestaties om het bereiken van bedrijfsdoelen te verbeteren tegen betaalbare bedrijfskosten, maar met meer manipulatieve functies zoals foutdetectie en waarschuwingssystemen.

In deze blog bespreken we de Percona-versie van MongoDB en hoe deze de kracht van MongoDB op verschillende manieren uitbreidt.

Wat is Percona Server voor MongoDB?

Om een database goed te laten presteren, moet er een optimaal ingestelde onderliggende server zijn voor het verbeteren van lees- en schrijftransacties. Percona Server voor MongoDB is een gratis open-source drop-in vervanging voor de MongoDB Community Edition, maar met extra enterprise-grade functionaliteit. Het is ontworpen met enkele belangrijke verbeteringen aan de standaard MongoDB-serverconfiguratie.

Het levert hoge prestaties, verbeterde beveiliging en betrouwbaarheid voor optimale prestaties met lagere uitgaven voor relaties met propriëtaire softwareleveranciers.

Percona Server voor MongoDB opvallende kenmerken

MongoDB Community Edition is de kern van de Percona-server, aangezien het al belangrijke functies bevat, zoals het flexibele schema, gedistribueerde transacties, bekendheid van de JSON-documenten en native hoge beschikbaarheid. Daarnaast integreert Percona Server voor MongoDB de volgende opvallende kenmerken waardoor het kan voldoen aan de hierboven genoemde aspecten:

Hot back-ups
Versleuteling van gegevens in rust
Auditregistratie
Percona-geheugenengine
Externe LDAP-authenticatie met SASL
HashiCorp Vault-integratie
Verbeterde zoekopdrachtprofilering

Hot back-ups

Percona-server voor MongoDB maakt een fysieke gegevensback-up op een draaiende server op de achtergrond zonder merkbare verslechtering van de werking. Dit kan worden bereikt door de opdracht createBackup als beheerder uit te voeren in de beheerdersdatabase en de back-upmap op te geven.

> use admin

switched to db admin

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

{ "ok" : 1 }

Als u { "ok" :1 } ontvangt, is de back-up gelukt. Anders, als u bijvoorbeeld een leeg back-upmappad opgeeft, ontvangt u mogelijk een foutreactie, bijvoorbeeld:

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

Als je de back-up wilt herstellen, moet je eerst de mongod-instantie stoppen, de gegevensmap opschonen, de bestanden uit de map kopiëren en vervolgens de mongod-service opnieuw starten. Dit kan gedaan worden door het onderstaande commando uit te voeren

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

U kunt de back-up ook in archiefindeling opslaan als u Percona-server gebruikt voor MongoDB 4.2.1-1

> use admin

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

Je kunt ook rechtstreeks een back-up maken naar AWS S3 met de standaardinstellingen of met meer configuraties. Voor een standaard S3-bucketback-up:

> db.runCommand({createBackup:1, s3:{bucket:"backup", path:"newBackup"}})

Data-at-rest-codering

MongoDB versie 3.2 introduceerde data-at-rest-codering voor de WiredTiger-opslagengine om ervoor te zorgen dat gegevensbestanden kunnen worden gedecodeerd en gelezen door partijen met alleen een decoderingssleutel. Gegevensversleuteling in rust in Percona Server voor MongoDB is geïntroduceerd in versie 3.6 om samen te gaan met de gegevensversleuteling in rust-interface in MongoDB. De nieuwste versie biedt echter geen ondersteuning voor Amazon AWS- en KIMP-sleutelbeheerservices.

De codering kan ook worden toegepast om bestanden terug te draaien wanneer gegevens in rust is ingeschakeld. Percona Server voor MongoDB gebruikt encryptieCipherMode-optie met 2 selectieve coderingsmodi:

AES256-CBC (standaard coderingsmodus)
AES256-GCM

Je kunt gegevens versleutelen met de onderstaande opdracht

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

We gebruiken de optie --ecryptionKeyFile om het pad op te geven naar een bestand dat de coderingssleutel bevat.

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

Auditregistratie

Voor elk databasesysteem hebben beheerders een mandaat om de activiteiten die plaatsvinden bij te houden. In Percona Server voor MongoDB genereert de server, wanneer auditing is ingeschakeld, een auditlogbestand dat informatie bevat over verschillende gebruikersgebeurtenissen, zoals autorisatie en authenticatie. Als de server echter wordt gestart met auditing ingeschakeld, worden de logboeken tijdens runtime niet dynamisch weergegeven.

De Audit Logging in MongoDB Community Edition kan twee gegevensformaten aannemen, namelijk JSON en BSON. Voor Percona Server voor MongoDB is auditregistratie echter beperkt tot alleen JSON-bestanden. De server registreert ook alleen belangrijke opdrachten in tegenstelling tot MongoDB die alles logt. Omdat de filterprocedure in Percona zo onduidelijk is in termen van de filtersyntaxis, zou het inschakelen van het auditlogboek zonder filteren meer items opleveren waaruit men kan verfijnen tot eigen specificaties.

Percona-geheugenengine

Dit is een speciale configuratie van de WiredTiger-opslagengine die geen gebruikersgegevens op schijf opslaat. De gegevens blijven volledig aanwezig en zijn direct beschikbaar in het hoofdgeheugen, met uitzondering van diagnostische gegevens die naar schijf worden geschreven. Dit maakt de gegevensverwerking veel sneller, maar met de overweging dat u ervoor moet zorgen dat er voldoende geheugen is voor de gegevensset en dat de server niet mag worden afgesloten. Men kan een opslagengine selecteren om te gebruiken met de opdracht --storageEngine. Gegevens die voor één opslagengine zijn gemaakt, kunnen niet compatibel zijn met andere opslagengines, omdat elke opslagengine zijn eigen gegevensmodel heeft. Bijvoorbeeld om de in-memory storage engine te selecteren. U stopt eerst een actieve mongod-instantie en geeft vervolgens de opdrachten:

$ service mongod stop

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

Als je al wat gegevens hebt met je standaard MongoDB Community-editie en je wilt migreren naar Percona Memory Engine, gebruik dan de hulpprogramma's mongodumb en mongorestore door het volgende commando uit te voeren:

$ 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>

Externe LDAP-authenticatie met SASL

Telkens wanneer klanten een lees- of schrijfverzoek indienen bij de MongoDB mongod-instantie, moeten ze zich eerst verifiëren bij de MongoDB-servergebruikersdatabase. De externe authenticatie stelt de MongoDB-server in staat om de klantreferenties (gebruikersnaam en wachtwoord) te verifiëren tegen een afzonderlijke service. De externe authenticatie-architectuur omvat:

LDAP-server die op afstand alle gebruikersreferenties opslaat
SASL Daemon die wordt gebruikt als een MongoDB server-lokale proxy voor de externe LDAP-service.
SASL-bibliotheek:creëert noodzakelijke authenticatiegegevens voor MongoDB-client en server.

Verificatiesessiereeks

De client wordt verbonden met een actieve mongod-instantie en maakt een PLAIN-verificatieverzoek met behulp van de SASL-bibliotheek.
Het auth-verzoek wordt vervolgens naar de server verzonden als een speciaal Mongo-commando dat vervolgens door de mongod-server wordt ontvangen met zijn verzoekpayload.
De server maakt enkele SASL-sessies die zijn afgeleid van clientreferenties met behulp van zijn eigen verwijzing naar de SASL-bibliotheek.
De mongod-server geeft de auth-payload door aan de SASL-bibliotheek, die deze overhandigt aan de saslauthd-daemon. De daemon geeft het door aan de LDAP en wacht op een JA of NEE antwoord op het authenticatieverzoek door te controleren of de gebruiker bestaat en of het ingediende wachtwoord correct is.
De saslauthd geeft dit antwoord door aan de mongod-server via de SASL-bibliotheek, die het verzoek vervolgens dienovereenkomstig verifieert of afwijst.

Hier is een illustratie voor dit proces:

Een externe gebruiker toevoegen aan een mongod-server:

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

Externe gebruikers kunnen echter geen rollen krijgen toegewezen in de beheerdersdatabase.

HashiCorp Vault-integratie

HashCorp Vault is een product dat is ontworpen om geheimen te beheren en gevoelige gegevens te beschermen door de toegang tot vertrouwelijke informatie veilig op te slaan en streng te controleren. Met de vorige Percona-versie werd de data-at-rest-coderingssleutel lokaal opgeslagen op de server in het sleutelbestand. De integratie met HashCorp Vault beveiligt de coderingssleutel veel beter.

Verbeterde zoekopdrachtprofilering

Profilering heeft een verslechterende invloed op de databaseprestaties, vooral wanneer er zoveel query's worden verzonden. Percona-server voor MongoDB komt van pas door het aantal query's dat door de databaseprofiler wordt verzameld te beperken, waardoor de impact op de prestaties wordt verminderd.

Conclusie

Percona Server voor MongoDB is een verbeterde open source en zeer schaalbare database die kan fungeren als een compatibele drop-in vervanging voor MongoDB Community Edition, maar met vergelijkbare syntaxis en configuratie. Het verbetert de uitgebreide gegevensbeveiliging, met name een in rusttoestand, en verbeterde databaseprestaties door middel van de Percona Server-engine, waardoor onder andere de profileringssnelheid wordt beperkt.

Percona Server voor MongoDB wordt volledig ondersteund door ClusterControl als optie voor implementatie.