Vedligeholdelse af MongoDB Replica Sets i skyen ved hjælp af Ansible

Replikering er blevet bredt anvendt i databasesystemer for at sikre høj tilgængelighed af data ved at skabe redundans. Det er dybest set en strategi at lave en kopi af de samme data på forskellige kørende servere, der kan være på forskellige maskiner, så i tilfælde af fejl på hovedserveren, kan en anden bringes i stand til at fortsætte med serveringen.

Et replikasæt er en gruppe af MongoDB-instanser, der vedligeholder det samme sæt data. De er grundlaget for produktionsinstallationer. Replikering er fordelagtig ved, at data altid er tilgængelige fra en anden server, bare hvis hovedserversystemet svigter. Desuden forbedrer det læsegennemløbet ved at gøre det muligt for en klient at sende læseanmodning til forskellige servere og få svar fra den nærmeste.

Et replikasæt udgør adskillige databærende noder, som kunne være hostet i forskellige maskiner og en arbiter-knude. En af disse databærende noder er mærket som den primære, mens de andre er sekundære noder. Den primære node modtager alle skriveoperationer og replikerer derefter dataene til de andre noder, efter at skriveoperationen er afsluttet og ændringerne registreret i en oplog.

En voldgiftsdommer er en yderligere instans, der ikke vedligeholder et datasæt, men som giver et quorum i et replikasæt ved at reagere på hjerteslag og valganmodninger fra andre replikasætmedlemmer. De reducerer således omkostningerne ved at vedligeholde et replikasæt i stedet for et fuldt funktionelt replikasætmedlem med et datasæt.

Automatisk failover

En primær node kan svigte på grund af nogle årsager, såsom strømafbrydelser eller netværksafbrydelse, og derved ikke i stand til at kommunikere med de andre medlemmer. Hvis kommunikationen er afbrudt i mere end den konfigurerede period med valgTimeoutMillis, opfordrer en af de sekundære til et valg for at nominere sig selv som den nye primære. Hvis valget er gennemført og vellykket, fortsætter klyngen med den normale drift. I denne periode kan der ikke udføres skriveoperationer. Læseforespørgslerne kan dog konfigureres til at gå som normalt på de sekundære, mens den primære er offline.

For en optimal replikeringsproces bør mediantiden, før klyngen vælger en ny primær, højst være 12 sekunder med standardindstillinger for replikeringskonfiguration. Dette kan blive påvirket af faktorer såsom netværksforsinkelse, som kan forlænge tiden, og derfor bør man tage hensyn til klyngens arkitektur for at sikre, at denne tid ikke er sat for højt.

Værdien for choiceTimeoutMillis kan sænkes fra standardværdien 10000 (10 sekunder), så den primære kan detekteres allerførst under meget hurtig. Dette kan dog være at udskrive valget ofte på grund af selv mindre faktorer, såsom midlertidig netværksforsinkelse, selvom den primære knude er sund. Dette vil føre til problemer såsom rollbacks for skriveoperationer.

Ansible for replikasæt

Som nævnt kan et replikasæt have medlemmer fra forskellige værtsmaskiner, hvilket gør det mere komplekst at vedligeholde klyngen. Vi har brug for en enkelt platform, hvorfra dette replikasæt nemt kan vedligeholdes. Ansible er et af de værktøjer, der giver et bedre overblik til at konfigurere og administrere et replikasæt. Hvis du er ny inden for ansible, bedes du få en hurtig opsummering fra denne artikel for at forstå det grundlæggende, såsom at oprette en spillebog.

Konfigurationsparametre

arbiter_at_index: dette definerer arbiterens position på listen over replikasætmedlemmer. En dommer husker ikke har nogen data som de andre medlemmer og kan ikke bruges som den primære node. Det er kun tilgængeligt at oprette et beslutningsdygtigt under valget. For eksempel hvis du har et lige antal medlemmer, er det godt at tilføje en dommer, så hvis stemmerne er lige, tilføjer den en 1 for at blive et vindende medlem. Værdien, der skal tildeles, skal være et heltal.
chaining_allowed: Dette tager en boolesk værdi og definerer, om de andre sekundære medlemmer skal replikere fra de andre sekundære medlemmer, hvis kæde _allowed =true. Ellers, hvis kæde _allowed =false, kan de andre sekundære medlemmer kun replikere fra den primære. Standardværdien er sand.
election_timeout_secs: som standard er værdien 10000 (tager en heltalsværdi). Det er tiden i millisekunder til at detektere, hvornår den primære knude ikke kan nås eller snarere ikke kommunikerer til de andre medlemmer og derfor udløser et valg. Indstil dette til en medianværdi på 12 sekunder. Hvis den er sat for højt, vil det tage lang tid, før den primære fiasko opdages og dermed længere tid at gennemføre et valg. Da dette påvirker skriveoperationen, kan du ende med at miste en masse data i den periode. På den anden side, hvis det er sat for lavt, vil der være hyppig udløsning af et valg, selv når sagen ikke er så alvorlig, og primærvalget stadig nås. Som et resultat vil du have så mange tilbagerulninger for skriveoperationer, der på et tidspunkt kan føre til dårlig dataintegritet eller inkonsistens.
heartbeat_timeout_secs: Replika-sæt skal kommunikere med hinanden før et valg ved at sende et signal, der kaldes et hjerteslag. Medlemmerne skal derefter reagere på denne signalering inden for en specifik periode, som som standard er sat til 10 sekunder. Heartbeat_timeout_secs er det antal sekunder, replikasætmedlemmerne venter på et vellykket hjerteslag fra hinanden, og hvis et medlem ikke reagerer, er det markeret som utilgængeligt. Dette gælder dog kun for protokolversion 0. Værdien for dette er derfor et heltal.
login_host: Dette er værten, der huser login-databasen. Som standard for MongoDB er localhost.
login_database: standarden er administratoren og er der, hvor loginoplysningerne gemmes.(tager en strengværdi)
login_user: brugernavnet, som godkendelsen skal udføres med.(tager en strengværdi)
login_adgangskode: adgangskoden til at godkende bruger med. (tager en strengværdi)
login_port: Dette er MongoDB-porten, som værten kan logge på. (tager en heltalsværdi)
medlemmer: definerer en liste over replikasætmedlemmer. Det er en streng adskilt af komma eller en yaml-liste, dvs. mongodb0:27017,mongodb2:27018,mongodb3:27019... Hvis der ikke er noget portnummer, antages 27017.
protokolversion: tager et heltal, der definerer versionen af replikeringsprocessen. Enten 0 eller 1
replika_sæt: dette er en strengværdi, der definerer navnet på replikasættet.
ssl: boolesk værdi, der definerer, om der skal bruges SSL-forbindelse, når der oprettes forbindelse til databasen eller ej.
ssl_certs_reqs: dette angiver, om der kræves et certifikat fra den anden side af forbindelsen, og om der vil være behov for at validere det, hvis det leveres. Valgene for dette er CERT_NONE, CERT_OPTIONAL og CERT_REQUIRED. Standarden er CERT_REQUIRED.
valider: tager en boolesk værdi, der definerer, om der skal udføres en grundlæggende validering på den angivne replikasætkonfiguration. Standardværdien er sand.

Oprettelse af et MongoDB-replikasæt ved hjælp af Ansible

Her er et simpelt eksempel på opgaver til opsætning af et replikasæt i ansible. Lad os kalde denne fil 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 vores playbook kan vi kalde opgaverne som

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

Hvis du kører dette i din playbook, ansible-playbook -i inventory.txt -c ssh mongodbcreateReplcaSet.yaml vil du blive præsenteret for et svar, om replikasættet er blevet oprettet eller ej. Hvis nøglen mongodb_replicaset returneres med en værdi af succes og en beskrivelse af replikasættet, der er blevet oprettet, så er du klar til at gå.

Konklusion

I MongoDB er det generelt kedeligt at konfigurere et replikasæt til de mongod-forekomster, der kan hostes af forskellige maskiner. Ansible giver dog en simpel platform til at gøre det samme ved blot at definere nogle få parametre som diskuteret ovenfor. Replikering er en af de processer, der sikrer kontinuerlig applikationsdrift, og bør derfor konfigureres godt ved at indstille et multiple antal medlemmer i produktionsverdenen. En voldgiftsdommer bruges til at skabe et quorum under valgprocessen, og bør derfor inkluderes i konfigurationsfilen ved at definere dens position.