[ English | Deutsch | Indonesia | русский | English (United Kingdom) ]

Pemeliharaan klaster RabbitMQ

Broker RabbitMQ adalah pengelompokan logis dari satu atau beberapa node Erlang dengan setiap node yang menjalankan aplikasi RabbitMQ dan berbagi pengguna, host virtual, antrian, pertukaran, bindings, dan parameter runtime. Kumpulan node sering disebut sebagai cluster. Untuk informasi lebih lanjut tentang pengelompokan RabbitMQ, lihat RabbitMQ cluster.

Within OpenStack-Ansible, all data and states required for operation of the RabbitMQ cluster is replicated across all nodes including the message queues providing high availability. RabbitMQ nodes address each other using domain names. The hostnames of all cluster members must be resolvable from all cluster nodes, as well as any machines where CLI tools related to RabbitMQ might be used. There are alternatives that may work in more restrictive environments. For more details on that setup, see Inet Configuration.

Buat klaster RabbitMQ

Kluster RabbitMQ dapat dibentuk dengan dua cara:

  • Secara manual dengan rabbitmqctl

  • Deklaratif (daftar node kluster dalam konfigurasi, dengan rabbitmq-autocluster, atau rabbitmq-clusterer plugins)

Catatan

Broker RabbitMQ dapat mentoleransi kegagalan node individu dalam cluster. Node ini dapat mulai dan berhenti sesuka hati selama mereka memiliki kemampuan untuk menjangkau anggota yang diketahui sebelumnya pada saat shutdown.

Ada dua jenis node yang dapat Anda konfigurasi: node disk dan RAM. Paling umum, Anda akan menggunakan node Anda sebagai node disk (lebih disukai). Sedangkan node RAM lebih dari konfigurasi khusus yang digunakan dalam kelompok kinerja.

Node RabbitMQ dan alat CLI menggunakan erlang cookie untuk menentukan apakah mereka memiliki izin untuk berkomunikasi atau tidak. Cookie adalah serangkaian karakter alfanumerik dan bisa sesingkat atau selama yang Anda inginkan.

Catatan

Nilai cookie adalah rahasia bersama dan harus dilindungi dan dijaga kerahasiaannya.

Lokasi default dari cookie pada lingkungan /var/lib/rabbitmq/.erlang.cookie atau di $HOME/.erlang.cookie.

Tip

Sementara pemecahan masalah, jika Anda melihat satu node menolak untuk bergabung dengan cluster, itu pasti bernilai memeriksa apakah cookie erlang sesuai dengan node lainnya. Ketika cookie salah dikonfigurasi (misalnya, tidak identik), RabbitMQ akan mencatat kesalahan seperti "Connection attempt from disallowed node" dan "Could not auto-cluster". Lihat clustering untuk informasi lebih lanjut.

Untuk membentuk Cluster RabbitMQ, Anda mulai dengan mengambil broker RabbitMQ independen dan mengkonfigurasi kembali node-node ini ke dalam konfigurasi cluster.

Menggunakan contoh 3 node, Anda akan memberitahu node 2 dan 3 untuk bergabung dengan cluster dari node pertama.

  1. Login to the 2nd and 3rd node and stop the RabbitMQ application.

  2. Bergabunglah dengan kluster, lalu mulai ulang aplikasi:

    rabbit2$ rabbitmqctl stop_app
Stopping node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl join_cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.
rabbit2$ rabbitmqctl start_app
Starting node rabbit@rabbit2 ...done.

Periksa status cluster RabbitMQ

  1. Jalankan rabbitmqctl cluster_status dari salah satu node.

Anda akan melihat rabbit1 dan rabbit2 sama-sama berjalan seperti sebelumnya.

Perbedaannya adalah bahwa bagian status klaster dari output, kedua node sekarang dikelompokkan bersama:

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Untuk menambahkan node RabbitMQ ketiga ke cluster, ulangi proses di atas dengan menghentikan aplikasi RabbitMQ pada node ketiga.

  1. Bergabunglah dengan cluster, dan restart aplikasi pada node ketiga.

  2. Jalankan rabbitmq cluster_status untuk melihat semua 3 node:

    rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
 {running_nodes,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Berhenti dan mulai kembali klaster RabbitMQ

Untuk menghentikan dan memulai cluster, ingatlah urutan urutan Anda mematikan node. Node terakhir yang Anda hentikan, harus menjadi node pertama yang Anda mulai. Node ini adalah master.

Jika Anda memulai nodes yang tidak berurutan, Anda dapat mengalami masalah saat berpikir master saat ini tidak boleh menjadi master dan menghapus pesan untuk memastikan bahwa tidak ada pesan baru yang diantrikan sementara master asli turun.

RabbitMQ and Mnesia

Mnesia adalah database terdistribusi yang digunakan RabbitMQ untuk menyimpan informasi tentang pengguna, pertukaran, antrian, dan binding. Pesan, namun tidak disimpan dalam database.

For more information about Mnesia, see the Mnesia overview.

To view the locations of important RabbitMQ files, see File Locations.

Perbaiki klaster RabbitMQ yang dipartisi untuk satu node

Invariably due to something in your environment, you are likely to lose a node in your cluster. In this scenario, multiple LXC containers on the same host are running RabbitMQ and are in a single RabbitMQ cluster.

Jika host masih menunjukkan sebagai bagian dari cluster, tetapi tidak berjalan, laksanakan:

# rabbitmqctl start_app

Namun, Anda mungkin melihat beberapa masalah dengan aplikasi Anda karena klien mungkin mencoba untuk mendorong pesan ke node yang tidak responsif. Untuk memperbaiki ini, lupakan node dari cluster dengan mengeksekusi yang berikut:

  1. Pastikan RabbitMQ tidak berjalan di node:

    # rabbitmqctl stop_app

  2. On the RabbitMQ second node, execute:

    # rabbitmqctl forget_cluster_node rabbit@rabbit1

Dengan melakukan ini, cluster dapat terus berjalan dengan efektif dan Anda dapat memperbaiki node yang gagal.

Penting

Perhatikan ketika Anda me-restart node, itu masih akan berpikir itu adalah bagian dari cluster dan akan meminta Anda untuk mereset node. Setelah mereset, Anda harus dapat bergabung kembali ke node lain sesuai kebutuhan.

rabbit1$ rabbitmqctl start_app
Starting node rabbit@rabbit1 ...

Error: inconsistent_cluster: Node rabbit@rabbit1 thinks it's clustered
       with node rabbit@rabbit2, but rabbit@rabbit2 disagrees

rabbit1$ rabbitmqctl reset
Resetting node rabbit@rabbit1 ...done.
rabbit1$ rabbitmqctl start_app
Starting node rabbit@mcnulty ...
...done.

Memperbaiki cluster RabbitMQ yang dipartisi untuk cluster multi-node

Konsep yang sama berlaku untuk cluster multi-node yang ada di cluster node tunggal. Satu-satunya perbedaan adalah bahwa berbagai node sebenarnya akan berjalan pada host yang berbeda. Hal utama yang perlu diingat ketika berhadapan dengan multi-node cluster adalah:

  • Ketika seluruh klaster diturunkan, node terakhir yang harus turun harus menjadi node pertama yang dibawa online. Jika ini tidak terjadi, node akan menunggu 30 detik untuk node disk terakhir untuk kembali online, dan gagal setelahnya.

    Jika node terakhir untuk offline tidak dapat dibawa kembali, itu dapat dihapus dari cluster menggunakan perintah forget_cluster_node .

  • Jika semua node cluster berhenti secara simultan dan tidak terkontrol, (misalnya, dengan pemadaman listrik), Anda dapat ditinggalkan dengan situasi di mana semua node berpikir bahwa beberapa node lain berhenti setelahnya. Dalam hal ini Anda dapat menggunakan perintah force_boot pada satu node untuk membuatnya dapat di-boot kembali.

Lihat halaman manual rabbitmqctl untuk informasi lebih lanjut.

Migrate between HA and Quorum queues

In the 2024.1 (Caracal) release OpenStack-Ansible switches to use RabbitMQ Quorum Queues by default, rather than the legacy High Availability classic queues. Migration to Quorum Queues can be performed at upgrade time, but may result in extended control plane downtime as this requires all OpenStack services to be restarted with their new configuration.

In order to speed up the migration, the following playbooks can be run to migrate either to or from Quorum Queues, whilst skipping package install and other configuration tasks. These tasks are available from the 2024.1 release onwards.

$ openstack-ansible openstack.osa.rabbitmq_server --tags rabbitmq-config
$ openstack-ansible openstack.osa.setup_openstack --tags common-mq,post-install

In order to take advantage of these steps, we suggest setting oslomsg_rabbit_quorum_queues to False before upgrading to 2024.1. Then, once you have upgraded, set oslomsg_rabbit_quorum_queues back to the default of True and run the playbooks above.