07-31-2019, 07:29 AM
Nagios, ani jego pochodne niestety nie przewiduje grupowania hostów w klastry. Oczywiście nie ma powodów dla których nie moglibyśmy monitorować fizyczności każdego z węzłów klastra osobno – prawdopodobnie jednak nie zależy nam tylko na tym, aby poznać jedynie obciążenie procesora, dysków, czy pamięci RAM.
Należy zadać sobie pytanie, co jest najistotniejsze w działaniu klastra. Odpowiedź jest dość prosta – dostępność usług. Do klastra często możemy przypisać całe mnóstwo adresów IP – fizycznych nodów, jak i logicznych związanych z usługami. Jak można sobie z tym poradzić?
Jak już pisałem, możemy monitorować każdy maszynę osobno. Sam stan naszego hosta-klastra powinien raczej zależeć od stanu IP logicznych niż fizycznych. Na szczęście Nagios Core pozwala nam na przypisanie parametru check_command i check_command_args nie tylko do serwisu. Jest to o tyle przydatne, że jeśli do naszego klastra przypiszemy przykładowo 10 adresów, to musimy jakoś sobie z nimi poradzić – domyślna metoda check-host-alive w tym przypadku niewiele nam pomoże. Dlatego utworzyliśmy komendę która sprawdza po kolei wszystkie IP z listy oddzielonej przecinkami, a lista ta zostaje umieszczona w parametrze address hosta, przez co jest dostępna w macro $HOSTADDRESS$.
Oczywiście tej samej metody możemy użyć wewnątrz klastra celem sprawdzenia IP fizycznych, jednak naszym zdaniem stan fizycznych IP nie powinien wpływać na stan klastra jako hosta.
W ten sposób utworzyliśmy hosta, który jest odpowiednim miejscem dla monitoringu wszelki serwisów uruchomionych na klastrze, tj. baz danych, stron www, a także GFS (Global File System) – te zasoby przecież są współdzielone między węzły klastra.
Powyższe informacje tak naprawdę możemy zastosować do dowolnego klastra, nie koniecznie opartego o systemy Red Hat. Monitoring powinien również oprzeć się o komendę
Niestety komenda ta wymaga uprawnień uid 0, przez co system monitoringu musi mieć odpowiedni wpis w pliku /etc/sudoers – albo dla komendy, albo dla metody np.
Ta komenda daje nam informacje na temat statusu węzłów (Online, Offline, Inactive) i statusu usług (started, failed, pending, disabled, stopped). Przykładowy wynik komendy:
Ważne jest aby wykonywać sprawdzenie na wszystkich węzłach. W przypadku gdy któryś z węzłów nie działa w klastrze, nie ma on informacji o pozostałych węzłach i usługach.
To co nas interesuje w przypadku stanu członków to, czy wszyscy pozostają w stanie Online. Proponujemy aby informacja o stanie Offline wywoływała stan krytyczny (CRITICAL), a informacja o stanie Inactive stan ostrzegawczy (WARNING).
Podobnie w przypadku serwisów, stan porządany to wszystkie usługi w stanie started. Bez wątpienia stan failed możemy uznać za stan krytyczny, a stany pending, disabled i stopped jako stany ostrzegawcze.
Należy zadać sobie pytanie, co jest najistotniejsze w działaniu klastra. Odpowiedź jest dość prosta – dostępność usług. Do klastra często możemy przypisać całe mnóstwo adresów IP – fizycznych nodów, jak i logicznych związanych z usługami. Jak można sobie z tym poradzić?
Jak już pisałem, możemy monitorować każdy maszynę osobno. Sam stan naszego hosta-klastra powinien raczej zależeć od stanu IP logicznych niż fizycznych. Na szczęście Nagios Core pozwala nam na przypisanie parametru check_command i check_command_args nie tylko do serwisu. Jest to o tyle przydatne, że jeśli do naszego klastra przypiszemy przykładowo 10 adresów, to musimy jakoś sobie z nimi poradzić – domyślna metoda check-host-alive w tym przypadku niewiele nam pomoże. Dlatego utworzyliśmy komendę która sprawdza po kolei wszystkie IP z listy oddzielonej przecinkami, a lista ta zostaje umieszczona w parametrze address hosta, przez co jest dostępna w macro $HOSTADDRESS$.
Oczywiście tej samej metody możemy użyć wewnątrz klastra celem sprawdzenia IP fizycznych, jednak naszym zdaniem stan fizycznych IP nie powinien wpływać na stan klastra jako hosta.
W ten sposób utworzyliśmy hosta, który jest odpowiednim miejscem dla monitoringu wszelki serwisów uruchomionych na klastrze, tj. baz danych, stron www, a także GFS (Global File System) – te zasoby przecież są współdzielone między węzły klastra.
Powyższe informacje tak naprawdę możemy zastosować do dowolnego klastra, nie koniecznie opartego o systemy Red Hat. Monitoring powinien również oprzeć się o komendę
KOD: ZAZNACZ CAŁY
Code:
# clustatNiestety komenda ta wymaga uprawnień uid 0, przez co system monitoringu musi mieć odpowiedni wpis w pliku /etc/sudoers – albo dla komendy, albo dla metody np.
KOD: ZAZNACZ CAŁY
Code:
Cmnd_Alias OP5 = /opt/plugins/custom/emca/check_linux_cluster
%op5 ALL=(ALL) NOPASSWD: OP5Ta komenda daje nam informacje na temat statusu węzłów (Online, Offline, Inactive) i statusu usług (started, failed, pending, disabled, stopped). Przykładowy wynik komendy:
KOD: ZAZNACZ CAŁY
Code:
# clustat
Member Status: Quorate, Group Member
Member Name State ID
------ ---- ----- --
wezel1 Online 0x0000000000000002
wezel2 Online 0x0000000000000001
Service Name Owner (Last) State
-------- ----- ----- ------ -----
usluga1 wezel1 failed
usluga2 wezel1 startedWażne jest aby wykonywać sprawdzenie na wszystkich węzłach. W przypadku gdy któryś z węzłów nie działa w klastrze, nie ma on informacji o pozostałych węzłach i usługach.
To co nas interesuje w przypadku stanu członków to, czy wszyscy pozostają w stanie Online. Proponujemy aby informacja o stanie Offline wywoływała stan krytyczny (CRITICAL), a informacja o stanie Inactive stan ostrzegawczy (WARNING).
Podobnie w przypadku serwisów, stan porządany to wszystkie usługi w stanie started. Bez wątpienia stan failed możemy uznać za stan krytyczny, a stany pending, disabled i stopped jako stany ostrzegawcze.
