En introduktion till Percona Server för MongoDB 4.2

När du väljer en NoSQL-databasteknik bör viktiga överväganden tas i beaktande, såsom prestanda, motståndskraft, tillförlitlighet och säkerhet. Dessa nyckelfaktorer bör också anpassas till att uppnå affärsmål, åtminstone vad gäller databasen.

Många tekniker har kommit in för att förbättra dessa aspekter, och det är tillrådligt för en organisation att förbättra de framträdande alternativen och försöka integrera dem i databassystemen.

Ny teknik bör säkerställa maximal prestanda för att förbättra uppnåendet av affärsmål till en överkomlig driftskostnad men med mer manipulativa funktioner som feldetektering och varningssystem.

I den här bloggen kommer vi att diskutera Percona-versionen av MongoDB och hur den utökar kraften hos MongoDB på en mängd olika sätt.

Vad är Percona Server för MongoDB?

För att en databas ska fungera bra måste det finnas en optimalt etablerad underliggande server för att förbättra läs- och skrivtransaktioner. Percona Server för MongoDB är en gratis drop-in-ersättning med öppen källkod för MongoDB Community Edition, men med ytterligare funktioner i företagsklass. Den är designad med några stora förbättringar av standard MongoDB-serverinställningen.

Det ger hög prestanda, förbättrad säkerhet och tillförlitlighet för optimal prestanda med minskade utgifter för proprietära mjukvaruleverantörsrelationer.

Percona Server for MongoDB Salient Features

MongoDB Community Edition är kärnan i Percona-servern med tanke på att den redan utgör viktiga funktioner som det flexibla schemat, distribuerade transaktioner, förtrogenhet med JSON-dokumenten och inbyggd hög tillgänglighet. Utöver detta integrerar Percona Server för MongoDB följande framträdande funktioner som gör det möjligt för den att uppfylla de aspekter vi har nämnt ovan:

Hot Backups
Data i vila kryptering
Revisionsloggning
Percona Memory Engine
Extern LDAP-autentisering med SASL
HashiCorp Vault Integration
Förbättrad frågeprofilering

Hot Backups

Percona-server för MongoDB skapar en fysisk datasäkerhetskopiering på en körande server i bakgrunden utan någon märkbar driftsförsämring. Detta kan uppnås genom att köra kommandot createBackup som administratör på admindatabasen och ange säkerhetskopieringskatalogen.

> use admin

switched to db admin

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

{ "ok" : 1 }

När du får { "ok" :1 } så lyckades säkerhetskopieringen. Annars, om du t.ex. anger en tom sökväg för säkerhetskopiering, kan du få ett felsvar, t.ex.:

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

Att återställa säkerhetskopian kräver att man först stoppar mongod-instansen, rengör datakatalogen, kopierar filerna från katalogen och sedan startar om mongod-tjänsten. Detta kan göras genom att köra kommandot nedan

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

Du kan också lagra säkerhetskopian i arkivformat om du använder Percona-server för MongoDB 4.2.1-1

> use admin

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

Du kan också säkerhetskopiera direkt till AWS S3 med standardinställningarna eller med fler konfigurationer. För en standard S3-bucket backup:

> db.runCommand({createBackup:1, s3:{bucket:"backup", sökväg:"newBackup"}})

Data-at-rest-kryptering

MongoDB version 3.2 introducerade data at rest-kryptering för WiredTiger-lagringsmotorn för att säkerställa att datafiler kan dekrypteras och läsas av parter med enbart dekrypteringsnyckel. Datakryptering i vila i Percona Server för MongoDB introducerades i version 3.6 för att gå i hand med datakryptering i vila-gränssnitt i MongoDB. Den senaste versionen inkluderar dock inte stöd för Amazon AWS och KIMP-nyckelhanteringstjänster.

Krypteringen kan också tillämpas på återställningsfiler när data i vila är aktiverad. Percona Server för MongoDB använder alternativet krypteringsCipherMode med två selektiva chifferlägen:

AES256-CBC (standard chifferläge)
AES256-GCM

Du kan kryptera data med kommandot nedan

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Vi använder alternativet --ecryptionKeyFile för att ange sökvägen till en fil som innehåller krypteringsnyckeln.

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

Revisionsloggning

För varje databassystem har administratörer mandat att hålla reda på aktiviteter som äger rum. I Percona Server för MongoDB, när granskning är aktiverad, genererar servern en granskningsloggfil som utgör information om olika användarhändelser såsom auktorisering och autentisering. Men om du startar servern med granskning aktiverad, kommer loggarna inte att visas dynamiskt under körning.

Revisionsloggningen i MongoDB Community Edition kan ha två dataformat, det vill säga JSON och BSON. Men för Percona Server för MongoDB är granskningsloggning begränsad till endast JSON-filer. Servern loggar också bara viktiga kommandon i motsats till MongoDB som loggar allt. Eftersom filtreringsproceduren i Percona är så otydlig när det gäller filtreringssyntaxen, skulle aktivering av granskningsloggen utan filtrering erbjuda fler poster från vilka man kan begränsa sig till egna specifikationer.

Percona Memory Engine

Detta är en speciell konfiguration av WiredTiger-lagringsmotorn som inte lagrar användardata på disken. Datan finns helt och hållet och är lätt tillgänglig i huvudminnet förutom diagnostiska data som skrivs till disk. Detta gör databehandlingen mycket snabbare men med hänsyn till att du måste se till att det finns tillräckligt med minne för att lagra datamängden och servern bör inte stängas av. Man kan välja en lagringsmotor att använda med --storageEngine-kommandot. Data som skapas för en lagringsmotor kan inte vara kompatibel med andra lagringsmotorer eftersom varje lagringsmotor har sin egen datamodell. Till exempel för att välja lagringsmotorn i minnet. Du stoppar först alla pågående mongod-instanser och utfärdar sedan kommandona:

$ service mongod stop

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

Om du redan har några data med din standard MongoDB Community-utgåva och du vill migrera till Percona Memory Engine, använd bara mongodumb och mongorestore-verktygen genom att utfärda kommandot:

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

Extern LDAP-autentisering med SASL

När klienter gör antingen en läs- eller skrivbegäran till MongoDB mongod-instansen måste de autentisera mot MongoDB-serverns användardatabas först. Den externa autentiseringen tillåter MongoDB-servern att verifiera klientuppgifterna (användarnamn och lösenord) mot en separat tjänst. Den externa autentiseringsarkitekturen innefattar:

LDAP-server som fjärrlagrar alla användaruppgifter
SASL Daemon som används som MongoDB-serverlokal proxy för fjärr-LDAP-tjänsten.
SASL-bibliotek:skapar nödvändig autentiseringsdata för MongoDB-klienten och servern.

Autentiseringssessionssekvens

Klienten ansluts till en körande mongod-instans och skapar en PLAIN autentiseringsbegäran med hjälp av SASL-biblioteket.
Autentiseringsbegäran skickas sedan till servern som ett speciellt Mongo-kommando som sedan tas emot av mongod-servern med dess nyttolast.
Servern skapar några SASL-sessioner härledda med klientuppgifter med sin egen referens till SASL-biblioteket.
Mongod-servern skickar autentiseringsnyttolasten till SASL-biblioteket som lämnar över den till saslauthd-demonen. Demonen skickar den till LDAP och inväntar ett JA eller NEJ-svar på autentiseringsbegäran genom att kontrollera om användaren finns och det inlämnade lösenordet är korrekt.
Saslauthd skickar detta svar till mongod-servern genom SASL-biblioteket som sedan autentiserar eller avvisar begäran i enlighet med detta.

Här är en illustration för denna process:

Så här lägger du till en extern användare till en mongod-server:

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

Externa användare kan dock inte ha roller tilldelade i administratörsdatabasen.

HashiCorp Vault Integration

HashCorp Vault är en produkt designad för att hantera hemligheter och skydda känslig data genom att säkert lagra och noggrant kontrollera åtkomst till konfidentiell information. Med den tidigare Percona-versionen lagrades krypteringsnyckeln för data i vila lokalt på servern inuti nyckelfilen. Integrationen med HashCorp Vault säkrar krypteringsnyckeln mycket mycket bättre.

Förbättrad frågeprofilering

Profilering har en försämrad inverkan på databasens prestanda, särskilt när det finns så många frågor. Percona-servern för MongoDB kommer till hands genom att begränsa antalet frågor som samlas in av databasprofileraren, vilket minskar dess inverkan på prestanda.

Slutsats

Percona Server för MongoDB är en förbättrad öppen källkod och mycket skalbar databas som kan fungera som en kompatibel drop-in-ersättning för MongoDB Community Edition men med liknande syntax och konfiguration. Det förbättrar omfattande datasäkerhet, särskilt en i vila, och förbättrad databasprestanda genom tillhandahållande av Percona Server-motor, vilket begränsar profileringshastigheten bland andra funktioner.

Percona Server för MongoDB stöds fullt ut av ClusterControl som ett alternativ för distribution.