🥇 Besiūlis MongoDB į Kubernetes Migration

Šis straipsnis tęsia mūsų naujausia medžiaga apie RabbitMQ migraciją ir skirta MongoDB. Kadangi prižiūrime daug „Kubernetes“ ir „MongoDB“ grupių, atsirado natūralus poreikis perkelti duomenis iš vieno įrenginio į kitą ir tai padaryti be prastovų. Pagrindiniai scenarijai yra tie patys: „MongoDB“ perkėlimas iš virtualaus / aparatinės įrangos serverio į „Kubernetes“ arba „MongoDB“ perkėlimas tame pačiame „Kubernetes“ klasteryje (iš vienos vardų srities į kitą).

Mūsų receptas skirtas atvejams, kai yra senas MongoDB klasteris (pavyzdžiui, iš 3 mazgų ir jau yra K8s arba senesniuose serveriuose), su kuriuo veikia Kubernetes priglobta programa:

Kaip tokį klasterį perkelsime į naują gamybą Kubernetes?

Теория

Bendras perkėlimo algoritmas yra panašus į aprašytą „RabbitMQ“ situacijoje.

Svarbu pažymėti, kad norint perkelti reikia, kad „MongoDB“ ir „Kubernetes“ serveriai būtų tame pačiame tinkle. „MongoDB“ klasterio mazgai bendraus vienas su kitu naudodami senųjų serverių IP (kur yra senieji „MongoDB“ įrenginiai) ir pagal K8s „MongoDB“ grupių DNS pavadinimus. Todėl aparatinės įrangos serveriuose (su senais įrenginiais) turėsite persiųsti maršrutus į ankštis, o tada sukonfigūruoti juos naudoti DNS serverį, veikiantį Kubernetes (arba užregistruoti reikiamus pavadinimus /etc/hosts, nors apskritai šios galimybės geriau vengti).

Kitas žingsnis yra sukurti MongoDB klasterį Kubernetes poduose. Mūsų atveju duomenų bazės klasteris susideda iš 3 mazgų ir kiekvienas mazgas yra atskirame K8s podelyje – tačiau jų skaičius gali skirtis. „ConfigMap“ turite nurodyti „MongoDB“ pagrindinio kompiuterio adresą iš senojo diegimo: tada „MongoDB“ mazgai, esantys K8s poduose, iškart pradės sinchronizuoti su juo.

Kai visos ankštys yra sukurtos, susidaro MongoDB klasteris iš 6 mazgų:

Atkreipkite dėmesį, kad ankšties kilimas užtruks ilgai, nes kiekviena grupė paleidžiama paeiliui, o paleidimo metu sinchronizuoja pagrindinio įrenginio duomenis.

Tada galite perjungti programą, kad galėtumėte naudoti naujus MongoDB serverius:

Belieka pašalinti senus mazgus iš MongoDB klasterio, po kurio perkėlimas gali būti laikomas baigtu:

Mes dažnai naudojame šią schemą gamyboje ir, kad būtų lengviau naudoti, įdiegėme ją modulyje priedų operatorius (mes neseniai paskelbta), leidžianti tipines MongoDB konfigūracijas paskirstyti daugelyje grupių. Netrukus planuojame paskelbti savo modulius, tačiau kol kas pateikiame atskiras instrukcijas, su kuriomis galėsite išbandyti siūlomą sprendimą nenaudodami priedų operatoriaus.

Pabandykime tai praktiškai

Reikalavimai

Reikalavimai:

Kubernetes klasteris (tiks ir minikube);
MongoDB klasteris (gali būti įdiegtas ant pliko metalo ir pagamintas kaip įprastas Kubernetes klasteris iš oficialios Helm diagramos).

Toliau pateiktame pavyzdyje bus pavadintas senasis MongoDB klasteris mongo-old ir įdiegta tame pačiame Kubernetes klasteryje, kur vėliau įdiegsime naują (mongo-new).

Senojo klasterio paruošimas

1. Kaip pavyzdį, kuriame aprašyta schema veikia, sukurkime „seną“ (t. y. perkeliamą) MongoDB klasterį tiesiai Kubernetes (iš tikrųjų jis gali būti atskiruose serveriuose už K8s ribų). Norėdami tai padaryti, atsisiųskite vairo diagramą:

helm fetch --untar stable/mongodb-replicaset

... ir šiek tiek redaguokite nustatydami prieigos teisę:

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

Taip pat values.yaml galite konfigūruoti sertifikatus ir dar daugiau.

2. Įdiekite diagramą:

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

Po to bus paleistas bandomasis „senasis“ MongoDB diegimas:

kubectl --namespace=mongo-old get pods

Eikime į podėlį su jos pagrindiniu ir sukurkime bandomąją duomenų bazę:

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

Eidamas į skirtingas ankštis sužinojau, kad meistras yra mongo-old-mongodb-replicaset-0. Tačiau norint patogiau išspręsti šią problemą, įdiegus vairo diagramą, rodoma komanda, kaip nustatyti MASTER_POD. Mano atveju (dėl mongo-old iš 3 mazgų) atrodo taip:

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

Šiuo metu paruošta senoji MongoDB instaliacija, kurios duomenys bus perkelti.

Perkelkite MongoDB klasterį

Dabar įdiegkime naują MongoDB diegimą, kuris bus Kubernetes ir bus naudojamas gamybinėje programoje.

NB: Atkreipkite dėmesį, kad turi būti naudojama ta pati MongoDB versija kaip ir anksčiau. Priešingu atveju kyla suderinamumo problemų rizika.

Analogiškai su ankstesniu skyriumi (kur mes imitavome „seną“ MongoDB diegimą), paimkime jau minėtą Helm diagramą (su komanda helm fetch) ir sukonfigūruoti autorizaciją bei kitus parametrus, jei jie naudojami. Be to, mes pataisysime failą init/on-start.sh, laikinai pridedant prie jo 165 eilutėje pagrindinį adresą, gautą atliekant ankstesnį veiksmą (arba jums žinomą diegiant MongoDB atskiruose serveriuose):

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

Esame pasirengę sukurti naują MongoDB diegimą:

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

Laukiame, kol prasidės visos ankštys (jei yra daug duomenų, jų paleidimas gali užtrukti valandas):

Dabar mes darome exec į naują podėlį ir pažiūrėkite į duomenų bazių sąrašą:

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

Du MongoDB klasteriai yra sujungti į vieną, susidedantį iš 6 mazgų.

Šiuo metu galite perjungti programą į naują grupę, tačiau liko keli veiksmai, kad užbaigtumėte perkėlimą.

Iš failo init/on-start.sh naujame diegime pašaliname pridėtą eilutę:

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

Dabar pereikime prie senojo klasterio pagrindinio kompiuterio ir jį „nuverskime“ - tada klasteriui bus priskirtas naujas pagrindinis. Su MongoDB meistru pereiname į rinkinį:

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

Po to keičiame mazgų prioritetus ir keičiame pagrindinius elementus:

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

Dabartinis mazgas nustojo būti pagrindinis – bus renkamas naujas mazgas. Kadangi pakeitėme prioritetus, mums reikalingas mazgas taps pagrindiniu.

NB: Pagal numatytuosius nustatymus visi MongoDB mazgai turi 1 prioritetą. Aukščiau mes padidiname mazgo, kurio mums reikia, prioritetą iki 2. Taigi naujojo klasterio narys neabejotinai tampa generaliniu meistru. Daugiau apie tai, kaip šie mechanizmai veikia MongoDB, galite perskaityti dokumentacija.

Išjunkite seną MongoDB diegimą, tada eikite į naują vedlį ir ištrinkite senus mazgus:

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

Po to perkėlimas gali būti laikomas baigtu: sėkmingai perėjome iš senojo MongoDB klasterio į naują!

rezultatai

Aprašyta schema tinka beveik visais atvejais, kai reikia perkelti MongoDB arba tiesiog pereiti į naują klasterį.

Galbūt pagrindinis niuansas perduodant yra būtinybė persiųsti naujų blokų IP adresus į senojo MongoDB diegimo serverius, jei jis yra už K8s ribų, ir teisingai juos pavadinti DNS (arba /etc/hosts). Pavyzdyje šie veiksmai nebuvo būtini, nes perkėlimas įvyko tarp skirtingų to paties Kubernetes klasterio vardų erdvių.