Implementer et replikasæt med høj tilgængelighed i MongoDB 3.4 ved hjælp af nøglefil til adgangskontrol på Ubuntu 16.04

Siden sin idé i 2009 har MongoDB været førende i NoSQL-industrien. Et af kernekoncepterne i MongoDB er replikasættet, så før du arbejder med det, lad os først gennemgå konceptet.

Om replikasæt

Den enkleste kommunikationsmodel, der bruges til replikering af databaser, er Master-Slave-arkitekturen. Som navnet antyder har denne model 2 roller, som er spredt i en unik master og mange slaver, masterens rolle er at behandle læse- og skriveoperationerne udført af klienterne, og slaverne behandles som en replika af masteren.

Den vigtigste fordel ved denne model er, at masterens ydeevne ikke kompromitteres af backup-operationerne, backup-operationerne udføres på en asynkron måde, og dette kan blive et alvorligt problem, når en master-knude svigter. Slavenoder er skrivebeskyttede, og de skal manuelt forfremmes til masterknudepunktet, så i denne tid er der mulighed for at miste data.

En mulighed for at løse tilgængelighedsproblemet er at have mere end én master i arkitekturen, men dette kan føre til et andet problem i dataenes sammenhæng mellem disse instanser og den ekstra kompleksitet af konfigurationen.

Nu givet kontekst kan vi præsentere Replica Set- teknologien fra MongoDB. Replica Set er navnet på Master-Slave-arkitekturen, der har automatisk failover, så i det øjeblik, hvor en master (som nu hedder primary), ikke fungerer korrekt, electionvil en trigger og en ny primær node blive valgt blandt de resterende slaver ( nu omtalt som secondaries).

Primær knude

Den primære node er den eneste, der udfører skriveoperationer, som standard håndteres læseoperationer også af den primære, men denne adfærd kan ændres senere.

Operationerne registreres i oplog(driftsloggen), derefter opdaterer sekundære noder deres indhold asynkront baseret på indholdet afoplog

Bemærk: oploger en lukket samling, det betyder, at samlingen har en grænse, med local.oplog.rsdu kan kontrollere indholdet af denne samling inde i en mongo-skal i ethvert sæt medlem.

Sekundær knude

Udover at være dem, der laver en ordentlig backup af databasen, har en sekundær node disse roller:

• Kan acceptere læseoperationer, hvis det er nødvendigt.
• Kan udløse et valg, hvis en primær node fejler.
• Kan stemme ved valg.
• Kan blive den nye primære, hvis det er nødvendigt.

Takket være disse egenskaber kan vi have forskellige typer sekundære noder:

• Prioritet 0 : Disse noder kan ikke blive en primaryog kan ikke udløse et valg, stadig kan de stemme ved valg, have en komplet replika og kan acceptere læseoperationer. Disse kan være nyttige ved implementering af multidatacenter.
• Skjult : Disse er Priority 0medlemmer, men de kan desuden ikke behandle læseoperationer. De kan stemme, hvis det er nødvendigt. Foretrukne opgaver for disse medlemmer er rapportering og backup.
• Forsinket : Disse noder er ansvarlige for "historiske data" ved at blive forsinket med en eller anden enhed i tid. Et forsinket medlem skal være en priority 0node, og det anbefales, at de også er hiddenmedlem.

Forudsætninger

• Tilgængeligheden til at køre minimum 3 forekomster af Ubuntu 16.04 x64 med samme serverstørrelse.

Design Replica-sættet

Før du implementerer en infrastruktur, er det vigtigt at designe den, og der er punkter at overveje i dette design.

Valg af antal medlemmer

Husk, at minimumsantallet af elementer til at bygge et replikasæt er 3. Du kan blande de tre typer noder med minimum en primær og en sekundær node.

I denne guide implementerer vi 3 medlemmer, en primær og to standardsekundære.

Bemærk: Det anbefales at have et maksimalt antal på 7 stemmeberettigede medlemmer med en blanding af dommere og sekundære medlemmer.

Vælg et navn

Navnet er kun til reference, men du bruger det i sættets konfiguration. Husk på, at du kan have mere end ét replika-sæt i dit produktionsmiljø, så forsøm ikke dit sæts navn.

Denne vejledning opfordrer brugeren til at vælge navnet på sættet.

Fordeling af medlemmerne i forskellige datacentre

Denne vejledning foreslår at implementere på det samme datacenter, så du kan undgå at have kommunikationsproblemer.

Bemærk: I tilfælde af implementering i forskellige datacentre anbefales det at omslutte dine noder med en VPN

Installationsvejledning

Trin 1: Implementer minimumsnoder til din infrastruktur

Start 3 noder af Ubuntu 16.04 x64; i samme region fra din kundeportal, hvis det er muligt. Glem ikke at navngive dem i overensstemmelse med den type projekt, du har at gøre med, og sørg for at have den samme serverstørrelse i alle disse noder.

Når du har installeret dine 3 noder, skal du være sikker på, at hver node kan tale med resten. Du skal ssh ind i to noder og nå de andre ved hjælp af ping -c 4 EXAMPLE_IP. Skift EXAMPLE_IPtil de faktiske IP'er for dine noder.

Her kan du se et eksempel på vellykket kommunikation mellem to noder.

root@foo_node:~# ping -c 4 EXAMPLE_IP
PING EXAMPLE_IP (EXAMPLE_IP) 56(84) bytes of data.
64 bytes from EXAMPLE_IP: icmp_seq=1 ttl=59 time=0.594 ms
64 bytes from EXAMPLE_IP: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from EXAMPLE_IP: icmp_seq=3 ttl=59 time=0.477 ms
64 bytes from EXAMPLE_IP: icmp_seq=4 ttl=59 time=0.551 ms

--- EXAMPLE_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3021ms
rtt min/avg/max/mdev = 0.477/0.565/0.640/0.064 ms

Trin 2: Installer MongoDB i hver node i din infrastruktur

Generelt kan du bruge MongoDB-pakken til Ubuntu, men det er bedre at bruge den officielle community-repo, fordi den altid er opdateret. Denne repo indeholder disse pakker:

• mongodb-org , gruppepakken , der omslutter de fire komponenter.
• mongodb-org-server , denne indeholder mongoddæmonen (primær proces, der håndterer dataanmodninger ).
• mongodb-org-mongos , denne indeholder mongosdæmonen (routingtjeneste til delte implementeringer).
• mongodb-org-shell , dette er mongo shellJavaScript-grænsefladen.
• mongodb-org-tools , nogle værktøjer til administrationsaktiviteter.

Fortsæt med at installere pakkerne.

Importer den offentlige nøgle til pakkehåndteringssystemet.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

Opret listefilen til MongoDB '/etc/apt/sources.list.d/mongodb-org-3.4.list'.

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Opdater pakkedatabasen.

sudo apt-get update

Installer MongoDB-metapakken.

sudo apt-get install -y mongodb-org

Start MongoDB-tjenesten.

sudo service mongod start

Nu kan du åbne mongo shelli enhver bash-session. For at gøre dette skal du bruge mongokommandoen. Du vil blive mødt af noget der ligner dette.

MongoDB shell version v3.4.7
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.7
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
Server has startup warnings:
*Some extra logs are cut by the way*
>

Glem ikke at lukke for tjenesten med sudo service mongod stop, for senere starter vi mongodigen med nogle parametre. Gentag denne proces i alle 3 noder i sættet.

Trin 3: Konfigurer adgangsnøglefilen

Brug af en nøglefil fremtvinger to koncepter i Replica Set-administration. Den første er Internal Authentication. Som standard kan du starte en mongo shellsession uden at bruge en bruger, og denne session vil have fuld kontrol over databasen, men når du bruger en nøglefil til godkendelse mongo shell, når din session en tilstand kaldet localhost exception. Denne tilstand lader dig kun oprette administratorbrugeren og replikasættet. Det andet koncept er Role-Based Access Control, eller med andre ord autorisation. Dette håndhæves for at styre administrative niveauer til Replica-sættet.

Opret din nøglefil

Nøglefilen er adgangskoden til at bruge i sættet, denne adgangskode skal være den samme i alle medlemmer af sættet. For at øge sikkerheden er det vigtigt at bruge en tilfældig nøgle med det valgte værktøj.

Indholdet skal være mellem 6 og 1064 tegn langt. Du skal også indstille read onlytilladelsen til nøglefilen.

chmod 400 PATH_OF_YOUR_KEYFILE

Placer nøglefilen i hvert sætmedlem

Kopier nu din nøglefil til hvert sæt-medlem, brug venligst en konsistent mappe til fremtidig reference, og gem den ikke på et flytbart medium.

Brug også en mappe til den fil, du mongodkan få adgang til.

Gennemtving ved hjælp af nøglefilen i replikasættet

I dette trin skal vi starte mongod daemon i hvert sæt medlem . Der er to måder at starte mongodprocessen på: ved at bruge en konfigurationsfil eller ved at bruge kommandolinjen. Begge er ret nemme metoder, men for nemheds skyld bruger denne tutorial kommandolinjeversionen.

Kommandolinjekonfiguration

Brug det navn, du valgte tidligere i denne kommando.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Kører som standard mongodikke som en dæmon. Du bliver nødt til at bruge --forkparameteren eller bruge for upstartat køre den fuldt ud som en dæmon. I denne tutorial opfordrer vi ikke til at køre mongodsom en dæmon, så du kan se logfilerne direkte på din terminal.

Bemærk: Indtast forsigtigt navnet på replikasættet, fordi når det først er oprettet, kan du ikke ændre det.

Trin 4: Opret forbindelse til den lokale værtsgrænseflade fra et af sætmedlemmerne

Bemærk: Hvis du kører mongodsom en ikke-dæmon-proces, bliver du nødt til at åbne en anden ssh-forbindelse for at fortsætte med at arbejde.

Du skal bruge mongokommandoen for at åbne mongo shell. Dette kan gøres i ethvert medlem af sættet.

I dette øjeblik er vi i en tilstand kaldet localhost exception. Når en nøglefil bruges til at opsætte mongodprocessen, er du forpligtet til at oprette en databaseadministrator, før du kan anvende læse-skrive-operationer, men det kommer vi ind på senere.

Trin 5: Start af replikasættet

Dette er en delikat del, vi bruger kommandoen rs.initiate()inde mongo shellfra trin 4. Inden vi bruger denne kommando, lad os gennemgå den.

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "example1.net:27017" },
      { _id : 1, host : "example2.net:27017" },
      { _id : 2, host : "example3.net:27017" }
    ]
  }
)

Det første _idfelt er en streng og skal matche det, --replSetder blev sendt før til mongod. Hver værdi af hostskal også være enten ip eller domænenavnet for hvert medlem af replikasættet. Glem ikke at tilføje porten, som mongo-instansen bruger i hvert medlem.

Nu er det tid til at udføre kommandoen med dine data på, dette vil udløse en election, så vil en primær blive valgt automatisk.

Her skal du bemærke, at din shell-markør er ændret til YOUR_SET_NAME:PRIMARY>eller YOUR_SET_NAME:SECONDARY. Det betyder, at oprettelsen af ​​et sæt var en succes.

For at fortsætte med at arbejde skal du finde primary, hvis du selvfølgelig ikke er på den. Brug rs.status()kommandoen til at vise oplysningerne om replikasættet og find primary. Du leder efter ejendommen "stateStr" : "PRIMARY".

Trin 6: Oprettelse af administrator

Når du har fundet primary, skal du indtaste mongo shellog køre den næste kommando ved hjælp af dine data.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOU_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

Den admin = db.getSiblingDB("admin")del lader os skrive ind adminfra en anden database. Dette skaber et alias kaldet admin, så vi kan udføre kommandoer ved at bruge det i stedet.

Hvis operationen er en succes, vil du få en meddelelse om, at brugeren er blevet tilføjet.

Successfully added user: {
    "user" : "YOUR_USER",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

På dette tidspunkt har vi kun en administrator for alle serverne, men at have et replika-sæt tvinger os til at have en bruger med clusterAdminrollen. Vi vil oprette en anden bruger med kun den rolle for at adskille bekymringer.

Trin 7: Godkendelse som administrator

Vi har nået grænsen for localhost exception, hvorfor vi er nødt til at ændre godkendelsen til den bruger, der er oprettet et trin før.

Du kan ændre brugere inde i mongo shellmed følgende.

db.getSiblingDB("admin").auth("YOUR_ADMIN", "YOUR_PASSWORD" )

Hvis du ikke allerede har oprettet forbindelse til den, mongo shellbrug denne kommando i stedet.

mongo -u "YOUR_ADMIN" -p "YOUR_PASSWORD" --authenticationDatabase "admin"

Du får besked om ændringen af ​​en bruger, og du kan gå til næste trin.

Trin 8: Oprettelse af klyngemasteren

Den clusterAdminrolle giver brugeren fuld kontrol over replika sæt. At oprette det er lige så nemt som at oprette en admin-bruger.

db.getSiblingDB("admin").createUser(
  {
    "user" : "YOUR_USER",
    "pwd" : "YOUR_PASSWORD",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Bemærk, at rollen denne gang ændres tilclusterAdmin .

Trin 9: Indsættelse af data i replikasættet

I øjeblikket har vi 2 admin-brugere: en, der har total kontrol over serveren, og en anden, der har adgang til administrative opgaver på Replica-sætniveau. Vi mangler dog en bruger, der har adgang til at "bruge" en database, så den bruger vil vi oprette nu.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOUR_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "cars" } ]
  }
)

Bemærk denne gang, vi ændrer dbdelen, der sætter vi databasen tilgængelig for brugeren, i dette tilfælde bruger vi en database med navnet cars.

Databasen er ikke oprettet endnu. For at gøre det skal du skrive nogle kommandoer for implicit at oprette det. Skift til carsdatabasen.

use cars

Du får en besked: switched to db cars.

Databasen er stadig ikke oprettet, for at gøre det skal du skrive noget til den. Vi bruger følgende eksempel.

db.models.insert({ make: "Dodge", model: "Viper", year: 2010 })

Denne gang får du besked med WriteResult({ "nInserted" : 1 }).

Hvis du vil, kan du hente alle objekterne i databasen, med find()metoden:

db.models.find()
{ "_id" : ObjectId("59acd8b55334882863541ff4"), "make" : "Dodge", "model" : "Viper", "year" : 2010 }

Bemærk, at det _idvil være anderledes i dit output, men de andre data skal være de samme. Givet tilstrækkelig tid, vil disse data blive replikeret til de andre medlemmer.

Konklusion

At oprette et replikasæt kan være udfordrende i starten, fordi der er en masse info at forstå, men når du først har fået ideen bag det, kan du implementere det i en leg, så giv ikke op, hvis du ikke kan fatte det første gang. Husk, at Replica-sæt er vigtigt i MongoDB-administration, fordi det åbner muligheden for at tilføje avancerede funktioner som Load Balancing.