En introduktion til Percona Server til MongoDB 4.2

Når du vælger en NoSQL-databaseteknologi, bør vigtige overvejelser tages i betragtning, såsom ydeevne, robusthed, pålidelighed og sikkerhed. Disse nøglefaktorer bør også tilpasses til opnåelse af forretningsmål, i det mindste for så vidt angår databasen.

Mange teknologier er kommet i spil for at forbedre disse aspekter, og det er tilrådeligt for en organisation at forbedre de fremtrædende muligheder og prøve at integrere dem i databasesystemerne.

Nye teknologier bør sikre maksimal ydeevne for at forbedre opnåelsen af forretningsmål til en overkommelig driftsomkostning, men med mere manipulerende funktioner såsom fejlregistrering og alarmsystemer.

I denne blog vil vi diskutere Percona-versionen af MongoDB, og hvordan den udvider magten i MongoDB på en række forskellige måder.

Hvad er Percona Server for MongoDB?

For at en database skal fungere godt, skal der være en optimalt etableret underliggende server til at forbedre læse- og skrivetransaktioner. Percona Server til MongoDB er en gratis open source drop-in-erstatning for MongoDB Community Edition, men med yderligere funktionalitet i virksomhedskvalitet. Den er designet med nogle større forbedringer af standard MongoDB-serveropsætningen.

Det leverer høj ydeevne, forbedret sikkerhed og pålidelighed for optimal ydeevne med reducerede udgifter til proprietære softwareleverandørrelationer.

Percona Server til MongoDB Salient Features

MongoDB Community Edition er kernen i Percona-serveren i betragtning af, at den allerede udgør vigtige funktioner såsom det fleksible skema, distribuerede transaktioner, kendskab til JSON-dokumenterne og indbygget høj tilgængelighed. Udover dette integrerer Percona Server til MongoDB følgende fremtrædende funktioner, der gør det muligt for den at opfylde de aspekter, vi har nævnt ovenfor:

Varme sikkerhedskopier
Data i hvile kryptering
Revisionslogning
Percona Memory Engine
Ekstern LDAP-godkendelse med SASL
HashiCorp Vault Integration
Forbedret forespørgselsprofilering

Hot Backups

Percona server til MongoDB opretter en fysisk data backup på en kørende server i baggrunden uden nogen mærkbar driftsforringelse. Dette kan opnås ved at køre createBackup-kommandoen som administrator på admin-databasen og specificere backup-mappen.

> use admin

switched to db admin

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

{ "ok" : 1 }

Når du modtager { "ok" :1 }, var sikkerhedskopieringen vellykket. Ellers, hvis du f.eks. angiver en tom backup-mappesti, kan du modtage et fejlsvar, f.eks.:

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

Gendannelse af sikkerhedskopien kræver, at man først stopper mongod-forekomsten, renser databiblioteket, kopierer filerne fra biblioteket og genstarter derefter mongod-tjenesten. Dette kan gøres ved at køre kommandoen nedenfor

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

Du kan også gemme sikkerhedskopien i arkivformat, hvis du bruger Percona-serveren til MongoDB 4.2.1-1

> use admin

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

Du kan også sikkerhedskopiere direkte til AWS S3 ved at bruge standardindstillingerne eller med flere konfigurationer. For en standard S3 bucket backup:

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

Data-at-rest-kryptering

MongoDB version 3.2 introducerede data ved hvile-kryptering til WiredTiger-lagringsmotoren for at sikre, at datafiler kan dekrypteres og læses af parter med kun dekrypteringsnøgle. Datakryptering i hvile i Percona Server til MongoDB blev introduceret i version 3.6 for at gå i hånd med datakryptering i hvile-grænseflade i MongoDB. Den seneste version inkluderer dog ikke understøttelse af Amazon AWS og KIMP nøglehåndteringstjenester.

Krypteringen kan også anvendes på rollback-filer, når hvilende data er aktiveret. Percona Server til MongoDB bruger encryptionCipherMode-indstillingen med 2 selektive chiffertilstande:

AES256-CBC (standard chiffertilstand)
AES256-GCM

Du kan kryptere data med kommandoen nedenfor

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Vi bruger --ecryptionKeyFile-indstillingen til at angive stien til en fil, der indeholder krypteringsnøglen.

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

Revisionslogning

For hvert databasesystem har administratorer mandat til at holde styr på aktiviteter, der finder sted. I Percona Server for MongoDB, når revision er aktiveret, genererer serveren en revisionslogfil, der udgør information om forskellige brugerhændelser såsom autorisation og autentificering. Hvis du starter serveren med revision aktiveret, vil logfilerne dog ikke blive vist dynamisk under kørsel.

Revisionslogning i MongoDB Community Edition kan have to dataformater, nemlig JSON og BSON. Men for Percona Server til MongoDB er revisionslogning kun begrænset til JSON-fil. Serveren logger også kun vigtige kommandoer i modsætning til MongoDB, der logger alt. Da filtreringsproceduren i Percona er så uklar med hensyn til filtreringssyntaksen, ville aktivering af revisionsloggen uden filtrering give flere poster, hvorfra man kan indsnævre sig til egne specifikationer.

Percona Memory Engine

Dette er en speciel konfiguration af WiredTiger-lagringsmotoren, der ikke gemmer brugerdata på disken. Dataene ligger fuldt ud og er let tilgængelige i hovedhukommelsen undtagen diagnostiske data, der er skrevet til disken. Dette gør databehandling meget hurtigere, men med en betragtning om, at du skal sikre, at der er nok hukommelse til at opbevare datasættet, og serveren bør ikke lukke ned. Man kan vælge en storage-motor til brug med --storageEngine-kommandoen. Data, der er oprettet til én storage-motor, kan ikke være kompatible med andre storage-motorer, fordi hver storage-motor har sin egen datamodel. For eksempel for at vælge lagermotoren i hukommelsen. Du stopper først enhver kørende mongod-instans og udsteder derefter kommandoerne:

$ service mongod stop

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

Hvis du allerede har nogle data med din standard MongoDB Community-udgave, og du gerne vil migrere til Percona Memory Engine, skal du blot bruge mongodumb og mongorestore-værktøjerne ved at udstede kommandoen:

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

Ekstern LDAP-godkendelse med SASL

Når klienter foretager enten en læse- eller skriveanmodning til MongoDB mongod-instansen, skal de først godkendes mod MongoDB-serverens brugerdatabase. Den eksterne godkendelse gør det muligt for MongoDB-serveren at verificere klientoplysningerne (brugernavn og adgangskode) mod en separat tjeneste. Den eksterne autentificeringsarkitektur involverer:

LDAP-server, som eksternt gemmer alle brugeroplysninger
SASL Daemon, der bruges som en MongoDB server-lokal proxy for den eksterne LDAP-tjeneste.
SASL-bibliotek:opretter nødvendige godkendelsesdata for MongoDB-klient og server.

Sekvens for godkendelsessession

Klienten bliver forbundet til en kørende mongod-instans og opretter en PLAIN-godkendelsesanmodning ved hjælp af SASL-biblioteket.
Authentanmodningen sendes derefter til serveren som en speciel Mongo-kommando, som derefter modtages af mongod-serveren med dens anmodningsnyttelast.
Serveren opretter nogle SASL-sessioner afledt med klientlegitimationsoplysninger ved hjælp af sin egen reference til SASL-biblioteket.
Mongod-serveren sender godkendelsesnyttelasten til SASL-biblioteket, som overdrager den til saslauthd-dæmonen. Dæmonen sender den til LDAP og afventer et JA eller NEJ-svar på godkendelsesanmodningen ved at kontrollere, om brugeren eksisterer, og den indsendte adgangskode er korrekt.
Saslauthd'en sender dette svar til mongod-serveren gennem SASL-biblioteket, som derefter godkender eller afviser anmodningen i overensstemmelse hermed.

Her er en illustration til denne proces:

Sådan tilføjer du en ekstern bruger til en mongod-server:

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

Eksterne brugere kan dog ikke have roller tildelt i administratordatabasen.

HashiCorp Vault Integration

HashCorp Vault er et produkt designet til at administrere hemmeligheder og beskytte følsomme data ved sikker lagring og stram kontrol af adgangen til fortrolige oplysninger. Med den tidligere Percona-version blev data i hvile-krypteringsnøgle gemt lokalt på serveren inde i nøglefilen. Integrationen med HashCorp Vault sikrer krypteringsnøglen meget langt bedre.

Forbedret forespørgselsprofilering

Profilering har en forringet indvirkning på databasens ydeevne, især når der er så mange forespørgsler. Percona-serveren til MongoDB kommer i hånden ved at begrænse antallet af forespørgsler, der indsamles af databaseprofileren, og reducerer dermed dens indvirkning på ydeevnen.

Konklusion

Percona Server til MongoDB er en forbedret open source og meget skalerbar database, der kan fungere som en kompatibel drop-in-erstatning for MongoDB Community Edition, men med lignende syntaks og konfiguration. Det forbedrer omfattende datasikkerhed, især én i hvile, og forbedret databaseydeevne gennem levering af Percona Server-motor, hvilket begrænser profileringshastigheden blandt andre funktioner.

Percona Server til MongoDB er fuldt understøttet af ClusterControl som en mulighed for implementering.