Strona główna > IT, Windows 2008 > Session Broker Cz2 – DNS RR

Session Broker Cz2 – DNS RR

W końcu się zebrałem. Dziś o tym o czym miało być w zeszłym miesiącu ;)  2 serwery terminali w farmie, Session Broker, i DNS Round Robin.

Zanim przejdę dalej, mały skrót co to jest DNS Round Robin i jak to działa.DNS RR to takie dziwne rozwiązanie pseudo load balancingu i pseudo odporności na awarie. Na serwerze DNSu, pod który podlegają nasze stacje klienckie konfiguruje się to bardzo prosto. Przy założeniach ze mamy 2 serwery terminali T1 = 10.0.0.1 i T2 = 10.0.0.2 oba maja w DNSie rekordy typu A. Fajnie tego nie ruszamy, przyda się jak kiedyś trzeba będzie się połączyć do każdego serwera z osobna po coś. Tworzymy 2 nowe rekordy o tej samej nazwie.

Terminal IN A 10.0.0.1
Terminal IN A 10.0.0.2

W zasadzie to tyle, jak kogoś interesują szczegóły i dodatkowe opcje odsyłam tu Działa to na zasadzie pętli. User X pyta DNS co to jest terminal. DNS odpowiada ze to jest 10.0.0.1. User Y pyta co to jest Terminal DNS odpowie mu ze to będzie 10.0.0.2. Jak user Y zapyta drugi raz dostanie odpowiedz ze to jest 10.0.0.1. DNS nie rozróżnia użytkowników rozróżnia zapytania. 1 zapytanie – odpowiedz A drugie zapytanie odpowiedź B trzecie zapytanie odpowiedz A i tak w kolko. Raz zapytany adres wędruje na koniec kolejki.

Teraz do rzeczy – dwa scenariusze: SB na jednym z serwerów terminali i SB zainstalowane gdzieś indziej.

Farma terminali skonfigurowana z poprzedniej części. DNS RR skonfigurowany.

Scenariusz pierwszy a wiec SB na jednym z serwerów terminali. DNS RR odpowiada tu tylko za inicjalizacje połączenia z jednym z serwerów dopiero po nawiązaniu połączenia SB (który w odróżnieniu od DNSu już rozróżnia kto to się łączy) sprawdza czy aby nie ma gdzieś istniejącej sesji danego usera, jak jest to przyłączy jak nie ma to stworzy nowa tam gdzie tych sesji będzie mniej. Dopóki wszystko działa, wszystko działa.

Teraz załóżmy, ze pada jeden z serwerów – T1(10.0.0.1). Userzy –  Ci co pracowali na działającym pracuj dalej Ci, których wywaliło już nie, prawdopodobnie większość (przynajmniej w UK) od razu zacznie dzwonić i się żalić (tego uniknąć się nie da przy żadnym rozwiązaniu bo jak serwer pada to pada – sesje przepadają)  Powiemy im wiec, spróbujcie się połączyć jeszcze raz, Ci co bardziej kumaci będą to robić bez dzwonienia.  I teraz… DNS bladego pojęcia nie ma czy serwer żyje czy nie. A user pyta, co to jest Terminal, DNS odpowiada Terminal = 10.0.0.1, user próbuje się połączyć a  T1 leży- timeout, pamiętajmy ze takich userow jest 20. Teoretycznie możne się zdarzyć, ze user po timeoucie zapyta drugi raz i znów trafi na odpowiedz T1. Wtedy się zirytuje i zadzwoni jak nic. Praktycznie w miarę szybko im więcej userow się połączy tym szybciej ci co nie mogą tez się połączą i problem się rozwiąże –  ale TYLKO jeśli SB był zainstalowany na padniętym T1.  Jak jest na T2 to cały czas działa, do tego nikt nie usunął mu z farmy niedostępnego T1 to userzy będą dostawiać takie coś:

s2(obrazek może nie koniecznie ma poprawne nazwy serwerów ale treść będzie ta sama)

I będą dostawać tego dużo bo SB wie ile ma sesji na T2 zdaje mu się, ze wie ile ma na T1 a nie wie, ze T1 nie ma ;)  Usuniecie T1 z farmy rozwiąże problem. Można tez wyłączyć opcje, która nie dopuszcza do dublowania sesji, ale wtedy jak wszystko będzie działać dobrze a będą jakieś małe problemy z połączeniem to sesje będą eis dublować, zaczną się problemy z profilami userow i inne tego typu pierdoły. To wszystko tez chwile zajmuje i trzeba to wiedzieć. A user po błędzie wyżej może już być podirytowany. Downtime będzie zależny od ilości userow i czasu w jakim admin się kapnie. W sytuacji kiedy SB był na T1 downtime skróci się znacznie, bo user będzie zależny tylko od odpowiedzi DNSu a to już idzie znacznie szybciej. W przypadku gdy SB będzie poza farma na start trzeba pamiętać ze jak coś padnie trzeba osunąć to z farmy SB. Jak można się przed tym zabezpieczyć ? Szukając ładnego rozwiązania – nie można.

A co jeśli mamy więcej niż 2 serwery ? Wtedy trzeba pamiętać o tym by serwer, który leży wywalić z farmy SB. DNS RR będzie działał co ciekawe lepiej niż w przypadku dwóch serwerów z punktu widzenia usera, bo zwiększy się szansa ze do czegoś się połączy jak padł tylko 1 z 5 serwerów.

Słowem podsumowania, jak z jakiegoś powodu koniecznie chcemy wdrożyć rozwiązanie SB + DNS RR na 2 serwerach to bym sugerował instalacje SB na jednym z nich, a nóż jak padnie to będzie ten z SB i problemów będzie mniej. Inaczej zawsze trzeba pamiętać o wywaleniu padniętego serwera z farmy SB. Co do samego DNS RR to ja bym tego po prostu przy konfiguracji terminali nie robił w ogóle natomiast  MS rzecze, ze DNS RR można ale ostatecznie do farmy max 5 serwerów.

W następnej części będzie o SB + NLB które jest dużo lepsze od tego rozwiązania ale i tak nie idealne.

Reklamy
  1. pyrotechnik
    28 Wrzesień, 2009 o 9:33 am

    Witam
    Nie mogę znaleźć nic na temat możliwości wpięcia w2k8 do istniejącej farmy z 3 maszynami na w2k3 i klastrem NLB. NLB jest dla tych 3 serwerów terminali i działa tylko na porcie 3389. Session Directory jest na niezależnym czwartym w2k3. W2k8 mogę podpiąć do NLB, ale jak ustawić Session Directory na nim? TS Session Brocker to raczej coś innego. Może uruchomić Session Brockera na jakieś maszynie W2k8 i dodać do grupy hosty z W2k3 i W2k8, ale czy to będzie działać?

  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: