Distribuera en replikuppsättning med hög tillgänglighet i MongoDB 3.4 med nyckelfil för åtkomstkontroll på Ubuntu 16.04

Sedan starten 2009 har MongoDB lett NoSQL-branschen. Ett av kärnkoncepten i MongoDB är Replica Set, så innan vi arbetar med det, låt oss först se över konceptet.

Om Replica Set

Den enklaste kommunikationsmodellen som används vid replikering av databaser är Master-Slave-arkitekturen. Som namnet antyder har denna modell 2 roller som är spridda i en unik master och många slavar, masterns roll är att bearbeta läs- och skrivoperationerna som görs av klienterna och slavarna behandlas som en replik av mastern.

Den viktigaste fördelen med denna modell är att masterns prestanda inte äventyras av backup-operationerna, backup-operationerna görs på ett asynkront sätt och detta kan bli ett allvarligt problem när en masternod misslyckas. Slavnoder är skrivskyddade och de måste flyttas upp manuellt till masternoden, så under denna tid finns det möjlighet att förlora data.

Ett alternativ för att lösa tillgänglighetsproblemet är att ha mer än en master i arkitekturen, men detta kan leda till ytterligare ett problem i datakonsistensen mellan dessa instanser och den ökade komplexiteten i konfigurationen.

Med tanke på sammanhanget kan vi presentera Replica Set- tekniken från MongoDB. Replica Set är namnet på Master-Slave-arkitekturen som har automatisk failover, så i det ögonblick som en masternod (som nu heter primary) misslyckas med att fungera korrekt electionkommer en utlösare och en ny primär nod att väljas från de återstående slavarna ( kallas nu secondaries).

Primär nod

Den primära noden är den enda som utför skrivoperationer, som standard hanteras läsoperationer även av den primära men detta beteende kan ändras senare.

Operationerna registreras i oplog(driftsloggen), sedan uppdaterar sekundära noder sitt innehåll asynkront baserat på innehållet ioplog

Obs: oplogär en begränsad samling, detta betyder att samlingen har en gräns, med local.oplog.rsdu kan kontrollera innehållet i denna samling inuti ett mongoskal i valfri uppsättningsmedlem.

Sekundär nod

Förutom att vara de som gör en ordentlig säkerhetskopiering av databasen, har en sekundär nod dessa roller:

• Kan acceptera läsoperationer vid behov.
• Kan utlösa ett val om en primär nod misslyckas.
• Kan rösta i val.
• Kan bli den nya primära om det behövs.

Tack vare dessa egenskaper kan vi ha olika typer av sekundära noder:

• Prioritet 0 : Dessa noder kan inte bli en primaryoch kan inte utlösa ett val, ändå kan de rösta i val, har en komplett replik och kan acceptera läsoperationer. Dessa kan vara till hjälp vid distribution av flera datacenter.
• Dolda : Dessa är Priority 0medlemmar, men dessutom kan de inte bearbeta läsoperationer. De får rösta om det behövs. Föredragna uppgifter för dessa medlemmar är rapportering och säkerhetskopiering.
• Fördröjd : Dessa noder ansvarar för "historiska data" genom att försenas med någon tidsenhet. En fördröjd medlem måste vara en priority 0nod, och det rekommenderas att de också är en hiddenmedlem.

Förutsättningar

• Tillgängligheten för att köra minst 3 instanser av Ubuntu 16.04 x64 med samma serverstorlek.

Designa Replica-setet

Innan du distribuerar en infrastruktur är det viktigt att designa den, och det finns punkter att tänka på i denna design.

Att välja antal medlemmar

Tänk på att det minsta antalet element för att bygga en replikuppsättning är 3. Du kan blanda de tre typerna av noder med minst en primär och en sekundär nod.

I den här guiden distribuerar vi 3 medlemmar, en primär och två standardsekundärer.

Notera: Det rekommenderas att ha ett maximalt antal av 7 röstberättigade medlemmar med en blandning av skiljedomare och sekundära medlemmar.

Välj ett namn

Namnet är bara för referens men du använder det i uppsättningens konfiguration. Tänk på att du kan ha mer än en replikuppsättning i din produktionsmiljö, så försumma inte uppsättningens namn.

Denna handledning uppmuntrar användaren att välja namnet på uppsättningen.

Fördelning av medlemmarna i olika datacenter

Den här handledningen föreslår att du installerar på samma datacenter så att du kan undvika kommunikationsproblem.

Obs: Vid distribution i olika datacenter rekommenderas att du omsluter dina noder med ett VPN

Installationsinstruktioner

Steg 1: Distribuera de lägsta noderna för din infrastruktur

Starta 3 noder av Ubuntu 16.04 x64; i samma region från din kundportal, om möjligt. Glöm inte att namnge dem i enlighet med den typ av projekt du har att göra med och se till att ha samma serverstorlek i alla dessa noder.

Efter att du har distribuerat dina 3 noder måste du vara säker på att varje nod kan prata med resten. Du måste ssh till två noder och nå de andra med ping -c 4 EXAMPLE_IP. Ändra EXAMPLE_IPtill de faktiska IP-adresserna för dina noder.

Här kan du se ett exempel på framgångsrik kommunikation mellan två 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

Steg 2: Installera MongoDB i varje nod i din infrastruktur

I allmänhet kan du använda MongoDB-paketet för Ubuntu, men det är bättre att använda den officiella community-repo eftersom den alltid är uppdaterad. Denna repo innehåller dessa paket:

• mongodb-org , grupppaketet som omsluter de fyra komponenterna.
• mongodb-org-server , denna innehåller mongoddemonen (primär process som hanterar dataförfrågningar).
• mongodb-org-mongos , denna innehåller mongosdemonen (rutttjänst för delade distributioner).
• mongodb-org-shell , detta är mongo shellJavaScript-gränssnittet.
• mongodb-org-tools , några verktyg för administrationsaktiviteter.

Fortsätt med att installera paketen.

Importera den publika nyckeln till pakethanteringssystemet.

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

Skapa listfilen för 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

Uppdatera paketdatabasen.

sudo apt-get update

Installera MongoDB-metapaketet.

sudo apt-get install -y mongodb-org

Starta MongoDB-tjänsten.

sudo service mongod start

Nu kan du öppna mongo shelli valfri bash-session. För att göra detta måste du använda mongokommandot. Du kommer att mötas av något liknande detta.

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

Glöm inte att stänga av tjänsten med sudo service mongod stop, för senare börjar vi mongodigen med några parametrar. Upprepa denna process i alla tre noder i uppsättningen.

Steg 3: Konfigurera åtkomstnyckelfilen

Att använda en nyckelfil tvingar fram två koncept i Replica Set-administrationen. Den första är Internal Authentication. Som standard kan du starta en mongo shellsession utan att använda en användare och denna session kommer att ha full kontroll över databasen, men när du använder en nyckelfil för autentisering mongo shellnår din session ett tillstånd som kallas localhost exception. Det här tillståndet låter dig bara skapa administratörsanvändaren och replikuppsättningen. Det andra konceptet är Role-Based Access Control, eller med andra ord auktorisation. Detta genomdrivs för att styra administrativa nivåer till replikuppsättningen.

Skapa din nyckelfil

Nyckelfilen är lösenordet som ska användas i setet, detta lösenord måste vara detsamma i alla medlemmar i setet. För att öka säkerheten är det viktigt att använda en slumpmässig nyckel med det verktyg du väljer.

Innehållet måste vara mellan 6 och 1064 tecken långt. Du måste också ställa in read onlybehörigheten för nyckelfilen.

chmod 400 PATH_OF_YOUR_KEYFILE

Placera nyckelfilen i varje setmedlem

Kopiera nu din nyckelfil till varje uppsättningsmedlem, använd en konsekvent mapp för framtida referens och lagra den inte på ett flyttbart medium.

Använd också en mapp för filen som mongodkan komma åt.

Framtvinga med hjälp av nyckelfilen i replikuppsättningen

I det här steget måste vi starta mongod daemon medlemmen i varje set . Det finns två sätt att starta mongodprocessen: med hjälp av en konfigurationsfil eller med kommandoraden. Båda är ganska enkla metoder, men bara för enkelhetens skull använder den här handledningen kommandoradsversionen.

Kommandoradskonfiguration

Använd namnet du valde tidigare i det här kommandot.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Som standard mongodkörs inte som en demon. Du kommer att behöva använda --forkparametern eller använda för upstartatt köra den helt som en demon. I den här handledningen uppmuntrar vi inte att köra mongodsom en demon så att du kan se loggarna i din terminal direkt.

Obs: Skriv noggrant namnet på replikuppsättningen eftersom du inte kan ändra den när den väl har skapats.

Steg 4: Anslut till det lokala värdgränssnittet från en av uppsättningsmedlemmarna

Obs: Om du kör mongodsom en icke-demon-process, måste du öppna en annan ssh-anslutning för att fortsätta arbeta.

Du måste använda mongokommandot för att öppna mongo shell. Detta kan göras i vilken medlem som helst i uppsättningen.

I detta ögonblick är vi i ett tillstånd som heter localhost exception. När en nyckelfil används för att ställa in mongodprocessen är du skyldig att skapa en databasadministratör innan du kan tillämpa läs-skrivoperationer, men vi kommer att gå in på det senare.

Steg 5: Initiering av replikuppsättningen

Detta är en känslig del, vi använder kommandot rs.initiate()inuti mongo shellfrån steg 4. Innan vi använder det här kommandot låt oss granska det.

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örsta _idfältet är en sträng och måste matcha det --replSetsom skickades innan till mongod. Varje värde på hostmåste också vara antingen ip eller domännamn för varje medlem i replikuppsättningen. Glöm inte att lägga till porten som mongoinstansen använder i varje medlem.

Nu är det dags att utföra kommandot med dina data på, detta kommer att utlösa en election, sedan väljs en primär automatiskt.

Här bör du notera att din skalmarkör har ändrats till YOUR_SET_NAME:PRIMARY>eller YOUR_SET_NAME:SECONDARY. Det betyder att skapandet av ett set var en framgång.

För att fortsätta arbeta måste du hitta primary, om du inte är på den förstås. Använd rs.status()kommandot för att visa informationen om replikuppsättningen och lokalisera primary. Du letar efter fastigheten "stateStr" : "PRIMARY".

Steg 6: Skapa administratören

När du har hittat primary, skriv in mongo shelloch kör nästa kommando med dina data.

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

Den admin = db.getSiblingDB("admin")del låter oss skriva in adminfrån en annan databas. Detta skapar ett alias som heter admin, så vi kan köra kommandon med det istället.

Om operationen lyckas får du ett meddelande om att användaren har lagts till.

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

Vid det här laget har vi bara en administratör för alla servrar, men att ha en replikuppsättning tvingar oss att ha en användare med clusterAdminrollen. Vi kommer att skapa en annan användare med bara den rollen för att skilja problem.

Steg 7: Autentisera som administratör

Vi har nått gränsen för localhost exception, vilket är anledningen till att vi måste ändra autentiseringen till användaren som skapats ett steg innan.

Du kan ändra användare inuti mongo shellmed följande.

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

Om du inte redan har anslutit till mongo shellkommandot använd detta kommando istället.

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

Du kommer att meddelas om bytet av en användare och du kan gå till nästa steg.

Steg 8: Skapa klustermastern

Den clusterAdminroll ger användaren full kontroll över Replica set. Att skapa det är lika enkelt som att skapa en adminanvändare.

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

Observera att denna gång ändras rollen tillclusterAdmin .

Steg 9: Infoga data i replikuppsättningen

För närvarande har vi 2 administratörsanvändare: en som har total kontroll över servern och en annan som har åtkomst till administrativa uppgifter på replikuppsättningsnivån. Vi saknar dock en användare som har tillgång att "använda" en databas, så vi kommer att skapa den användaren nu.

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

Observera att den här gången ändrar vi dbdelen, där lägger vi databasen tillgänglig för användaren, i det här fallet använder vi en databas som heter cars.

Databasen är inte skapad ännu. För att göra det måste du skriva några kommandon för att implicit skapa det. Byt till carsdatabasen.

use cars

Du får ett meddelande: switched to db cars.

Databasen har fortfarande inte skapats, för att göra det måste du skriva något till den. Vi använder följande exempel.

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

Den här gången kommer du att meddelas med WriteResult({ "nInserted" : 1 }).

Om du vill kan du hämta alla objekt i databasen, med find()metoden:

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

Observera att det _idkommer att vara annorlunda i din utdata, men de andra uppgifterna bör vara desamma. Med tillräckligt med tid kommer denna data att replikeras till de andra medlemmarna.

Slutsats

Att skapa ett replikset kan vara utmanande till en början eftersom det finns mycket information att förstå, men när du väl har fått idén bakom det kan du distribuera det på ett enkelt sätt, så ge inte upp om du inte kan förstå den första gången. Tänk på att Replica-set är viktigt i MongoDB-administration eftersom det öppnar möjligheten att lägga till avancerade funktioner som lastbalansering.