🥇Migrasi RabbitMQ ke Kubernetes yang lancar

RabbitMQ adalah broker pesan yang ditulis dalam Erlang yang memungkinkan Anda mengatur cluster failover dengan replikasi data penuh di beberapa node, di mana setiap node dapat melayani permintaan baca dan tulis. Memiliki banyak cluster Kubernetes dalam operasi produksi, kami mendukung instalasi RabbitMQ dalam jumlah besar dan dihadapkan pada kebutuhan untuk memigrasikan data dari satu cluster ke cluster lainnya tanpa downtime.

Kami memerlukan operasi ini setidaknya dalam dua kasus:

Mentransfer data dari cluster RabbitMQ yang tidak berlokasi di Kubernetes ke cluster baru – yang sudah “kubernetisasi” (yaitu beroperasi di pod K8s) –.
Migrasi RabbitMQ dalam Kubernetes dari satu namespace ke namespace lainnya (misalnya, jika sirkuit dibatasi oleh namespace, maka untuk mentransfer infrastruktur dari satu sirkuit ke sirkuit lainnya).

Resep yang diusulkan dalam artikel ini difokuskan pada situasi (tetapi tidak terbatas pada situasi tersebut) di mana terdapat cluster RabbitMQ lama (misalnya, dari 3 node), yang sudah terletak di K8 atau di beberapa server lama. Aplikasi yang dihosting di Kubernetes (sudah ada atau di masa depan) dapat digunakan dengannya:

...dan kita dihadapkan pada tugas untuk memigrasikannya ke produksi baru di Kubernetes.

Pertama, akan dijelaskan pendekatan umum terhadap migrasi itu sendiri, dan setelah itu akan dijelaskan rincian teknis pelaksanaannya.

Algoritma migrasi

Tahap pendahuluan pertama sebelum tindakan apa pun adalah memeriksa apakah mode ketersediaan tinggi diaktifkan di instalasi RabbitMQ lama (HA). Alasannya jelas – kami tidak ingin kehilangan data apa pun. Untuk melakukan pemeriksaan ini, Anda dapat masuk ke panel admin RabbitMQ dan di tab Admin → Kebijakan pastikan nilainya telah ditetapkan ha-mode: all:

Langkah selanjutnya adalah membangun cluster RabbitMQ baru di pod Kubernetes (dalam kasus kami, misalnya, terdiri dari 3 node, tetapi jumlahnya mungkin berbeda).

Setelah ini, kami menggabungkan cluster RabbitMQ lama dan baru, memperoleh satu cluster (terdiri dari 6 node):

Proses sinkronisasi data antara cluster RabbitMQ lama dan baru dimulai. Setelah semua data disinkronkan antara semua node di cluster, kita dapat mengalihkan aplikasi untuk menggunakan cluster baru:

Setelah operasi ini, cukup dengan menghapus node lama dari cluster RabbitMQ, dan perpindahan tersebut dapat dianggap selesai:

Kami telah menggunakan skema ini berkali-kali dalam produksi. Namun, demi kenyamanan kami, kami menerapkannya dalam sistem khusus yang mendistribusikan konfigurasi RMQ standar ke beberapa cluster Kubernetes (Bagi yang penasaran: yang sedang kita bicarakan addon-operatortentang yang kita baru saja diberitahu). Di bawah ini kami akan menyajikan instruksi individual yang dapat diterapkan oleh siapa saja pada instalasi mereka untuk mencoba solusi yang diusulkan dalam tindakan.

Mari kita mencobanya dalam praktek

Persyaratan

Detailnya sangat sederhana:

Cluster Kubernetes (minikube juga bisa berfungsi);
Cluster RabbitMQ (dapat diterapkan pada bare metal, dan dibuat seperti cluster biasa di Kubernetes dari grafik Helm resmi).

Untuk contoh di bawah ini, saya menerapkan RMQ ke Kubernetes dan memanggilnya rmq-old.

Persiapan berdiri

1. Unduh diagram Helm dan edit sedikit:

helm fetch --untar stable/rabbitmq-ha

Untuk kenyamanan, kami menetapkan kata sandi, ErlangCookie dan membuat politik ha-allsehingga secara default antrian disinkronkan antara semua node 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. Instal grafik:

helm install . --name rmq-old --namespace rmq-old

3. Masuk ke panel admin RabbitMQ, buat antrian baru dan tambahkan beberapa pesan. Mereka akan dibutuhkan agar setelah migrasi kami dapat memastikan bahwa semua data tetap terjaga dan kami tidak kehilangan apa pun:

Bangku pengujian sudah siap: kami memiliki RabbitMQ “lama” dengan data yang perlu ditransfer.

Memigrasikan klaster RabbitMQ

1. Pertama, mari kita terapkan RabbitMQ baru teman ruang nama dengan sama ErlangCookie dan kata sandi untuk pengguna. Untuk melakukan ini, kami akan melakukan operasi yang dijelaskan di atas, mengubah perintah terakhir untuk menginstal RMQ menjadi berikut:

helm install . --name rmq-new --namespace rmq-new

2. Sekarang Anda perlu menggabungkan cluster baru dengan cluster lama. Untuk melakukan ini, buka masing-masing pod baru RabbitMQ 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

Dalam sebuah variabel OLD_RMQ alamat salah satu node ditemukan tua gugus RMQ.

Perintah-perintah ini akan menghentikan node saat ini baru Cluster RMQ, lampirkan ke cluster lama dan luncurkan lagi.

3. Cluster RMQ yang terdiri dari 6 node sudah siap:

Anda harus menunggu hingga pesan disinkronkan di antara semua node. Tidak sulit untuk menebak bahwa waktu sinkronisasi pesan bergantung pada kapasitas perangkat keras tempat cluster digunakan dan jumlah pesan. Dalam skenario yang dijelaskan, hanya ada 10 pesan, sehingga data langsung tersinkronisasi, namun dengan jumlah pesan yang cukup banyak, sinkronisasi bisa memakan waktu berjam-jam.

Jadi, status sinkronisasi:

Di sini +5 berarti pesan sudah masuk lebih lanjut pada 5 node (kecuali yang ditunjukkan di lapangan Node). Dengan demikian, sinkronisasi berhasil.

4. Yang tersisa hanyalah mengalihkan alamat RMQ dalam aplikasi ke cluster baru (tindakan spesifik di sini bergantung pada tumpukan teknologi yang Anda gunakan dan spesifikasi aplikasi lainnya), setelah itu Anda dapat mengucapkan selamat tinggal pada yang lama.

Untuk operasi terakhir (yaitu sudah setelah mengalihkan aplikasi ke cluster baru) pergi ke setiap node tua cluster dan jalankan perintah:

rabbitmqctl stop_app
rabbitmqctl reset

Cluster “lupa” tentang node lama: Anda dapat menghapus RMQ lama, dan pada saat itu perpindahan akan selesai.

Catatan: Jika Anda menggunakan RMQ dengan sertifikat, maka tidak ada perubahan mendasar - proses pemindahan akan dilakukan dengan cara yang persis sama.

Temuan

Skema yang dijelaskan cocok untuk hampir semua kasus ketika kita perlu memigrasi RabbitMQ atau sekadar berpindah ke cluster baru.

Dalam kasus kami, kesulitan hanya muncul satu kali, ketika RMQ diakses dari banyak tempat, dan kami tidak memiliki kesempatan untuk mengubah alamat RMQ ke yang baru di mana pun. Kemudian kami meluncurkan RMQ baru di namespace yang sama dengan label yang sama sehingga akan termasuk dalam layanan dan Ingress yang ada, dan saat meluncurkan pod, kami memanipulasi label dengan tangan, menghapusnya di awal sehingga permintaan tidak jatuh pada kosongkan RMQ, dan tambahkan kembali setelah pesan disinkronkan.

Kami menggunakan strategi yang sama saat memperbarui RabbitMQ ke versi baru dengan konfigurasi yang diubah - semuanya bekerja seperti jam.

PS

Sebagai kelanjutan logis dari materi ini, kami sedang menyiapkan artikel tentang MongoDB (migrasi dari server perangkat keras ke Kubernetes) dan MySQL (bagaimana kami menyiapkan DBMS ini di dalam Kubernetes). Mereka akan diterbitkan dalam beberapa bulan mendatang.

Migrasi RabbitMQ ke Kubernetes yang mulus