🥇Bezproblémová migrácia MongoDB do Kubernetes

Tento článok nadväzuje na náš nedávny materiál o migrácii RabbitMQ a je venovaný MongoDB. Keďže spravujeme množstvo klastrov Kubernetes a MongoDB, prirodzene sme narazili na potrebu migrovať údaje z jednej inštalácie na druhú a robiť to bez prestojov. Hlavné scenáre zostávajú rovnaké: presun MongoDB z virtuálneho/fyzického servera do Kubernetes alebo presun MongoDB v rámci jedného klastrového Kubernetes (z jedného menného priestoru do druhého).

Naším receptom je určené pre prípady, keď funguje starý klaster MongoDB (napríklad z 3 uzlov, ktorý sa nachádza buď už v K8s, alebo na starých serveroch), s ktorým pracuje aplikácia umiestnená v Kubernetes:

Ako budeme prevádzať taký klaster do nového produkčného prostredia v Kubernetes?

Teória

Celkový algoritmus migrácie je podobný tomu, ktorý bol popísaný v situácii s RabbitMQ.

Je dôležité poznamenať, že na umožnenie presunu musia byť servery s MongoDB a Kubernetes v tej istej sieti. Uzly klastrov MongoDB sa budú medzi sebou komunikovať cez IP adresy starých serverov (kde sa nachádzajú staré inštalácie MongoDB) a cez DNS názvy podov s MongoDB v K8s. Preto na fyzických serveroch (so starými inštaláciami) bude potrebné presmerovať trasy na podom a potom ich nastaviť na používanie DNS servera, ktorý beží v Kubernetes (alebo zapísať potrebné názvy do /etc/hosts, hoci v obecných prípadoch je lepšie tejto možnosti sa vyhnúť).

Ďalším krokom je vytvorenie klasteru MongoDB v podoch Kubernetes. V našom prípade sa klaster DB skladá z 3 uzlov a každý uzol sa nachádza v samostatnom pode K8s - aj keď ich počet môže byť iný. V ConfigMape je potrebné uviesť adresu majstra MongoDB zo starej inštalácie: potom uzly MongoDB, nachádzajúce sa v podoch v K8s, okamžite začnú synchronizáciu s ním.

Po tom, čo sa všetky podi spustia, vytvorí sa klaster MongoDB z 6 uzlov:

Všimnite si, že podi sa budú dlho spúšťať, pretože každý pod sa spúšťa postupne a v momente spúšťania synchronizuje údaje s majstrom.

Po tomto je možné prepnúť aplikáciu na používanie nových serverov MongoDB:

A ostáva len odstrániť staré uzly z klastru MongoDB, po čom sa presun môže považovať za ukončený:

Túto schému často používame v produkcii a pre pohodlnosť jej využívania sme ju implementovali v rámci modulu addon-operator (túto utilitu sme nedávno oznámili), ktorá umožňuje rozšíriť štandardné konfigurácie MongoDB na viaceré klastre. Publikovanie našich modulov plánujeme čoskoro, zatiaľ predstavujeme jednotlivé pokyny, s ktorými si môžete vyskúšať navrhované riešenie v akcii a bez použitia addon-operator.

Skúšame v praxi

Požiadavky

Údaje:

Kubernetes cluster (vhodný aj minikube);
MongoDB cluster (môže byť nasadený na bare metal alebo vytvorený ako bežný cluster v Kubernetes z oficiálneho Helm chartu).

V nižšie popísanom príklade bude starý cluster s MongoDB nazvaný mongo-old a nainštalovaný v tom istom Kubernetes klustri, kde neskôr nainštalujeme aj nový (mongo-new).

Pripravujeme starý cluster

1. Pre príklad demonštrujúci popísanú schému v akcii vytvoríme "starý" (t.j. podliehajúci migrácii) cluster MongoDB priamo v Kubernetes (v skutočnosti môže byť aj na samostatných serveroch mimo K8s). Na to si stiahneme Helm chart:

helm fetch --untar stable/mongodb-replicaset

… a trochu ho upravíme, nastavením autorizácie:

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

Taktiež v values.yaml je možné nastaviť certifikáty a mnoho ďalšieho.

2. Nainštalujeme chart:

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

Po tomto bude spustená testovacia "staršia" inštalácia MongoDB:

kubectl --namespace=mongo-old get pods

Prihlásime sa do podu s jeho majstrom a vytvoríme testovaciu databázu:

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

Pri práci v rôznych podech som zistil, že majstrom je mongo-old-mongodb-replicaset-0. Avšak, pre jednoduchšie riešenie tejto otázky po nainštalovaní Helm chartu sa zobrazí príkaz, ako určiť MASTER_POD. V mojom prípade (pre mongo-old z 3 uzlov) to vyzerá takto:

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

Tým je príprava starej inštalácie MongoDB, ktorej údaje budú prenášané, hotová.

Migrácia clusteru MongoDB

Teraz rozvineme novú inštaláciu MongoDB, ktorá bude umiestnená v Kubernetes a používaná aplikáciou v produkcii.

Poznámka: Upozorňujem, že by sa mala používať rovnaká verzia MongoDB, akú sme používali predtým. V opačnom prípade hrozí riziko problémov s kompatibilitou.

Podobne ako v predchádzajúcej časti (kde sme imitovali "starú" inštaláciu MongoDB) vezmeme už spomínaný Helm chart (príkazom helm fetch) a nastavíme autorizáciu, ako aj iné parametre, ak sa používajú. Okrem toho opravíme súbor init/on-start.sh, dočasne pridáme na 165. riadok adresu majstra, získanú v predchádzajúcom kroku (alebo známu z inštalácie MongoDB na oddelených serveroch):

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

Sme pripravení na vytvorenie novej inštalácie MongoDB:

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

Čakáme, kým sa spustia všetky pod, (ak sú dáta veľké, ich spustenie môže trvať hodiny):

Teraz robíme exec do nového podu a pozeráme zoznam databáz:

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

Dva clustre MongoDB boli zlúčené do jedného, pozostávajúceho zo 6 uzlov.

Momentálne už môžeme prepínať aplikáciu na nový clust, ale na dokončenie migrácie zostáva niekoľko krokov.

Zo súboru init/on-start.sh v novej inštalácii odstraňujeme pridaný riadok:

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

Teraz sa dostaneme do starého majstra clustera a "zhodíme" ho — potom bude v clustere pridelený nový majster. Vstúpime do podu s majstrom MongoDB:

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

Potom meníme priority uzlov a meníme majstra:

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

Aktuálny uzol prestal byť majstrom — prebehnú voľby nového. Keďže sme zmenili priority, majstrom sa stane potrebný uzol.

Poznámka: Predvolene majú všetky uzly MongoDB prioritu 1. Hore zvyšujeme prioritu potrebného uzla na 2. Týmto spôsobom sa definitívne majstrom stáva člen nového clustera. Podrobnosti o tom, ako sú tieto mechanizmy v MongoDB usporiadané, si môžete prečítať v dokumenácie.

Vypneme starú inštaláciu MongoDB, potom sa dostaneme do majstra novej inštalácie a odstránime staré uzly:

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")

Potom môžeme migráciu považovať za ukončenú: úspešne sme prešli zo starého clustera MongoDB na nový!

Zhrnutie

Opísaná schéma vyhovuje prakticky všetkým situáciám, keď je potrebné presunúť MongoDB alebo jednoducho presťahovať do nového clustera.

Hlavný aspekt pri migrácii je nutnosť presmerovania IP adries nových podov na servery staršej inštalácie MongoDB, ak sa nachádza mimo K8s, a správne pomenovanie v DNS (alebo /etc/hosts). V tomto príklade tieto kroky neboli potrebné, pretože migrácia prebiehala medzi rôznymi priestormi názvov v rovnakom Kubernetes klastri.

P.S.

Prečítajte si tiež na našom blogu:

Zdroj: habr.com