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

14

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?

Johan
sumber
1
Dan saat ini setiap cadangan yang diambil sebelum "dimatikan" mungkin hanya mencadangkan data yang rusak, meskipun dalam situasi ini lebih mungkin bahwa meta-data sistem file rusak, daripada konten file.
Johan
Saya khawatir Anda akan kehilangan setidaknya beberapa data dalam hal apa pun. Mematikan host secara fisik atau menghentikan VM secara paksa mungkin memiliki konsekuensi yang tidak diinginkan dari mengacaukan segalanya (yaitu bahkan sistem file yang hanya dipasang sekali). Saya mungkin akan mencoba untuk menghentikan semuanya sebersih mungkin untuk meminimalkan kerugian. Dan tentu saja memastikan itu tidak terjadi lagi.
peterph
Sedangkan untuk mencegahnya, IIUC Anda mungkin mencoba untuk mengatur izin pada perangkat di dom0 setelah dibuka oleh tamu, tetapi karena izin fs (pada file perangkat) dapat dilintasi oleh root (kecuali jika Anda memiliki kernel yang ditambal) itu mungkin tidak perlu membantu.
peterph
1
Mengenai skrip posting Anda: jika perangkat terlihat melalui beberapa jalur maka kernel mungkin bahkan tidak tahu bahwa mereka semua adalah perangkat yang sama, jadi bagaimana mungkin "cadangan" itu? Sedangkan untuk mengekspor perangkat dari dom0 ke beberapa domUs, Anda dapat melakukannya karena Anda mungkin ingin melakukannya dengan sengaja (mis. Dengan sistem file yang mendukungnya, atau dipasang hanya-baca di mana saja).
Celada
@Celada saya pikir itu, tetapi ada cara "mengunci" perangkat: PowerPath harus (tidak dalam kasus Solaris) mencadangkan semua jalur induk dari perangkat (Pada saat itu menginisialisasi). Selain itu, perintah "cadangan" SCSI dikelola oleh perangkat target, jadi setelah target dicadangkan, ia harus menolak untuk mengizinkan cadangan terhadap salah satu jalur untuk perangkat itu. Setidaknya itu adalah pemahaman saya yang terbatas.
Johan

Jawaban:

2

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.

Bentuk Kehidupan Alien
sumber
0

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.

Johan
sumber
0

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.

Huygens
sumber
Terima kasih. Pelanggan memiliki ekspor basis data. Saya pikir mereka hanya menggunakan FTP untuk mengeluarkannya dari VM, tetapi dimungkinkan untuk me-mount berbagi jaringan dan mengekspor langsung ke sana.
Johan
Saya telah bermain-main dengan gagasan menangguhkan VM dan kemudian mengambil salinan lengkap ke host lain dan kemudian mencoba untuk a) Melanjutkan dari tidur, atau b) boot itu, diikuti oleh reboot dan fsck. Idenya adalah karena saya masih memiliki VM yang ditangguhkan pada host asli, saya mungkin dapat melanjutkan yang satu jika salinan tidak bekerja pada host lain.
Johan
Juga FWIW masalah dengan kembali ke cadangan adalah dikhawatirkan bahwa semua cadangan yang diambil selama beberapa bulan terakhir rusak.
Johan
@ Johan ini lebih dari mungkin benar, sebagian besar jika tidak semua cadangan (karena masalah terjadi) mungkin rusak. Hal yang sama mungkin berlaku untuk ekspor basis data. Semoga berhasil lagi, Anda akan membutuhkannya!
Huygens