У нас есть сервер на базе CentOS 6.4, подключенный к хранилищу Hitachi HNAS 3080, и мы наблюдали, как ядро перемонтировало файловую систему в режиме только для чтения:
16 мая 07:31:03 GNS3-SRV-CMP-001 ядро: [1259725.675814] EXT3-fs (dm-1): ошибка: перемонтирование файловой системы только для чтения
Это произошло после нескольких ошибок ввода-вывода и отказа всех путей к устройству:
16 мая 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: оставшиеся активные пути: 0
Я просматривал журналы sar и вижу несколько очень больших (2 секунды) времени ожидания:
07:40:00 dev8-0 17.91 112.04 98.03 11.73 0.00 0.20 0.07 0.12
07:40:00 dev8-16 0.23 1.85 0.00 8.00 0.00 3.71 3.71 0.09
07:40:00 dev8-32 91.50 8338.76 5292.93 148.98 8.38 91.60 9.76 89.35
07:40:00 dev252-0 91.27 8336.91 5292.93 149.34 17.79 194.88 9.79 89.38
07:40:00 dev252-1 674.80 8168.16 5292.93 19.95 1473.53 2183.60 1.32 88.98
Время между 07: 30: 00-07: 40: 00 действительно происходит в то время, когда файловая система смонтирована только для чтения. Однако даже в нормальных условиях одно повторяющееся наблюдение состоит в том, что время ожидания для нижележащих устройств намного меньше, чем у многолучевого устройства. Например:
00:00:00 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
00:10:00 dev8-0 19.27 129.41 78.61 10.80 0.01 0.27 0.16 0.32
00:10:00 dev8-16 0.23 1.80 0.00 8.00 0.00 0.86 0.84 0.02
00:10:00 dev8-32 94.88 10285.16 3363.48 143.86 3.39 35.76 6.83 64.82
00:10:00 dev252-0 94.65 10283.34 3363.48 144.18 3.64 38.47 6.86 64.89
00:10:00 dev252-1 435.06 10087.12 3363.48 30.92 118.42 272.21 1.47 64.12
dev8-0 оказывается локальным диском, а dev8-16 (/dev/sdb) и dev8-32 (/dev/sdc) являются базовыми для dev252-0 (/dev/mapper/mpatha). dev252-1 (/dev/mapper/mpathap1) является одним разделом, охватывающим все многопутевое устройство. Вот вывод из multipath -ll:
mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
`- 8:0:0:0 sdb 8:16 active ready running
Зачем нужно ждать /dev/mapper/mpathap1 быть намного выше, чем у /dev/mapper/mpatha или даже /dev/sdb или /dev/sdc?
Как предполагает пользователь the-wabbit, происходит объединение запросов. Вы можете видеть, что в столбце avgrq-sz средний размер запроса, который показывает значительное увеличение.
Теперь «ожидание» - это время, проведенное в очереди, плюс время, потраченное на обслуживание этих запросов. Если небольшой запрос, назовем его 'x', объединяется с парой других запросов (y и z, выданных после x), то x будет
Это, очевидно, окажет негативное влияние на статистику ожидания, в основном из-за способа вычисления ожидания, но не означает, что проблема сама по себе.
Теперь посмотрим на / dev / sdb (dev8-16). Вы знали, что не идете по этому пути? В вашей конфигурации multipath есть две группы приоритета, одна из которых
status=enabled
и дальше
status=active
У тебя наверное есть
path_grouping_policy failover
в вашей конфигурации (по умолчанию).
Если вы хотите предотвратить ошибки ввода-вывода в случае, если оба пути не работают, вы можете попробовать:
features "1 queue_if_no_path"in your multipath.conf
Остается вопрос: почему оба пути идут вниз?