Ciekawostki NLB. Cz1

Multicast czy Unicast ?  Jedna sieciówka per węzeł czy dwie ? Dzisiaj będzie o NLB (Network Load Balancing) Podstawowa funkcjonalność, różnice pomiędzy NLB w W2k3 i W2k8. W jakich zastosowaniach jaką wybrać opcje i dlaczego. Jak sprawuje się NLB na serwerach zwirtualizowanych pod Hyper-V.

Funkcjonalność NLB (Network Load Balancing) miał już Windows 2000 Adv Server, Nie wiem jak było z NT bo wtedy to chodziłem jeszcze do podstawówki chyba. W w2k3 NLB zagościło od wersji Standard w górę. W w2k8 MS zostawił tak samo jak było w w2k3. Ten pierwszy wymieniony system, a więc w2k sobie odpuścimy bo już stary i w ogóle, aczkolwiek konsola zarządzania NLB od czasów w2k wygląda identycznie nawet ikonek nie upiększyli w w2k8, pozmieniali za to trochę w środku ale o tym później.

Ogólnie rzecz biorąc NLB przydaje się wtedy kiedy chcemy albo potrzebujemy rozładować sobie ruch przychodzący do jakieś usług/aplikacji albo kiedy zajdzie potrzeba zrównoważenia obciążenia na serwerach hostujacych jakąś usługę/aplikacje albo kiedy potrzebujemy trochę więcej odporności na awarie (jeden serwer pada, 3 inne przejmują na siebie cały ruch zapewniając dostęp do usługi)  a najczęściej wszystko na raz. Jak pomyśleć do czego NLB może się przydać to przychodzą mi do głowy 4 scenariusze. Zapewne jest ich więcej ale te 4 chyba są najczęściej wykorzystywane w środowisku MS.

1. WWW (IIS) – równoważenie obciążenia farmy serwerów hostujacych jakieś tam WWW przy okazji zapewniając ciągłość dostępu.
2. Terminale – równoważenie obciążenia dostępu do serwerów Terminali
3. ISA – równoważenie obciążenia ruchu przychodzącego i wychodzącego do sieci przy okazji zapewniając ciągłość dostępu.
4. Aplikacje – równoważenie obciążenia dostępu do aplikacji (nie przychodzi mi na myśl żadna aplikacja na ten moment)

Zagłębimy się w to NLB na przykładzie serwerów terminali, kiedyś też postaram się napisać coś o ISA a mam nadzieje ze już TMG. Z IISem za dużo nie pracuje więc gdzieś w necie na bank będą lepsze wywody od moich to samo w kwestii aplikacji, zwłaszcza, że mi żadna do głowy nie przychodzi. Przydałby się jakiś scenariusz – może taki:

Jak widać mamy do czynienia z 2 węzłowym klastrem NLB (N1 N2) chodzącym na w2k8, zwirtualizowanym pod Hyper-V rozbitym na 2 fizyczne serwery Hyper-V. Oba serwery w jednej podsieci, każdy robi za serwer terminali. Session Broker zainstalowany na N1 (*1). Gdzieś po drodze jakiś router  (*2) do innej podsieci gdzie siedzi grupka userów (D,E,F), która też chce korzystać z dobrodziejstw NLB. Każdy z węzłów ma po jednej sieciówce (*3) Klaster chodzi w trybie multicast (*4). Affinity ustawione na single (*5).  Wszystko to śmiga w domenie. Każdy z przypadków/potencjalnych problemów zaznaczony jest (*cyfra) i każdy opisze osobno i chyba w kilku częściach bo wątpię żeby mi się chciało napisać wszystko dzisiaj.

Scenariusz już jest i nawet działa a przynajmniej tak się wydaje na początku. Pierwszy dzień po wdrożeniu i już tel. Ludzie z za routera nie mogą się połączyć na IP (VIP) klastra(*2). Userzy z tej samej sieci co klaster łączyć się mogą bez problemów więc jednak działa co jest ?  Kurwa tyle kasy poszło na ten sprzęt, licencje i już problemy. Szybkie RDP na jeden z serwerów  żeby zobaczyć co jest grane.. wyskakuje takie okienko

Coś nie idzie.. Jeszcze jedna próba udało się..(*1).  Godzinę później okazuje się, że znów coś nie tak. Jeden z serwerów się nudzi drugi jest poważnie obciążony(*5). RDP na serwer czasem działa czasem wyskoczy błąd taki jak wyżej. No zawsze pozostaje konsola Hyper-V managera. Wskakujemy na  ten obciążony… (N1)  pełno sesji. Ten który się nudzi nie ma żadnej. Dodam, że N1 siedzi na HV1 który też jest bardziej obciążony od HV2 – kto to planował i wdrażał ;) Co jest grane ?

*1. Przy próbie połączenia z każdym z węzłów z osobna może się zdarzyć a właściwie zdarzy się, że Session Broker będzie chciał przerzucić sesje na drugi serwer i otrzymamy taką właśnie informacje jak na rysunku powyżej. Zachowanie to jest normalne, w końcu po to jest Session Broker, żeby(w dużym uproszczeniu) rozrzucać sesje pomiędzy serwery w farmie jednocześnie pamiętając gdzie jaka jest i jaki ma stan (Active/Disconnected)  Umiejscowienie SB na jednym z węzłów (N1) w tym przypadku nie ma znaczenia, sposobem na rozwiązanie tego problemu jest, korzystanie z przełącznika /admin (dawniej /console) przy nawiązywaniu połączenia RDP z wybranym węzłem. Inna sprawa, że ktoś by mógł powiedzieć: Bez sensu, że ten Session Broker jest na jednym z węzłów co będzie jak akurat ten serwer się wywali?  Ano w tym przypadku nic nie będzie. Wszystko będzie działać jak powinno, userzy i tak łącza się na VIP klastra a NLB w odróżnieniu od SB wie, który serwer działa a który nie, i przekieruje połączenie na serwer N2. Więcej o Session Brokerze i scenariuszach w ten deseń będzie jak skończę z NLB.

*5 Affinity ustawione na single.

Afinity mamy ustawione na Single bo tak radzi MS, pechowo w przypadku NLB + Session Broker ta rada się średnio sprawdza. Czemu, ano dlatego, że opcja Single powoduje, że wiele połączeń na adres VIP klastra z tego samego adresu IP klienta wpadają zawsze na ten sam węzeł.  Ma to sens jak zamiast terminali będzie tam IIS albo jak klient się proxuje ale w przypadku terminali, gdzie klient nawiązuje tylko jedno połączenie TCP3389 będzie to przeszkadzać zwłaszcza jak grupa klientów łączy się z tego samego adresu IP (z punktu widzenia klastra np: jest za NAT-em gdzies w oddziale)  To może wybierzemy ustawienie Class C ? Też nie bardzo Class C to tak naprawdę jakby rozszerzenie Single, powoduje to, że klienci łączący się z tej samej puli adresów z klasy C trafią na ten sam węzeł. Też do niczego ta opcja się nie przyda.  Zostaje opcja: None – na dobry początek zaznaczę, że opcja ‚None’ nadaje się tylko do TCP, nie obsługuje UDP tzn obsługuje ale nie poradzi sobie z fragmentami IP, tak samo nie będzie to działało jak trzeba jak ruch, który chcemy równoważyć wpada i po TCP i po UDP. Na szczęście RDP to tylko TCP3389 wiec luz. Affinity ustawione na  ‚None’ powoduje to, że połączenia TCP wpadające na adres VIP z tego samego IP klienta, będą równoważone przez różne węzły. W ogóle połączenia skądkolwiek i kogokolwiek na VIP będą równoważone przez różne węzły. Ktoś pomyśli bez sensu, w przypadku serwera terminali będą się zestawiały sesje na różne serwery – nie będą bo mamy Session Brokera, który tego pilnuje. Opcja ‚None’ wydaje się więc dla terminal z SB najlepsza. Klikamy None dajemy Ok i po chwili widać już, że sesje zaczynają się powoli rozkładać na oba serwery w miarę równoważnie. Lux.

Na tym etapie mamy rozwiązane 2 problemy z scenariusza u góry. *1 Wiemy co zrobić żeby połączyć się po RDP z tym serwerem z którym chcemy pomijając SB i *2 co robi która opcja w Affinity, i dlaczego musi być None aby obciążenie równoważyło się.. równo ;-)

Problemy  *2 *3 *4  w następnej części jako że, są ze sobą połączone i wymagają dużo pisania :)