Nie dopuść, aby VRRP Master został Mistrzem po awarii

12

Mam dwie maszyny (A i B, A to Master) z systemem VRPP (z keepalived) dla wirtualnego adresu IP.

Jak mogę zapobiec ponownemu zostaniu Mistrzem A, jeśli zawiódł i nie wrócił (z jakiegokolwiek powodu)?

Robię to, abyśmy mieli jedno przełączenie awaryjne na drugie okno, a powrót do normy wymagałby ręcznej interwencji.

linux keepalived vrrp

— MrMagu
źródło

Jestem zbyt nowy, aby utworzyć tag „VRRP”

— MrMagu

14

Zgodnie z tym stosunkowo starym wątkiem na liście programistów Keepalived można to zrobić. Ustawiasz oba serwery na równy priorytet (lub wcale), i nie deklarujesz stanu jako MASTER lub BACKUP, a zamiast tego ustawiasz stan na EQUAL dla obu.

EDYCJA (07 grudnia 2017):

Wygląda na to, że EQUAL nie jest tak naprawdę prawidłowym stanem, mimo że wydaje się, że zapewnia pożądany efekt w chwili opublikowania tej odpowiedzi. Zwróć uwagę na poniższe komentarze, w szczególności link do bieżącej listy problemów dla keepalived, dostarczonej przez @cristi.

— James Sneeringer
źródło

3

Dziękujemy - Warto również zwrócić uwagę, używając powyższej konfiguracji (o równym priorytecie i używając „EQUAL”), jeśli żaden master nie przejął, instancja VRRP o najniższym IP stanie się MASTER.

— MrMagu

1

To jest źle. Zobacz tę wiadomość od programistów: github.com/acassen/keepalived/issues/707

— cristi

@ Cristi - Było to działające rozwiązanie w momencie, gdy zostało opublikowane (2009), które z kolei było oparte na informacjach, które wyraźnie uznałem za stare nawet wtedy (2003). Zaktualizowałem łącze w mojej odpowiedzi na działające, ponieważ wydaje się, że osdir.com nie ma już archiwów keepalived-devel. Domyślam się, że w tamtym czasie oprogramowanie po cichu zignorowało niepoprawną EQUALdyrektywę i traktowało ją tak, jakby żaden priorytet nie został ustawiony (co akurat przyniosło pożądany efekt).

— James Sneeringer,

8

Rozwiązaliśmy to poprzez dodanie nopreemptflagi do naszego pliku konfiguracyjnego Keepalived. Nie musiałem nic zmieniać (nadal pozostawiałem jeden jako taki, MASTERa drugi tak BACKUPi tak dalej). Zasadniczo mówi to, aby nie przełączać masterów tylko dlatego, że nowy serwer wszedł w tryb online, przełącza się tylko, gdy obecny master zawiedzie.

— davr
źródło

4

from „ article.gmane.org/gmane.linux.keepalived.devel/1537 „ Jeśli „stan” jest ustawiony na MASTER, „nopreempt” jest zasadniczo ignorowany, ponieważ gdy maszyna z „stan MASTER” powróci, po prostu pobierze adres IP z maszyna z „stanem BACKUP” bez przeprowadzania wyborów. Musiałem ustawić oba moje komputery na stan BACKUP z jednym o wyższym priorytecie, aby „nopreempt” działał zgodnie z przeznaczeniem.

— MrMagu

Usunięto priorytet i stan oraz dodano niepoprawę. Działa dla mnie dobrze

— Rihard Novozhilov,

-1

Jak rozumiem, kiedy pojawia się nowy serwer VRRP, wymusza wybory, a obecny serwer nie ma żadnych korzyści, więc stary mistrz przyjdzie i wygra wybory. Wątpię, byś mógł zrobić wiele, by to powstrzymać, poza dość brutalnym Shoot The Other Node In The Head. Keepalive może mieć pewną konfigurację do kontrolowania procesu wyborczego. Niestety nie mam teraz czasu na sprawdzenie, ale spróbuję później.

— David Pashley
źródło

Robi to flaga konfiguracji, więc ta odpowiedź jest zła.

— davr

Głosowana odpowiedź jest poprawna dla ogólnego wdrożenia vrrp, w którym nie chcesz, aby master przejął kontrolę po powrocie do usługi. Jak mówisz, istnieje również utrzymywany sposób na zrobienie tego, co jest prawdopodobnie bardziej poprawne podczas robienia rzeczy związanych z linuksem HA zamiast używania vrrp w celu zapewnienia redundancji L3 dla domyślnej trasy (bardziej tradycyjny powód używania vrrp).

— Chris