Sanal ortamlarımız içinde barınan Virtual Machine Dosyaları (Vhd ve VM) organizasyonumuzun büyümesiyle birlikte büyüme göstereceklerdir ve bu sebepten ötürü Sahip olduğumuz bu Virtual Machine verileri, ilerleyen zaman içinde barınmış oldukları Storage sığamayacaklardır. Bu durumu yaşanılması muhtemel nedenlerle örnekleyelim.
,
Yukarıdaki ekran görüntüsü içinde HyperV Hostlarımıza tanımlanmış bulunan dört farklı Cluster Shared Volume’ yi görebilmektesiniz. Volume1, Volume2, Volume3 isimli storage' ler üzerinde mevcut VM dosyaları barınmaktadır ve özellikle Volume 3 isimli Storagemiz sınırlara yaklaşmak üzeredir. Migrate Storage işlemlerini yapmamız için temel nedenleri;
· Sahip olduğumuz bu storage’ ler dolmak üzere ve VM’ lerimiz için yetersiz olduğunu düşünelim.
· VM’ lerin barınmış olduğu storage’ ler üzerinde yük dengelemesi yapmak ve daha iyi disk I/O elde etmek için Storageler arasında VM’ leri taşıma ihtiyacı olabilir.
· VM’ lerimizin barınmış olduğu Mevcut Storagemizi değiştireceğiz. Daha yeni bir storage' ı kullanacağız ve bu sebepten ötürü eski storagemiz üzerindeki VM’ leri yeni storage üzerine taşıma ihtimali olabilir.
· Mevcut VM’ lerimiz Storage üzerinde SAS diskler üzerindedir. SAS diskler pahalıdır ve Test sunucularımızı yeni almış olduğumuz SATA diskler üzerinde çalışmasını isteyebiliriz.
Özetlememiz gerekirse, IT iş akışlarını ve süreçlerini düşünürsek bu ve benzeri senaryolarla karşılaşmamız an meselesidir.
Yukarıdaki senaryolardan bir tanesiyle karşılaştığımız zaman yapmamız gereken işlemler nelerdir?
Virtual Machine Manager yazılımına sahip değilsek eğer mevcut VM’ leri HyperV Hostlar üzerinde Export-Import işlemini yapmamız gerekecektir. Sanal bilgisayarlarımızı kapatacağız ve taşınacak olan Sanal bilgisayarımız ulaşılmaz durumdayken mevcut Storage dizininden export edip, yeni storage üzerine import edeceğiz. Sanal makinelerin sahip olmuş olduğu veri büyüklüğüne bağlı olarak işlemler uzun bir zaman alacaktır. Veya üçüncü bir yedekleme yazılımıyla sahip olduğumuz sanal bilgisayarların Host Base yedeklerini alacağız ve recovery işlemini yeni storagemiz üzerine yapıp, bu yeni storage üzerinden çalışmasını sağlayacağız.
VMM yazılımına sahip durumda değilsek bizleri iyi planlamamız gereken bir iş akışı beklemektedir.
Virtual Machine Manager yazılımına sahip durumdaysak işlemlerimiz çok daha kolaydır. Yeni Storagemizi HyperV Fail Over Cluster Kümesine yeni bir CSV olarak tanımlayacağız. Bu değişiklik VMM tarafından algılanacak olup yeni Storage' ı VMM görebilir duruma gelecektir. Bu işlemi yaptıktan sonra Taşımak istediğimiz Sanal bilgisayar çalışır durumdayken üzerinde Migrate Storage işlemine başlayacağız.
Migrate Virtual Machine Wizard ekranında seçmiş olduğumuz VM’ in mevcut barınmış olduğu storage' ı görebilmekteyiz. Örneğimizdeki gibi bir VM üzerinde birden fazla VHD dosyası olması da muhtemeldir. Sihirbaz içinde istersek bunu Virtual Disk bölümünden her bir Vhd için ayrı ayrı yapabilir veya sadece istemiş olduğumuz VHD’ nin storage öğesini değiştirebiliriz. Bu ekranı görünce başka bir senaryoda gelişmiş olabilir. İlgili VM’ in verilerinin bulunmuş olduğu farklı işletim sisteminin yüklü bulunmuş olduğu farklı bir storage olarak ta yapılandırabiliriz.
Senaryomuz içinde sanal makinenin sahip olmuş olduğu bütün verilerin taşınması gerektiğini belirtiyorum. Virtual Machine Path bölümünde Browse butonuyla mevcut Storage ları listelemiyorum.
Listelenen Storageler HyperV Hostlarıma tanıtmış olduğumuz Cluster Shared Volume özelliğine sahip durumda olan Storage lardır ve taşıma işlemini gerçekleştirebileceğim storage’ ler üzerinde Migration Capable bilgisini görebiliyorum. İlgili Storagemizi seçiyorum.
Storagemizi seçtikten sonra Virtual Machine verilerimizin taşınacak olduğu yeni Migrate Virtual Machine Wizard içinde görebiliyorum.
Summary bölümünde özet bilgileri görüyoruz ve Move butonuyla işlemlere başlayabiliyoruz.
İşlemler başladığı zaman taşıma işlemi gerçekleşen sanal bilgisayarımız VMM yönetim ara yüzünde Under Migration olarak görülüyor ve hizmet edebilir durumda.
Jobs bölümünde, VMM sunucumuzun yapmış olduğu işlemleri adım adım izleyebiliriz. Dikkat ederseniz 1.3 ve 1.4 adımlarında Create checkpoint bölümünde sanal bilgisayarımız için snapshot aldığını görebiliriz.
Taşıma işlemi gerçekleştirilen mevcut sanal bilgisayarımızın verilerinin bulunmuş olduğu mevcut (Volume3) dizini kontrol ediyoruz. Sanal bilgisayarımızın sahip olmuş olduğu her bir .vhd dosyası için .avhd yani snapshot dosyaları oluşmuş durumda.
Sanal Bilgisayarımız VMM sunucusu tarafından taşınırken hizmet etmeye devam ettiğini söylemiştik. Oluşan snapshot ları HyperV Manager üzerinde görebilmekteyiz.
Gerçekleştirmiş olduğumuz işlemler gereği sanal makinelerimiz için kesinti değil ama işlemler süresince performans düşmesi olacaktır. Bu verilere değişen Ping TTL değerlerinden anlayabilmekteyiz.
Snapshot işlemleri tamamlandıktan sonra ve Base Virtual Machine verileri mevcut storage' dan yeni storage ye taşınıyor.
Kopyalama işlemi tamamlandıktan sonra sanal makinelerimiz Save State durumuna geliyor ve erişim kesiliyor. Base Virtual Machine verilerinden sonra snapshot verileri aynı şekilde mevcut storage' dan yeni storage ye taşınıyor. Snapshot verileri taşınırken sanal makinelerimiz Save State Durumunda ve erişilmezdir.
Ve yukarıda son durum karşımızda. MM yazılımı mevcut storage' dan yeni storage üzerine Virtual Machine bilgilerini taşımış, Snapshot verilerini silmiş ve merge işlemini tamamlamıştır
Silinen Snapshot verilerini ve tekrardan erişilebilir duruma gelen sanal makinemizi görebilmekteyiz.
Taşıma işlemleri tamamlandıktan sonra HyperV Cluster kümesi içinde bulunan yeni Storage hazır durumunu görüyoruz. Volume 3 üzerinde biraz olsun yer kazandık ve Volume4 artık kullanabilir duruma geldik.
Sanal makinemizin verileri artık yeni lokasyonda barınmaktadır. Bu makaleyle birlikte VMM ile kazanmış olduğumuz avantajlara bir örnek daha vermek istedik. VMM olmasaydı böyle bir projede yapacak olduğumuz işlemleri, iş yükünü ve kesintinin bizlere verecek olduğu sıkıntı-stresi göz önüne getirmenizi istiyorum.
VMM 2008 R2 nin sahip olmuş olduğu bu özellik Quick olarak adlandırılmaktadır. Yani hızlı aktarma ve sınırlı sayıda kesintiyle bu işlemleri yerine getirebiliyoruz. VMM 2012 ile birlikte Live Migrate Storage özelliği gelecektir ve bu bilgiyi bu makale çatısı altında sizlerle şimdiden paylaşıyorum.