Sanal makinede veritabanı çalıştırmanın sakıncaları nelerdir? Onları nasıl aşabilirim? [kapalı]

Sanal bir makinede herhangi bir şeyi çalıştırmak, belirli bir performans seviyesine ulaşır, ancak bu bir veritabanı sisteminin performansını gerçekten ne kadar etkiler?

Bu akademik referans belgesini bazı ilginç kriterler ile buldum , ancak yalnızca Xen ve PostgreSQL kullanan sınırlı bir testti. Sonuç olarak, bir VM kullanmanın "performans açısından yüksek bir maliyete ulaşmadığı" sonucuna varıldı (gerçek verilerin aksi söylendiğini düşünebilseniz de).

Sanal makinede veritabanı çalıştırmayla ilgili teknik, idari ve diğer dezavantajlar nelerdir?

Lütfen objektif gerçeklerle desteklenebilecek cevapları gönderin, spekülasyonlarla ya da diğer yarı dini tartışmalarla ilgilenmiyorum (inek tutkusu birçok yönden iyidir, ama bu bize yardımcı olmaz).

Söyleniyor ki,

• Sanal Makinede veritabanı çalıştırırken hangi sorunlar ortaya çıkıyor? (lütfen referans gönderiniz)
• Bu konular önemli mi?
  • Sadece belirli senaryolar altında mı anlamlılar?
• Geçici çözümler nelerdir?

Pek çok DB satıcısı bunu yapmak için çok yavaş olsa da, neredeyse hepsi artık resmi olarak sanallaştırılmış bir ortamda çalışan yazılımlarını destekliyor.

ESXi'nin üstüne Linux'ta birçok Oracle 11g örneği çalıştırıyoruz ve çok iyi performans elde etmek kesinlikle mümkün. Tüm donanım ölçeklendirmelerinde olduğu gibi, sanallaştırma sunucusunun çok fazla kaynağa (RAM, CPU) sahip olduğundan ve disk katmanınızın ihtiyaç duyduğunuz IO performansını sağlama görevine bağlı olduğundan emin olmanız yeterlidir .

ErikA'nın dediği gibi, bu gittikçe yaygınlaşıyor. SQL Server kampındayım ve kişisel olarak VM'lerde çalışan herhangi bir üretim sistemim yok, ancak tereddüt etmem (konuyla ilgili biraz daha çalışmanın ardından). Bu yolda ilerlemeden önce mutlaka göz önünde bulundurmanız gereken bazı şeyler vardır (en azından SQL Server için). Disk IO (diğerlerinin belirttiği gibi) ve bellek ayırma sadece 2 örnektir. Farklı hipervizörler arasında da her şey farklı olacak.

Brent Ozar, özellikle VMWare'de SQL Server'ı sanallaştırmakta tanınmış bir uzmandır. Materyali okumanı şiddetle tavsiye ederim.

http://www.brentozar.com/community/virtualization-best-practices/

Orada olabilir ve sonra gerekir . Bir corvette 150 mil gidebilir, ama halk otoyollarında mısın? Gereksiz yere kendinize zarar verebilirsiniz.

Veritabanları konuk işletim sistemleridir. Tasarım başladığında bir kaynağın bloklarını kaparlar ve performans nedenleriyle doğrudan yönetirler. Veri tabanı sunucusunun çekirdek işletim sistemini sanallaştırılmış bir barındırma ortamında misafir haline getirdiğiniz anda, hipervizör ile disk ve RAM'in ayrılmış blok elemanı ile veritabanı sunucusu arasında bir arabuluculuk katmanı yerleştiriyorsunuz. Yavaşlayacak. Sorgularınız ne kadar verimli olursa, o kadar yavaşlar. Bu verimsizlikler bugün adanmış donanıma göre maskelenebilir, ancak bağımlı kaynağınıza tahkim sağladığınız anda çok hızlı bir şekilde öğreneceksiniz.

Sanallaştırma talep eden birçok fasulye sayacının ne anlama geldiği, konuk işletim sistemleri olarak veritabanı sunucularının kendi konsolidasyon katmanlarını sunduklarıdır. Hizmetlerin bu doğal bir şekilde birleştirilmesine izin vermek için tek bir fiziksel sunucudaki birden fazla mantıksal veritabanı örneğini, hareketli IP adresleri, ek ana bilgisayar adları vb. Ve bu model ile sadece yönetimin daha az sayıda fiziksel ana bilgisayar için zorladığı maliyet tasarrufunu elde etmekle kalmaz, aynı zamanda keyfi hiper denetimcinin engellemeden fiziksel kaynaklara erişimini engellersiniz; diğerleri.

Aynı şey, Java gibi diğer konuk işletim sistemleri için de geçerlidir. Sanallaştırma çözümleri genellikle meşgul ortamlardır ve hipervizör, kaynak üzerinde "belirteç alan" konusunda çok fazla karar vermek zorundadır. İstediğin zaman bu katmanı ortadan kaldırabilirsin, daha iyi olacaksın.

Önce doğal konuk işletim sistemi katmanını kullanarak birden fazla örneği bir araya getirin. Olasılıklar platform konsolidasyonunuza ve performans hedeflerinize daha kolay ulaşabileceksiniz.

Burada gerçekleştirilmesi gereken iki şey var:

• Donanım birimi başına DB performans birimi sanallaştırılmış bir db için biraz daha düşüktür. Bu, aynı performans seviyesini elde etmek için biraz daha fazla donanım satın almanız gerektiği anlamına gelir.
• Bu aynı seviye anlamına gelmez veya istenen performans seviyesinin elde edilemez olduğu anlamına gelmez. Genellikle gelişmiş yönetim ve (daha kolay HA) gibi diğer faydalarından Alacağınız kazançlar yolu marjinal artış donanım maliyetlerini izale etti.

Sql Server kurulumumun çalıştığı yerde, yakın zamanda herhangi bir zamanda sanallaştırma niyetimde bulunmadığım sadece iki sunucudan biri (diğeri birincil DC).

SQL Server'ı çalıştırmak, VM'nizi uygulamanızı çalıştırmak için yeterli kaynak sağlayabilmeniz koşuluyla iyi olacaktır. Fiziksel dünyada 24 çekirdeğe ve 256 GIG RAM'e ihtiyacınız varsa, sanal dünyada 24 vCPU'ya ve 256 GIG RAM'e ihtiyacınız olacaktır.

Sadece geçen ay SQL Server dergisi VMware'in vSphere yazılımı altında SQL Server'ın çalıştırılmasıyla ilgili bir makale yazdım .

Bir PostgreSQL ve diğer MySQL olmak üzere iki veritabanını dom0'ların yüksek oranda bulunduğu sanal bir ortamda (Xen) çalıştırıyorum. domU dosya sistemlerinin tümü, LVM2 mantıksal birimleri ile oyulmuş bir iSCSI SAN LUN'da bulunur. MySQL veritabanı yalnızca Cacti'ye yöneliktir ve bu nedenle çok fazla kullanım görmez ve iSCSI LUN'da da bulunur.

PostgreSQL veritabanı, evreleme ortamımızın veri tabanıdır ve bu nedenle MySQL db'den daha yüksek yararlanmaktadır. Bu nedenle, veritabanı yerel bir RAID10 setinde bulunur ve DRBD ikinci küme düğümüne çoğaltılır. Ancak, gerçek yük açısından, bu evreleme veritabanı hiç çok yüksek bir yük görmüyor. Bu bence, sanallaştırmayı iyi / harika bir aday yapıyor.

Kuruluşumuzun yararlarından bazıları, düşük güç tüketimi, daha az raf alanı ve daha az donanım idari masrafı idi.

Ana üretim veritabanımız ise sanal olmayı hayal edemiyorum.

MSSQL ve MySQL sunucularında çok sayıda sunucu üzerinde çalışıyorum. Birkaç yıl önce, VM'lerde SQL sunucularını kurmakta tereddüt ettim çünkü bir VM'de bir SQL sunucusunu çalıştırmanın performans sorunlarını duymuştum. Bununla birlikte, ilk SQL serverlarımı kurduktan ve performansta bir değişiklik olmadığını gördükten sonra şaşırdım. Çalıştığım sunucuların çoğu ve daha fazlası VM'de ve çalıştığım büyük kurumsal istemcilerin neredeyse hepsinde SQL sunucularına neredeyse erişildi.

Evet, VM bir miktar ek maliyet ekler ve tek bir kutuda birden fazla VM barındırıyorsanız, güzel bir etli sunucuya ihtiyacınız olacaktır. Dikkat edilmesi gereken genel bir kaynak sorunu, ek VM'ler eklemek ve mevcut kaynakları incelemek. Bazı büyüme planlaması yaygın bir uygulamadır, ancak sunucunuzu 2 veya 3 VM'yi barındırmak için satın aldıysanız ve şimdi çalışan 10 VM'yi çalıştırıyorsanız, muhtemelen bir performans hitini göreceksiniz.

VM'de bir SQL sunucusunda çalışan performans sorunlarını hiç görmediğimi söylersem yalan söylemiş olurum. Ancak, düşük performans görüyorsanız, çevre ile ilgili muhtemelen bir sorun olduğunu öğrendim.