O multipath de fibra falha: Resultado: hostbyte = DID_ERROR driverbyte = DRIVER_OK

6

Estou tentando copiar (~ 7TB de dados usando o rsync) entre dois servidores no mesmo data center no backend usando o EMC VMAX3

Depois de copiar ~ 30-40GB de início de multicaminho de dados com falha

Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: Recovered to normal mode
Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: remaining active paths: 1
Dec 15 01:57:53 test.example.com kernel: sd 1:0:2:20: [sdeu]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK 

[root@test log]# multipath -ll |grep -i fail
 |- 1:0:0:15 sdq  65:0   failed ready running
  - 3:0:0:15 sdai 66:32  failed ready running

Estamos usando o multipath.conf padrão

HBA driver version  8.07.00.26.06.8-k

HBA model QLogic Corp. ISP8324-based 16Gb Fibre Channel to PCI Express Adapter

OS: CentOS 64-bit/2.6.32-642.6.2.el6.x86_64
Hardware:Intel/HP ProLiant DL380 Gen9

Já verificamos esta solução e verificamos com a EMC tudo parece ser bom link

Mais algumas informações

Não há pacotes de queda / erro no lado da rede.

  • O Filesystem é montado com noatime, nodiratime
  • Sistema de arquivos ext4 (Já tentei o xfs mas o mesmo erro)
  • O LVM está no modo striped (iniciado com a opção linear e depois convertido em striped)
  • Já desabilitou o THP

  • echo nunca > / sys / kernel / mm / redhat_transparent_hugepage / enabled

  • Sempre que o processo de falha inicial do multipath for para o estado D
  • Atualização do firmware do sistema
  • Tentei com a versão mais recente do driver qlogic
  • Tentei com um agendador diferente (noop, prazo final, cfq)
  • Tentei com diferentes perfis ajustados (armazenamento empresarial)

Vmcore coletado durante o período da edição

Eu sou capaz de coletar vmcore durante o tempo de emissão

  KERNEL: /usr/lib/debug/lib/modules/2.6.32-642.6.2.el6.x86_64/vmlinux
DUMPFILE: vmcore  [PARTIAL DUMP]
    CPUS: 36
    DATE: Fri Dec 16 00:11:26 2016
  UPTIME: 01:48:57
  LOAD AVERAGE: 0.41, 0.49, 0.60
   TASKS: 1238
NODENAME: test.example.com
 RELEASE: 2.6.32-642.6.2.el6.x86_64
 VERSION: #1 SMP Wed Oct 26 06:52:09 UTC 2016
 MACHINE: x86_64  (2297 Mhz)
  MEMORY: 511.9 GB
   PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000018"
     PID: 15840
 COMMAND: "kjournald"
    TASK: ffff884023446ab0  [THREAD_INFO: ffff88103def4000]
     CPU: 2
   STATE: TASK_RUNNING (PANIC)

Depois de Enbaling Debug mode no sid do qlogic

qla2xxx [0000:0b:00.0]-3822:5: FCP command status: 0x2-0x0 (0x70000) nexus=5:1:0 portid=1f0160 oxid=0x800 cdb=2a200996238000038000 len=0x70000 rsp_info=0x0 resid=0x0 fw_resid=0x0 sp=ffff882189d42580 cp=ffff88276d249480.
qla2xxx [0000:84:00.0]-3822:7: FCP command status: 0x2-0x0 (0x70000) nexus=7:0:3 portid=450000 oxid=0x4de cdb=2a20098a5b0000010000 len=0x20000 rsp_info=0x0 resid=0x0 fw_resid=0x0 sp=ffff882189d421c0 cp=ffff8880237e0880.
    
por Prashant Lakhera 17.12.2016 / 06:13

4 respostas

1

Finalmente, a questão é resolvida

Erro: VISUALIZAÇÃO DA TECNOLOGIA: o suporte a DIF / DIX pode não ser totalmente suportado.

Eu vi constantemente esta mensagem no dmesg durante o tempo de emissão e continue ignorando esta mensagem

Em mais depuração, descobri que o Kernel está em estado corrompido

 cat /proc/sys/kernel/tainted **So it's a combination of  TAINT_TECH_PREVIEW and TAINT_WARN**
 536871424

 lsmod |egrep -i "dif|dix" 
 crc_t10dif              1209  1 sd_mod

 modinfo crc_t10dif
 filename:       /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/lib/crc-t10dif.ko
 softdep:        pre: crct10dif
 license:        GPL
 description:    T10 DIF CRC calculation
 srcversion:     52BC47DEA6DD58B87A2D9C1
 depends:        
 vermagic:       2.6.32-642.6.2.el6.x86_64 SMP mod_unload modversions

Como por RedHat

DIF is a new feature recently added to the SCSI Standard. It increases the size of the commonly-used 512-byte disk block from 512 to 520 bytes. The extra bytes comprise the Data Integrity Field (DIF). The basic idea is that the HBA will calculate a checksum value for the data block on writes, and store it in the DIF. The storage device will confirm the checksum on receive, and store the data plus checksum. On a read, the checksum will be checked by the storage device and by the receiving HBA.

The Data Integrity Extension (DIX) allows this check to move up the stack: the application calculates the checksum and passes it to the HBA, to be appended to the 512 byte data block. This provides a full end-to-end data integrity check

Some vendors have adopted the name Protection Information (PI) to refer to the DIF/DIX functionality. There is one difficulty associated with DIF/DIX on Linux - the memory management system may change the data buffer while it is queued for a write. If it does this, then the memory management system must remember to keep that page marked dirty after the I/O succeeds. If the memory management system changes the data in the buffer after the checksum is calculated, but before the write is done, then the checksum test will fail, the write will fail, and the filesystem will go read-only, or some similar failure will occur.

Because of this, users of Red Hat Enterprise Linux 6 should note the following: The DIF/DIX hardware checksum feature must only be used with applications that exclusively issue O_DIRECT I/O. These applications may use the raw block device, or the XFS file system in O_DIRECT mode. (XFS is the only filesystem that does not fall back to buffered IO when doing certain allocation operations). Only applications designed for use with O_DIRECT I/O and DIF/DIX hardware should enable this feature.

DIF/DIX is a Tech Preview in RHEL 6.0. There are currently just two driver/hba combinations that have this support: Emulex lpfc and LSI mpt2sas. There are just a few storage vendors who support it: the Netapp Engenio FC RAID array, and certain Hitachi SAS disks. We expect additional storage vendors to support this feature in the future.

Como estamos usando a EMC, decidimos desativar esse recurso e isso foi o truque

   cat /etc/modprobe.d/qla2xxx.conf
   options qla2xxx ql2xenabledif=0 ql2xenablehba_err_chk=0
   Back up existing initramfs:  cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
   Rebuild initramfs:  dracut -f -v
   Verify that /etc/modprobe.d/qla2xxx.conf is the same as the one in initramfs (time and size should be the same):     lsinitrd | grep qla2xxx.conf; ls -al /etc/modprobe.d/qla2xxx.conf
    
por 16.01.2017 / 22:11
3

Este é um servidor HP ProLiant DL380 Gen9 . Servidor de classe empresarial bastante padrão.

Você pode me fornecer informações sobre a revisão de firmware do servidor?
O EMC PowerPath está realmente instalado? Em caso afirmativo, consulte aqui .

Você tem os Agentes de Gerenciamento da HP instalados? Em caso afirmativo, você tem a capacidade de postar a saída de hplog -v .

Você viu alguma coisa no log do ILO4? A OIT é acessível?

Você pode descrever todas as placas PCIe instaladas nos slots do sistema?

Para ajuste específico do RHEL6, eu recomendo altamente o XFS, executando tuned-adm profile enterprise-storage e garantindo que seus sistemas de arquivos sejam montados nobarrier ( o perfil ajustado deve lidar com isso ).

Para os volumes, verifique se você está usando os dispositivos dm (multipath) em vez de /dev/sdX . Veja: link

Olhando o que você apresentou até agora e o cheque listado no site de suporte do Redhat (e o descrição aqui ), não posso descartar o potencial para problemas de falha de HBA ou PCIe riser. Além disso, há uma pequena possibilidade de que haja um problema no lado do VMAX.

Você pode trocar slots PCIe e tentar novamente? Você pode trocar cartas e tentar novamente?

O firmware está na corrente do HBA? Este é o pacote mais recente de Dezembro de 2016 .

Firmware 6.07.02 BIOS 3.21

A DID_ERROR typically indicates the driver software detected some type of hardware error via an anomaly within the returned data from the HBA.

A hardware or san-based issue is present within the storage subsystem such that received fibre channel response frames contain invalid or conflicting information that the driver is not able to use or reconcile.

Please review the systems hardware, switch error counters, etc. to see if there is any indication of where the issue might lie. The most likely candidate is the HBA itself.

    
por 05.01.2017 / 15:01
2

Isso me parece que um de seus SFPs falhou soft ... Procure no seu switch de armazenamento por erros na porta enquanto você está fazendo uma cópia grande.

Eu tive um problema semelhante recentemente, onde tudo parecia ótimo. O fornecedor de servidores concordou com o material, o fornecedor de armazenamento disse que o material ficou bom, jurou que os SFPs estão bem ... O SFP ainda estava ativo e funcional, até grandes quantidades de dados serem enviados pela interface do MPIO e muitos erros no sistema. porta do switch de armazenamento começaria a ser registrada.

Eu tive que substituir todos os cabos de fibra por novos e, em seguida, trocar os SFPs por peças de reposição que eu tinha disponível para provar ao fornecedor que o SFP estava ruim, mesmo que parecesse bem.

    
por 06.01.2017 / 00:20
1

Eu sei que se você mudar em / etc / sysconfig / mkinitrd / multipath MULTIPATH = NÃO em MULTIPATH = YES e no arquivo /etc/multipath.conf - comentário a seguir:

lista negra {devnode "*"}

Ativar carregamento automático:

chkconfig multipathd em

Ativar o download do módulo:

modprobe dm-multipath

modprobe dm-round-robin

Em autocfg:

multipath -v2

Recarregue o servidor, cheeking all up:

lsmod | grep dm _

assistindo a vários caminhos:

multipath -ll

    
por 05.01.2017 / 12:50