Кореневі файлові системи Xen DomU стають доступними лише для читання у віртуальних відмовах IP iSI

Мої сервери 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 також виходять з ладу, тому машина важко падає. Просто перезапустивши його з 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.

Я врешті-решт вирішив це за допомогою наступних порад та налаштувань із документації на відкриту 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, тому він веде себе так, ніби базовий диск відійшов і переглянув файлову систему лише для читання (див. Manpage (1) manpage - 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 тільки в режимі одного користувача.

Налаштування таким чином може запобігти сегментації у вищезгаданій ситуації у поєднанні з іншими пропозиціями.