Жахлива ситуація - файлові системи, змонтовані одночасно кількома незалежними екземплярами ОС

Як мені безпечно вийти з цієї ситуації?

Деталі такі:

Сервер xen має блокові пристрої, призначені для VM. Але ці пристрої також були встановлені всередині Xen.

Насправді 44 з цих блокових пристроїв встановлені так. Що ще гірше, кожен фізичний пристрій бачиться на 4 контурах, і кожен з них встановлюється на окремій точці кріплення. Іншими словами, пристрої фактично змонтовані 5 разів кожен.

Гостьова ОС VM бачить шлях через псевдопристрій PowerPath (виділяється як phy: блокувати пристрій до domU)

Деякі пристрої відформатовані як ext2 та reiserfs.

Не потрібно мені пояснювати ризики корупції файлової системи.

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

Зауважте, що додатки, бази даних Oracle здебільшого, у всіх VM все ще працюють і використовуються.

Я виявив це, коли досліджував високе використання процесора на dom0. Існує нерозбірливий процес "знайти", з cwd -> / media / disk-12, який монтується з / dev / sdf1, що належить / dev / emcpowerr

Перш ніж хтось запитує, я, коли я бачив, як процеси не можуть бути вбиті і продовжують використовувати процесор і оперативну пам’ять (на відміну від неіснуючого / зомбі-процесу), це коли є видатний зафіксований ввід / вивід, наприклад синхронізація повернута, але фізично ще не на диску . Частіше це трапляється на стрічкових введеннях / виводах.

Пропозиції !?

PS Я б очікував, що пристрої будуть "зарезервовані" після встановлення, щоб не допустити подібних речей? Або це неможливо в Linux?

EDIT: По-перше, я переконаний, що винуватець KDE в гіпервізорі). Схоже, KDE монтує пристрої, які він може вести в журнал, щоб створювати піктограми на робочому столі. Те ж саме не відбувається і на інших серверах Xen, але всі інші сервери мають набагато більш стару версію SLES та KDE ... Здається, що V4 ображає, а 3.4 веде себе краще).

Крім того, вивісили два некритичні ВМ. Після їх вимкнення вони не завантажуватимуться знову через пошкодження файлової системи. Основний / виробничий VM все ще працює, і база даних на ньому все ще працює, але очевидно, що це бомба часу. Замовник намагається відновити середовище на іншому VM на іншому сервері, але він застряг у питаннях налаштування деяких компонентів, тому ми чекаємо ...

У будь-якому випадку я відчуваю, що жодна з відповідей досі не була більше, ніж "найкраща практика завжди граціозно закривається". І я сподіваюся отримати щось більш конкретне ... У будь-якому випадку, я відчуваю, що ця ситуація може бути підставою для більш обережних мислення. Чи призведе до вимкнення синхронізованих вводу-виводу, зокрема оновлення метаданих файлової системи від гіпервізора, і спричинить потенційно серйозне пошкодження файлової системи?

Якщо диски записуються з однієї точки кріплення, шкоди не завдається. Зробіть чисте відключення (виправте його з призупиненого стану, якщо будете) виправити кріплення. Не запускайте нічого, крім голих потрібних додатків на Dom0. Якщо, OTOH, розділи записуються з декількох контурів, це BAD і погіршується на другий. Витягніть вилку.

Я не маю конкретних причин, але почуття кишечника говорить мені, що наступним може бути найкращий підхід:

1. Вимкніть програми.
2. Скопіюйте всі дані з VM через мережу в резервне місце.
3. Від’єднайте файлові системи зсередини VM.
4. Вимкніть ВМ. (На цьому хості зараз працює лише одна VM).
5. Переконайтесь, що не встановлено автоматичний запуск domUs.
6. Вийміть живлення на хості, щоб запобігти виконанню гіпервізора будь-яких "закриваючих" дій, синхронізації видатних вводу-виводу тощо.
7. Завантажте ВМ, сподіваючись, що гіпервізор сам пережив потужність.
8. Якщо це не вдається, відновіть навколишнє середовище. (Завантажувальні диски VM засновані на файлах, але точки монтажу даних знаходяться на зовнішньому диску, виділеному як блокові пристрої)
9. Перевірте, чи встановлює гіпервізор будь-які файлові системи, що належать до domUs. Скасуйте їх перед тим, як розпочати будь-який домен)
10. Вимкніть автоматичне встановлення KDE.
11. Запустіть VM і примусьте повністю перевірити FS.

Альтернатива 11: Запустіть VM та монтуйте файлові системи без повного fsck.

Аргументація полягає в тому, що я не хочу, щоб гіпервізор Xen мав більше шансів, які абсолютно необхідні, щоб викликати корупцію у файлових системах domU.

Я не експерт Xen і ще не мав досвіду з цим. Але мій підхід, якби я був на вашому місці, був би такий: спершу я знаю, що можу втратити дані (можливо, навіть усі); по-друге, я б спробував створити знімки, а потім призупинив VM, відновивши їх у безпечному іншому середовищі.
Я не хочу покладати на тебе помилкових надій, але, думаю, вам пощастить, якщо ви зможете щось відновити.

Попередження : дотримання цих порад може втратити всі дані. Це вирішувати, чи варто ризикувати чи ні.

З великою долею ваші програми все ще працюють, тому що дані, якими вони користуються, знаходяться у нестабільній пам'яті. Вам слід спробувати скористатися цією ситуацією (спробуйте оцінити, чи може це бути так, на основі програм для кожного додатка) та експортувати живі дані в загальну мережу, якщо програми пропонують таку функцію. Якщо будь-які дані є на диску, ця функція експорту може бути "заблокована" так, як ваша findзаява, або збій (і збій програми або ОС) через змінені / пошкоджені дані диска.

Тоді ви можете спробувати зробити знімок у прямому ефірі, інструкції з наступної статті: Створення знімків у Xen . Я б пішов на байт-байт-знімок, хоча він може застрягнути так само, як і ваша findкоманда ... Однак я не дав би такої надії.

Перш ніж виконувати попередню команду, вам слід прочитати цей документ від Citrix, який допомагає зрозуміти знімки в Xen (PDF) .

Я бажаю вам удачі.