Hyper-V üzerindeki Snapshot kavramını şu şekilde tanımlamak mümkün: VM’in (Sanal Makine) o anki durumunun görüntüsünün alınması (Çalışır durumda ya da kapalıyken) ve bu görüntü noktasının ilerleyen zamanlarda geri dönülebilmek üzere rezerve edilmesi işlemidir.
Alınan snapshot içerisinde ise aşağıda listelediğim dört temel bilgi bulunur.
Yeni AVHD dosyası/dosyaları (Boştur ve VHD’nin kopyası değildir),
Donanım ve yapılandırma bilgisi (Configuration File – XML),
Bellek içeriği (Memory Content – BIN File) (Sadece VM up durumdayken alınan snapshotta)
Diğer destek bilgileri (VSV File) (Sadece VM up durumdayken alına snapshotta)
Daha genel bir tanım ile sanal makineyi o anki hali ve tüm sanal disk içeriği ile yedekliyoruz (aslında işaretliyoruz), ilerleyen günlerde ya da testlerimizi tamamladıktan sonra sistemi snapshot aldığımız zamana geri döndürebiliyoruz.
Snapshot kavramı Hyper-V dışındaki sanallaştırma teknolojilerinde de yer alan bir özellik. Tabi her üretici bu özelliği kendine göre dizayn etmiş ve farklı mimarilerde kullanıma sunmuştur. Amaçlanan aynı olsa dahi bu özellik arka planda farklı şekillerde işlemektedir. Bu doğrultuda Hyper-V üzerinde kullanılan snapshot alt yapısının diğer vendor’ların üretmiş olduğu sanallaştırma ürünlerinde kullanılan snapshot alt yapılarına göre farklılıklar gösterdiğini söyleyebiliriz.
Bu makale serisinde Hyper-V Snapshot yapısını ayrıntılı olarak ele alıyoruz.
İlk bölümde (Hyper-V Snapshot Kavramı): Snapshot kavramı, kullanım amaçları, nasıl çalıştığı, neleri içerdiği/yedeklediği konularını yani background’u inceliyoruz.
İkinci bölümde (Hyper-V Snapshot İşlemleri): Snapshot almak, alınmış bir snapshot’a geri dönmek ve snapshot silme işlemleri ile bu işlemlerin VHD/AVHD ve fiziksel partition’lar üzerindeki etkilerini inceleyeceğiz.
Üçüncü bölümde (Hyper-V Snapshot Özellikleri ve Tavsiyeler): Snapshot özellikleri ve snapshot’lar ile çalışırken dikkat edilmesi gereken noktaları inceleyeceğiz.
Yukarıda snapshot tanımını kısaca yaptıktan sonra bu özelliğin ne amaçla, hangi durumlarda kullanıldığını birkaç örnek senaryo ile inceleyerek başlayalım.
Örneğin Hyper-V üzerinde çalışan bir VM ile Terminal Services hizmeti veriyoruz. Bu sanal makine üzerinde Windows Server 2003 SP1 kurulu ve biz bu sistem üzerine SP2 geçmeyi planlıyoruz.
Bilindiği üzere Service Pack’ler üretici tarafından yayınlanan, yazılımlar üzerinde ciddi değişiklikler ve geliştirmeler yapan paketlerdir. Bu nedenle SP yükleme işlemlerinde risk unsuru her zaman mevcuttur. SP yüklemesinden sonra açılmayan sistemlere yada corrupt olan uygulamalara mutlaka denk gelmişsinizdir. Birde senaryomuzdaki gibi production ortamda hizmet veren bir sunucunun başına böyle bir durum gelmesi eminim hiç kimsenin hoşuna gitmez.
Fiziksel olarak çalışan bir sunucuda SP yükleme işlemini yapmadan önce mutlaka çalışan uygulamaların yedeklerini alırız ve ya imaj programları ile system partition ve ya ilgili partition’ların imajlarını alırız ki bir felaket anında hızlı geri dönüş şansımız olabilsin. İşte sunucu sanallaştırma teknolojilerinin IT yapılarına katmış olduğu avantajlardan birisi olan snapshop özelliği ile bu gibi durumlar için daha kısa sürede önlemler almak mümkün.
Örnek senaryomuzdaki VM üzerine SP yüklemeden hemen önce bir snapshot alırız ve daha sonra SP yükleme işlemini gerçekleştiririz. Eğer ki SP yükleme işleminde bir sorun meydana gelirse (ki bu sorun sanal işletim sisteminin açılmaması dahi olabilir) sistemi almış olduğumuz snapshot noktasına hızlıca geri döndürüp SP yüklemeden önceki çalışır duruma getirebiliriz. Geri dönüş işlemi dakikalar içerisinde gerçekleşebilir. Fiziksel dünyada bu işlemin alacağı zamanı ve iş süreçleri üzerindeki olumsuz etkisini yorumlamayı ise size bırakıyorum J
Bir başka senaryoda ise şunu kurgulayabiliriz:
Firmamızda yazılım geliştirme departmanı var ve Hyper-V üzerinde çalışan test sistemlerine sahipler. Üzerinde çalıştıkları yazılımları geliştirmek adına işletim sistemini ciddi anlamda kurcalıyorlar ve genellikle de bozuyorlar J. Olay çoğu zaman işletim sisteminin yeniden kurulmasına kadar gidebiliyor. Böyle bir durumda testlere başlamadan önce bir snapshot, testler sırasında ise belirli periyotlarda farklı snapshot’lar alınabilir, daha sonra bu snapshot’lara hızlı geri dönüşler gerçekleştirilebilir. Böylece daha esnek bir test ortamı sağlamış, zamandan da tasarruf etmiş oluruz.
Farklı bir senaryoda ise çalışan sanal sistem üzerinde ciddi bir değişiklik yapmamız gerekiyor olabilir. Örneğin sunucu üzerine yeni bir role ekleyeceğiz ama bu rolün sağlıklı çalışıp çalışmayacağından, çalışmıyor ise bu rolü remove ettiğimiz zaman sistemde bir sorun meydana gelip gelmeyeceğinden emin olamıyoruz. Bu durumda işlemlere başlamadan önce bir snapshot alırız ve işimiz bittikten sonra sistemin çalışmasından memnun değilsek her şeyi ilk haline hızlıca geri döndürebiliriz.
Daha ilginç bir senaryoda ise şunu örneklemek istiyorum:
Sanal sistem için bu gün bir snapshot aldınız ve 3 gün sonra sisteme virüs bulaştı. Mevcut araçlar ile de temizleyemiyorsunuz. Ama korkmanıza gerek yok. Virüsü uçurmak için aldığınız snapshot’a geri dönmeniz yeterli J. Tabi bu senaryo için bazı özel durumlar söz konusu. Örneğin sistemi geri döndürdüğünüzde Virüsle beraber 3 günlük verilerde geri gidiyor olabilir. Bu nedenle bu senaryo için sanal sistem ve üzerindeki veri yapısını iyi tasarlamalı, önemli verileri snapshot ile geri dönmeyecek birimlerde saklamalısınız.
Snapshot’ların kullanım amacı ile ilgili kafanızda bir tanım oluşmuş olmalı.
Doğru kullanıldığı taktirde gerçekten hayat kolaylaştıran ve zaman kazandıran bir özellik olmakla birlikte her teknolojide olduğu gibi snapshot özelliği için de dikkat edilmesi gereken bazı noktalar mevcuttur. Aksi durumda geri dönüşü olmayan veri kayıpları yaşanması mümkündür. Makalenin ilerleyen bölümlerinde snapshot kavramının derinlerine indikçe söylemek istediğimi daha iyi anlayacaksınız.
Peki Hyper-V üzerinde nasıl snapshot alıyoruz?
Hyper-V Manager yönetim konsolu ya da System Center Virtual Machine Manager 2008 ile snapshot’lar almak mümkün. Ben Hyper-V Manager ile devam ediyorum çünkü herkesin yapısında VMM2008 bulunmayabilir.
Hyper-V Manager konsolunda işlem yapmak istediğimiz VM’i seçtikten sonra aşağıda gibi snapshot komutunu uygulamamız yeterli. Saniyeler içinde snapshot işlemi tamamlanır.
Bu işlemlere yazının ilerleyen bölümlerinde ayrıntılı olarak değineceğim için şimdilik girmiyorum çünkü öncelikle snapshot background’unu inceleyeceğiz.
Bir VM’in nelerden oluştuğunu inceleyerek başlayalım.
Hyper-V üzerinde yeni bir VM (sanal makine) yaratıldıktan sonra Parent Partition üzerinde aşağıdaki dosyalar ile var olur.
Virtual Machine Configuration File: VM create işlemi sırasında oluşur ve içerisinde sanal donanım bilgileri, sanal disklerin konumları, sanal NIC’in MAC adresi ve hangi sanal switch üzerinde hangi sanal portta çalıştığı, yüklü ise integration components servis durumları gibi VM’e ait çeşitli yapılandırma bilgileri bulunur. VM üzerine yeni bir donanım eklediğinizde bu bilgi o VM’e ait ilgili XML içerisine yazılır. Bu dosyanın ismi ise o VM’in sistem tarafından üretilen GUID’i ile aynıdır. Bu GUID unique bir veridir.
Yukarıda Virtual Machines dizini içindeki XML dosyasını görüyorsunuz. Açıp içeriğini inceleyebilirsiniz yalnız hangi tag’in ne anlama geldiğini bilmiyorsanız değişiklik yapmayın.
Yine yukarıdaki ekran görüntüsünde XML dosyasının hemen üstündeki klasör ise BIN ve VSV dosyalarının bulunduğu dizindir. BIN ve VSV dosyaları VM çalışır durumdayken vardır ve bunlar Saved State dosyalarıdır.
BIN File: Sanal makinene çalışırken vardır ve sanal makinenin bellek içeriğinin yazıldığı dosyadır (bir nevi page file).
VSV File: Yine sanal makine çalışırken vardır ve sanal makine için diğer işlem destek bilgilerinin tutulduğu dosyadır.
Bu iki dosya sanal makinenin yaratıldığı path altında otomatik olarak yaratılan ve sanal makinenin eşsiz GUID ‘i ile aynı isme sahip bir dizin içinde durur. Dosyaların isimleri de yine aynı GUID’e sahiptir. Unutmayın, BIN ve VSV dosyaları sadece VM açık durumdayken kullanılır, VM kapalı ise BIN ve VSV dosyası ilgili path altında göremezsiniz.
Virtual Hard Disk (VHD): Sanal disklerdir. İki temel tip yani Dynamically Expanding veya Fixed Size olabilirler (Differencing 3ncü tiptir ama kullanım amacı biraz farklıdır). Sanal disklerin uzantısı VHD dir. Dynamically Expanding veya Fixed Size tipindeki her sanal disk, Parent Partition üzerinde duran birer dosya ile temsil edilirler. Birde Pass-through disk çeşidi vardır ancak bu makalede bu konuya girmiyoruz.
VHD dosyaları herhangi bir path altında durabilir ve sanal makineden bağımsız olarak yaratılabilirler. Aşağıdaki C.VHD dosyası ilgili VM’in C sürücüsünün bulunduğu sanal diski temsil ediyor (isim temsilidir)
VM ve VHD dosyalarının bulunacağı default lokasyonu değiştirebiliriz ve bundan daha önceki makalelerimizde bahsetmiştik. Hatırlamak gerekirse,
Ayrıca snapshot’ların saklanacağı lokasyonu da değiştirme şansımız var. Default olarak Virtual Machine dosyaları ile aynı dizinde saklanır. Eğer değiştirmek isterseniz,
İlgili sanal makineyi seçtikten sonra yukarıdaki gibi değiştirebilirsiniz. Ayar VM bazlıdır yani tek bir sanal makineye etki eder.
Toparlarsak;
Çalışan bir sanal makine:
XML uzantılı bir configuration dosyasına,
Sanal disk sayısına göre bir yada daha fazla sayıda VHD dosyasına,
Bellek/işlem bilgilerinin tutulduğu BIN ve VSV dosyalarına sahiptir.
Peki snapshot işlemi nasıl gerçekleşir?
Snapshot adımlarına geçmeden önce AVHD disklerden bahsetmek istiyorum.
Sanal disklerin uzantısının VHD olduğunu biliyoruz. Bir makine için snapshot alındığında AVHD uzantılı yeni bir sanal disk yaratılır ve VHD dosyasına bağlanır. Snapshot işleminden önce sanal makine içerisine eklenen her türlü veri (bu veri kurulan programlar, download edilen dosyalar vs.. gibi her şey olabilir) ilgili VHD dosyası içerisine yazılırken, snapshot işleminden sonra eklenen her türlü veri AVHD dosyası içerisine yazılmaya başlar. Artık VHD dosyasına yeni veri eklenmez ancak VHD dosyası içerisindeki eski veriler okunmaya devam eder.
Yukarıda iki snapshot’a sahip sanal makinenin sanal disk yapısını görüyorsunuz. Snapshot yapısında AVHD dosyaları ile VHD dosyası arasında parent-child ilişkisi vardır ve bu nedenle diferrencig olarak tanımlanabilirler.
Zincirdeki AVHD dosyası tek başına bir anlam ifade etmez. Yani bu dosyayı herhangi bir VM’e gösterip içeriğini göremeyiz çünkü Parent VHD ye ihtiyaç duyar. Zincirdeki AVHD’lerden ilkinin başına bir şey gelirse, ondan sonra gelen AVHD dosyasındaki veriler de kullanılamaz hale gelir (yani sonraki snapshot’lar).
Toparlarsak; AVHD dosyası çoğunlukla sanpshot özelliğinde karşımıza çıkan, differencing tipte ve Parent VHD’e bağlı bir sanal disktir. Tek başına bir anlam ifade etmez ve parent disk’e ihtiyacı vardır.
Gelelim snapshot adımlarına. Snapshot aksiyonunu VM açıkken ve kapalıyken olmak üzere iki farklı senaryoda gerçekleşir.
VM kapalıyken ilk kez snapshot alındığında:
1. VM’in bulunduğu dizinde snapshot isimli yeni bir dizin yaratılır. (default durum – daha önce yaratılmamışsa)
2. Snapshot dizini altında iki yeni dizin daha yaratılır.
2.1 Bir dizin VMGUID ile aynı isme sahiptir ve içinde AVHD dosyaları saklanacaktır.
2.2 Diğer dizin için ise rastgele bir GUID yaratılır ve bu ismi alır (SNAPGUID diyebiliriz). İçinde BIN ve VSV dosyalarının kopyaları saklanacaktır. Ama bu senaryoda VM kapalı olduğu ve memory ile ilgili herhangi bir işlem olmadığı için ortada BIN ve VSV dosyaları yoktur (hatırlarsanız bu durumun nedeninden az önce bahsetmiştik). Bu nedenle bu dizin boş olarak kalır.
3. VM’in o anki configuration bilgisini tutan XML dosyasının bir kopyası sanapshot dizini altına alınır ve dosyanın ismi rastgele üretilen SNAPGUID ile aynı olur (Aynı SNAPGUID 2.2 adımda da kullanılmıştı) Bu ilk snapshot olduğu için ayrıt etmek adına SNAP1GUID diyebiliriz.
4. 2.1 adımında yaratılan dizin içerisinde DiskName_RandomGUID şeklinde isime sahip, uzantısı ise AVHD olan yeni bir child disk yaratılır. Bu uzantının snapshot disk (differencing disk) uzantısı olduğundan bahsetmiştik.
5. Son olarak VM dizininde duran orijinal XML dosyası içerisinde pathname type tag’ı düzenlenir ve eski VHD dosyası yerine yeni AVHD dosyasının path’i yazılır.
Bu adımları az sonra diagram üzerinde yeniden inceleyeceğiz.
Şimdi ise VM açıkken snapshot alındığında neler oluyor bir göz atalım.
VM açıkken ilk kez snapshot alındığında:
1. VM’in bulunduğu dizinde snapshot isimli yeni bir dizin yaratılır. (default durum – daha önce yaratılmamışsa)
2. Snapshot dizini altında iki yeni dizin daha yaratılır.
2.1 Bir dizin VMGUID ile aynı isme sahiptir ve içinde AVHD dosyaları saklanacaktır.
2.2 Diğer dizin için ise rastgele bir GUID yaratılır ve bu ismi alır (SNAPGUID diyebiliriz). İçinde BIN ve VSV dosyalarının kopyaları saklanacaktır. Bu senaryoda VM açık olduğu için BIN ve VSV dosyaları kullanımdadır ve bir kopyaları bu dizine alınacaktır.
3. VM’in o anki configuration bilgisini tutan XML dosyasının bir kopyası sanapshot dizini altına alınır ve dosyanın ismi 2.2 adımda üretilen SNAPGUID ile aynı olur.
4. Açık olan sanal makine tarafından kullanılan BIN ve VSV dosyalarının birer kopyası 2.2 de yaratılan dizin içerisine alınır.
5. 2.1 adımında yaratılan dizin içerisinde DiskName_RandomGUID şeklinde isime sahip, uzantısı ise AVHD olan yeni bir child disk yaratılır.
6. Son olarak VM dizininde duran orijinal XML dosyası içerisinde pathname type tag’ı düzenlenir ve eski VHD dosyası yerine yeni AVHD dosyasının path’i yazılır.
Aslında VM kapalıyken alının snapshot’tan tek farkı, VM açık olduğu için kullanımda olan BIN ve VSV dosyalarının da kopyalanıyor olması.
Bu adımları birde diagram üzerinde biraz daha gerçekçi bir senaryo ile inceleyelim.
Aşağıda Hyper-V üzerinde çalışan bir VM görüyorsunuz. XML, VHD, BIN ve VSV dosyaları ise Parent OS üzerindeki ilgili dizinler içerisinde duruyor ve VM bunları kullanıyor.
BIN ve VSV dosyaları VM çalışır durumda olduğu için kullanımda ve şu an yazılan her veri VHD dosyasına ekleniyor.
Bu noktadayken XML dosyasının içeriğini açarsanız disk olarak VHD uzantılı dosyayı kullandığını görebilirsiniz.
Senaryo gereği yeni bir uygulama test etmemiz gerekiyor ve sanal makine üzerine bu uygulamayı yükleyip çalışır hale getiriyoruz. VHD dosyasının Parent OS üzerinde şu anki boyutunu 30GB olarak kabul ediyoruz.
Senaryo gereği kurmuş olduğumuz uygulama için update’ler geçmemiz gerekiyor ve ayrıca işletim sistemi için de SP yükleyeceğiz. Bu işlemlere başlamadan önce 15.04.2009 tarihinde önlem olarak bir snapshot alıyoruz.
İlk snapshottan sonra mimari aşağıdaki gibi oluyor
Sanal makine eski XML, BIN ve VSV dosyalarını kullanmaya devam ediyor (köşeleri kırmızı olan kopyalar). Snapshot aksiyonu olarak bu dosyalar o anki durumları ile yedeklenip yukarıdaki adımlarda bahsetmiş olduğumuz dizinler içerisine kopyalanıyor (Köşeleri yeşil olan kopyalar – Bu kopyalar 15.04.2009 tarihindeki duruma ait) ve daha sonra kullanılmak üzere rezerve ediliyor.
Ek olarak yine yukarıdaki adımlarda bahsettiğim ilgili path altında AVHD uzantılı yeni ve boş bir sanal disk dosyası yaratılıyor. Bu dosya Parent VHD ile parent-child ilişkisine geçiyor. AVHD ilk yaratıldığında boyutu oldukça küçüktür. Sadece VHD’e bağlı ve veri eklendikçe boyutu artacak bir birimdir. Yani AVHD dosyası VHD dosyasının kopyası değildir. Bu arada VHD dosyası hala 30GB boyutunda.
Son olarak sanal makinenin artık verilerini AVHD içerisine yazması için, kullanımda olan (kopyası alınan değil) XML dosyasının içeriği editleniyor ve pathname type olarak AVHD dosyasının path’i yazılıyor.
Bu noktadan sonra sanal makine içine eklenen her türlü veri, üzerinde yapılan her türlü işlem artık AVHD dosyasına yazılmaya başlıyor.
Senaryomuzdaki sanal makine üzerinde çalışan uygulama için updates geçiyoruz ve sanal işletim sistemine SP yüklüyoruz.
Şu noktada VHD/AVHD boyutları aşağıdaki gibidir.
Parent VHD :30GB
15.04.2009 snapshot için yaratılan AVHD :2GB
Bu rakamlar sanal makine içerisinde örneğin C sürücüsündeki 32GB veriyi temsil eder. Gördüğünüz gibi snapshot işleminden sonra yapılan update’ler ve SP yükleme işlemi ile gelen geliştirmelerin (verilerin) hepsi AVHD dosyasına yazılmış durumda. VHD ise aynı boyut ile duruyor.
Peki bir snapshot daha alırsak ne olur?
20.04.2009 tarihinde bir snapshot daha alıyoruz. İkinci snapshottan sonra dagram aşağıdaki gibidir.
Sanal makine yine eski XML, BIN ve VSV dosyalarını kullanmaya devam ediyor (köşeleri kırmızı olan kopyalar). Snapshot aksiyonu olarak bu dosyalar o anki durumları ile yeniden yedeklenip ilgili dizinler içerisine kopyalanıyor (Köşeleri mavi olan kopyalar – Bu kopyalar 20.04.2009 tarihindeki duruma ait) ve yine daha sonra kullanılmak üzere rezerve ediliyor.
Ek olarak ilk AVHD dosyasının bulunduğu dizinde ikinci ve boş bir AVHD dosyası daha yaratılıyor. Bu dosya da Parent VHD ve ilk AVHD ile parent-child ilişkisine geçiyor ve aşağıdaki gibi zincirin bir halkası oluyor.
Son olarak sanal makine verilerinin ikinci AVHD içerisine yazması için, kullanımda olan XML dosyasının içeriği yeniden editleniyor ve pathname type olarak 2nci AVHD dosyasının path’i yazılıyor.
Yine senaryo gereği 2nci snapshottan sonra sanal makine içerisine 15GB veri eklediğimizi var sayalım. Bu durumda size’ı değişen dosya aşağıdaki gibi ikinci AVHD olacaktır.
Parent VHD :30GB
15.04.2009 snapshot için yaratılan 1. AVHD :2GB
20.04.2009 snapshot için yaratılan 2. AVHD :15GB
Bu rakamlar yine sanal makine içerisinde örneğin C sürücüsündeki 47GB veriyi temsil eder (Bu arada rakamlar temsilidir, boyutlar değişiklik gösterebilir). Sonraki snapshot’lar da aynı mantık ile devam etmektedir.
Herhangi bir nedenle 15.04.2009 tarihinde aldığımız snapshot’a geri dönmek istersek, ilgili snapshot’a sağ tıklayıp Apply dememiz yeterli. Bu durumda sistem 15.04.2009 tarihindeki yazılım updates ve SP yüklenmemiş duruma dönecektir.
Bu konular (snapshot’a geri dönmek, snapshot’ı silmek ve merge) bir sonraki makalede inceleyeceğimiz için şimdilik ayrıntıya girmiyorum.
Hyper-V üzerindeki snapshot özelliği bu şekilde çalışmakta. Buraya kadar anlattıklarım sıralı snapshot alma işlemleri ve snapshot alınması esnasındaki background aksiyonlarını içermektedir.
Bir sonraki bölümde konularını inceleyeceğiz.
Serhat AKINCI – IT Professional
