Здрасти пак от мен...
Джиткам си аз из мултипатинга тая събота и си мисля, чакай да разгледам малко кода ( OpenSource overrated... )
И си направих следата карта на пачнатата от Ред Хат версия 0.4.9-64.0.6.
( Не е много ясна... ама не съм dev )
------------------------ MULTIPATHD - USERSPACE LEVEL ----------------------
Source file: multipathd/main.c
Routine check_path:
Calls get_state
if new state differs from old state:
Print the message for the patch checker ( why there is a change? )
If the new state is "OFFLINE":
Tell device-mapper to mark the path as failed
If the new state is "ONLINE"
Tell device-mapper to mark the path as up
If there was not change it the path status:
If state is ONLINE:
Double the time for the next_check until it reaches max_checkint(4*time)
If state is OFFLINE;
Put in the log the report from the patch checker
Calls update_prio - to update path priority.
Updates priority groups
If failover is required and configured in multipath.conf, it is performed.
Routine update_prio:
If all paths in the priority group should be updated:
#This is done only when a new path is up.
Call pathinfo for each path in the priority group of the provided path
Call pathinfo for the provided path.
pathinfo(pp, conf->hwtable, DI_PRIO);
Source file: libmultipath/discovery.c
Routine: get_state:
if there is no assigned checker for the path:
Initialize checker
if no checker_timeout has been configured in multipath.conf:
Sets checker timeout to the SCSI timeout for the particular device.
Calls checker_check routine
Routine: pathinfo:
Fetches information about the provided path from sysfs
If priority grouping policy is used and the path is up or its priority is unknown:
#Means that we will try to get the priority of a path even if it is down.
Call get_prio
Routine get_prio:
if path is down(path_offline(pp) == PATH_DOWN), return failure
If there is no priority callout, then select one
Call prio_getprio with corresponing priority_callout: prio_getprio(pp->prio, pp);
Source file: cat libmultipath/prio.c
Routine: add_prio
Initialize priority callout object
Resolve rouines from library
Routine: prio_getprio:
Calls library routine getprio
Source file: libmultipath/checkers.c
Routine: add_checker:
Creates a structure for the checker object
Resolves routines from library
Routine checker_check:
Calls library routine libcheck_check
Source file: libmultipath/checkers/tur.c
Routine: libcheck_check:
Checks if checker supports sync or async mode
if sync:
Calls tur_check
Returns path status
if async:
Checks if thread is still running
if yes:
return the path status
if no:
Set-up new thread
Assign thread completition time = checker_timeout
New thread calls tur_check
Routine: tur_check:
Does TEST UNIT READY SPC3 command ( SCSI Timeout = checker_timeout ) Returns path status
Source file: libmultipath/prioritizers/alua.c
Routine: getprio
Calls get_target_port_group_support
Calls get_target_port_group
Calls get_asymmetric_access_state
Analyses the output
Source file: libmultipath/prioritizers/alua_rtpg.c
Routine do_inquiry
Timeout ( 300s - as coded ) ioctl(fd, SG_IO, &hdr)
Routine do_rtpg
Timeout ( 300s - as coded ) ioctl(fd, SG_IO, &hdr)
Интересно е че multipathd проверява пътищата асинхронно (процедура check_path в main.c ). Т.е. не би трябвало да блокира заради tur.
С patch-ове RHBZ-725541-01-async-tur-checker.patch и RHBZ-565933-checker-timeout.patch би трябвало хората да са си решили проблема
Обаче май не баш...
checkerloop в main.c вика check_path, което в случая когато имаме ALUA вика и path_info, което може да блокира и то още как! Защото scsi timeout е коднат на 300s и не може да се промени.
От друга страна fast_io_tail_tmo е проактивна метрика ( която би ни спасила... ). Т.е. HBA ще я използва само когато сметне 4е нещо не е наред и се разлогне от отдалечения порт.
Но какво ще стане ако вместо загуби връзка с порта има performance проблем?
Примерно кредитите на DC интерконекта се изчерпят и имам по голямо latency на някой път... и опашките започнат да се пълнят...
Кофти е, че имам твърде малко хардуер за тестване.
Забравих да си задам въпроса:
Може ли някои който има Red Hat и EVA да го тества като ограничи iops-a? ( ако има един примерно 2 пътя, и направи със cgroup за единия от пътищата примерно 10iops, тогава би трябвало едно dd да блокира пътя, но multipathd няма да направи failover ). И двете ми машинки са доста важни за да си играя с тях
Или някой да погледне кода на multipathd да потвърди бъга?
Автор
Тема: Бавен фейловър (Прочетена 2820 пъти)