Вопросы Теги

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

Я также имею:

  • коврик для мыши
  • перо
  • PostITs
  • Термоизолированная чашка чая
9
задан 24 June 2009 в 10:02
4 ответа

Я в конечном счете решил это при помощи следующего совета и настроек из открытой-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, как описано выше, обработка отказа работает как очарование, даже если требуется несколько минут для случая.

6
ответ дан 2 December 2019 в 22:35
  • 1
    У меня была та же проблема с дб напоминания mysql, находящимся на iscsi объеме с теми же ошибками в/var/log/messages и файловой системе, находящейся в режиме только для чтения. Эта подсказка решила проблему. –  RainDoctor 10 April 2010 в 07:52

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

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

Вы упоминаете, что "весь другой ввод-вывод перестал работать" в это время - Вы имеете в виду domU или dom0?

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

0
ответ дан 2 December 2019 в 22:35
  • 1
    Обновленный исходное описание с ответами на Ваши вопросы. Я предполагаю, что мог заглянуть к мультисоединению каналом вместо этого, но система более приспособлена для виртуальной обработки отказа IP в ее текущей форме. I' m не уверенный, как репликация блочного уровня вошла бы для проигрывания с мультисоединением каналом, тем более, что одна из единиц SAN должна определяться ведущее устройство. Спасибо за указание на меня к части о файловой системе. Я думаю, что в значительной степени объясняет это. Я предполагаю, что мог попытаться переключить его на ' continue' режим, или возможно смотрят на изменение файловой системы к чему-то более эластичному как XFS. –  Kamil Kisiel 24 June 2009 в 10:11
  • 2
    Там isn' t что-либо по сути плохо о ext3 - you' ll имеют подобные проблемы с XFS. И я wouldn' t рекомендуют использовать onerror=continue - система будет полагать, что блок нечитабелен и you' ll теряют данные. Мультисоединение каналом не зеркально отражает - Вы don' t должен волноваться о любой репликации на хосте. Вы просто соединились бы через iSCSI и с ведущим устройством и со вторичными целями, и хост знал бы это, если бы ведущее устройство перестало работать, чтобы не передать ошибку стек, но попробовать ту же команду, направленную на вторичную цель. –  MikeyB 24 June 2009 в 21:02
  • 3
    Мой комментарий по поводу репликации расценивал то, что два сервера SAN должны синхронизировать свои данные. Внутренне я думаю, что система работает так же к drbd с одной из единиц (тот, который в настоящее время имеет VIP), быть ведущим устройством. Это могло бы работать с мультисоединением каналом, но I' d действительно любят решать эту проблему, не переключаясь далеко от текущей архитектуры. Должен быть способ сделать эту работу иначе, мои системы, которые непосредственно монтируются, объемы iSCSI никогда не имеют проблему с объемом, становящимся только для чтения. –  Kamil Kisiel 3 July 2009 в 02:19

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

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

2
ответ дан 2 December 2019 в 22:35

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

"/" должен только быть смонтирован RW в однопользовательском режиме.

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

-1
ответ дан 2 December 2019 в 22:35

Теги

Похожие вопросы