Clustering RabbitMQ na CentOS 7

• Wymagania wstępne
• Skonfiguruj zaporę
• Zainstaluj rabbitmqadmin
• Skonfiguruj DNS
• Klaster węzłów
• Utwórz politykę wysokiej dostępności
• Testowanie konfiguracji
• Usuń użytkownika-gościa

RabbitMQ to broker komunikatów typu open source, który obsługuje AMQP, STOMP i inne technologie komunikacyjne. Jest szeroko stosowany w aplikacjach korporacyjnych i nowoczesnych architekturach mikrousług, gdzie działa jako asynchroniczny kanał komunikatów między różnymi mikrousługami. W tym przewodniku opisano sposób klastra RabbitMQ na wielu serwerach CentOS 7 w celu utworzenia brokera komunikatów o wysokiej dostępności. W tym samouczku jeden serwer będzie działał jako serwer główny, a pozostałe serwery będą działać jako serwery lustrzane na wypadek, gdyby serwer główny stał się niedostępny.

Wymagania wstępne

• Co najmniej dwie świeżo wdrożone i zaktualizowane instancje CentOS 7 w tej samej podsieci z włączoną siecią prywatną
• RabbitMQ zainstalowany z włączoną konsolą zarządzania na każdym serwerze (zobacz Jak zainstalować RabbitMQ na CentOS 7 )
• Użytkownik niebędący administratorem z uprawnieniami sudo (zobacz Jak korzystać z Sudo w Debianie, CentOS i FreeBSD )

Skonfiguruj zaporę

Zapora sieciowa CentOS ( firewalld) domyślnie nie zezwala na ruch przychodzący. Aby RabbitMQ był dostępny dla innych systemów w sieci i poza nią oraz aby umożliwić nam dostęp do konsoli zarządzania, musimy najpierw otworzyć niektóre porty.

Konsola zarządzania interfejsem sieciowym RabbitMQ domyślnie nasłuchuje na porcie 15672. Chcemy udostępnić publicznie konsolę zarządzania, abyśmy mogli uzyskać do niej dostęp z naszego komputera. Dlatego poinstruujemy, firewalldaby na stałe otworzyć port 15672w strefie publicznej (która jest domyślną i aktywną strefą w instancji Vultr).

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

Węzły RabbitMQ muszą mieć możliwość komunikowania się ze sobą. Chcielibyśmy otworzyć niezbędne porty, ale tylko przez sieć wewnętrzną. Nie chcemy, aby ktokolwiek w Internecie mógł administrować lub bezpośrednio kontaktować się z naszymi serwerami. Poniższe polecenia zakładają, że nasze serwery znajdują się w 192.168.0.100/24podsieci.

Pierwszą usługą jest usługa wyszukiwania epmdrównorzędnego, która domyślnie nasłuchuje na porcie 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'

W przypadku komunikacji w trybie międzynarodowym i CLI RabbitMQ musi mieć możliwość komunikacji przez port 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'

Narzędzia CLI komunikują się w zakresie portów 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'

Jeśli twoje aplikacje potrzebują protokołu AMQP, będziesz również musiał otworzyć porty 5671i 5672. Jeśli potrzebujesz możliwości komunikacji za pośrednictwem innego protokołu, możesz znaleźć niezbędne informacje na temat wymagań sieciowych RabbitMQ w oficjalnej dokumentacji 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'

Teraz, gdy firewalldjest skonfigurowany, musimy poinstruować go, aby ponownie załadował konfigurację.

sudo firewall-cmd --reload

Powtórz kroki z tej sekcji na wszystkich serwerach.

zainstalować rabbitmqadmin

Wtyczka do zarządzania jest dostarczana z narzędziem Python, rabbitmqadminktóre można łatwo zainstalować w systemie po włączeniu wtyczki do zarządzania.

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

Skonfiguruj DNS

Musisz użyć nazw hosta serwera, aby zidentyfikować serwery podczas klastrowania. Domyślnie serwery nie mają przypisanego rekordu DNS i połączenie nie powiedzie się. Aby szybko temu zaradzić, dodaj nazwę hosta głównego i /etc/hostskopii lustrzanej do pliku za pomocą swojego ulubionego edytora.

Na przykład plik hosts głównego może wyglądać następująco. Zwróć uwagę na dwa ostatnie rekordy, które pozwalają serwerom na identyfikację się po nazwie hosta. Pamiętaj, aby zmienić adresy IP na własne.

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

Klaster węzłów

Warunkiem importu umożliwiającym połączenie węzłów jest to, że ciasteczko Erlang wszystkich węzłów jest identyczne. Domyślnie do każdego węzła zostanie przypisany unikalny plik cookie Erlang, dlatego należy go ponownie skonfigurować we wszystkich węzłach.

Następujące polecenie ustawi ciasteczko Erlang na „ WE<3COOKIES”, ale możesz je zmienić według własnych upodobań. Zrób to na wszystkich serwerach.

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

Uruchom ponownie RabbitMQ na wszystkich serwerach, aby upewnić się, że ciasteczko Erlang zostało poprawnie ponownie załadowane.

sudo systemctl restart rabbitmq-server.service

Wykonaj następujące polecenia na wszystkich serwerach oprócz serwera głównego. Pozwoli to węzłom dołączyć do serwera głównego i utworzyć klaster.

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

Sprawdź, czy węzły dołączyły do ​​klastra, uruchamiając następujące polecenie.

sudo rabbitmqctl cluster_status

Wszystkie twoje węzły pojawią się w sekcji nodesi running_nodeswyniku. Odtąd nie trzeba już powtarzać kroków na każdym serwerze, konfiguracja będzie automatycznie dublowana w innych węzłach.

Utwórz politykę wysokiej dostępności

Teraz, gdy mamy klaster węzłów RabbitMQ, możemy go wykorzystać do tworzenia kolejek i wymian o wysokiej dostępności, ustanawiając nowe zasady. Te zasady można dodać za pomocą konsoli zarządzania RabbitMQ lub interfejsu wiersza poleceń.

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

Poniższa lista wyjaśni, co oznacza każda część polecenia.

• -p "/": Użyj tej zasady na "/"vhostie (domyślnie po instalacji)
• --priority 1: Kolejność stosowania zasad
• --apply-to "all": Może być "queues", "exchanges"lub"all"
• ha: Nazwa, którą nadajemy naszej polityce
• ".*": Wyrażenie regularne, które służy do decydowania, które kolejki lub wymiany są stosowane. ".*"dopasuje wszystko
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': Reprezentacja zasad przez JSON. Ten dokument opisuje, że chcemy - dokładnie 2 węzły, na których dane są automatycznie synchronizowane

Krótko mówiąc, ta zasada zapewni, że zawsze będziemy mieć 2 kopie danych w kolejce lub wymianie, o ile będziemy mieć co najmniej 2 uruchomione węzły. Jeśli masz więcej węzłów, możesz zwiększyć wartość ha-params. N/2 + 1Zalecane jest kworum ( ) węzłów. Posiadanie większej liczby kopii danych spowodowałoby większe zużycie dysku, operacji we / wy i sieci, co mogłoby obniżyć wydajność.

Jeśli chcesz skopiować dane do wszystkich węzłów w klastrze, możesz użyć następującego dokumentu JSON.

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

Jeśli chcesz skopiować dane tylko do określonych węzłów (na przykład: node-1i node-2), możesz użyć następujących.

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

Możesz zmienić wyrażenie regularne, aby przypisać różne zasady do różnych kolejek. Powiedzmy, że mamy następujące trzy węzły:

• królik @ mistrz
• królik @ klient-ha
• królik @ produkt-ha

Możemy następnie utworzyć dwie polityki, które spowodują, że kolejki będą miały nazwę zaczynającą się od „klienta”, która będzie dublowana do rabbit@client-hawęzła, i wszystkie kolejki, które mają nazwę rozpoczynającą się od „produktu”, będą dublowane do rabbit@product-hawęzła.

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"}

Mała uwaga tutaj: wyłączne kolejki nigdy nie są dublowane ani trwałe w RabbitMQ, nawet jeśli te zasady pasują do takich kolejek. Wyłączne kolejki są automatycznie niszczone, gdy klient się rozłącza, i dlatego replikacja go na innym serwerze nie byłaby użyteczna. Jeśli serwer ulegnie awarii, klient rozłączy się z nim, a kolejka zostanie automatycznie zniszczona. Lustrzane instancje również zostaną zniszczone.

Testowanie konfiguracji

Aby przetestować konfigurację klastrową, możemy utworzyć nową kolejkę za pomocą interfejsu wiersza poleceń za pośrednictwem konsoli zarządzania.

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

Spowoduje to utworzenie trwałej kolejki na domyślnym /vhostie o nazwie my-ha-queue.

Uruchom następującą komendę i sprawdź w danych wyjściowych, że do kolejki ma przypisaną naszą zasadę „ha” i ma pid na urządzeniu głównym i węźle lustrzanym.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Możemy teraz opublikować komunikat w kolejce z węzła głównego i zatrzymać RabbitMQ w węźle głównym.

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

Teraz odzyskaj go, łącząc się z węzłem lustrzanym.

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

Wreszcie możemy ponownie uruchomić nasz węzeł główny.

sudo systemctl start rabbitmq-server.service

Usuń użytkownika-gościa

Jak wspomniano wcześniej, RabbitMQ automatycznie tworzy użytkownika gościa z domyślnym hasłem gościa. Złą praktyką byłoby pozostawienie tego domyślnego użytkownika w systemie publicznym.

sudo rabbitmqctl delete_user guest