Hyper-V Ortamında SQL Server 2008 Çalıştırma

Transkript

Hyper-V Ortamında SQL Server 2008 Çalıştırma
 Hyper-V Ortamında SQL Server 2008 Çalıştırma
En İyi Yöntemler ve Performans Değerlendirmeleri
SQL Server Teknik Makalesi
Yazarlar: Lindsey Allen, Mike Ruthruff, Prem Mehra
Teknik Gözden Geçirme: Cindy Gross, Burzin Petal, Denny Lee, Michael Thomassy, Sanjay
Mishra, Savitha Padmanabhan, Tony Voellm, Bob Ward
Yayımlanma Tarihi: Ekim 2008
Uygulama alanı: SQL Server 2008
Özet:
Windows Server 2008'deki Hyper-V, TCO'yu düşürerek ve Hizmet Kalitesini koruyarak veya
geliştirerek, yeterince kullanılamayan sunucuları birleştirmek için kurumsal BT'nin
kullanabileceği güçlü bir sanallaştırma teknolojisidir. SQL Server uygulamasının temel
prensiplerini temsil eden bir dizi test senaryosuyla bu belge Windows Hyper-V ortamında SQL
Server'ı çalıştırmak için en iyi yöntem tavsiyelerini size sunar.
Telif Hakkı
Bu belgenin içerdiği bilgiler, Microsoft Corporation'ın bu sorunlar konusunda yayımlanma
tarihindeki görüşünü belirtir. Microsoft değişen pazar koşullarına yanıt vermek zorunda olduğu
için, bu belge Microsoft tarafından verilen bir taahhüt olarak değerlendirilmemelidir ve Microsoft,
yayımlanma tarihinden sonra sunulan bilgilerin tutarlılığını garanti etmez.
Bu teknik inceleme yalnızca bilgilendirme amaçlıdır. MICROSOFT, BU BELGEDEKİ
BİLGİLERLE İLGİLİ OLARAK AÇIK, ZIMNİ VEYA KANUNİ HİÇBİR GARANTİ VERMEZ.
Tüm geçerli telif hakkı yasalarına uymak kullanıcının sorumluluğundadır. Telif hakları
kapsamındaki haklar saklı kalmak kaydıyla, Microsoft Corporation’ın yazılı açık izni olmadan bu
belgenin hiçbir bölümü herhangi bir biçimde, herhangi bir yöntemle (elektronik, mekanik,
fotokopi, kayıt veya başka şekilde) veya herhangi bir amaçla çoğaltılamaz, yeniden
kullanılabileceği bir sisteme yerleştirilemez veya böyle bir sistemde saklanamaz veya iletilemez.
Microsoft bu belgedeki konuyu kapsayan patentlere, patent uygulamalarına, ticari markalara,
telif haklarına veya başka fikri mülkiyet haklarına sahip olabilir. Microsoft'un herhangi bir yazılı
lisans sözleşmesinde açıkça belirtilmedikçe, bu belgeye sahip olmak size bu patentler, ticari
markalar, telif hakları veya diğer fikri mülkiyet hakları için herhangi bir lisans vermez.
Aksi belirtilmedikçe, burada adı geçen şirket, kuruluş, ürünler, etki alanı adları, e-posta adresleri,
logolar, kişiler, yerler ve olaylar gerçek dışıdır; gerçek şirket, kuruluş, ürün, etki alanı adı, eposta adresi, logo, kişi, yer ve olaylarla ilişkilendirilmemeli ve bu şekilde yorumlanmamalıdır.
© 2008 Microsoft Corporation. Tüm hakları saklıdır.
Microsoft, Hyper-V, SQL Server, Windows ve Windows Server Microsoft şirketler grubunun
ticari markalarıdır.
Diğer tüm ticari markalar kendi sahiplerine aittir.
İçindekiler
Giriş ............................................................................................................................................................... 4 Hyper‐V Yapılandırma Kurulumu ve Yapılandırması .................................................................................... 4 Hyper‐V Ön Yükleme İçin Yapılacaklar Listesi ve Dikkate Alınacak Hususlar ............................................ 4 Depolama Yapılandırma Tavsiyeleri.......................................................................................................... 5 Test Metodolojisi ve İş Yükleri ...................................................................................................................... 5 Test İş Yükleri ............................................................................................................................................ 6 Hyper‐V Yapılandırmalarında SQL Server'ı İzleme ................................................................................... 7 Test Sonuçları, Gözlemler ve Tavsiyeler...................................................................................................... 10 Hyper‐V'de SQL Server'ı Çalıştırmanın Performans Ek Yükü .................................................................. 10 Doğrudan Geçiş Diskleri G/Ç Ek Yükü‐ SQLIO ..................................................................................... 11 Sanal Makine Performans Ek Yükü: OLTP İş Yükü............................................................................... 13 Raporlama Sorgusu Performans Karşılaştırması ................................................................................. 16 Veritabanı İşlemleri ............................................................................................................................. 17 Hyper‐V Kullanarak SQL Server Birleştirme Senaryoları ......................................................................... 21 Birleştirme Ortamında Depolama Yapılandırmalarını Karşılaştırma................................................... 22 Sanal Örnek Ölçeklenebilirliği ............................................................................................................. 24 Aşırı Yürütülen CPU Kaynaklarıyla Sanal Örnek Performansı.............................................................. 26 Birleştirme Seçeneklerini Karşılaştırma .............................................................................................. 27 Sonuç........................................................................................................................................................... 28 Gözlemler:............................................................................................................................................... 28 Tavsiyeler: ............................................................................................................................................... 29 Daha Fazla Bilgi ....................................................................................................................................... 29 Ek 1: Hyper‐V Mimarisi ............................................................................................................................... 30 Ek 2 Donanım gereksinimleri ...................................................................................................................... 33 Bellek....................................................................................................................................................... 33 İşlemciler ................................................................................................................................................. 33 Ağ ............................................................................................................................................................ 34 Depolama................................................................................................................................................ 34 Ek 3 Donanım Yapılandırması ..................................................................................................................... 35 Giriş
Windows Server® 2008 işletim sisteminde bulunan, hiper yönetim teknolojisine dayalı Hyper-V™
sanallaştırma özelliği, donanım ve işletim sistemi arasında bulunan, birden çok işletim sisteminin
değiştirilmeden aynı anda tek bir ana bilgisayarda çalışmasını sağlayan ince bir yazılım
tabakasıdır. Hyper-V, toplam sahip olma maliyetini (TCO) düşürerek ve hizmet kalitesini (QoS)
koruyarak veya geliştirerek, yeterince kullanılamayan sunucuları birleştirmek için kurumsal
BT'nin kullanabileceği güçlü bir sanallaştırma teknolojisidir. Hyper-V, aksi durumda donanım
yetersizliği tarafından kısıtlanacak potansiyel gelişme ve test ortamı türleri sağlar.
Genelde mevcut iş yükünü birleştirmek ve büyüme alanı sağlamak için donanımı doğru
ayarlamak yeterince zordur. Karışıma sanallaştırmayı da eklemek, olası kapasite planlama
zorluklarını daha da artırır. Bu belgenin amacı, bir Hyper-V ortamında Microsoft® SQL Server®
çalıştırmanın iki önemli alanına odaklanarak bunlara çözüm bulmanıza yardımcı olmaktır:
•
•
Hyper-V ortamında SQL Server çalıştırmaktan kaynaklanan sistem kaynağı ek yükü
Hyper-V çalışan SQL Server 2008'i ne kadar iyi ölçeklendirilebileceği
Bu teknik inceleme, Hyper-V'de çalışan SQL Server'ı kapsayan çeşitli olası senaryoları temsil
eden bizim bir dizi test yapılandırmalarını açıklamaktadır. Bu belgede sonuçlarımız ve
gözlemlerimiz tartışılmış ve tavsiyelerimiz sunulmuştur. Test sonuçlarımız, Hyper-V'de SQL
Server 2008'in istikrarlı bir performans ve ölçeklenebilirlik sağladığını gösteriyor. Windows
Server 2008 Hyper-V'nin SQL Server 2008 için uygun iş yükünde güçlü bir platform olduğunu
düşünüyoruz. İş yükü Hyper-V konuk sanal makinenizin kapasitesi dahilinde olduğu müddetçe,
üretim iş yüklerini Hyper-V ortamında çalıştırmak faydalı bir yöntemdir.
Hyper-V Yapılandırma Kurulumu ve Yapılandırması
Bu bölümde, basitleştirilmiş bir Hyper-V yüklemesi için yapılacaklar listesi bulunur. Hyper-V
hakkında daha fazla bilgi için, bu incelemenin sonunda bulunan ve test için kullandığımız
donanımı açıkladığımız ek teknik incelemelerine ve Ek 3'e bakın.
Hyper-V Ön Yükleme İçin Yapılacaklar Listesi ve Dikkate Alınacak Hususlar
•
•
•
Donanım destekli sanallaştırmayı destekleyen bir sunucu işlemcisi kullanın.
İki seçeneğiniz vardır:
o Inter VT
o AMD Virtualization (AMD-V)
Donanım destekli sanallaştırma ve Veri Yürütme Engellemesinin (DEP) hazır ve etkin
olduğundan emin olun. (Bunu BIOS ayarlarından doğrulayabilirsiniz.)
Yalnızca Windows® işletim sisteminin kök bölümündeki Hyper-V sunucu rolünü
çalıştırın.
•
•
•
•
Konuk sanal makine için doğrudan geçiş diski olarak yapılandırılacak diskleri,
DISKPART veya Birim Yöneticisi kullanarak kök bölümde çevrimdışı olarak ayarlayın.
Konuk sanal makineye tümleştirme bileşenlerinin (“geliştirmeler”) yüklendiğinden emin
olun.
Sanal makine için ağı yapılandırırken eski ağ adaptörünün yerine bir ağ adaptörü kullanın.
SQL Server dağıtımları için öykünmüş aygıtları kullanmaktan mümkün olduğunca
kaçının. Sentetik aygıtlara nazaran bu aygıtlar daha çok CPU ek yüküne neden olabilirler.
Depolama Yapılandırma Tavsiyeleri
Herhangi bir SQL Server dağıtımında, düzgün boyutlandırılmış ve yapılandırılmış G/Ç
performans için çok önemlidir. Sanallaştırılmış ortamlarda depolamayı yapılandırmak da farklı
değildir; depolama donanımının, planlanan sanal makinelerin mevcut ve gelecekteki ihtiyaçlarını
karşılamak için yeterli G/Ç iş çıkışı ve depolama kapasitesi sağlaması gerekir. Depolamanızı
yapılandırırken tüm yöntemlerini izlediğinizden emin olun.
Hyper-V birkaç farklı depolama seçeneğini destekler. Depolama seçeneklerinin her biri bir IDE
veya SCSI denetleyicisi vasıtasıyla eklenebilir. SQL Server veri ve günlük dosyaları için sanal
SCSI denetleyicisi yapılandırma seçeneğini kullandık. SQL Server G/Ç yoğun olduğundan,
en iyi iki performans seçeneğinden birini tercih etmenizi tavsiye ederiz:
•
Doğrudan geçiş diski
Sabit boyutlu Sanal Sabit Diskler (VHD'ler) Dinamik VHD'ler performans nedeniyle tavsiye
edilmez. Bunun nedeni dinamik VHD'lerde, diskteki öbekler sıfırlanmış öbek olarak başlar ancak
dosyada herhangi bir gerçek alan tarafından desteklenmez. Bu tür öbeklerden okuma sadece
sıfırlarla dolu bir öbek döndürür. Bir öbek ilk yazıldığında, sanallaştırma yığınının VHD dosyası
içinde öbek için alan tahsis etmesi ve ardından meta veriyi güncellemesi gerekir. Bunun yanı sıra,
mevcut bir öbeğe her gönderme yapıldığında, meta verideki öbek eşleştirmesine bakmak gerekir.
Bu okuma ve yazma işlemleri için G/Ç sayısını ve CPU kullanımını artırır. Dinamik büyüme,
depolama gereksinimi arttıkça yeterli disk alanı olduğundan emin olmak için sunucu
yöneticisinin disk kapasitesini izlemesini de gerektirir. Sabit boyutlu VHD'ler gerekirse
genişletilebilir ancak bunun için işlem sırasında konuk sanal makinenin kapatılması gerekir.
Bu inceleme için test senaryolarında hem doğrudan geçiş hem de sabit boyutlu VHD depolama
yapılandırmalarını kullandık. Tüm yapılandırmalarda konuk sanal makineler için sentetik SCSI
denetleyicileri kullanıldı. Bu testler için kullandığımız donanım hakkında daha fazla bilgi için,
bkz. Ek 3. (Not: Sentetik IDE test edilmedi.)
Test Metodolojisi ve İş Yükleri
SQL Server 2008 uygulamalarını Hyper-V ortamında çalıştırmak için en iyi yöntemleri ve
performans değerlendirmelerini belirlemek üzere bir dizi test senaryosu seçtik. İlk test
senaryomuz yerel ortam ve Hyper-V konuk sanal makine ortamındaki performans ek yükü
karşılaştırmasını anlamak üzere tasarlandı. İkinci test senaryomuz bir ana sunucu üzerinde konuk
sanal makineyi ölçeklendirme özelliklerini anlamak için tasarlandı.
Test İş Yükleri
Farklı senaryoların performansını ölçmek için birkaç iş yükü kullanıldı. Bu teknik incelemede,
yerel Hyper-V etkinleştirilmemiş bir Windows kurulumu anlamına gelir; kök Hyper-V
etkinleştirilmiş bir Windows Hyper-V yapılandırmasında ana bölüm anlamına gelir; konuk sanal
makine Windows'un kök (veya ana) bölümünde bulunan konuk sanal makine anlamına gelir.
Bu senaryoların asıl odağı aşağıdakilerdi:
•
•
•
Bir kök ve konuk sanal makinede çalışan SQL Server'ın performansını karşılaştırmak.
Bir yerel Windows örneğinde çalışan birden fazla SQL Server örneğiyle birden fazla
konuk sanal makinede çalışan tek SQL Server örneğinin performansını karşılaştırmak.
Tek bir kök bölüm üzerinde çalışan konuk sanal makine sayısı artarken SQL Server iş
yükü çıkışının ölçeklenebilirliğini gözlemlemek.
Bu test için kullanılan iş yükleri, özellikleri ve her bir iş yükü için hedeflenen senaryolar
aşağıdaki tabloda açıklanmıştır.
Tablo 1: İş Yükleri ve Senaryolar İş Yükü
Genel özellikler
Hedeflenen senaryolar
SQLIO
GÇ iş yükü üretir.
•
OLTP iş yükü
OLTP türü iş yükü müşteriyi
karşılayan aracı bir uygulamaya
benzer. Donanım
yapılandırmasıyla ilgili daha fazla
bilgi için, bkz. Ek 3.
•
•
•
Raporlama iş
yükü
Büyük miktarda CPU ve G/Ç
kaynağı kullanan raporlama
sorguları.
•
SQL Server
işletimsel iş
yükü
Yedekleme/Geri Yükleme,
yeniden dizin oluşturma, DBCC
CHECKDB.
•
Ana ve konuk sanal makine
üzerinde G/Ç performansını
karşılaştırma.
Yerel, kök ve konuk sanal
makine arasında iş yükü
performansı karşılaştırması.
Bir yerel Windows'ta çalışan
birden fazla SQL Server
örneğiyle her biri tek bir SQL
Server örneği çalıştıran birden
fazla konuk sanal makinenin
karşılaştırması.
Konuk sayısı artarken iş yükü
çıkışını ölçeklendirme.
Yerel, kök ve konuk sanal
makine arasında raporlama
sorgusu performansını
karşılaştırma.
Yerel, kök ve konuk sanal
makineleri arasında veritabanı
işlemlerinin performansını
karşılaştırma.
Aşağıdaki listede çalıştırılan iş yüklerinin her biri tarafından hedeflenen senaryolar hakkında
daha fazla bilgi bulunmaktadır:
•
•
•
•
SQLIO testi: SQLIO, verilen bir yapılandırmanın G/Ç kapasitesini belirlemek için
kullanılan bir araçtır. Bu test senaryosu depolama ayarı olarak doğrudan geçiş diski
kullanarak bir konuk sanal makine çalıştırırken G/Ç ek yükünü belirlemek için tasarlandı.
OLTP iş yükü. Bu test senaryosu:
o Yerel Windows ortamında çalışan SQL Server'ın performansını, bir konuk sanal
makine altındaki performansıyla karşılaştırır. Bu karşılaştırma için, hem yerel
örnek hem de konuk sanal makine eşit donanım yapılandırmalarıyla yapılandırıldı.
o Veri ve günlük dosyaları için çeşitli depolama yapılandırmalarını kullanarak SQL
Server'ın performansını karşılaştırır. Doğrudan geçiş diski yapılandırması ve
VHD yapılandırmalarının karşılaştırması ve altında bulunan farklı depolama
dizini ayarları (yani paylaşılan ve adanmış bellek yapılandırmaları karşılaştırması).
o Windows ortamında yerel olarak çalışan birden çok SQL Server örneğinin
performansını, her biri tek bir SQL Server örneği ile yapılandırılan eşit sayıda
konuk sanal makineyle karşılaştırır.
o Tek bir fiziksel sunucunun kök bölümüne daha çok konuk sanal makine
eklendikçe iş yükü ölçeklendirmesini gözlemler. Bu durumda, gözlemlediğimiz
vakalarda aşağıdakiler gerçekleşti:
ƒ Tüm konuk sanal makineler için mantıksal CPU çekirdeklerinin toplamı,
fiziksel CPU çekirdeklerinin sayısına eşitti.
ƒ Tüm konuk sanal makinelerde ( “aşırı yürütülen” CPU kaynakları denilen)
mantıksal CPU çekirdeklerinin toplamı, fiziksel CPU çekirdeklerinin
sayısından fazlaydı.
Raporlama iş yükü: Bu senaryo, Windows ortamında yerel olarak çalışan SQL Server'ın
performansını, eşit donanım yapılandırmasındaki bir konuk sanal makine üzerinde çalışan
SQL Server'ın performansıyla karşılaştırır.
Veritabanı işlemleri: Bu senaryo, Windows ortamında yerel olarak çalışan SQL Server'ın
performansını, eşit donanım yapılandırmasındaki bir konuk sanal makine üzerinde çalışan
SQL Server'ın performansıyla karşılaştırır.
OLTP iş yükünü kullanan senaryolarda, farklı CPU seviyeleri altındaki davranış farklarını
gözlemlemek için bazı farklı iş yükü seviyeleri kullanıldı. Bu farklı iş yükü seviyelerinin
ayrıntıları daha sonra bu teknik incelemede tartışılacaktır.
Hyper-V Yapılandırmalarında SQL Server'ı İzleme
Hyper-V yapılandırmasında çalışan SQL Server iş yüklerinin performansını Windows Sistem
İzleyicisi (genellikle perfmon olarak bilinir) kullanarak izlerken dikkate alınacak bazı hususlar
vardır. Kaynak kullanımını doğru olarak ölçmek için, kök bölümünde Windows tarafından
ortaya çıkarılan Hyper-V sayaçlarını kullanmak gerekir. Derinlemesine bir Hyper-V izleme
tartışması, bu teknik izlemenin kapsamı dışındadır. Daha fazla bilgi için, bkz. Ek 3.
Bu test sırasında performans izleme konusunda bazı gözlemlerde bulunduk. Dikkate alınacak
hususların çoğunluğu CPU kullanımı ölçümleriyle ilgilidir. Hyper-V çalıştıran bir sunucuda CPU
kullanımını izlerken, kök bölümünde çıkan Hyper-V İşlemci sayaçlarını kullanmanız gerekir.
Hyper-V, CPU kullanımıyla ilgili üç ana sayaç çıkarır:
•
•
•
Hyper-V Hiper Yönetici Mantıksal İşlemci: Tüm fiziksel sunucuda kullanılan toplam
CPU kaynağı hakkında en doğru sonucu verir.
Hyper-V Hiper Yönetici Kök Sanal İşlemci: Kök bölüm tarafından kullanılan CPU
kaynaklarının en doğru ölçümünü sunar.
Hyper-V Hiper Yönetici Sanal İşlemci: Belirli konuk sanal makineler için CPU
kullanımının en doğru ölçümünü sunar.
Geleneksel İşlemci Zamanı % sayaçları kök bölüm içinde izlenebilir ancak bu işlemci
sayaçlarının etkili olmadığı sanallaştırma katmanları olduğu için gerçek CPU kaynak kullanımını
yansıtmayabilirler. Performansı izlerken, hiper yönetici etkinken Hyper-V rolünü çalıştıran
herhangi bir sunucuda CPU kullanımını Hyper-V sayaçlarını kullanarak ölçün. Daha fazla bilgi
için Tony Voellm’in Hyper-V performans izleme hakkındaki bloğunu okuyabilirsiniz.
Şekil 1'de bu sayaçların her biri gösterilmiştir. Bu resimde, en üstteki sayaç kümesi
(\\SQLBP08R900) kök bölümünde izlenir ve alttaki küme (\\sqlhv1) konuk perspektifinden izlenen
sayaçları gösterir. Bu örnekte, kök bölümde görünen 16 fiziksel CPU çekirdeği ve konuk sanal
makinede görülen dört mantıksal CPU çekirdeği olduğunu unutmayın. Ayrıca kökte çalışan iki
konuk sanal makine olmasına rağmen, alan kısıtlaması nedeniyle yalnızca bir tanesi grafikte
gösterilmiştir. İkinci sanal makinenin dört adet mantıksal işlemci sayacı grafiğin sağ tarafında
devam eder.
Şekil 1: Hyper‐V perfmon sayaçları İzleme ve bu özel sorunlar hakkında daha fazla bilgi için, Windows 2008 performans ayarlama
yönergeleri sanallaştırma bölümüne ve Hyper-V sayacı bloglarına bakın.
SQL Server'ı izleme konusunda da bir konuk sanal makine üzerinde çalışırken özel bir husus
yoktur. SQL Server sayaçları genelde ya tüketim (SQL Server'a özel kaynaklar) ya da iş çıkışı
ölçümü içindir. Ek olarak, SQL Server sayaçları bir konuk sanal makinede çalışırken kök
bölümde görünmezler; konuk sanal makine içinde izlenmeleri gerekir.
Konuk depolama yapılandırmasına bağlı olarak G/Ç performansı ölçümü farklı olur. Gecikme,
geçen zamanın ölçütüdür ve kök veya konuk makine üzerinden makul doğruluk değerleriyle
ölçülebilir. Aşağıda disk performansını izleme hakkında bazı genel hususlar verilmiştir:
•
•
•
G/Ç performansını izlemek için konuk sanal makine içinde mantıksal veya fiziksel disk
sayaçlarını kullanabilirsiniz. Kök bölümdeki sayaçlar tarafından bildirilen değerlerle
konuk sanal makinedeki sayaçlar tarafından bildirilen değerler arasında çok az farklılık
olduğunu gördük; ancak, konuk sanal makineden izlediğimizde kök bölümünden
izlediğimizden biraz daha yüksek gecikme değerleri (Ort. Disk/sn Okuma ve Yazma)
gördük. Bunun nedeni sanal makine perspektifinden G/Ç'nin tamamlanmasının biraz
daha uzun sürmesidir.
Konuk sanal makine depolaması doğrudan geçiş olarak yapılandırılmışsa, disk kök
bölümü katmanında çevrimdışı görünür ve kök bölüm içinde mantıksal disk sayaçları
altında görünmez. Kök bölümde doğrudan geçiş disklerin performansını izlemek için,
fiziksel disk sayaçlarının kullanılması gerekir. Testler sırasında, Windows Server 2008
fiziksel disk sayaçlarında çok yollu çözümler kullanıldığında bilinen sorunlar vardı.
Bu sorunlar en son Sistem Merkezi Sanal Makine Yöneticisi GDR'sinde düzeltildi.
Konuk sanal makineler depolama için VHD dosyaları kullanacak şekilde
yapılandırıldıklarında ve bu VHD dosyaları ortak fiziksel disklerde bulunduğunda,
disk sayaçlarını konuk sanal makineden izlediğinizde o VHD için G/Ç detaylarını
görebilirsiniz. Kök bölümdeki tüm VHD dosyalarının bulunduğu bölümünü izlediğinizde
disk veya disk bölümüne karşı toplam G/Ç değerlerini görebilirsiniz.
Tablo 2, testlerimizin OLTP iş yükü bölümü için çalıştırılan iş yüklerinden toplanan sayaç
türlerini göstermektedir. Konuk sanal makineden ve kök bölümden izleme yapıldığında
performans sayaçlarında bildirilen farkları göstermektedir.
Tablo 2: Sayaçlar ve İş Yükleri Ölçüm yapılan sayaçlar… Konuk sanal
makine
Düşük OLTP iş yükü Orta OLTP iş yükü Yüksek OLTP iş yükü İşlem/sn 352 546 658 Toplu İş/sn 565 897 1075 İşlemci Süresi % 34,2 65,3 84,2 Öncelik Süresi % 5,1 8 8,4 Mantıksal ‐ Ort. Disk sn/Okuma(_Toplam) 0,005 0,006 0,007 Mantıksal ‐ Disk Okuma/sn (_Toplam) 1053 1597 1880 Sayaç Kök bölüm
İşlemci Süresi % 4,9 7,8 11,2 Öncelik Süresi % Hyper‐V Mantıksal İşlemci ‐ Hiper Yönetici Çalışma Süresi % Hyper‐V Mantıksal İşlemci ‐ Toplam Çalışma Süresi % Hyper‐V Mantıksal İşlemci ‐ Konuk sanal makine Çalışma Süresi % 3,6 6,1 7,3 4 4,8 4,3 39,1 68,7 86,5 35,1 63,9 82,1 Fiziksel ‐ Ort. Disk sn/Okuma(_Toplam) 0,005 0,006 0,006 Fiziksel ‐ Disk Okuma/sn (_Toplam) 1053 1597 1880 Her CPU başına toplu iş % (Toplu iş/sn / Konuk sanal makine Çalışma Zamanı %) 16,1 14 13,1 Not: Kök bölümde ölçülen Hyper-V sayaçları, çalışan tüm konuk sanal makinelerin
toplamıdır.
Test Sonuçları, Gözlemler ve Tavsiyeler
Bu bölümde test sonuçlarını özetleyip analiz edecek ve sanallaştırılmış bir ortamda SQL Server'ı
çalıştırmak için tavsiyelerimiz ve gözlemlerimiz hakkında ayrıntılı bilgi vereceğiz. Bu bölüm iki
kategori olarak hazırlanmıştır: İlk kategoride Hyper-V ortamında SQL Server çalıştırılırken
oluşan temel kaynak ek yükü tartışılmakta, ikinci grupta da SQL Server'ı sanal örnekler olarak
birleştirmenin etkileri tartışılmaktadır.
Hyper-V'de SQL Server'ı Çalıştırmanın Performans Ek Yükü
İlk gruptaki test senaryoları “ayıklanmış” Hyper-V ortamında SQL Server'ı çalıştırmanın
performans ek yükünü anlamak için tasarlandı. Temel değerlendirme testleri üç şekilde yürütüldü:
yerel Windows ortamında Hyper-V devre dışı bırakılıp, kök bölümünde Hyper-V etkinleştirilip
ve tek bir konuk sanal makinede. Her durumda, donanım yapılandırması aynıdır.
Not: Yerel örnek yerel Windows ortamında çalışan bir SQL Server örneğidir ve sanal örnek
konuk sanal makinede çalışan bir SQL Server örneğidir.
Bu bölümde aşağıdaki test senaryoları bulunmaktadır:
•
•
•
•
SQLIO kullanarak doğrudan geçiş disklerinin G/Ç ek yükünü belirleme
OLTP iş yükü performansını bir yerel örnek ve sanal örnek arasında karşılaştırma
Yerel bir örnek ve sanal bir örnekte raporlama sorgusu performansını karşılaştırma
Ortak veritabanı işlemlerinde sanallaştırmanın etkisini gözlemleme:
o Sıkıştırılmış yedekleme ve geri yükleme
o Yeniden dizin oluşturma
o DBCC CHECKDB
Doğrudan Geçiş Diskleri G/Ç Ek Yükü- SQLIO
G/Ç ek yükü, sanallaştırılmış ortamlarda sorunlu bir konuydu. Bu, SQL Server gibi G/Ç
yoğunluğuna sahip uygulamalar için önemli sorunlara yol açabilirdi. Hyper-V ile teknoloji
değişmiştir. En iyi durum senaryosunu anlamak için en iyi G/Ç yapılandırması olan adanmış
doğrudan geçiş diski kullanarak G/Ç ek yüküne baktık. Ana sistemden G/Ç alt sistemine en kısa
kod yoluna sahip olduğu için doğrudan geçiş disk yapılandırmasını seçtik. Testlerde, kök bölüme
ve konuk sanal makineye aynı sayıda fiziksel iğne tahsis edildi. Çeşitli rasgele ve sıralı G/Ç
testlerini tekrarlayarak doğrudan geçiş diski kullanan Hyper-V'nin G/Ç ek yükünün sıfır ila
minimum arasında olduğunu gördük. Doğrudan geçiş diskleri ve sanal sabit disklerin
derinlemesine bir performans analiziyle birlikte daha fazla bilgi için, Tony Voellm ve Liang
Yang'ın yakında çıkacak olan “Windows Server 2008 Hyper-V Sanal Sabit Disk ve Doğrudan
Geçiş Disk Performansı” çalışmasına bakın. Ayrıca Hyper-V depolama performansı analizi
hakkında buradan (http://blogs.msdn.com/tvoellm/archive/2008/09/24/what‐hyper‐v‐storage‐is‐best‐
for‐you‐show‐me‐the‐numbers.aspx) daha fazla bilgi edinebilirsiniz.
Depolama Yapılandırması
Kök ve sanal makine için doğrudan geçiş disk yapılandırması aynıydı. Her bir yapılandırma aynı
sayıda fiziksel disk kaynağı kullanan depolama dizininden mantıksal birim numaralarıyla (LUN)
sunuldu. Herhangi bir LUN arasında disk düzeyinde paylaşım yoktu; başka bir deyişle, LUN'lar
arasında iğne paylaşımı bulunmamaktaydı. Şekil 2'de her biri için sunulan yapılandırma
gösterilmiştir.
Şekil 2: Depolama yapılandırması doğrudan geçiş Doğrudan Geçiş Yapılandırması Performansı
İş çıkışı temeli için, tüm konuk sanal makinelerde ve kökte SQLIO testleri yapıldı. Şekil 3 ve 4'te
SQLIO kullanılan rastgele ve sıralı G/Ç testlerinin sonuçları gösterilmiştir. Bu test senaryosu için
iki yaygın SQL IO boyutunu seçtik (8K ve 64K).
Şekil 3: Doğrudan Geçiş 8K rasgele G/Ç Şekil 4: Doğrudan Geçiş 64K sıralı G/Ç Sanal Makine Performans Ek Yükü: OLTP İş Yükü
Bu test senaryosunun amacı, bir aracı uygulamaya benzeyen OLTP iş yükünü kullanarak SQL
Server 2008'i sanal makinede çalıştırmanın etkisini ölçmekti. Bu test için kullandığımız donanım
ayarları hakkında daha fazla bilgi için, bkz. Ek 3. Temel, kök ve konuk sanal makineye göre üç
düzey iş yükü çalıştırıldı. Temel, SQL Server örneğinin yerel sunucuda Hyper-V devre dışıyken
çalıştırılmasıdır. Bu, geçerli olması için Windows'un yeniden başlamasını gerektiren
hypervisorlaunchtype kapalı (örn. bcdedit /set hypervisorlaunchtype off) ayarı kullanılarak
yapıldı. Test senaryosu vurgu seviyeleri CPU kullanımı yüzdesine göre tanımlandı. Ürün
ortamında tamamen doygun CPU yaygın bir senaryo olmadığı için biz %20 ile %80 arasında bir
CPU vurgu seviyesi aralığı hedefledik. Her bir iş yükü seviyesinin CPU kullanma hedefleri
Tablo 3'te belirlenmiştir.
Tablo 3: CPU Kullanma Hedefleri Test iş yükü OLTP – Düşük OLTP – Orta OLTP – Yüksek Yaklaşık CPU hedefi %30 %50‐%60 %80 Hyper-V konuk sanal makinesi dört adede kadar mantıksal işlemciyi desteklediğinden,
doğrudan karşılaştırma için ana bilgisayar BIOS ayarlarından dört çekirdek kullanmaya ayarlandı
(NUMPROC=4). Depolama yapılandırmasının etkisini anlamak için iki sanal makine, SQL
Server iş yükleri için önerilen iki çeşit Hyper-V depolama yapılandırması (doğrudan geçiş
diskleri ve sabit VHD) kullanılarak iki sanal makine yapılandırıldı.
İş çıkışı ve İşlemci Etkisi
Hyper-V rolü devre dışı bırakılmış yerel Windows Server 2008 ortamında üç iş yükü
seviyesinin temel testi yapıldı. Aynı iş yükü kümesi Hyper-V etkin kök bölümünde,
doğrudan geçiş disk depolaması kullanmaya ayarlanmış bir konuk sanal makinede ve sabit
VHD depolama kullanan bir konuk sanal makinede çalıştırıldı.
Tablo 4'te %CPU başına düşen göreli toplu iş talebi ve tüm test vakalarındaki ek yük
gösterilmiştir. Bu senaryoda sistem tüm test vakalarında çok iyi sonuç verdi;
yapılandırmaların hepsi aynı iş çıkışını verdi, sanal makine aynı iş çıkışına erişmek için daha
yüksek CPU maliyetine neden oldu. Doğrudan Geçiş disklerinin ve sabit VHD'nin
performansları yüzde birden daha az bir ek yükü farkıyla birbirine çok yakındı.
Tablo 4'te OLTP iş yüklerini sanal makinede çalıştırmaktan doğan CPU ek yükü de
gösterilmiştir. Yüzde olarak ek yükün daha düşük bir iş yükünde daha yüksek olduğunu
gözlemledik. Sanal makineyle ilişkili belirli miktarda sabit iş ve CPU bulunmaktadır. Bu
daha küçük iş miktarlarına dağıtılırsa, ek yük yüzde olarak daha büyük olur. Performans
ölçütü olarak aşağıdaki formülü kullandık:
Toplu İş/%CPU = Toplu İş Talepleri/sn bölü CPU kullanım yüzdesi
Tablo 4: OLTP iş yüklerini çalıştıran sanal makine CPU ek yükü Düşük Toplu iş talebi/s Temel1
Kök
2
VM_PT
3
Toplu iş/%C
PU Orta Ek Yük Toplu iş talebi/s Toplu iş/%C
PU Yüksek Ek Yük Toplu iş talebi/s Toplu iş/%C
PU 5
Ek Yük 566
19,2
%0,00
908
16
%0,00
1069
14,8
%0.00
566
17,5
%8,85
907
14,8
%7,50
1113
13,5
%8,78
565
16,1
%16,15
897
14
%12,50
1075
13,1
%11,49
4
VM_VHD
563
15,7
%18,23
876
13,9 %13,13
1029
13,2
%10,81
1. Temel: Hyper-V rolü etkinleştirilen yerel bir Windows Server 2008 ortamı. Sanal ağ anahtarı kapatılmadı.
2. Kök bölüm: Windows Server 2008'de Hyper-V'nin etkin olduğu bir kök bölüm.
3. VM_PT: doğrudan geçiş diskleri, dört mantıksal işlemci ve 14 GB RAM ile yapılandırılan bir konuk sanal
makine.
4. VM_VHD: sabit VHD diskler, dört mantıksal işlemci ve 14 GB RAM ile yapılandırılan bir konuk sanal makine.
5. Ek yük Temelle karşılaştırılarak hesaplanır ((Temel Toplu İşler/CPU – VM Toplu İşleri/CPU)/ Temel
Toplu İşleri/CPU)
Şekil 5: Göreli iş çıkışı – %CPU başına toplu iş talebi Depolama Yapılandırması ve Performans
İki konuk sanal makine de SQL Server veri ve günlük dosyaları için aynı temel disk
yapılandırmasını kullandığından, bunlar doğrudan karşılaştırılabilir (iki sanal makinenin de
fiziksel yapılandırma detayları bu belgede daha önce geçmiştir ve SQLIO testi için kullanılan
yapılandırmayla aynıdır). Kök bölümünde görünen fiziksel disklerde bulunan tek dosyalar VHD
dosyalarıydı. SQL Server veri ve günlük dosyalarını depolamak için VHD'leri kullandığımızda,
Şekil 5'te gösterildiği gibi iş yükü çıkışında küçük bir etkiye dönüşen küçük bir gecikme
gözlemledik.
Konuk sanal makine yapılandırması için VHD kullanmanın hem yapılandırma hem de yönetim
avantajları vardır. İş çıkışı/performans perspektifinden bakıldığında, düşük ağırlıklı durumlarda
doğrudan geçiş ve sabit VHD arasında fark yoktur. İş yükü arttıkça doğrudan geçiş diski küçük
bir performans avantajı göstermeye başlar. Şekil 6'da bu OLTP test senaryosunda kaydedilen
Okuma performansı gösterilmiştir.
Şekil 6: Veri birimleri (saniye başına okuma) Şekil 7'de test sonuçlarında elde edilen ortalama disk gecikmesi gösterilmiştir. Beklenildiği gibi,
doğrudan geçiş diskin gecikmesi yerel depolamanın gecikmesine eşitken en çok gecikme
VHD'dedir. VHD gecikmesi için bildirilen gecikme değerleri konuk sanal makine sayaçlarından
bildirildi; ancak, bu değerlerle kök bölümden bildirilen değerler arasında fark bulamadık. Şekil 7: Ortalama disk gecikmesi Raporlama Sorgusu Performans Karşılaştırması
Raporlama sorguları genelde çok fazla CPU ve G/Ç kaynağı kullanan uzun süreli, salt okunur
sorgulardır. OLTP iş yükleriyle karşılaştırıldığında, bu tür sorgular genelde düşük kullanıcı eş
zamanlılığı altında yayınlanır. Bu test senaryosunda, kaynak tüketimini ve tamamlama süresini
ölçmek için peş peşe dört raporlama sorgusu gerçekleştirildi. Bu dört sorgu G/Ç açısından yoğun
sorgulardır ve toplanmalar nedeniyle önemli bir CPU kullanımına sahiptir. Sorguların mevcut
tüm CPU kaynaklarından faydalanması için sp_configure ‘maksimum paralellik derecesi’ ayarı
0 olarak ayarlanmıştır.
Sorguları konuk sanal makinede çalıştırmak ve kök bölümde veya yerel ortamda çalıştırmak
arasındaki fark çok azdı; konuk sanal makinelerde oldukça küçük bir performans ek yükü artışı
gözlemledik. Şekil 8'de sorguların tamamlanma süreleri ve CPU tüketimi gösterilmiştir.
Şekil 8: Raporlama sorgusu performansı Veritabanı İşlemleri
Bazı ortak veritabanı işlemleri CPU'ya oldukça yüklenir. Bu bölümdeki test sonuçları,
sıkıştırılmış yedekleme ve geri yükleme, tekrar dizin oluşturma ve DBCC CHECKDB gibi
veritabanı işlemlerinde sanallaştırmanın etkisini kapsamaktadır.
Yedekleme ve Geri Yükleme
Yedekleme ve geri yükleme işlemleri, yedekleme dosyalarının hedefi olan farklı bir fiziksel
sunucudaki dosya paylaşımı kullanılarak gerçekleştirildi. Bu durumda, yedekleme ve geri
yükleme disk veya işlemciye değil ağın bant genişliğine bağlıydı. Yedekleme işlemi testi için
SQL Server 2008 yerel yedekleme sıkıştırmasını kullandık.
Yerel bir işletim sisteminde gerçekleştirilen aynı işlemle karşılaştırıldığında, yedekleme iş
çıkışında kayda değer bir CPU artışıyla %10-15 civarında bir performans kaybı vardı. Geri
yükleme iş çıkışında da benzer bir düşüş gözlemlendi. Bu iş çıkışı kaybı konuk sanal makine
içindeki işlemler ağ kaynaklarını yoğun şekilde kullandığında oluşan ağ ek yüküyle açıklanabilir.
Testlerimizde, SQL Server Hyper-V konuk sanal makinesinden çalıştırıldığında oluşan ek yük
dikkate alındığında bunun en çok kaygı uyandıran alan olduğunu gördük. Bu, G/Ç veya CPU
işlemlerinde gözlemlenen herhangi bir ek yükten çok daha önemliydi.
Bu test senaryosunda, yedekleme ve geri yükleme işlemi sırasında ağ iş çıkışının 50-60 MB/sn
aralığında olduğunu gözlemledik. SQL Server için kullanılan sunucuda da, yedekleme hedefi
için ağ paylaşım dosyasının bulunduğu sunucuda da tek bir 1Gb/sn ağ adaptörü vardı.
Yedekleme ve geri yükleme iş çıkışı saniyede 100 MB civarındadır. Ölçümler SQL Server
yedekleme ve geri yükleme çıkışından alınmıştır. Bu işlem sırasında sıkıştırma yapılmıştır. Bu da
bildirilen iş çıkışının neden verilen ağ yapılandırmasının desteklediği ağ iş çıkışından kayda
değer ölçüde daha yüksek olduğunu açıklar.
Şekil 9, 10 ve 11 doğrudan geçiş diskleri ve sabit VHD kullanılarak yapılandırılan yerel, kök
bölüm ve sanal makinelerin yedekleme ve geri yükleme iş çıkışını göstermektedir. Y eksenindeki
göreceli iş çıkışı, saniye başına toplam megabayt bölü toplam ortalama CPU yüzdesi olarak
hesaplanır. Geri yükleme iş çıkışının biraz daha yüksek olması, hedef dosya paylaşımının yazma
performansıyla açıklanabilir (RAID5 kullanıldığı için o paylaşımın okuma performansı biraz
daha iyidir).
Şekil 9: Yedekleme ve geri yükleme iş çıkışı karşılaştırması Şekil 10: Yedekleme ağ ve CPU kullanımı Şekil 11: Geri yükleme ağ ve CPU kullanımı Tablo 5 bu test senaryosundan edindiğimiz verileri içermektedir. Tablo 5: Yedekleme ve Geri yükleme İş Çıkışı Temel Kök bölüm Konuk sanal makine (doğrudan geçiş) Konuk sanal makine (sabit VHD) Yedekleme iş çıkışı (MB/s)
Toplam yedekleme süresi (saniye)
Geri yükleme iş çıkışı (MB/s)
181,00
764,00
241,00
158,00
875,00
218,00
154,00
874,00
173,00
157,00
874,00
167,00
Toplam yedekleme süresi (saniye)
573
634
799
824
Yeniden Dizin Oluşturma
Yeniden dizin oluşturma çok yaygın bir veritabanı işlemidir ve hem CPU hem de G/Ç açısından
yoğun bir işlemdir. Bu testin amacı, yeniden dizin oluşturma işlemi üzerinde sanallaştırmanın
etkisini anlamaktı. SAYFA sıkıştırma etkin halde peş peşe üç büyük dizin yeniden oluşturuldu
(SQL Server 2008'in bir dizin içinde veri sayfalarını sıkıştıran yeni bir özelliğidir). CPU
baskısını artırmak için dizini SAYFA sıkıştırma etkin haldeyken oluşturduk. Kaynak kullanımı
ve tamamlama süresi alındı.
Aynı işlem sanal makinelerde gerçekleştirildiğinde çok az ek yük gözlemlendi. Şekil 12 dizin
oluşturma süresini ve yerel işletim sistemi, kök bölüm ve konuk sanal makinelerde CPU
yüzdesini göstermektedir.
Şekil 12: SAYFA sıkıştırmayla peş peşe yeniden oluşturulan üç dizin DBCC CHECKDB
Ayrıca başka bir CPU ve G/Ç açısından yoğun işlem olan DBCC CHECKDB işlemini de test
ettik. Konuk sanal makinede işlemi tamamlamak, ana işletim sistemine nazaran daha uzun
sürmektedir. Şekil 13, tamamlama zamanı ve işlem sırasında tüketilen toplam CPU kaynakları
karşılaştırmasını göstermektedir. Yeniden dizin oluşturma testlerinde olduğu gibi, tamamlama
süresinde çok az bir artış gözlemledik.
Şekil 13: MAXDOP 0 ile DBCC CHECKDB Hyper-V Kullanarak SQL Server Birleştirme Senaryoları
Bu test senaryoları dizisi Hyper-V ortamında SQL Server'ı birleştirmek hakkında bazı önemli
sorulara cevap vermek için tasarlanmıştır:
•
Birden çok örneğin depolama yapılandırmasının performans etkisi
Bu test senaryosunun amacı bir birleştirme ortamında adanmış ve paylaşımlı
depolamanın performansa etkisini anlamaktı.
•
Sanal örnek ölçeklenebilirliği
Bu test senaryosunun amacı, konuk sanal makine için yapılandırılmış mantıksal işlemciye
1:1 eşleşmeyi destekleyecek yeterli fiziksel işlemci olduğunda sanal örneğin
ölçeklenebilirliğini anlamaktı.
•
Aşırı Yürütülen CPU Kaynaklarıyla Sanal Örnek Performansı
Bu test senaryosunun amacı, sanal örnekler için yapılandırılan toplam mantıksal işlemci
sayısının sunucuda bulunan fiziksel işlemci sayısından daha fazla olmasının performansa
etkisini anlamaktı.
Birleştirme Ortamında Depolama Yapılandırmalarını Karşılaştırma
Şimdiye kadar doğrudan geçiş diskleri ve sabit VHD'lerin ikisinin de SQL Server iş yükü için iyi
depolama yapılandırması olduğunu gördük. Bu iki farklı depolama yapılandırmasının OLTP iş
yüküne etkisini daha iyi anlamak için, aşağıdaki depolama yöntemlerini karşılaştırmak üzere iki
grup test ayarladık:
•
•
Doğrudan Geçiş diskleri kullanan adanmış depolama (yani disk düzeyinde paylaşım yok)
SQL Server veri ve günlük dosyalar için VHD dosyalarıyla disk kaynaklarının ortak bir
havuzu
İlk depolama yapılandırmasında Şekil 14'te gösterildiği gibi her bir sanal makine için adanmış
depolamayla doğrudan geçiş diskleri kullanılmıştır. Her bir konuk sanal makine, veri dosyaları
için iki LUN'dan (150 GB) ve günlük dosyaları için bir LUN'dan (50 GB) oluşan bu
yapılandırmayla sunulmuştur. Konuk sanal makineler arasında fiziksel disk düzeyinde paylaşım
yoktu ve her LUN'un adanmış fiziksel diski vardı.
Şekil 14: Her sanal makine/kök için disk yapılandırması İkinci depolama yapılandırması Şekil 15'te gösterildiği gibi ortak bir disk havuzu kullanılarak
yapılandırıldı. Bu durumda, SQL Server veri dosyalarını içeren VHD dosyaları için tek bir disk
kaynağı, SQL Server günlük dosyalarını içeren VHD dosyaları için de ayrı bir disk kaynağı
havuzu kullanıldı. Sanallaştırılmış depolama ortamları için bu yapılandırma daha esnek bir
yaklaşım sunar.
Şekil 15: Tek havuz Sonra aynı OLTP tipi iş yükü iki yapılandırmada da farklı iş çıkışı seviyelerinde çalıştırıldı. Şekil
16 ve 17 doğrudan geçiş diski kullanan adanmış depolama yapılandırmasıyla VHD dosyalarını
kullanan paylaşımlı depolama yapılandırması arasındaki G/Ç iş çıkışı ve gecikme
karşılaştırmasını göstermektedir.
Şekil 16: Doğrudan Geçiş ve sabit VHD kullanırken G/Ç iş çıkışı ve gecikme Şekil 17: Paylaşımlı disklerde adanmış doğrudan geçiş LUN'ları ve sabit VHD iş çıkışı İki depolama yapılandırmasının da performansları birbirine yakındı. Ortalama olarak, sabit VHD
yapılandırması adanmış doğrudan geçiş disklerden %3,5 oranında daha yavaştı. Uygulamanız
için G/Ç performansı ve öngörülebilirliği önemliyse, adanmış disk kaynaklarında doğrudan geçiş
diskleri kullanmanızı tavsiye ederiz. Ancak, VHD dosyalarının sunduğu esneklik için küçük bir
götürü bulunmaktadır. Sanal Örnek Ölçeklenebilirliği
Aynı ana bilgisayar üzerinde birden çok sanal makine çalıştırmanın en yaygın dağıtım senaryosu
olduğu kesindir. Sanal makinelerle ölçeklendirilen veritabanı iş yükünün özelliklerini anlamak
için bu test senaryosunu dahil ettik.
Bu test için kullanılan Dell R900'de 16 fiziksel çekirdek bulunmaktadır. İki grup test vakası
gerçekleştirildi. İlk grupta 8 çekirdek kullanıldı (NUMPROC=8). İkinci grupta 16 fiziksel
çekirdeğin hepsi kullanıldı (NUMPROC=16). Tüm konuk sanal makineler dört mantıksal işlemci
ve 14 GB RAM ile yapılandırıldı. SQL Server 2 GB'lık bölümü işletim sistemine bırakıp 12
GB'lık bölümü kullanmaya ayarlandı.
İki Eş Zamanlı Konuk Sanal Makine
Bu test vakasında sekiz fiziksel işlemci kullanılarak yapılandırılan ana bilgisayarda eş zamanlı
çalışan iki sanal makine bulunuyor. İki sanal makine de dört mantıksal işlemciyle yapılandırıldı.
Sanal makineler aynı öncelikli depolamayla yapılandırıldı.
Şekil 18'deki sonuç tablosu iş yükü arttıkça yapılandırmanın daha iyi ölçeklendirdiğini
göstermektedir.
Şekil 18: Eş zamanlı konuk sanal makinelerin ölçeklenebilirliği Dört Eş Zamanlı Konuk Sanal Makine
Bu testi fiziksel işlemcilerin mantıksal işlemcilerle birebir eşleşmesini destekleyecek yeterli
işlemci kaynağı olduğunda OLTP iş yükü çalıştıran sanal makinelerin ölçeklenebilirliğini
anlamak için gerçekleştirdik. Ana bilgisayarda 16 CPU vardı ve her sanal makine dört mantıksal
işlemciyle yapılandırıldı. Dört sanal makinenin hepsinde öncelikli depolama aynıydı.
Şekil 19'da gösterilen sonuçlar CPU'ya aşırı yüklenilmediğinde sanal makinelerin çok iyi
ölçeklenebildiğini göstermektedir. İki eş zamanlı konuk sanal makineyle karşılaştırıldığında dört
eş zamanlı sanal makinede daha fazla ek yük gözlemlenebilir. Eş zamanlılığın artması nedeniyle
bu beklenen bir şeydir.
Şekil 19: Aşırı yürütülen CPU'lar olmadan sanal makine ölçeklenebilirliği Aşırı Yürütülen CPU Kaynaklarıyla Sanal Oluşum Performansı
Hyper‐V, 1:8 mantıksal‐sanal işlemci eşleşmesine kadar aşırı yürütme olan CPU'yu destekler. Aşırı yürütme yapılan işlemciler fiziksel sunucuda bulunan CPU kaynaklarını maksimize etmek için birleştirmede kullanılabilir. Ancak bu teknik, beraberinde kayda değer bir CPU ek yükü de getirir. Bu bölümde açıklanan testler, SQL Server'ı sanallaştırılmış ortamlarda aşırı yürütme yapılan CPU kaynaklarıyla çalıştırmanın etkilerini keşfetti. Aşırı Yürütülen CPU Kaynaklarıyla Dört Eş Zamanlı Konuk Sanal Makine
Aşırı yürütülen işlemci senaryomuz için dört konuk sanal makine eş zamanlı çalışacak şekilde
yapılandırıldı. Her bir sanal makine dört mantıksal işlemci, 14 GB RAM ve SQL Server
tarafından kullanılan 12 GB ile ayarlandı. Dört sanal makinenin hepsinde öncelikli depolama
aynıydı.
Şekil 16, iş yükü arttıkça ölçeklenebilirlik sonuçlarını göstermektedir. İş yükü artarken ölçek
oldukça düzdür ve %90'a yaklaşıldığında azalmaktadır. Dört sanal işlemciyle dört sanal
makineyi çalıştırırken hepsi de aşırı CPU yürütmesiyle sonuçlandı: yalnızca 8 fiziksel CPU
çekirdeği bulunan 16 sanal işlemci CPU tarafından kaynak sıkıntısı çekti.
Hyper-V, sanal makine düzeyinde bu tür senaryolarda kullanılabilecek CPU kaynak yönetimi
seçenekleri sunar. Bu seçenekler daha sonraki bir incelemede tartışılacaktır.
Şekil 20: Aşırı yürütülen CPU ile dört eş zamanlı konuk sanal makinenin ölçeklenebilirliği Birleştirme Seçeneklerini Karşılaştırma
Sanallaştırma, birleştirme senaryoları için bir çok fayda getirdi. En iyi faydalarından birisi,
sanal makinelerin aynı ana bilgisayar üzerinde birden çok yalıtılmış ortam sağlayabilmesidir.
Performans açısından, geldiğiniz yer uygulamaya, iş yükü ve donanıma göre değişir.
Birleştirme projeniz için bir yerel örnek mi yoksa sanal örnek mi kullanacağınızın avantajları ve
dezavantajlarını iyice test edip değerlendirmek son derece önemlidir. Tablo 6'da yerel örnekler
ve sanal örnekler birleştirme açısından karşılaştırılmıştır.
Tablo 6: Birleştirme Seçenekleri Yalıtım
CPU kaynakları
Birden çok SQL Server
örneği
Paylaşılan Windows örneği
Windows örneğine görünen
CPU sayısı
Bellek
Sunucu sınırı
esnek (maksimum sunucu
belleği)
Depolama
Standart depolama
seçenekleriyle SQL Server
veri dosyaları
WSRM (işlem seviyesi)
50
Normal kurallar geçerlidir
Normal kurallar geçerlidir
Kaynak yönetimi
Örnek sayısı
Destek
Yüksek
kullanılabilirlik
Birden çok sanal makine
Adanmış Windows örneği
Maksimum
• Windows 2008 – en fazla 4 sanal CPU
• Windows 2003 – en fazla 2 sanal CPU
Statik olarak sanal makineye tahsis edilmiş
• Yalnızca çevrimdışı değişiklikler
• Aşırı yürütülen bellek kaynakları özelliği yok
Her sanal makine için 64 GB sınır
Her ana bilgisayar için 2 terabayt (TB) sınır
Sanal makinede görünen doğrudan geçiş veya sanal sabit
disk kullanan
SQL Server veri dosyaları
Hyper-V konuk sanal makine
Fiziksel kaynaklar tarafından belirlenen uygulanabilir sınır
SQL Server 2008 ve SQL Server 2005
Konuk kümeleme desteklenmez
Veritabanı Yansıtma, günlük gönderme (desteklenir)
Sonuç
Performans açısından bakarsak, Hyper-V, SQL Server birleştirme senaryoları için uygun bir
seçenektir. Sanallaştırılmış Hyper-V ortamında çalışan SQL Server'ın genel performansı eşit
yerel Windows Server 2008 ortamıyla karşılaştırıldığında makul seviyededir.
Uygun G/Ç kapasitesi ve yapılandırmasıyla, G/Ç ek yükü minimum düzeydedir. En iyi
performans için, CPU kaynaklarına aşırı yürütmeyi önlemek üzere sunucuda yapılandırılan
sanal işlemci sayısını destekleyecek kadar fiziksel işlemciye sahip olmanız gerekir. CPU
kaynaklarına aşırı yüklenildiği zaman CPU ek yükü büyük ölçüde artış gösterir. Üretimde,
Hyper-V ortamına dağıtmadan önce her uygulamayı iyice test etmek önemlidir.
Hyper-V ortamında SQL Server çalıştırırken dikkat etmeniz gereken bazı genel
değerlendirmelerimiz ve tavsiyelerimiz aşağıda verilmiştir.
Gözlemler
•
•
•
•
•
Hyper-V konuk sanal makineleri en fazla dört CPU çekirdeğiyle sınırlanmıştır;
bu nedenle SQL Server'ı Hyper-V konuk sanal makinesinde ancak dört CPU iş yükü
performansınızı karşılayabiliyorsa çalıştırın.
Kıyaslanabilir donanım kaynaklarına sahip yerel yapılandırmayla karşılaştırıldığında,
CPU kullanım maliyetinin biraz artmasıyla konuk sanal makinede aynı iş çıkışı elde
edilebilir. Tüm konuk sanal makinelerde yapılandırılan mantıksal CPU çekirdeği
sayısı sunucuda bulunan fiziksel CPU çekirdeklerinin gerçek sayısından daha fazla
olduğunda Hyper-V ile CPU kaynakları aşırı yürütülebilir. Bu tür durumlarda, SQL
Server iş yüklerini çalıştırdığımızda daha çok CPU ek yükü ve performans ek yükü
gözlemledik. Uygun donanım boyutlandırması, SQL Server performansı için çok
önemlidir. İş yükünüzü planlanan sanallaştırılmış ortamda test ederek bir sunucudaki
toplu fiziksel CPU çekirdeklerinin konuk sanal makinelerin ihtiyaçlarını karşılamaya
yeterli olduğundan emin olmanız gerekmektedir.
Ağ kullanımı yoğun olan iş yükleri daha fazla CPU ek yüküne neden olur ve
dolayısıyla performansı daha çok etkiler.
Şimdiye kadar edinilen bilgiler performansa özgü değerlendirmelerdi; dağıtımınız
için işlevsel değerlendirmeleri de (örn. desteklenen yapılandırma, yüksek
kullanılabilirliğe ulaşma seçenekleri vb.) göz önünde bulundurun. Genel Hyper-V
işlevselliğini ve SQL Server'ı Hyper-V yapılandırmasında çalıştırmaya ilişkin mevcut
destek ilkelerini kapsayan ek kısmında daha fazla bilgi bulunabilir.
SQL Server'ı bir konuk sanal makinede çalıştırırken minimum G/Ç performans ek
yükü olduğunu gördük. Doğrudan geçiş disk yapılandırması en iyi G/Ç performansını
verdi; ancak, sabit boyutlu VHD kullanarak çalıştırdığımızda minimum ek yükü
gözlemledik. Hangi depolama yapılandırmasının kullanılacağına her bir dağıtım için
•
hangisinin daha mantıklı olduğuna bakılarak karar verilmelidir; VHD kullanan sanal
makinelerin taşınması doğrudan geçiş diskleri kullananlardan daha kolaydır.
Birleştirme senaryoları için, kullanılabilir depolama kaynaklarının miktarı ve senaryo
kararınızı şekillendirir. Bizim testimizde, hem paylaşımlı hem de adanmış
yapılandırmada kabul edilebilir düzeyde performans sergilendiğini gördük. Her iki
durumda da, depolamanızı iş yükü ve tepki süresi gereksinimlerinizi akılda tutarak
boyutlandırmanız gerekir. Hyper-V ortamlarında öncelikli depolama konusunda da
herhangi bir SQL Server dağıtımında yapacağınız gibi her zaman en iyi uygulamaları
takip edin. Daha fazla bilgi için, bkz. SQL Server için En İyi Ön Dağıtım G/Ç
Yöntemleri.
Öneriler
•
•
•
•
Konuk sanal makine depolamanız için doğrudan geçiş diskleri veya sabit VHD
kullanın. Performans için bunlar en iyi seçeneklerdir ve SQL Server iş yükleri için en
iyi sonuçları verirler. Dinamik VHD'ler performans nedeniyle önerilmez.
Öykünmüş aygıt kullanmaktan kaçının ve bunun yerine Hyper-V için tümleştirme
bileşenlerinin kurulduğundan ve sentetik aygıtların G/Ç, ağ vb. için kullanıldığından
emin olun. Sentetik aygıtlar en düşük CPU ek yüküyle en yüksek performansı sağlar.
Bu tekniklerden bazılarını kullanabilmeniz donanım olanaklarına bağlıdır.
Ağ kaynaklarından yoğun olarak faydalanan iş yükleri için, özel yapılandırmanızda
ağı en iyi duruma getirmeye yönelik en iyi yöntemler için Windows Performans
Ayarlama rehberinin Sanallaştırma ve Ağ bölümlerine bakın. İş yükü özellikleri
büyük farklılıklar gösterebileceğinden performansı kendi iş yükünüzle test edin.
Daha Fazla Bilgi için
•
•
•
•
•
•
•
•
•
•
Windows Server Hyper-V
Hyper-V Dağıtım ve Planlama Rehberi
Hyper-V için Microsoft Değerlendirme ve Planlama Araç Seti 3.1
Adım Adım Hyper-V'ye Başlama Rehberi
Windows Server 2008 için Performans Ayarlama Rehberi (Sanallaştırma Bölümü)
Hyper-V Performansı SSS
Hyper-V İzleme (Windows Ekibi - Tüm Konular Performans BLOGU)
Hyper-V Ortamında SQL Server'ı Çalıştırmak için Destek İlkesi
SQL Server için En İyi G/Ç Yöntemleri
Microsoft Sistem Merkezi Sanal Makine Yöneticisi
Ek 1: Hyper-V Mimarisi
Hyper-V, Windows Server 2008 için hiper yönetici tabanlı bir sanallaştırma teknolojisidir. Hiper
yönetici, birden çok yalıtılmış işletim sisteminin tek bir donanım platformu paylaşmasına imkan
sağlayan, işlemciye özel sanallaştırma platformudur.
Hyper-V, bölüm açısından yalıtımı destekler. Bölüm, hiper yönetici tarafından desteklenen ve
işletim sistemlerinin yürütülmesini sağlayan mantıksal bir yalıtım birimidir. Microsoft hiper
yönetici, Windows Server 2008 64-bit Edition çalıştıran en az bir ana veya kök bölüme sahip
olmalıdır. Sanallaştırma yığını ana bölümde çalıştırılır ve donanım aygıtlarına doğrudan
erişebilir. Bu durumda kök bölüm, konuk işletim sistemlerine ev sahipliği yapan alt bölümler
oluşturur. Kök bölüm, hiper çağrı uygulama programlama arabirimini (API) kullanarak alt
bölümler oluşturur.
Bölümler, fiziksel işlemciye erişemezler veya işlemci kesintilerini taşıyamazlar. Bunun yerine,
işlemcinin sanal görüntüsüne sahiptirler ve her konuk bölüm için özel olan sanal bellek adres
bölgesinde çalışırlar. Hiper yönetici, işlemci kesintilerini tutar ve onları ilgili bölümlere
yönlendirir. Hyper-V ayrıca, CPU tarafından kullanılan bellek yönetimi donanımından bağımsız
çalışan bir Giriş Çıkış Bellek Yönetimi Birimi (IOMMU) kullanarak çeşitli konuk adres alanları
arasındaki adres dönüştürmeyi donanımla hızlandırabilir. IOMMU, fiziksel bellek adreslerini alt
bölümler tarafından kullanılan adreslere yeniden eşlemek için kullanılır.
Alt bölümler, diğer donanım kaynaklarına da doğrudan erişemezler ve sanal aygıtlar (VDev'ler)
olarak kaynakların sanal görünümünü sunarlar. Sanal aygıt istekleri VMBus veya hiper yönetici
vasıtasıyla istekleri tutan ana bölümdeki aygıtlara yönlendirilir. VMBus mantıksal bir bölümler
arası iletişim kanalıdır. Ana bölüm, alt bölümlerden aygıt erişimini tutan VMBus üzerinden
iletişim kuran Sanallaştırma Servis Sağlayıcılarına (VSP) ev sahipliği yapar. Alt bölümler, aygıt
isteklerini VMBus vasıtasıyla ana bölümlerdeki VSP'lere yönlendiren Sanallaştırma Servis
Kullanıcılarına (VSC) ev sahipliği yapar. Tüm bu işlemler, konuk işletim sistemi için şeffaftır.
Sanal Aygıtlar; depolama, ağ iletişimi, grafik ve giriş alt sistemleri için Geliştirilmiş GÇ adı
verilen bir Windows Server Sanallaştırma özelliğinden yararlanır. Geliştirilmiş GÇ, tüm aygıt
öykünme katmanlarını atlayıp VMBus'ı doğrudan kullanan yüksek düzeyli iletişim protokolleri
(SCSI gibi) için özel bir sanallaştırmaya duyarlı uygulamadır. Bu, iletişimi daha etkili kılar,
ancak hiper yönetici ve VMBus duyarlı bir geliştirilmiş konuk gerektirir. Hyper-V tümleştirme
servisleri vasıtasıyla Hyper-V geliştirilmiş G/Ç ve hiper yöneticiye duyarlı çekirdek sağlanır.
Diğer istemci işletim sistemleri için de sanal sunucu istemcisini (VSC) içinde bulunduran
tümleştirme bileşenleri mevcuttur. Hyper-V için Intel VT veya AMD Virtualization (AMD-V)
teknolojisi tarafından sağlananlar gibi bir donanım destekli sanallaştırma içeren bir işlemci
gereklidir.
Aşağıdaki diyagram, Windows Server 2008 üzerinde çalışan bir Hyper-V ortamının mimarisine
yüksek düzeyli bir genel bakış sunar.
Hyper-V mimarisine genel bakış
Yukarıdaki diyagramda kullanılan kısaltmalar ve terimler aşağıda açıklanmıştır:
APIC – Gelişmiş Programlanabilir Kesme Denetleyicisi – Kesme çıktılarına atanacak öncelik
düzeylerine izin veren aygıttır.
Alt Bölüm – Konuk işletim sistemine ev sahipliği yapan bölüm - Alt öğe tarafından fiziksel bellek ve
aygıtlara tüm erişim Sanal Makine Veri Yolu (VMBus) veya hiper yönetici vasıtasıyla sağlanır.
Hiper çağrı – hiper yönetici ile iletişim için arabirimdir - hiper çağrı arabirimi, hiper yönetici
tarafından sağlanan optimizasyon erişimini uygun hale getirir.
Hiper Yönetici – Donanım ile bir veya birden çok işletim sisteminin arasında yer alan bir yazılım
katmanıdır. Başlıca işi, bölüm olarak adlandırılan yalıtılmış yürütme ortamları sağlamaktır. Hiper
yönetici, temel donanıma erişimi denetler ve bu erişime aracılık yapar.
IC – Tümleştirme bileşeni – Alt bölümlerin diğer bölümler ve hiper yönetici ile iletişim kurmasını
sağlayan bileşendir.
G/Ç yığını – Giriş/çıkış yığını
MSR – Bellek Servis Yordamı
kök bölüm Bölümü – Aygıt sürücüleri, güç yönetimi ve aygıt ekleme/kaldırması gibi makine
düzeyindeki işlevleri yönetir. Kök (veya ana) bölüm, fiziksel bellek ve aygıtlara doğrudan erişimi
olan tek bölümdür.
VID – Sanallaştırma Altyapı Sürücüsü – Bölümler için bölüm yönetim servisleri, sanal işlemci
yönetimi servisleri ve bellek yönetim servisleri sağlar.
VMBus – Bölümler arası iletişim ve birden çok etkin sanallaştırılmış bölüm içeren sistemlerde aygıt
sayımı için kullanılan kanal tabanlı iletişim mekanizmasıdır. VMBus, Hyper-V Tümleştirme
Hizmetleriyle yüklenir.
VMMS – Sanal Makine Yönetim Servisi – Alt bölümlerdeki tüm sanal makinelerin durumunu
yönetmekten sorumludur.
VMWP – Sanal Makine Çalışan İşlemi –Sanallaştırma yığını için bir kullanıcı modu bileşenidir.
Çalışan işlemi, ana bölümdeki Windows Server 2008 örneğinden, alt bölümlerdeki konuk işletim
sistemleri için sanal makine yönetim servisi sağlar. Sanal Makine Yönetim Servisi, çalışan her sanal
makine için ayrı bir çalışan işlemi oluşturur.
VSC – Sanallaştırma Servis İstemcisi – Bir alt öğede bulunan sentetik aygıt örneğidir. VSC'ler, ana
bölümdeki Sanallaştırma Servis Sağlayıcıları (VSP) tarafından sağlanan donanım kaynaklarını
kullanır. Alt bölüm aygıtı G/Ç isteklerini karşılamak için ana bölümdeki VSP'ler ile VMBus
üzerinden iletişim kurar.
VSP – Sanallaştırma Servis Sağlayıcısı – Kök bölümlerde bulunur ve alt bölümlere, Sanal Makine
Veri Yolu (VMBus) üzerinden sentetik aygıt desteği sağlar.
WinHv – Windows Hiper Yönetici Arabirim Kitaplığı - WinHv, bölümlendirilmiş işletim sistemi
sürücüleri ve hiper yönetici arasında sürücülerin, standart Windows çağrı kurallarını kullanarak
doğrudan hiper yöneticiyi aramasını sağlayan bir köprüdür.
WMI – Sanal Makine Yönetim Servisi, sanal makinelerin yönetimi ve denetimi için bir dizi Windows
Yönetim Araçları (WMI) tabanlı API çıkarır.
Ek 2: Donanım Gereksinimleri
Hyper-V özel donanım gerektirir. Ek bir yeterlilik olarak Hyper-V için Windows Server
katalogundan x64 mimarisini ve Hyper-V'yi destekleyen sistemleri bulabilirsiniz (bkz.
http://go.microsoft.com/fwlink/?LinkId=111228).
Hyper-V rolünü yükleyip kullanmak için aşağıdakilere ihtiyacınız vardır:
x64-tabanlı bir işlemci. Hyper-V, Windows Server 2008 64-bit sürümlerinde, özellikle Windows
Server 2008 Standard, Windows Server 2008 Enterprise ve Windows Server 2008 Datacenter 64-bit
sürümlerinde mevcuttur. 32-bit (x86) sürümleri veya Itanium-Based Systems için Windows
Server 2008 için Hyper-V mevcut değildir. Ancak 32-bit sürümleri için Hyper-V yönetim araçları
mevcuttur.
Donanım destekli sanallaştırma. Bu, sanallaştırma seçeneği içeren işlemciler için, özellikle Intel
Virtualization Technology (Intel VT) veya AMD Virtualization (AMD-V) teknolojisini içeren
işlemciler için geçerlidir.
Donanım uygulamalı Veri Yürütme Engellemesi (DEP) kullanılabilir ve etkin olmalıdır.
Özellikle Intel XD bit (yürütmeyi devre dışı bırakma biti) veya AMD NX bit (yürütmeme biti) etkin
olmalıdır.
İpucu
Donanım destekli sanallaştırma ve donanım uygulamalı DEP ayarları BIOS'ta mevcuttur. Ancak
ayar adları, yukarıda belirlenen adlardan farklı olabilir. Hyper-V'yi destekleyen özel bir işlemci
modelinin olup olmadığı ile ilgili daha fazla bilgi için bilgisayarın üreticisine başvurun. Donanım
destekli sanallaştırma veya donanım uygulamalı DEP ayarlarını değiştirirseniz, bilgisayarı
kapatıp tekrar açmanız gerekebilir. Bilgisayar yeniden başlatıldığında değişiklikler ayarlara
uygulanmayabilir.
Bellek
Kullanılabilecek maksimum bellek miktarı, işletim sistemi tarafından aşağıdaki şekilde belirlenir:
Windows Server 2008 Enterprise ve Windows Server 2008 Datacenter için fiziksel bilgisayar, en
fazla 1 TB fiziksel bellek ile yapılandırılabilir. Bu sürümlerden biriyle çalışan sanal makineler de
sanal makine başına en fazla 64 GB bellek ile yapılandırılabilir.
Windows Server 2008 Standard için fiziksel bilgisayar, en fazla 32 GB fiziksel bellek ile
yapılandırılabilir. Bu sürümlerden biriyle çalışan sanal makineler de sanal makine başına en fazla 31
GB bellek ile yapılandırılabilir.
İşlemciler
Fiziksel bilgisayarlarda Hyper-V 16'ya kadar mantıksal işlemciyle desteklenir. Bir mantıksal
işlemci çekirdek işlemci veya hyper-threading teknolojisini kullanan bir işlemci olabilir. Bir
sanal makinede en çok 4 sanal işlemci yapılandırabilirsiniz. Ancak, bir konuk işletim sisteminin
desteklediği sanal işlemci sayısı daha düşük olabilir. Daha fazla bilgi için, bkz. Sanal Makineler
ve konuk Sanal Makine İşletim Sistemleri.
Aşağıda, desteklenen sistemlere bazı örnekler ve sundukları mantıksal işlemci sayısı verilmiştir:
Tek işlemcili/çift çekirdekli sistem 2 mantıksal işlemci sağlar.
Tek işlemcili/dört çekirdekli sistem 4 mantıksal işlemci sağlar.
Çift işlemcili/çift çekirdekli sistem 4 mantıksal işlemci sağlar.
Çift işlemcili/dört çekirdekli sistem 8 mantıksal işlemci sağlar.
Dört işlemcili/çift çekirdekli sistem 8 mantıksal işlemci sağlar.
Dört işlemcili/çift çekirdekli, hyper-threaded sistem 16 mantıksal işlemci sağlar.
Dört işlemcili/dört çekirdekli sistem 16 mantıksal işlemci sağlar.
Ağ İletişimi
Hyper-V aşağıdaki ağ iletişimi desteğini sağlar:
Tüm sanal makineler 12'ye kadar sanal ağ adaptörüyle yapılandırılabilir. Bunların 8'i “ağ adaptörü”
tipi ve 4'ü “eski ağ adaptörü” türünde olabilir. Ağ adaptörü türü daha iyi performans sunar ve
tümleştirme hizmeti paketinde sanal makine sürücüsü olması gerekir.
Her bir sanal ağ adaptörü bir statik veya dinamik MAC adresiyle yapılandırılabilir.
Her bir sanal ağ adaptörü tümleşik sanal yerel ağ (VLAN) desteği sunar ve tek bir VLAN kanalına
atanabilir.
Her sanal ağ için sınırsız sayıda sanal makineye sahip sınırsız sayıda sanal ağ kurabilirsiniz. Sanal
ağlar hakkında daha fazla bilgi için, bkz. Sanal Ağları Yapılandırma.
Not
Sanal bir ağı kablosuz ağ adaptörüne bağlayamazsınız. Sonuç olarak, sanal makinelere kablosuz
ağ özellikleri sağlayamazsınız.
Depolama
Hyper-V çeşitli depolama seçeneklerini destekler. Hyper-V çalıştıran bir sunucuyla aşağıdaki
fiziksel depolama türlerini kullanabilirsiniz:
Doğrudan bağlı depolama: Serial Advanced Technology Attachment (SATA), external Serial
Advanced Technology Attachment (eSATA), Parallel Advanced Technology Attachment (PATA),
Serial Attached SCSI (SAS), SCSI, USB ve Firewire kullanabilirsiniz.
Depolama alanı ağları (SAN'lar): Internet SCSI (iSCSI), Fiber Kanal ve SAS teknolojileri
kullanabilirsiniz.
Ağa bağlı depolama
Bir sanal makineyi aşağıdaki sanal depolama türlerini kullanmaya ayarlayabilirsiniz.
2040 GB'a kadar sanal sabit diskler. Sabit sanal sabit diskleri, dinamik olarak genişleyen sanal
sabit diskleri ve fark kayıt diskleri kullanabilirsiniz.
Sanal IDE aygıtları. Her sanal makine 4 adede kadar IDE aygıtı destekler. Başlangıç diskinin (bazen
önyükleme diski olarak da adlandırılır) IDE aygıtlarından birine bağlanması gerekir. Başlangıç diski
sanal bir sabit disk veya fiziksel bir disk olabilir.
Sanal SCSI aygıtları. Her bir sanal makine 4'e kadar sanal SCSI denetleyicisi destekler ve her
denetleyici 64 adede kadar disk destekler. Bu da her bir sanal makinenin 256 sanal SCSI diskiyle
yapılandırılabileceği anlamına gelir.
Fiziksel diskler. Doğrudan bir sanal makineye bağlanan fiziksel disklerde (bazen doğrudan geçiş
diski de denilen) konuk işletim sisteminin desteklediğinin dışında boyut sınırlaması yoktur.
Sanal makine depolama kapasitesi. Sanal sabit diskler kullanılarak her bir sanal makine 512 TB'a
kadar depolama alanı destekler. Fiziksel diskler kullanılarak bu sayı konuk işletim sisteminin
desteklemesine bağlı olarak daha da büyüyebilir.
Sanal makine anlık görüntüleri. Hyper-V her bir sanal makine için 50 adede kadar anlık görüntüyü
destekler.
Not
Sanal makinenin konuk işletim sistemini başlatmak için başlatma diski olarak sanal bir IDE aygıtı
kullanması gerekmesine rağmen, sanal IDE aygıtı için depolama alanı sağlayacak fiziksel aygıtı
seçerken birçok seçeneğiniz vardır. Örneğin, önceki listede belirlenen fiziksel depolama
türlerinden herhangi birini kullanabilirsiniz.
Ek 3: Donanım Yapılandırması
SQL Server Hyper-V Test Yapılandırması
İşlemci
Sunucu Dell R900 Depolama HDS AMS1000 Önbellek
4 yuvalı dört çekirdekli Intel 2.40GHz, 1066Mhz
veri yolu
6 MB L2 önbellek
Bellek
HBA
İşletim Sistemi
Ağ
64 GB fiziksel bellek
2x 4Gb/s çift bağlantı noktalı Emulex
Windows Server 2008 SP1
2 x Broadcom BCM5708C NetXtreme II GigE
Veriler
8 x 8 iğne (4+4) (RAID 1+0)
Günlük
4 x 4 iğne (2+2) (RAID 1+0)
Yedek
İşletim Sistemi
6 iğne (5+1) (RAID 5)
4 x disk (1+1) (RAID 1+0)

Benzer belgeler