Hier ist also das Szenario, und ich hoffe, dass @Chopper3 hier etwas dazu sagen kann. Für unser SAN-Fabric haben wir ein Paar Cisco MDS 9513 FC-Switches mit drei direkt angeschlossenen EMC-Frames und vier Cisco UCS-Domänen.
Das Verhalten, das wir beobachten, besteht darin, dass die CNAs auf den Blades FC-Abbrüche senden, weil die Fabric-Verbindung FCoE-Pausenframes überträgt. Cisco TAC erklärt, dass dieses Verhalten auf eine Überlastung oder Latenz im Upstream zurückzuführen ist. Wir sehen einen entsprechenden Anstieg in unseren Daten von den etwa 200 ESXi-Servern in der Umgebung, die Latenzspitzen von 100 ms bis 2000 ms melden. Einige Frames und Pfade scheinen etwas stärker betroffen zu sein als andere, was mich zu der Annahme veranlasst, dass wir einen oder mehrere der Links überlasten.
Bei den Blades handelt es sich um Server der Serien B200M2, B200M3 und B420M3. Die M2-Serie verwendet den „Palo“-Adapter M81KR und die M3-Serie den Adapter VIC1240.
Da ich nicht so viel über FC weiß, wäre ich für einige Vorschläge, wie ich das aufspüren könnte, dankbar.
Antwort1
Hier ist die Geschichte dazu:
Ich habe es aus der falschen Perspektive betrachtet. Adapterabbrüche sind ein normales Symptom, das darauf hinweist, dass eine Komponente irgendwo nicht mithält. In diesem Fall waren Adapterabbrüche ein Symptom dafür, dass die SAN-Frontend-Ports zu beschäftigt waren, um die Anforderungen zu bearbeiten. Dies wurde durch einige verschiedene Bedingungen noch verschärft.
1) Fehlerhafte Treiber – Unsere UCS-Firmware-Ebene schreibt einen passenden Treiber in ESXi vor, der bekannte Probleme bei der Wiederherstellung nach Abbrüchen hat, wodurch er in eine Schleife gerät, die nur durch einen Neustart gelöscht werden kann.
2) Zu viele Variablen – Drei SANs mit drei unterschiedlichen Problemen werden alle durch Adapterabbrüche dargestellt.
3) SAN-Fehler – Wir mussten VAAI deaktivieren, da Fehler in unserem EMC VNX-Code Probleme verursachten.
2015 BEARBEITEN:
Ich wollte diesen Thread aktualisieren, da auch viele neue Informationen ans Licht gekommen sind und das Erkennen nun ja, schwierig ist. Ich hoffe, dieser Beitrag wird einige Leute in die richtige Richtung lenken.
1) Alle oben genannten Punkte sind tatsächlich immer noch relevant. Bringen Sie all dies so schnell wie möglich in eine Supportmatrix.
2) Einige UCS 2.1-Versionen schalten die Prioritätsflusssteuerung versehentlich aus (obwohl NXOS immer noch entsprechend konfiguriert ist), was dazu führt, dass ein Teil des FCoE-Verkehrs wie der Rest behandelt wird und Sie daher manchmal FC-Frames in der falschen Reihenfolge erhalten.
3) Irgendwo in der Mitte des UCS 2.1-Codes wurde eine IO-Throttling-Einstellung von einem kosmetischen zu einem aktiven Feld. Die alte „eingebrannte“ Firmware-Einstellung war eine IO-Throttling-Anzahl von 256, die so ziemlich alle Hosts verwendeten, obwohl der Windows-Treiber es Ihnen erlaubte, dies anzupassen. Irgendwo in der Mitte dieses Codes wurde der ursprüngliche Standardwert von „16“, der dazu führte, dass „256“ in die Hardware installiert wurde, zu einer ungültigen Einstellung, und der UCSM-Code begann, dies als „2048“ zu interpretieren, was das Maximum ist. Das Ergebnis war, dass ein einzelner UCS VIC-Adapter so konfiguriert wurde, dass er unsere Speicher-Arrays absolut ZERSTÖRT.
Lesen Sie also Ihre Versionshinweise. Wir haben daraus gelernt und das Problem endlich behoben.
IO-Drosselungsfehler:https://tools.cisco.com/quickview/bug/CSCum10869