🥇Probleemivaba MongoDB migreerimine Kuberneteses

See artikkel jätkab meie hiljutist materjali RabbitMQ migreerimisest ja on pühendatud MongoDB-le. Kuna me haldame mitmeid Kubernetes ja MongoDB klastri, on tekkinud loomulik vajadus migreerida andmed ühest installatsioonist teise ja teha seda ilma seiskamiseta. Peamised stsenaariumid jäävad endiseks: MongoDB üleviimine virtuaalsest / füüsilisest serverist Kubernetesesse või MongoDB üleviimine ühe Kubernetes klastri piires (ühe nimede ruumist teise).

Meie retsept on mõeldud juhtudel, kui vana MongoDB klastri (näiteks 3 sõlme ja juba K8s-s või vanadel serveritel) tõhusalt töötab ja rakendus, mis töötab Kuberneteses:

Kuidas me plaanime sellise klastri uude tootmisüksusesse Kubernetesesse migreerida?

Teooria

Üldine migreerimise algoritm on sarnane kirjeldatud olukorraga RabbitMQ puhul.

Oluline on märkida, et migreerimise võimaldamiseks peavad MongoDB ja Kubernetes serverid olema samas võrgus. MongoDB klastri sõlmed suhtlevad omavahel vanade serverite IP-aadresside kaudu (kus vanad MongoDB installatsioonid asuvad) ja K8s MongoDB pod'ide DNS-nimedega. Seetõttu tuleb vanadel serveritel (kus on vanad installatsioonid) suunata marsruudid pod'ide poole ja seejärel seadistada need kasutama Kuberneteses töötavat DNS-serverit (või siis kirjutada vajalikud nimed) /etc/hosts, kuigi üldjuhul on selliste võimaluste vältimine parem).

Järgmine samm on käivitada MongoDB klaster K8s pod'ides. Meie puhul koosneb andmebaasi klaster 3 sõlmest ja iga sõlm asub eraldi K8s pod'is — kuigi nende arv võib olla ka erinev. ConfigMap'is tuleb määrata vana installatsiooni MongoDB peaserveri aadress: siis hakkavad K8s pod'ides asuvad MongoDB sõlmed kohe selle järgi sünkroniseerima.

Pärast seda, kui kõik pod'id on käivitunud, moodustub MongoDB klaster, mis koosneb 6 sõlmest:

Pange tähele, et pod'id käivituvad kaua, kuna iga pod käivitatakse järjestikku ja käivitamisel sünkroniseerivad nad andmed peaserveriga.

Pärast seda saab rakendust lülitada uute MongoDB serverite kasutamisele:

Ja jääb vaid kustutada vanad sõlmed MongoDB klastrist, pärast mida saab migreerimise lõppenuks lugeda:

Seda skeemi rakendame me sageli tootmises ja mugavuse nimel oleme selle rakendanud addon-operator mooduli raames seda utiliiti me), mis võimaldab levitada MongoDB tüüpilisi konfiguratsioone paljude klastrite vahel. Me plaanime oma moodulite avaldamise lähitulevikus, kuid esitleme eraldi juhiseid, millega saab pakkuda lahendust toimingus ja ilma addon-operatorit kasutamata.

Proovime praktikas

Nõuded

Andmed:

Kubernetes klaster (sobib ka minikube);
MongoDB klaster (võib olla paigaldatud nii bare metal'ile kui ka tavalise klastri kujul Kuberneteses ametlikust Helm'i kaardist).

Allpool kirjeldatud näites nimetatakse vana MongoDB klastri mongo-old ja see paigaldatakse samasse Kubernetes klastrisse, kuhu paigaldame ka uue (mongo-new).

Valmistame vana klastrit

1. Näite jaoks, mis demonstreerib kirjeldatud skeemi toimimist, loome „vana” (st migratsioonile kuuluva) MongoDB klastri otse Kuberneteses (reaalsuses võib see asuda ka eraldi serverites väljaspool K8s). Selleks laadime Helm'i kaardi alla:

helm fetch --untar stable/mongodb-replicaset

… ja muudame seda veidi, seadistades autoriseerimise:

auth:
  enabled: true
  adminUser: mongo
  adminPassword: pa33w0rd
  # metricsUser: metrics
  # metricsPassword: password
  # key: keycontent
  # existingKeySecret:
  # existingAdminSecret:
  # exisitingMetricsSecret:

Samuti saab values.yaml seadistada sertifikaate ja palju muud.

2. Paigaldame kaardi:

helm install . --name mongo-old --namespace mongo-old

Pärast seda käivitatakse testimise "vana" MongoDB installeerimine:

kubectl --namespace=mongo-old get pods

Siseneme pod'i, kus on selle master ja loome testi andmebaasi:

kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')
use music
db.artists.insert({ artistname: "The Tea Party" })
show dbs

Erinevatesse pod'idesse sisenedes selgitasin välja, et master on mongo-old-mongodb-replicaset-0. Kuid mugavama lahenduse leidmiseks pärast Helm'i kaardi paigaldamist antakse käsk, kuidas määrata MASTER_POD. Minu juhul (3 sõlme) on see selline: mongo-old for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done

Nüüd on vana MongoDB installeerimise ettevalmistus, mille andmed kantakse üle, valmis.

MongoDB klastri migratsioon

Nüüd paigaldame uue MongoDB installeerimise, mis asub Kuberneteses ja mida rakendus kasutab tootmises.

: Jätan meelde, et tuleb kasutada sama MongoDB versiooni, mis oli enne. Vastasel juhul on oht, et võivad tekkida ühilduvusprobleemid.

NBSarnase ülesehituse kohaselt eelnevale jaotisele (kus simuleerisime "vana" MongoDB installeerimist) võtame juba mainitud Helm'i kaardi (käsk

helm fetch helm fetch) ja seadistame autoriseeringu ning muud parameetrid, kui need on kasutusel. Samuti parandame faili init/on-start.sh, ajutiselt lisades selle 165. reale meistri aadressi, mis saadi eelneval etapil (või see on teile teada MongoDB installimisel eraldi serverites):

peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'

Me oleme valmis looma uut MongoDB installatsiooni:

helm install . --name mongo-new --namespace mongo-new

Ootame, kuni kõik pod'id käivitatakse (kui andmeid on palju, võib käivitamine kesta tunde):

Nüüd teeme exec uude pod'i ja vaatame andmebaaside loendit:

kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo

Kaks MongoDB klastrit on ühendatud üheks, mis koosneb 6 sõlmest.

Praegu on juba võimalik rakendust uuele klastrile üle viia, kuid migratsiooni lõpetamiseks on veel mõned sammud.

Failist init/on-start.sh eemaldame meie lisatud rea uues installatsioonis:

peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'

Nüüd siseneme vana klastrimeistri juurde ja 'deposeerime' selle — siis määratakse klastris uus meister. Siseneme MongoDB meistripodi:

kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')

Pärast seda muudame sõlmede prioriteete ja vahetame meistrit:

cfg = rs.conf()
cfg.members[5].priority = 2
rs.reconfig(cfg)
rs.stepDown(120)

Praegune sõlm ei ole enam meister — toimub uue valimine. Kuna me muutsime prioriteete, saab mehitatud meie soovitud sõlm.

NB: Vaikimisi on kõigil MongoDB sõlmedel prioriteet 1. Ülal tõstame soovitud sõlme prioriteedi 2-ni. Seega, ühise meistrina muutub kindlasti uue klastriga liige. Täiendavalt MongoDB mehhanismide kohta lugeda saab dokumentatsioon.

Lülitame välja vana MongoDB installatsiooni, seejärel siseneme uue meistri juurde ja eemaldame vanad sõlmed:

rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")

Pärast seda võib migratsiooni lugeda lõpetatuks: oleme edukalt üle viidud vanalt MongoDB klastrilt uuele!

Summary

Käesolev skeem sobib praktiliselt kõikides olukordades, kus tuleb MongoDB üle kanda või lihtsalt liikuda uude klastrisse.

Peamine nüanss ülekandel on vajadus suunata uute pod'ide IP-aadressid vana MongoDB installatsiooni serveritesse, kui see asub väljaspool K8s, ja nende õige nimetus DNS-is (või /etc/hosts). Antud näite puhul ei olnud neid samme vaja, kuna migreerimine toimus sama Kubernetes klastrite erinevate nimede ruumide vahel.