Voir aussi : https://access.redhat.com/solutions/137073
Variables importantes :
/sys/block/<path>/device/timeout)/sys/class/fc_remote_ports/rport-<id>/fast_io_fail_tmo)/sys/class/fc_remote_ports/rport-<id>/dev_loss_tmo8:1:5:0 sdk 8:160 active ready running
`- host:channel:id:lun devnode major:minor dm_status_if_known path_status online_status
Cela signifie :
Exemple fichier multipath.conf :
blacklist {
device {
vendor ".*"
product ".*"
}
}
blacklist_exceptions {
device {
vendor "3PARdata"
product "VV"
}
}
defaults {
max_polling_interval 10
polling_interval 5
checker_timeout 15
}
devices {
device {
vendor "3PARdata"
product "VV"
path_grouping_policy "group_by_prio"
uid_attribute "ID_SERIAL"
prio "alua"
#path_selector "round-robin 0"
path_selector "service-time 0"
path_checker "tur"
hardware_handler "1 alua"
failback "immediate"
rr_weight "uniform"
rr_min_io_rq 1
fast_io_fail_tmo 10 # IO 10s en queue avant path failed (avec no_path_retry à 0)
dev_loss_tmo 14 #Prendra la valeur 14 avec no_path_retry à 0 ou 180 avec no_path_retry à 36 ou infini avec no_path_retry à queue
#no_path_retry "queue" #Sans mirroir / Sans Pacemaker => IO bloqués jusqu'à ce que le SAN redevienne opérationnel
no_path_retry 36 #En mirroir sans pacemaker : 18 x polling_interval + max_polling_interval => soit environ 180s (la préco d'HP est de 18 avec un polling_interval à 10, j'ai divisé par 2 le polling_interval et multiplié par 2 le no_path_retry, ce qui a pour conséquence de mettre le dev_loss_tmo à 180 dans les 2 cas)
#no_path_retry 0 #En mirroir avec Pacemaker
}
}
multipaths {
multipath {
wwid WWID_LUN
alias MON_ALIAS
}
}