Xen DomU kök dosya sistemleri iSCSI sanal IP yük devretmesinde salt okunur hale geliyor

Xen sunucularım iSCSI SAN kümemize open-iscsi ile openSUSE 11.1. SAN modülleri, başlatıcıların bağlandığı sanal IP'nin arkasında bir IP yük devretme grubundadır.

Birincil SAN sunucusunun çökmesi durumunda, ikincil hedef olarak hizmet etme rolünü alır. Tüm bunlar LeftHand SAN / iQ yazılımı tarafından ele alınır ve çoğu durumda iyi çalışır.

Sahip olduğum sorun, zaman zaman bazı Xen DomU'larımın bir IP yük devretme işleminden sonra kök dosya sisteminin salt okunur olmasını sağlayacak. Tutarlı değildir ve her yük devretme gerçekleştiğinde farklı bir alt kümeye dönüşür. Hepsi aynı openSUSE 11.1 yazılım görüntüsünü çalıştırıyor.

Her bir DomU için kök dosya sistemleri Dom0'daki open-iscsi tarafından monte edilir ve daha sonra Xen, DomU'ya göstermek için standart blok aygıt sürücüsünü kullanır.

Tam belirti, çalışan bir kök olarak touch /test"salt okunur dosya sistemi" hatasını döndürür. Bununla birlikte, çıktıları mountokuma-yazma olarak monte edildiğini gösterir. Tabii ki, domU'daki diğer tüm G / Ç de şu anda başarısız oluyor, bu yüzden makine sert düşüyor. xmİSCSI oturumunu yeniden bağlamadan Dom0'dan yeniden başlatmak , her şeyin tekrar çalışmasını sağlar.

Dom0 tarafında, devretme sırasındaki sistem günlüğü iletileri aşağıdaki gibidir:

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) 

Bu sorunu ayıklamak için hangi katmanı bulmakta zorlanıyorum, bu DomU çekirdeğinde bir şey mi? veya Dom0 veya Xen seviyesinde mi? Bir yerde zaman aşımını artırmak için ince ayar yapılması gereken bazı parametreler olduğunu düşünüyorum, ama nereye bakacağımdan emin değilim.

Gerçekten bağlı iscsi ile ilgili bir sorun olduğunu düşünmüyorum çünkü bağlı blok cihazı hala Dom0'dan okunabilir ve yazılabilir.

Sonunda bunu open-iscsi belgelerinden aşağıdaki tavsiye ve ayarları kullanarak çözdüm:

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

Yukarıda açıklandığı gibi her LUN'a bağlantı kurduktan sonra, yerine çalışma birkaç dakika sürse bile yük devretme bir cazibe gibi çalışır.

Bu, dom0'da çalışan iSCSI başlatıcısında bir sorun gibi görünüyor. Başlatıcı, bu kadar hızlı bir şekilde SCSI arızalarını göndermemelidir. Muhtemelen iscsi.conf dosyasında ConnFailTimeout'u ayarlamak isteyeceksiniz. Bu, bir bağlantı hatasını bir hata olarak değerlendirmeden önce ne kadar süre geçeceğini belirleyen ve bu hatayı SCSI yığınını gönderecek olan ayardır.

Ayrıca yük devretmenin aslında ne kadar sürdüğüne de bakacağım, beklediğinizden daha uzun sürebilir. Eğer öyleyse, VIP yük devretme ARP ile ilgili sorunlar nedeniyle çok uzun sürüyor.

Dom0'da, yük devretme sırasında herhangi bir okuma / yazma hatası veya scsi hatası gösteren herhangi bir mesaj var mı? Eğer öyleyse, bu yazma hatası domU'ya aktarılıyor gibi görünüyor. DomU, bir iSCSI cihazı olduğunu "bilmez", bu nedenle alttaki disk kaybolmuş gibi davranır ve dosya sistemini salt okunur olarak yeniden monte eder (bkz. Mount (1) manpage - errors=continue / errors=remount-ro / errors=panic)

Dom0'ın bakış açısından, salt okunur olarak değişmeyecek - bu salt okunur davranış, bir blok cihaz semantiği değil, bir dosya sistemi semantiği.

Şu anda "diğer tüm G / Ç'nin başarısız olduğunu" belirtiyorsunuz - domU veya dom0 mı demek istediniz?

Genellikle bir HA iSCSI çözümü kurarken, sanal IP devralma yerine çoklu yol kullanıyorum - ana makineye daha fazla görünürlük sağlar ve bir iSCSI oturumunuz aniden kaybolur ve yeniden başlatılması gerekir - her zaman orada, sadece iki tane var . Bu, bu ortamda bir seçenek mi?

Um ... Sorunun bir kısmı da RO olarak çalışmıyor olmanız. En iyi uygulamalar güvenlik açısından "/" monte edilmiş ro olmalı ve rw'ye ihtiyaç duyan dosya sistemlerinin ayrı ayrı (yani / var ve / tmp) monte edilmesi gerektiğini belirtir. / Etc altında yazılması gereken dizinler varsa, / var / etc / path dizinine taşınmalı ve / etc dizinine eklenmelidir.

"/" yalnızca RW'yi tek kullanıcı modunda monte etmelidir.

Bu şekilde kurmak, diğer önerilerle birleştirildiğinde yukarıdaki durumda segfaultu önleyebilir.