Jadi sungguh, apa overhead virtualisasi dan kapan saya harus khawatir?


16

Saya sedang mencari aturan praktis yang baik untuk memahami kapan TIDAK memvirtualisasi mesin.

Sebagai contoh, saya tahu bahwa proses yang sepenuhnya terikat CPU dengan pemanfaatan hampir 100% mungkin bukan ide yang bagus untuk divirtualisasi, tetapi apakah ada gunanya menjalankan sesuatu yang memanfaatkan CPU sebagian besar waktu sebagai "jumlah besar" (katakanlah 40 atau 50%)?

Contoh lain: jika saya memvirtualisasi 1000 mesin, bahkan jika itu hanya digunakan secara ringan atau sedang, mungkin akan buruk untuk menjalankan semuanya pada host dengan hanya 4 core.

Dapatkah seseorang meringkas petunjuk tentang virtualisasi berdasarkan beban kerja mesin atau banyaknya mesin tamu jika dibandingkan dengan sumber daya host?

Saya biasanya melakukan virtualisasi pada host Windows menggunakan VirtualBox atau VMWare, tapi saya berasumsi ini adalah pertanyaan yang cukup umum.


1
bahkan dengan beberapa tugas yang terikat CPU ada satu titik untuk virtualisasi - memungkinkan pengguna untuk mengirimkan pekerjaan ke kelompok karena gambar VM memungkinkan mereka kontrol yang jauh lebih besar terhadap lingkungan pekerjaan yang dijalankan daripada yang mungkin hanya dengan penjadwal batch sederhana misalnya.
Flexo

Tetapi pada beberapa titik penjadwalan "eksekusi VM" tampaknya seperti overhead yang tidak perlu ketika sudah cukup sulit untuk menjadwalkan utas dalam satu VM, apakah saya benar?
kvista

Jawaban:


13

Subsistem disk. Ini biasanya sumber daya yang paling tidak dapat dibagikan. Memori, tentu saja, tetapi yang itu jelas.

Batasan subsistem disk berfungsi dengan dua cara. Jika suatu sistem menggunakan banyak disk I / O, tamu lain melambat. Jika tamu ini dalam produksi, maka perlu respons cepat terhadap kueri web. Ini bisa sangat membuat frustrasi dan juga alasan besar mengapa tidak menyewa perangkat keras virtual. Anda dapat meminimalkan masalah ini dengan menggunakan disk khusus.

Menggunakan hanya 512 MB memori di Tamu menempatkan semua cache disk pada host. Dan itu tidak terbagi rata di antara para tamu.

Jangan khawatir tentang CPU IO. Dengan cara ini, virtualisasi sangat efisien, seringkali terkait karena hanya beberapa proses yang berjalan pada sistem yang sama. Saya jarang melihat sistem multi-xeon berjalan 100% pada CPU.

edit: salah ketik


3
persyaratan I / O disk yang berat akan menjadi alasan # 1 untuk tidak melakukan virtualisasi - ini adalah sumber daya yang paling berat dihantam oleh hukuman virtualisasi, lihat codinghorror.com/blog/2006/10/…
Jeff Atwood

Terima kasih - kedua komentar sangat membantu. Hanya ingin tahu apakah ada yang tahu mengapa penggunaan disk tinggi bermasalah untuk divirtualisasi? Mengapa insinyur virtualisasi mengabaikan masalah yang relatif mendasar itu? Atau hanya lebih kompleks daripada virtualisasi CPU?
kvista

Catatan - @ Jeff, saya membaca posting blog 2006 Anda dan saya berasumsi bahwa akan menjelaskan mengapa lebih baik (yaitu, reservasi spindle), tetapi pertanyaan saya untuk desainer / pelaksana virtualisasi tetap sama - apakah ini hanya secara mendasar bermasalah untuk virtualisasi di cara virtualisasi CPU tidak?
kvista

3
Hanya ada begitu banyak upaya yang dapat dilakukan oleh harddisk. Untuk harddisk 5ms ini akan menjadi 200 mencari per detik. Dan, secara umum, ketika OS menyalin file atau memindai direktori selalu menggunakan 100% dari disk io. Selama waktu ini semua permintaan kecil dari disk tertunda, dan ada banyak dari mereka. Juga buffer sistem file terbuang karena salinan. Orang bisa mengatakan konsep OS yang berfungsi bergantung pada hard disk yang menganggur.
Antti Rytsölä

1
Terima kasih. Saya kira itu akan menarik untuk melihat apakah SSD mengubah persamaan ini sama sekali. Tapi sekarang kita sudah terlalu jauh ke mode diskusi. Saya mengerti - terima kasih semua.
kvista

15

Hal-hal yang saya tidak akan pernah masukkan ke dalam VM:

  • Apa pun yang menggunakan perangkat keras tertentu yang tidak dapat divirtualkan: biasanya grafik, beberapa modul keamanan perangkat keras, apa pun dengan driver yang disesuaikan (misalnya driver jaringan tujuan khusus).

  • Sistem dengan masalah lisensi. Beberapa biaya perangkat lunak per CPU fisik atau inti, tidak peduli seberapa sedikit Anda telah mengalokasikan ke VM. Anda akan terkena dalam audit jika Anda memiliki perangkat lunak yang dilisensikan untuk satu inti berjalan dalam VM pada server 32-inti.

Hal-hal yang saya tidak ingin menempatkan dalam VM:

  • Perangkat lunak yang sudah berupaya menggunakan semua sumber daya dalam perangkat keras komoditas. Mesin yang bekerja sebagai bagian dari upaya "data besar" seperti hadoop biasanya dirancang untuk dijalankan dengan logam biasa.

  • Apa pun yang akan disetel dengan halus untuk memanfaatkan sumber daya. Ketika Anda benar-benar mulai menyetel basis data, VM yang bersaing untuk sumber daya benar-benar akan melemparkan kunci pas dalam pekerjaan.

  • Apa pun yang sudah memiliki hambatan besar. Itu sudah tidak bermain baik dengan dirinya sendiri, kemungkinan tidak akan bermain dengan baik dengan orang lain.

Ada beberapa hal yang cukup mengagumkan untuk dimasukkan ke dalam VM:

  • Apa pun yang menghabiskan banyak waktu idle. Host utilitas seperti mail dan DNS mengalami kesulitan menghasilkan cukup beban pada perangkat keras modern untuk menjamin server khusus.

  • Aplikasi yang tidak skala dengan baik (atau mudah) sendiri. Kode lama cukup sering masuk dalam kategori ini. Jika aplikasi tidak akan berkembang untuk mengambil server, gunakan banyak server virtual kecil.

  • Proyek / aplikasi yang mulai kecil tetapi berkembang. Jauh lebih mudah untuk menambahkan sumber daya ke VM (dan juga pindah ke perangkat keras yang lebih baru, lebih besar) daripada memulai dengan bare metal.

Juga, saya tidak yakin apakah Anda melebih-lebihkan tentang menempatkan sejumlah besar VM pada satu host, tetapi jika Anda mencoba untuk rasio VM: HW yang besar, Anda mungkin ingin mempertimbangkan ESX, Xen, KVM sebagai gantinya. Tarif Anda akan jauh lebih baik daripada menggunakan VMware atau kotak virtual di Windows.


1
+1 komentar terorganisir yang sangat membantu - terima kasih!
kvista

Satu komentar lagi - bahkan jika saya menggunakan ESX, dll. Saya berasumsi pada titik tertentu tidak ada gunanya menempatkan mesin X pada host inti Y. Apa aturan praktis yang baik? Saya berasumsi virtualisasi s / w kertas putih di suatu tempat harus mengatasi masalah ini, tetapi sayangnya saya tidak dapat dengan mudah menemukannya.
kvista

1
Untuk VMware, Anda bisa mulai di sini: vmware.com/technology/whyvmware/calculator
Cakemox

Untuk referensi: per tautan VMWare di atas, Anda dapat mengonfigurasi hingga 30 VM per CPU. Standarnya adalah 6 VM per CPU.
Alex Yursha

4

Ada dua poin untuk kinerja virtualisasi.

  • kemacetan bersama
  • persaingan

Pada kemacetan bersama, siapa lagi yang menggunakan besi yang sama? Jika Anda berada di lokasi yang tervirtualisasi, Anda sangat bergantung pada mitra hosting yang jujur ​​kepada Anda.

Saya pikir pertanyaan utama untuk kinerja mentah (terutama interaktivitas) untuk ditanyakan adalah bagian mana dari sistem virtualisasi yang ditiru. Ini berbeda tergantung pada pengaturan. Disk dan jaringan adalah kandidat yang umum. Sebagai patokan, emulasi menggandakan "biaya" kinerja untuk melakukan suatu tindakan, sehingga waktu latensi perangkat keras harus dihitung dua kali lipat dan angka thruput apa pun harus dibelah dua.


1
angka yang saya lihat adalah CPU pada 96-97%, jaringan pada 70-90%, dan disk pada 40-70% (dari logam kosong)
Jeff Atwood

1
Komentar +1 aturan praktis sangat membantu.
kvista


1

Jawaban yang bagus dari anttiR.

Selain itu, sistem waktu kritis. Saya hanya mencari tahu bahwa pembalikan sepeser pun Hyper-V (vm perlahan-lahan jatuh di belakang, semua OS modern di vm melakukan itu, sering disinkron ulang) tidak bermain dengan baik dengan beberapa aplikasi penting waktu saya kembangkan. Ditambah lagi saya akan menggunakan cpu "banyak" di sana, dan berencana untuk mendapatkan mesin 12 inti hanya untuk aplikasi tersebut dalam produksi.


Asterisk adalah salah satu aplikasi tersebut. Anda mendapatkan beberapa hal yang sangat aneh terjadi selama panggilan konferensi saat divisualisasikan.
Ryaner

Saya memiliki masalah dengan stabilitas jam untuk perekaman data;) Terima kasih ya ampun, saya mendapatkan stempel waktu yang dapat diandalkan dari umpan data, tetapi mencari tahu apakah ada masalah jaringan sulit ketika jam sistem tidak stabil.
TomTom
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.