Hyper-V Sanal Disk Türleri - Fixed, Dynamic, Differencing | Serhat AKINCI - IT Blog
20.09.2015 | 15:09 Hyper-V 4 Yorum
Zaman zaman Hyper-V sanal makinelerine bağlanan sanal disk türleriyle ilgili şeylerden bahsetmiştim. Ama fark ettim ki blog üzerinde bu konuya adanmış bir post yok. Ne tuhaf :) Bu önemli konu hakkında hemen bir tane kaleme alayım ve blog’taki yerini alsın. (Update: 7 yıl önce kısa bir tane yazmışım)
Kısaca sanal makineler tarafından depolama alanı olarak kullanılan ve gerçekte fiziksel HDD’ler üzerinde konumlanmış dosya formatlarıdır. Sanal disk türüne göre değişmekle birlikte header, block allocation table, data blocks, footer gibi yapısal bölümlerin birleşiminden oluşurlar.
Windows Server 2008 Hyper-V ve Windows Server 2008 R2 Hyper-V’de tek bir sanal disk formatı yer aldı: VHD.
VHD (ve halefi VHDX) için Microsoft dünyasında kullanılan ortak sanal disk formatıdır diyebiliz.
VHD formatlı sanal diskleri .vhd uzantılarından kolayca tanıyabilirsiniz. Halla kullanımda olsa da özellikle power failure kaynaklı beklenmedik kapanma durumlarında corruption ihtimali olan, sadece NTFS dosya sistemi üzerinde host edilebilen ve mesela maksimum 2TB’a kadar kapasite sağlayabilen VHD formatı büyük oranda geride kaldığı için fazla kurcalamadan uzaklaşalım :)
Windows Server 2012’yle birlikte Hyper-V platformuna yeni bir sanal disk formatı dahil oldu: VHDX.
Eğer kullandığınız Hyper-V sürümü VHDX formatını destekliyorsa sanal makineleriniz için mutlaka VHDX formatını tercih edin. Ayrıca VHDX’leri Windows Server 2008 R2 Hyper-V ve önceki sürümlerde kullanamayacağınızı da unutmayın.
VHD ve VHDX formatları kendi içlerinde Sabit (fixed), Dinamik (dynamic) ve Fark (differencing) olmak üzere üç sanal disk türü barındırır. Her bir sanal disk türü kendine has karakteristik özelliklere sahiptir ve çeşitli amaçlar için kullanılır.
Aşağıdaki sanal disk türleri hem VHD hem de VHDX formatı için geçerlidir.
Fixed Size (sabit boyutlu)
Dynamically Expanding (dinamik olarak genişleyen)
Differencing (fark tutan)
İlk oluşturulma işlemi diğer türlere daha uzun sürer.
Yoğun disk aktiviteleri için önerilir çünkü diğer iki sanal disk türüne göre daha performanslıdır.
Fixed size vhdx’lere veri yazıldıkça veya silindikçe VHDX dosya boyutu değişmez.
Bana göre en büyük dezavantajı fiziksel depolama alanı kullanımını verimsizleştirmesidir çünkü doğası gereği aslında sanal makine tarafından henüz kullanılmayan depolama alanını da sanal makine için rezerve eder. Diğer taraftan bakıldığında ise kontrollüdür çünkü sanal disklerin plan dışı genişlemesi yüzünden fiziksel depolama alanının taşması gibi takip gerektiren durumları ortadan kaldırır.
Özellikle platform (virtualization host) seviyesinde alınan yedek boyutunu ciddi anlamda şişirip yedekleme yatırımınızı gözden geçirmenize neden olabilir :) Mesela başlangıçta 150GB kapasiteye ihtiyaç duyan ve 6 ay içerisinde 300GB’a genişleyeceği tahmin edilen bir fixed size vhdx’i en başta geniş geniş 500GB olarak oluşturursanız, host level yedek alırken 200GB’ı boş yere yedeklemiş olursunuz. Aslında içerisinde veri olmayan bu bölüm hem yedekleme alanını tüketir, hem de yedekleme süresini uzatır. Bu yüzden eğer fixed size vhdx’ler kullanıyorsanız başlangıç kapasitelerini düşük tutun ancak sanal işletim sistemi içerisinden de disk dolma ihtimaline karşı volume size’ları mutlaka takip edin. Veya alternatif olarak sanal işletim sistemi içerisinden (guest os level) yedek almayı deneyebilirsiniz; bu yöntem genellikle uygulama yedekleme için kullanılır.
Bir fixed size vhdx’i sanal makine çalışır durumdayken kolayca genişletebilirsiniz. Bu sırada fiziksel diskte yeteri kadar boş alan olması gerektiğini unutmayın, aksi durumda genişleyemez.
Block level fragmentation yüzdesi daima VHDX’in ilk oluşturulduğu an ile aynıdır çünkü fiziksel HDD üzerine yazılmış sektörler değişmez.
Yapıya göre değişmekle birlikte fixed size vhdx’ler genellikle yüksek boyutlu dosyalardır ve çoğaltırken, farklı bir alana taşırken veya örneğin Hyper-V Replica ile DRC’ye replike ederken biraz can sıkıcı olabilirler çünkü aslında boş olan o asla 200GB paçanızı bırakmaz :)
Pek dikkat edilmez ama aklınızda bulunsun: Eğer fixed size vhdx ile çalışan bir sanal makine üzerinde Checkpoint alırsanız o noktada bir zincir oluşumu başlar ve ucuna aslında Dynamically Expanding sanal disk türüne çok benzeyen ama uzantısı AVHDX olan bir Differencing disk bağlanır. Checkpoint sanal makine üzerinde durduğu sürece hem zincir yapısındaki ufak gecikme sebebiyle, hem de Dynamically Expanding sanal disk türünün Fixed Size türe oranla biraz daha yavaş kalması nedeniyle performans kayıpları yaşanabilir.
Fixed size sanal diskler, sadece VHD formatını kullanabilen belirli Hyper-V sürümlerine kadar Exchange Server gibi, SQL Server gibi birçok önemli iş yükü için resmi olarak desteklenen tek sanal disk türüydü. Windows Server 2012 Hyper-V ile birlikte bu durum ortadan kalkmış olsa da aklınızın bir köşesinde bulunsun, işyükünün desteklediği veya önerdiği disk türlerine göz atmak her zaman iyi bir fikirdir.
Henüz içerisinde herhangi bir veri yer almayan 4TB kapasiteli bir Dynamically Expanding VHDX oluşturduğunuzda .vhdx dosyasının boyutu yaklaşık 3-4mb civarındadır ve bu aşamada fiziksel disk kapasitesinin teknik olarak bir önemi yoktur. Ancak bu vhdx dosyası içerisine veri yazıldıkça büyür ve başta belirlediğiniz örneğin 4TB’a kadar genişleyebilir; bu noktada genişleyebileceği fiziksel alana ihtiyaç duyar.
Oluşturulma süresi oldukça kısadır. 1-2 saniye diyelim.
Genellikle fazla yoğun olmayan disk aktiviteleri için önerilir ve yeni sürümlerde canlı ortamda kullanımı da desteklenir.
Dynamically Expanding vhdx dosyaları veri yazıldıkça genişler ancak veri silindikçe daralmaz. Bu yüzden içerisinden önemli ölçüde veri silinmiş Dynamically Expanding vhdx’leri daraltmak için Optimize-VHD işlemi uygulamak gerekir. Mesela maksimum size’ı 500GB olan bir Dynamically Expanding sanal disk içerisinde 200GB veri yer alıyor ve vhdx dosyasının boyutu da yaklaşık 200GB. Sanal disk içerisine 100GB daha veri yazdığınızda vhdx dosyasının boyutu yaklaşık 300GB’a ulaşır. Ardından 100GB veri sildiğinizde, sanal işletim sistemi içerisinden bakıldığında ilgili volume için kullanılan alan 200GB göründüğü halde fiziksel disk üzerindeki vhdx dosyasının boyutu 200GB’a gerilemez ve 300GB yer kaplamaya devam eder. Çözüm belirli zamanlarda Optimize-VHD uygulamak.
Fiziksel depolama alanını daha verimli kullanmanıza yardımcı olur ancak plansız büyüdükleri taktirde fiziksel depolama alanını taşırma ve içerisinde çalışan tüm sanal makineleri bir anda durmdurma ihtimalleri vardır. Bu yüzden Dynamically Expanding sanal disklerin makismum kapasiteleri iyi belirlenmeli ve fiziksel depolama katmanı ani genişlemelere karşı mutlaka izlenmelidir. Mesela bu işi takip etmek için Get-HypervReport.ps1’in Storage Overcommitment özelliğini kullanabilirsiniz.
Bu türdeki bir sanal diskin VHDX dosya boyutu Fixed Size VHDX’e göre genelde daha düşük olur ve host level yedekleme sırasında daha az yer kaplar ve büyük ihtimalle daha kısa sürede yedeklenir.
Bir Dynamically Expanding vhdx’i sanal makine çalışır durumdayken kolayca genişletebilirsiniz.
Block level fragmentation yüzdesi değişkendir. Zaman içerisinde yeni veriler yazılıp silindikçe ciddi anlamda fragmentation oluşabilir. Get-HypervReport.ps1 ile takip edebilirsiniz.
Eğer dynamically expanding vhdx ile çalışan bir sanal makine üzerinde Checkpoint alırsanız o noktada bir zincir oluşumu başlar ve ucuna aslında Dynamically Expanding sanal disk türüne çok benzeyen ama uzantısı AVHDX olan bir Differencing disk bağlanır. Checkpoint sanal makine üzerinde durduğu sürece performans açısından yaşanabilecek en önemli olumsuzluk zincir yapısından kaynaklı gecikme olabilir.
Windows Server 2012 Hyper-V ve sonraki sürümlerde, önemli iş yüklerinin neredeyse tamamı dynamically expanding vhdx’ler üzerinde resmi olarak desteklenir.
Çalışabilmek için bir parent vhdx’e ihtiyaç duyar.
Bir parent vhdx’e birden fazla differencing vhdx bağlanabilir.
Oluşturulma süresi oldukça kısadır.
Genellikle fazla yoğun olmayan disk aktivitelerinde ve VDI senaryolarında kullanılır.
Birçok açıdan Dynamically Expanding karakteristiği taşır.
Block level fragmentation yüzdesi yine değişkendir. Zaman içerisinde yeni veriler yazılıp silindikçe ciddi anlamda fragmentation oluşabilir. Get-HypervReport.ps1 ile takip edebilirsiniz.
Yoğun disk aktivitesi gerçekleştiren sistemler ve kritik iş yükleri için önerilmez.
Yazı Etiketleri: Hyper-V , Sanal Disk , VHD
• Get-HyperVReport.ps1 v1.5 is released!
10.02.2016 - 19:27
Ellerine sağlık hocam harika bir makale olmuş.
Ellerinize sağlık, çok güzel anlatmışınız.
19.09.2016 - 19:56
Bare Metal Server üzerinde, Server 2012 R2 Std. işletim sistemi kurulu. Bu sistem üzerinde yer alan ve total size 3 TB. içinde de 1,8 TB data bulunan D Partition’ı yeni yaratmış olduğum Hyper-V makinesine ek sanal disk olarak bağlamak istiyorum.
Sorum şudur ki; D içinde yer alan 1,8 TB’lık data kaybolmadan ve yüksek performans alma hedefiyle bu Partition’ı nasıl yeni Hyper-V makineme bağlayabilirim?
Şimdiden çok teşekkür eder, başarılarınızın devamını dilerim.
ibrahim bayraktar – Pass-through disk olarak bağlayabilirsin. Pass-through diskler temelde VHD’ler gibi olmadığı için yukarıdaki yazıda yer almıyor.
Bir Hyper-V Host üzerindeki fiziksel diski, içerisinde veri (partition/data) olsa dahi, doğrudan ve içerisindeki veriye zarar vermeden bir VM’e bağlamak mümkün. Hyper-V terminolojisinde buna pass-through disk diyoruz. Uygulama adımları basitçe aşağıdaki gibi.
1) Öncelikle ilgili fiziksel disk içerisindeki partition’lara access olmadığından emin ol. (açık dosyalar, o sürücüde çalışan uygulamalar olmasın)
2) Host üzerinde ilgili diski “offline” konuma çek. (diskmgmt.msc’den yapabilirsin)
2) VM’i kapat, yeni bir “hard disk” ekle ve bir VHD göstermek yerine hemen alt bölümdeki “physical hard disk” seçeneği ile az önce offline’a çekilen diski göster. (Host üzerindeki offline diskler burada listelenir)
3) VM’i başlat, bu sefer Guest OS içinde yine diskmgmt.msc ile diski “online” konuma çek. Ardından partition’lar VM içerisinde erişilebilir olur. (Eğer sürücü harfi çakışması olur ise manuel olarak sürücü harfi atayabilirsin)
Not: Fiziksel disk seviyesinde uygulanan bir özellik olduğu için aynı fiziksel disk içindeki D: E: F: gibi tüm partition’lar VM’e bağlanmış olur. Bu yüzden mesela Host OS (C:) ve data (D:) sürücüleri aynı fiziksel disk üzerinde ise, sadece D: sürücüsünü bu şekilde aktarma şansın yok. Bu durumda D: içeriğini bir VHDX’e kopyalayarak bağlamak en mantıklısı olacaktır.
– Pass-through diskler Host üzerinde sabit olduğu için bağlı olan VM’in de mobility’sini etkiler; birçok durumda VM’i LM/QM gibi aktarım teknolojileriyle farklı Host’lara taşıyamazsın.
– Başlamadan önce mümkünse yedek al.