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.

Dalam OpenStack-Ansible, semua data dan status yang diperlukan untuk pengoperasian kluster RabbitMQ direplikasi di semua node termasuk antrian pesan yang menyediakan ketersediaan tinggi. Node RabbitMQ membahas satu sama lain menggunakan nama domain. Nama host dari semua anggota cluster harus dapat dipecahkan dari semua node cluster, serta mesin apa pun yang mana alat CLI yang terkait dengan RabbitMQ dapat digunakan. Ada alternatif yang dapat bekerja di lingkungan yang lebih ketat. Untuk detail lebih lanjut tentang pengaturan itu, lihat Inet Configuration.

Catatan

Saat ini ada bug Ansible dalam hal HOSTNAME. Jika host .bashrc menyimpan var bernama HOSTNAME, penampung dimana modul lxc_container 'menempel akan mewarisi var ini dan berpotensi menyetel $HOSTNAME yang salah. Lihat the Ansible fix yang akan dirilis dalam Ansible versi 2.3.

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.

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¶

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.

Bergabunglah dengan cluster, dan restart aplikasi pada node ketiga.

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 dan mnesia¶

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

Untuk informasi lebih lanjut tentang Mnesia, lihat Mnesia overview.

Untuk melihat lokasi file Rabbit yang penting, lihat File Locations.

Perbaiki klaster RabbitMQ yang dipartisi untuk satu node¶

Tanpa kecuali penyebab sesuatu di lingkungan Anda, Anda cenderung kehilangan node di kluster Anda. Dalam skenario ini, beberapa kontainer LXC di host yang sama menjalankan Rabbit dan berada dalam satu cluster Rabbit.

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:

Pastikan RabbitMQ tidak berjalan di node:
```
# rabbitmqctl stop_app
```

Pada node Rabbit2, jalankan:

# 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.

Pemeliharaan klaster RabbitMQ

Pemeliharaan klaster RabbitMQ¶

Buat klaster RabbitMQ¶

Periksa status cluster RabbitMQ¶

Berhenti dan mulai kembali klaster RabbitMQ¶

RabbitMQ dan mnesia¶

Perbaiki klaster RabbitMQ yang dipartisi untuk satu node¶

Memperbaiki cluster RabbitMQ yang dipartisi untuk cluster multi-node¶

openstack-ansible 28.1.0.dev135

Page Contents