Distribuer et replikasett med høy tilgjengelighet i MongoDB 3.4 ved å bruke nøkkelfil for tilgangskontroll på Ubuntu 16.04

Siden unnfangelsen i 2009 har MongoDB vært ledende i NoSQL-industrien. Et av kjernekonseptene til MongoDB er replikasettet, så før du jobber med det, la oss først se gjennom konseptet.

Om replikasett

Den enkleste kommunikasjonsmodellen som brukes i replikering av databaser er Master-Slave-arkitekturen. Som navnet antyder har denne modellen 2 roller som er spredt i en unik master og mange slaver, masterens rolle er å behandle lese- og skriveoperasjonene utført av klientene, og slavene blir behandlet som en kopi av masteren.

Den viktigste fordelen med denne modellen er at ytelsen til masteren ikke kompromitteres av sikkerhetskopieringsoperasjonene, backupoperasjonene gjøres på en asynkron måte og dette kan bli et alvorlig problem når en masternode svikter. Slavenoder er skrivebeskyttet, og de må forfremmes manuelt til masternoden, så i denne tiden er det mulighet for å miste data.

Et alternativ for å løse tilgjengelighetsproblemet er å ha mer enn én master i arkitekturen, men dette kan føre til et annet problem i konsistensen av dataene mellom disse forekomstene og den ekstra kompleksiteten til konfigurasjonen.

Nå gitt kontekst kan vi presentere Replica Set- teknologien til MongoDB. Replica Set er navnet på Master-Slave-arkitekturen som har automatisk failover, så i det øyeblikket en master- primarynode (som nå heter ) ikke fungerer som den skal, electionvil en utløse og en ny primærnode bli valgt fra de gjenværende slavene ( referert nå som secondaries).

Primær node

Den primære noden er den eneste som utfører skriveoperasjoner, som standard håndteres leseoperasjoner av den primære også, men denne oppførselen kan endres senere.

Operasjonene registreres i oplog(driftsloggen), deretter oppdaterer sekundære noder innholdet asynkront basert på innholdet ioplog

Merk: oploger en avkortet samling, dette betyr at samlingen har en grense, med local.oplog.rsdu kan sjekke innholdet i denne samlingen i et mongo-skall i et hvilket som helst settmedlem.

Sekundær node

Foruten å være de som tar en skikkelig sikkerhetskopi av databasen, har en sekundær node disse rollene:

• Kan godta leseoperasjoner om nødvendig.
• Kan utløse et valg hvis en primær node mislykkes.
• Kan stemme ved valg.
• Kan bli ny primær ved behov.

Takket være disse egenskapene kan vi ha forskjellige typer sekundære noder:

• Prioritet 0 : Disse nodene kan ikke bli en primaryog kan ikke utløse et valg, likevel kan de stemme i valg, ha en komplett replika og kan godta leseoperasjoner. Disse kan være nyttige ved distribusjon av flere datasenter.
• Skjult : Dette er Priority 0medlemmer, men dessuten kan de ikke behandle leseoperasjoner. De kan stemme om nødvendig. Foretrukne oppgaver for disse medlemmene er rapportering og sikkerhetskopiering.
• Forsinket : Disse nodene har ansvaret for "historiske data" ved å bli forsinket med en eller annen tidsenhet. Et forsinket medlem må være en priority 0node, og det anbefales at de også er hiddenmedlem.

Forutsetninger

• Tilgjengeligheten til å kjøre minimum 3 forekomster av Ubuntu 16.04 x64 med samme serverstørrelse.

Design Replica-settet

Før du distribuerer en infrastruktur er det viktig å designe den, og det er punkter å vurdere i denne designen.

Valg av antall medlemmer

Husk at minimumsantallet av elementer for å bygge et replikasett er 3. Du kan blande de tre typene noder med minimum én primær og én sekundær node.

I denne veiledningen distribuerer vi 3 medlemmer, en primær og to standard sekundærer.

Merk: Det anbefales å ha et maksimalt antall på 7 stemmeberettigede medlemmer med en blanding av dommere og sekundære medlemmer.

Velg et navn

Navnet er kun for referanse, men du bruker det i konfigurasjonen av settet. Husk at du kan ha mer enn ett replikasett i produksjonsmiljøet ditt, så ikke overse settets navn.

Denne opplæringen oppfordrer brukeren til å velge navnet på settet.

Fordeling av medlemmene i ulike datasentre

Denne opplæringen foreslår å distribuere på samme datasenter slik at du kan unngå kommunikasjonsproblemer.

Merk: Ved distribusjon i forskjellige datasentre anbefales det å omslutte nodene dine med en VPN

Instruksjoner for distribusjon

Trinn 1: Distribuer minimumsnodene for infrastrukturen din

Start 3 noder av Ubuntu 16.04 x64; i samme region fra kundeportalen din, hvis mulig. Ikke glem å navngi dem i henhold til typen prosjekt du har å gjøre med, og sørg for å ha samme serverstørrelse i alle disse nodene.

Etter at du har distribuert de tre nodene dine, må du være sikker på at hver node kan snakke med resten. Du må ssh inn i to noder og nå de andre ved å bruke ping -c 4 EXAMPLE_IP. Bytt EXAMPLE_IPtil de faktiske IP-ene til nodene dine.

Her kan du se et eksempel på vellykket kommunikasjon mellom 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

Trinn 2: Installer MongoDB i hver node i infrastrukturen din

Generelt kan du bruke MongoDB-pakken til Ubuntu, men det er bedre å bruke den offisielle fellesskapsrepoen fordi den alltid er oppdatert. Denne repoen inneholder disse pakkene:

• mongodb-org , gruppepakken som omslutter de fire komponentene.
• mongodb-org-server , denne inneholder mongoddaemonen (primær prosess som håndterer dataforespørsler ).
• mongodb-org-mongos , denne inneholder mongosdaemonen (rutingstjeneste for delte distribusjoner).
• mongodb-org-shell , dette er mongo shellJavaScript-grensesnittet.
• mongodb-org-tools , noen verktøy for administrasjonsaktiviteter.

Fortsett med å installere pakkene.

Importer den offentlige nøkkelen til pakkebehandlingssystemet.

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

Opprett listefilen for 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

Oppdater pakkedatabasen.

sudo apt-get update

Installer MongoDB-metapakken.

sudo apt-get install -y mongodb-org

Start MongoDB-tjenesten.

sudo service mongod start

Nå kan du åpne mongo shelli hvilken som helst bash-økt. For å gjøre dette, må du bruke mongokommandoen. Du vil bli møtt av noe som ligner på 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*
>

Ikke glem å slå av tjenesten med sudo service mongod stop, for senere starter vi mongodigjen med noen parametere. Gjenta denne prosessen i alle 3 noder i settet.

Trinn 3: Konfigurer tilgangsnøkkelfilen

Bruk av en nøkkelfil fremtvinger to konsepter i Replica Set-administrasjonen. Den første er Internal Authentication. Som standard kan du starte en mongo shelløkt uten å bruke en bruker, og denne økten vil ha full kontroll over databasen, men når du bruker en nøkkelfil for autentisering mongo shellnår økten en tilstand som kalles localhost exception. Denne tilstanden lar deg bare opprette administratorbrukeren og replikasettet. Det andre konseptet er Role-Based Access Control, eller med andre ord autorisasjon. Dette håndheves for å styre administrative nivåer til Replica-settet.

Lag din nøkkelfil

Nøkkelfilen er passordet som skal brukes i settet, dette passordet må være det samme i alle medlemmer av settet. For å øke sikkerheten er det viktig å bruke en tilfeldig nøkkel med verktøyet du velger.

Innholdet må være mellom 6 og 1064 tegn langt. Du må også angi read onlytillatelsen for nøkkelfilen.

chmod 400 PATH_OF_YOUR_KEYFILE

Plasser nøkkelfilen i hvert settmedlem

Kopier nå nøkkelfilen din til hvert sett-medlem, vennligst bruk en konsistent mappe for fremtidig referanse, og ikke lagre den på et flyttbart medium.

Bruk også en mappe for filen mongoddu har tilgang til.

Håndheve ved å bruke nøkkelfilen i replikasettet

I dette trinnet må vi starte mongod daemon i hvert sett-medlem . Det er to måter å starte mongodprosessen på: ved å bruke en konfigurasjonsfil eller ved å bruke kommandolinjen. Begge er ganske enkle metoder, men bare for enkelhets skyld bruker denne opplæringen kommandolinjeversjonen.

Kommandolinjekonfigurasjon

Bruk navnet du valgte tidligere i denne kommandoen.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Som standard mongodkjører ikke som en demon. Du må bruke --forkparameteren eller bruke for upstartå kjøre den fullt ut som en demon. I denne opplæringen oppfordrer vi ikke til å kjøre mongodsom en demon, slik at du kan se loggene direkte på terminalen din.

Merk: Skriv nøye inn navnet på replikasettet fordi du ikke kan endre det når det først er opprettet.

Trinn 4: Koble til det lokale vertsgrensesnittet fra et av settemedlemmene

Merk: Hvis du kjører mongodsom en ikke-demonprosess, må du åpne en annen ssh-tilkobling for å fortsette å jobbe.

Du må bruke mongokommandoen for å åpne mongo shell. Dette kan gjøres i hvilket som helst medlem av settet.

I dette øyeblikk er vi i en tilstand som heter localhost exception. Når en nøkkelfil brukes til å sette opp mongodprosessen, er du forpliktet til å opprette en databaseadministrator før du kan bruke lese-skrive-operasjoner, men vi vil gå inn på det senere.

Trinn 5: Starte replikasettet

Dette er en delikat del, vi bruker kommandoen rs.initiate()i mongo shellfra trinn 4. før vi bruker denne kommandoen, la oss se gjennom 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 _idfeltet er en streng og må samsvare med det --replSetsom ble sendt før til mongod. Dessuten må hver verdi av hostenten være ip-en eller domenenavnet til hvert medlem av replikasettet. Ikke glem å legge til porten mongo-forekomsten bruker i hvert medlem.

Nå er det på tide å utføre kommandoen med dataene dine på den, dette vil utløse en election, så vil en primær velges automatisk.

Her bør du merke deg at skallmarkøren har endret seg til YOUR_SET_NAME:PRIMARY>eller YOUR_SET_NAME:SECONDARY. Dette betyr at å lage et sett var en suksess.

For å fortsette å jobbe må du finne primary, hvis du ikke er på den selvfølgelig. Bruk rs.status()kommandoen til å vise informasjonen om replikasettet og finn primary. Du leter etter eiendommen "stateStr" : "PRIMARY".

Trinn 6: Opprette administratoren

Etter at du har funnet primary, skriv inn mongo shellog kjør den neste kommandoen ved å bruke dataene dine.

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

Den admin = db.getSiblingDB("admin")delen lar oss skrive inn adminfra en annen database. Dette skaper et alias kalt admin, slik at vi kan utføre kommandoer ved å bruke det i stedet.

Hvis operasjonen er vellykket, vil du få et varsel om at brukeren er lagt til.

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

På dette tidspunktet har vi bare en administrator for alle serverne, men å ha et replikasett tvinger oss til å ha en bruker med clusterAdminrollen. Vi vil opprette en annen bruker med bare den rollen for å skille bekymringer.

Trinn 7: Autentisering som administrator

Vi har nådd grensen for localhost exception, som er grunnen til at vi må endre autentiseringen til brukeren opprettet ett trinn før.

Du kan endre brukere inne i mongo shellmed følgende.

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

Hvis du ikke allerede har koblet til, mongo shellbruk denne kommandoen i stedet.

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

Du vil bli varslet om endring av en bruker, og du kan gå til neste trinn.

Trinn 8: Opprette klyngemasteren

Den clusterAdminrollen gir brukeren full kontroll over Replica sett. Å lage det er like enkelt som å opprette admin-brukeren.

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

Merk at denne gangen endres rollen tilclusterAdmin .

Trinn 9: Sette inn data i replikasettet

For øyeblikket har vi 2 admin-brukere: en som har total kontroll over serveren og en annen som har tilgang til administrative oppgaver på Replica-settnivået. Vi mangler imidlertid en bruker som har tilgang til å "bruke" en database, så vi oppretter denne brukeren nå.

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

Legg merke til at denne gangen endrer vi dbdelen, der legger vi databasen tilgjengelig for brukeren, i dette tilfellet bruker vi en database som heter cars.

Databasen er ikke opprettet ennå. For å gjøre det, må du skrive inn noen kommandoer for å implisitt lage den. Bytt til carsdatabasen.

use cars

Du vil få et varsel: switched to db cars.

Databasen er fortsatt ikke opprettet, for å gjøre det må du skrive noe til den. Vi bruker følgende eksempel.

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

Denne gangen vil du bli varslet med WriteResult({ "nInserted" : 1 }).

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

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

Merk at det _idvil være annerledes i utdataene dine, men de andre dataene skal være de samme. Gitt nok tid, vil disse dataene bli replikert til de andre medlemmene.

Konklusjon

Å lage et replikasett kan være utfordrende til å begynne med fordi det er mye informasjon å forstå, men når du først har fått ideen bak det kan du distribuere det i en lek, så ikke gi opp hvis du ikke kan forstå det første gang. Husk at Replica-sett er viktig i MongoDB-administrasjon fordi det åpner muligheten for å legge til avanserte funksjoner som Load Balancing.