Enkla migreringar av MongoDB till Kubernetes

Denna artikel fortsätter vår senaste material om migrering av RabbitMQ och handlar om MongoDB. Eftersom vi hanterar många Kubernetes- och MongoDB-kluster har vi kommit till den naturliga slutsatsen att migrera data från en installation till en annan utan driftstopp. De grundläggande scenarierna är desamma: att flytta MongoDB från en virtuell/physical server till Kubernetes eller flytta MongoDB inom ett och samma Kubernetes-kluster (från ett namnrum till ett annat).

Vårt recept är avsett för fall där en gammal MongoDB-kluster är i drift (till exempel från 3 noder och antingen redan i K8s eller på gamla servrar), som applikationen som körs i Kubernetes arbetar med:

Hur kommer vi att överföra detta kluster till en ny produktionsmiljö i Kubernetes?

Teori

Den allmänna migrationsalgoritmen liknar den som beskrivs i situationen med RabbitMQ.

Det är viktigt att notera att för möjligheten att flytta krävs att servrarna med MongoDB och Kubernetes finns i samma nätverk. Noderna i MongoDB-klustret kommer att kommunicera med varandra via IP-adresserna för de gamla servrarna (där de gamla installationerna av MongoDB finns) och via DNS-namn för poddar med MongoDB i K8s. Därför behöver du på de fysiska servrarna (med gamla installationer) dirigera rutter till poddarna och sedan konfigurera dem för att använda DNS-servern som fungerar i Kubernetes (eller skriva in de nödvändiga namnen i /etc/hosts, även om det i allmänhet är bättre att undvika denna möjlighet).

Nästa steg är att höja upp MongoDB-klustret i Kubernetes-poddar. I vårt fall består databasklustret av 3 noder och varje nod är belägen i en separat K8s-podd – men deras antal kan vara annorlunda. I ConfigMap måste du ange adressen till MongoDB-mastern från den gamla installationen: då kommer de MongoDB-noder som finns i poddarna i K8s att börja synkronisera med den direkt.

Efter att alla poddar har startat kommer ett MongoDB-kluster att bildas med 6 noder:

Observera att poddarna kommer att ta tid att starta, eftersom varje podd startas i tur och ordning, och under startprocessen synkroniserar data med mastern.

Efter detta kan applikationen växlas till att använda de nya MongoDB-servrarna:

Och det återstår bara att ta bort de gamla noderna från MongoDB-klustret, efter vilket flytten kan anses vara fullbordad:

Denna procedur använder vi ofta i produktion och för att underlätta dess användning har vi implementerat den inom modulen k addon-operator (detta verktyg har vi nyligen annonserat), vilket gör att man kan distribuera standardkonfigurationer av MongoDB över flera kluster. Publiceringen av våra moduler planerar vi att genomföra inom kort, och tills vidare presenterar vi separata instruktioner som man kan prova den föreslagna lösningen med i praktiken utan att använda addon-operator.

Testar i praktiken

Krav

Uppgifter:

• Kubernetes-kluster (minikube fungerar också);
• MongoDB-kluster (kan både vara implementerat på bare metal och skapat som ett vanligt kluster i Kubernetes från den officiella Helm-diagrammet).

I det följande exemplet kommer det gamla klustret med MongoDB att kallas mongo-old och installeras i samma Kubernetes-kluster där vi senare kommer att installera den nya (mongo-new).

Förbereder det gamla klustret

1. För att demonstrera det beskrivna schemat i praktiken, skapar vi ett "gamalt" (dvs. som ska migreras) MongoDB-kluster direkt i Kubernetes (i verkligheten kan det även befinna sig på separata servrar utanför K8s). För detta laddar vi ner Helm-diagrammet:

helm fetch --untar stable/mongodb-replicaset

… och redigerar det lite, ställer in autentisering:

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

Det går också att ställa in certifikat och mycket mer i values.yaml .

2. Installera diagrammet:

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

Därefter kommer en testinstallation av "det gamla" MongoDB att startas:

kubectl --namespace=mongo-old get pods

Vi går in i pod med dess master och skapar en testdatabas:

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

Genom att gå in i olika podar hittar jag att mastern är mongo-old-mongodb-replicaset-0. För att lösa denna fråga mer bekvämt efter installationen av Helm-diagrammet visas ett kommando för att identifiera MASTER_POD. I mitt fall (för mongo-old av 3 noder) ser det ut så här:

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

Således är förberedelserna för den gamla MongoDB-installationen, vars data ska migreras, klara.

Migrering av MongoDB-klustret

Nu kommer vi att implementera en ny MongoDB-installation som kommer att finnas i Kubernetes och användas av applikationen i produktion.

NB: Observera att samma version av MongoDB bör användas som tidigare. Annars finns det risk för kompatibilitetsproblem.

I likhet med den föregående delen (där vi imiterade en "gammal" installation av MongoDB), tar vi den nämnda Helm-diagrammet (kommandot helm fetch) och konfigurerar autentisering samt andra parametrar, om de används. Dessutom kommer vi att korrigera filen init/on-start.sh, temporärt lägga till adressen till master på rad 165, som erhölls i föregående steg (eller som du känner till från installationen av MongoDB på separata servrar):

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

Vi är redo att skapa en ny installation av MongoDB:

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

Vänta tills alla poddar startas (om det finns mycket data kan det ta timmar):

Nu gör vi exec i den nya podden och tittar på listan över databaser:

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

Två MongoDB-kluster har förenats till ett, bestående av 6 noder.

För tillfället kan applikationen redan växlas till det nya klustret, men det återstår några steg för att avsluta migreringen.

Från filen init/on-start.sh tar vi bort raden vi lade till i den nya installationen:

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

Nu går vi in i den gamla masterklustret och "avsätter" den — då kommer det att utses en ny master i klustret. Gå in i podden med MongoDB-mastern:

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

Därefter ändrar vi prioriteringarna hos noderna och byter master:

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

Den nuvarande noden har slutat vara master — val av ny kommer att äga rum. Eftersom vi har ändrat prioriteringarna kommer den nod vi önskar att bli master.

NB: Som standard har alla MongoDB-noder en prioritet på 1. Här höjer vi prioriteten hos den nod vi önskar till 2. Således blir en medlem av det nya klustret den gemensamma mastern. Mer om hur dessa mekanismer fungerar i MongoDB kan man läsa i dokumentationen.

Vi kommer att stänga den gamla installationen av MongoDB, och sedan gå in i den nya mastern och ta bort de gamla noderna:

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

Därefter kan man anse att migreringen är avslutad: vi har framgångsrikt växlat från det gamla MongoDB-klustret till det nya!

Sammanfattning

Det beskrivna schemat passar praktiskt taget alla fall när man behöver flytta MongoDB eller bara flytta till ett nytt kluster.

Kanske det viktigaste att tänka på vid migrering är behovet av att vidarebefordra IP-adresserna för de nya poddarna till servrarna för den gamla installationen av MongoDB, om den finns utanför K8s, samt att namnge dem korrekt i DNS (eller /etc/hosts). I exemplet behövdes inte dessa steg eftersom migreringen skedde mellan olika namnrymder inom samma Kubernetes-kluster.

P.S.

Läs även i vår blogg:

• «En utmanande migrering av RabbitMQ till Kubernetes»;
• «Databaser och Kubernetes (översikt och videoföreläsning)»;
• «K8s tips & tricks: Snabbare bootstrap av stora databaser».

Källa: habr.com