Underhålla MongoDB Replica Sets i molnet med Ansible

Replikering har använts i stor utsträckning i databassystem för att säkerställa hög tillgänglighet av data genom att skapa redundans. Det är i grunden en strategi att göra en kopia av samma data i olika körande servrar som kan finnas i olika maskiner så att, i händelse av fel på huvudservern, en annan kan fås att fortsätta med serveringen.

En replikuppsättning är en grupp av MongoDB-instanser som upprätthåller samma uppsättning data. De är grunden för produktionsinstallationer. Replikering är fördelaktigt genom att data alltid är tillgänglig från en annan server ifall huvudserversystemet skulle misslyckas. Dessutom förbättrar den läskapaciteten genom att en klient kan skicka läsbegäran till olika servrar och få svar från den närmaste.

En replikuppsättning utgörs av flera databärande noder som kan finnas på olika maskiner och en arbiternod. En av dessa databärande noder är märkta som den primära medan de andra är sekundära noder. Den primära noden tar emot alla skrivoperationer och replikerar sedan data till de andra noderna efter att skrivoperationen har slutförts och ändringarna registrerats i en oplog.

En skiljedomare är en ytterligare instans som inte upprätthåller en datamängd utan ger ett kvorum i en replikuppsättning genom att svara på hjärtslag och valförfrågningar från andra replikuppsättningsmedlemmar. De minskar alltså kostnaden för att underhålla en replikuppsättning snarare än en fullt fungerande replikuppsättningsmedlem med en datamängd.

Automatisk failover

En primär nod kan misslyckas på grund av vissa orsaker såsom strömavbrott eller nätverksavbrott och därigenom inte kunna kommunicera med de andra medlemmarna. Om kommunikationen är avstängd för mer än den konfigurerade period för valTimeoutMillis, kräver en av sekundärerna ett val för att nominera sig själv som ny primär. Om valet är avslutat och framgångsrikt fortsätter klustret med den normala verksamheten. Under denna period kan inga skrivoperationer utföras. Läsfrågorna kan dock konfigureras att gå som vanligt på sekundärerna medan den primära är offline.

För en optimal replikeringsprocess bör mediantiden innan klustret väljer en ny primär högst vara 12 sekunder med standardinställningar för replikeringskonfiguration. Detta kan påverkas av faktorer som nätverkslatens som kan förlänga tiden och därför bör man ta hänsyn till klustrets arkitektur för att säkerställa att denna tid inte är inställd för högt.

Värdet för choiceTimeoutMillis kan sänkas från standardvärdet 10000 (10 sekunder) och därför kan den primära detekteras allra först under mycket snabb. Detta kan dock utlysa valet ofta för även mindre faktorer som tillfällig nätverkslatens även om den primära noden är frisk. Detta kommer att leda till problem som återställningar för skrivoperationer.

Ansible for Replica Sets

Som nämnts kan en replikuppsättning ha medlemmar från olika värddatorer, vilket gör det mer komplicerat att underhålla klustret. Vi behöver en enda plattform från vilken denna replikuppsättning kan underhållas med lätthet. Ansible är ett av verktygen som ger en bättre överblick för att konfigurera och hantera en replikuppsättning. Om du är ny på ansible, vänligen ha en snabb sammanfattning från den här artikeln för att förstå grunderna som att skapa en spelbok.

Konfigurationsparametrar

arbiter_at_index: detta definierar arbiterns position i replikuppsättningens medlemslista. En arbiter remember har inga data som de andra medlemmarna och kan inte användas som den primära noden. Det är endast tillgängligt för att skapa beslutförhet under valet. Om du till exempel har ett jämnt antal medlemmar är det bra att lägga till en domare så att om rösterna är lika, lägger den till en 1 för att bli en vinnande medlem. Värdet som ska tilldelas bör vara ett heltal.
chaining_allowed: Detta tar ett booleskt värde och definierar om de andra sekundära medlemmarna ska replikera från de andra sekundära medlemmarna om kedjan _allowed =true. Annars, om kedjan _allowed =false, kan de andra sekundära medlemmarna bara replikera från den primära. Standardvärdet är sant.
election_timeout_secs: som standard är värdet 10000 (tar ett heltalsvärde). Det är tiden i millisekunder för att detektera när den primära noden inte är nåbar eller snarare inte kommunicerar med de andra medlemmarna och därför utlöser ett val. Ställ in detta på ett medianvärde på 12 sekunder. Om det sätts för högt kommer det att ta lång tid innan det primära misslyckandet upptäcks och därmed längre tid att genomföra ett val. Eftersom detta påverkar skrivoperationen kan du förlora mycket data under den perioden. Å andra sidan, om det sätts för lågt, kommer det ofta att utlösas ett val även när fallet inte är så allvarligt och primärvalet fortfarande kan nås. Som ett resultat kommer du att få så många återställningar för skrivoperationer som vid något tillfälle kan leda till dålig dataintegritet eller inkonsekvens.
heartbeat_timeout_secs: Replikuppsättningar måste kommunicera med varandra före ett val genom att skicka en signal som kallas hjärtslag. Medlemmarna måste sedan svara på denna signalering inom en specifik period som som standard är inställd på 10 sekunder. Heartbeat_timeout_secs är antalet sekunder som replikuppsättningens medlemmar väntar på ett lyckat hjärtslag från varandra och om en medlem inte svarar markeras den som otillgänglig. Detta gäller dock endast för protokollversion 0. Värdet för detta är därför ett heltal.
login_host: Det här är värden som innehåller inloggningsdatabasen. Som standard för MongoDB är localhost.
inloggningsdatabas: standard är admin och det är där inloggningsuppgifterna lagras.(tar ett strängvärde)
login_user: användarnamnet som autentiseringen ska göras med.(tar ett strängvärde)
login_password: lösenordet att autentisera användare med. (tar ett strängvärde)
login_port: Detta är MongoDB-porten som värden kan logga in på. (tar ett heltalsvärde)
medlemmar: definierar en lista över replikuppsättningsmedlemmar. Det är en sträng separerad med kommatecken eller en yaml-lista, dvs mongodb0:27017,mongodb2:27018,mongodb3:27019... Om det inte finns något portnummer antas 27017.
protocol_version: tar ett heltal som definierar versionen av replikeringsprocessen. Antingen 0 eller 1
replikuppsättning: detta är ett strängvärde som definierar namnet på replikuppsättningen.
ssl: booleskt värde som definierar om SSL-anslutning ska användas vid anslutning till databasen eller inte.
ssl_certs_reqs: detta anger om ett certifikat krävs från den andra sidan av anslutningen och om det kommer att behövas valideras om det tillhandahålls. Valen för detta är CERT_NONE, CERT_OPTIONAL och CERT_REQUIRED. Standard är CERT_REQUIRED.
validera: tar ett booleskt värde som definierar om någon grundläggande validering ska göras på den angivna replikuppsättningskonfigurationen. Standardvärdet är sant.

Skapa en MongoDB-replikuppsättning med Ansible

Här är ett enkelt exempel på uppgifter för att sätta upp en replikuppsättning i ansible. Låt oss kalla den här filen tasks.yaml

# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_user: admin
    login_password: root
    replica_set: replica0
    arbiter_at_index:2
    election_timeout_secs:12000
    members:
    - mongodb1:27017
    - mongodb2:27018
    - mongodb3:27019
  when: groups.mongod.index(inventory_hostname) == 0

# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3001
    login_user: admin
    login_password: root
    login_database: admin
    replica_set: replica0
    members: localhost:3000
    validate: yes

- name: Ensure replicaset replica1 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3002
    login_user: admin
    login_password: secret
    login_database: root
    replica_set: replica1
    members: localhost:3001
    validate: yes

I vår lekbok kan vi kalla uppgifterna som

---
- hosts: ansible-test
  remote_user: root
  become: yes
  Tasks:
- include: tasks.yml

Om du kör detta i din playbook, ansible-playbook -i inventory.txt -c ssh mongodbcreateReplcaSet.yaml kommer du att få ett svar om replikuppsättningen har skapats eller inte. Om nyckeln mongodb_replicaset returneras med ett värde av framgång och en beskrivning av replikuppsättningen som har skapats, är du bra att gå.

Slutsats

I MongoDB är det i allmänhet tråkigt att konfigurera en replikuppsättning för mongod-instanserna som kan finnas på olika maskiner. Ansible tillhandahåller dock en enkel plattform för att göra detsamma genom att bara definiera några parametrar som diskuterats ovan. Replikering är en av processerna som säkerställer kontinuerlig applikationsdrift och bör därför konfigureras väl genom att ställa in ett flertal medlemmar i produktionsvärlden. En skiljedomare används för att skapa ett beslutfört under valprocessen och bör därför inkluderas i konfigurationsfilen genom att definiera dess position.