Como ler o estado do multipath num host Linux

Se o seu servidor guarda os dados numa SAN, o relatório de saúde mais importante da máquina vem de um comando que a maioria das pessoas nunca executa. O multipath -ll diz-lhe quantos caminhos levam ao seu disco, quais deles o array prefere e se o host sobreviveria se perdesse um. É assim que se lê, e é isto que se muda quando não parece bem.

Redundância que não se vê não é redundância

Quando um path morre em silêncio, ninguém repara. O host continua a correr com o que resta, e o primeiro sinal de problema é o dia em que o segundo path se vai e o volume desaparece debaixo de uma base de dados. Um servidor entregue com o dispositivo multipath montado e nunca mais revisto só tem redundância no papel. A verificação demora trinta segundos e deve fazer parte de cada build, de cada manutenção e de cada revisão de incidente.

Ler a saída, linha a linha

Um exemplo genérico de um host com duas portas HBA e duas portas de array com zoning por fabric:

mpatha (360002ac000000000000000000000abcd) dm-2 3PARdata,VV
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 1:0:0:1 sdb 8:16 active ready running
  |- 1:0:1:1 sdc 8:32 active ready running
  |- 2:0:0:1 sdd 8:48 active ready running
  `- 2:0:1:1 sde 8:64 active ready running

A primeira linha dá o nome amigável, o WWID e as strings de vendor e de produto. O WWID é a identidade do volume tal como o array a reporta. Se alguma vez precisar de provar que volume do array corresponde a que dispositivo Linux, compare esta string com a listagem de volumes do próprio array, nunca com uma letra de dispositivo, porque as letras de dispositivo mudam entre arranques.

A segunda linha guarda as definições que decidem o comportamento em caso de falha. queue_if_no_path significa que, se todos os paths se perderem, o I/O espera em vez de falhar. hwhandler='1 alua' significa que o array fala ALUA, a forma padrão de um array dizer ao host que portas são preferidas.

A linha do path group mostra a política de seleção e a prioridade. Um array simétrico active/active como o acima coloca todos os paths num só grupo com prioridade igual. Um array assimétrico mostra dois grupos: um grupo de prioridade mais alta com paths otimizados marcados active, e um grupo de prioridade mais baixa marcado enabled que só transporta I/O se o primeiro grupo falhar. Ambas as disposições são saudáveis. O que importa é que a disposição corresponda ao que o fabricante do seu array documenta para o seu tipo de host.

Cada linha de path lê-se host:channel:target:lun, depois o dispositivo, depois três estados. O primeiro número é o SCSI host, que num servidor Fibre Channel significa a porta HBA. Todos os volumes devem mostrar paths através de ambos os números de porta HBA. Se todos os paths de um volume partilham o mesmo número de host, esse volume só é alcançável através de um fabric, diga o diagrama de cablagem o que disser. Os três estados são o estado do device-mapper (active ou failed), o resultado do path checker (ready, faulty, ghost) e a visão que o kernel tem do dispositivo (running ou offline).

Um host saudável, em forma de lista de verificação

• Todos os volumes mostram o mesmo número de paths, e esse número é igual a portas HBA vezes portas de array com zoning por fabric.
• Todos os volumes têm paths através de ambos os números de host das HBA.
• Nenhum path está failed, faulty, offline ou shaky.
• A string de vendor, o hardware handler e as prioridades correspondem ao guia de host do fabricante do array, e o host está registado no array com o host persona ou host type correspondente.
• O comportamento quando todos os paths se perdem (no_path_retry) foi escolhido de propósito, não herdado.
• O LVM usa apenas os dispositivos multipath, nunca os paths sd subjacentes.

Estes comandos dão-lhe a imagem completa:

multipath -ll
multipathd show paths
multipathd show maps status
cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

Para contar os paths vivos por volume de uma só vez:

multipath -ll | awk '/ dm-/{m=$1} /active ready/{c[m]++} END{for (k in c) print k, c[k]}'

Execute-o após cada alteração de zoning, cada alteração no array e cada reinício. Uma contagem que difere entre volumes merece ser investigada hoje.

As definições que mais importam

A maior parte das distribuições traz uma tabela interna razoável de predefinições por array, mas o guia de host do fabricante do array é a autoridade. Uma secção device típica tem este aspeto:

defaults {
    user_friendly_names yes
    find_multipaths yes
}
devices {
    device {
        vendor               "3PARdata"
        product              "VV"
        path_grouping_policy group_by_prio
        prio                 alua
        hardware_handler     "1 alua"
        path_checker         tur
        failback             immediate
        no_path_retry        18
    }
}

O único valor que vale a pena pensar por si próprio é o no_path_retry. Fazer queueing durante algum tempo permite a um host atravessar um failover de controlador ou um reinício do fabric sem que um erro de I/O chegue à aplicação. Fazer queueing para sempre pode congelar um host de base de dados de uma forma mais difícil de recuperar do que uma falha limpa. Escolha um número de tentativas que cubra, com margem, o tempo de failover documentado do seu array, escreva porquê, e aplique-o a todos os hosts desse tipo.

O outro problema clássico é o LVM analisar os paths em bruto e queixar-se de physical volumes duplicados. Em sistemas atuais, a lista de dispositivos (lvmdevices) ou um filtro no lvm.conf que aceite apenas dispositivos /dev/mapper resolve a questão. Os avisos de PV duplicados não são cosméticos: significam que o LVM pode abrir um único path em vez do dispositivo multipath, e nesse caso deixa de estar protegido.

Prove o failover antes de precisar dele

Um path que nunca fez failover é uma teoria. Antes de um host levar produção, retire um path e observe:

# terminal 1: keep reading from the volume
dd if=/dev/mapper/mpatha of=/dev/null bs=1M iflag=direct status=progress

# terminal 2: take one path offline, watch, then bring it back
echo offline > /sys/block/sdb/device/state
multipathd show paths
echo running > /sys/block/sdb/device/state
journalctl -k -f

A leitura no primeiro terminal deve continuar sem parar mais do que um instante. Quando o path regressar, o multipathd show paths deve devolvê-lo a active ready. Depois faça o teste maior, o que conta: desative a porta do host num dos fabrics, no switch, confirme que o volume corre apenas com o outro fabric, reponha-a, confirme que todos os paths regressam, e repita para o segundo fabric. Se algum passo o surpreender, encontrou o problema numa tarde sossegada em vez de durante uma indisponibilidade.

Como o fazemos

Na nossa plataforma, cada host ligado à SAN, hypervisor ou dedicated server, recebe uma porta HBA em cada um de dois fabrics Fibre Channel independentes e é registado nos nossos arrays HPE 3PAR all-flash com o persona que faz o ALUA comportar-se exatamente como o seu sistema operativo espera. Quando movemos um volume em produção entre arrays, o host faz rescan, vê os seus novos paths e continua, e a contagem de paths é a prova de que a mudança está concluída.

Se a saída do seu multipath não se parece com o exemplo saudável acima, ou se não tem a certeza de como a sua deveria ser, teremos todo o gosto em lê-la consigo.

cta: Fale com um engenheiro

Related

• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/fibre-channel-fabrics/
• /what-we-do/storage-compute/bare-metal-servers/