Situasi mengerikan - sistem file dipasang secara bersamaan oleh beberapa instance OS independen

Bagaimana saya keluar dari situasi ini dengan aman?

Detailnya adalah sebagai berikut:

Server xen memiliki perangkat blok yang dialokasikan untuk VM. Tetapi perangkat ini juga telah dipasang di dalam Xen.

Bahkan 44 dari perangkat blok ini telah dipasang seperti ini. Untuk membuat keadaan menjadi lebih buruk, setiap perangkat fisik terlihat di 4 jalur dan masing-masing dipasang pada titik mount terpisah. Dengan kata lain perangkat sebenarnya dipasang masing-masing 5 kali.

VM guest OS melihat path melalui perangkat pseudo PowerPath (dialokasikan sebagai perangkat phy: blok ke domU)

Beberapa perangkat diformat sebagai ext2 dan reiserfs.

Tidak perlu menjelaskan kepada saya risiko korupsi sistem file yang terlibat di sini.

Saya takut bahwa bahkan hanya melepas sistem file dapat menyebabkan korupsi, dan merasa bahwa pada titik ini menarik daya dari tuan rumah, adalah opsi paling aman .

Perhatikan bahwa aplikasi, database Oracle untuk sebagian besar, di semua VM masih berjalan dan digunakan.

Saya menemukan ini ketika menyelidiki penggunaan CPU yang tinggi pada dom0. Ada proses "find" yang tidak dapat digunakan, dengan cwd -> / media / disk-12 yang di-mount dari / dev / sdf1, yang merupakan milik / dev / emcpowerr

Sebelum ada yang bertanya, satu kali saya melihat proses tidak dapat dimatikan dan terus menggunakan CPU dan RAM (tidak seperti proses zombie / mati), adalah ketika ada I / Os yang memiliki komitmen, mis. Sinkronisasi dikembalikan tetapi tidak secara fisik pada disk . Lebih umum ini terjadi pada rekaman I / O.

Saran!?

PS Saya berharap perangkat "dicadangkan" setelah dipasang, untuk mencegah hal semacam ini? Atau apakah itu tidak mungkin di Linux?

EDIT: Pertama saya yakin bahwa KDE di dalam hypervisor) adalah pelakunya. Sepertinya KDE sedang memasang perangkat yang dapat di-logging untuk membuat ikon desktop. Namun hal yang sama tidak terjadi pada server Xen lain, tetapi semua server lain menjalankan versi SLES dan KDE yang jauh lebih tua ... V4 tampaknya adalah yang menyinggung, dengan 3,4 berperilaku lebih baik).

Selain itu, dua VM yang tidak kritis telah digantung. Setelah mematikannya, mereka tidak mau boot lagi karena kerusakan sistem file. VM utama / produksi masih berjalan dan database di atasnya masih berfungsi, tetapi jelas ini adalah bom waktu. Pelanggan sedang mencoba untuk membangun kembali lingkungan pada VM lain di server lain tetapi terjebak pada masalah mengkonfigurasi beberapa komponen, jadi kami menunggu ...

Bagaimanapun saya merasa bahwa tidak ada jawaban sejauh ini lebih dari "praktik terbaik selalu ditutup dengan anggun" Dan saya berharap untuk mendapatkan sesuatu yang lebih konkret ... Bagaimanapun, saya merasa bahwa situasi ini mungkin memerlukan beberapa lebih hati-hati berpikir. Akankah mematikan menyebabkan IO yang beredar, khususnya sistem file meta, pembaruan data dari hypervisor, akan disinkronkan dan berpotensi menyebabkan kerusakan sistem file yang besar?

Jika disk sedang ditulis dari titik mount tunggal tidak ada salahnya dilakukan. Lakukan shutdown yang bersih, (cadangkan dari status ditangguhkan jika Anda mau) perbaiki mount. Jangan menjalankan apa pun kecuali aplikasi telanjang yang diperlukan di Dom0. Jika, OTOH, partisi sedang ditulis dari banyak jalur, itu BURUK dan semakin buruk dengan yang kedua. Tarik steker.

Saya tidak punya alasan konkret, tetapi firasat saya mengatakan bahwa berikut ini mungkin pendekatan terbaik:

1. Matikan aplikasi.
2. Salin semua data dari VM melalui jaringan ke lokasi cadangan.
3. Batalkan pemasangan sistem file dari dalam VM.
4. Matikan VM. (Hanya ada satu VM yang berjalan pada host ini sekarang).
5. Pastikan tidak ada domUs yang diatur untuk memulai secara otomatis.
6. Tarik daya pada host untuk mencegah hypervisor melakukan tindakan "penutupan", sinkronisasi I / O yang beredar, dll.
7. Boot VM, berharap hypervisor itu sendiri selamat dari power-yank.
8. Jika gagal, bangun kembali lingkungan. (Disk boot VM berbasis file, tetapi titik mount data berada pada disk eksternal yang dialokasikan sebagai perangkat blok)
9. Periksa apakah hypervisor memasang sistem file apa pun yang termasuk dalam domUs. Batalkan pemasangan ini sebelum domUs dimulai)
10. Matikan pemasangan otomatis KDE.
11. Mulai VM dan paksa cek FS penuh.

Alternatif ke 11: Mulai VM dan pasang sistem file tanpa fsck penuh.

Alasannya adalah bahwa saya tidak ingin Xen hypervisor memiliki lebih banyak kesempatan yang benar-benar diperlukan untuk menyebabkan korupsi pada sistem file domU.

Saya bukan ahli Xen dan belum memiliki pengalaman dengannya. Tetapi pendekatan saya jika saya menggantikan Anda adalah: pertama saya tahu saya mungkin kehilangan data (mungkin bahkan semua); kedua saya akan mencoba membuat snapshot dan kemudian menangguhkan VM, memulihkannya di lingkungan yang berbeda dan aman.
Saya tidak ingin memberi Anda harapan palsu, tetapi saya pikir Anda akan beruntung jika Anda dapat memulihkan apa pun.

Peringatan : mengikuti saran ini dapat membuat Anda kehilangan semua data. Terserah Anda untuk melihat apakah itu sepadan dengan risikonya atau tidak.

Dengan banyak keberuntungan, aplikasi Anda masih berfungsi karena data yang mereka gunakan semuanya dalam memori volatile. Anda harus mencoba untuk mendapatkan keuntungan dari situasi ini (mencoba untuk mengevaluasi apakah itu dapat terjadi pada basis per aplikasi) dan mengekspor data langsung ke jaringan berbagi jika aplikasi menawarkan fitur seperti itu. Jika ada data pada disk, fungsi ekspor ini bisa "dikunci" seperti findpernyataan atau kerusakan Anda (dan crash aplikasi atau OS) karena data disk yang diubah / rusak.

Kemudian Anda dapat mencoba untuk melakukan snapshot langsung, instruksi dalam artikel berikut: Membuat snapshot di Xen . Saya akan memilih snapshot byte-by-byte, meskipun itu bisa macet seperti findperintah Anda ... Namun, saya tidak akan memberikan banyak harapan ini.

Sebelum melakukan perintah sebelumnya, Anda harus membaca dokumen ini dari Citrix yang membantu memahami foto dalam Xen (PDF) .

Semoga kamu berhasil.