Корневые файловые системы 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.
Точный симптом заключается в том, что в качестве корня, как работает touch /test возвращает ошибку "файловая система только для чтения". Тем не менее, выход mount показывает это как смонтированный чтение-запись. Разумеется, все другие операции ввода-вывода в domU также не выполняются в данный момент, поэтому аппарат выходит из строя. Просто перезапустите его xm из Dom0 даже без повторного подключения сеанса 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.
4 ответа
В конце концов я решил эту проблему, используя следующие рекомендации и настройки из документации 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 только в однопользовательском режиме.
Установка таким способом может предотвратить появление ошибки в описанной выше ситуации в сочетании с другими предложениями.