Strona główna > Hyper-V, IT, Klastry, Windows 2008 > Ciekawostki NLB. Cz2

Ciekawostki NLB. Cz2

Zebrałem się w sobie dzisiaj będzie cześć druga. Dla przypomnienia schemacik sieci. Ostatnio udało się dojść czemu był problem z połączeniem RDP na ten węzeł na który się chciało i o co chodziło w Affinity było też troszkę o Sesson Brokerze ale to akurat z NLB co najmniej średnio jest związane. Zostały te rzeczy, o których będę musiał się więcej rozpisać. Dla przypomnienia:

scenario1

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.

Problemy *1 i *5 są załatwione w poprzedniej części. Dzisiaj reszta. A więc userzy (D,E,F) ciągle dzwonią, że nie mogą się połączyć na VIP klastra. W ogóle jeden z nich tam jest kumaty i próbuje go zapingować dostaje brak odpowiedzi. O co chodzi ? To zależy od paru rzeczy, które bezpośrednio łączą się z *3 i *4.

W przypadku gdy klaster chodzi w trybie Unicast userzy bez problemu z za routera się dostaną, czemu i co to za różnica czy unicast czy multicast? Trochę jest. W trybie unicast na dobry początek klaster potrzebuje (praktycznie) po dodatkowej sieciówce (*3) per węzeł do komunikacji między węzłowej. Czemu ? W tym trybie wszystkie węzły mają ten sam MAC adres, który nadaje im usługa NLB. Oryginalny adres MAC nie jest w ogóle używany to powoduje, że węzły nie mogą ze sobą gadać.. no bo jak.  Dodatkowa sieciówka per węzeł rozwiązuje problem. Dobrze, gdy już zdecydujemy się na unicast – tą odrębną sieć do komunikacji międzywęzłowej wrzucić sobie w osobny VLAN czy inny subnet po co sobie śmiecić w sieci hm – ‚głównej’.  Jest jeszcze coś, jakikolwiek ruch sieciowy kierowany do konkretnego węzła z jakiegoś tam powodu i tak trafi do wszystkich, w przypadku jak są 2 węzły to można z tym żyć ale jak będzie 20 to po co sobie dodatkowo zapychać sieć.  A więc muticast. Małe zestawienie poniżej zbiera różnice pomiędzy trybami pracy dla tych którym nie chce się czytać treści:

Unicast

  • Każdy węzeł klastra posługuje się tym samym adresem MAC.
  • W przypadku konfiguracji z jedną kartą sieciową nie będzie komunikacji między węzłowej.
  • Na ogół trzeba dwie sieciówki per węzeł. (NLB Manager nie działa w trybie z jedną sieciówką, tzn. nie połączy się z innymi węzłami)
  • Ruch dedykowany dla pojedynczego węzła i tak trafi do wszystkich.
  • Nie ma problemów z podsieciami.

Multicast

  • Każdy węzeł klastra ma po dwa adresy MAC jeden nadany przez NLB jeden oryginalny.
  • Nie potrzeba drugiej karty sieciowej, ale jak ktoś chce to można.
  • Ruch dedykowany dla pojedynczego węzła trafi tylko do tego węzła (o ile posługujemy się adresem IP węzła a nie VIP i o ile w Port Rules nie mamy zdefiniowane, że chcemy balansować ruch na wszystkich portach.
  • Problemy z podsieciami.

Wspólną czynnością, którą prawdopodobnie trzeba będzie wykonać w przypadku W2K8 będzie włączenie IPForwardingu, który domyślnie jest wyłączony, a w przypadku NLB się przyda, bo umożliwia systemowi wysłanie odpowiedzi na zapytanie z siecówki A przez sieciówke B (w dużym uproszczeniu i dotyczy tylko przypadku, w którym z jakiegoś powodu chcemy mieć po dwie sieciówki.) Włączyć to można dwojako albo w rejestrze albo przez netsh (pierwsze wymaga restartu drugie nie)

1.       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
wartość: IPEnableRouter zmieniamy na 1

2.       netsh interface ipv4 set int „[nazwa polaczenia sieciowego]” forwarding=enabled

Jak dla mnie najlepszy jest  multicast z pojedynczą siecówką per węzeł,  mało skomplikowany i prosty w implementacji, jedyny problem jaki generuje to dostępnośc klastra z innych podsieci ale to można łatwo naprawić. Wystarczy statyczny wpis ARP na routerze który wskaże VIP klastra i MAC klastra i wszystko działa. Załóżmy, bo nie zrobiłem na schemacie, że MAC klastra (który można sobie sprawdzić NLB Managerze) to 00-00-00-11-11-11 dodajemy więc wpis:

arp -s 1.0.0.3 00-00-00-11-11-11

i userzy D,E,F przestają marudzić. To by chyba było wszystko, jasne jest już jaka jest różnica pomiędzy Unicastem a Multicastem, kiedy dwie sieciówki a kiedy jedna per węzeł no i czemu czasem klastra nie widać z innej podsieci.  Jeszcze kwestia Hyper-V, NLB pod Hyper-V chodzi tak samo dobrze jak na fizycznych serwerach. Rzecz jasna trzymanie paru wirtualnych węzłów na tym samym serwerze fizycznym ma średni sens i dobrze jest je porozbijać na różne. Za to jak łatwo dołożyć sobie węzeł gdy obecne rozwiązanie się nie wyrabia. Kopia VHD, potem tylko zmienić parę rzeczy typu nazwa, rejoin do domeny, może GUID nie zaszkodzi też i kolejny węzeł śmiga. Warto jeszcze porobić sobie dedykowane połączenia sieciowe do węzłów, tzn niekoniecznie mieć 5 różnych VMow robiących różne rzeczy zbindowanych do tego samego fizycznego połączenia sieciowego. To tyle..wszelkie komentarze, mile widziane :)

Reklamy
  1. orzepka
    9 Listopad, 2011 o 7:35 pm

    Dzięki stary. To było bardzo dobre.

  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: