Wersja TL; DR: Okazuje się, że był to głęboki błąd sieci Broadcom w Windows Server 2008 R2. Zastąpienie sprzętem Intel naprawiło to. Nie używamy już sprzętu Broadcom. Zawsze.
Używamy HAProxy wraz z pulsu z projektu Linux-HA. Używamy dwóch instancji Linuksa, aby zapewnić przełączenie awaryjne. Każdy serwer ma własny publiczny adres IP i pojedynczy adres IP, który jest dzielony między nimi za pomocą interfejsu wirtualnego (eth1: 1) pod adresem IP: 69.59.196.211
Interfejs wirtualny (eth1: 1) IP 69.59.196.211 jest skonfigurowany jako brama dla serwerów Windows za nimi i używamy ip_forwarding do kierowania ruchem.
Od czasu do czasu mamy do czynienia z awarią sieci na jednym z naszych serwerów Windows za bramami Linuksa. HAProxy wykryje, że serwer jest w trybie offline, co możemy zweryfikować, przesyłając go na uszkodzony serwer i próbując wysłać polecenie ping do bramy
Pinging 69.59.196.211 z 32 bajtami danych: Odpowiedź od 69.59.196.220: Host docelowy jest nieosiągalny.
Uruchomienie arp -ana tym uszkodzonym serwerze pokazuje, że nie ma wpisu adresu bramy (69.59.196.211):
Interfejs: 69.59.196.220 --- 0xa Typ adresu fizycznego adresu internetowego 69.59.196.161 00-26-88-63-c7-80 dynamiczny 69.59.196.210 00-15-5d-0a-3e-0e dynamiczny 69.59.196.212 00-21-5e-4d-45-c9 dynamic 69.59.196.213 00-15-5d-00-b2-0d dynamiczny 69.59.196.215 00-21-5e-4d-61-1a dynamiczny 69.59.196.217 00-21-5e-4d-2c-e8 dynamiczny 69.59.196.219 00-21-5e-4d-38-e5 dynamiczny 69.59.196.221 00-15-5d-00-b2-0d dynamiczny 69.59.196.222 00-15-5d-0a-3e-09 dynamiczny 69.59.196.223 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 statyczny 224.0.0.252 01-00-5e-00-00-fc statyczny 225.0.0.1 01-00-5e-00-00-01 statyczny
Na naszych instancjach bramy linux arp -apokazuje:
peak-colo-196-220.peak.org (69.59.196.220) w <incomplete> na eth1 stackoverflow.com (69.59.196.212) o 00: 21: 5e: 4d: 45: c9 [eter] na eth1 peak-colo-196-215.peak.org (69.59.196.215) o 00: 21: 5e: 4d: 61: 1a [eter] na eth1 peak-colo-196-219.peak.org (69.59.196.219) o 00: 21: 5e: 4d: 38: e5 [eter] na eth1 peak-colo-196-222.peak.org (69.59.196.222) o 00: 15: 5d: 0a: 3e: 09 [eter] na eth1 peak-colo-196-209.peak.org (69.59.196.209) o 00: 26: 88: 63: c7: 80 [eter] na eth1 peak-colo-196-217.peak.org (69.59.196.217) o 00: 21: 5e: 4d: 2c: e8 [eter] na eth1
Dlaczego arp czasami ustawia wpis dla tego serwera, który uległ awarii, jako <kompletny>? Czy powinniśmy definiować nasze wpisy arp statycznie? Zawsze zostawiałem arp w spokoju, ponieważ działa 99% czasu, ale w tym jednym przypadku wydaje się, że zawodzi. Czy są jakieś dodatkowe kroki rozwiązywania problemów, które możemy podjąć, aby rozwiązać ten problem?
Rzeczy, które próbowaliśmy
Dodałem statyczny wpis arp do testowania na jednej z bram Linuksa, co wciąż nie pomogło.
root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1
root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms
Ponowne uruchomienie serwera systemu Windows tymczasowo rozwiązuje ten problem bez żadnych innych zmian w sieci, ale z naszego doświadczenia wynika, że problem ten powróci.
Zamiana kart sieciowych i przełączników
Zauważyłem, że lampka łącza na porcie przełącznika dla uszkodzonego serwera Windows działała z prędkością 100 Mb zamiast 1 Gb na uszkodzonym interfejsie. Przeniosłem kabel do kilku innych otwartych portów, a łącze wskazało 100 Mb dla każdego portu, którego próbowałem. Zamieniłem też kabel z tym samym rezultatem. Próbowałem zmienić właściwości karty sieciowej w systemie Windows, a serwer został zamknięty i wymagałem twardego resetu po kliknięciu przycisku Zastosuj. Ten serwer Windows ma dwa fizyczne interfejsy sieciowe, więc zamieniłem kable i ustawienia sieciowe na dwóch interfejsach, aby sprawdzić, czy problem występuje po interfejsie. Jeśli interfejs publiczny ponownie się zawiesi, będziemy wiedzieć, że nie jest to problem z kartą sieciową.
(Wypróbowaliśmy też inny przełącznik, który mamy pod ręką, bez zmian)
Zmiana wersji sterowników sprzętu sieciowego
Mamy ten sam problem z najnowszym sterownikiem Broadcom, a także z wbudowanym sterownikiem, który jest dostarczany z systemem Windows Server 2008 R2.
Wymiana kabli sieciowych
Jako ostatni wysiłek przywołaliśmy kolejną zmianę, która nastąpiła, to wymiana wszystkich kabli połączeniowych między naszymi serwerami / przełącznikami. Kupiliśmy dwa zestawy, jeden zielony o długości 1 stopy - 3 stopy dla interfejsów prywatnych i drugi zestaw czerwonych kabli dla interfejsów publicznych. Wymieniliśmy wszystkie kable z interfejsem publicznym innej marki i przez cały tydzień bez problemu prowadziliśmy nasze serwery ... aaaaaa, a potem problem się powtórzył.
Wyłącz odciążanie sumy kontrolnej, usuń TProxy
Próbowaliśmy również wyłączyć odciążanie sumy kontrolnej TCP / IP w sterowniku, bez zmian. Wyciągamy teraz TProxy i przechodzimy do bardziej tradycyjnego x-forwarded-forukładu sieci bez żadnego fantazyjnego przepisywania adresu IP. Zobaczymy, czy to pomoże.
Przełącz dostawców wirtualizacji
Przy okazji było to w jakiś sposób związane z Hyper-V (obsługujemy na nim maszyny wirtualne z systemem Linux), przeszliśmy na serwer VMWare. Brak zmiany.
Zmień model hosta
Dotarliśmy do końca naszej liny do rozwiązywania problemów i teraz formalnie angażujemy wsparcie Microsoft. Zalecili zmianę modelu hosta:
- http://en.wikipedia.org/wiki/Host_model
- http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Zrobiliśmy to, a także otrzymaliśmy kilka niepublikowanych poprawek jądra, które prawdopodobnie zostały wprowadzone do wersji R2 z dodatkiem SP1 2008. Bez naprawy.
Wymiana sprzętu karty sieciowej
Ostatecznie zastąpienie sprzętu sieciowego Broadcom sprzętem sieciowym Intel rozwiązało ten problem. Dlatego jestem skłonny myśleć, że to wina sterowników Broadcom Windows Server 2008 R2!
źródło
Odpowiedzi:
Od http://linux-ip.net/html/ether-arp.html :
Wygląda na to, że twoje pole bramy nie odpowiada (lub odpowiada zbyt wolno) na żądania ARP z twojego pola bramy. Czy to
<incomplete>ostatecznie się zmienia<failed>? Jaki masz sprzęt sieciowy między serwerem a bramą? Czy jest możliwe, że rozsyłane żądania ARP są filtrowane lub blokowane gdzieś między dwoma hostami?źródło
Oznacza to, że wysłałeś polecenie ping do adresu, adres IP ma rekord PTR (stąd nazwa), ale nic nie odpowiedziała na danym komputerze. Kiedy to widzimy, najczęściej dzieje się tak z powodu nieprawidłowego ustawienia maski podsieci lub w przypadku adresów IP powiązanych z interfejsem pętli zwrotnej, które przypadkowo zostały powiązane z interfejsem eth.
Co to jest 196,220? Jaki jest związek z 196.211? Zakładam, że .220 jest jednym z hostów serwera proxy HA. Kiedy uruchomisz na nim ifconfig -a & arp -a, co to pokazuje?
źródło
Jak mówi Max Clark, <komplet> oznacza po prostu, że 69.59.196.211 wysłało żądanie ARP dla 69.59.196.220 i jeszcze nie otrzymało odpowiedzi. (W Windows-land zobaczysz to jako mapowanie ARP na „00-00-00-00-00-00” ... BTW wydaje mi się dziwne, że nie widzisz takiego mapowania ARP na 69.59.196.220 dla 69.59.196.211.)
Nie lubię używać statycznych wpisów ARP, ponieważ z mojego doświadczenia wynika, że ARP generalnie wykonuje swoją pracę przez cały czas.
Gdybym to był ja, wąchałbym odpowiedni interfejs Ethernet na „niedziałającym” komputerze z systemem Windows (69.59.196.220), aby obserwować ARP dla 69.59.196.211 i obserwować, jak / jeśli odpowiada na żądania ARP z 69.59. 196,211. Zastanowiłbym się również nad sniffowaniem na maszynie bramy tylko dla ARP (
tcpdump -i interface-name arp), aby zobaczyć, jak wygląda ruch ARP z boku maszyny z systemem Linux.Wiem z bloga , że masz sieć zaplecza i sieć front-end. Czy podczas tych awarii serwer Windows z błędem (69.59.196.220) ma jakieś problemy z komunikacją z innymi komputerami w sieci front-end, czy może po prostu ma problemy z komunikacją z bramą? Jestem ciekawy, czy wchodzisz w awarię komputera przez sieć front-end lub back-end, gdy łapiesz go na gorącym uczynku.
Co robisz, aby „rozwiązać” problem, gdy się pojawi?
Edytować:
Z aktualizacji wynika, że ponownie uruchamiasz „nieudany” komputer z systemem Windows, aby rozwiązać problem. Czy zanim to zrobisz następnym razem, czy możesz sprawdzić, czy komputer z systemem Windows może w ogóle „rozmawiać” na interfejsie użytkownika? Weź także kopię tabeli routingu z komputera z systemem Windows (
route print) również podczas awarii. (Zasadniczo próbuję ustalić, czy karta sieciowa / sterownik nie działa prawidłowo na komputerze z systemem Windows).źródło
Ten dokument pokazuje różne stany (tabela 2.1). Niekompletne oznaczałoby, że wysłał pierwsze żądanie ARP (prawdopodobnie po przestarzałej, opóźnionej, sondującej), ale jeszcze nie otrzymał odpowiedzi.
źródło
Powodem, dla którego statyczny ARP w węźle haproxy nie pomaga, jest to, że twój serwer WWW nadal nie może znaleźć sposobu na powrót do bramy.
Statyczny ARP na serwerze internetowym przerywa zdolność serwerów do przełączania bram, gdy jeden z węzłów haproxy ulegnie awarii - Zgaduję, że interfejs wirtualny ma ten sam adres MAC, co w et1 węzła haproxy, więc musicie kod do jednej z dwóch bram do każdego serwera WWW.
Czy masz oprogramowanie zabezpieczające zainstalowane na uszkodzonym serwerze WWW? Spędziłem długą noc z serwerem Windows 2008, na którym był Symantec Endpoint Security - instaluje trochę kodu filtrującego na stosie sieciowym, który w ogóle nie pozwala na zobaczenie pakietów ARP bramy. Rozwiązaniem tego problemu (podanym przez Microsoft) było usunięcie wpisu rejestru, który załadował bibliotekę DLL.
Innym razem, gdy wystąpił ten problem, usunięcie całej karty sieciowej z menedżera urządzeń i ponowna instalacja wydawały się pomocne.
źródło
Ponieważ statycznie ustawiłeś wpis arp, twoje serwery wiedzą, gdzie znaleźć bramę. Jeśli jednak przełącznik nie wie, gdzie jest brama, nie przekaże pakietów.
Wygląda na to, że masz złe (lub zdezorientowane) przełączanie między HAproxy i serwerami internetowymi. Uruchom ponownie.
Albo to, albo twoje serwery HAproxy nie zgadzają się co do tego, który z nich ma kontrolę, i oba odpowiadają na zapytania arp dla .211.
Na tych samych liniach, jeśli twój przełącznik jest przeciążony, twoje HAproxies mogą nie być w stanie komunikować się ze sobą wystarczająco szybko i ulegają awarii.
źródło
Następnym razem, gdy wystąpi ten problem, sugeruję uruchomienie przechwytywania pakietów na dwóch przedmiotowych hostach, aby ustalić, jaki ruch ARP obserwuje każdy z nich.
Twoja maszyna HAproxy najprawdopodobniej będzie miała zainstalowany smak tcpdump . W przypadku komputera z systemem Windows potrzebujesz aplikacji WinPCAP , takiej jak Wireshark lub Microsoft Network Monitor .
W rzeczywistości, myśląc o tym, ponieważ wydaje się, że problem dotyczy konkretnie ARP, możesz potencjalnie po prostu stale rejestrować cały ruch ARP na maszynie HAproxy i maszynie Windows, o której mowa, z kroczącym plikiem przechwytywania (na wszelki wypadek) 10 MB. Powinno to być wystarczająco duże, aby do czasu wykrycia awarii plik przechwytywania nadal zawierał ruch ARP sprzed awarii. (Warto eksperymentować, uruchamiając przechwytywanie przez około godzinę, aby zobaczyć, ile danych generuje).
Przykładowa składnia przechwytywania dla Linux tcpdump (uwaga: nie mam pod ręką Linux-a do przetestowania tego; proszę przetestować zachowanie -C i -W przed użyciem w produkcji!):
Mam nadzieję, że powinno to dać ci pewne wskazówki, co dokładnie zawodzi. Po wygaśnięciu wpisu ARP (i zgodnie z tym artykułem nowsze wersje systemu Windows wydają się bardzo agresywnie starzeć „nieaktywne” wpisy), spodziewałbym się, że tak się stanie:
Choć wydaje się to proste, istnieje wiele innych rzeczy, które mogą zakłócać ten proces:
Rzeczy, aby sprawdzić, czy / kiedy to się powtórzy:
źródło
Wystąpił podobny problem z jednym z naszych serwerów terminali R2 w 2008 r., W którym cały ruch na karcie sieciowej zostałby zatrzymany, ale pozostałby podłączony, a diody LED karty sieciowej pokazywałyby komunikaty. To był ciągły problem, który pojawiał się 2-3 razy w tygodniu, ale dopiero po około 12-13 godzinach bezczynności (serwer jest restartowany co noc).
Odkryłem, że przyczyną był Seriousbit Netbalancer po tym, jak spróbowałem (z ciekawości) zakończyć usługę NetbalancerService. Następnie ruch zaczął się przesuwać przez interfejs. Od tego czasu odinstalowałem Netbalancer.
źródło
Miałem ten sam problem z siecią Asus na płycie głównej. Zostało to naprawione poprzez zainstalowanie najnowszego sterownika ze strony Realtek
źródło