🥇Bezproblémová migrace MongoDB do Kubernetes

Tento článek pokračuje v našem nedávném materiálu o migraci RabbitMQ a je věnován MongoDB. Jelikož spravujeme mnoho klastrů Kubernetes a MongoDB, přirozeně jsme narazili na potřebu migrovat data z jedné instalace na druhou a udělat to bez výpadku. Hlavní scénáře zůstávají stejné: přesun MongoDB z virtuálního/hardwarového serveru do Kubernetes nebo přesun MongoDB v rámci jednoho klastru Kubernetes (z jednoho jmenného prostoru do druhého).

Náš recept je určen pro případy, kdy funguje starý klastr MongoDB (například ze 3 uzlů a nachází se buď již v K8s, nebo na starých serverech), se kterým pracuje aplikace umístěná v Kubernetes:

Jak budeme převádět tento klastr do nového produkčního prostředí v Kubernetes?

Teorie

Obecný algoritmus migrace je podobný tomu, který je popsán v situaci s RabbitMQ.

Je důležité poznamenat, že pro možnost přesunu je třeba, aby servery s MongoDB a Kubernetes byly ve stejné síti. Uzly klastru MongoDB budou komunikovat mezi sebou pomocí IP starých serverů (kde se nacházejí staré instalace MongoDB) a pomocí DNS jmen podů s MongoDB v K8s. Proto bude na hardwarových serverech (se starými instalacemi) potřeba prohodit směrování k podům a poté je nastavit na používání DNS serveru, který funguje v Kubernetes (nebo zapisovat potřebná jména do /etc/hosts, ačkoli obecně je lepší se této možnosti vyhnout).

Dalším krokem je zprovoznění klastru MongoDB v podech Kubernetes. V našem případě se klastr DB skládá z 3 uzlů a každý uzel je umístěn v samostatném podu K8s – nicméně jejich počet může být i jiný. V ConfigMapu je třeba uvést adresu hlavního uzlu MongoDB ze staré instalace: pak uzly MongoDB umístěné v podech v K8s okamžitě začnou synchronizaci s ním.

Jakmile se všechny pody zvednou, vytvoří se klastr MongoDB z 6 uzlů:

Všimněte si, že pody se budou dlouho zvedat, protože každý pod se spouští postupně a při spuštění synchronizuje data s hlavním uzlem.

Poté lze aplikaci přepnout na používání nových serverů MongoDB:

A zbývá pouze odstranit staré uzly z klastru MongoDB, po čemž lze migrační proces považovat za dokončený:

Tento scénář často používáme v produkci a pro usnadnění jeho použití jsme ho implementovali v rámci modulu k addon-operator (tuto utilitu jsme nedávno oznámili), což umožňuje šířit typové konfigurace MongoDB napříč mnoha clustery. Publikaci našich modulů plánujeme provést v blízké době, zatím nabízíme jednotlivé pokyny, se kterými si můžete vyzkoušet navrhované řešení v akci a bez použití addon-operator.

Zkoušíme v praxi

Požadavky

Údaje:

Kubernetes cluster (vhodný je i minikube);
Cluster MongoDB (může být nasazen jak na bare metal, tak na klasickém clusteru v Kubernetes z oficiálního Helm chartu).

V níže popsaném příkladu bude starý cluster s MongoDB označen mongo-old a bude nainstalován ve stejném clusteru Kubernetes, kde později nainstalujeme i nový (mongo-new).

Příprava starého clusteru

1. Pro příklad, který demonstruje popsanou schéma v akci, vytvoříme "starý" (tj. podléhající migraci) cluster MongoDB přímo v Kubernetes (ve skutečnosti může být i na oddělených serverech mimo K8s). K tomu stáhneme Helm chart:

helm fetch --untar stable/mongodb-replicaset

… a trochu ho upravíme, nastavíme autorizaci:

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

Také v values.yaml můžeme nastavit certifikáty a mnoho dalšího.

2. Nainstalujeme chart:

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

Po tomto bude spuštěna testovací "starší" instalace MongoDB:

kubectl --namespace=mongo-old get pods

Pojďme do podu s jejím masterem a vytvořme testovací databázi:

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

Při přihlašování do různých podů jsem zjistil, že master je mongo-old-mongodb-replicaset-0. Nicméně pro pohodlnější řešení této otázky se po instalaci Helm chartu zobrazuje příkaz, jak určit MASTER_POD. V mém případě (pro mongo-old z 3 uzlů) to vypadá 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ímto je příprava staré instalace MongoDB, jejíž data budou přenášena, hotova.

Migrace clusteru MongoDB

Nyní nasadíme novou instalaci MongoDB, která bude umístěna v Kubernetes a použita aplikací v produkci.

NB: Upozorňuji, že by měla být použita stejná verze MongoDB, jako dříve. Jinak existuje riziko vzniku problémů s kompatibilitou.

Podobně jako v předchozí části (kde jsme simulovali "starou" instalaci MongoDB) vezmeme již zmíněný Helm chart (příkazem helm fetch) a nastavíme autorizaci, jakož i další parametry, pokud se používají. Kromě toho opravíme soubor init/on-start.sh, dočasně přidáním na řádek 165 adresu mastera, získanou v předchozím kroku (nebo vám známou podle instalace MongoDB na samostatných serverech):

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

Jsme připraveni k vytvoření nové instalace MongoDB:

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

Čekáme, až se spustí všechny pod (pokud je dat hodně, může jejich spuštění trvat hodiny):

Teď provedeme exec do nového podu a podíváme se na seznam databází:

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

Dva clustery MongoDB byly spojeny do jednoho, který se skládá z 6 uzlů.

V tuto chvíli již můžete přepnout aplikaci na nový cluster, ale k dokončení migrace zbývá několik kroků.

Ze souboru init/on-start.sh v nové instalaci odstraníme námi přidaný řádek:

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

Teď se podíváme na starého mastera clusteru a "svrhneme" ho — tím se v clusteru stanoví nový master. Přihlašujeme se do podu s masterem MongoDB:

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

Poté změníme priority uzlů a změníme mastera:

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

Aktuální uzel přestal být masterem — proběhnou volby nového. Vzhledem k tomu, že jsme změnili priority, stane se masterem potřebný uzel.

NB: Ve výchozím nastavení mají všechny uzly MongoDB prioritu 1. Vyšší prioritu na 2 zvedáme u potřebného uzlu. Takto se určitě stane celkovým mistrem člen nového clusteru. Více o tom, jak tyto mechanismy fungují v MongoDB, si můžete přečíst v dokumentaci.

Odpojíme starou instalaci MongoDB a pak se podíváme na mastera nové a odstraníme 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")

Poté lze migraci považovat za dokončenou: úspěšně jsme přešli ze starého clusteru MongoDB na nový!

Závěry

Popisovaný postup je vhodný prakticky pro všechny případy, kdy je potřeba přenést MongoDB nebo se jednoduše odstěhovat do nového clusteru.

Snad nejdůležitější nuancí při přesunu je nutnost propašovat IP adresy nových podů na servery staré instalace MongoDB, pokud se nachází mimo K8s, a správně je pojmenovat v DNS (nebo /etc/hosts). V příkladu tyto kroky nebyly potřeba, protože migrace probíhala mezi různými jmennými prostory jednoho a téhož Kubernetes clusteru.

P.S.

Přečtěte si také náš blog:

Zdroj: habr.com