lpfc + multipath + ubuntu - o caminho continua mudando

Question

Estou tendo problemas ao configurar o multipath usando o Emulex (lpfc). Embora eu não detecte corrupção de dados, o administrador da SAN possui uma ferramenta que mostra que os caminhos estão sendo alternados a cada 20 segundos ou mais. Aqui estão os detalhes:

# multipath -l
san01 (3600a0b80002a042200002cb44a9a29ca) dm-2 IBM     ,1815      FASt
[size=100G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
 \_ 3:0:0:0 sdb 8:16  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 4:0:0:0 sdc 8:32  [active][undef]

Os vários caminhos estão conectados ao mesmo LUN.

# /lib/udev/scsi_id -g -u -d /dev/sdb
3600a0b80002a042200002cb44a9a29ca
# /lib/udev/scsi_id -g -u -d /dev/sdc
3600a0b80002a042200002cb44a9a29ca

Aqui está o /etc/multipath.conf

defaults {
        udev_dir                /dev
        polling_interval        5
        selector                "round-robin 0"
        path_grouping_policy    failover
        getuid_callout          "/lib/udev/scsi_id -g -u -d /dev/%n"
        path_checker            readsector
        failback                immediate
        user_friendly_names     yes
}
multipaths {
        multipath {
                wwid    3600a0b80002a042200002cb44a9a29ca
                alias   san01
        }
}

fdisk -l

Disk /dev/sdb: 107.3 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x61b4bf95

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       13054   104856223+  83  Linux

Disk /dev/sdc: 107.3 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x61b4bf95

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       13054   104856223+  83  Linux

Eu aumentei a verbosidade do lpfc e agora recebo o seguinte no dmesg:

[ 2519.241119] lpfc 0000:07:00.0: 1:0336 Rsp Ring 0 error: IOCB Data: xff000018 x37a120c0 x0 x0 xeb x0 x1b108db xa29b16
[ 2519.241124] lpfc 0000:07:00.0: 1:(0):0729 FCP cmd x12 failed <0/0> status: x1 result: xeb Data: x1b1 x8db
[ 2519.241127] lpfc 0000:07:00.0: 1:(0):0730 FCP command x12 failed: x0 SNS x0 x0 Data: x8 xeb x0 x0 x0
[ 2519.241130] lpfc 0000:07:00.0: 1:(0):0716 FCP Read Underrun, expected 254, residual 235 Data: xeb x12 x0
[ 2519.241275] lpfc 0000:07:00.0: 1:0336 Rsp Ring 0 error: IOCB Data: xff000018 x37a14c48 x0 x0 xd2 x0 x1b208e6 xa29b16
[ 2519.241279] lpfc 0000:07:00.0: 1:(0):0729 FCP cmd x12 failed <0/0> status: x1 result: xd2 Data: x1b2 x8e6
[ 2519.241283] lpfc 0000:07:00.0: 1:(0):0730 FCP command x12 failed: x0 SNS x0 x0 Data: x8 xd2 x0 x0 x0
[ 2519.241286] lpfc 0000:07:00.0: 1:(0):0716 FCP Read Underrun, expected 254, residual 210 Data: xd2 x12 x0

Alguém pode ver algo errado com essa configuração? Obrigado.

Com base nos comentários do janneb, mudei a configuração no multipath.conf para:

defaults {
        udev_dir                /dev
        polling_interval        5
        selector                "round-robin 0"
        path_grouping_policy    multibus
        getuid_callout          "/lib/udev/scsi_id -g -u -d /dev/%n"
        failback                immediate
        user_friendly_names     yes
}

O que agora dá:

san01 (3600a0b80002a042200002cb44a9a29ca) dm-2 IBM     ,1815      FASt
[size=100G][features=0][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 3:0:0:0 sdb 8:16  [active][ready]
 \_ 4:0:0:0 sdc 8:32  [active][ready]

Mas ainda fica [ativo] [undef] depois de um tempo, depois volta para [pronto].

Ah, eu só notei algo, quando eu executo 'multipath -l' eu recebo [undef], no entanto, se eu executar 'multipath -ll' eu fico [pronto].

-l     show the current multipath topology from information fetched in sysfs and the device mapper
-ll    show the current multipath topology from all available information (sysfs, the device mapper, path checkers ...)

A configuração está errada? Como posso depurar? Obrigado.

Obrigado janneb e zerolagtime por ajudarem.

Veja como isso se complica, achei que não precisaria explicar tudo isso, e atualmente estou me inclinando para a confusão na configuração de hardware.

Na verdade, existem dois servidores conectados ao mesmo LUN usando o FC. No nível do sistema operacional, apenas um servidor acessaria o sistema de arquivos (embora o mesmo LUN esteja exposto a ambos), já que ele é ext3 (não um sistema de arquivos de cluster). Se o servidor 1 cair, o servidor 2 entra em ação (linux-ha) e monta o sistema de arquivos.

Servidor 1 (multipath -ll):

san01 (3600a0b80002a042200002cb44a9a29ca) dm-2 IBM     ,1815      FASt
[size=100G][features=0][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 3:0:0:0 sdb 8:16  [active][ready]
 \_ 4:0:0:0 sdc 8:32  [active][ready]

Servidor 2 (multipath -ll):

san01 (3600a0b80002a042200002cb44a9a29ca) dm-2 IBM     ,1815      FASt
[size=100G][features=0][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 3:0:0:0 sdb 8:16  [active][ready]
 \_ 4:0:0:0 sdc 8:32  [active][ready

Nomes de portas do servidor 1:

# cat /sys/class/fc_host/host3/port_name 
0x10000000c96c5fdb
# cat /sys/class/fc_host/host4/port_name 
0x10000000c96c5df5
root@web-db-1:~# 

Nomes de portas do servidor 2:

#cat /sys/class/fc_host/host3/port_name 
0x10000000c97b0917
# cat /sys/class/fc_host/host4/port_name 
0x10000000c980a2d8

Esta configuração está errada? A maneira que o LUN está exposto a ambos os servidores está errada? Eu estou pensando que a conexão de hardware está incorreta, o que poderia estar errado? Poderia server1 path_checker interferir na operação do server2? Obrigado.

    

Answer 1

Sua configuração parece estranha; normalmente você teria 4 caminhos para o mesmo dispositivo (ou seja, 4 dispositivos / dev / sdX por dispositivo de múltiplos caminhos). O controlador de matriz normalmente é capaz de informar o host sobre a prioridade de cada caminho, portanto, você tem dois caminhos com prioridade mais alta e dois com prioridade mais baixa. Em seguida, dm-multipath multiplexa IO pelos dois caminhos de alta prioridade (a opção "seletor" com o padrão rr_min_io = 100). Agora, você tem dois grupos de caminho com a mesma prioridade, então talvez o dm-multipath esteja distribuindo IO sobre ambos, o que pode não ser o que o administrador da SAN deseja que você faça. Outra coisa estranha é que os dispositivos são marcados com "undef" ao invés de "prontos". Outra coisa estranha é que a numeração do seu caminho parece bem estranha (tudo segue pelo mesmo caminho?). Você realmente tem certeza de que tudo está devidamente conectado, devidamente zoneado, etc.?

Uma saída típica de "multipath -ll" deve se parecer com

sanarch3 (3600508b4000683de0000c00000a20000) dm-6 HP,HSV200
[size=2.0T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=100][active]
 \_ 0:0:0:5 sdc 8:32  [active][ready]
 \_ 1:0:0:5 sdk 8:160 [active][ready]
\_ round-robin 0 [prio=20][enabled]
 \_ 0:0:1:5 sdg 8:96  [active][ready]
 \_ 1:0:1:5 sdo 8:224 [active][ready]

Lá você vê 4 caminhos agrupados em 2 grupos de prioridade, e o IO é feito através de dispositivos sdc e sdk enquanto o sdg e o sdo estão ociosos e usados somente durante uma falha.

EDIT Portanto, o motivo pelo qual você deve ver 4 caminhos é que você tem 2 portas HBA e a matriz possui 2 controladores redundantes. Então você tem 2 redes redundantes com uma camada de switch final que fornece conexões de rede cruzada. Assim, ambos os HBAs veem os dois controladores, portanto, quatro caminhos para cada LUN. Você pode ver que no meu exemplo acima para a numeração de ID SCSI, que vai como [ID do controlador host]: [ID do canal]: [ID do controlador de destino]: [ID LUN]. O que você pode ver acima é que os caminhos ativos estão no controlador # 0, já que neste caso o controlador # 0 passa a "possuir" o LUN; O IO é possível através do outro controlador, mas com uma penalidade de desempenho, já que o outro controlador (dependendo da implementação do controlador) precisa encaminhar o IO ao controlador de propriedade. Portanto, o controlador informa que os caminhos que vão para o controlador # 0 têm maior prioridade.

Então, a partir da sua pergunta, vemos que não há caminho para o outro controlador. E, caso você não tenha controladores e redes redundantes, por que se preocupar com multipath em primeiro lugar?

    

Answer 2

As SANs da IBM geralmente têm exemplos de multipath.conf bem definidos em suas documentações, você não começou por aí? Deixarei essa parte como exercício para o leitor . Além disso, seu administrador de SAN lhe deve um pouco mais de suporte. Alguns pontos rápidos

• As oscilações de caminho, como você descreveu, são geralmente devido ao fato de o verificador de caminho não ter sido configurado, em suas duas iterações quando readsector0 para nenhum , o que provavelmente está levando o padrão multipath para aquele make e model, provavelmente tur (test unit ready).

• Nenhum verificador de prioridades definido, nenhum verificador de prioridades, sem prioridades.

• Provavelmente, é necessário um manipulador de hardware que esteja bem definido na documentação.

A melhor história de guerra da IBM em 1815 que encontrei foi esta , resumo:

• Instale o driver rdac, modprobe scsi_dh_rdac e adicione-o ao seu initrd
• Use o seguinte multipath.conf:

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^sda"
    device {
        vendor "Maxtor*"
        product "OneTouch*"
    }
}
blacklist_exceptions {
    device {
            vendor  "IBM"
            product "1815*"
    }
}
defaults {
    failback                immediate
    no_path_retry           queue
    user_friendly_names     no
    path_grouping_policy    failover
}
devices {
    device {
            vendor                  "IBM"
            product                 "1815*"
            failback                manual
            hardware_handler        "1 rdac"
            path_checker            rdac
            prio_callout            "/sbin/mpath_prio_rdac /dev/%n"
    }
}

Deixe-nos saber como isso acontece. Boa sorte!

    

Answer 3

Primeiro de tudo, você define multibus, tem certeza que o seu Storage suporta isso? Pergunte ao administrador da SAN se o seu armazenamento é realmente ativo / ativo, o armazenamento passivo ativo não permite alternar do controler o tempo todo, isso tem um custo para o armazenamento e também causará problemas no lado do cliente. Na primeira configuração, não foi definido na configuração, o que significa que você pega o config default no multipath (veja /usr/share/doc/mulitpath.conf.anotted) ou olha para a saída do multipathd -k show config para ter um melhor visão. (de qualquer maneira aleays rever a configuração padrão com suas especificações de armazenamento, porque eles não são sempre os melhores: eu tive algum problema com HDS et rhel)

A segunda coisa, você disse que nenhum problema de integridade no FS, tem certeza que seu FS está usando o dispositivo multipathed ??? Se eu assumir que você usa o LVM, você verificou as configurações do Filtro no lvm.conf? se isso não for bem definido, o lvm usará o dispositivo diretamente em vez de usar o MPIO, isso pode ser ainda mais um problema com o armazenamento ativo / passivo, já que o lvm forçará o uso de um controlador que pode não ser o preferido. .. Espero que ajude Considere