Korkunç durum - birden fazla bağımsız işletim sistemi örneği tarafından aynı anda monte edilen dosya sistemleri

Bu durumdan nasıl güvenle çıkarım?

Detaylar aşağıdaki gibidir:

Bir xen sunucusunda VM'lere ayrılmış blok cihazları vardır. Ancak bu cihazlar Xen'in içine de monte edilmiştir.

Aslında bu blok cihazların 44'ü bu şekilde monte edilmiştir. Daha da kötüsü, her fiziksel cihaz 4 yol üzerinde görülür ve her biri ayrı bir bağlantı noktasına monte edilir. Başka bir deyişle, cihazlar aslında her biri 5 kez monte edilir.

VM konuk işletim sistemi yolu bir PowerPath sözde aygıtı (domU'ya bir phy: blok aygıtı olarak ayrılır) aracılığıyla görür

Bazı cihazlar ext2 ve reiserfs olarak biçimlendirilmiştir.

Burada yer alan dosya sistemi bozulma risklerini açıklamaya gerek yok.

Korkarım ki sadece dosya sistemlerini ayırmak yolsuzluğa neden olabilir ve bu noktada ana bilgisayardan gücü çekmenin en güvenli seçenek olduğunu hissediyorum .

Tüm VM'lerde uygulamaların, çoğunlukla Oracle veritabanlarının, hala çalışmakta ve kullanımda olduğunu unutmayın.

Dom0'da yüksek CPU kullanımını araştırırken bunu keşfettim. / Dev / sdf1 dizininden / dev / emcpowerr'a ait olan cwd -> / media / disk-12 ile bir unkillable "find" işlemi vardır.

Birisi sormadan önce, süreçlerin öldürülemeyeceğini ve CPU ve RAM'i kullanmaya devam edemediğini (geçersiz / zombi işleminin aksine), olağanüstü taahhüt edilmiş G / Ç'ler olduğu zaman, örneğin senkronizasyon geri döndü, ancak henüz fiziksel olarak diskte değil . Daha yaygın olarak bu, bant G / Ç'sinde meydana gelir.

Öneriler!?

PS Ben bu tür bir şey önlemek için, monte kez cihazlar "ayrılmış" beklenirdi? Yoksa Linux'ta bu mümkün değil mi?

EDIT: Öncelikle hiper yönetici içinde KDE) suçlu olduğuna ikna oldum. KDE, masaüstü simgeleri oluşturmak için günlüğe kaydedebileceği cihazları monte ediyor gibi görünüyor. Ancak aynı şey diğer Xen sunucularında da gerçekleşmiyor, ancak diğer tüm sunucular SLES ve KDE'nin çok daha eski bir sürümünü çalıştırıyor ... V4, 3.4 daha iyi davranan rahatsız edici gibi görünüyor).

Dahası, kritik olmayan iki VM asıldı. Onları kapattıktan sonra dosya sistemi bozulması nedeniyle yeniden önyükleme olmaz. Ana / üretim VM hala çalışıyor ve üzerindeki veritabanı hala çalışıyor, ama açıkça bu bir saatli bomba. Müşteri, ortamı başka bir sunucudaki başka bir VM'de yeniden oluşturmaya çalışıyor, ancak bazı bileşenlerin yapılandırılmasıyla ilgili sorunlara takıldı, bu yüzden bekliyoruz ...

Her halükarda, cevapların hiçbirinin şu ana kadar "en iyi uygulama her zaman zarif bir şekilde kapatıldığından" daha fazla olmadığını hissediyorum ve umarım daha somut bir şey elde etmeyi umuyorum ... Her durumda, bu durumun biraz daha dikkatli olabileceğini hissediyorum. düşünce. Kapatmak, olağanüstü IO'nun, özellikle hiper yöneticiden gelen dosya sistemi meta veri güncellemelerinin senkronize edilmesine ve büyük olasılıkla büyük dosya sistemi bozulmasına neden olur mu?

Diskler tek bir montaj noktasından yazılıyorsa, herhangi bir zarar verilmez. Temiz bir kapatma yapın, (takarsanız askıya alma durumundan yedekleyin) montajları düzeltin. Dom0'da çıplak ihtiyaç duyulan uygulamalardan başka bir şey çalıştırmayın. OTOH, bölümler birden çok yoldan yazılıyorsa, bu KÖTÜ ve ikincisi daha da kötüye gidiyor. Fişi çekin.

Somut bir nedenim yok ama bağırsak hissim bana aşağıdakilerin en iyi yaklaşım olabileceğini söylüyor:

1. Uygulamaları kapatın.
2. Ağ üzerindeki VM'deki tüm verileri bir yedek konuma kopyalayın.
3. Dosya sistemlerini VM'den ayırın.
4. VM'yi kapatın. (Şu anda bu ana bilgisayarda çalışan yalnızca bir VM var).
5. Hiçbir domU'nun otomatik olarak başlamaya ayarlanmadığından emin olun.
6. Hiper denetimcinin herhangi bir "kapanma" eylemi gerçekleştirmesini, olağanüstü G / Ç senkronizasyonunu vb. Yapmasını önlemek için ana makinenin gücünü çekin.
7. Sanal makineyi, hipervizörün kendisinin güçten kurtulduğunu umarak başlatın.
8. Başarısız olursa, ortamı yeniden oluşturun. (VM'lerin önyükleme diskleri dosya tabanlıdır, ancak veri bağlama noktaları blok aygıtlar olarak atanan harici diskte bulunur)
9. Hipervizörün domU'lara ait herhangi bir dosya sistemi kurup kurmadığını kontrol edin. Herhangi bir domU başlatılmadan önce bunları çıkarın.
10. KDE otomatik montajını kapatın.
11. VM'yi başlatın ve tam FS kontrolünü zorlayın.

11'e alternatif: VM'yi başlatın ve dosya sistemlerini tam fsck olmadan bağlayın.

Bunun nedeni, Xen hipervizörünün domU dosya sistemlerinde bozulmaya neden olması için daha fazla şansa sahip olmasını istemememdir.

Ben Xen uzmanı değilim ve onunla ilgili henüz bir deneyimim yoktu. Ama senin yerinde olsaydım yaklaşımım şöyle olurdu: ilk önce veri kaybedebileceğimi biliyorum (belki de hepsi); İkincisi, anlık görüntüler oluşturmaya ve daha sonra sanal makinelerin askıya alınmasına ve güvenli farklı bir ortamda geri yüklenmesine çalışacağım.
Sana sahte umutlar vermek istemiyorum, ama bir şeyleri kurtarabilirsen şanslı olacağını düşünüyorum.

Uyarı : Bu önerileri takip etmek tüm verilerinizi kaybetmenize neden olabilir . Riske değip değmeyeceğini görmek size kalmıştır.

Bol şansla, uygulamalarınız hala çalışıyor çünkü kullandıkları verilerin hepsi kalıcı bellekte. Bu durumdan yararlanmaya çalışmalısınız (uygulama başına böyle bir durum olup olmadığını değerlendirmeye çalışın) ve uygulamalar böyle bir özellik sunuyorsa canlı verileri bir ağ paylaşımına aktarın. Diskte herhangi bir veri varsa, bu dışa aktarma işlevi find, değiştirilen / bozuk disk verileri nedeniyle ifadeniz veya kilitlenmeniz gibi "kilitlenebilir" (ve uygulamanın veya işletim sisteminin çökmesine neden olabilir).

Daha sonra, aşağıdaki makaledeki talimatları canlı bir anlık görüntü yapmaya çalışabilirsiniz: Xen'de anlık görüntüler oluşturma . Ben sizin bayt-byte-byte anlık görüntü için gitmek istiyorum find, ama bu sizin komutunuz gibi sıkışmış olabilir ... Ancak, ben bu kadar umut vermezdim.

Önceki komutu yapmadan önce , Xen'deki (PDF) anlık görüntüleri anlamaya yardımcı olan bu belgeyi Citrix'ten okumalısınız .

İyi şanslar dilerim.