Yine geçtiğimiz günlerde gelen bir soru üzerine yazdığım cevap maili alıp başını gidince, konuyu biraz daha detaylandırıp blog entry olarak yayınlamak istedim :)

Soru tam olarak şöyle:

“Peki, ornegin uzerinde 10 guest calisan bir sunucuda tek bir ethernet uzerinde her guest cok siki network haberlesmesi yapiyorsa ve sunucunun 1Gbit lik bir ethetnet i varsa bu durumda her sunucuya 100Mbit (veya ilk alana cok sonra gelene nanik :)) mi ayriliyor”

Peki cevap?

Cevap kısa ve net: “Kimseye nanik yok, bu işler parayla değil sırayla :)”

Hyper-V için 3 temel Virtual Network tipi vardır.

- External (Fiziksel dünya ile konuşabilen network – External Virtul Switch)
- Internal (Sadece aynı Hyper-V sunucusu üzerinde çalışan VM’lerin kendi aralarında ve Hyper-V sunucusu ile konuşabildiği network – Internal Virtual Switch)
- Private (VM’lerin sadece kendi aralarında konuşabildiği network – Private Virtual Switch)

Daha önce Hyper-V Virtual Networks konusunda yazdığım bir yazıya buradan ulaşabilirsiniz. Bu yazıya göz atarsanız; VM’lerin ve Parent OS’in Virtual NIC’ler kullandığından ve bu vNIC’lerin fiziksel NIC üzerinden external network’e çıkış yaptığıdan bahsetmiştim. Bu durumda VM’lerin ve Parent OS’in external network iletişimi için kullanabileceği toplam bandwidth miktarı, fiziksel NIC’in gerçek bandwidth miktarına eşittir. External network bandwidth diyorum çünkü VM to VM yada Host to VM iletişiminde fiziksel NIC kullanılmayabilir. Yani Internal ve Private networkler için bandwidth konusu farklıdır.

Sorudan yola çıkalım. Hyper-V üzerinde çalışan 10 VM var. External Virtual Switch ve tek bir fiziksel NIC üzerinde çalışan MS Virtual Network Switch Protocol ile external network’e send/receive yapıyorlar. Fiziksel NIC ise 1GB bandwidth’e sahip. Bu noktada network kuralları gereği pakedi gönderen, aracı olan ve pakedi alan noktaların bandwidt’i, iletim bandwidth durumuna direkt etki eder. Örneğin 1000MBps NIC üzerinden çıkan paketler, 1000MBps Switch üzerinden geçip, 100MBps NIC’e giriş yapıyor olabilir. Bu durumda source noktasından 1000MBps veri çıksada, destination maximum 100MBps veri alabileceği için aslında iletim bandwidth’i 100MBps dir.

Peki VM’lerin Virtual NIC’lerinin bandwidth’i nedir?

Windows Server 2003 ve 2008 Guest OS’ler için konuşursak vNIC başına bandwidth 10gb tır. Ancak bu teorik rakam VMs ve Virtual Switch arasındaki iletişimde geçerlidir (Her bir vNIC’in 10GBps olarak, virtual CAT5 ile Virtual SW’e bağlandığını düşünebilirsiniz). Bu durumda teorik olarak aynı Virtual SW’e bağlı VM’ler kendi aralarında 10GBps olarak iletişim kurabilirler (Internal veya Private Virtual SW’ler üzerinde çalışan VM’lerin bu ağ üzerinde yüksek hızlarla konuştuğunu test edebilirsin). Ama bu Virtual Switch external tipte ise dışarı çıkışta bandwidth düşecektir çünkü Virtual SW’den external networke akan trafik Fiziksel NIC üzerinden çıkmak zorundadır. Bu durumda da toplam bandwidth maximu 1GB olur (fiziksel NIC bandwidth’i). Aşağıdaki diagram bu yapıyı temsil ediyor.

Gelelim sorunun cevabına. 10 VM’den gelen ve external networke gitmek isteyen paketler Parent Partition üzerindeki Virtual Switch’te toplanır (VSC/VSP/VMBUS desteği ile) ve sırayla fiziksel NIC üzerinden gönderilir. Bu noktada sıralamayı belirleyen bileşenlerin başında Virtual Switch, VSP  (Virtual Service Provider) ve Windows Server 2008 Network mimarisi gelir. Virtual Switch üzerinde kullanılan routing algoritması özel bilgidir ve bu konu ile ilgili public kaynak yoktur. Bu nedenle daha derine inmek doğru olmaz :)

Ama şöyle bir yetenekten bahsedebilirim:

Örneğin Parent Partition üzerinde iki fiziksel NIC var. Bunlardan birisi External Virtual Switch olarak tanımlanmış  ve bu bacak yerine Virtual NIC yaratılmış. İkincisi ise fiziksel şekilde duruyor. Yani Parent OS’in fiziksel networke erişebilmesi için Virtul NIC ve ikinci fiziksel NIC olamak üzere iki şansı var ve her iki NIC’in de aynı networke erişebildiğini kabul edelim.

Bu durumda Parent OS üzerindeki herhangi bir application fiziksel networke erişmek istediğinde hangi NIC’i kullanmalı? Bu yapıda Virtual NIC Virtual Switch üzerinden, fiziksel NIC ise direkt çıkış yapabilecek konumdadır. Bu durumda tabiki fizikselden çıkmak çok daha mantıklı. İşte bahsettiğimiz algoritma bu gibi kararları kendisi alıp network trafiğini en doğru ve kısa yoldan gönderebilmektedir. Aşağıdaki diagram bu yapıyı temsil ediyor.

(sorunun cevabına dönersek) Sonuç olarak 1GB bandwidth VM’ler arasında 100mb olarak paylaştırılmaz, sistem tarafından önceliklendirilip işlenir.

Sanallaştırma olmayan fiziksel yapıları düşünelim. Sistemde çalışan uygulamalardan biri fazla network trafiği yarattığında, aynı sistem üzerindeki diğer uygulamaların performansı bundan etkilenir. Çünkü bandwidth’i ortak kullanırlar. Aynı mantık bir noktada Hyper-V Virtual Networks içinde geçerli.

Peki biz her VM için 100MBps olarak limit veremez miyiz? Hyper-V üzerinde Processor, Memory ve Storage kullanım limitleri verebiliyoruz ancak NIC tarafında şimdilik limit verme şansımız yok ve bu durum birçok sanallaştırma ürününde bu şekilde.

Bu noktada VM network aktivitelerini izleyip değerlendirmenizi tavsiye ederim. Her ne kadar Virtual NIC’ler ve Virtual Switch’ler den bahsetsekte, bu sanal aygıtları (üzerlerindeki sanal portlara kadar) izleme şansımız var. Örneğin Ex-SW1 isimli sanal switch’in üzerinde çalışan VM21 sanal makinesinin bağlı bulunduğu portun trafiğine kadar izleyebilirsiniz. Nasıl mı?

Örneğin Windows Server 2008 üzerinde ücretsiz olarak gelen Reliability and Performance Monitor ve aşağıdaki counter’ları kullanabilirsiniz.

Hyper-V Virtual Switch (Seçtiğiniz Virtual SW/SWs üzerinde paket send/receive, multicast-broadcast, flood gibi durumları izler)
Hyper-V Virtual Switch Port (Daha detaylı olarak port bazlı send/receive izlenebilir)
Hyper-V Virtual Network Adapter (NIC bazlı send/receive izlenebilir)

Yada çok daha gelişmiş monitoring işlemleri için System Center Operations Manager kullanabilirsiniz.

İyi çalışmalar dilerim.

Serhat AKINCI – IT Professional

Geçtiğimiz günlerde teknik topluluklardan birinde gelen soru üzerine yazdığım cevabı düzenleyerek burada da paylaşmak istedim.

Soruda merak edilen; sunucu sanallaştırma ortamlarında, örneğin 3 Guest sistemin tek bir fiziksel NIC’i kullanması bir sorun teşkil eder mi?

Öncelikle bu durum bir sorun teşkil etmez. Zaten Server Virtualization teknolojilerinin temel amacı olan konsolidasyon işleminin zemininde, fiziksel kaynakların birden fazla sanal işletim sistemine kullandırılması yatar. Tek bir fiziksel NIC üzerinden 3 Guest OS’in send/receive yapabilmesi gibi… Tabi 3 Guset sistem external network’e normal üstü send/receive yapıyorsa, fiziksel NIC’in sahip olduğu bandwidth’e göre dar boğaz yaşanabilir ancak bu özel bir durumdur, bu gibi durumlarda zaten ayrı fiziksel NIC’ler kullanılmalı.

Konu açılmışken Virtual Network process’lerinin Hyper-V tarafında nasıl gerçekleştiğinden bahsetmek istiyorum. Bu mantık bir çok sunucu sanallaştırma ürünü içinde geçerlidir.

Hyper-V sunucularında VM’lerin ve Parent OS’in fiziksel network iletişimi için kullanılan Microsoft Virtual Network Switch Protocol çalışır (vSW).  VM’lerde ise Virtual Network Interface Card‘lar vardır (vNIC).

Örneğin tek fiziksel NIC’e sahip sunucuda Hyper-V enable edip yeni bir external virtual network yaratırsanız, Parent OS’e ait fiziksel NIC üzerinde çalışan (TCP/IP dahil) tüm protokoller devre dışı kalır ve fiziksel NIC üzerinde sadece Microsoft Virtual Network Switch Protocol çalışmaya başlar.

Aşağıda da görebileceğiniz gibi “Broadcom NetXtreme Gigabit Ethernet” üzerinde sadece Virtual Network Switch Protocol çalışıyor.

Bu fiziksel NIC bir noktada Hyper-V Serverın dış dünya ile görüşen sanal switch’i durumundadır. Bu NIC’in herhangi bir IP adresi de yoktur.

Peki bu durumda Parent OS network iletişimini nasıl gerçekleştirecek?

Senaryonun devamı olarak Parent OS’e yeni bir Virtual NIC eklenir ve fiziksel NIC ile ilişkili sanal switch’e bağlanır (otomatik olarak).

Parent OS artık bu Virtual NIC üzerinde çalışan protokoller (fiziksel NIC üzerinden kalkan protokoller) ile network iletişimini sürdürür.  Parent OS için aksiyon budur.

Ayrıca şunu da belirtmek isterim: Parent OS üzerindeki Virtua NIC’i kaldırıp (veya hiç eklemeyip) Microsoft
Virtual Network Switch Protocol ve Parent OS’in iletişimi için gerekli protokollerin hepsini aynı fiziksel NIC üzerinde çalıştırmak mümkün. Bu durumda Parent OS için Virtual NIC olmaz, sadece VM’lerde Virtua NICs olur. Bu durumda mimaride herhangi bir değişiklik olmaz, mantık yine aynı. (Kişisel tavsiyem: fiziksel NIC üzerinde sadece Microsoft Virtual Network Switch Protocol çalışsın, Parent OS ise Virtual NIC kullansın.)

Hyper-V tarafında Virtual Network mimarisi kabaca böyle. Ancak bu konuda yanlış bilinen bir nokta var. VM’lerin external network iletişimini sağlayan Parent OS üzerindeki Virtual NIC değil, yukarıda da bahsettiğim gibi fiziksel NIC üzerinde çalışan Microsoft Virtual Network Switch Protocoldür. Nasıl ki Parent OS üzerine eklenen Virtual NIC, external network send/receive için fiziksel NIC üzerinde çalışan Microsoft Virtual Network Switch Protocol ‘e bağlı ise, VM’ler üzerinde yer alan Virtual NIC‘ler
de aynı şekilde bu protokol ile external netwok’e send/receive yaparlar. Bu protokole veriyi gönderen ise external virtual switch’tir.

Toparlarsak; Sunucu üzerindeki fiziksel NIC sanal bir switch görevi üstleniyor, Parent OS ve VM’ler ise üzerlerindeki Virtual NIC’ler ile bu switch’e bağlı şekilde external network’e send/receive yapıyor (fiziksel NIC’in fiziksel olarak erişebildiği networke).

Yukarıdaki diagram bu yapıyı temsil ediyor.

Serhat AKINCI – IT Pro.

Hyper-V ile üzerinde çalışan Linux tabanlı sanal işletim sistemleri arasında tam entegrasyon sağlayan ve Linux Guest OS’lerin daha performanslı çalışmasını amaçlayan Linux Integration Components beta durumdaykan burada duyurusunu yapmıştım.

Linux Integration Components artık hazır ve Microsoft Download Center üzerinden indirilebilir durumda.

Download için: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab7f4983-93c5-4a70-8c79-0642f0d59ec2#tm

Linux Guest OS üzerine Linux ICs kurulumu adımları için buraya bakabiklirsiniz.

VHD’nin (Virtual Hard Disk) Hyper-V üzerinde çalışan VM’lerin (Virtual Machine) sanal disk formatı olduğunu artık biliyorsunuz :) . Bu format aynı zamanda Virtual Server ve Virtual PC ortamları içinde geçerli. Yani MS tarafında genel sanal disk formatı diyebiliriz.

Hyper-V üzerinde 3 farklı VHD tipi vardır.

Dynamically Expanding
Fixed Size
Differencing

Genelde ilk iki tip VHD’i kullanırız. Bu iki tip arasındaki temel farklardan ise burada kısaca bahsetmiştim.

Hyper-V Manager konsolu üzerinden 10GB boyutlu yeni bir Dynamically Expanding VHD yaratmak istediğimizde işlem saniyeler içinde gerçekleşir çünkü Dynamically Expanding tipinde örneğin 10GB olarak belirlenen sanal disk alanı, oluşan VHD dosyasının boyutunu etkilemez. Bu Dynamically Expanding VHD’lere özel bir durumdur. Sanal disk boyutu VHD yaratılma işlemi sırasında fiziksel disk/partition üzerinde rezerve edilmez. Bu nedenle Dynamically Expanding VHD dosyası çok hızlı bir şekilde yaratılır.

Yine Hyper-V Manager konsolu üzerinden bu sefer 10GB boyutlu bir Fixed SizeVHD yaratmak istediğimizde işlem çok daha uzun sürecektir çünkü Fixed SizeVHD tipinde belirlenen sanal disk alanı, oluşan VHD dosyasının boyutunu etkiler ve eşittir. Yani 10GB size’a sahip bir Fixed SizeVHD dosyası, fiziksel disk/partition üzerinde de 10GB boyutlu bir dosya şeklinde olacaktır çünkü oluşturulma işlemi sırasında boyut rezerve edilir. Bu da Fixed SizeVHD oluşturulma işlem zamanının belirlenen boyut ile doğru orantılı olarak uzamasına neden olur. 10 yada 20 GB kapasiteli Fixed SizeVHD’ler belki 2-3 dk içerisinde oluşacaktır ancak 200 – 300 GB kapasiteli Fixed SizeVHD’ler yaratmak oldukça zaman alır.

Bu iki tip arasındaki farkları daha iyi anlamak için buraya bakmanızı öneririm.

Peki Fixed SizeVHD yaratma işlemlerini daha hızlı gerçekleştirebilir misiniz? Kesinlikle evet 

MSDN Code Gallery üzerinde yayınlanan VHD Tool yardımı ile çok kısa sürede ve tamamen sağlıklı Fixed Size VHD’ler yaratabilirsiniz.

Birkaç örnek ile aracı inceleyelim.

Öncelikle VhdTool.exe yi aşağıdaki link üzerinden indiriyoruz.

http://code.msdn.microsoft.com/vhdtool/Release/ProjectReleases.aspx?ReleaseId=2437

Bu tool Server tarafından Windows Server 2003 ve üzeri, Client tarafında ise Windows XP ve üzeri sistemlerde çalışabilir ve NTFS partition gerekliliği vardır.

Tool ile kullanabileceğiniz komutlar aşağıda.

VhdTool.exe /create <FileName> <Size>
VhdTool.exe /convert <FileName> /quiet
VhdTool.exe /extend <FileName> <NewSize>

Gördüğünüz gibi 3 temel komut var.

/Create ile yeni bir Fixed Size VHD yaratabilirsiniz

/Convert var olan bir dosyayı (ör: IMG) Fixed Size VHD’e convert edebilirsiniz

/Extend ile var olan bir Fixed Size VHD’nin boyutunu genişletebilirsiniz

Bu arada VhdTool.exe’nin bir grafik ara yüzü bulunmuyor. İşlemleri komut satırından gerçekleştiriyoruz.

Örneğin 30GB boyutlu bir Fixed Size VHD yaratalım.

Bu işlem için kullanmanız gereken komut:

VhdTool.exe /create e:\TestVHDs\FX.vhd 32212254720

Bu komut içindeki e:\TestVHDs\FX.vhd VHD dosyasının yaratılacağı dizini ve dosyanın ismini temsil ediyor. 32212254720 ise sanal disk miktarını temsil ediyor. Byte cinsindendir.

32212254720byte = 30GB

Nasıl hesaplanır? Mantık şu: GB> MB> KB> Byte şeklinde, 1024 ile çarparak aşağı inilir.

30GB * 1024 = 30720 MB
30720MB * 1024 = 31457280 KB
31457280KB * 1024 = 32212254720 Byte

Yaratacağımız VHD’nin boyutunu byte cinsinden belirledikten sonra, cmd.exe açıyoruz, VhdTool.exe’nin olduğu dizine geçiyoruz ve VhdTool.exe /create e:\TestVHDs\FX.vhd 32212254720 komutunu uyguluyoruz.

1 Numarada E:\ içinde VhdToll.exe nin olduğunu görüyorsunuz.
2 Numarada uyguladığımız komut var

2 Numaralı komutun hemen altında uygulanan adımları görüyorsunuz ve en sonda Complate bilgisi var.

Bu yöntemle saniyeler içinde ve boyuttan bağımsız olarak Fixed Size VHD’ler yaratabilir, genişletebilir, convert edebilirsiniz.

Extend ve Convert komutları da aşağıdaki gibi uygulanabilir.

Yukarıda Extend komutuyla 3GB’lık Fixed Size VHD dosyasının boyutunu 20GB’a genişletiyorum

Aşağıda ise .img dosyasını Fixed Size yapıyoruz. Bu komutta /quiet parametresi olduğu için print yoktur.

En güzel yanı da tüm bu işlemlerin saniyeler içinde gerçekleşiyor olması. Bu işlemleri normal yollar ile uyguladığımızda oldukça zaman alır.

Serhat AKINCI – IT Pro.

Mehmet’in de blogunda bahsettiği hazır VHD’ler gerçekten test için süper aletler :)

VHD formatı MS sanallaştırma ürünlerinde kullanılan standart sanal disk formatıdır. Ürünlerin setuplarını indrip kurmak yerine, bu hazır VHD dosyalarını Hyper-V yada Virtual Server 2005 üzerinde start edip hazır kurulu bir sistemi test etmeye başlayabilirsiniz. Windows Server 2008 VHD’lerine ek olarak aşağıda bir kaç ürünü daha bulabilirsiniz.

System Center yönetim ailesinin Sanallaştırma ortamlarını yönetirken kullandığımız üyesi olan ve daha önce burada temel özelliklerinden bahsettiğim Virtual Machine Manager 2008′in R2 sürümü beta olarak kullanıma sunuldu.

http://connect.microsoft.com/ sitesine login olarak ürünün beta halini indirip test edebilirsiniz.

Bildiğiniz gibi Hyper-V 2.0 da şu an beta olarak test edilebilir durumda (Windows Server 2008 R2 beta veya Hyper-V Server 2008 R2 beta ile birlikte). Yani Windows Server 2008 R2 beta ile çalışan Hyper-V 2.0 sunucularınızı ve sanal makinelerinizi VMM2008 R2 beta ile yönetip, önümüzdeki senenin sanallaştırma ortamını şimdiden test edebilirsiniz.

Virtual Machine manager 2008 R2 ile gelen yenilikleri ayrıntılı olarak inceleyeceğiz ancak şimdilik bir kaç şey söyleyelim.

- Live Migration ve Clustered Shared Volumes: Ayrılmaz ikili :) Hyper-V hostları üzerinde çalışan VM’lerin canlı olarak (yani sıfır kesinti ile) cluster yapısındaği diğer Hyper-V hostları üzerine taşınması işlemi. Clustered Shared Volumes ise LUN (csv volume) içinden, diğer VM’leri etkilemeden tek bir VM’in migrate edilebilmesi noktasında destek oluyor. VMM2008 R2 ile live migration özelliğini yönetilebiliyoruz.

- SAN migration in and out of clusters

- Tek LUN üzerinde birden fazla VM

- Tek iSCSI Target için birden fazla LUN

- Hyper-V Networking geliştirmeleri

- Reusable port groups in VMWare VirtualCenter

- Disjoint domains

- BITS compact server

- “Maintenance mode” ara yüzü

gibi yenilikler beta sürümde test edilebilir.

Geçen hafta burada duyurusunu yaptığımız ancak ertelemek dumunda kaldığımız “Hyper-V Server 2008 ile Sıfır Maliyetli Sunucu Sanallaştırma” konulu webcast’i 11.03.2008 Çarşamba günü, saat 10:00-11:00 arasında gerçekleştiriyoruz.

Bildiğiniz gibi Hyper-V ücretsiz bir teknoloji ancak Windows Server 2008 ile birlikte kullanıyorsak, Windows Server 2008 lisansına sahip olmamız gerekiyor.

Bu webcast’imizde Hyper-V’nin tamamen ücretsiz sürümü olan ancak birtakım limitleri bulunan Hyper-V Server 2008 üzerine konuşacağız. Hyper-V Server 2008′in yönetimi için kullanabileceğimiz ücretsiz araçları inceleyeceğiz, yönetimin nasıl gerçekleştiğine bakacağız ve yine ücretsiz fizikselden sanala dönüştürme yöntemlerine göz atacağız.

Yani konumuz sıfır maliyetli sunucu sanallaştırma (Ekonomik krize uygun bir konu :))

Webcast bilgileri aşağıda yer alıyor.

Webcast (Çarşamba)

Konu : Microsoft Hyper-V Server 2008 ile Sıfır Maliyetli Sunucu Sanallaştırma
Konuşmacı : Serhat AKINCI
Başlama zamanı : 11 Mart 2009, Çarşamba,   10:00
Bitiş zamanı : 11 Mart 2009, Çarşamba, 11:00
Katılım Bağlantısı : https://www.livemeeting.com/cc/microsoft/join?id=DWM722&role=attend

Web seminerine nasıl katılabilirsiniz? ve ayrıntılar

2010 yılında release olması beklenen Windows Server 2008′in ikinci dağıtımı R2 versiyonu 256 adet logical processor (mantıksal işlemci) destekliyor.

Örneğin sunucu üzerinde 1 adet Quad-Core processor var ise bu 4 adet logical processor demektir çünkü Quad-Core işlemciler 4 çekirdeğe sahiptir.

Ya da 2 adet Dual-Core processor var ise, bu yine 4 adet logical processor demektir çünkü her bir Dual-Core processor 2′şer çekirdeğe sahiptir, toplamda 4 yapar.

Aşağıdaki resimde tek bir Quad-Core processor ile çalışan Windows Server 2008 den alınmış task manager görüntüsünü yer alıyor.

CPU Usage History bölümünde 4 logical processor’ün listelendiğini görüyorsunuz. Bu arada Windows Server 2008 64 adet logical processor çalıştırabilir. Peki Windows Server 2008 R2 ? Yazının devamını oku … »

İlk bölümde VMM2008 ile aynı domain ortamında yada trusted bir domain ortamında çalışan Hyper-V Host’ların eklenmesi işlemini incelemiştik. Bu makaleye buradan ulaşabilirsiniz.

Makalemizin bu bölümünde Perimeter Network içerisinde çalışan Hyper-V Host’ları System Center Virtual Machine Manager 2008’e ekleme yöntemini ve Local Agent kurulumunu göreceğiz.

Hatırlarsanız bu tip host’ları (yani perimeter network içinde çalışan) eklerken, host üzerine agent kurulumunu manuel olarak yapmak zorundaydık. Bu nedenle öncelikle SCVMM2008 kurulum medyasını, ekleyeceğimiz host üzerinde çalıştırıyoruz ve aşağıdaki pencerede Local Agent seçerek kurulumu başlatıyoruz.

Aşağıdaki pencerede Next ile ilerliyoruz. Yazının devamını oku … »