Apa kelemahan menjalankan database di dalam mesin virtual? Bagaimana cara mengatasinya? [Tutup]


65

Menjalankan apa-apa di dalam mesin virtual akan memiliki beberapa tingkat kinerja hit, tapi berapa banyak apakah itu benar-benar berdampak pada kinerja sistem database?

Saya menemukan makalah referensi akademis ini dengan beberapa tolok ukur yang menarik, tetapi itu adalah tes terbatas menggunakan Xen dan PostgreSQL saja. Kesimpulannya adalah bahwa menggunakan VM tidak "datang dengan biaya tinggi dalam kinerja" (meskipun Anda mungkin berpikir data aktual mengatakan sebaliknya).

Apa kelemahan teknis, administratif, dan lainnya yang terkait dengan menjalankan database dalam mesin virtual?

Tolong posting jawaban yang dapat didukung oleh fakta-fakta obyektif, saya tidak tertarik pada spekulasi atau argumen semi-agama lainnya (gairah geek baik dalam banyak hal, tetapi itu tidak akan membantu kami di sini).

Yang telah dibilang,

  • Masalah apa yang muncul saat menjalankan database di Mesin Virtual? (silakan kirim referensi)
  • Apakah masalah itu penting?
    • Apakah itu hanya signifikan dalam skenario tertentu?
  • Apa solusinya?

+1 Saya terutama tertarik mendengar umpan balik tentang skenario SQL Server dan Windows 2008 R2
goodguys_activate

4
@Shane Madden - Bisakah Anda jelaskan sedikit tentang penutupannya? Saya berharap bahwa motivasi didorong oleh satu jawaban yang tidak spesifik (yang kemudian terombang-ambing dalam komentar), bukan pertanyaan itu sendiri. Mengenai pertanyaan, 44 suara dan 12 favorit dalam waktu sekitar satu hari sebelum keberadaan pra-penutupan menyiratkan kepada saya bahwa itu adalah pertanyaan yang bagus dengan jawaban / informasi yang berguna (terutama dibandingkan dengan apa yang tampaknya khas untuk lalu lintas pertanyaan ServerFault). Inilah yang menjadi tujuan berbagai situs SE. Apakah Anda lebih suka ungkapan pertanyaan yang lebih spesifik, vs longgar "seberapa buruk itu?".
Russ

1
@ErikA, Shane, Womble, mikeyb, Ben - Saya membuat edit komunitas yang dapat membuat pertanyaan ini lebih konstruktif. Pertimbangkan untuk membuka kembali ini, atau memposting pertanyaan serupa pada pertanyaan baru / bersih.
goodguys_activate

Jawaban:


40

Meskipun banyak vendor DB sangat lambat melakukan hal ini, hampir semua dari mereka sekarang secara resmi mendukung perangkat lunak mereka yang berjalan dalam lingkungan yang tervirtualisasi.

Kami menjalankan banyak instance Oracle 11g di linux di atas ESXi, dan tentu saja mungkin untuk mendapatkan kinerja yang sangat baik. Seperti semua penskalaan perangkat keras, Anda hanya perlu memastikan bahwa host virtualisasi memiliki banyak sumber daya (RAM, CPU), dan bahwa lapisan disk Anda siap untuk memberikan kinerja IO apa pun yang Anda butuhkan.


7
+1 Seperti dicatat, Kritis bahwa sumber daya sesuai dengan tugas. Disk telah menjadi hambatan besar bagi kami dan perencanaan yang cermat diperlukan.
Dave M

2
+1 Anda harus melakukan pekerjaan rumah Anda tentang penggunaan basis data sebelumnya. Jika kotak fisik Anda dipalu di atas pemanfaatan 40%, maka keuntungan Anda untuk mulai mulai larut. Yang sedang berkata kita memiliki banyak sql terisolasi aplikasi kecil spesifik yang berjalan pada vm tanpa masalah. Tetapi mesin besar kami yang berat menggunakan perangkat keras khusus karena kurangnya keuntungan.
Nate

5
Sudah pasti Disk IO adalah biang keroknya, dan lingkungan yang tervirtualisasi cenderung rapuh.
lynxman

1
@lynxman - Setuju. Kami menjalankan semua instance Oracle kami pada disk SAN Tier 1 kami, yang merupakan 15k SAS. Dari apa yang bisa saya katakan, kami sangat dekat dengan kinerja pribumi yang dekat.
EEAA

10
"Satu ons tes layak satu pon tebakan."
Chris B. Behrens

21

Seperti yang dikatakan ErikA, ini menjadi semakin umum. Saya di kamp SQL Server dan secara pribadi tidak memiliki sistem produksi yang berjalan di VM, tapi saya tidak akan ragu untuk (setelah sedikit lebih banyak belajar tentang topik). Pasti ada beberapa hal yang perlu dipertimbangkan sebelum Anda pergi jalan itu, meskipun (setidaknya untuk SQL Server). Disk IO (seperti yang disebutkan orang lain) dan alokasi memori hanyalah 2 contoh. Hal-hal akan berbeda antara hypervisor yang berbeda juga.

Brent Ozar adalah pakar yang diakui dalam virtualisasi SQL Server, khususnya di VMWare. Saya akan sangat merekomendasikan membaca bahan-bahannya.

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


11

Ada yang bisa dan kemudian harus ada . Sebuah korvet dapat mencapai 150 mph, tetapi apakah Anda harus berada di jalan raya umum? Anda bisa melukai diri sendiri secara tidak perlu.

Database adalah sistem operasi tamu. Dengan desain ketika mereka mulai, mereka mengambil blok sumber daya dan mengelolanya secara langsung untuk alasan kinerja. Segera setelah Anda membuat sistem operasi inti dari server basis data menjadi tamu di lingkungan hosting tervirtualisasi, maka Anda menempatkan lapisan arbitrase dengan hypervisor antara blok elemen yang dialokasikan dari disk dan RAM dan server basis data. Ini akan melambat. Semakin tidak efisien kueri Anda, semakin lambat. Inefisiensi ini dapat ditutup hari ini pada perangkat keras khusus, tetapi segera setelah Anda memperkenalkan arbitrase ke sumber daya dependen Anda, Anda akan mengetahuinya dengan sangat cepat.

Apa yang tidak diketahui oleh banyak penghitung kacang yang menuntut virtualisasi adalah bahwa server basis data, sebagai sistem operasi tamu, menawarkan lapisan konsolidasi mereka sendiri. Tidak ada alasan mengapa Anda tidak dapat memindahkan menggabungkan beberapa contoh basis data logis pada satu server fisik, bahkan sampai memindahkan alamat IP, mengatur nama host tambahan, dll ..., untuk memungkinkan penggabungan alami layanan ini terjadi. Dan, dengan model ini Anda tidak hanya mempertahankan penghematan biaya yang didorong oleh manajemen untuk mengurangi jumlah host fisik, tetapi Anda mempertahankan blok akses ke sumber daya fisik tanpa melanggar hypervisor sewenang-wenang, yang kadang-kadang dapat membuat keputusan yang menguntungkan dan tidak lainnya.

Hal yang sama berlaku untuk sistem operasi tamu lainnya, seperti Java. Solusi virtualisasi biasanya merupakan lingkungan yang sibuk dan hypervisor harus membuat banyak keputusan tentang siapa yang "mendapatkan token" pada sumber daya. Kapan saja Anda bisa menghilangkan lapisan itu, Anda akan menjadi lebih baik.

Menggabungkan beberapa instance menggunakan layer sistem operasi guest natural terlebih dahulu. Kemungkinan Anda akan dapat mencapai target konsolidasi dan target kinerja Anda dengan lebih mudah.


4
Definisi menarik tentang "sistem operasi tamu." Sementara poin Anda diambil sehubungan dengan murni, kinerja murni, seberapa sering database Anda benar-benar macet di CPU? I / O jauh lebih mungkin, dan untuk aplikasi berkinerja lebih tinggi Anda sudah berbagi waktu I / O di SAN. Saya berharap bahwa Anda akan mempertimbangkan kembali filosofi virtualisasi Anda ketika masalah keamanan dengan satu aplikasi kompromi semua hash kata sandi database konsolidasi Anda, atau ketika satu proses yang berjalan dalam JVM Anda mengkonsumsi setiap byte dari ruang tumpukan yang tersedia.
Shane Madden

5
Untuk lebih jelasnya, saya setuju sepenuhnya bahwa server basis data berperforma tinggi, sibuk besar, dan padat harus memiliki perangkat keras fisiknya sendiri. Tapi itu bukan norma, dan manfaat lain dari virtualisasi cenderung lebih besar daripada hit kinerja, yang tidak dapat dibedakan dengan sebagian besar beban kerja.
Shane Madden

3
Saya tidak setuju dengan poin Anda tentang selalu pergi ke lapisan konsolidasi yang ada terlebih dahulu. Terkadang itu masuk akal. Tapi lihat, misalnya, pada tradeoff biaya dalam menyeimbangkan sumber daya antara menggabungkan beberapa basis data pada satu OS dan menggabungkan beberapa basis data / kombinasi OS di atas hypervisor. Yang pertama lebih efisien. Yang kedua jauh lebih mudah untuk menyeimbangkan kembali. Migrasi dan OS / database ke host baru jauh lebih tidak mengganggu daripada bermigrasi database ke OS baru.
Jake Oshins

Komentar saya datang dari pengamatan langsung di lapangan tentang migrasi yang berhasil dan gagal ke solusi virtualisasi selama dekade terakhir sebagai insinyur kinerja. Ada banyak aplikasi database yang buruk di luar sana yang penggunaan masalah perangkat keras topeng kinerja promiscuous. Tambahkan virtualisasi dan masalah-masalah itu terungkap. Jika Anda memiliki aplikasi yang menuntut jam yang tepat untuk menentukan waktu atau keperluan audit, maka dengan jam yang terapung dalam virtualisasi perangkat lunak Anda berada di luar perburuan.
James Pulley

1
Wow, wow James. Saya tidak punya waktu atau kesabaran untuk membuang semua poin yang Anda buat dalam jawaban Anda dan komentar berikutnya, tetapi saya hanya merasa saya perlu memberikan komentar di sini untuk siapa pun yang mungkin terjadi pada jawaban ini. Pandangan James adalah, baik, miliknya sendiri, dan tidak mencerminkan apa yang benar-benar mungkin. Jika Anda kelebihan langganan maka tentu saja Anda akan memiliki kinerja yang buruk. Jadi jangan terlalu banyak berlangganan. Sangat mungkin untuk memiliki lingkungan virtualisasi berperforma sangat tinggi. Adalah kebodohan untuk membuat rekomendasi selimut terhadapnya karena "berkinerja buruk".
EEAA

6

Ada dua hal yang perlu disadari di sini:

  • Unit kinerja DB per unit Hardware sedikit lebih rendah untuk db tervirtualisasi. Ini berarti Anda perlu membeli sedikit lebih banyak perangkat keras untuk mendapatkan tingkat kinerja yang sama.
  • Itu tidak berarti tingkat yang sama atau tingkat kinerja yang diinginkan tidak dapat diperoleh. Keuntungan yang Anda peroleh dari manajemen yang lebih baik dan manfaat lainnya (seperti HA yang lebih mudah) seringkali jauh lebih besar daripada mengimbangi peningkatan biaya perangkat keras yang sedikit meningkat.

Yang mengatakan, tempat saya bekerja instalasi Sql Server kami adalah salah satu dari hanya dua server yang saya tidak punya niat untuk virtualisasi dalam waktu dekat (yang lain adalah DC utama).


4

Menjalankan SQL Server adalah VM akan baik-baik saja, asalkan Anda dapat memberikan sumber daya yang cukup untuk VM untuk menjalankan aplikasi Anda. Jika di dunia fisik Anda membutuhkan 24 core dan 256 Gigs RAM maka Anda perlu menyediakan 24 vCPU dan 256 Gigs RAM di dunia virtual.

Saya baru saja menulis sebuah artikel di majalah SQL Server bulan lalu tentang menjalankan SQL Server di bawah VMware's vSphere.


2

Saya menjalankan dua database, satu PostgreSQL dan MySQL lainnya, dalam lingkungan virtual (Xen) di mana dom0s sangat tersedia. sistem file domU semua terletak pada SAN LUN iSCSI, diukir dengan volume logis LVM2. Basis data MySQL hanya untuk Cacti, dan karena itu tidak melihat banyak penggunaan sama sekali, dan terletak di LUN iSCSI juga.

Basis data PostgreSQL adalah basis data untuk lingkungan pementasan kami, dan karenanya melihat pemanfaatan yang lebih tinggi daripada db MySQL. Untuk alasan ini, database terletak pada set RAID10 lokal, dan DRBD direplikasi ke node cluster kedua. Namun, dalam hal beban nyata, basis data pementasan ini tidak melihat beban yang sangat tinggi sama sekali. Yang, menurut saya, menjadikannya kandidat yang bagus / hebat untuk melakukan virtualisasi.

Beberapa manfaat bagi organisasi kami adalah pengurangan konsumsi daya, menghemat ruang rak, dan biaya administrasi perangkat keras yang lebih sedikit.

Database produksi utama kami, di sisi lain, saya tidak bisa membayangkan menjadi virtual ....


2

Saya bekerja dengan server MSSQL dan MySQL di banyak server. Beberapa tahun yang lalu saya ragu-ragu untuk mulai menyiapkan server SQL pada VM karena saya telah mendengar tentang masalah kinerja menjalankan server SQL pada VM. Namun, saya terkejut setelah saya mengatur pasangan SQL server pertama saya dan tidak melihat perubahan kinerja. Semakin banyak server tempat saya bekerja berada di VM dan hampir semua klien perusahaan yang lebih besar tempat saya bekerja telah mengolah server SQL.

Ya, VM memang menambah biaya overhead dan jika Anda akan meng-hosting beberapa VM pada satu kotak, Anda akan memerlukan server yang bagus. Masalah sumber daya umum yang harus diwaspadai adalah menambahkan VM tambahan dan menipis sumber daya yang tersedia. Ini adalah praktik umum untuk merencanakan beberapa pertumbuhan, tetapi jika Anda membeli server Anda untuk meng-host 2 atau 3 VM dan sekarang ini menjalankan 10 VM Anda mungkin akan melihat peningkatan kinerja.

Saya akan berbohong jika saya mengatakan saya belum pernah melihat masalah kinerja menjalankan server SQL pada VM. Tapi, saya telah belajar bahwa jika Anda melihat kinerja yang buruk, mungkin ada yang salah dengan lingkungan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.