Apakah penjadwalan geng dipekerjakan oleh VMware merupakan kelemahan serius?

Saya sedang membaca beberapa artikel technet serta yang ini mengenai perbedaan antara cara VMware dan hyper v melakukan penjadwalan CPU.

Saya bertanya-tanya apakah saya bisa mendapatkan informasi yang objektif tentang ini. Tampaknya penjadwalan geng yang digunakan oleh VMware adalah kerugian yang SANGAT BESAR, tapi saya tidak ingin minum minuman dingin saja. Apakah itu berdampak serius pada kinerja atau melakukan iterasi terbaru dari hyper visor VMware menyelesaikan ini?

Sunting: Ketika saya mengatakan kerugian saya maksudkan relatif terhadap "penjadwalan prosesor bebas" Hyper V atau KVM melakukannya. Materi yang saya baca tidak mengatakan ada masalah dengan "penjadwalan prosesor gratis" yang dihindari dengan penjadwalan geng.

Seperti melantunkan Bloody Mary ke cermin kamar mandi yang gelap, mari kita lihat apakah kita bisa membuat Jake Oshins muncul ...

Penjadwalan geng juga disebut sebagai penjadwalan bersama. Saya pikir VMware lebih suka istilah co-scheduling daripada penjadwalan geng.

Dalam versi ESX sebelum versi 3.x, VMware menggunakan penjadwalan bersama "ketat", yang memiliki kelemahan sinkronisasi. Di ESX 3.x dan di atasnya, VMware beralih ke penjadwalan bersama "santai".

Penjadwalan bersama yang santai menggantikan penjadwalan bersama yang ketat dalam ESX 3.x dan telah disempurnakan dalam rilis berikutnya untuk mencapai pemanfaatan CPU yang lebih baik dan untuk mendukung mesin virtual multiprosesor yang luas. Penjadwalan bersama yang santai memiliki beberapa sifat yang berbeda dibandingkan dengan algoritma penjadwalan yang ketat. Yang paling penting dari semuanya, sementara dalam algoritma penjadwalan bersama yang ketat, keberadaan vCPU yang lagging menyebabkan seluruh mesin virtual terhenti bersama. Dalam algoritma penjadwalan bersama yang santai, vCPU terkemuka memutuskan apakah harus menghentikan sendiri berdasarkan kemiringan terhadap vCPU saudara yang paling lambat. Jika kemiringan lebih besar dari ambang, vCPU terkemuka berhenti sendiri. Perhatikan bahwa vCPU lagging adalah salah satu yang membuat kemajuan jauh lebih sedikit daripada vCPU saudara tercepat, sementara vCPU terkemuka adalah salah satu yang membuat kemajuan lebih signifikan daripada vCPU saudara paling lambat. Dengan melacak vCPU saudara paling lambat, sekarang dimungkinkan bagi setiap vCPU untuk membuat keputusan penjadwalan sendiri secara mandiri. Seperti co-stop, keputusan awal juga dibuat secara individual. Setelah saudara kandung vCPU yang paling lambat mulai berkembang, vCPU yang berhenti bersama memenuhi syarat untuk memulai bersama dan dapat dijadwalkan tergantung pada ketersediaan pCPU. Ini memecahkan masalah fragmentasi CPU dalam algoritma penjadwalan bersama yang ketat dengan tidak mengharuskan sekelompok vCPU dijadwalkan bersama. Dalam contoh sebelumnya dari mesin virtual 4- vCPU, mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU kosong yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. Dengan melacak vCPU saudara paling lambat, sekarang dimungkinkan bagi setiap vCPU untuk membuat keputusan penjadwalan sendiri secara mandiri. Seperti co-stop, keputusan awal juga dibuat secara individual. Setelah saudara kandung vCPU yang paling lambat mulai berkembang, vCPU yang berhenti bersama memenuhi syarat untuk memulai bersama dan dapat dijadwalkan tergantung pada ketersediaan pCPU. Ini memecahkan masalah fragmentasi CPU dalam algoritma penjadwalan bersama yang ketat dengan tidak mengharuskan sekelompok vCPU dijadwalkan bersama. Dalam contoh sebelumnya dari mesin virtual 4- vCPU, mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU kosong yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. Dengan melacak vCPU saudara paling lambat, sekarang dimungkinkan bagi setiap vCPU untuk membuat keputusan penjadwalan sendiri secara mandiri. Seperti co-stop, keputusan awal juga dibuat secara individual. Setelah vCPU saudara yang paling lambat mulai mengalami kemajuan, vCPU yang berhenti bersama memenuhi syarat untuk memulai bersama dan dapat dijadwalkan tergantung pada ketersediaan pCPU. Ini memecahkan masalah fragmentasi CPU dalam algoritma penjadwalan bersama yang ketat dengan tidak mengharuskan sekelompok vCPU dijadwalkan bersama. Dalam contoh sebelumnya dari mesin virtual 4- vCPU, mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU kosong yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. Setelah saudara kandung vCPU yang paling lambat mulai berkembang, vCPU yang berhenti bersama memenuhi syarat untuk memulai bersama dan dapat dijadwalkan tergantung pada ketersediaan pCPU. Ini memecahkan masalah fragmentasi CPU dalam algoritma penjadwalan bersama yang ketat dengan tidak mengharuskan sekelompok vCPU dijadwalkan bersama. Dalam contoh sebelumnya dari mesin virtual 4- vCPU, mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU kosong yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. Setelah vCPU saudara yang paling lambat mulai mengalami kemajuan, vCPU yang berhenti bersama memenuhi syarat untuk memulai bersama dan dapat dijadwalkan tergantung pada ketersediaan pCPU. Ini memecahkan masalah fragmentasi CPU dalam algoritma penjadwalan bersama yang ketat dengan tidak mengharuskan sekelompok vCPU dijadwalkan bersama. Dalam contoh sebelumnya dari mesin virtual 4- vCPU, mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU kosong yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU siaga yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU. mesin virtual dapat membuat kemajuan maju bahkan jika hanya ada satu pCPU siaga yang tersedia. Ini secara signifikan meningkatkan pemanfaatan CPU.

Cuplikan di atas adalah dari dokumentasi VMware sendiri .

Jadi VMware tidak menggunakan penjadwalan geng yang ketat lagi. Saya akan memperlakukan dokumentasi langsung dari vendor sebagai lebih otoritatif.

Satu-satunya hal yang akan memberi Anda angka keras adalah patokan, dan itu akan sepenuhnya tergantung pada jenis kode yang sedang dijalankan CPU. Tetapi saya dapat memberitahu Anda bahwa jika VMware berada pada posisi yang kurang menguntungkan, maka mereka tidak akan memiliki bagian terbesar dari pasar virtualisasi.

Oke, Ryan, kau membuat hariku. Saya tidak membaca forum ini sebanyak dulu, tapi kebetulan saya check in.

Red888, Anda harus tahu di muka bahwa saya seorang arsitek perangkat lunak yang bekerja pada Hyper-V di Microsoft. Saya berasumsi sebagian besar orang yang membaca ini sangat mampu mengklik tautan nama saya di bawah ini dan menemukan itu, atau bahkan Googling saya, tetapi untuk jawaban ini sangat berguna untuk sepenuhnya yakin bahwa orang-orang yang membaca ini tidak memiliki keraguan tentang perspektif saya.

Secara umum, penjadwalan geng berguna jika hypervisor tidak memiliki cara untuk mempengaruhi perilaku OS yang berjalan di dalam VM. Ini, tentu saja, mengapa VMware memulai dengan cara ini. Mereka tidak memiliki sistem operasi apa pun sehingga tujuan mereka adalah membuat sistem operasi yang ada berfungsi dengan baik. Jika saya adalah mereka, di sinilah saya akan mulai.

Penjadwalan geng, dan VMware mungkin akan mengatakan bahwa saya benar tentang hal ini, meninggalkan banyak batasan tentang bagaimana Anda dapat menggunakan prosesor fisik di dalam mesin. Hypervisor seringkali tidak dapat menemukan sumber daya yang tepat untuk saat ini. Jadi mereka telah memodifikasi algoritme mereka selama bertahun-tahun, mencari cara untuk melakukan penjadwalan yang berfungsi lebih baik.

Microsoft (dan mungkin beberapa perusahaan lain) memulai dengan pandangan yang berbeda. Kami memiliki Windows. Kami akan membuat Windows berperilaku baik ketika divirtualisasikan. Dan dengan demikian penjadwalan geng tidak akan diperlukan. Kami bahkan tidak akan repot-repot membangun penjadwal geng.

Menariknya, kami di Microsoft lebih peduli tentang Windows yang berjalan dengan baik dibandingkan dengan sistem operasi lain daripada kami peduli tentang Hyper-V yang terlihat lebih baik daripada VMware, atau KVM, atau Xen, atau Oracle, atau Unisys, dll. Jadi kami menerbitkan antarmuka yang Windows gunakan untuk bekerja sama dengan hypervisor. Berikut tautan jika Anda penasaran, meskipun saya tidak merekomendasikannya sebagai bacaan sebelum tidur:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Jadi setiap vendor hypervisor dapat mengekspos hal-hal yang akan memicu perilaku kooperatif dari Windows. Beberapa dari mereka memilikinya. Jujur saya tidak tahu apakah VMware memiliki, atau tidak, atau akan mengungkapkan ini. Anda harus bertanya kepada mereka, atau seseorang yang membayar banyak perhatian kepada mereka. Dan jika mereka melakukannya, saya akan sangat terkejut jika mereka tidak mengubah jadwal mereka untuk lebih santai. Pernyataan terakhir itu, tentu saja, adalah spekulasi murni.

Jadi jawaban saya adalah saya ragu Anda harus membuat keputusan pembelian pada tahun 2014 berdasarkan cara kerja penjadwal hypervisor. Saya curiga mereka sudah cukup baik sekarang. Beberapa tahun yang lalu, itu mungkin tidak benar.

Anda harus mencoba beban kerja Anda pada berbagai sistem dan melihat cara kerjanya. Saya berani bertaruh kinerja utama Anda akan turun ke apakah penyimpanan dan jaringan Anda memenuhi kebutuhan Anda.