Sanal makine, temel fiziksel makineden daha mı yavaş?

Bu soru oldukça geneldir, ancak özellikle de Ubuntu Enterprise Cloud çalıştıran sanal makinenin herhangi bir sanallaştırma olmadan aynı fiziksel makineden daha yavaş olup olmayacağını bilmekle ilgileniyorum. Ne kadar (% 1,% 5,% 10)?

Web sunucusu veya db sunucusu (sanal VS fiziksel) performans farkını ölçen var mı?

Yapılandırmaya bağlıysa, 64 bit ubuntu kurumsal sunucuyu çalıştıran iki adet dört çekirdekli işlemci, 12 GB bellek ve bir demet SSD disk düşünelim. Bunun da ötesinde, yalnızca 1 sanal makinenin mevcut tüm kaynakları kullanmasına izin verildi.

Çıplak bir metal \ Tip 1 Hiper Yönetici'de genel amaçlı bir sunucu iş yükü için tipik deneyim, genel IO yüküne bağlı olarak değişen bazı ek yüklerle birlikte, CPU ek yükünün% 1-5'i ve% 5-10 Bellek yüküdür. Bu, temel donanımın uygun şekilde tasarlandığı VMware ESX \ ESXi, Microsoft Hyper-V ve Xen işletim sistemlerinde çalışan modern Misafir İşletim Sistemlerinde deneyimimde oldukça tutarlı. En güncel cpu donanım sanallaştırma uzantılarını destekleyen donanımda çalışan 64 bit Sunucu işletim sistemleri için, tüm Tip 1 hiper denetleyicilerin bu% 1 genel gider numarasına yönelmesini beklerdim. KVM'nin vadesi bu noktada Xen'e (ya da VMware'e) bağlı değil, ancak tanımladığınız örnek için onlardan belirgin şekilde daha kötü olacağını düşünmek için hiçbir neden görmüyorum.

Belirli kullanım durumları için sanal ortamın genel "toplam" performansı "tamamen metal \ ayrık sunucuları aşabilir. İşte bir VMware Kümelenmiş uygulamasının, çıplak bir metal Oracle RAC'den daha hızlı \ daha iyi \ daha ucuz olabileceği üzerine bir tartışma örneği . VMware'in bellek yönetimi teknikleri (özellikle saydam sayfa paylaşımı), yeteri kadar benzer VM'leriniz varsa, neredeyse tamamen ek yükü ortadan kaldırabilir. Tüm bu durumlarda önemli olan şey, sanallaştırmanın sağlayabileceği performans \ verimlilik avantajlarının yalnızca birden fazla VM'yi ana bilgisayarlar üzerinde birleştirmeniz durumunda gerçekleşmesidir; örneğin (ana bilgisayarda 1 VM), her zaman bir dereceye kadar metalden daha yavaş olacaktır .

Tüm bunlar faydalı olmakla birlikte, Sunucu sanallaştırma açısından asıl meseleler yönetim, yüksek kullanılabilirlik teknikleri ve ölçeklenebilirlik merkezli olma eğilimindedir. % 2-5 CPU performans marjı, 20, 40 veya her bir ana bilgisayarda ihtiyaç duyduğunuz VM sayısını verimli şekilde ölçekleyebilmek kadar önemli değildir. Temel performansınız olarak biraz daha hızlı bir CPU seçerek veya kümelerinize daha fazla düğüm ekleyerek, ancak ana bilgisayar çalıştığı VM sayısını ölçekleyemiyorsa veya ortamın yönetilmesi zorsa veya Güvenilmez sonra sunucu sanallaştırma perspektifinden değersizdir.

"Performans" ın birçok yönü vardır. N00b'ler bir işletim sisteminin önyükleme süresini ölçer ve örneğin Windows 2012'nin sooooooo harika olduğunu söyler çünkü gerçek HD'de 12 saniye, SSD'de 1 saniye önyükleme yapar.
Ancak bu tür ölçümler pek kullanışlı değil: performans işletim sistemi önyükleme süresine eşittir, ancak işletim sistemi ayda bir kez önyüklenir, bu nedenle optimizasyon çok anlamlı olmaz.

Çünkü bu benim günlük mesleğim, "performans" ı oluşturan aşağıdaki 4 bölüme dikkat çekebilirim.

1. CPU yükü
   Bu karşılaştırılabilir olmalıdır, yani çıplak metal üzerinde 1000 msn alan bir görev, aynı donanımdaki boş bir VM ortamında 1000 ms işlem süresi ve muhtemelen 1050 ms saat süresi gerçekleştirecektir. Google, işlem zamanı ve sorgulama performansı sayacı için MSDN’yi ve yu, VM’nizin CPU zamanını ne kadar yediğini gösterebilecek bir şey yapabilir.

2. SQL performansı
   SQL performansı, IO'ya, SQL verilerinin depolandığı veri deposuna güvenir. Buffalo home NAS'ta bulabileceğiniz 1'lerin gen ISCSI'sini, sonra DCE'li ISCSI'yi ve tüm seviyelerde gerçek bir eski okul FC ortamını bulan% 300 fark gördüm. FC bugünlerde hala kazanıyor, çünkü FC gecikmesi, TCP / IP veri merkezi geliştirmeleri için FC protokolünün bir "kopyasına" yol açan düşük seviyeli. Burada IOps ve gecikme hayati önem taşır ancak sunucu işleminden medyaya kadar IO bant genişliği de - uygulamanın No-SQL veya Datawarehousing eğiliminde olup olmadığına veya ERP sistemlerinde olduğu gibi bunun ortasında ... Sage KHK, küçük işletmeler için, SAP Büyükler için.

3. Dosya Sistemi Erişimi
   Video akışı gibi bazı uygulamalar garantili bir minimum bant genişliğine dayanır, diğerleri ise büyük dosyaları bir hex editöründe açmak, bir video projesini en sevdiğiniz film yapım programına yüklemek gibi maksimum IO verimine güvenir. Bir vm için tipik bir durum değil .... IOps da geliştiriciler için önemli olabilir. Geliştiriciler genellikle VM'leri kullanırlar; çünkü gelişen ortamlar çok hassastır ve bu yüzden bir VM'de bunu yapma eğilimi yüksektir. Büyük bir projeyi derlemek, çoğu zaman küçük dosyaların okunması, derleyici işlemlerinin yapılması ve bir EXE ve beraberindeki bileşenlerin oluşturulması anlamına gelir.

4. İstemciye ağda gecikme
   Burada WYSIWIG'in kullanılabilirliği 2010, Openoffice Writer, LaTEX, GSView ve diğerleri gibi kelimelere benziyor - fare eyleminin istemciden sunucuya ne kadar hızlı geçtiğini görmek. Özellikle CAD uygulamalarında bu önemlidir .... fakat aynı zamanda bir LAN sorunu değildir, WAN üzerinden uzaktan erişim önemlidir.

Ancak - ve yıllar süren danışmanlık perspektifinden konuşuyorum - yönetici şifresine sahip kullanıcılar (ve genellikle BÜYÜK bir bütçeye ve BÜYÜK bir cep defterine sahip BÜYÜK bir şirketin çalışanlarıdır), bundan ve bunlardan şikayetçi olmalılar. Hangi performans bileşeni onlar için önemlidir ve hangileri kullandıkları uygulama açısından önemlidir.
Büyük olasılıkla not defteri değil, ancak bunu yapmak için oldukça karmaşık bir uygulama olan ve aynı zamanda çok pahalı olan ve VMware, HyperV veya Xenapp'a taşınması gereken ve beklendiği gibi performans göstermeyen bir uygulama.

Ancak, saf CPU performansı için yaratılmayan blade'lerde 1,5 GHz Xeons ile çalışabileceğini akıllarında tutmadıklarını, ortalama olarak üretildiklerini, "CPU döngüsü başına $ için optimize edilmiş" veya "Watt başına CPU döngüleri" diyelim. .

Ve takaslar ve ekonomizasyonlar hakkında konuştuğumuzda - bu çoğunlukla aşırı taahhütlere neden oluyor. Aşırı taahhütler CPU'nun oldukça iyi kullanılabileceği sorunların bulunmamasına neden olmakla birlikte, bellek eksikliği çağrılamaya neden olur, çekirdek yönlendiricilerdeki IO eksikliği her şeyde yanıt sürelerinin artmasına neden olur ve her türlü depolamada işlemsel aşırı yüklenme her kullanışlı uygulamayı durdurabilir çok hızlı yanıt vermekten. Burada izleme gereklidir, ancak birçok yazılım satıcısı bu tür bilgileri sağlayamaz. Öte yandan, 3 fiziksel sunucu kaynağına sahip bir ana bilgisayar, büyük olasılıkla aynı düzende 8 sanal makineyi idare edebilir ...

Boşta sistemlerdeki CPU değişimleri genellikle fiziksel sistemlere göre% 50 daha yavaş çalışan sistemlere yol açar, diğer yandan müşterinin BT adamlarının VM'ye taşımak istediği "gerçek dünya" os'ı ve "gerçek dünya" uygulamasını kuramaz Kutu. Ayrıca, VM teknolojisinin saf CPU hızı ticareti yaparak esneklik sunabileceğini açıkça belirtmek günler (belki haftalar ancak kesin 42 toplantılar) sürer. Bu, günümüzde daha büyük VM ortamlarına ev sahipliği yapan bu blade sistemlerdeki CPU'lara dahil edilmiştir. Ayrıca hafıza karşılaştırılamayacak, bazı takaslar geçerli olacaktır. DDR3 1600 CL10, DDR2 800 ECC LLR'den daha yüksek bellek bant genişliğine sahip olacak ve herkes Intel CPU'larının AMD cpus'tan farklı bir şekilde kar ettiğini biliyor. Ancak üretken ortamlarda nadiren kullanılırlar, daha fazla beyaz kutuda veya 3. dünya ülkesinde barındırılan veri merkezlerinde, kendi ülkenizdeki bir veri merkezinin fiyatının% 10'una veri merkezi hizmeti sunan veri merkezi hizmetini sunabilir. Citrx sayesinde, son kullanıcı ile veri merkezi arasındaki 150 ms'den daha az gecikme süresi varsa, bir veri merkezi her yerde olabilir.

Ve ev kullanıcıları perspektif ....

Son fakat en az değil, bazı insanlar Win7 veya XP'yi atmak ve bir Linux için takas etmek istiyorlar ve ardından oyun sorusu ortaya çıkıyor çünkü aslında Linux ve Windows için sadece birkaç oyun mevcut. Oyun, yüksek hızda 3D ivmesine dayanıyor. VMWare 6.5 Workstation ve bağlı olan ücretsiz oyuncu DirectX 9 ile çalışabilir, yani bir VM'deki bir Doom3 ana bilgisayar grafik kartında tam ekranda çalışabilir. Oyunlar çoğunlukla 32 bit uygulamalardır, bu nedenle 3 GB'den fazla ve çoğunlukla 3 CPU'dan fazla yemeyeceklerdir (Crysis'te görülür). Daha yeni VM oyuncuları ve WS, daha yüksek DirectX sürümlerini ve muhtemelen OpenGL'yi de idare edebilirler ... VMware 6.5'te UT ve UT2004'ü oynadım, sunucunun bir ATI Radeon 2600 cep telefonu ve bir T5440 işlemcisi vardı. 1280x800'de kararlıydı ve ağ oyunlarında bile oynanabiliyordu ....

Evet. Ancak sorun bu değil. Fark normalde ihmal edilebilirdir (% 1 ila% 5).

Sanallaştırmanın bazı durumlarda fiziksel performansı aşabileceğini belirtmek isterim. Ağ katmanı gigabit hızı ile sınırlı olmadığı için (donanım emülasyonu belirli bir lan kartında olsa bile), aynı sunucudaki VM'ler, ortalama ağ ekipmanı ile birden fazla phyiscal sunucunun ötesindeki hızlarda birbirleriyle iletişim kurabilir.

Aynı testi çalıştıran aynı yazılımın bazı test karşılaştırmalarını yapıyorum (yüksek hacimli web trafiği ve önemli SQL Server erişimi olan .NET tabanlı web uygulaması). İşte gördüğüm şey:

• Fiziksel makine örnekleme sınıflarında daha iyidir (sistem düzeyinde bellek tahsis etmek anlamına gelir) - bu bana mantıklı geliyor çünkü fiziksel makineler bunu bellek yönetimi donanımıyla ve VM'ler bunu yazılımla (kısmi donanım yardımı ile) yapıyor (VM'de) , uygulama, yapıcılarında (belleğin ayrıldığı (ve başka hiçbir şeyin yapılmadığı) fiziksel makinede, inşaatçılar ilk 1000'e bile dahil edilmemiş) önemli bir süre harcadı
• Bir yöntemin ortasındayken, ikisi yaklaşık olarak eşittir - bu muhtemelen, her ikisinin de “aynı olduğunu” gösteren kıyaslama ölçütlerinin çoğunun nasıl yapıldığıdır.
• Bir ağ denetleyicisine eriştiğinizde, fiziksel VM'yi biraz dışarı atar - yine, fiziksel işlem .NET ile donanım arasında çok fazla oturmaz. VM, her işlemin geçmesi gereken diğer "öğeleri" de ekler.
• Gerçekten, aynı şey disk erişimine de uygulandı (SQL Server başka bir makinedeydi) - fark çok küçük, ama hepsini topladığınızda farkediliyor. Bu, daha yavaş ağ erişiminden veya daha yavaş bir disk erişiminden kaynaklanmış olabilir.

Birisinin% 1 farklı veya aynı olduklarını veya VM'lerin daha hızlı olduğu noktaları nasıl gösterdiğini ölçütler oluşturabildiğini kolayca görebiliyorum. İşleminizin, VM'de yazılımı simüle etmek için ihtiyaç duyduğu yerel donanım desteğinin avantajlarından yararlandığı hiçbir şeyi dahil etmeyin.

Bir işletim sistemini, yazılımı ve belirli bir fiziksel donanıma yüklenen verileri aynı işletim sistemine, yazılıma ve kendi başına aynı orijinal donanıma bağlı bir hipervizöre yüklenen veri ile karşılaştırmaya çalışıyorsunuz. Bu karşılaştırma geçerli değil, çünkü neredeyse hiç kimse bunu yapmıyor (en azından ilk başta). Elbette bu daha yavaş olacaktır. Neyse ki, sunucuları neden sanallaştırdığınızın en yaygın noktasını tamamen kaçırıyor.

Burada daha iyi bir örnek, veri merkezinizdeki iki (veya daha fazla!) Eski sunucuya bakmaktır. Oldukça iyi performans gösteren sunucuları arayın, ancak şimdi eski ve yenileme döngülerinde ortaya çıkıyor. Bu sunucular zaten eski donanımlarda iyi bir performans sergiliyorlar ve Moore'un yasası sayesinde elde ettiğiniz her şey çok net bir şekilde anlaşılacak.

Ee ne yapıyorsun? Basit. İki yeni sunucu satın almak yerine, yalnızca bir tane satın alırsınız ve sonra eski sunucularınızı aynı fiziksel yeni aygıta geçirirsiniz. Yeni sunucunuzu satın almaya hazırlanırken, sadece hem eski sunuculardaki yükü hem de hiper denetleyiciden (ve belki de biraz daha fazla olan herhangi bir yükü) kaldırabilecek kapasiteye sahip olmayı, yine de performans artışı sağlayabilmenizi ve büyüme için izin verebilir).

Özetle: sanal makineler çoğu durumda "yeterince iyi" performans sağlar ve "boşa" işlem gücünden kaçınmak için sunucularınızı daha iyi kullanmanıza yardımcı olur.

Şimdi bunu biraz daha uzatalım. Bunlar eski sunucular olduğundan, belki de değiştirmeleri için 1500 dolarlık küçük bir pizza kutusu sunucusuna bakıyordunuz. Muhtemelen, bu pizza kutularından biri bile her iki varsayımsal eski makinenin yükünü kolaylıkla kaldırabiliyor ... ama bunun yerine bazı donanımlara 7500 $ veya daha fazla harcama yapmaya karar verdiğinizi varsayalım. Artık mevcut sunucularınızdan bir düzine kadar (bir depolama ve ağ bağlantısına nasıl bağlı olduğunuza bağlı olarak) sadece 5 başlangıç ​​maliyetiyle kolayca başa çıkabilen bir cihaza sahipsiniz. Ayrıca, yalnızca bir fiziksel sunucuyu yönetme, ayrıştırma avantajlarına sahipsiniz Donanımınızdaki yazılımınız (yani: donanım yenileme işleminin artık yeni bir windows lisansına ihtiyaç duyması veya aksama süresine neden olma olasılığı düşüktür), güçten tasarruf etmenizi sağlar ve hipervizörünüz size performanstan daha iyi bilgi verebilir. Geçmişte yaşadım. Bunlardan iki tane alın ve ne kadar büyük olduğunuza bağlı olarak tüm veri merkeziniz sadece iki makineye bağlı, ya da belki de daha iyi bir kullanılabilirlik hikayesi anlatmak için ikinci sunucuyu sıcak bir bekleme olarak kullanmak istiyorsunuz.

Buradaki noktam bunun sadece performansla ilgili olmadığı. Mükemmel bir üretim sunucusunu asla alıp tek başıma eşdeğer donanıma göre sanallaştırmam. Maliyet tasarrufu ve yüksek kullanılabilirlik gibi konsolidasyondan elde edebileceğiniz diğer avantajlar hakkında daha fazla bilgi. Bu avantajların farkına varmak, sunucuları farklı bir donanıma taşıdığınız anlamına gelir ve bu da, hipervizör cezasının muhasebesi de dahil olmak üzere, bu donanımı uygun şekilde boyutlandırmak için zaman ayırmanız gerektiği anlamına gelir. Evet, bu makinelerin her birinin kendi fiziksel cihazında olmasından daha az miktarda toplam bilgi işlem gücüne ihtiyacınız olabilir (ipucu: muhtemelen daha az toplam bilgi işlem gücüne ihtiyacınız vardır ), ancak çok daha ucuz ve daha verimli olacak ve bakımı daha kolay bir fiziksel sunucuyu çalıştırmaktan çok çalıştırmak.

Daha yeni bir SSD'ye (OCZ Vertex 2) yükselttim ve üzerinde XP VM geliştirme ortamını çalıştırıyorum, bir yazılım geliştiricisiyim. Fark ettiğim bir şey, bir programı başlattığımda (yüklenmesi zaman alacak kadar büyük) sanal işlemcinin bir çekirdeğinin ortaya çıkması. Bu IE yüklerken de olur. CPU açıldığından beri, tıkanıklığın SSD değil CPU olduğunu düşünüyorum. Ancak garip görünüyor, fiziksel bir makinede aynı şeyin daha hızlı yükleneceği ve daha hızlı yükleneceği hissine kapıldım, VMWare'in disk erişiminde CPU harcayan fazladan bir işlem yükü olduğu yönünde bir his var.

Bir örnek olarak, Delphi kullanıyorum ve normal bir HDD içeren fiziksel bir makinede soğuk bir önyüklemeden başlamak 20 saniye sürebiliyor. Bir SSD'den çalışan VM'de, soğuk bir başlangıçtan itibaren 19 saniye içinde yüklenir. Çok fazla fark yok, SSD fiziksel makinedeyse daha hızlı yükleyeceğini iddia ediyorum. Bununla birlikte, fiziksel makinedeki CPU kullanımını kontrol etmedim, buradaki CPU'nun da darboğaz olması muhtemeldi.

Ancak VM'nin hissi, disk erişiminin VM'ye vergi vermesidir.

Açıkçası, sanal bir makine fiziksel makineden daha yavaştır. Ancak bu senaryoda iken, ihtiyaçlarınızı karşılamak için neyin en uygun olduğunu değerlendirmek zorundasınız. Yalnızca bir sisteme ihtiyacınız varsa ve hızlı olmanız gerekiyorsa, doğrudan cihaza yükleyin. Diğer tarafta, esnekliğe ihtiyacınız varsa, ölçeklenebilirlik (ve diğer tüm sanallaştırma avantajları: P) bir VM dağıtır. Daha yavaş olacak, ancak bazı durumlarda IMHO haklı ve performans önemli ölçüde yavaş değil.

Microsoft bu konuda farklı yapılandırmalarda BizTalk sunucusu ve SQL Server kullanarak bazı testler yapmış görünüyor. Aşağıdaki linke bakınız:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

İdeal olarak Sanal PC performansı:

CPU: sunucunun% 96-97'si

Ağ: ev sahibinin% 70-90'ı

Disk: sunucunun% 40-70'i

TomTom ile aynı fikirde olduğum için üzgünüm.

VMware Workstation'ı bir süredir çoğunlukla Windows XP, Windows Vista ve şimdi Windows Seven yerel sistemlerinde, Ubuntu'nun yanı sıra farklı Windows lezzetleri çalıştırmak için kullanıyorum.

Evet, sanallaştırılmış bir ortam yerel bir sistemden daha yavaştır ve% 5 ile% 100 arasında olabilir.

Asıl sorun CPU yükü kadar değil ama fiziksel hafızanın olmaması.

Diyelim ki boşta çalışırken yaklaşık 1,5 Gb'ye ihtiyaç duyan ve CPU'nun ~% 10'unu kullanan bir 4 Gb sistemde çalışan Windows Seven 64 Ultimate. Ekstra VMware katmanını başlatmak size ~ 300 Kb mal olacak ve CPU yükleri ~% 20'ye kadar çıkacaktır. Daha sonra VMware'de sanal bir sistem başlatmak, o sanal makine için tanımladığınız ve herhangi bir makul sistem için minimum 1 Gb olan minimum bellek miktarını isteyecektir. Ardından, sanal makine Ubuntu ise CPU yükünü ~% 60 ve son Windows işletim sistemindeki herhangi bir lezzet için ~% 80'i görürsünüz.

Şimdi, bu sanal makinedeki farklı uygulamaları başlatacaksınız.

Bu sanal makine için belirlediğiniz bellek miktarı yeterli değilse, sanallaştırılmış sistem değişmeye başlar ve ardından genel performansını ve yanıt vermesini önemli ölçüde yavaşlatır.

Bu sanal makine için belirlediğiniz bellek miktarının ve yerel sisteminiz için gereken bellek miktarının, yerel sisteminizin bellek miktarının üzerindeyse, o zaman değiştiren ve yavaşlatan yerel sisteminizdir. hem yerel hem de sanallaştırılmış sistem.

Bu nedenle, ilk önce hem yerli hem de sanallaştırılmış makineler için gereken belleğin dengesine bağlıdır.

Şimdi neredeyse CPU yükü ile aynı. Sanallaştırılmış bir uygulamanın büyük bir CPU yüküne ihtiyacı varsa ve yerel bir uygulamanın da büyük bir CPU yüküne ihtiyacı varsa, yerel sisteminizin önceliği yönetmesi ve CPU yükünü farklı uygulamaları arasında dengelemesi gerekir; sanallaştırılmış sistem bir uygulamadan başka bir şey değildir. fenomen, uygulama öncelikleriyle kandırabileceğiniz klasik bir CPU yükleme problemidir.

Bu nedenle, sanallaştırmayı kullanmanız gerekirse ilk tavsiyem, yerel olarak veya sanal bir makine içinde kullandığınız işletim sistemi ne olursa olsun, makinenize bir miktar bellek koymaktır.

Sadece 2 sentim.

Saygılarımla.

Tecrübelerime göre sanal makineler her zaman fiziksel olanlardan daha yavaştır.

Yalnızca diske çarpan uygulamaları çalıştırırken ve CPU’ya çok vergi uygularsınız. Sanal makinelerde ve son kullanıcı olarak birçok veritabanını ve web sunucusunu çalıştırdım ve diğer son kullanıcılardan gelen geri bildirimleri (yani: uygulamaya uzak bir web tarayıcısından erişmek) sanal makineleri kullanırken oldukça büyük bir gecikme var.

Elbette, uygun şekilde yapılandırılmış bir sanal makine% 80 (gerçek sayıyı bilmiyorum) veya fiziksel makinenin hızından bağımsız olarak gelebilir, ancak uygulamanın ne yaptığını ve sanal makinenin ne kadar derinlemesine kazmak zorunda kalmanız gerekir. Eserleri. Bu yüzden VM'leri yeni bir sunucu satın alıp barındıran ayetleri yapılandırma zamanınızın ne kadar değerli olduğunu tahmin ediyorum.

Benim için sanal makineler PERFORMANS HAKKINDA DEĞİLDİR, fakat elbette düşük performanslı VM'lerin yönetilmesi ve barındırılması konusunda daha kolay olma konusunda.