Artikel ini melanjutkan
materi migrasi RabbitMQ kami
baru -
baru ini dan didedikasikan untuk MongoDB. Karena kami melayani banyak kluster Kubernet dan MongoDB, kami telah sampai pada kebutuhan alami untuk memigrasikan data dari satu instalasi ke instalasi lainnya dan melakukannya tanpa downtime. Skenario utama adalah sama: transfer MongoDB dari server virtual / besi ke Kubernetes atau transfer MongoDB dalam satu cluster Kubernetes (dari satu namespace ke yang lain).
Resep kami ditujukan untuk kasus-kasus ketika cluster MongoDB lama berfungsi (misalnya, dari 3 node dan terletak sudah di K8s atau di server lama) dengan mana aplikasi yang dihosting di Kubernetes bekerja:
Bagaimana kita akan mentransfer cluster seperti itu ke produksi baru di Kubernetes?
Teori
Algoritma migrasi umum mirip dengan yang dijelaskan dalam situasi dengan RabbitMQ.
Penting untuk dicatat bahwa kemampuan untuk pindah membutuhkan server dengan MongoDB dan Kubernetes berada di jaringan yang sama. Node dari cluster MongoDB akan berkomunikasi satu sama lain melalui IP server lama (di mana instalasi MongoDB lama berada) dan nama DNS pod dari MongoDB di K8s. Oleh karena itu, pada server besi (dengan instalasi lama), akan perlu untuk meneruskan rute ke pod, dan kemudian mengkonfigurasinya untuk menggunakan server DNS yang berjalan di Kubernetes (atau mendaftarkan nama-nama yang diperlukan di
/etc/hosts , meskipun dalam kasus umum lebih baik untuk menghindari kemungkinan ini )
Langkah selanjutnya adalah meningkatkan cluster MongoDB di pod Kubernetes. Dalam kasus kami, cluster database terdiri dari 3 node dan setiap node terletak di pod yang terpisah dari K8 - namun, jumlahnya mungkin berbeda. Di ConfigMap Anda perlu menentukan alamat master MongoDB dari instalasi lama: maka node MongoDB yang terletak di pod di K8s akan segera mulai menyinkronkannya.
Setelah semua pod naik, cluster MongoDB 6-node terbentuk:
Harap perhatikan bahwa pod akan naik untuk waktu yang lama, karena setiap pod dimulai secara bergantian, dan pada saat peluncurannya akan menyinkronkan data dari wizard.
Setelah itu, Anda dapat beralih aplikasi untuk menggunakan server MongoDB baru:
Dan itu tetap hanya untuk menghapus node lama dari cluster MongoDB, setelah itu langkah dapat dianggap selesai:
Kami sering menggunakan skema ini dalam produksi dan, untuk kenyamanan penggunaannya, kami mengimplementasikannya dalam modul
addon-operator (kami
baru-baru ini
mengumumkan utilitas ini), yang memungkinkan kami untuk mendistribusikan konfigurasi MongoDB yang khas di banyak kluster. Kami berencana untuk menerbitkan modul kami dalam waktu dekat, tetapi untuk saat ini kami menyajikan instruksi terpisah yang dengannya Anda dapat mencoba solusi yang diusulkan dalam tindakan dan tanpa menggunakan addon-operator.
Kami mencoba dalam praktik
Persyaratan
Detail:
- Cluster Kubernetes (minikube juga cocok);
- Cluster MongoDB (dapat digunakan pada bare metal, dan dibuat sebagai cluster reguler di Kubernet dari bagan Helm resmi).
Dalam contoh yang dijelaskan di bawah ini, cluster lama dengan MongoDB akan disebut
mongo-old dan diinstal di cluster Kubernetes yang sama, di mana di masa depan kita akan menginstal yang baru (
mongo-new ).
Mempersiapkan cluster lama
1. Untuk contoh yang menunjukkan skema yang dijelaskan dalam tindakan, kami akan membuat kluster MongoDB "lama" (yaitu, akan mengalami migrasi) langsung di Kubernetes (pada kenyataannya, ia juga dapat ditemukan di server terpisah di luar K8). Untuk melakukan ini, unduh grafik Helm:
helm fetch --untar stable/mongodb-replicaset
... dan edit sedikit dengan mengatur otorisasi:
auth: enabled: true adminUser: mongo adminPassword: pa33w0rd # metricsUser: metrics # metricsPassword: password # key: keycontent # existingKeySecret: # existingAdminSecret: # exisitingMetricsSecret:
Juga di
values.yaml Anda dapat mengkonfigurasi sertifikat dan banyak lagi.
2. Atur grafik:
helm install . --name mongo-old --namespace mongo-old
Setelah itu, uji coba instalasi "lama" MongoDB akan diluncurkan:
kubectl --namespace=mongo-old get pods
Mari kita pergi ke pod dengan masternya dan membuat basis tes:
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
Pergi ke pod yang berbeda, saya menemukan bahwa masternya adalah
mongo-old-mongodb-replicaset-0 . Namun, untuk solusi yang lebih mudah untuk masalah ini, setelah menginstal Helm-chart, sebuah perintah ditampilkan tentang cara menentukan
MASTER_POD . Dalam kasus saya (untuk
mongo-old dari 3 node) kelihatannya seperti ini:
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
Mengenai hal ini, persiapan instalasi MongoDB lama, yang datanya akan ditransfer, siap.
Migrasi Cluster MongoDB
Sekarang kami akan menggunakan instalasi MongoDB baru, yang akan berlokasi di Kubernetes dan digunakan oleh aplikasi dalam produksi.
NB : Harap dicatat bahwa versi MongoDB yang sama harus digunakan seperti sebelumnya. Jika tidak, ada risiko masalah kompatibilitas.Dengan analogi dengan bagian sebelumnya (di mana kita meniru instalasi MongoDB "lama"), kita mengambil Helm-chart yang sudah disebutkan (menggunakan perintah
helm fetch ) dan mengkonfigurasi otorisasi, serta parameter lainnya, jika digunakan. Selain itu, kami akan memperbaiki file
init/on-start.sh dengan menambahkan sementara pada baris 165 alamat wizard yang diperoleh pada langkah sebelumnya (atau diketahui oleh Anda dari instalasi MongoDB pada server terpisah):
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'
Kami siap membuat instalasi MongoDB baru:
helm install . --name mongo-new --namespace mongo-new
Kami menunggu hingga semua pod memulai (jika ada banyak data, maka peluncurannya bisa memakan waktu berjam-jam):
Sekarang kami membuat
exec di pod baru dan melihat daftar pangkalan:
kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo
Dua cluster MongoDB digabungkan menjadi satu, terdiri dari 6 node.
Saat ini, Anda sudah bisa beralih aplikasi ke cluster baru, tetapi beberapa langkah tetap untuk menyelesaikan migrasi.
Dari file
init/on-start.sh di instalasi baru, kami menghapus baris yang kami tambahkan:
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'
Sekarang mari kita masuk ke master lama dari cluster dan "menggulingkan" itu - maka master baru akan ditugaskan di cluster. Kami masuk ke pod dengan master MongoDB:
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password')
Setelah itu, kami mengubah prioritas node dan mengubah wisaya:
cfg = rs.conf() cfg.members[5].priority = 2 rs.reconfig(cfg) rs.stepDown(120)
Node saat ini telah berhenti menjadi master - pemilihan baru akan terjadi. Saat kami mengubah prioritas, simpul yang kita butuhkan akan menjadi master.
NB : Secara default, semua node MongoDB memiliki prioritas 1. Di atas kita menaikkan menjadi 2 prioritas dari simpul yang kita butuhkan. Dengan demikian, anggota cluster baru pasti akan menjadi tuan bersama. Anda dapat membaca lebih lanjut tentang bagaimana mekanisme ini bekerja di MongoDB dalam dokumentasi .Nonaktifkan instalasi MongoDB lama, lalu pergi ke wizard baru dan hapus node lama:
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")
Setelah ini, migrasi dapat dianggap selesai: kami berhasil beralih dari cluster MongoDB lama ke yang baru!
Ringkasan
Skema yang dijelaskan cocok untuk hampir semua kasus ketika Anda perlu mentransfer MongoDB atau hanya pindah ke cluster baru.
Mungkin nuansa utama selama transfer adalah kebutuhan untuk meneruskan alamat IP dari pod baru ke server instalasi MongoDB lama, jika di luar K8, dan menamai dengan benar dalam DNS (atau
/etc/hosts ). Dalam contoh ini, langkah-langkah ini tidak diperlukan, karena migrasi terjadi antara ruang nama yang berbeda dari kluster Kubernet yang sama.
PS
Baca juga di blog kami: