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 üç farklı Cluster Shared Volume’ yi görebilmektesiniz. Volume1, Volume2, Volume3 isimli storage' ler üzerinde mevcut VM dosyaları barınmaktadır ve özellikle Volume 1 isimli Storagemiz sınırlara yaklaşmak üzeredir.
Migrate Storage işlemlerini yapmamız için temel nedenlerimiz;
· 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 her zaman olasıdır.
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;
· 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.
· Üçü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.
· HyperV 3.0 Kullanıyorsak HyperV Replica Özelliğini yapılandıracağız ve VM’ i bir hostdan diğer bir hosta taşıyacağız. Bu işlemi yaparken yeni storageyi seçebilmekteyiz.
VMM yazılımına sahip durumda değilsek bizleri iyi planlamamız gereken bir iş akışı beklemektedir.
Taşımayı planlamış olduğumuz R2DC1 isimli sanal sunucumuzun vhd ve barınmış olduğu CSV bilgilerini görebilmekteyiz.
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ılanacaktır ve 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 yapılandırabiliriz.
Sanal makinemizin sahip olduğu her bir Vhd dosyasını ayrı Volumelere taşımak istersek Allow Vhds to placed individuallyözelliğini kullanmamız gerekecektir.
Senaryomuz içinde sanal makinenin sahip olmuş olduğu bütün verilerin taşınması gerektiğini belirtiyorum ve bu sebepten Automatically place all Vhds with the configuration seçimini yapıyorum.
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, taşımak istediğim Volume seçiyorum.
Taşımak istediğim Volume üzerinde sanal bilgisayarımızın barınmış olduğu HyperV Host’ un erişilebilir durumda olması gerekmektedir.
İşlemler başladığı zaman taşıma işlemini Job’s bölümünden izleyebiliyorum.
Taşıma işlemleri gerçekleştirilirken taşımış olduğum sanal makine hizmet edebilir durumdadır.
VMM2012 ile birlikte gelen yeni bir özellik ise taşıma işlemleri sırasında SnapShot almamasıdır. Bu özellik VMM2008 üzerinde bulunuyordu ve en büyük fark olarak SnapShot almamasını söyleyebiliriz.
Yukarıda son durumu görebilmekteyiz. VMM yazılımı mevcut storage' dan yeni storage üzerine sanal bilgisayarlarımızı taşımıştır.
Sanal bilgisayarımızın özelliklerine baktığımız zaman VHD yolunun değiştiğini görebiliyoruz.
Taşıma işlemleri tamamlandıktan sonra HyperV Cluster kümesi içinde bulunan Storage’ lerimizin durumunu görüyoruz. Volume 1 üzerinde biraz olsun yer kazandık ve sanal makinemizi Volume3’ e taşıdık ve yük dengelemesini sağladık.
Sanal makinemizin verileri artık yeni lokasyonda barınmaktadır. Bu makaleyle birlikte VMM ile kazanmış olduğumuz avantajlara bir örnek daha vermek istedim. 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.