Zarządzając klastrem, musimy mu zaufać wierząc, że wspierane usługi będą mądrze podzielone pomiędzy węzły. Nie byłoby najlepiej, gdyby wszystkie grupy usług wylądowały na tym samym węźle i tam zostały, bijąc się o zasoby, podczas gdy inne węzły czekają na cokolwiek do obsłużenia. Jeżeli usługi w klastrze nie są specjalnie wymagające to nie ma wielkiej tragedii. Gorzej, gdy trafi się kilka usług, które umieszczone na jednym węźle zaczną poważnie rywalizować o zasoby. Przykładem mogą być tu poważniejsze bazy SQL albo rozbudowane maszyny wirtualne.

Jakimś rozwiązaniem jest zarządzanie dozwolonymi węzłami, preferencjami i opcją failback. Jest to cenna funkcjonalność, niemniej jednak w wielu przypadkach okazuje się niewystarczająca.

W praktyce, często okazuje się, że właściwa polityka dla zasobów klastra powinna brzmieć: "Wszystko może być wszędzie, ale TE KONKRETNE usługi – nie razem." Czasem, poza względami wydajnościowymi, wymóg taki wynika z realiów technicznych, jest to jednak rzadkość. Można podejść do tego problemu przy pomocy ustawiania dozwolonych węzłów. Ogranicza to jednak elastyczność klastra a przy tym robi się kłopotliwe, jeżeli mamy do czynienia z większą ilością takich usług.

Z pomocą przychodzą tu tytułowe AntiAffinityClassNames. Jest to jeden z wielu kruczków, które klastry chowają przed użytkownikami GUI. Gdy tylko przyzwyczaimy się do składni polecenia cluster.exe – zarządzanie AntiAffinityClassNames staje się proste.

W największym skrócie, AntiAffinityClassNames zdefiniować można właśnie jako sposób realizacji polityki "nigdy razem". Każdej grupie w klastrze można nadać dowolną ilość nazw AntiAffinity. Podczas przenoszenia grupy, klaster tak wybiera dla niej miejsce, żeby żadna nazwa nie była taka sama jak którakolwiek z nazw grup już istniejących na serwerze. Oczywiście funkcjonalność ta ma stosunkowo niewielki sens przy klastrze składającym się z dwóch węzłów. Ale klastry to czasem 32 węzły i tam już może warto nad AntiAffinityClassNames pomyśleć.

Aby ustawić AntiAffinityClassNames dla grupy o nazwie MojaGrupaKlastrowa, należy na jednym z węzłów z linii poleceń uruchomić 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 żadnego ograniczenia dla ilości takich nazw, jednak grupa nie zostanie przeniesiona na żaden węzeł, na którym już jest jakaś grupa z właściwością "abc" LUB "def". Jedną nazwę AntiAffinity może mieć wiele różnych usług i wszystkie łatwo się ze sobą godzą dopóki nie zrobi się zbyt ciasno. Ponieważ AntiAffinityClassNames nie mają charakteru bezwzględnego zakazu (ważniejsza jest jednak wysoka dostępność usług) – w skrajnej sytuacji może okazać się, że na każdym węźle istnieje już jakaś nazwa AntiAffinity zabraniająca umieszczenia grupy., Mimo zakazu, dla usługi jednak znajdzie się gdzieś miejsce. Przypadek taki będzie miał miejsce również wtedy, gdy z AntiAffinityClassNames spróbujemy skorzystać w klastrze dwuwęzłowym a następnie wyłączymy jeden z węzłów.

Na koniec jeszcze jedno przydatne polecenie służące do odczytania wartości AntiAffinityClassNames dla danej grupy: cluster.exe . group "MojaGrupaKlastrowa" /prop

A gdyby ktoś chciał koniecznie i bezwzględnie zabronić równoczesnego utrzymywania dwóch grup na jednym serwerze? Klaster zapewnia taką możliwość, ale tu już trzeba trochę poprogramować.

Autor: Grzegorz Tworek [MVP]