TL; DR-Version: Es stellte sich heraus, dass dies ein tiefer Broadcom-Netzwerkfehler in Windows Server 2008 R2 war. Das Ersetzen durch Intel-Hardware wurde behoben. Wir verwenden keine Broadcom-Hardware mehr. Je.
Wir haben HAProxy zusammen mit Heartbeat aus dem Linux-HA-Projekt verwendet. Wir verwenden zwei Linux-Instanzen, um ein Failover bereitzustellen. Jeder Server verfügt über eine eigene öffentliche IP-Adresse und eine einzelne IP-Adresse, die über eine virtuelle Schnittstelle (eth1: 1) unter IP: 69.59.196.211 von beiden geteilt wird
Die virtuelle Schnittstelle (eth1: 1) IP 69.59.196.211 ist als Gateway für die Windows-Server dahinter konfiguriert, und wir verwenden ip_forwarding, um den Datenverkehr weiterzuleiten.
Es kommt gelegentlich zu einem Netzwerkausfall auf einem unserer Windows-Server hinter unseren Linux-Gateways. HAProxy erkennt, dass der Server offline ist. Dies können wir überprüfen, indem wir eine Remoteverbindung zum ausgefallenen Server herstellen und versuchen, das Gateway per Ping zu erreichen:
Ping 69.59.196.211 mit 32 Datenbytes: Antwort von 69.59.196.220: Zielhost nicht erreichbar.
Die Ausführung arp -aauf diesem ausgefallenen Server zeigt, dass für die Gateway-Adresse (69.59.196.211) kein Eintrag vorhanden ist :
Schnittstelle: 69.59.196.220 --- 0xa Internetadresse Typ der physischen Adresse 69.59.196.161 00-26-88-63-c7-80 dynamic 69.59.196.210 00-15-5d-0a-3e-0e dynamisch 69.59.196.212 00-21-5e-4d-45-c9 dynamisch 69.59.196.213 00-15-5d-00-b2-0d dynamic 69.59.196.215 00-21-5e-4d-61-1a dynamisch 69.59.196.217 00-21-5e-4d-2c-e8 dynamic 69.59.196.219 00-21-5e-4d-38-e5 dynamic 69.59.196.221 00-15-5d-00-b2-0d dynamic 69.59.196.222 00-15-5d-0a-3e-09 dynamisch 69.59.196.223 ff-ff-ff-ff-ff-ff statisch 224.0.0.22 01-00-5e-00-00-16 statisch 224.0.0.252 01-00-5e-00-00-fc statisch 225.0.0.1 01-00-5e-00-00-01 statisch
Auf unseren Linux-Gateway-Instanzen arp -azeigt:
peak-colo-196-220.peak.org (69.59.196.220) bei <incomplete> auf eth1 stackoverflow.com (69.59.196.212) um 00: 21: 5e: 4d: 45: c9 [ether] auf eth1 peak-colo-196-215.peak.org (69.59.196.215) um 00: 21: 5e: 4d: 61: 1a [ether] auf eth1 peak-colo-196-219.peak.org (69.59.196.219) um 00: 21: 5e: 4d: 38: e5 [ether] auf eth1 peak-colo-196-222.peak.org (69.59.196.222) um 00: 15: 5d: 0a: 3e: 09 [ether] auf 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) um 00: 21: 5e: 4d: 2c: e8 [ether] auf eth1
Warum hat arp den Eintrag für diesen ausgefallenen Server gelegentlich als <unvollständig> festgelegt? Sollen wir unsere Arp-Einträge statisch definieren? Ich habe arp immer alleine gelassen, da es 99% der Zeit funktioniert, aber in diesem einen Fall scheint es zu scheitern. Gibt es zusätzliche Schritte zur Fehlerbehebung, mit denen wir dieses Problem beheben können?
DINGE, DIE WIR VERSUCHT HABEN
Ich habe einen statischen Arp-Eintrag zum Testen auf einem der Linux-Gateways hinzugefügt, der immer noch nicht geholfen hat.
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
Ein Neustart des Windows-Webservers behebt dieses Problem vorübergehend, ohne dass Änderungen am Netzwerk vorgenommen werden. Unsere Erfahrung zeigt jedoch, dass dieses Problem erneut auftritt.
Austausch von Netzwerkkarten und Switches
Ich bemerkte, dass die Verbindungsleuchte am Port des Switches für den ausgefallenen Windows-Server auf der ausgefallenen Schnittstelle mit 100 MB anstelle von 1 GB lief. Ich habe das Kabel auf mehrere andere offene Ports verschoben, und der Link zeigte 100 MB für jeden Port an, den ich ausprobiert habe. Mit dem gleichen Ergebnis habe ich auch das Kabel getauscht. Ich habe versucht, die Eigenschaften der Netzwerkkarte in Windows zu ändern, und der Server wurde gesperrt. Nach dem Klicken auf Übernehmen war ein Hard-Reset erforderlich. Dieser Windows-Server verfügt über zwei physische Netzwerkschnittstellen. Daher habe ich die Kabel und Netzwerkeinstellungen der beiden Schnittstellen vertauscht, um festzustellen, ob das Problem auf die Schnittstelle zurückzuführen ist. Wenn die öffentliche Schnittstelle wieder ausfällt, wissen wir, dass es kein Problem mit der Netzwerkkarte gibt.
(Wir haben auch versucht, einen anderen Schalter zur Hand zu haben, keine Änderung)
Ändern der Netzwerkhardwaretreiberversionen
Wir hatten das gleiche Problem mit dem neuesten Broadcom-Treiber sowie dem in Windows Server 2008 R2 integrierten Treiber.
Netzwerkkabel ersetzen
Als letzte Anstrengung haben wir uns daran erinnert, dass eine weitere Änderung darin bestand, alle Patchkabel zwischen unseren Servern / Switches auszutauschen. Wir hatten zwei Sets gekauft, eines mit einer Länge von 1 - 3 Fuß für die privaten Schnittstellen und ein weiteres Set mit roten Kabeln für die öffentlichen Schnittstellen. Wir haben alle öffentlichen Schnittstellen-Patchkabel gegen andere Marken ausgetauscht und unsere Server eine Woche lang ohne Probleme betrieben ... und dann trat das Problem erneut auf.
Deaktivieren Sie die Prüfsummenverschiebung und entfernen Sie TProxy
Wir haben auch versucht, das TCP / IP-Prüfsummen-Offload im Treiber zu deaktivieren, keine Änderung. Wir ziehen jetzt TProxy heraus und gehen zu einer traditionelleren x-forwarded-forNetzwerkanordnung über, ohne dass die IP-Adresse neu geschrieben werden muss. Mal sehen, ob das hilft.
Wechseln Sie den Virtualisierungsanbieter
Da dies auf irgendeine Weise mit Hyper-V zu tun hatte (wir hosten Linux-VMs darauf), sind wir auf VMWare Server umgestiegen. Keine Änderung.
Host-Modell wechseln
Wir haben das Ende unserer Problembehandlung erreicht und beziehen jetzt offiziell den Microsoft-Support ein. Sie empfahlen, das Host-Modell zu ändern:
- http://en.wikipedia.org/wiki/Host_model
- http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Wir haben das getan und wir haben auch einige unveröffentlichte Kernel-Hotfixes bekommen, die vermutlich in 2008 R2 SP1 eingeführt wurden. Keine Reparatur.
Ersetzen der Netzwerkkartenhardware
Letztendlich hat das Ersetzen der Broadcom-Netzwerkhardware durch Intel-Netzwerkhardware dieses Problem für uns behoben. Daher neige ich zu der Annahme, dass die Broadcom Windows Server 2008 R2-Treiber fehlerhaft sind!
quelle
Antworten:
Von http://linux-ip.net/html/ether-arp.html :
Es sieht so aus, als würde Ihre Gateway-Box nicht (oder zu langsam) auf ARP-Anfragen von Ihrer Gateway-Box antworten. Schaltet das
<incomplete>irgendwann um<failed>? Welche Netzwerkhardware haben Sie zwischen dem Server und dem Gateway? Ist es möglich, dass Broadcast-ARP-Anforderungen irgendwo zwischen den beiden Hosts gefiltert oder blockiert werden?quelle
Dies bedeutet, dass Sie die Adresse gepingt haben, die IP einen PTR-Eintrag (daher der Name) hat, aber nichts von dem fraglichen Computer geantwortet hat. Wenn wir das sehen, liegt das meistens daran, dass eine Subnetzmaske falsch eingestellt ist - oder im Fall von IPs, die an eine Loopback-Schnittstelle gebunden sind und stattdessen versehentlich an die eth-Schnittstelle gebunden wurden.
Was ist 196.220? In welcher Beziehung steht es zu 196.211? Ich gehe davon aus, dass .220 einer der HA-Proxy-Hosts ist. Wenn Sie ifconfig -a & arp -a ausführen, was wird angezeigt?
quelle
Wie Max Clark sagt, bedeutet <unvollständig> nur, dass 69.59.196.211 eine ARP-Anfrage für 69.59.196.220 gesendet hat und noch keine Antwort erhalten hat. (In Windows-Land wird dies als ARP-Zuordnung zu "00-00-00-00-00-00" angezeigt. Für mich ist es übrigens merkwürdig, dass Sie keine solche ARP-Zuordnung sehen 69.59.196.220 für 69.59.196.211.)
Ich mag es nicht, statische ARP-Einträge zu verwenden, da ARP meiner Erfahrung nach im Allgemeinen die ganze Zeit seine Arbeit geleistet hat.
Wenn ich es wäre, würde ich die entsprechende Ethernet-Schnittstelle auf dem "fehlerhaften" Windows-Computer (69.59.196.220) beschnüffeln, um zu beobachten, wie ARP für 69.59.196.211 funktioniert, und um zu beobachten, wie / ob auf ARP-Anforderungen von 69.59 reagiert wird. 196,211. Ich würde auch in Betracht ziehen, auf dem Gateway-Rechner nur für ARP (
tcpdump -i interface-name arp) zu schnüffeln, um zu sehen, wie der ARP-Verkehr von der Seite des Linux-Rechners aus aussieht.Ich weiß aus dem Blog , dass Sie ein Back-End-Netzwerk und ein Front-End-Netzwerk haben. Hat der "ausfallende" Windows-Server (69.59.196.220) während dieser Ausfälle Probleme bei der Kommunikation mit anderen Computern im Front-End-Netzwerk oder hat er nur Probleme, mit seinem Gateway zu kommunizieren? Ich bin neugierig, ob Sie über das Front-End- oder Back-End-Netzwerk an den fehlerhaften Rechner kommen, wenn Sie ihn auf frischer Tat ertappen.
Was tun Sie, um das Problem zu beheben, wenn es auftritt?
Bearbeiten:
Ich sehe aus Ihrem Update, dass Sie den "fehlerhaften" Windows-Computer neu starten, um das Problem zu beheben. Können Sie vor dem nächsten Mal überprüfen, ob der Windows-Computer überhaupt in der Lage ist, über die Front-End-Oberfläche zu kommunizieren? Nehmen Sie auch
route printwährend eines Fehlers eine Kopie der Routingtabelle vom Windows-Computer ( ). (Ich versuche festzustellen, ob die Netzwerkkarte / der Treiber auf dem Windows-Computer fehlerhaft funktioniert.)quelle
Dieses Dokument zeigt die verschiedenen Zustände (Tabelle 2.1). Unvollständig würde bedeuten, dass eine erste ARP-Anforderung gesendet wurde (vermutlich nach einem veralteten, verzögerten oder getesteten Vorgang), aber noch keine Antwort erhalten hat.
quelle
Der Grund, warum der statische ARP auf dem Haproxy-Knoten nicht hilft, ist, dass Ihr Webserver immer noch nicht herausfindet, wie er zum Gateway zurückkehren kann.
Statisches ARP auf dem Webserver unterbricht die Fähigkeit Ihrer Webserver, Gateways zu wechseln, wenn einer der Haproxy-Knoten ausfällt. Ich vermute, dass die virtuelle Schnittstelle dieselbe MAC-Adresse wie eth1 des Haproxy-Knotens hat, sodass Sie es schwer haben würden Code zu einem der beiden Gateways in jedem Webserver.
Ist auf dem ausfallenden Webserver eine Sicherheits-Software installiert? Ich habe eine lange Nacht mit einem Windows 2008-Server verbracht, auf dem Symantec Endpoint Security installiert ist. Er installiert einen Filtercode im Netzwerkstapel, der verhindert, dass die ARP-Pakete des Gateways überhaupt angezeigt werden. Das Update dafür (wie von Microsoft bereitgestellt) war das Entfernen des Registrierungseintrags, der die DLL geladen hat.
Das andere Mal, als dieses Problem auftrat, schien das Entfernen des gesamten Netzwerkadapters aus dem Geräte-Manager und die Neuinstallation zu helfen.
quelle
Da Sie Ihren Arp-Eintrag statisch festgelegt haben, wissen Ihre Server , wo sich das Gateway befindet. Wenn Ihr Switch jedoch nicht weiß, wo sich das Gateway befindet, werden Ihre Pakete nicht weitergeleitet.
Klingt so, als hätten Sie einen schlechten (oder verwirrten) Wechsel zwischen Ihrem HAproxy und Ihren Webservern. Starte es neu.
Entweder das, oder Ihre HAproxy-Server sind sich nicht einig, welcher die Kontrolle hat, und beide beantworten die Arp-Suche nach .211.
Wenn Ihr Switch überlastet ist, können Ihre HAproxies möglicherweise nicht schnell genug miteinander kommunizieren und es kommt zu einem Failover.
quelle
Wenn dieses Problem das nächste Mal auftritt, würde ich vorschlagen, einige Paketerfassungen auf den beiden fraglichen Hosts durchzuführen, um festzustellen, welchen ARP-Verkehr jeder von ihnen beobachtet.
Auf Ihrem HAproxy-Computer ist höchstwahrscheinlich ein Teil von tcpdump installiert. Für den Windows-Computer benötigen Sie entweder eine WinPCAP- Anwendung wie Wireshark oder Microsoft Network Monitor .
Wenn Sie darüber nachdenken, könnte das Problem anscheinend spezifisch bei ARP liegen, und Sie könnten möglicherweise den gesamten ARP-Verkehr auf dem HAproxy-Computer und dem betreffenden Windows-Computer mit einer fortlaufenden Erfassungsdatei von (aus Gründen des Arguments) 10 MB kontinuierlich aufzeichnen. Diese sollte groß genug sein, damit die Erfassungsdatei zum Zeitpunkt der Feststellung eines Fehlers weiterhin den ARP-Verkehr enthält, der vor dem Fehler aufgetreten ist. (Es lohnt sich zu experimentieren, indem Sie das Capture etwa eine Stunde lang ausführen, um zu sehen, wie viele Daten es generiert.)
Beispiel-Capture-Syntax für Linux tcpdump (Hinweis: Ich habe keine Linux-Box zum Testen parat. Bitte testen Sie das Verhalten von -C und -W, bevor Sie sie in der Produktion verwenden!):
Dies sollte Ihnen hoffentlich einen Hinweis darauf geben, was genau ausfällt. Wenn ein ARP-Eintrag abläuft (und gemäß diesem Artikel scheinen neuere Versionen von Windows "inaktive" Einträge sehr aggressiv zu altern), würde ich Folgendes erwarten:
So einfach es klingt, es gibt eine Reihe anderer Dinge, die diesen Prozess stören können:
Zu überprüfende Punkte, ob / wann dies erneut geschieht:
quelle
Wir hatten ein ähnliches Problem mit einem unserer 2008 R2-Terminalserver, bei dem der gesamte Datenverkehr auf der Netzwerkkarte gestoppt wurde, jedoch in Verbindung blieb und die Netzwerkkarten-LEDs die Kommunikation anzeigten. Dies war ein fortlaufendes Problem, das 2-3 Mal pro Woche auftrat, jedoch erst nach ca. 12-13 Stunden Betriebszeit (der Server wird jede Nacht neu gestartet).
Ich stellte fest, dass Seriousbit Netbalancer die Ursache war, nachdem ich (aus Neugier) versucht hatte, den NetbalancerService-Dienst zu beenden. Der Verkehr begann sich dann über die Schnittstelle zu bewegen. Ich habe Netbalancer seitdem deinstalliert.
quelle
Ich hatte das gleiche Problem mit dem Asus Mainboard LAN. Es wurde behoben, indem ein neuester Treiber von der Realtek- Website installiert wurde
quelle