Jak skonfigurować RabbitMQ przy użyciu architektury Active/Passive High Availability

Question

Próbuję skonfigurować klaster serwerów RabbitMQ, aby uzyskać wysoce dostępne kolejki przy użyciu architektury serwerowej aktywnej/pasywnej. Obserwuję to prowadzi:

1. http://www.rabbitmq.com/clustering.html
2. http://www.rabbitmq.com/ha.html
3. http://karlgrz.com/rabbitmq-highly-available-queues-and-clustering-using-amazon-ec2/

Moje wymóg wysokiej dostępności jest prosta, mam dwa węzły (CentOS 6.4) z RabbitMQ (v3.2) i Erlang R15B03. Węzeł 1 musi być "aktywny", odpowiadając na wszystkie żądania, a węzeł 2 musi być węzłem "pasywnym", który ma replikowane wszystkie kolejki i komunikaty (z węzła 1).

Aby to zrobić, mam skonfigurowane następujące:

• node1 z RabbitMQ działa poprawnie w trybie non-klastra
• Node2 z RabbitMQ działa poprawnie w trybie non-klastra

następnie stworzyłem klaster między obydwoma węzłami: łącząc Node2 z Node1 (przewodnik 1). Następnie skonfigurowałem zasadę tworzenia dublowania kolejek (przewodnik 2), replikowania wszystkich kolejek i wiadomości między wszystkimi węzłami w klastrze. Działa to, mogę połączyć się z dowolnym węzłem i opublikować lub skonsumować wiadomość, gdy oba węzły są dostępne.

Problem występuje, gdy mam kolejkę "queueA", która została utworzona w węźle 1 (wzorzec w kolejce A), a gdy węzeł 1 jest zatrzymany, nie mogę połączyć się z koleją A w węźle 2, aby tworzyć lub zużywać wiadomości, Węzeł2 zgłasza błąd informujący, że węzeł 1 jest niedostępny (uważam, że kolejka A nie jest replikowana do węzła Node2, a węzła Node2 nie można awansować jako wzorca kolejki A).

Błąd jest:

{ "The AMQP operacja została przerwana: AMQP zbliżenie powód, zainicjowany przez Peer, code = 404, text = \" NOT_FOUND - home węzeł 'królik @ node1' z trwały kolejek queueA 'w vhost 'app01' jest w dół lub w niedostępnych \ "CLASSID = 50 methodId = 10, bo ="}

kolejność etapów jest stosowany:

Node1:

1. rabbitmq-server -detached 
2. rabbitmqctl start_app 

Node2:

3. Copy .erlang.cookie from Node1 to Node2 
4. rabbitmq-server -detached 

Dołącz do klastra (Node2):

5. rabbitmqctl stop_app 
6. rabbitmqctl join_cluster rabbit@node1 
7. rabbitmqctl start_app 

Konfiguracja Kolejka mirroring polityka:

8. rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' 

Uwaga: Wzór stosowany do nazw kolejek to "" (wszystkie kolejki).

Po uruchomieniu "rabbitmqctl list_policies" i "rabbitmqctl cluster_status" wszystko jest w porządku.

Dlaczego węzeł2 nie może odpowiedzieć, jeśli węzeł 1 jest niedostępny? Czy jest coś nie tak w tej konfiguracji?

Answer 1

Czy w konsoli zarządzania sieciowego kolejka A jest wyświetlana jako Węzeł1 +1?

Wygląda na to, że może wystąpić problem z konfiguracją. Mam zestaw vagrant boxes, które są wstępnie skonfigurowane do pracy w klastrze. Czy warto wypróbować to i zidentyfikować problemy w konfiguracji?

Answer 2

Czytaj uważnie informacyjnych

http://www.rabbitmq.com/ha.html

Można użyć skupisko węzłów RabbitMQ skonstruować swój RabbitMQ brokera. Będzie to odporne na utratę pojedynczych węzłów w warunkach ogólnej dostępności usługi, ale niektóre ważne zastrzeżenia o numerach obowiązują: , podczas gdy wymiany i wiązania przetrwają utratę poszczególnych węzłów, kolejek i ich wiadomości nie. Dzieje się tak dlatego, że kolejka i jej zawartość znajdują się dokładnie na jednym węźle, a zatem utrata węzła spowoduje, że jego kolejki będą niedostępne.

Answer 3

Upewnij się, że kolejka nie jest trwała lub ekskluzywna.

Z dokumentacji (https://www.rabbitmq.com/ha.html):

Exclusive kolejki zostaną usunięte podczas połączenia, które je zadeklarowana jest zamknięta. Z tego powodu nie jest przydatne, aby ekskluzywna kolejka miała być dublowana (lub trwała), ponieważ gdy węzeł hostuje go, połączenie zostanie zamknięte, a kolejka będzie musiała zostać usunięta w każdym razie i .

Z tego powodu, ekskluzywne kolejki nie są nigdy odzwierciedlane (nawet jeśli są zgodne z zasadami stwierdzającymi, że powinny być). Nie są też nigdy trwałe (nawet jeśli są zadeklarowane jako takie).

ze swojego komunikat o błędzie:

{ "The AMQP operacja została przerwana: AMQP zbliżenie powód, zainicjowany przez Peer, code = 404, text = \" NOT_FOUND - węzeł domu „królik @ node1' z wytrzymałego kolejce 'queueA' w vhost 'app01' jest wyłączony lub niedostępny \ "cLASSID = 50, methodId = 10, przyczyna ="}

wygląda na to stworzył trwałe kolejki.

Answer 4

Nie określono hosta wirtualnego (app01) w wywołaniu set_policy, w związku z czym zasada będzie obowiązywać tylko dla domyślnego hosta wirtualnego (/). Komenda ta powinna działać:

rabbitmqctl set_policy -p app01 ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' 

Answer 5

Tylko kolejka lustro, które są zsynchronizowane z mistrzem są promowane jako mistrz, po awarii. Jest to domyślne zachowanie, ale można je zawsze zmienić na promowanie po zamknięciu systemu.