Sistem file root Xen DomU menjadi read-only pada iSCSI virtual IP failover


9

Server Xen saya adalah openSUSE 11.1 dengan open-iscsi untuk kluster SAN iSCSI kami. Modul SAN berada dalam grup IP failover di belakang IP virtual yang terhubung oleh pemrakarsa.

Jika server SAN utama turun, sekunder mengambil peran melayani sebagai target. Ini semua ditangani oleh perangkat lunak LeftHand SAN / iQ dan berfungsi dengan baik di sebagian besar situasi.

Masalah yang saya miliki adalah bahwa kadang-kadang beberapa Xen DomUs saya akan membuat sistem file root mereka hanya baca setelah IP failover. Itu tidak konsisten, dan terjadi pada subset yang berbeda setiap kali terjadi failover. Mereka semua menjalankan citra perangkat lunak openSUSE 11.1 yang sama.

Root filesystems untuk setiap DomU dipasang oleh open-iscsi di Dom0 dan kemudian Xen menggunakan driver perangkat blok standar untuk mengeksposnya ke DomU.

Gejala yang tepat adalah bahwa sebagai root saat menjalankan touch /testmengembalikan kesalahan "read-only filesystem". Namun, output mountmenunjukkan itu sedang dipasang baca-tulis. Tentu saja, semua I / O lain di domU juga gagal pada saat ini sehingga mesin turun keras. Cukup restart dengan xmdari Dom0 bahkan tanpa menghubungkan kembali sesi iSCSI membuat semuanya berfungsi kembali.

Di sisi Dom0 pesan syslog selama fail-over adalah sesuatu seperti berikut:

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) 

Saya mengalami kesulitan mencari tahu pada layer apa untuk debug masalah ini, apakah itu sesuatu di kernel DomU? atau di level Dom0 atau Xen? Saya pikir kemungkinan ada beberapa parameter di suatu tempat yang perlu diubah untuk meningkatkan semacam waktu tunggu, tapi saya tidak yakin ke mana harus mencari.

Saya tidak berpikir itu masalah dengan open-iscsi hanya karena perangkat blok yang terhubung masih dapat dibaca dan ditulis dari Dom0.

Jawaban:


6

Saya akhirnya menyelesaikan ini dengan menggunakan saran dan pengaturan berikut dari dokumentasi open-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

Setelah mengatur koneksi ke masing-masing LUN seperti yang dijelaskan di atas, failover berfungsi seperti mantra, bahkan jika diperlukan beberapa menit.


1
Saya memiliki masalah yang sama dengan mysql prod db duduk di volume iscsi, dengan kesalahan yang sama di / var / log / messages dan sistem file dalam mode read-only. Tip ini memecahkan masalah.
RainDoctor

2

Ini terdengar seperti masalah dengan inisiator iSCSI berjalan di dom0. Inisiator tidak boleh mengirim kegagalan SCSI ke tumpukan dengan cepat. Anda mungkin ingin mengatur ConnFailTimeout di iscsi.conf ini adalah pengaturan yang menentukan berapa lama sebelum menganggap kegagalan koneksi sebagai kesalahan dan mengirimkan kesalahan itu ke tumpukan SCSI.

Saya juga akan melihat berapa lama waktu yang dibutuhkan failover, mungkin butuh waktu lebih lama dari yang Anda harapkan. Jika demikian, mungkin kegagalan VIP terlalu lama karena masalah terkait ARP.


Saya pikir inilah yang saya butuhkan.
Kamil Kisiel

0

Apakah ada pesan di dom0 yang mengindikasikan kesalahan baca / tulis atau kesalahan scsi pada saat failover? Jika demikian, sepertinya kesalahan tulis ini diteruskan ke domU. DomU tidak "tahu" bahwa itu adalah perangkat iSCSI, jadi itu berperilaku seolah-olah disk yang mendasarinya telah pergi dan remount sistem file read-only (lihat mount (1) manual - errors=continue / errors=remount-ro / errors=panic)

Dari perspektif dom0, itu tidak akan berubah menjadi read-only - perilaku read-only ini adalah semantik filesystem, bukan semantic device blok.

Anda menyebutkan bahwa "semua I / O lainnya gagal" saat ini - apakah maksud Anda domU atau dom0?

Biasanya ketika mengatur solusi HA iSCSI saya menggunakan multipathing daripada pengambilalihan IP virtual - ini memungkinkan visibilitas yang lebih besar ke host dan Anda tidak memiliki sesi iSCSI tiba-tiba menghilang kemudian perlu dihidupkan ulang - selalu ada, hanya ada dua . Apakah ini opsi di lingkungan ini?


Diperbarui deskripsi asli dengan jawaban atas pertanyaan Anda. Saya kira saya bisa melihat ke multipathing saja, tetapi sistem ini lebih diarahkan untuk failover IP virtual dalam bentuk saat ini. Saya tidak yakin bagaimana replikasi level blok akan digunakan untuk bermain dengan multipathing, terutama karena salah satu unit SAN perlu ditunjuk sebagai master. Terima kasih telah mengarahkan saya ke bagian tentang sistem file. Saya kira cukup banyak menjelaskannya. Saya kira saya bisa mencoba beralih ke mode 'melanjutkan', atau mungkin melihat mengubah sistem file ke sesuatu yang lebih tangguh seperti XFS.
Kamil Kisiel

1
Tidak ada yang secara inheren buruk tentang ext3 - Anda akan memiliki masalah serupa dengan XFS. Dan saya tidak akan merekomendasikan menggunakan onerror = continue - sistem akan percaya bahwa blok tidak dapat dibaca dan Anda akan kehilangan data. Multipathing bukan mirroring - Anda tidak perlu khawatir tentang replikasi pada host. Anda hanya akan terhubung melalui iSCSI ke target master dan sekunder dan tuan rumah akan tahu bahwa jika master gagal, tidak meneruskan kesalahan ke atas tumpukan tetapi untuk mencoba perintah yang sama diarahkan pada target sekunder.
MikeyB

Komentar saya tentang replikasi berkaitan dengan fakta bahwa kedua server SAN perlu menyinkronkan data mereka. Secara internal saya pikir sistem bekerja mirip dengan drbd, dengan salah satu unit (yang saat ini memiliki VIP) menjadi master. Mungkin bekerja dengan multipathing, tapi saya benar-benar ingin menyelesaikan masalah ini tanpa beralih dari arsitektur saat ini. Seharusnya ada cara untuk membuat ini berfungsi sebaliknya, sistem saya yang secara langsung me-mount volume iSCSI tidak pernah memiliki masalah dengan volume menjadi read-only.
Kamil Kisiel

-1

Um ... Bagian dari masalahnya adalah Anda tidak menjalankan / sebagai RO. Praktik terbaik menyatakan keadaan keamanan Anda harus memiliki "/" mount ro, dan bahwa setiap sistem file yang perlu rw harus dipasang secara terpisah, (yaitu, / var dan / tmp). Jika ada direktori di bawah / etc yang perlu ditulis, mereka harus dipindahkan ke / var / etc / path dan disinkronkan ke / etc.

"/" hanya boleh dipasang RW dalam mode pengguna tunggal.

Menyiapkan dengan cara ini dapat mencegah kesalahan dalam situasi di atas ketika dikombinasikan dengan saran lainnya.


2
Apakah Anda yakin menjawab pertanyaan yang benar?
Kamil Kisiel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.