🥇Seisakuvaba MongoDB migreerimine Kubernetesesse

See artikkel jätkab meie viimast materjali RabbitMQ migratsioonist ja on pühendatud MongoDB-le. Kuna hooldame mitmeid Kubernetes ja MongoDB klastreid, on loodud loomulik vajadus migreerida andmeid ühest installeerimisest teise ja teha seda katkestusteta. Peamised stsenaariumid on sama: MongoDB üleviimine virtuaalsest/füüsilisest serverist Kubernetesesse või MongoDB üleviimine ühe Kubernetes klastris (ühes namespaces teise).

Meie retsept on mõeldud olukordadesse, kus vana MongoDB klaster (näiteks koosneb 3 sõlmest ja asub kas juba K8s-is või vanadel serveritel) töötab, millega töötab Kuberneteses hostitud rakendus:

Kuidas me selle klastri viime uude productioni Kuberneteses?

Teooria

Üldine migratsioonialgoritm on sarnane olukorras kirjeldatule RabbitMQ puhul.

Oluline on märkida, et üleminekuks peavad MongoDB ja Kubernetes serverid olema samas võrgus. MongoDB klastri sõlmed suhtlevad omavahel vanade serverite IP-de kaudu (kus asuvad vanad MongoDB installeerimised) ja K8s MongoDB pod'ide DNS-nimede kaudu. Seetõttu peavad raudserveritel (vana installeerimisega) suunama teed pod'idele ning seejärel seadistama need kasutama Kuberneteses töötavat DNS-serverit (või siis kirjutama vajalikud nimed sisse, kuigi sellise võimaluse suhtes on parem hoiduda). /etc/hosts, kuigi selliseid võimalusi on üldjuhul parem vältida).

Järgmine samm on tõsta MongoDB klaster K8s pod'idesse. Meie puhul koosneb andmebaasi klaster 3 sõlmest ja iga sõlm asub eraldi K8s pod'is — siiski, nende arv võib olla ka teine. ConfigMap'is peab olema määratud vana installeerimise MongoDB meistri aadress: siis hakkavad K8s pod'ides olevad MongoDB sõlmed kohe sünkroonima.

Kui kõik pod'id on tõusnud, moodustub 6 sõlmega MongoDB klaster:

Pange tähele, et pod'id tõusevad kaua, kuna iga pod käivitatakse kordamööda ja käivitamise ajal sünkroonivad nad andmeid meistriga.

Pärast seda saab rakenduse tõsta uute MongoDB serverite kasutamisele:

Ja jääb vaid eemaldada vanad sõlmed MongoDB klastrist, pärast mida saab üleviimist pidada lõpetatuks:

Seda skeemi kasutame sageli tootmis keskkonnas ja selle mugavuse tagamiseks oleme selle rakendanud moodulis addon-operator (seda utiliiti me kuulutasime hiljuti), mis võimaldab levitada tüüpilisi MongoDB konfiguratsioone paljudes klastrites. Meie moodulite avaldamine on plaanis teha varsti, kuid seni esitame eraldi juhiseid, millega saab pakutavat lahendust proovida ja ilma addon-operatorita.

Proovime praktikas

Nõuded

Rekvisiidid:

Kubernetes klaster (sobib ka minikube);
MongoDB klaster (mida võib olla käitatakse bare metalil või loodud tavaliseks klastriks Kubernetesis ametlikust Helm chart'ist).

Allpool toodud näites nimetatakse vana MongoDB klaster mongo-old ja paigaldatakse samasse Kubernetes klastrisse, kus me hiljem paigaldame ka uue (mongo-new).

Valmistame vana klastrit

1. Näiteks, et demonstreerida antud skeemi toimimist, loome Kuberneteses "vana" (st migratsiooniks ette nähtud) MongoDB klastrila, mis tegelikult võib asuda ka eraldi serverites väljaspool K8s. Selleks laadime alla Helm-chart'i:

helm fetch --untar stable/mongodb-replicaset

… ja teeme natuke muudatust, seadistades autentimise:

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

Samuti on values.yaml võimalik seadistada sertifikaate ja palju muud.

2. Installime chart'i:

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

Pärast seda käivitatakse testimiseks "vana" MongoDB installatsioon:

kubectl --namespace=mongo-old get pods

Logime pod'i, millel on selle meister, ja loome testandmebaasi:

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 meistriks on mongo-old-mongodb-replicaset-0. Siiski, selle küsimuse mugavamaks lahendamiseks väljastatakse pärast Helm-chart'i paigaldamist käsk, kuidas määrata MASTER_POD. Minu puhul (3 sõlmega) näeb see välja järgmiselt: 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

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 installatsiooni ettevalmistamine, mille andmed kantakse üle, valmis.

MongoDB klusteri migratsioon

Nüüd loome uue MongoDB installatsiooni, mis asub Kuberneteses ja mida kasutatakse tootmises.

NB: Tähelepanu, et tuleb kasutada sama MongoDB versiooni, mis oli enne. Vastasel juhul on ühilduvuse probleemide risk.

Samuti eelmine jaotis (kus me imiteerisime «vana» MongoDB installatsiooni), võtame juba mainitud Helm chart'i (käsk helm fetch) ja seadistame autentimise ning muud parameetrid, kui need on kasutusel. Samuti parandame faili init/on-start.sh, ajutiselt lisades sellele 165. reale meistrite aadressi, mis saadi eelmisel etapil (või mis on teile tuntud MongoDB installatsioonilt eraldi serverites):

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

Oleme valmis uue MongoDB installatsiooni loomiseks:

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

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

Nüüd teeme exec uue pod'i ja vaatame andmebaaside nimekirja:

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

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

Praeguseks on juba võimalik rakendus uuele klastrile üle lülitada, kuid migratsiooni lõpuleviimiseks on veel mõned sammud.

Failist init/on-start.sh uus installatsioon eemaldame meie lisatud rea:

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

Nüüd siseneme vana klasteri meisterrežiimi ja „tõukame” selle välja — siis määratakse klastris uus meister. Siseneme MongoDB meistriga podi:

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

Pärast seda muutame sõlmede prioriteedid ja vahetame meistri:

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 oleme prioriteedid muutnud, saab mehistriks see sõlm, mida me vajame.

NB: Vaikimisi on kõikide MongoDB sõlmede prioriteet 1. Ülal tõstame vajaliku sõlme prioriteedi 2. Nii, et üldiseks meistriks saab kindlasti uue klastriga liige. Rohkem teavet nende mehhanismide kohta MongoDB-s saate lugeda dokumentatsioonis.

Käivitame vana MongoDB installatsiooni välja, pärast seda siseneme uue meistri 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 saab migratsiooni lugeda lõpetatuks: oleme edukalt lülitunud vana MongoDB klastrilt uuele!

Kokkuvõte

Kirjeldatud skeem sobib praktiliselt kõikide juhtumite jaoks, kus tuleb MongoDB-d üle kanda või lihtsalt uude klastrisse kolida.

Peamine nüanss ülekande juures on vajadus suunata uute pod’ide IP-aadressid vana MongoDB installatsiooni serveritele, kui see asub väljaspool K8s, ja nende õige nimetus DNS-is (või /etc/hosts). Antud näites neid samme ei olnud vajalik, kuna migratsioon toimus sama Kubernetes klastrite erinevate nimede vahel.