Мои серверы 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.
В конце концов я решил эту проблему, используя следующие советы и настройки из документации 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, поэтому он ведет себя так, как если бы базовый диск исчез и перемонтировал файловую систему в режиме только для чтения (см. Справочную страницу mount (1) - errors=continue / errors=remount-ro / errors=panic)
С точки зрения dom0, он не станет доступным только для чтения - это поведение только для чтения является семантикой файловой системы, а не семантикой блочного устройства.
Вы упомянули, что «все остальные операции ввода-вывода не работают» - вы имеете в виду domU или dom0?
Обычно при настройке решения HA iSCSI я использую множественный путь, а не виртуальный захват IP - это обеспечивает большую видимость для хоста, и у вас нет сеанса iSCSI, который внезапно исчезает, а затем его нужно перезапускать - он всегда там, их всего два . Это вариант в этой среде?
Гм ... Отчасти проблема в том, что вы не работаете / как РО. Рекомендации по безопасности гласят, что у вас должен быть смонтирован "/" ro, и что любые файловые системы, которым требуется rw, должны монтироваться отдельно (например, / var и / tmp). Если в / etc есть каталоги, в которые нужно писать, их следует переместить в / var / etc / path и связать с / etc.
"/" следует монтировать как RW только в однопользовательском режиме.
Такая настройка может предотвратить segfault в вышеуказанной ситуации в сочетании с другими предложениями.