Корневые файловые системы Xen DomU становятся доступными только для чтения при отработке отказа виртуального IP-адреса iSCSI

Мои серверы Xen - openSUSE 11.1 с open-iscsi для нашего кластера iSCSI SAN. Модули SAN находятся в группе аварийного переключения IP за виртуальным IP, к которому подключаются инициаторы.

В случае, если основной сервер SAN выходит из строя, дополнительный выбирает роль выступающей в качестве цели. Все это обрабатывается программным обеспечением LeftHand SAN / iQ и хорошо работает в большинстве ситуаций.

У меня проблема в том, что иногда некоторые из моих Xen DomU имеют корневую файловую систему, доступную только для чтения, после восстановления IP-адреса. Это не соответствует и происходит с другим подмножеством каждый раз, когда происходит аварийное переключение. Все они используют один и тот же образ программного обеспечения openSUSE 11.1.

Корневые файловые системы для каждого DomU монтируются open-iscsi в Dom0, а затем Xen использует стандартный драйвер блочного устройства для предоставления его DomU.

Точный симптом заключается в том, что в качестве пользователя root при запуске touch /testвозвращает ошибку «файловая система только для чтения». Тем не менее, вывод mountпоказывает, что он смонтирован для чтения и записи. Разумеется, все другие операции ввода-вывода в domU также в данный момент не выполняются, поэтому аппарат выходит из строя. Простой перезапуск с xmDom0 без повторного подключения сеанса iSCSI заставляет все работать снова.

На стороне Dom0 сообщения системного журнала во время переключения при сбое выглядят примерно так:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Мне трудно понять, на каком уровне отлаживать эту проблему, это что-то в ядре DomU? или на уровне Dom0 или Xen? Я думаю, что где-то есть параметр, который нужно настроить, чтобы увеличить время ожидания, но я не уверен, где искать.

Я не думаю, что это проблема open-iscsi просто потому, что подключенное блочное устройство все еще доступно для чтения и записи из Dom0.

В конце концов я решил эту проблему, используя следующие рекомендации и настройки из документации open-iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

После настройки подключения к каждому LUN, как описано выше, аварийное переключение работает как чудо, даже если это занимает несколько минут.

Это звучит как проблема с инициатором iSCSI, работающим на dom0. Инициатор не должен посылать сбои SCSI вверх по стеку так быстро. Возможно, вы захотите установить ConnFailTimeout в iscsi.conf. Это параметр, который определяет, как долго он будет считать ошибку сбоя соединения ошибкой и отправит эту ошибку в стек SCSI.

Я бы также посмотрел, сколько времени на самом деле занимает отказоустойчивость, а может и дольше, чем вы ожидаете. Если это так, возможно, аварийное переключение VIP занимает слишком много времени из-за проблем, связанных с ARP.

Есть ли в dom0 какие-либо сообщения, указывающие на какие-либо ошибки чтения / записи или ошибки scsi во время аварийного переключения? Если это так, похоже, что эта ошибка записи передается в domU. DOMU не «знает», что это устройство iSCSI, поэтому он ведет себя так, как будто основной диск ушел и перемонтирует файловую систему только для чтения (см. Man-страницу mount (1) - errors=continue / errors=remount-ro / errors=panic)

С точки зрения dom0, он не будет изменен на «только для чтения» - это поведение только для чтения - семантическая файловая система, а не семантика блочного устройства.

Вы упоминаете, что «все другие операции ввода-вывода не выполняются» - вы имеете в виду domU или dom0?

Обычно при настройке решения HA iSCSI я использую многолучевое распространение, а не захват виртуального IP-адреса - это обеспечивает лучшую видимость для хоста, и у вас нет сеанса iSCSI, внезапно исчезающего, а затем нуждающегося в перезапуске - он всегда есть, их всего два , Это вариант в этой среде?

Хм ... Часть проблемы также в том, что вы не работаете / как RO. Наилучшие рекомендации по безопасности говорят о том, что у вас должен быть смонтирован символ "/" ro, и что любые файловые системы, которым требуется rw, должны быть смонтированы отдельно (т. Е. / Var и / tmp). Если в каталоге / etc есть каталоги, в которые нужно записать данные, они должны быть перемещены в / var / etc / path и связаны с / etc.

«/» следует монтировать RW только в однопользовательском режиме.

Установка таким способом может предотвратить появление ошибки в описанной выше ситуации в сочетании с другими предложениями.