Групиране на RabbitMQ на CentOS 7

RabbitMQ е брокер на съобщения с отворен код, който поддържа AMQP, STOMP и други комуникационни технологии. Той е широко използван в корпоративни приложения и съвременни архитектури на микро-услуги, където действа като асинхронен канал за съобщения между различни микро-услуги. Това ръководство ще опише как можете да групирате RabbitMQ на множество сървъри на CentOS 7, за да образувате посредник за съобщения с висока достъпност. В този урок един сървър ще действа като главен сървър, а другите сървъри ще действат като огледални сървъри, в случай че главният сървър стане недостъпен.

Предпоставки

• Най-малко два току-що внедрени и актуализирани екземпляра на CentOS 7 в една и съща подмрежа с активирана частна мрежа
• RabbitMQ, инсталиран с активирана конзола за управление на всеки сървър (вижте Как да инсталирате RabbitMQ на CentOS 7 )
• Потребител без администратор с sudo права (вижте Как да използвате Sudo на Debian, CentOS и FreeBSD )

Конфигурирайте защитната стена

Защитната стена на CentOS, ( firewalld), не позволява входящ трафик по подразбиране. За да направим RabbitMQ достъпен за други системи в и извън мрежата и за да ни позволим достъп до конзолата за управление, първо трябва да отворим някои портове.

Конзолата за управление на уеб интерфейса на RabbitMQ слуша по подразбиране на порт 15672. Бихме искали да направим конзолата за управление публично достъпна, така че да имаме достъп до нея от нашия компютър. Ето защо ще инструктираме firewalldпостоянно отваряне на порт 15672в публичната зона (която е зоната по подразбиране и активна зона на екземпляр на Vultr).

sudo firewall-cmd --zone=public --add-port=15672/tcp --permanent

Възлите RabbitMQ трябва да могат да комуникират помежду си. Бихме искали да отворим необходимите портове, но само през вътрешната мрежа. Не искаме някой в ​​интернет да може да администрира или директно да се свързва с нашите сървъри. Следните команди предполагат, че нашите сървъри са в 192.168.0.100/24подмрежата.

Първата услуга е услугата за epmdоткриване на партньори, която слуша по подразбиране на порта 4369.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="4369" accept'

За комуникация между възли и CLI RabbitMQ трябва да може да комуникира през порт 25672.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="25672" accept'

CLI инструментите комуникират през диапазона от портове 35672-35682.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="35672-35682" accept'

Ако вашите приложения се нуждаят от протокола AMQP, ще трябва също да отворите портове 5671и 5672. Ако трябва да можете да общувате по друг протокол, можете да намерите необходимата информация за мрежовите изисквания на RabbitMQ в официалната документация на RabbitMQ .

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5672" accept'

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5671" accept'

Сега, когато firewalldе конфигуриран, трябва да го инструктираме да презареди конфигурацията.

sudo firewall-cmd --reload

Повторете стъпките от този раздел на всички сървъри.

Инсталирай rabbitmqadmin

Плъгинът за управление идва с инструмент на Python, наречен, rabbitmqadminкойто може лесно да бъде инсталиран в системата, след като плъгинът за управление е активиран.

sudo wget http://localhost:15672/cli/rabbitmqadmin
sudo mv rabbitmqadmin /usr/local/bin/
sudo chmod +x /usr/local/bin/rabbitmqadmin

Конфигурирайте DNS

Трябва да използвате имената на хостовете на сървъра, за да идентифицирате сървърите при клъстериране. По подразбиране сървърите нямат назначен DNS запис и връзката ще се провали. За да преодолеете бързо това, добавете главното и огледалното име на хост към /etc/hostsфайла, като използвате любимия си редактор.

Например хост файлът на вашия господар може да изглежда по следния начин. Обърнете внимание на последните два записа, които позволяват на сървърите да се идентифицират един друг по името на хоста си. Не забравяйте да промените IP адресите на вашите собствени.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

127.0.0.1 guest
::1       guest

127.0.0.1 YOUR_MASTER_SERVER_HOST_NAME
::1       YOUR_MASTER_SERVER_HOST_NAME


192.168.0.101 YOUR_MASTER_SERVER_HOST_NAME
192.168.0.102 YOUR_MIRROR_SERVER_HOST_NAME

Групирайте възлите

Предпоставка за импортиране, за да се позволи на възлите да се присъединят един към друг, е бисквитката Erlang на всички възли да са идентични. По подразбиране на всеки възел ще бъде присвоена уникална бисквитка Erlang, така че трябва да я преконфигурирате на всички възли.

Следната команда ще настрои бисквитката Erlang на " WE<3COOKIES", но не се колебайте да промените това по ваш вкус. Направете това на всички сървъри.

sudo sh -c "echo 'WE<3COOKIES' > /var/lib/rabbitmq/.erlang.cookie"

Рестартирайте RabbitMQ на всички сървъри, за да се уверите, че бисквитката Erlang е правилно презаредена.

sudo systemctl restart rabbitmq-server.service

Изпълнете следните команди на всички сървъри, освен на главния сървър. Това ще позволи на възлите да се присъединят към главния сървър и да образуват клъстер.

sudo rabbitmqctl stop_app
sudo rabbitmqctl join_cluster "rabbit@<YOUR_MASTER_SERVER_HOST_NAME>"
sudo rabbitmqctl start_app

Проверете дали възлите са се присъединили към клъстера, като изпълните следната команда.

sudo rabbitmqctl cluster_status

Всичките ви възли ще се появят в секцията nodesи running_nodesна изхода. Отсега нататък вече не е необходимо да повтаряте стъпки на всеки сървър, конфигурацията автоматично ще бъде огледална към другите възли.

Създайте политика за висока наличност

Сега, когато имаме клъстер от възли RabbitMQ, можем да използваме това, за да правим опашки с висока наличност и обмени, като настроим нова политика. Тази политика може да бъде добавена чрез конзолата за управление на RabbitMQ или чрез интерфейса на командния ред.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "all" ha ".*" '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}'

Следващият списък ще обясни какво означава всяка част от командата.

• -p "/": Използвайте тази политика на "/"vhost (по подразбиране след инсталиране)
• --priority 1: Редът, в който да се прилагат политиките
• --apply-to "all": Може да бъде "queues", "exchanges"или"all"
• ha: Името, което даваме на нашата политика
• ".*": Регулярният израз, който се използва, за да реши към кои опашки или обмени да се приложи това правило. ".*"ще съответства на всичко
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': JSON представянето на политиката. Този документ описва, че искаме - точно 2 възела, на които данните се синхронизират автоматично

Накратко, тази политика ще гарантира, че винаги ще имаме 2 копия на данните на опашка или обмен, стига да имаме поне 2 възела, работещи и работещи. Ако имате повече възли, можете да увеличите стойността на ha-params. Препоръчва се кворум ( N/2 + 1) от възли. Наличието на повече копия на вашите данни ще доведе до по-високо използване на диск, вход/изход и мрежа, което може да доведе до влошаване на производителността.

Ако искате да отразявате данните във всички възли в клъстера, можете да използвате следния JSON документ.

'{ "ha-mode": "all", "ha-sync-mode": "automatic"}'

Ако искате да отразявате данните само към конкретни възли (например: node-1и node-2), можете да използвате следното.

'{ "ha-mode": "nodes", "ha-params" :["rabbit@node-1", "rabbit@node-2"], "ha-sync-mode": "automatic"}'

Можете да промените регулярния израз, за ​​да присвоите различни политики на различни опашки. Да кажем, че имаме следните три възела:

• заек@майстор
• rabbit@client-ha
• заек@продукт-ха

След това можем да създадем две политики, които ще доведат до това, че опашките с име, което започва с "клиент", да бъдат огледални към rabbit@client-haвъзела и всички опашки, които имат име, което започва с "продукт", да бъдат огледални към rabbit@product-haвъзела.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-client "client.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@client-ha"], "ha-sync-mode": "automatic"}
sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-product "product.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@product-ha"], "ha-sync-mode": "automatic"}

Една малка забележка тук: изключителните опашки никога не са огледални или трайни в RabbitMQ, дори ако тази политика съответства на такива опашки. Изключителните опашки се унищожават автоматично, след като клиентът прекъсне връзката и като такъв не би било от полза да го репликирате на друг сървър. Ако сървърът се повреди, клиентът ще прекъсне връзката с него и опашката ще бъде унищожена автоматично. Огледалните екземпляри също ще бъдат унищожени.

Тестване на настройката

За да тестваме клъстерираната настройка, можем да създадем нова опашка, използвайки интерфейса на командния ред през конзолата за управление.

sudo rabbitmqadmin declare queue --vhost "/" name=my-ha-queue durable=true

Това ще създаде трайна опашка на /vhost по подразбиране с името my-ha-queue.

Изпълнете следната команда и проверете в изхода, че на опашката е присвоена нашата политика 'ha' и има pid на главния и на огледалния възел.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Вече можем да публикуваме съобщение на опашката от главния възел и да спрем RabbitMQ на главния възел.

sudo rabbitmqadmin -u user_name -p password  publish routing_key=my-ha-queue payload="hello world"
sudo systemctl rabbitmqctl shutdown

Сега го върнете, като се свържете с огледалния възел.

 sudo rabbitmqadmin -H MIRROR_NODE_IP_OR_DNS -u user_name -p password get queue=my-ha-queue

Накрая можем да рестартираме нашия главен възел.

sudo systemctl start rabbitmq-server.service

Изтрийте гост потребителя

Както споменахме по-горе, RabbitMQ автоматично създава гост потребител с парола за гост по подразбиране. Би било лоша практика да оставите този потребител по подразбиране на публично открита система.

sudo rabbitmqctl delete_user guest