Назад | Перейти на главную страницу

iSCSI, аварийное переключение и XenServer

У меня есть настройка реализации отказоустойчивого iSCSI, поэтому, если один из моих модулей хранения выходит из строя, другой немедленно берет на себя управление (он также запускает общие ресурсы NFS). Когда происходит отработка отказа, тома экспортируются, IP-адрес переключается на другую машину, а целевые объекты меняются. Отработка отказа самой системы хранения работает нормально. Я использую NexentaStor в качестве фильтра.

Когда я выполняю тестовую (ручную) отработку отказа своего хранилища, происходит следующее:

Примечание: я запускаю виртуальную машину администратора на NFS и виртуальную машину клиента на iSCSI.

  1. Все виртуальные машины на базе NFS остаются включенными и отлично работают во время аварийного переключения и после него.
  2. Все виртуальные машины, работающие на iSCSI, в конечном итоге сообщают следующее:
    • Ошибка о невозможности записи в конкретный блок
    • Ошибка о том, что ведение журнала не работает
    • Затем файловая система переходит в RO

Чтобы виртуальная машина снова заработала, мне нужно сделать следующее:

  1. Принудительное отключение «сломанных» ВМ.
  2. Отсоедините iSCSI SR
  3. Повторно подключите iSCSI SR.
  4. Загрузите виртуальную машину на другом сервере (5 в моем пуле). Если я не загружаюсь на другом сервере, я получаю эту ошибку "Internal error: Failure("The VDI <uuid&gt; is already attached in RW mode; it can't be attached in RO mode!")" Единственный способ исправить эту ошибку, который я нашел, - это перезагрузить весь сервер, на котором он работал ранее, что, очевидно, является огромной проблемой.

В настоящее время многопутевый режим НЕ включен (но может быть и то же самое происходит). Я отредактировал большую часть файла /etc/iscsid.conf для работы с настройками тайм-аута, но безрезультатно.

Короче говоря, мое хранилище отключается правильно, но XenServer не поддерживает соединение. Как вы думаете, ошибка, которая появляется в пункте 4 выше, может быть основной причиной, и исправление, которое все исправит?

Любая помощь будет оценена больше, чем вы думаете.

У меня была очень похожая проблема с отказоустойчивым iSCSI. Он адресован в этот вопрос. Вы можете увидеть мое принятое решение, которое я обнаружил самостоятельно, чтобы узнать, как я его решил.

В основном это включало настройку

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.session.timeo.replacement_timeout = 86400

чтобы у сеанса iSCSI было достаточно времени для восстановления, прежде чем он сообщит об ошибках по цепочке ядру.

xe-toolstack-restart исправил это для меня.