Come leggere lo stato multipath su un host Linux

Se il vostro server tiene i dati su una SAN, il rapporto di salute più importante della macchina arriva da un comando che la maggior parte delle persone non esegue mai. multipath -ll vi dice quante strade portano al vostro disco, quali di esse l'array preferisce, e se l'host sopravvivrebbe alla perdita di una. Ecco come leggerlo, e cosa cambiare quando sembra sbagliato.

Una ridondanza che non vedete non è ridondanza

Quando un percorso muore in silenzio, nessuno se ne accorge. L'host continua a funzionare con ciò che resta, e il primo segno di guai è il giorno in cui cade il secondo percorso e il volume sparisce da sotto un database. Un server consegnato con il dispositivo multipath montato e mai più guardato ha una ridondanza solo sulla carta. Il controllo richiede trenta secondi e dovrebbe far parte di ogni build, di ogni manutenzione e di ogni revisione di incidente.

Leggere l'output, riga per riga

Ecco un esempio generico da un host con due porte HBA e due porte array zonate per 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

La prima riga dà il nome amichevole, il WWID e le stringhe di vendor e prodotto. Il WWID è l'identità del volume così come la riporta l'array. Se mai doveste dimostrare quale volume dell'array corrisponde a quale dispositivo Linux, confrontate questa stringa con l'elenco dei volumi dell'array, mai con una lettera di dispositivo, perché le lettere cambiano tra un boot e l'altro.

La seconda riga contiene le impostazioni che decidono il comportamento in caso di guasto. queue_if_no_path significa che, se tutti i percorsi vanno persi, l'I/O attende invece di fallire. hwhandler='1 alua' significa che l'array parla ALUA, il modo standard con cui un array dice all'host quali porte sono preferite.

La riga del path group mostra la policy di selezione e la priorità. Un array simmetrico active/active come quello sopra mette ogni percorso in un unico gruppo con priorità uguale. Un array asimmetrico mostra due gruppi: uno a priorità più alta con i percorsi ottimizzati marcati active, e uno a priorità più bassa marcato enabled che porta I/O solo se il primo gruppo fallisce. Entrambe le disposizioni sono sane. Ciò che conta è che la disposizione corrisponda a quanto documenta il vostro vendor di storage per il vostro tipo di host.

Ogni riga di percorso si legge host:channel:target:lun, poi il dispositivo, poi tre stati. Il primo numero è lo SCSI host, che su un server Fibre Channel è la porta HBA. Ogni volume dovrebbe mostrare percorsi attraverso entrambi i numeri di porta HBA. Se tutti i percorsi di un volume condividono un solo numero di host, quel volume è raggiungibile attraverso un solo fabric, qualunque cosa dica lo schema di cablaggio. I tre stati sono lo stato del device-mapper (active o failed), il risultato del path checker (ready, faulty, ghost) e la vista del kernel sul dispositivo (running o offline).

Un host sano, come checklist

• Ogni volume mostra lo stesso numero di percorsi, e quel numero è pari a porte HBA per porte array zonate per fabric.
• Ogni volume ha percorsi attraverso entrambi i numeri di host HBA.
• Nessun percorso è failed, faulty, offline o shaky.
• La stringa del vendor, l'hardware handler e le priorità corrispondono alla guida host del vostro vendor di storage, e l'host è registrato sull'array con la persona o il tipo di host corrispondente.
• Il comportamento alla perdita di tutti i percorsi (no_path_retry) è stato scelto di proposito, non ereditato.
• LVM usa solo i dispositivi multipath, mai i percorsi sd sottostanti.

Questi comandi vi danno il quadro completo:

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

Per contare i percorsi vivi per volume in un colpo solo:

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

Eseguitelo dopo ogni modifica di zoning, ogni modifica all'array e ogni riavvio. Un conteggio che differisce tra volumi vale la pena inseguirlo oggi.

Le impostazioni che contano di più

La maggior parte delle distribuzioni fornisce una tabella integrata ragionevole di default per array, ma la guida host del vendor di storage è l'autorità. Una tipica sezione device appare così:

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

L'unico valore su cui vale la pena ragionare da soli è no_path_retry. Accodare per un po' permette a un host di attraversare un failover del controller o un riavvio del fabric senza che un errore di I/O arrivi all'applicazione. Accodare per sempre può congelare un host database in un modo più difficile da recuperare di un fallimento pulito. Scegliete un numero di tentativi che copra il tempo di failover documentato del vostro array con margine, scrivete il perché, e applicatelo a ogni host di quel tipo.

L'altro problema classico è LVM che scansiona i percorsi grezzi e si lamenta di physical volume duplicati. Sui sistemi attuali la lista dei dispositivi (lvmdevices) o un filtro in lvm.conf che accetta solo dispositivi /dev/mapper lo sistema. Gli avvisi di PV duplicati non sono cosmetici: significano che LVM potrebbe aprire un singolo percorso invece del dispositivo multipath, e a quel punto non è più protetto.

Dimostrate il failover prima di averne bisogno

Un percorso che non ha mai fatto failover è una teoria. Prima che un host porti produzione, togliete un percorso e osservate:

# 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

La lettura nel primo terminale dovrebbe proseguire senza fermarsi più di un istante. Quando il percorso torna, multipathd show paths dovrebbe riportarlo ad active ready. Poi fate il test più grande che conta: disabilitate la porta dell'host su un fabric allo switch, confermate che il volume gira solo sull'altro fabric, ripristinatela, confermate che ogni percorso torna, e ripetete per il secondo fabric. Se un passo vi sorprende, avete trovato il problema in un pomeriggio tranquillo invece che durante un'interruzione.

Come lo facciamo noi

Sulla nostra piattaforma ogni host collegato alla SAN, hypervisor o server dedicato, riceve una porta HBA in ciascuno di due fabric Fibre Channel indipendenti ed è registrato sui nostri array all-flash HPE 3PAR con la persona che fa comportare ALUA esattamente come il suo sistema operativo si aspetta. Quando spostiamo un volume dal vivo tra array, l'host riesegue la scansione, vede i nuovi percorsi e prosegue, e il conteggio dei percorsi è la prova che lo spostamento è completo.

Se il vostro output multipath non somiglia all'esempio sano qui sopra, o non siete sicuri di come dovrebbe essere il vostro, siamo lieti di leggerlo insieme a voi.

cta: Parla con un ingegnere

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/