Problem mit dem Heartbeat-Switch des Cisco Catalyst-Clusters - Erhöhung der Eingabefehler

PROBLEM: Die Server in zwei Clustern verlieren immer wieder die Heartbeat-Konnektivität miteinander, was zu Datenbankausfällen führt. Ausfälle sind kurz, aber störend.

INSTALLIEREN:

• Es gibt zwei Cluster mit jeweils drei Servern.
• Jeder Server verfügt über eine Netzwerkkarte, die mit einem einzelnen Layer 2-Switch (Catalyst 2950) verbunden ist, wobei die Switch-Ports mit 100 MB / Vollduplex fest codiert sind.
• Die DBAs bestätigen, dass jede Heartbeat-NIC fest auf 100 MB / Vollduplex codiert ist.
• In VLAN 100 und im selben Subnetz (10.40.60.0/24) sind zwei Cluster konfiguriert.
• Die Verwaltungs-IP-Adresse befindet sich in einem separaten Subnetz (10.40.1.0/24) und der Switch-Port befindet sich in VLAN 1.

SYMPTOME:

• Ich sehe eine ständig steigende Fehleranzahl an den Switch-Ports. Für die drei Server in einem Cluster betragen die Eingabefehler (alle CRC) etwa 3% der gesamten Eingabepakete. Es gibt keine Ausgabefehler. Der andere Cluster macht ungefähr 6% der gesamten Eingabepakete aus.
• Die Sende- und Empfangslast an den Switch-Ports ist gering, unter 20/255 bei txload und rxload.
• Das Switch-Protokoll zeigt die Switch-Ports an:

  16. Mai 11:15:31 PDT:% LINEPROTO-5-UPDOWN: Leitungsprotokoll auf der Schnittstelle FastEthernet0 / 13, Status auf down geändert
  16. Mai 11:15:32 PDT:% LINK-3-UPDOWN: Schnittstelle FastEthernet0 / 13 geändert Status nach unten
  16. Mai 11:15:34 PDT:% LINK-3-UPDOWN: Schnittstelle FastEthernet0 / 13, Status nach oben geändert
  16. Mai 11:15:35 PDT:% LINEPROTO-5-UPDOWN: Leitungsprotokoll auf Schnittstelle FastEthernet0 / 13, Status geändert nach oben

FEHLERSUCHE SCHRITTE DURCHGEFÜHRT:

• Ich habe die alte Cat5-Verkabelung zwischen der Server-Heartbeat-Netzwerkkarte und dem Switch durch eine neue Cat6-Verkabelung ersetzt - keine Auswirkung.
• Ich habe ein neues VLAN 200 in einem neuen Subnetz (10.40.61.0/24) erstellt und die DBAs ihre Heartbeat-NICs in einem Cluster erneut IP-fähig machen lassen - keine Auswirkung.
• Wir haben jede Kombination aus Geschwindigkeit und Duplex am Switch-Port und an der Netzwerkkarte ausprobiert - kein Effekt, bei beiden wurde auf 100 MB / Vollduplex zurückgegriffen.
• Die Datenbankadministratoren haben die Broadcom-Treiber in beiden Clustern auf den neuesten Stand gebracht. Der Fehleranteil im 6% -Cluster ist auf 4% gesunken, der andere Cluster liegt immer noch bei 3%.

MEINE VORGESCHLAGENEN NÄCHSTEN SCHRITTE:

• Auf den Servern befinden sich Intel-Netzwerkkarten. Versuchen Sie, den Cluster-Heartbeat auf eine Intel-Netzwerkkarte zu verschieben. Vielleicht ist es ein Broadcom-Problem?
• Wechseln Sie den Schalter zu einem Gig-fähigen Schalter. Es ist ein Catalayst 3560x verfügbar, dessen Aufnahme jedoch ein Projekt verzögert. Vielleicht Gig am Switch-Port und NIC wird besser spielen?

GEDANKEN?

Kann ich auf dem vorhandenen 2950-Switch etwas konfigurieren, um die Fehler zu minimieren? Welche zusätzlichen Schritte zur Fehlerbehebung sollte ich unternehmen?

CRC-Fehler sind häufig Verkabelungsprobleme. Hier sind die Dinge, die ich als nächstes überprüfen würde, bevor ich Hardware austausche:

• Sind die Server direkt mit dem Switch verbunden oder stellen sie eine Verbindung über eine Infrastrukturverkabelung her? Wenn ja, lassen Sie die Infrastrukturkabel erneut zertifizieren.
• Wenn Sie einen echten Kabeltester haben (keinen einfachen Durchgangsprüfer), würde ich die Kabel testen.
• Wenn die Kabel von Hand gefertigt werden, würde ich sie durch werkseitig hergestellte Kabel ersetzen. Bei handgefertigten Kabeln treten häufig solche Probleme auf.
• Überprüfen Sie, ob sich in der Nähe der Kabel eine EM-Quelle befindet. Verlegen Sie die Kabel neu, wenn Sie dies auch nur vorübergehend tun können, um sicherzustellen, dass sie von der Stromversorgung oder anderen EM-Quellen getrennt sind.

Darüber hinaus würde ich bei den NICs beginnen, wie Sie bereits angegeben haben. Könnte sein, dass du welche von einem schlechten Lauf hast.

Ich würde empfehlen, zu testen, indem Sie auf die von Ihnen vorgeschlagene Intel-Netzwerkkarte wechseln. Ich bin auf ähnliche Probleme gestoßen, bei denen ein kleiner Prozentsatz des Datenverkehrs Eingabefehler waren. Wir haben das Problem behoben, indem wir einen dummen Hub zwischen dem Server (in meinem Fall Kameras) und dem Switch platziert haben. Wenn der Switch keine Eingabefehler mehr sieht, liegt das Problem in der Server-Netzwerkkarte.

Ich habe viele der gleichen Schritte ausprobiert, die Sie vorgeschlagen haben. In meinem Fall stellte sich heraus, dass es sich um einen schlechten Produktionslauf handelte. Das einzige, was das Problem behoben hat, war das Ersetzen der Netzwerkkarte (Kameras).