Implementeer een replicaset met hoge beschikbaarheid in MongoDB 3.4 met behulp van Keyfile voor toegangscontrole op Ubuntu 16.04

• Over Replica Set
• Vereisten
• Ontwerp de Replica-set
• Implementatie-instructies
• Gevolgtrekking

Sinds de oprichting in 2009 leidt MongoDB de NoSQL-industrie. Een van de kernconcepten van MongoDB is de replicaset, dus voordat we ermee aan de slag gaan, moeten we eerst het concept bekijken.

Over Replica Set

Het eenvoudigste communicatiemodel dat wordt gebruikt bij het repliceren van databases is de Master-Slave-architectuur. Zoals de naam al doet vermoeden, heeft dit model 2 rollen die zijn verdeeld in een unieke master en vele slaves, de rol van de master is om de lees- en schrijfbewerkingen van de clients te verwerken en de slaves worden behandeld als een replica van de master.

Het belangrijkste voordeel van dit model is dat de prestaties van de master niet in het gedrang komen door de back-upbewerkingen, de back-upbewerkingen worden asynchroon uitgevoerd en dit kan een ernstig probleem worden wanneer een masterknooppunt faalt. Slave-knooppunten zijn alleen-lezen en ze moeten handmatig worden gepromoveerd naar het masterknooppunt, dus in deze tijd bestaat de mogelijkheid om gegevens te verliezen.

Een optie om het beschikbaarheidsprobleem op te lossen is om meer dan één master in de architectuur te hebben, maar dit kan leiden tot een ander probleem in de consistentie van de gegevens tussen die instanties en de extra complexiteit van de configuratie.

Nu we de context hebben gegeven, kunnen we de Replica Set- technologie van MongoDB presenteren . Replicaset is de naam van de Master-Slave-architectuur met automatische failover, dus op het moment dat een masterknooppunt (dat nu heet primary) niet naar behoren functioneert, wordt een electiontrigger geactiveerd en wordt een nieuw primair knooppunt gekozen uit de resterende slaven ( hierna aangeduid als secondaries).

Primair knooppunt

Het primaire knooppunt is het enige knooppunt dat schrijfbewerkingen uitvoert, standaard worden leesbewerkingen ook afgehandeld door het primaire, maar dit gedrag kan later worden gewijzigd.

De bewerkingen worden vastgelegd in het oplog(bewerkingslogboek), waarna secundaire knooppunten hun inhoud asynchroon bijwerken op basis van de inhoud van deoplog

Let op: oplogis een afgetopte collectie, dit betekent dat de collectie een limiet heeft, waarmee local.oplog.rsje de inhoud van deze collectie in een mongo-shell kunt controleren in elk ingesteld lid.

Secundair knooppunt

Behalve degenen die een goede back-up van de database maken, heeft een secundair knooppunt deze rollen:

• Kan indien nodig leesbewerkingen accepteren.
• Kan een verkiezing activeren als een primair knooppunt faalt.
• Kan stemmen bij verkiezingen.
• Kan indien nodig de nieuwe primaire worden.

Dankzij deze kenmerken kunnen we verschillende soorten secundaire knooppunten hebben:

• Prioriteit 0 : Deze knooppunten kunnen geen a worden primaryen kunnen geen verkiezingen uitlokken, maar ze kunnen wel stemmen bij verkiezingen, hebben een volledige replica en kunnen leesbewerkingen accepteren. Deze kunnen nuttig zijn bij de implementatie van meerdere datacenters.
• Verborgen : dit zijn Priority 0leden, maar ze kunnen bovendien geen leesbewerkingen verwerken. Ze kunnen zo nodig stemmen. Voorkeurstaken voor deze leden zijn rapportage en back-ups.
• Vertraagd : deze knooppunten zijn verantwoordelijk voor "historische gegevens" doordat ze met een bepaalde eenheid op tijd zijn vertraagd. Een vertraagd lid moet een priority 0knooppunt zijn en het wordt aanbevolen dat ze ook hiddenlid zijn.

Vereisten

• De beschikbaarheid om minimaal 3 exemplaren van Ubuntu 16.04 x64 uit te voeren met dezelfde servergrootte.

Ontwerp de Replica-set

Voordat een infrastructuur wordt geïmplementeerd, is het belangrijk om deze te ontwerpen en er zijn punten die in overweging moeten worden genomen in dit ontwerp.

Het kiezen van het aantal leden

Houd er rekening mee dat het minimumaantal elementen om een ​​replicaset te bouwen 3 is. U kunt de drie typen knooppunten combineren met minimaal één primair en één secundair knooppunt.

In deze gids zetten we 3 leden in, één primair en twee standaard secondairen.

Opmerking: het wordt aanbevolen om een ​​maximum van 7 stemgerechtigde leden te hebben met een mix van arbiters en secundaire leden.

Kies een naam

De naam is alleen ter referentie, maar u gebruikt deze in de configuratie van de set. Houd er rekening mee dat u meer dan één Replica-set in uw productieomgeving kunt hebben, dus verwaarloos de naam van uw set niet.

Deze tutorial moedigt de gebruiker aan om de naam van de set te selecteren.

Verdeling van de leden in verschillende datacenters

Deze tutorial stelt voor om op hetzelfde datacenter te implementeren, zodat u communicatieproblemen kunt voorkomen.

Opmerking: in het geval van implementatie in verschillende datacenters is het raadzaam om uw knooppunten te omhullen met een VPN

Implementatie-instructies

Stap 1: Implementeer de minimale knooppunten voor uw infrastructuur

Start 3 knooppunten van Ubuntu 16.04 x64; in dezelfde regio vanaf uw klantenportaal, indien mogelijk. Vergeet niet om ze een naam te geven in overeenstemming met het type project waar je mee te maken hebt en zorg ervoor dat al deze knooppunten dezelfde servergrootte hebben .

Nadat u uw 3 knooppunten heeft geïmplementeerd, moet u er zeker van zijn dat elk knooppunt met de rest kan praten. U moet in twee knooppunten sshen en de andere bereiken met ping -c 4 EXAMPLE_IP. Wijzig EXAMPLE_IPnaar de werkelijke IP-adressen van uw knooppunten.

Hier ziet u een voorbeeld van succesvolle communicatie tussen twee knooppunten.

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

Stap 2: Installeer MongoDB in elk knooppunt van uw infrastructuur

Over het algemeen kun je het MongoDB-pakket van Ubuntu gebruiken, maar het is beter om de officiële community-repo te gebruiken omdat deze altijd up-to-date is. Deze repo bevat deze pakketten:

• mongodb-org , het groepspakket dat de vier componenten omvat.
• mongodb-org-server , dit bevat de mongoddaemon (primair proces dat gegevensaanvragen verwerkt).
• mongodb-org-mongos , dit bevat de mongosdaemon (routingservice voor gedeelde implementaties).
• mongodb-org-shell , dit is de mongo shellJavaScript-interface.
• mongodb-org-tools , enkele tools voor administratieve activiteiten.

Ga verder met het installeren van de pakketten.

Importeer de openbare sleutel in het pakketbeheersysteem.

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

Maak het lijstbestand voor 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

Update de pakketdatabase.

sudo apt-get update

Installeer het MongoDB-metapakket.

sudo apt-get install -y mongodb-org

Start de MongoDB-service.

sudo service mongod start

Nu kunt u de mongo shellin elke bash-sessie openen. Om dit te doen, moet je de mongoopdracht gebruiken. U wordt begroet door iets dat hierop lijkt.

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

Vergeet niet om de service af te sluiten met sudo service mongod stop, want later zullen we opnieuw beginnen mongodmet enkele parameters. Herhaal dit proces in alle 3 knooppunten van de set.

Stap 3: Configureer het toegangssleutelbestand

Het gebruik van een sleutelbestand dwingt twee concepten in het beheer van de Replica Set. De eerste is Internal Authentication. Standaard kunt u een mongo shellsessie starten zonder een gebruiker te gebruiken en deze sessie heeft volledige controle over de database, maar wanneer u een sleutelbestand gebruikt voor authenticatie mongo shell, bereikt uw sessie een status met de naam localhost exception. Met deze status kunt u alleen de beheerder en de replicaset maken. Het tweede concept is Role-Based Access Control, of met andere woorden autorisatie. Dit wordt afgedwongen om de bestuursniveaus voor de replicaset te bepalen.

Maak je keyfile

De keyfile is het wachtwoord dat in de set moet worden gebruikt, dit wachtwoord moet hetzelfde zijn voor alle leden van de set. Om de veiligheid te vergroten is het belangrijk om een ​​willekeurige sleutel te gebruiken met de tool van uw keuze.

De inhoud moet tussen de 6 en 1064 tekens lang zijn. Ook moet u de read onlytoestemming voor het sleutelbestand instellen.

chmod 400 PATH_OF_YOUR_KEYFILE

Plaats het sleutelbestand in elk ingesteld lid

Kopieer nu uw keyfile naar elk ingesteld lid, gebruik een consistente map voor toekomstige referentie en bewaar deze niet op een verwijderbaar medium.

Gebruik ook een map voor het bestand dat mongodtoegankelijk is.

Dwing af met behulp van de keyfile in de Replica-set

In deze stap moeten we de mongod daemon in elk ingesteld lid starten . Er zijn twee manieren om het mongodproces te starten: via een configuratiebestand of via de opdrachtregel. Beide zijn vrij eenvoudige methoden, maar voor het gemak gebruikt deze tutorial de opdrachtregelversie.

Command line configuratie

Gebruik de naam die u eerder in deze opdracht hebt gekozen.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Standaard mongoddraait het niet als een daemon. U moet de --forkparameter gebruiken of de gebruiken upstartom deze volledig als een daemon uit te voeren. In deze tutorial raden we het gebruik mongodals een daemon niet aan, zodat je de logs direct in je terminal kunt zien.

Opmerking: typ zorgvuldig de naam van de replicaset, want eenmaal gemaakt kunt u deze niet meer wijzigen.

Stap 4: Maak verbinding met de localhost-interface van een van de ingestelde leden

Opmerking: als u mongodals een niet-daemon-proces draait, moet u een andere ssh-verbinding openen om verder te werken.

U moet de mongoopdracht gebruiken om de mongo shell. Dit kan in elk lid van de set.

Op dit moment bevinden we ons in een staat die wordt genoemd localhost exception. Wanneer een keyfile wordt gebruikt om het mongodproces in te stellen, bent u verplicht om een ​​databasebeheerder te maken voordat u read-write-bewerkingen kunt toepassen, maar daar komen we later op terug.

Stap 5: De replicaset starten

Dit is een delicaat onderdeel, we gebruiken de opdracht rs.initiate()in de mongo shellstap 4, voordat we deze opdracht gebruiken, laten we deze bekijken.

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

Het eerste _idveld is een tekenreeks en moet overeenkomen met het veld --replSetdat eerder is doorgegeven mongod. Elke waarde van hostmoet ook de ip- of de domeinnaam zijn van elk lid van de replicaset. Vergeet niet de poort toe te voegen die de mongo-instantie in elk lid gebruikt.

Nu is het tijd om de opdracht uit te voeren met uw gegevens erop, dit zal een activeren electionen vervolgens wordt automatisch een primaire gekozen.

Hier moet u opmerken dat uw shell-cursor is gewijzigd in YOUR_SET_NAME:PRIMARY>of YOUR_SET_NAME:SECONDARY. Dit betekende dat het maken van een set een succes was.

Om door te gaan met werken, moet je de vinden primary, als je er niet op zit natuurlijk. Gebruik de rs.status()opdracht om de informatie van de replicaset weer te geven en zoek de primary. U zoekt de woning "stateStr" : "PRIMARY".

Stap 6: De beheerder maken

Nadat u de hebt gevonden primary, voert u de in mongo shellen voert u de volgende opdracht uit met uw gegevens.

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

Met het admin = db.getSiblingDB("admin")onderdeel kunnen we adminvanuit een andere database schrijven. Dit creëert een alias genaamd admin, zodat we in plaats daarvan commando's kunnen uitvoeren.

Als de operatie succesvol is, krijg je een melding dat de gebruiker is toegevoegd.

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

Op dit moment hebben we alleen een beheerder voor alle servers, maar het hebben van een Replica-set dwingt ons om een ​​gebruiker met de clusterAdminrol te hebben. We zullen een andere gebruiker maken met alleen die rol om zorgen te scheiden.

Stap 7: Verifiëren als beheerder

We hebben de limiet van de bereikt localhost exceptionen daarom moeten we de authenticatie wijzigen in de gebruiker die een stap eerder is gemaakt.

U kunt gebruikers binnen mongo shellde volgende wijzigen.

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

Als je nog geen verbinding hebt gemaakt met het mongo shellgebruik, gebruik dan deze opdracht.

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

U wordt op de hoogte gesteld van het wijzigen van een gebruiker en u kunt doorgaan naar de volgende stap.

Stap 8: De clustermaster maken

De clusterAdminrol geeft de gebruiker volledige controle over de replicaset. Het maken ervan is net zo eenvoudig als het aanmaken van de admin-gebruiker.

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

Merk op dat deze keer de rol wordt gewijzigd inclusterAdmin .

Stap 9: gegevens invoegen in de replicaset

Op dit moment hebben we 2 admin-gebruikers: een die volledige controle heeft over de server en een andere die toegang heeft tot administratieve taken op het ingestelde Replica-niveau. Het ontbreekt ons echter aan een gebruiker die toegang heeft tot het "gebruiken" van een database, dus we zullen die gebruiker nu aanmaken.

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

Merk op dat we deze keer het dbonderdeel veranderen , daar plaatsen we de database toegankelijk voor de gebruiker, in dit geval gebruiken we een database met de naam cars.

De database is nog niet aangemaakt. Om dit te doen, moet u enkele opdrachten typen om het impliciet te maken. Schakel over naar de carsdatabase.

use cars

U krijgt een melding krijgen: switched to db cars.

De database is nog steeds niet aangemaakt, daarvoor moet je er iets naar schrijven. We gebruiken het volgende voorbeeld.

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

Deze keer krijgt u bericht met WriteResult({ "nInserted" : 1 }).

Als je wilt, kun je alle objecten in de database ophalen met de find()methode:

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

Merk op dat _idhet in uw uitvoer anders zal zijn, maar de andere gegevens moeten hetzelfde zijn. Bij voldoende tijd worden deze gegevens gerepliceerd naar de andere leden.

Gevolgtrekking

Het maken van een replicaset kan in het begin een uitdaging zijn, omdat er veel informatie te begrijpen is, maar zodra u het idee erachter krijgt, kunt u het in een handomdraai inzetten, dus geef niet op als u het de eerste keer niet kunt bevatten. Houd er rekening mee dat Replica-set belangrijk is in MongoDB-beheer omdat het de mogelijkheid opent om geavanceerde functies zoals Load Balancing toe te voegen.