Session Broker – Cz1

Coś coraz mniej chyba pisze, albo i coraz rzadziej. To wynika chyba z tego, że mi się nie chce albo, że mnie meczą w robocie coraz to głupszymi pytaniami. (to chyba będzie to drugie)  Wybitnie mnie meczą powiem, co ciekawe śmieją się z Jankesów jacy ci ludzie w tej Ameryce głupi itp. Nie bylem nigdy w US, ale jak Angole się z nich śmieją a sami nie są lepsi no to.. kiepsko. Tyle słowem wstępu. Dzisiaj o Session Brokerze, zobaczymy jak wyjdzie. Jak by się ktoś pytał to ja się nigdy nie bawię w pisanie sprawdzanie i przygotowywanie czy cacy. Pisze klikam publikuj i jest, dobra poprawiam błędy. Wychodzę z założenia ze jak pisze bzdury ktoś mi to napisze w komentarzu. Zaczynamy.

Session Broker to takie coś co się bardzo przydaje przy serwerach terminalowych, dokładniej to przy więcej niż jednym.  Taka lepsza wersja Session Directory z Windows 2003, której w sumie głównym zadaniem było pilnowanie żeby user nie miał zalogowanej albo rozłączonej sesji na 10 serwerach w klastrze tylko, żeby cały czas zapinał się do tej samej sesji i nie mógł sesji dublować. Session Broker to w zasadzie to samo tylko z bajerami, w książce bajery brzmiały świetnie w praktyce wychodzi to trochę inaczej ale i tak dobrze. Z bajerów można by wymienić:

- Coś w deseń NLB tylko nie do końca, ot SB rozrzuca sesje userow.. równo pomiędzy wszystkie serwery w farmie.
- Definiowanie sobie wagi danego serwera, jak np nie ma kasy żeby mieć 5 wypasionych serwerów i dwa z nich są stare ale jare, dajemy im mniejsza wagę i gra.
- Server Drain (Drain-Mode) nie związane bezpośrednio z SB, ale SB ma wpływ na te funkcje. W teorii ma to zapobiegać nowym logowaniom na serwe, np jak chcemy zrobić reset czy bo ramu brakło.

Session Broker jest w sumie niekonfigurowalny ot feature który się instaluje gdzie się chce. (dotyczy oczywiście tylko W2k8), najlepiej żeby serwer na którym to instalujemy był w domenie ale nie musi też będzie działać. Tak naprawdę, to cala konfiguracja wokół SB rozgrywa się na każdym z serwerów terminali albo w GPO, jak kto woli. Wybitnie istota jest tez reszta rzeczy pozornie z SB nie związana o czym później.  Od strony serwera terminali wygląda to tak, że wklikujemy się w Terminal Services Configuration, tam rzuci nam się w oczy hmm, akapit?  TS Session Broker a pod nim ‘Member of farm in TS Session Broker’ po polsku pewnie coś w klimat, ‘członek farmy session brokera’ Klik i mamy okienko o takie:

Po kolei od góry, członkostwo serwera w farmie. po angielsku cały zwrot brzmi zaawansowanie co najmniej jakby tych serwerów miało być 500 (ciekawe czy gdzieś tyle jest w jednej farmie) , albo kojarzy się z farma krów czy tez modnych ostano świń ;)  Farma to nic innego jak  parę serwerów terminali zgrupowanych razem. Nazwa farmy to chyba wiadomo, dla wszystkich musi być ta sama bo nie zadziała. Niżej checkbox od SBLB – czyli wbudowanego w mechanizm Session Brokera Load Balancingu – to mega banalny load balacing polegający tylko i wyłącznie na rozrzucaniu sesji po równo per serwer. Jak widać można ustawić sobie wagę danego serwera, ma to sens jak mamy jeden wypasiony serwer a jeden ‘stary ale jary’ wtedy dajemy sobie np 70 na nowym i 30 na starym i wszyscy się cieszą, stary serwer jest wykorzystany.

Dalej jest checkbox od ponownych połączeń do rozłączonych wcześniej z jakiegoś powodu (ręcznie, przez awarie sieci, wanu/vpna) I teraz mało kto pewnie będzie miał kasę na sprzętowy load balancer, który obsługuje tokeny SB. W ogóle o tym nie będę pisał z prostego powodu -  nic o tym nie wiem. W każdym innym przypadku to pole musi byc zaznaczone. Niżnej wybieramy IP, który ma być wykorzystany do recconnecta. Na logikę dobrze jest wybrać IP sieciowi, która przyjmuje połączenia RDP. W przypadku konfiguracji z NLB nie wybieramy IP klastra (VIP) a IP węzła, bo możne się zdarzyć, ze NLB będzie chciało usilnie przerzucić próbę recconecta sesji na drugi węzeł który i tak połączenia odmówi.  W następnych częściach rzucimy okiem na 2 rozwiązania.

1. Opisywane przez innych blogerów, ale jakoś pominęli kilka istotnych i upierdliwych szczegółów co czyni to rozwianie kiepskim ale tanim -  DNS Round Robin jako pseudo LoadBalancing + SBNLB  i przynajmniej 2 serwery terminali.
2 – Całkiem fajne ale i trochę droższe w rożnych scenariuszach: NLB + SB, NLB + SBNLB, Session Broker na jednym z serwerów w farmie i poza farma.

Mam nadzieje, aczkolwiek głównie zależy to od chęci ze uda mi się to napisać w tym miesiącu jeszcze, przynajmniej któryś z punktów, bo jak widać ostatnio nieźle sobie pogrywam i częstotliwość wpisów spada – muszę się poprawić.