Veelgestelde vragen: FNIC Aborts

Inleiding

Dit document beschrijft wat een Fibre Channel Network Interface Card (FNIC) afbreekt en biedt antwoorden op veelgestelde vragen.

Wat is een Afbreken?

Fibre Channel (FC) heeft geen middelen voor herstel na een val of beschadigde frames. Een ABTS-bericht wordt verzonden wanneer er problemen zijn met de uitwisseling. Een afbreekpunt is een service op koppelingsniveau die kan worden gegenereerd door de initiator of het doel. Het herstel wordt uitgevoerd door de SCSI-laag (Small Compute System Interface) met een duur van 60-120 seconden, afhankelijk van de configuratie van het besturingssysteem.

Waar past de FNIC in de stack?

In het geval van Linux/ESXi, de FNIC driver zit tussen de libfc-bibliotheken die worden geleverd door de OS-leverancier (Operating System) en de werkelijke hardware.  De SCSI-laag stuurt een verzoek naar het fnic-stuurprogramma, het fnic-stuurprogramma stuurt de SCSI-aanvraag naar de firmware. De firmware genereert Fibre Channel over Ethernet (FCoE)-frames en verzendt deze via de bedrading.

Is de FNIC-abortus veroorzaakt door FNIC-stuurprogramma?

Nee, FNIC aborts zijn niet noodzakelijk een driver-probleem, maar eerder een generiek bericht dat de initiatiefnemer (of doel) geen frame binnen de time-outperiode heeft ontvangen en de SCSI-laag de uitwisseling beëindigt en opnieuw probeert.

Wat kan FC abortus veroorzaken?

FC aborts kan worden veroorzaakt door verschillende redenen zoals stremming, low performance apparaten (harde schijf, opslagprocessor, low speed links), firmware problemen, driver problemen, OS problemen, link verlies, link down/up, enzovoort.

Omdat abortussen generieke boodschappen zijn, is de eerste stap om de reikwijdte van het probleem te beperken met vragen als:

• Komt het slechts aan één kant van de opslagstof voor of allebei?
• Komt het voor op een enkele host of meerdere hosts?
• Als meerdere hosts, wat is gemeenschappelijk tussen de hosts die een probleem hebben en wat is anders dan de hosts die geen probleem ervaren?
• Komt het voor wanneer het communiceert met een specifiek Storage Attached Network (SAN)-doel of een specifiek Logical Unit Number (LUN) op het SAN-doel?
• Zijn er andere SAN-doelen of LUN's die geen probleem ondervinden en zo ja, wat zijn de verschillen met deze werkende LUN's/doelen ten opzichte van het niet-werkende doel?
• Is er een patroon te zien wanneer het probleem zich voordoet, zoals tijdens wekelijkse back-uptaken?

De antwoorden op deze vragen helpen u te isoleren waar het probleem zich zou kunnen bevinden en waar u uw focus zou kunnen starten.

De meest voorkomende oorzaak van abortus is te wijten aan Layer 1 problemen en het wordt aanbevolen om het gehele pad te controleren vanaf initiatie of te richten op interfacefouten zoals Cyclic Redundancy Check (CRC) fouten of flappende interfaces.

De volgende gemeenschappelijke reden voor abortus is te wijten aan overtekening van koppelingen tussen de initiator/doel of overtekening van componenten op het doel zoals CPU en de schijf.  Dit is waar een goede prestatiesbasislijn van pas komt.

Wat geeft dit afbreekbericht in het logboek aan?

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 dit voorbeeld, op 2017-07-27T14:54:10 UTC tijd werd een abort op vmhba2 voor FCID 0x50a00 op LUN 0xa met host OS SCSI tag 0xc8 opgeroepen. 

De LUN ID 0xA wordt omgezet in decimaal om te bepalen dat LUN-id 10 de LUN was waarmee het besturingssysteem op de array probeerde te communiceren.

Het label 0xc8 is de IO-tag van de host-scsi-laag voor het verzoek die kan worden gebruikt om de loggegevens op de VIC-adapter aan te passen.

De device instantie 2kan worden gekoppeld aan het vmware vmhba nummer met fnic-tracetool -i

/tmp # ./fnic-tracetool -i
HBA             Device
---             ------
vmhba1          fnic1
vmhba2          fnic2

De FCID 0x50c00 kan worden gekoppeld aan een specifiek doel in de fcns-database op de noordelijke switches als de fabric interconnect loopt in de end-host modus.

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-adapterlogbestanden

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 => Er worden geen frames ontvangen
• exch_type 0x1 => Exchange is actief
• Totaal aantal verwachte bytes => tot_bytes_exp 0xa00
• Ontvangen wordt => 0x0 
• burst_offset is ingesteld => 0x0
• IOS-tag van de hostscsi-laag voor dit verzoek is => 0xc8
• Bron-ID => 0x36010f 
• Doel-ID Dest => 50x00
• Volgnummer => 0x0
• rx_id => 0

Status

• Status 3 = schrijfopdracht

• Status 1 = leesopdracht

Type uitwisseling (exch_type):
========================
EXCH_NOT_IN_USE = 0,
EXCH_INITIATOR_INGRESS_ACTIVE = 1
EXCH_TARGET_INGRESS_ACTIVE = 2
EXCH_EGRESS_ACTIVE = 3
EXCH_AFGEBROKEN = 4
EXCH_DEBUG = 5

Exchange-statuswaarden(s_stat)
================================

0x00 Er worden geen frames ontvangen

0x01 Minstens één frame recvd

0x02 Sequence is nog steeds actief

0x04 reeks is compleet

0x08 overbrengingsreeks init

0x10 uitgangsvolgorde is actief

0x20 rsp voor spraak en host-vermelding verzonden

0x40 exch gegevensreeks in behandeling

Wat is het verschil tussen een afbreekbericht en een FCPIO-mismatch?

FCPIO mismatch kan optreden wanneer niet alle verwachte gegevens zijn ontvangen.

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

Gerelateerde informatie

• Cisco UCS fijnafstemming
• LIBfc gebruiken met VMware en Cisco VIC voor probleemoplossing bij initiator-/doelcommunicatie
• SAN-congestie! Begrijpen, probleemoplossing, beperking in een Cisco-fabric
• Technische ondersteuning en documentatie – Cisco Systems