AntiAffinityClassNames


Zarzadzajac klastrem, musimy mu zaufac wierzac, ze wspierane uslugi beda madrze podzielone pomiedzy wezly. Nie byloby najlepiej, gdyby wszystkie grupy uslug wyladowaly na tym samym wezle i tam zostaly, bijac sie o zasoby, podczas gdy inne wezly czekaja na cokolwiek do obsluzenia. Jezeli uslugi w klastrze nie sa specjalnie wymagajace to nie ma wielkiej tragedii. Gorzej, gdy trafi sie kilka uslug, które umieszczone na jednym wezle zaczna powaznie rywalizowac o zasoby. Przykladem moga byc tu powazniejsze bazy SQL albo rozbudowane maszyny wirtualne.

Jakims rozwiazaniem jest zarzadzanie dozwolonymi wezlami, preferencjami i opcja failback. Jest to cenna funkcjonalnosc, niemniej jednak w wielu przypadkach okazuje sie niewystarczajaca.

W praktyce, czesto okazuje sie, ze wlasciwa polityka dla zasobów klastra powinna brzmiec: "Wszystko moze byc wszedzie, ale TE KONKRETNE uslugi – nie razem." Czasem, poza wzgledami wydajnosciowymi, wymóg taki wynika z realiów technicznych, jest to jednak rzadkosc. Mozna podejsc do tego problemu przy pomocy ustawiania dozwolonych wezlów. Ogranicza to jednak elastycznosc klastra a przy tym robi sie klopotliwe, jezeli mamy do czynienia z wieksza iloscia takich uslug.

Z pomoca przychodza tu tytulowe AntiAffinityClassNames. Jest to jeden z wielu kruczków, które klastry chowaja przed uzytkownikami GUI. Gdy tylko przyzwyczaimy sie do skladni polecenia cluster.exe – zarzadzanie AntiAffinityClassNames staje sie proste.

W najwiekszym skrócie, AntiAffinityClassNames zdefiniowac mozna wlasnie jako sposób realizacji polityki "nigdy razem". Kazdej grupie w klastrze mozna nadac dowolna ilosc nazw AntiAffinity. Podczas przenoszenia grupy, klaster tak wybiera dla niej miejsce, zeby zadna nazwa nie byla taka sama jak którakolwiek z nazw grup juz istniejacych na serwerze. Oczywiscie funkcjonalnosc ta ma stosunkowo niewielki sens przy klastrze skladajacym sie z dwóch wezlów. Ale klastry to czasem 32 wezly i tam juz moze warto nad AntiAffinityClassNames pomyslec.

Aby ustawic AntiAffinityClassNames dla grupy o nazwie MojaGrupaKlastrowa, nalezy na jednym z wezlów z linii polecen uruchomic program cluster.exe z odpowiednimi parametrami: cluster.exe . group "MojaGrupaKlastrowa" /prop AntiAffinityClassNames="abc" "def"

W tym konkretnym przypadku, grupa otrzymuje dwie nazwy AntiAffinity: abc oraz def. Nie ma zadnego ograniczenia dla ilosci takich nazw, jednak grupa nie zostanie przeniesiona na zaden wezel, na którym juz jest jakas grupa z wlasciwoscia "abc" LUB "def". Jedna nazwe AntiAffinity moze miec wiele róznych uslug i wszystkie latwo sie ze soba godza dopóki nie zrobi sie zbyt ciasno. Poniewaz AntiAffinityClassNames nie maja charakteru bezwzglednego zakazu (wazniejsza jest jednak wysoka dostepnosc uslug) – w skrajnej sytuacji moze okazac sie, ze na kazdym wezle istnieje juz jakas nazwa AntiAffinity zabraniajaca umieszczenia grupy., Mimo zakazu, dla uslugi jednak znajdzie sie gdzies miejsce. Przypadek taki bedzie mial miejsce równiez wtedy, gdy z AntiAffinityClassNames spróbujemy skorzystac w klastrze dwuwezlowym a nastepnie wylaczymy jeden z wezlów.

Na koniec jeszcze jedno przydatne polecenie sluzace do odczytania wartosci AntiAffinityClassNames dla danej grupy: cluster.exe . group "MojaGrupaKlastrowa" /prop

A gdyby ktos chcial koniecznie i bezwzglednie zabronic równoczesnego utrzymywania dwóch grup na jednym serwerze? Klaster zapewnia taka mozliwosc, ale tu juz trzeba troche poprogramowac.

Autor: Grzegorz Tworek [MVP]

Comments (2)

  1. KoprowskiT says:

    Interesująca właściwość. Podejrzewam, że całe grono kolegów z branży nie uzywało albo i nie znało (jak ja). Trzeba się będzie przyjrzeć w wolnej chwili…

  2. Radek_Kepa says:

    Fakt ciekawa wlasciwosc. Good to know. Niestety takich ukrytych wlasciwosci dla GUI jest całaaaaaaaaaa masa.

Skip to main content