Geleneksel olarak diskler üzerinde adresleme/formatlama işlemleri için Cylinder/Head/Sector(CHS) mantığı kullanılır. Disk üzerindeki plakalarda yapılan bu mantıksal adresleme işlemi üzerinden veriler yazılır ve okunur. Fakat günümüz teknolojisinde kurumsal ortamlarda disklerin yerini alan depolama üniteleri ile birlikle bu işlem de dikkat edilmesi gereken bazı farklılıklar mevcut. Depolama ünitelerinde tek bir diski bir sunucuya atamak yerine, diskler üzerinde oluşturduğumuz bir veri havuzundan belirlediğimiz bir miktarı (LUN) sunucuya atıyoruz. LUN aslında mantıksal olarak diski temsil eden kavramdır. Fakat bu mantıksal disklerin CHS yapıları storage ünitesinin yazılımı tarafından yine mantıksal olarak oluşturulurlar ve gerçekte arka planda her disk için ayrı ayrı adresleme yine depolama ünitesi tarafından yapılmaktadır.  Fiziksel disklerde standart olarak partition'ların 63. sektörden başlayacaktır çünkü sistemin açılması için gerekli MBR alanı 63 sektör kaplamaktadır. Geleneksel fiziksel diskler her zaman 512 byte bloklar bulunur. Ancak depolama üniteleri performans ve verimlilik gibi nedenlerden ötürü genellikle daha yüksek blok boyutları kullanırlar. (NetApp 4KB, EMC 64KB gibi) Hala kullanımda olan bir çok işletim sistemi ilk partition'ı oluştururken partition başlangıç sektörü olarak 63 seçerler. Bu işletim sistemlerine örnek olarak Windows 2003/2000/XP ve çeşitli linux türevleri verilebilir.

Buraya kadarki bilgilerin ışığında aşağıdaki probleme göz atalım. Örnek bir sistem düşünelim; Windows 2003 çalıştırıyor ve bir storage'daki LUN'u kullanıyor. Bu durumda aşağıdaki gibi bir durum oluşacaktır. 

Windows üzerinde oluşturulan NTFS partition'ın cluster'ları SAN'deki LUN'un disk chunk'larına bire bir örtüşmeyecektir. Aslında bunun sebebi partition'un 63. sektörden başlamasıdır. Örneğin yukarıdaki şekilde görülen 3. cluster'ın yazılması için 2 disk chunk'ına da yazılması gerekir ve bu ekstra disk IO'su demektir.

Araya bir de sanallaştırma katmanının girdiği durumda ise işlem biraz daha karışık hale gelir. VMFS'de partition ve sanal makinayı ayrı ayrı düşünmek gerekir.

Buradaki sorun daha büyüktür. Böyle bir yapıda 3. cluster'a yakından bakacak olursak.Bir cluster'ın yazılması için 3 adet chunk'a yazmak gerekmektedir. Çünkü hem VMFS partition LUN üzerine doğru align edilmemiş, hem de sanal makinanın diski içindeki NTFS doğru align edilmemiştir.

Oysaki beklenen yapı şöyle olmalıdır;

Burada her bir cluster tek bir chunk'a isabet etmektedir. Ek IO yükü oluşturacak bir durumdan söz edilemez.

Disk Alignment sorunu nasıl tespit edilir

Bu sorunu tespit etmek işletim sistemine göre farklılık gösterir. Öncelikle VMware tafarına bakıldığında VMFS3 ve VMFS5'de alignment sorunu yoktur. VMFS2 olarak oluşturulmuş ve upgrade edilerek devam edilmiş LUN'lar var ise bunlarda sorun vardır. En basit ve temiz yöntem bu LUN üzerindeki datastore'u silip yeni versiyon olarak tekrar oluşturmaktır.

Windows tarafında 2003 ve öncesinde bu sorun oluşmaktadır. Bunu tespit etmenin en kolay yolu msinfo32 uygulamasını çalıştırmaktır. Bu uygulama tüm Windows sürümlerinde bulunur ve "Start/Run" a "msinfo32" yazılarak başlatılabilir. Windows 2003 bir sistemden aldığım çıktı şu şekildedir. 

Bu uygulama ile Components\Storage\Disk altından her bir disk için "Partition Starting Ofset" değeri görülebilir. Windows Vista ve üstünde bu sorun giderilmiştir ve partition'lar 1MB'dan başlamaktadır.

Disk Alignment sorunu nasıl düzeltilir

Bunu düzeltmenin çok kolay bir yolu yoktur. Düzeltmek için izlenebilecek yöntemler şunlardır.

• Storage üreticilerinin sağladığı araçları kullanmak (örn; mbralign)
• Diskleri tekrar oluşturup doğru şekilde align etmek
• Vmware vCenter Standalone Converter 5 ile P2v ya da V2V yapmak
• vs..

Burada üzerinde durmak istediğim Windows 2003 tarafında yeni bir diskin nasıl doğru align edilerek oluşturulabileceği ve Converter kullanımı.

Windows 2003 ile bir diski doğru şekilde align etmek için partition'u diskpart komut satırı tool'u ile oluşturmalısınız. Aşağıda bir örnek görebilirsiniz.

Bu sayede partition doğru şekilde align edilmiş olacak.

Eğer bir Windows 2003 sunucuyu P2v yapıyorsanız artık bu işlem çok daha kolay. Sadece P2V değil elbette, hali hazırdaki sanal 2003 sunucularda da yukarıdaki anlattığım yöntemle yeni diskler oluşturup veriyi taşımak istemezseniz, Converter programı ile V2V yaparak bu sorunu giderebilirsiniz.

Converter 5 ile beraber hayatımıza giren bu kutucuk sayesinde oluşacak olan disklerdeki alingment sorunu otomatik olarak düzeltilecektir.

Fazla detaya girmeden anlatmaya çalıştığım bu yazım umarım faydalı olur.

Daha detaylı bilgi için;

http://media.netapp.com/documents/tr-3747.pdf

Öncelikle Workstation 8 kurulu makinanızın i7 ya da Nehalem işlemcili olması ve bios üzerinde bu özelliğin aktif olması gerekiyor.

HyperV kurulacak sanal makinayı oluştururken sanal makina versiyonu olarak v8 seçilmeli.

Sanal makina oluşturulduktan sonra Cpu ayarlarında Intel VT-x/EPT aktif hale getirilmeli.

Oluşturulan sanal makinanın vmx dosyasına aşağıdaki satır eklenmeli. (ÖNEMLİ: vmx dosyasını editlemeden önce workstation 8'i kapatmalısınız)

hypervisor.cpuid.v0 = "FALSE"

Şimdi Workstation 8'i başlatıp, oluşturduğunuz bu sanal makinayı açarak içine Windows Server 2008 R2 x64 kurduktan sonra HyperV rolünü kurabilirsiniz.

Not: Eğer sanal makinayı başlatırken işlemci ile ilgili hata alıyorsanız fiziksel CPU'nuz Intel VT-x/EPT desteklemiyor ya da bios üzerinden kapalı olabilir.

İşlemin uygulaması oldukça basit. Default olarak kapalı gelen bu özelliği açmak için fiziksel esxi 5 sunucumuz üzerindeki "/etc/vmware/config" dosyasına aşağıdaki satırı eklememiz yeterli.

vhv.allow = "TRUE"

Bundan sonra sunucumuzu restart etmemize bile gerek yok, doğrudan çalışmaya başlıyor.

Sanal Esxi

Sonraki aşamada ise içine esxi kuracağımız sanal sunucumuzu oluşturmalıyız. Sanal makina versiyonu 8 olmalı. Sunucuyu oluştururken işletim sistemi olarak Redhat 6 64bit seçebiliriz. Esxi ile uyumlu olması için Ethernet kartlarını E1000 olarak belirlemeli ve SCSI adaptor olarak da LSI Logic SAS seçebiliriz. İlginç şekilde sanal makinayı oluştururken işletim sistemi olarak esx(i) seçmek mümkün değil ama oluşturduktan sonra değiştirmek mümkün. Aşağıdaki şekildeki gibi.

Sonrasında ise esxi kurulumuna başlayıp normal şekilde kurup devam edebiliyoruz. Bu arada iç içe 3 adet esxi kurulabiliyor

Sanal HyperV

Eğer yapımızda HyperV çalıştırmak istersek ise öncelikle Windows 2008 R2 işletim sistemini seçerek versiyon 8 bir sanal makina oluşturmalıyız. Sonrasında sanal makinanın özelliklerini açarak Options tabına geçip, General bölümündeki "Configuration Parameters" butonuna tıklamalı ve çıkan ekranda "Add Row" butonuna tıklayarak aşağıdaki değerleri girmeliyiz.

hypervisor.cpuid.v0 = FALSE

Şekildeki gibi...

Ayrıca CPU özelliklerini sanal makinaya geçirmek için  sanal makinanın özelliklerini açarak Options tabına geçip, General bölümündeki "CPUID Mask" bölümünden "Advanced" butonuna tıklayıp Layer1 ecx altına aşağıdaki değer girilmeli.

---- ---- ---- ---- ---- ---- --H- ----

Bundan sonra sanal makinamıza 2008R2 işletim sistemini kurup HyperV'yi açabiliriz. HyperV test etmek için bile esxi kurmak gerekiyor

Sonuç şöyle oluyor...

Hatanın sebebine gelince; eğer Windows Cluster yapısında SnapDrive kurulumu yapılıyorsa, SnapDrive tüm cluster node'ları üzerine kurulmalı. Ayrıca tüm node'larda aynı versiyon olmak zorunda. Siz de benim gibi "Class not registered" hatası alıyorsanız, diğer cluster node'larına da aynı versiyon SnapDrive kurulumu yapmalısınız.

I'm instaling HyperV R2 and Netapp to a customer. We are using SMHV to backup VMs on HyperV hosts.  It's needed to install SnapDrive on all HyperV hosts as a requirement. To avoid of this error, please consider that install same version of SnapDrive on all hosts in the cluster.

XPS versiyonunu buradan,
PDF versiyonunu buradan, indirebilirsiniz...

http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-survival-guide.aspx