Geçenlerde karşılaştığımız bir sorunla ilgili olarak makale tadında bir problem çözümü ele aldım, umarım keyifle okursunuz.
Yapıyı biraz sadeleştirerek, kısaca senaryodan bahsedelim. Hyper-V host üzerinde çalışan bir VM düşünüyoruz. Bu VM, onu tutan host sistem yani Parent Partition (Parent OS) üzerinde paylaştırılmış bir dizine erişiyor (virtual network üzerinden) ve dosya yazıyor/siliyor.
Yazıya devam etmeden önce şunu belirtmek istiyorum: bu tavsiye edilen bir yapı değildir. Parent Partition yani host sistem üzerinde bu tip hizmetler (dosya paylaşımı vs..) vermek sorunlara yol açıyor. Sağlıklı sanallaştırma yapılarında Parent Partition’lar sadece ve sadece VM’leri çalıştırmaya odaklanmalı, başka bir hizmet ile meşgul olmamalıdır. Hatta mümkünse Parent Partition’lar Windows Server Core kurulum olmalıdır. Bu nedenle senaryomuzdaki Host ve VM arasındaki dosya paylaşım işlemini production ortamlarda kullanmayın. Eğer kullanmanız gerekiyor ise, yazının sonundaki çözüm ile kullanın.
Aşağıdaki diagram yapıyı temsil ediyor.
Senaryodaki Hyper-V sunucusu üzerinde 2 fiziksel NIC olduğunu görebiliyorsunuz. 1nci fiziksel NIC Virtual Network için hizmet veriyor ve üzerinde Microsoft Virtual Network Switch Protocol çalışıyor. 2nci fiziksel NIC ise Virtual Network’ten ayrı olarak sadece Parent Partition’a hizmet ediyor (örneğin management işlemleri için).
Yine Parent Partititon üzerinde görünen ve 192.168.5.5 IP adresine sahip Virtual NIC ise Fiziksel NIC 1 yerine yaratılan ve Virtual Network‘e dahil olan sanal bir donanımdır. Parent Partition VM’ler ile haberleşirken çoğunlukla bu Virtual NIC’i kullanıyor.
Bu konuyu yani Hyper-V Virtual Netwrok yapısını anlamak ve fiziksel NIC’ler duruken Parent Partition üzerinde neden sanal bir NIC yer aldığını öğrenmek için daha önce ele aldığım şu konuyu incelemenizi öneririm:
Hyper-V Virtual Network Yapısı
Senaryomuzdaki VM, Parent Partition üzerindeki örneğin \\Server\Share3 isimli paylaşıma erişmek istediğinde, aşağıdaki diagramda yeşil ile çizdiğim yolu izler.
Bu normal bir davranıştır.
Anormal olan ise, VM üzerinden bu paylaşım içerisinde herhangi bir MS Office dosyası yaratıp kayıt ederken
“Gecikmeli Yazma Başarısız” / “Delayed Write Failed”
hatası alıyor olmamız ve işlemin tamamlanamaması …
Ancak örneğin bir notepad dosyası yarattığımızda yada bir mp3 veya jpg dosyası kopyaladığımızda başarılı bir şekilde işlem tamamlanabiliyor.
Yani problemin karakteristik özelliği MS Office belgelerine özgü olması :)
Sanal makinemiz kendi host’u üzerindeki bir paylaşıma erişip MS Office belgesi yaratmak istediğinde gecikmeli yazma başarısız hatası alıyor. Problemimiz tam olarak bu.
Aslında gecikmeli yazma başarısız hatası genelde donanım (disk) kaynaklıdır ve çözümü bilinen bir sorundur: http://support.microsoft.com/kb/330174/tr . Ancak bizim senaryomuzdaki hata network üzerinde oluştuğu için makaledeki çözüm işimize yaramıyor.
Bu noktadan sonra ilk işimiz Hyper-V sunucusu üzerindeki fiziksel NIC’ler için yayınlanmış daha güncel bir driver olup olmadığını kontrol etmek oldu ancak işimize yarayacak bir driver yoktu. Yani elimizdekiler ile çözüm üretmemiz gerekiyordu :)
Garip olan ise bu hatanın bir anda ortaya çıkmış olması. Çünkü yapı uzun zamandır bu şekilde çalışıyordu ve VM’ler host üzerindeki paylaşımlara rahatlıkla MS Office belgeleri yazabiliyordu.
Bu durum ile ilgili genel event viewer kayıtlarında yada virtual network loglarında herhangi bir olay da yoktu.
Yaptığımız kontrollerde de farklı bir hata yada anormal bir duruma rastlamadık.
Bununla birlikte aynı senaryoyu farklı Hyper-V sunucular üzerinde denedik ve sorunsuz bir şekilde kendi üzerlerinde çalışan VM’lerin yine kendi üzerlerindeki paylaşımlara MS Office belgesi açıp, kayıt edebilidiklerini gördük ki zaten bu işlemin doğru olarak çalışması gerektiğini biliyoruz.
Anlayacağınız ortada çok specific bir sorun vardı.
Derken host sistem üzerindeki \\Server\Share3 paylaşımına başka fiziksel sistemler üzerindeki VM’lerden MS Office belgeleri yazabildiğimizi farkettik ve bizi çözüme götüren tespitte bu oldu :)
Sorun Parent Partition ve VM’ler arasındaki dosya paylaşımının aynı Virtual Network içerisinde gerçekleşiyor olması. Ama az önce de söylediğim gibi aslında bu sağlıklı çalışabilen bir process.
Bu durum için bilinen bir problem kaydı olmaması, bir gün öncesine kadar zaten çalışıyor olması ve farklı fiziksel sunucular üzerinde bu sorunun yaşanmaması da bu process’in doğru olarak tamamlanması gerektiği fikrimizi destekliyordu. Peki bu sunucunun sorunu neydi? (bu konuya az sonra geleceğim)
Problemi acil olarak çözmemiz gerektiği için hemen Hyper-V sunucusu üzerindeki Virtual NIC’i disable ettik çünkü Parent Partition tarafındaki dosya paylaşım trafiğini Virtual Network içerisinden çıkartmamız gerekiyordu . Böyle yaparak trafiğin 2nci fiziksel NIC üzerinden akmasını sağlamış olduk ve problemin ortadan kalktığını gördük.
Şu haliyle \\Server\Share3 paylaşımına erişmek isteyen VM’in izlediği yolu aşağıdaki diagramda görebilirsiniz.
Ve artık VM’ler host sistem üzerindeki paylaşımlara sağlıklı bir şekilde erişip, dosya yazma, okuma gibi işlemleri normal olarak yapabiliyorlardı.
Ayrıca belirtmek istiyorum; Virtual Network’leri ve Virtual NIC’leri kaldırıp yeniden yartmamız da çözüm olmamıştı.
Peki bu soruna yol açan neydi?
Aslında elimizde kesin sonuca ulaşacak belirgin veriler olmadığı için net birşey söylemek zor ama sıkıntının problem başlamadan bir gün önce gerçekleşen Windows Update (Parent Partition için) sonrası ortaya çıktığını söyleyebilirim. Bu düşüncemizi destekleyen ise, ortamda bire bir aynı donanıma sahip ve aynı marka 2 Hyper-V sunucusunun daha yer alıyor olması, aynı Update’leri onların da almış olması ve onlar üzerinde de aynı problemin olmasıydı. Ayrıca sunucular Windows Server 2008 logolu donanımlara sahip değillerdi. Ama yine bir gün önce Update almış ancak farklı donanım özellikleri olan, farklı marka Hyper-V sunucularda böyle bir porblem yoktu.
Problem çıkartan sunucularda Asus marka server mainboard’lar ve onboard NIC’ler vardı.
Benim düşüncem ise; Windows Update sonrası fiziksel donanıma özgü (özellikle NIC tarafında) driver temelli bir sıkıntının ortaya çıktığı yönünde oldu.
Problemli sunucular production networkte hizmet ettiği için bir an önce devreye almamız gerekti ve yüklenmiş update’leri tek tek uninstall edip, problemin daha derinlerine ineme şansımız olmadı.
Sonuç olarak Virtual Network için hizmet eden fiziksel NIC’i başka işler için kullanmanın doğru olmadığını unutmayın. Eğerki Parent Partition üzerinde farklı işler için network erişimine ihtiyacınız varsa, bunu sunucu üzerine takacağınız 2nci, 3ncü NIC’ler ile gerçekleştirin.
Örneğin senaryomuzda 1nci fiziksel NIC Virtual Network tarafına hizmet ediyor. 2nci fiziskel NIC’i ise dosya paylaşımı için kullanmış olduk. Eğer dosya paylaşımı tarafında yoğun bir trafik söz konusu ise bu NIC’i bu iş için dedicate edip, management ve diğer işlemler için 3ncü bir fiziksel NIC takabiliriz.
Gördüğünüz gibi problemin çözümü basit. Tek bir virtual NIC’i disable ederek sonuca ulaştık. Konuyu ayrıntılı ele almamın asıl amacı ise bu gibi durumlarda problemlere nasıl yaklaşmanız gerektiği konusunda fikir verebilmekti.
İyi çalışmalar.
En Yeni Yorumlar