RabbitMQ adalah broker pesan yang ditulis dalam Erlang yang memungkinkan Anda untuk mengatur kluster failover dengan replikasi data lengkap ke beberapa node, di mana setiap node dapat melayani permintaan baca dan tulis. Dengan banyak kluster Kubernet dalam produksi, kami mendukung sejumlah besar instalasi RabbitMQ dan dihadapkan dengan kebutuhan untuk memigrasikan data dari satu cluster ke yang lain tanpa downtime.
Operasi ini diperlukan bagi kami setidaknya dalam dua kasus:
- Mentransfer data dari kluster RabbitMQ, yang tidak ada di Kubernetes, ke kluster baru yang sudah "disetel keluar" (artinya, berfungsi di pod K8s).
- Migrasi RabbitMQ dalam Kubernetes dari satu namespace ke yang lain (misalnya, jika jalur dibatasi oleh ruang nama, maka untuk mentransfer infrastruktur dari satu jalur ke yang lain).
Resep yang diusulkan dalam artikel ini difokuskan pada situasi (tetapi tidak terbatas pada mereka), di mana ada cluster RabbitMQ lama (misalnya, dari 3 node), yang terletak di K8 atau di beberapa server lama. Aplikasi yang dihosting di Kubernet berfungsi dengan itu (sudah ada atau di masa depan):
... dan kami menghadapi tantangan untuk memigrasikannya ke produksi baru di Kubernetes.
Pertama, pendekatan umum untuk migrasi itu sendiri akan dijelaskan, dan setelah itu, rincian teknis tentang implementasinya.
Algoritma migrasi
Langkah pertama, pendahuluan, sebelum tindakan apa pun adalah memverifikasi bahwa mode ketersediaan tinggi (
HA ) diaktifkan di instalasi RabbitMQ yang lama. Alasannya jelas - kami tidak ingin kehilangan data apa pun. Untuk melakukan pemeriksaan ini, Anda dapat pergi ke panel admin RabbitMQ dan di tab Admin → Kebijakan pastikan bahwa nilai
ha-mode: all :
Langkah selanjutnya adalah meningkatkan cluster RabbitMQ baru di pod Kubernetes (dalam kasus kami, misalnya, terdiri dari 3 node, tetapi jumlahnya mungkin berbeda).
Setelah itu, kami menggabungkan cluster RabbitMQ lama dan baru, memperoleh satu cluster (dari 6 node):
Proses sinkronisasi data antara kluster RabbitMQ lama dan baru telah dimulai. Setelah semua data disinkronkan di antara semua node di cluster, kita bisa beralih aplikasi untuk menggunakan cluster baru:
Setelah operasi ini, cukup untuk menghapus node lama dari cluster RabbitMQ, dan langkah tersebut dapat dianggap selesai:
Kami telah berulang kali menggunakan skema ini dalam produksi kami. Namun, untuk kenyamanan mereka sendiri, mereka mengimplementasikannya dalam kerangka sistem khusus yang mendistribusikan konfigurasi RMQ pada kumpulan cluster Kubernet
(bagi mereka yang penasaran: kita berbicara tentang operator tambahan , yang baru saja kita bicarakan ) . Di bawah ini disajikan instruksi individual yang dapat diterapkan siapa pun pada instalasi mereka untuk mencoba solusi yang diusulkan dalam tindakan.
Kami mencoba dalam praktik
Persyaratan
Detailnya sangat sederhana:
- Cluster Kubernetes (minikube juga cocok);
- Cluster RabbitMQ (dapat digunakan pada bare metal, dan dibuat sebagai cluster reguler di Kubernetes dari grafik Helm resmi).
Untuk contoh yang dijelaskan di bawah ini, saya menggunakan RMQ ke Kubernetes dan menamainya
rmq-old .
Persiapan berdiri
1. Unduh grafik Helm dan edit sedikit:
helm fetch --untar stable/rabbitmq-ha
Untuk kenyamanan, kami menetapkan kata sandi,
ErlangCookie dan menetapkan kebijakan
ha-all sehingga secara default antrian disinkronkan di antara semua node dari cluster RMQ:
rabbitmqPassword: guest rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we definitions: policies: |- { "name": "ha-all", "pattern": ".*", "vhost": "/", "definition": { "ha-mode": "all", "ha-sync-mode": "automatic", "ha-sync-batch-size": 81920 } }
2. Atur grafik:
helm install . --name rmq-old --namespace rmq-old
3. Buka panel admin RabbitMQ, buat antrean baru dan tambahkan beberapa pesan. Mereka akan diperlukan sehingga setelah migrasi kami dapat memastikan bahwa semua data telah disimpan dan bahwa kami tidak kehilangan apa pun:
Bangku tes siap: kami memiliki RabbitMQ "lama" dengan data yang perlu ditransfer.
Migrasi Cluster RabbitMQ
1. Pertama, gunakan RabbitMQ baru di ruang nama yang
berbeda dengan
ErlangCookie dan kata sandi yang sama untuk pengguna. Untuk melakukan ini, kami melakukan operasi yang dijelaskan di atas, mengubah perintah instalasi RMQ akhir sebagai berikut:
helm install . --name rmq-new --namespace rmq-new
2. Sekarang Anda perlu menggabungkan cluster baru dengan yang lama. Untuk melakukan ini, buka setiap pod dari RabbitMQ
baru dan jalankan perintah:
export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && \ rabbitmqctl stop_app && \ rabbitmqctl join_cluster $OLD_RMQ && \ rabbitmqctl start_app
Variabel
OLD_RMQ alamat salah satu node dari cluster RMQ
lama .
Perintah-perintah ini akan menghentikan node saat ini dari RMQ cluster baru, melampirkannya ke cluster lama, dan restart itu.
3. RMQ cluster 6 node siap:
Anda harus menunggu sampai pesan disinkronkan antara semua node. Mudah ditebak bahwa waktu sinkronisasi pesan tergantung pada kapasitas besi tempat cluster digunakan, dan pada jumlah pesan. Dalam skenario yang dijelaskan hanya ada 10 di antaranya, sehingga data disinkronkan secara instan, tetapi dengan jumlah pesan yang cukup besar, sinkronisasi dapat berlangsung berjam-jam.
Jadi, status sinkronisasi:
Di sini,
+5 berarti bahwa pesan
sudah ada di 5 node lain (kecuali untuk apa yang ditentukan dalam bidang
Node ). Dengan demikian, sinkronisasi berhasil.
4. Tinggal memindahkan alamat RMQ dalam aplikasi ke cluster baru (tindakan spesifik di sini tergantung pada tumpukan teknologi yang Anda gunakan dan spesifik aplikasi lainnya), setelah itu Anda bisa mengucapkan selamat tinggal pada yang lama.
Untuk operasi terakhir (mis.,
Setelah mengalihkan aplikasi ke cluster baru), kami pergi ke setiap node dari cluster
lama dan menjalankan perintah:
rabbitmqctl stop_app rabbitmqctl reset
Cluster "lupa" tentang node lama: Anda dapat menghapus RMQ lama, yang akan menyelesaikan pemindahan.
Catatan : Jika Anda menggunakan RMQ dengan sertifikat, pada dasarnya tidak ada perubahan - proses pemindahan akan dilakukan persis sama.Kesimpulan
Skema yang dijelaskan cocok untuk hampir semua kasus ketika kita perlu mentransfer RabbitMQ atau hanya pindah ke cluster baru.
Dalam kasus kami, kesulitan hanya terjadi satu kali, ketika RMQ diakses dari banyak tempat, dan kami tidak memiliki kesempatan di mana-mana untuk mengubah alamat RMQ menjadi yang baru. Kemudian kami meluncurkan RMQ baru di namespace yang sama dengan label yang sama, sehingga jatuh di bawah layanan dan Ingress yang ada, dan ketika kami memulai pod, kami memanipulasi label dengan tangan kami, menghapusnya di awal, sehingga permintaan tidak jatuh pada RMQ yang kosong, dan menambahkannya kembali setelah sinkronisasi pesan.
Kami menggunakan strategi yang sama ketika memperbarui RabbitMQ ke versi baru dengan konfigurasi yang dimodifikasi - semuanya bekerja seperti jam.
PS
Sebagai kelanjutan logis dari materi ini, kami sedang menyiapkan artikel tentang MongoDB (migrasi dari server besi ke Kubernetes) dan MySQL (salah satu opsi untuk "mempersiapkan" DBMS ini di dalam Kubernetes). Mereka akan diterbitkan dalam beberapa bulan mendatang.
PPS
Baca juga di blog kami: