Wykrywanie martwych bram w systemie Windows 2008 Server

9

Niedawno wdrożyliśmy HAProxy dla stackoverflow.com. Zdecydowaliśmy się użyć TProxy do utrzymania adresu źródłowego dla klientów łączących się, aby nasze dzienniki i inne moduły IIS zależne od adresu IP klienta nie wymagały modyfikacji. Pakiety przybywają sfałszowane, jakby pochodziły z zewnętrznego internetowego adresu IP, podczas gdy w rzeczywistości pochodziły z lokalnego adresu IP 192.168.xx HAProxy w naszej sieci lokalnej.

Oba nasze serwery mają dwie karty sieciowe - jeden adres klasy routowalnej B w publicznym Internecie ze statycznym adresem IP, DNS i bramą domyślną oraz jeden prywatny adres klasy C niemożliwy do routingu skonfigurowany z bramą domyślną wskazaną na prywatny adres IP dla HAProxy. HAProxy ma dwa interfejsy - jeden publiczny i jeden prywatny i wykonuje zadanie przezroczystego routingu pakietów między interfejsami i kierowania ruchu do odpowiedniego serwera WWW.

Internetowy adapter Ethernet:

   Opis . . . . . . . . . . : karta sieciowa nr 1
   DHCP włączony. . . . . . . . . . . : Nie
   Autokonfiguracja włączona. . . . : Tak
   Adres IPv4. . . . . . . . . . . : 69.59.196.217 (Preferowane)
   Maska podsieci . . . . . . . . . . . : 255.255.255.240
   Brama domyślna . . . . . . . . . : 69.59.196.209
   Serwery DNS. . . . . . . . . . . : 208,67.222.222
                                       208,67.220.220
   NetBIOS przez Tcpip. . . . . . . . : Włączone

Adapter Ethernet Prywatny lokalny:

   Opis . . . . . . . . . . : karta sieciowa nr 2
   DHCP włączony. . . . . . . . . . . : Nie
   Autokonfiguracja włączona. . . . : Tak
   Adres IPv4. . . . . . . . . . . : 192.168.0.2 (Preferowane)
   Maska podsieci . . . . . . . . . . . : 255.255.255.0
   Brama domyślna . . . . . . . . . : 192.168.0.50
   NetBIOS przez Tcpip. . . . . . . . : Włączone

Wyłączyliśmy automatyczne pomiary na każdym z serwerów sieciowych i przypisaliśmy metodzie publicznej klasy B routowalnej metrykę 10, a nasz prywatny interfejs metrykę 20.

Ustawiliśmy także oba te klucze rejestru:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableDeadGWDetect"=dword:00000000

Mniej więcej dwa razy dziennie widzimy problemy, w których jeden z serwerów internetowych nie może skontaktować się z DNS lub nawiązać połączenia z innymi serwerami w publicznym Internecie.

Podejrzewamy, że wykrywanie martwej bramy fałszywie wykrywa awarię bramy publicznej i przełącza cały ruch na bramę prywatną, która w tym momencie nie ma dostępu do DNS, ale nie ma możliwości zweryfikowania tego.

Czy istnieje sposób, aby dowiedzieć się, czy wykrywanie martwej bramy jest uruchomione, czy nawet opcja na serwerze Windows 2008?
Jeśli tak, to czy istnieje sposób na wyłączenie wykrywania martwej bramy w serwerze Windows 2008?
Jeśli nie, czy mogą istnieć inne powody, dla których tracimy możliwość rozwiązania DNS lub nawiązania połączenia na krótki czas?

— Geoff Dalgas
źródło

1

Chociaż ta konfiguracja jest czasem niezadowolona (patrz blogs.technet.com/timmcmic/archive/2009/04/26/… ), działa ona dla nas wyjątkowo - cały ruch przychodzący z HAProxy do naszych witryn IIS wygląda na to, że nadal pochodzi z oryginalny adres IP. To oszczędza niezliczoną ilość czasu, ponieważ musielibyśmy (dowiedzieć się, jak skonfigurować) IIS i jego niezliczone wtyczki, aby używały nagłówka HTTP_X_FORWARDED_FOR.

— Jarrod Dixon

1

Dlaczego masz skonfigurowaną bramę w interfejsie 192.168.0.2? Możesz skonfigurować pustą bramę domyślną (i tak właśnie Windows prosi o zrobienie, gdy masz dwa interfejsy).

— Portman

@Portman - ponieważ nasze skrzynki internetowe widzą ruch z nienaruszonymi źródłowymi adresami IP klientów, odpowiedzi nie będą wysyłane do naszej sieci - dlatego musimy mieć domyślną bramę do naszego pola HAProxy.

— Jarrod Dixon

@Jarrod - ta konfiguracja wydaje się podejrzana. A jeśli chcesz uruchomić niezrównoważoną witrynę na tym serwerze? Odpowiedź zostanie przekierowana przez HAProxy? Jak poradzisz sobie z czymś takim jak zdalny pulpit? Zdaję sobie sprawę, że to nie dotyczy pytania, ale wydaje się, że jest to przypadek „robisz to źle”, o czym mówi (grzecznie) daivdsmalley.

— Portman

4

@ Jeff / Geoff / Jarrod - Nienawidzę mówić o oczywistości, ale wy, twórcy oprogramowania, dlaczego nie zatrudnić kogoś, kto jest specjalistą na jeden dzień do naprawy? Bardzo miło jest ubrudzić sobie ręce, ale jest tu wyraźna luka w wiedzy, niekiedy wpływa to na biznes i wyraźnie spędziłeś sporo cennego czasu, nie wykorzystując swoich podstawowych umiejętności, którymi jest rozwój. Zaufaj mi, poproś kogoś o naprawę, a następnie wybierz jego mózg po uruchomieniu. Do diabła, nawet jako webhosterzy musimy angażować ludzi, aby wypełnić te luki, gdy ma to wpływ na misję / usługi.

— Kev

5

Te DWORD wykrywania Dead Gateway są bezużyteczne w systemie Windows Server 2008. Jedynym powodem, dla którego istnieją, są względy zgodności. Sterownik TCP / IP i składniki routera Windows nie szukają już tych wartości.

Podejrzewam, że ta funkcja została wprowadzona do funkcji Auto-Tuning, która zadebiutowała w systemie Windows Vista. Spróbuj wykonać następujące czynności w wierszu polecenia z podwyższonym poziomem uprawnień (i uruchom ponownie):

netsh int tcp ustaw globalny autotuninglevel = wyłączony

Aktualizacja ( dodano 13 września 2009 r. O godz. 7:58 PST EST )

Jeśli to nie zadziała, potrzebujemy więcej danych diagnostycznych. Rozpocznij śledzenie (cykliczne) za pomocą scenariuszy NetConnection lub LAN i pozwól mu kontynuować działanie do momentu wystąpienia problemu.

Scenariusz uruchamiania śledzenia netsh = NetConnection maxSize = 512

_{(Przykład: uruchamia scenariusz śledzenia NetConnection z maksymalnym rozmiarem dziennika śledzenia 512 MB)}

Możesz otworzyć wynikowy ślad w Network Monitor 3.3 , po prostu upewnij się, że zainstalowałeś najnowsze parsery .

— Rafael Rivera
źródło

dobry pomysł, ale też nie działał ... po prostu doświadczyłem 5-minutowej przerwy w ruchu wychodzącym - co w tajemniczy sposób się naprawiło.

— Jeff Atwood

@Jeff: Hmm, potrzebujemy więcej danych Kapitanie! Zobacz edycję powyżej.

— Rafael Rivera

5

Nie byliśmy w stanie dojść do jednoznacznego wyniku, dlaczego nie mogliśmy kontrolować zachowania Dead Gateway Detection.

Zamiast spędzać mnóstwo czasu na rozwiązywaniu tego problemu, zdecydowaliśmy, aby nasza instancja HAProxy kierowała ruchem do bramy wychodzącej i ustawiła domyślną bramę obu serwerów WWW na adres IP haproxy i usunęła adres bramy wewnętrznej.

  [ soweb1 ] 69.59.196.220, GW=69.59.196.211 [haproxy]
       |
       +---- [haproxy] 69.59.196.211, GW 69.59.196.209
       |
    [ gw ] 69.59.196.209

Teraz jest tylko jedna brama domyślna, która eliminuje nasz problem, ponieważ wykrywanie martwej bramy domyślnej nie jest już używane.

— Geoff Dalgas
źródło

4

Chciałbym zapytać, dlaczego w ogóle musisz zmienić domyślną bramę na HAproxy. Zasadniczo nie powinieneś w ogóle zmieniać domyślnej bramy, chyba że wskazujesz ją na wysoce dostępną konfigurację N + 1, w której adres IP bramy może zostać przełączony na inny router / komputer w przypadku awarii. Jeśli coś stanie się z maszyną HAproxy i nie będziesz mieć dostępu poza pasmem, serwery internetowe po prostu odpadną z Internetu.

Ponieważ uważam, że powodem tego może być to, że używasz Tproxy w konfiguracji, aby adres IP klientów pojawiał się w dziennikach, a nie adres IP serwera proxy, czy mogę zasugerować, abyś to zrobił zamiast tego

Dodaj „opcję przekazywania dla ...” do konfiguracji HAproxy
Zainstaluj filtr ISAPI przekierowany na x
Usuń tproxy z konfiguracji
Zmień domyślną bramę z powrotem na tę samą bramę, z której korzystałeś wcześniej przy bezpośrednim połączeniu z Internetem

Nie mam komputera z systemem Windows, aby to przetestować, ale uważam, że powinno to przynieść pożądany efekt bez niepożądanej utraty łączności.

— davidsmalley
źródło

Dopiero zauważyłem twój komentarz do pierwotnego pytania dotyczącego tej konfiguracji. Wątpię jednak, czy „działa to dla nas niesamowicie”, jeśli wasze serwery

— tracą

3

Alternatywnie, możesz spojrzeć na znacznie bardziej niezawodne rozwiązanie, takie jak ldirectord + heartbeat, które po prostu przekierowuje ruch na poziomie jądra, ponieważ nie ma w ogóle żadnego proxy. Używam tego zestawu szeroko i działa świetnie. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html

— davidsmalley 13.09.2009

Przyjrzeliśmy się użyciu tego x-forwarded-fornagłówka i filtrów IIS do zmiany dzienników, ale nie wiemy, w jaki sposób (lub czy) nasze inne opcjonalne moduły IIS również używają nagłówka podczas ich działania.

— Jarrod Dixon

Dzięki za link linuxvirtualserver.org/HighA Availability.html - informacje tam są niesamowite! Jestem nieświadomy tych tematów (dlatego nie jestem tym, który to wszystko ustawia!), Ale staram się uczyć tak szybko, jak to możliwe. Być może możemy użyć pulsu + ldirectord podobnie jak linuxvirtualserver.org/docs/ha/ultramonkey.html z naszym ulubionym HAProxy.

— Jarrod Dixon

-1

Gdy w grę wchodzi dostęp do Internetu (zwykle), wówczas bramy domyślne powinny być NIGDY używane do oznaczenia ścieżki do INTERNETU. Jeśli zdefiniowano wiele bram domyślnych, router systemu operacyjnego nie może zdecydować, którego z nich użyć, a jeśli jedna brama domyślna wskazuje ślepą uliczkę (np. Wielosegmentową sieć LAN), wówczas pakiety przekazywane do Internetu są nie uda mi się.

— Adrien
źródło