Inhalt

Einführung

Was ist ein Abort?

Wo passt die FNIC in den Stack?

Wird die FNIC durch den FNIC-Treiber abgebrochen?

Was kann FC-Abbrüche verursachen?

Was bedeutet diese Abbruchmeldung, dass sie im Protokoll gefunden wurde?

Worin besteht der Unterschied zwischen einer Abort- und einer FCPIO-Inkongruenz-Nachricht?

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt, was ein Abbruch einer Fibre Channel-Netzwerkkarte (FNIC) ist, und gibt Antworten auf häufig gestellte Fragen (FAQs, Frequently Asked Questions, FAQs).

Was ist ein Abort?

Fibre Channel (FC) bietet keine Wiederherstellungsmöglichkeiten für verlorene oder beschädigte Frames. ABTS-Nachricht (Abort) wird bei Austauschproblemen gesendet. Ein Abbruch ist ein Link-Level-Service, der entweder vom Initiator oder vom Ziel ausgegeben werden kann. Die Wiederherstellung wird auf der SCSI-Ebene (Small Compute System Interface) mit Zeitüberschreitungen von 60-120 Sekunden durchgeführt, die von der Konfiguration des Betriebssystems abhängen.

Wo passt die FNIC in den Stack?

Im Fall von Linux/ESXi befindet sich der FNIC-Treiber zwischen den vom Betriebssystemhersteller bereitgestellten libfc-Bibliotheken und der tatsächlichen Hardware.  Die SCSI-Schicht sendet eine Anfrage an den Treiber fnic, der Treiber sendet die SCSI-Anfrage an die Firmware. Die Firmware generiert FCoE-Frames (Fibre Channel over Ethernet) und sendet diese über das Kabel.

Wird die FNIC durch den FNIC-Treiber abgebrochen?

Nein, FNIC-Abbrüche sind nicht unbedingt ein Treiberproblem, sondern vielmehr eine generische Meldung, dass der Initiator (oder das Ziel) innerhalb der Timeout-Periode keinen Frame erhalten hat und die SCSI-Schicht den Austausch und den erneuten Versuch beendet.

Was kann FC-Abbrüche verursachen?

FC-Abbrüche können aus verschiedenen Gründen verursacht werden, z. B. Überlastung, Geräte mit niedriger Leistung (Festplatte, Speicherprozessor, Links mit niedriger Geschwindigkeit), Firmware-Probleme, Treiber-Probleme, Betriebssystemprobleme, Link-Verlust, Link Down/Up usw.

Da Abtöne allgemeine Nachrichten sind, besteht der erste Schritt darin, den Umfang des Problems mit Fragen wie den folgenden einzugrenzen:

- Tritt sie nur auf einer Seite der Storage-Fabric oder auf beiden Seiten auf?

- Tritt sie auf einem oder mehreren Hosts auf?

- Wenn mehrere Hosts vorhanden sind, was ist bei Hosts mit einem Problem gemeinsam, und was unterscheidet sich von Hosts, bei denen kein Problem auftritt?

- Tritt er auf, wenn er mit einem bestimmten SAN-Ziel (Storage Attached Network) oder einer bestimmten Logical Unit Number (LUN) des SAN-Ziels kommuniziert?

- Gibt es andere SAN-Ziele oder LUNs, bei denen kein Problem auftritt, und wenn ja, welche Unterschiede bestehen zwischen diesen funktionierenden LUNs/Zielen und dem nicht funktionierenden Ziel?

- Gibt es ein Muster, wann das Problem auftritt, z. B. während wöchentlicher Sicherungsaufträge?

Anhand der Antworten auf diese Fragen können Sie ermitteln, wo das Problem auftritt und wo Sie sich konzentrieren sollten.

Die häufigste Ursache für Abbrüche sind Layer-1-Probleme. Es wird empfohlen, den gesamten Pfad vom Initiator bis zum Ziel auf Schnittstellenfehler wie CRC-Fehler (Cyclical Redundancy Check) oder Flapping-Schnittstellen zu überprüfen.

Der nächste häufige Grund für einen Abbruch ist die Überbelegung von Verknüpfungen zwischen Initiator/Ziel bzw. die Überbelegung von Komponenten auf dem Ziel wie CPU und Festplatte.  Hier ist eine gute Leistungsbasis praktisch.

Was bedeutet diese Abbruchmeldung, dass sie im Protokoll gefunden wurde?

VMWare vmkernel log:

2017-07-27T14:54:10.590Z cpu6:33351)<7>fnic : 2 :: Abort Cmd called FCID 0x50a00, LUN 0xa TAG c8 flags 3

In diesem Beispiel wurde für die UTC-Zeit 2017-07-27T14:54:10 auf vmhba2 für FCID 0x50a00 auf LUN 0xa mit dem Host-BS-SCSI-Tag 0xc8 ein Abbruch aufgerufen.

Die LUN ID 0 x A wird in decimal konvertiert, um zu bestimmen, dass die LUN-ID 10 die LUN war, mit der das Betriebssystem im Array kommunizieren wollte.

Das Tag 0xc8 ist das IO-Tag der Host-SCSI-Ebene für die Anfrage, das verwendet werden kann, um Protokolleinträgen auf dem VIC-Adapter zu entsprechen.

Die Geräteinstanz 2 kann mit fnic-tracetool -i bis zur vmware-vmhba-Nummer abgeglichen werden.

/tmp # ./fnic-tracetool -i

HBA             Device

---             ------

vmhba1          fnic1

vmhba2          fnic2

Die FCID 0x50c00 kann einem bestimmten Ziel in der Fcns-Datenbank der Northbound Fabric Switches zugeordnet werden, wenn das Fabric Interconnect im End-Host-Modus ausgeführt wird.

switch-A(nxos)# show fcns database fcid 0x50c00 detail vsan 1 ------------------------ VSAN:1 FCID:0x50c00 ------------------------ port-wwn (vendor) :50:00:00:00:ff:ff:ff:01 (EMC) node-wwn :50:00:00:00:ff:ff:ff:00 class :3 node-ip-addr :0.0.0.0 ipa :ff ff ff ff ff ff ff ff fc4-types:fc4_features :scsi-fcp:both 253 symbolic-port-name :SYMMETRIX::SAF- 3fB::FC::5876_272+::EMUL B80F0000 41234F44 94F360 07.27.15 11:14 symbolic-node-name :SYMMETRIX::FC::5876_272+ port-type :N port-ip-addr :0.0.0.0 fabric-port-wwn :20:1e:00:2a:6a:ea:00:00 hard-addr :0x000000 permanent-port-wwn (vendor) :50:00:00:00:ff:ff:ff:01 (EMC) connected interface :fc1/30

VIC-Adapterprotokolle

170727-14:54:10.590661 ecom.ecom_main ecom(4:0): abort called for exch abort called for exch 431b, status 3 rx_id 0s_stat 0x0xmit_recvd 0x0burst_offset 0x0sgl_err 0x0 last_param 0x0 last_seq_cnt 0x0tot_bytes_exp 0xa00h_seq_cnt 0x0exch_type 0x1s_id 0x36010fd_id 0x50c00 host_tag 0xc8

- s_stat 0x0 => Es werden keine Frames empfangen

- exch_type 0x1 => Exchange ist Eingangs und aktiv

- Erwartete Bytes insgesamt sind => tot_bytes_exp 0xa00

- Empfangen ist => 0x0.

- Burst_Offset => 0x0

- Der IO-Tag der Host-SCSI-Schicht für diese Anforderung ist => 0xc8.

- Quell-ID => 0x36010f

- Ziel-ID des Tests => 0x50c00

- SEQ ID => 0x0

- rx_id => 0

Status

- Status 3 = Schreibbefehl

- Status 1 = Lesebefehl

Exchange-Typ (exch_type):

================================

EXCH_NOT_IN_USE = 0,

EXCH_INITIATOR_INGRESS_ACTIVE = 1

EXCH_TARGET_INGRESS_ACTIVE = 2

EXCH_EGRESSION_ACTIVE = 3

EXCH_ABORTED = 4

EXCH_DEBUG = 5

Exchange-Status-Werte(s_stat):

============================================

0x00 Keine Frames empfangen

0x01 Mindestens ein zurückgestellter Frame

0x02-Sequenz ist weiterhin aktiv

0x04-Sequenz ist abgeschlossen

0x08 Übertragungssequenz init

0x10 Ausgangssequenz ist aktiv

0x20 rsp für und Host-Eintrag gesendet

0x40-Exch-Datensequenz ausstehend

Worin besteht der Unterschied zwischen einer Abort- und einer FCPIO-Inkongruenz-Nachricht?

FCPIO-Diskrepanzen können auftreten, wenn nicht alle erwarteten Daten empfangen werden.

Total bytes xmit < expecte ddata length

160621-04:26:51.733255 ecom.ecom_main ecom(8:3): ox_id 41d4 rx_id 44b seq_cnt 7 seq_id 1 160621-04:26:52.066235 ecom.ecom_main ecom(8:1): fcpio_data_cnt_mismatch for exch 4202 status 1 rx_id5f7 s_stat 0x3 xmit_recvd 0x3000 burst_offset 0x3000 sgl_err 0x0 last_param 0x2800 last_seq_cnt 0x0 tot_bytes_exp 0x8000 h_seq_cnt 0x5 exch_type 0x0 s_id 0xab800 d_id 0xab800 host_tag 0x377

Zugehörige Informationen

- Cisco UCS FC-Tunnel

- Verwenden von LIBfc mit VMware und Cisco VIC zur Fehlerbehebung bei der Initiator-/Zielkommunikation

- SAN-Überlastung! Verständnis, Fehlerbehebung, Eindämmung in einer Cisco Fabric

- Technischer Support und Dokumentation - Cisco Systems