fragen stichworte

Server mit langsamer Ping-Antwort

Zwei Boxen mit identischen Lasten, die dieselben Sites bedienen, werden langsamer und reagieren nicht mehr auf Ping. Der langsame (oder intermittierende) Ping veranlasst unseren Load Balancer zu der Ansicht, dass die Server offline sind, und deaktiviert sie. Es gibt einen dritten Server mit identischem Inhalt, bei dem das Problem nicht vorliegt. Daher bin ich ziemlich sicher, dass dies nicht die Websites sind.

Betriebssystem ist Windows Server 2008. Die Konfiguration ist etwas Besonderes: Da wir den Load Balancer von Barracuda Networks im Direct Server Return-Modus verwenden, mussten wir einige Loopback-Adapter konfigurieren, die die IP wie beschrieben "fälschen" hier. Für den physischen Adapter ist die Weiterleitung auf 2008 aktiviert, damit die Loopback-Adapter funktionieren.

Symptome:

  • Wenn dies auftritt, wird der Ping-Vorgang in der Regel entweder abgelaufen oder Pakete fallen gelassen.
  • Korrekturen scheinen einer oder mehrere der folgenden Punkte zu sein:
    • Anmelden über Remote Desktop.
    • Löschen des DNS-Cache oder des Arp-Cache (nicht sicher, welcher).
    • Neustart
  • Nach einem oder mehreren der obigen Punkte scheint der Server etwa 4 Stunden lang in Ordnung zu sein, bevor er wieder aktiv wird.

Frage:

Welche möglichen Gründe gibt es dafür? Was soll ich versuchen, dies zu diagnostizieren? Ich habe nichts ausgeschlossen. Switch Konfiguration, Domain/DNS-Server, alle Ideen sind willkommen.

Leider habe ich sehr wenig Wissen über eine gute Netzwerkadministration. Daher sind auch offensichtliche Antworten willkommen.

BEARBEITEN:

Als Antwort auf einige der gestellten Fragen.

Ich habe Barracuda kontaktiert und sie scheinen der Meinung zu sein, dass das Problem mit dem Netzwerk zusammenhängt. Ich glaube, ich stimme an dieser Stelle zu.

Die IP wird einer physischen Schnittstelle zugewiesen und nicht von Servern gemeinsam genutzt. Das Pinging erfolgt aus demselben Subnetz.

Die dritte Box übernimmt die gesamte Site-Last, wenn die anderen beiden heruntergefahren sind und keine großen Probleme damit hatten, aber gelegentlich auch Probleme. Ich habe noch kein Muster mit diesem gefunden.

Heute Abend habe ich mich mit einem anderen (erfahreneren) Netzwerk-Typ zusammengesetzt, um einige der Domänen- und Serverkonfigurationen durchzusehen. Er fand unter anderem ein fehlerhaftes DNS-Setup auf den Domänencontrollern. Sie wurden mit externen DNS-Servern als Alternative und nicht mit dem anderen DC konfiguriert. Wir haben sie für dns auf einander bezogen und die Weiterleitung zum dns-Dienst hinzugefügt. Wir haben auch externe DNS-Verweise von allen Webservern entfernt.

BEARBEITEN 2:

Mit Wireshark konnte ich den ICMP-Verkehr während einer Ausfallzeit untersuchen. Ich habe mit diesem Test begonnen, weil ich keinen freigegebenen Ordner in Box 2 aus Box 1 erreichen konnte.

Test:

  1. Starten Sie die Erfassung des Verkehrs in Box 2.
  2. Beobachtet, dass Box 2 Pings vom Barracuda Load Balancer sah und darauf antwortete.
  3. In Feld 1 angemeldet und in Feld 2 gepingelt.
  4. Beobachtet, dass Box 2 gesehen hat, aber NICHT auf Pings von Box 1 geantwortet hat.
  5. Beobachtet, dass Feld 2 gesehen hat, aber 100 Sekunden nach dem ersten Ping aus Feld 1 NICHT auf Pings von LB geantwortet hat.

Irgendwie führt der Verkehr zwischen den beiden Boxen dazu, dass Box 2 auf ICMP für eine gewisse Zeit ausfällt.

Ich sollte beachten, dass Box 1 während des gesamten Tests einwandfrei funktioniert hat, jedoch keine Anfragen aus Box 2 angezeigt wurden. Während Box 1 aus Box 2 gepinged wurde, zeigte Wireshark auf Box 2 die Meldung "Ziel nicht erreichbar (Kommunikation administrativ gefiltert)". von einer Quell-IP habe ich nicht erkannt.

antworten

Müssen Sie ICMP-Ping für Ihren Servertest verwenden? HTTP-Anforderungen werden von den meisten Lastverteilern unterstützt und sind in der Regel eine bessere Idee, da der Webserver möglicherweise heruntergefahren ist, während die Netzwerkkarte noch aktiv ist.

Ist der dritte Server unter Last oder ist er auf andere Weise von den anderen beiden Server eindeutig?

Ohne mehr darüber zu wissen, würde ich vorschlagen, Wireshark auf diese Server zu laden, während sie einen Ping-Befehl ausführen und sich die ICMP-Aktivität ansehen. Mein (möglicherweise unbegründeter) Verdacht ist, dass diese Server ARP-Probleme haben und Antwortpakete zurückschicken. Sie erhalten sie einfach nie.

Setzen Sie bei Wireshark Ihren Filter auf "arp oder icmp" und sehen Sie, was er bringt. Sie sollten auch einen kurzen Blick auf Ihre Systemereignisprotokolle werfen - da könnte etwas offensichtliches drin sein, das jede weitere Vermutung abkürzt.

Wenn Sie mit arp nicht vertraut sind, ist dies das Protokoll für die Übersetzung von IP-Adressen (Layer 3) in MAC-Adressen (Layer 2). Dies muss korrekt geschehen, oder der Layer-2-Frame, der das Layer-3-Paket enthält, wird entweder nie gesendet oder kommt am falschen Ziel an.

Die Duplex-/Geschwindigkeitsempfehlungen der anderen Poster sind schließlich eine bewährte Methode, auch wenn ich bezweifle, dass sie hier die Ursache sind. Beachten Sie, dass Sie sich bei Gigabit-Ethernet keine Sorgen mehr über das Autonegotiation-Saugen machen müssen.

BEARBEITEN

Die von Ihnen vorgenommenen DNS-Änderungen sind sicherlich eine gute Idee, aber es fällt mir schwer, mir ein Szenario vorzustellen, in dem dies zu ICMP-Timeouts führen würde. Möglicherweise blockiert die App Tausende von DNS-Abfragen und verbraucht so viele Ressourcen, dass sie nicht auf ICMP reagieren kann.

Wenn das Problem dadurch nicht behoben wird, sollten die Paketverfolgungen mehr Informationen darüber enthalten, was passiert.

Ich würde zuerst bei Barracuda Networks nachfragen. Dies kann ein bekanntes Problem sein. Wir hatten ein ähnliches Problem, das sich als unser Cisco Load Balancer herausstellte. Ein Firmware-Update behebte das Problem.

Welche IP-Adresse hat die administrative Filterung vorgenommen? Am wahrscheinlichsten ist dies die Ursache des Problems, und ich würde vermuten, dass es sich beim Load Balancer

befindet

Ich habe festgestellt, dass es hilfreich ist, sicherzustellen, dass die NIC auf dem Server und der Port auf dem Switch, an den er angeschlossen ist, auf die gleichen Geschwindigkeits- und Duplexeinstellungen eingestellt sind. Ich habe Probleme mit "automatischen Verhandlungen", die nicht sehr gut verhandeln, was zu vielen Fehlern auf dem Port und der Netzwerkkarte führt.

Versuchen Sie, Ihre Schnittstellen manuell auf Geschwindigkeit einzustellen, und vermeiden Sie, wenn möglich, die automatische Verhandlung zu verwenden.

Aktualisieren Sie die Netzwerktreiber auf Ihren Servern auf die neueste Version, die von Ihrem Hardwarehersteller bereitgestellt wird. Ich finde, das behebt manchmal seltsame Netzwerkprobleme.