Poprzednio powiedzieliśmy sobie o skalowalności op5 w odniesieniu do rozproszonej infrastruktury.
Czasami jednak możemy nie mieć jasnego sposobu podziału zadań pomiędzy serwery op5 Monitora, co wtedy?
Zespół op5 podołał zadaniu równoważenia obciążenia (load balancing).
Co z tego wynika:
Dwa lub więcej peerów związanych z tymi samymi zadaniami
Peery są identyczne, także mamy możliwość konfiguracji z dowolnego peera
Nowa konfiguracja musi trafić do wszystkich pozostałych węzłów
Peery automatycznie dzielą obciążenie między siebie
Po awarii jednego węzła, jego zadania automatycznie zostają przydzielone pozostałym
Wymagania są identyczne jak w przypadku węzłów w modelu rozproszonej infrastruktury
Przynajmniej dwa serwery op5 Monitor tej samej architektury (ważne)
Najlepiej tą samą wersję op5 Monitor, a przynajmniej >=5.2
Otwarty ruch pomiędzy serwerami na portach 15551 (port backendowy op5) i 22 (służący do synchronizowania konfiguracji)
Dodatkowo chcielibyśmy korzystać z nazw domenowych, ale odpowiednie wpisy w /etc/host.conf wystarczą
Przyjrzyjmy się kilku przykładowym zadaniom, które mogą być przydatne w takiej architekurze:
Konfiguracji na przykładzie dwóch serwerów peer1 i peer2
Dodaniu nowego peera peer3
Usunięciu peera peer2
Ustawieniu plików, które mają być synchronizowane
Podobnie jak w przypadku modelu master-poller korzystamy z narzędzia mon, które jest powiązane z modułem merlin (które to jest odpowiedzialny za skalowalność)
Konfiguracja na przykładzie dwóch serwerów peer1 i peer2.
Jako root na peer1 wykonujemy następujące polecenia
Dodanie nowego peera peer3
Usunięcie peera peer2
Jako root na peer1 wykonujemy następujące polecenia
Ustawienie plików, które podlegają synchronizacji.
Sytuacja wygląda identycznie jak w przypadku konfiguracji master->poller
Plik /opt/monitor/op5/merlin/merlin.conf
Zwróćmy uwagę że musi to zostać dopisane do każdego peera
Czasami jednak możemy nie mieć jasnego sposobu podziału zadań pomiędzy serwery op5 Monitora, co wtedy?
Zespół op5 podołał zadaniu równoważenia obciążenia (load balancing).
Co z tego wynika:
Dwa lub więcej peerów związanych z tymi samymi zadaniami
Peery są identyczne, także mamy możliwość konfiguracji z dowolnego peera
Nowa konfiguracja musi trafić do wszystkich pozostałych węzłów
Peery automatycznie dzielą obciążenie między siebie
Po awarii jednego węzła, jego zadania automatycznie zostają przydzielone pozostałym
Wymagania są identyczne jak w przypadku węzłów w modelu rozproszonej infrastruktury
Przynajmniej dwa serwery op5 Monitor tej samej architektury (ważne)
Najlepiej tą samą wersję op5 Monitor, a przynajmniej >=5.2
Otwarty ruch pomiędzy serwerami na portach 15551 (port backendowy op5) i 22 (służący do synchronizowania konfiguracji)
Dodatkowo chcielibyśmy korzystać z nazw domenowych, ale odpowiednie wpisy w /etc/host.conf wystarczą
Przyjrzyjmy się kilku przykładowym zadaniom, które mogą być przydatne w takiej architekurze:
Konfiguracji na przykładzie dwóch serwerów peer1 i peer2
Dodaniu nowego peera peer3
Usunięciu peera peer2
Ustawieniu plików, które mają być synchronizowane
Podobnie jak w przypadku modelu master-poller korzystamy z narzędzia mon, które jest powiązane z modułem merlin (które to jest odpowiedzialny za skalowalność)
Konfiguracja na przykładzie dwóch serwerów peer1 i peer2.
Jako root na peer1 wykonujemy następujące polecenia
KOD: ZAZNACZ CAŁY
Code:
#dodajemy do konfiguracji drugiego peera
mon node add peer2 type=peer
#tworzymy i wymieniamy klucze ssh między serwerami
mon sshkey push --all
mon sshkey fetch --all
#dodajemy do konfiguracji [i]peer2[/i] [i]peer1[/i]
mon node ctrl peer2 -- mon node add peer1 type=peer
#synchronizujemy konfigurację
mon oconf push
#restartujemy op5monitor na wszystkich peerach i wysyłamy logi
mon node ctrl --self -- mon restart; sleep 3; mon log push
Dodanie nowego peera peer3
KOD: ZAZNACZ CAŁY
Code:
Jako root na peer1 wykonujemy następujące polecenia
#Dodajemy peer3 do konfiguracji peer1 i peer2
mon node add peer3 type=peer
#Wymieniamy klucze ssh
mon sshkey push --all
mon sshkey fetch --all
#Dodajemy do konfiguracji na wzajem peery 2 i 3, a także 1 do konfiguracji peer3
mon node ctrl peer2 -- mon node add peer3 type=peer
mon node ctrl peer3 -- mon node add peer2 type=peer
mon node ctrl peer3 -- mon node add peer1 type=peer
#synchronizujemy konfigurację
mon oconf push
#restartujemy wszystkie peery i ponownie wysyłamy konfiguracją
mon node ctrl --self -- mon restart ; sleep 3 ; mon oconf push
Usunięcie peera peer2
Jako root na peer1 wykonujemy następujące polecenia
KOD: ZAZNACZ CAŁY
Code:
#Usuwamy konfigurację z [i]peer2[/i]
mon node ctrl peer2 -- mon node remove peer1
mon node ctrl peer2 -- mon node remove peer3
#Restartujemy peer2
mon node ctrl peer2 -- mon restart
#Usuwamy z konfiguracji pozostałych nodów [i]peer2[/i] (w tym przypadku tylko z peer3)
mon node ctrl --type=peer -- mon node remove peer2
#Restartujemy pozostałe nody
mon node ctrl --type=peer -- mon restart
#usuwamy peer2 z konfiguracji serwera na którym jesteśmy zalogowani
mon node remove peer2
#restartujemy op5 monitor na bieżącym serwerze
mon node ctrl -- mon restart
Ustawienie plików, które podlegają synchronizacji.
Sytuacja wygląda identycznie jak w przypadku konfiguracji master->poller
Plik /opt/monitor/op5/merlin/merlin.conf
KOD: ZAZNACZ CAŁY
Code:
peer peer2 {
address = <ip>
port = <port>
contact_group = <contactgroup>
sync {
/opt/plugins/custom/
/opt/monitor/etc/resource.cfg
/etc/op5/
}
}
Zwróćmy uwagę że musi to zostać dopisane do każdego peera