Aslında bunun sebebi ONTAP’ın LUN’ları oluştururken kullandığı disk geometrisidir. ONTAP oluşturduğunuz LUN’un boyutuna göre, her 50GB'da bir farklı bir geometri kullanır. Sahip olduğunuz LUN’ların disk geometrisini görmek için “lun geometry [lun_adı]” komutunu kullanabilirsiniz. Bu komut diagnostic modda(“priv set diag”) çalışır. Bu komut ile aynı zamanda her bir LUN için maksimum boyutu da görüntüleyebilirsiniz.

Aşağıdaki ekren görüntüsünde ilk LUN 51GB ikinci LUN ise 100GB boyutunda.

Görüldüğü üzere iki LUN’un da max resize boyutu aynı. Eğer 101GB’lık bir LUN oluşturursak “lun geometry” komut çıktısı şöyle olur.

…ve 150GB’a kadar oluşacak tüm LUN’lar aynı “max resize size” değerine sahip olacaktır.

LUN oluştururken buna dikkat etmeli ve nereye kadar büyütebileceğimizi bilmeliyiz. Sonradan kötü sürprizlerle karşılamamak için LUN boyutunu baştan uygun şekilde ayarlamalıyız.

Aşağıdaki tablo size bu konuda bir fikir verecektir.

VLAN ayarlarını üç farklı yöntem ile gerçekleştirebiliyoruz.

• External Switch Tagging (EST)
• Virtual Switch Tagging (VST)
• Virtual Guest Tagging (VGT)

Sırayla açıklık getirelim.

External Switch Tagging (EST)

Öncelikle bir çizim üzerinde görelim.

Bu yöntem ile ESXi tarafında herhangi bir ayar yapılmaz. Fiziksel dünyadaki her bir VLAN için ESXi içinde bir vSwitch oluşturulur. Sonrasında fiziksel switch’den vSwitch’e doğru giden linkler access portu olarak ayarlanır ve ilgili VLAN tag’lemesi fiziksel switch seviyesinde yapılır. Bu yöntemde Port Group’lara VLAN ID girilmez (“0” olarak bırakılır). Sanal makinalar hangi vSwitch’e bağlı ise o VLAN ile görüşebilecek demektir. Sık tercih edilen bir yöntem olmasa da ESXi tarafında konfigürasyon gerektirmediği için zaman zaman kullanılır.

Virtual Switch Tagging (VST)

Yine bir çizim ile izah edelim.

En çok tercih edilen yöntem bu olsa gerek. Bu yöntemde switch üzerindeki portlar trunk olarak ayarlanır. Tüm VLAN’lar böylece vSwitch’lere kadar ulaşmış olur. vSwitch içindeki ayrım için ise PortGroup’lar kullanılır. Her bir PortGroup’a 1-4094 arasında bir VLAN ID’si atanır. Böylece dış dünyadaki VLAN’ımız 802.1q protokolünü destekleyen ESXi’larımız üzerinde kullanılabilir hale gelir. En esnek ve kullanışlı yöntem budur.

Virtual Guest Tagging (VGT)

Son çizim de özel ihtiyaçlar haricinde pek kullanılmayan VGT yöntemi için…

Bu yöntemde fiziksel switch üzerindeki portlar trunk durumdadır. Tüm VLAN’lar içeri doğru akar. PortGroup’lar üzerinde VLAN ID olarak 4095 ayarlanmış olmalıdır ki bu ayar ilgili PortGroup’ların da bir nevi trunk gibi davranarak tüm VLAN’leri sanal makinalara kadar iletmesini sağlar. Böyle bir senaryoda VLAN tagging işlemiş sanal makina seviyesinde yapılmalıdır. Ancak default ayarlar buna müsade etmeyebilir. Bunu yapabilmek için guest OS’in desteklemesi ve 802.1q destekleyen uygun bir driver yüklü olması gerekir. Ayrıca vNic mutlaka E1000 olmalıdır. Çok sık kullanılar bir çözüm değildir.

Yukarıdaki 3 yöntemden genel olarak taviye edebileceğimiz yöntem VST’dir. Özel bir gereksinim olmadıkça VST kullanılması tavsiye edilir.

• USB redirection altyapısı yeniden tasarlandı
• View Storage Accelerator modülü eklendi (CBRC)
• Radius kimlik doğrulaması
• Yeni client yazılımları
• PCoIP (network ve cpu) iyileştirmeleri
• View Administrator ekranı artık daha hızlı
• Fiziksel makinalar için Persona Management
• XP’den Win7’ye upgrade için Persona Management migration tool
• Standalone View Composer Server
• Birkaç küçük iyileştirme daha…

Açıkçası benim için göze çarpan en önemli yenilik View Storage Accelerator oldu. Bunu, vSphere 5 ile birlikte ortaya çıkan CBRC(Content Based Read Cache) özelliğinin View üzerinde hayat bulmuş hali olarak düşünebiliriz. Özellikle VDI ortamları için geliştirilmiş CBRC özelliği disk üzerindeki master VDI imajlarının sık kullanılan bloklarını önceden RAM'e yükleyerek çok daha hızlı cevap vermesine olanak tanır. View kurulumlarında bootstorm'ların önüne geçmek ve toplam IOPS ihtiyacını düşürmek için kullanılmaktadır.

VMware tarafından yapılan bir test sonucunda View Storage Accelerator ile ortaya çıkan kazanım şu şekilde raporlanmış.

• Peak IOPS’da 80% azalma
• Ortalama IOPS’da %45 azalma
• Peak throughput’da %65 azalma
• Average throughput’da %25 azalma

Ayrıca View 5.1 ile bilirlikte View Composer API for Array Integration (VCAI) özelliği "tech preview" olarak karşımızda. Bu özellik ile Linked Clone oluşturmak için storage ünitesi seviyesinde snapshot'ları kullanabileceğiz. Bu sayede daha hızlı ve efektif bir şekilde Linked Clone'lar oluşturabileceğiz. Henüz "tech preview" aşamasında olan bu özellik production ortamlarda desteklenmiyor. Bu özelliği test etmek için aşağıdaki şartları sağlamak gerekli.

• VMware View 5.1
• VMware vSphere 5.0 ve sonrası
• VAAI destekleyen NAS cihazı
• View Cluster'ındaki vSphere sunucular için NAS cihazı üretici tarafından sağlanan plug-in

VCAI hakkında detaylı bilgi için NetApp tarafından sağlanan şu makaleye göz atılabilir.

https://communities.netapp.com/community/netapp-blogs/virtualization/blog/2012/05/02/vmware-view-51-view-storage-accelerator

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

http://www.labguides.com/autolab/

Bu siteden indirdiğimiz paketin içinde neler olduğunu ve nasıl kuracağınızı da şu guide'da bulabilirsiniz.

http://www.labguides.com/downloads/vSphere%205_AutoLab_V0_5.pdf

SSL'i disable etmek için;

• "converter-worker.xml" dosyasını açın. Bu dosya şurada bulunuyor;
• Vista ve sonrasında > “%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone”
• Daha eski Windows sürümlerinde > “%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone”
• Config>nfc>useSsl değerini false olarak değiştirip, kaydedin.
• “VMware vCenter Converter Standalone Worker” servisini restart edin.

Hepsi bu kadar.

Öncelikle E5 işlemciler (aslında Sandy Bridge-EP ailesinin tamamı) Intel'in Tick-Tock inovasyon modelinde 32nm işlemcilerin "tock" adımını temsil ediyor. Bundan sonraki model olan "Ivy Bridge" ise  üretim teknolojisi olarak 22nm kullanılacak.

E serisi bu işlemcilerde Westmere ailesine mensup 5600 serileri ile kıyaslandığında göze çarpan bazı noktalara dikkat çekmek istiyorum.

Intel bu yeni işlemci ailesi ile 5600 serisine göre %80'e varan performans kazanımı elde etmenin mümkün olduğunu iddia ediyor. Bağımsız testler ise ortalama %20-25 oranında net kazanım olduğunu gösteriyor. Ayrıca SAP uygulaması için bu işlemcileri kullanacak kişiler için referans niteliğinde olan SAPS benchmark'ları yayınlanmaya başladı. SAPS değerlerine göre baktığımızda ise örneğin IBM tarafında M3 ile M4 modeller arasında %60-70 arası bir performans iyileştirmesi görebiliyoruz ki bu değerler hiç de azımsanacak değerler değil. Bu performans arttırımının ardında yatan teknolojiler şunlar.

• Daha fazla çekirdek
• Daha yüksek önbellek
• Yeni nesil Turbo Boost teknolojisi
• Daha yüksek QPI band genişliği
• Intel AVX teknolojisi

Bu teknolojilerin detayları ile ilgili aşağıdaki videoya göz atabilirsiniz.

• AMD ve Intel tarafından sunulan yeni nesil işlemciler için destek eklendi. (bkz: HCG)
• Mac OS X 10.7.2 ve 10.7.3 için guest os desteği eklendi.
• Intel C600 serisi ve LSI MegaRAID SAS (version 5.34) için native storage sürücüleri eklendi.
• vCenter tarafında Windows 8, Ubuntu (10.04-11.10) ve SLES 11 SP2 için guest customization desteği eklendi.

Download için : www.vmware.com/go/download-vsphere

Release Notları :

VMware vCenter Server 5.0 Update 1 Release Notes

VMware ESXi 5.0 Update 1 Release Notes

Sunduğu özellikler kısaca şöyle;

• Manageability - Telnet, SSH, SNMP, TACACS+, RADIUS, Industry Standard CLI
• Advanced networking features - L2-L4 ACLs, Static and Dynamic port aggregation, PVLAN, QoS, EVB (IEEE 802.1Qbg)
• Network troubleshooting - SPAN, ERSPAN, sFlow, Syslog, VM network statistic

Ürün hakkında detaylı bilgi için aşağıdaki adresi ziyaret edebilirsiniz.

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS212-052

VmUpgradeHelper Kullanımı;

Öncelikle (Administrator olarak) komut satırını açıp "C:\Program Files\Vmware\Vmware Tools\" dizinine ilerliyoruz.

Interface ayarlarını yedeklemek için;
vmupgradehelper /s

Bu aşamadan sonra VM'in sanal donanımını upgrade edebiliriz.

Interface ayarlarını geri yüklemek için;
vmupgradehelper /r

netsh Kullanımı;

Yine  (Administrator olarak) komut satırını açarak işe başlıyoruz.

Interface ayarlarını yedeklemek için;
netsh dump interface > c:\backup.txt

Bu aşamadan sonra VM'in sanal donanımını upgrade edebiliriz.

Interface ayarlarını geri yüklemek için;
netsh exec c:\backup.txt

Eski ethernet kartını silmek

Başka bir konu da yine ara sıra karşılaştığımız bir başka durum, upgrade işlemlerinden sonra silinen ethernet kartının ayarlarının registry'den otomatik olarak silinmemesi durumu. Böyle bir durumda yeni ethernete ip vermek istediğimizde şöyle bir uyarı ile karşılaşırız.

Bu uyarıyı NO diyerek devam edebiliriz ama amacımız sistemdeki kalıntıları temizleme ise aşağıdaki adımları uygulamamız gerek.

Yine  (Administrator olarak) komut satırını penceresi açarak işe başlıyoruz.

set devmgr_show_nonpresent_devices=1 komutunu veriyoruz.

Aynı konsol ekranına aşağıdaki komutu girerek Device Manager penceresini açıyoruz.

devmgmt.msc

View menüsünden Show Hidden Devices'a tıklıyoruz. Artık eski ethernet kartımızın kalıntılarını silebiliriz.