Aplikasi "tidak didukung" dalam VM?


10

Kami membeli beberapa perangkat lunak dari perusahaan kecil, itu adalah manajer alur kerja konten video Windows 32-bit, telah ada beberapa penyesuaian oleh mereka.

Kami telah bekerja dengan baik selama lebih dari setahun menjalankan kode ini dalam VMWare ESXi 4.1u2 VM pada W2K3EE-32-bit (itulah yang mereka dukung saat menjalankannya).

Kemudian mereka memperbarui kode mereka sekitar sebulan lalu dan kami mulai melihat salah satu vCPU secara berkala mematok 100%, vCPU kedua cukup menganggur, katakanlah 5-7% - jadi kami hanya berasumsi bahwa kode tersebut di-threaded dengan buruk dan menghubungi mereka tentang Itu.

Mereka sekarang kembali kepada kami dengan mengatakan bahwa kode mereka tidak berfungsi dalam VM, mereka telah mengetahui tentang persyaratan ini selama 18 bulan atau lebih, dan bahwa mereka ingin kita menggunakannya. Mereka mengatakan mereka hanya melihat masalah ini ketika dijalankan di dalam VM. Saya sudah menelepon dengan programmer senior mereka yang dijadwalkan dalam beberapa jam untuk berdiskusi.

Sekarang untungnya kita memiliki beberapa fisik yang dapat kita lakukan ini, sedikit memakan waktu tetapi bisa dilakukan.

Namun pertanyaan saya adalah bahwa mengingat VM ini tidak menyentuh perangkat keras secara langsung, ada di host yang sangat modern dan sebenarnya memiliki persyaratan yang sangat rendah (2 x vCPU, 4GB, 20GB boot vdisk, 100GB data vdisk, vNIC tunggal dan tidak ada yang lain) apa mungkin masalah dengan menjalankannya di VM, jika ada?

Jelas saya sangat mengejar ini dengan mereka tetapi saya hanya bertanya-tanya apakah orang lain telah menemukan aplikasi reguler, yang entah bagaimana berkelakuan buruk di dalam VM tetapi tidak pada fisik.


Apakah kedua vCPU menarik dari CPU yang sama? Apakah Anda memiliki pengaturan bahwa setiap inti nyata memetakan langsung ke vCPU? Apakah Anda melakukan sesuatu yang lucu seperti mengaktifkan hyper-threading di CPU Anda? Ini adalah beberapa pertanyaan yang harus membantu mengatasi apa pun yang mungkin menyebabkan mereka melambat pada akhirnya yang dapat Anda tangani. Anda mungkin akan memiliki ide yang lebih baik setelah berbicara dengan programmer senior bagaimana mengatasi masalah yang mungkin muncul karena dijalankan di VM atau Anda akan tahu pasti apakah mereka hanya salah melakukannya. Bisa jadi kode tersebut ditulis dalam java.
Wilshire

Saya membiarkan ESXi melakukan hal itu sendiri dalam hal penjadwalan proses, dan pada> 55xx-series Xeons hyperthreading tidak dianggap 'lucu', itu berfungsi dan sangat berguna - oh dan kode. NET 3.5.
Chopper3

Saya tahu bahwa MySQL Cluster juga tidak 'resmi' bekerja di lingkungan tervirtualisasi. Alasan? Tidak tahu! : P
Ben Ashton

Jawaban:


3

Meskipun saya tidak dapat berbicara untuk vendor ini atau paket perangkat lunak, saya telah bekerja untuk vendor besar (multinasional), di mana salah satu bagian dari perangkat lunak yang mereka jual memiliki masalah yang sangat spesifik ketika dijalankan pada VMware.

Dalam kasus ini, satu masalah dapat menyebabkan perangkat lunak menemui jalan buntu, dan yang lainnya dapat menyebabkan kerusakan data. Dengan demikian, pelanggan disarankan untuk tidak menjalankan perangkat lunak dalam lingkungan virtual. Beberapa masih melakukannya, dan dalam semua kasus yang saya sadari, mereka mengalami satu atau kedua masalah.

Jadi, meskipun jarang, ada beberapa kasus di mana perangkat lunak tidak berkinerja seperti yang Anda harapkan di VMware.

Meskipun saya menyadari itu tidak secara langsung membantu masalah Anda, itu menunjukkan bahwa VMWare tidak selalu merupakan sistem yang sempurna.

Catatan Kaki: dalam hal ini vendor dapat bekerja dengan VMware untuk menemukan resolusi (beberapa perbaikan kode, beberapa perubahan konfigurasi VMWare), dan mereka sekarang memiliki beberapa (sangat spesifik) panduan tentang cara menjalankan perangkat lunak pada VMWare.


Itulah hal yang membuat saya sedih tetapi bersyukur untuk mendengarnya - seperti yang saya sebutkan kepada Janne dalam tanggapannya, kami begitu terbiasa dengan hal-hal yang bekerja dengan benar di VM sehingga menemukan keadaan yang aneh membuat saya sedikit bingung untuk jujur. , jadi mendengar dari Anda bahwa saya tidak sendirian dalam hal ini setidaknya menghibur. Saya belum mendengar hal positif dari vendor perangkat lunak, tetapi saya tahu mereka sedang mencari masalah, tidak bisa membayangkan perbaikan selama sebulan atau lebih meskipun sayangnya. Terima kasih lagi.
Chopper3

3

Dengan ESX v5 dan batas Monster VM (32vCPU 1TB RAM), jumlah aplikasi yang mengalami masalah dengan VM menyusut. Sebagian besar yang pernah saya alami adalah: - mengandalkan waktu untuk linier (proses waktu nyata atau aplikasi yang perlu memiliki waktu linier ... ini biasanya dapat diubah) - aplikasi yang menyebabkan banyak gangguan perangkat keras atau pengalihan konteks

Dalam kebanyakan kasus, Anda harus dapat meminta perwakilan vmware Anda untuk berbicara dengan mereka. Saya percaya vmware masih memiliki tim orang yang berdedikasi untuk membuat hal-hal berfungsi (mereka memiliki laboratorium pendukung hanya untuk ini di awal-awal).

Adapun solusi, saya punya masalah serupa dengan VM memiliki penggunaan CPU yang tinggi (tetapi tuan rumah memiliki banyak sumber daya CPU gratis). Kami memperbaiki masalah dengan bermigrasi ke server dengan CPU Nehalem dan mengubah tingkat kompatibilitas CPU di EVC (jika Anda memiliki cluster dengan DRS / HA)


Terima kasih atas tanggapan Anda - Anda yang sangat baik ketika ini sebenarnya bukan jenis pertanyaan hitam dan putih. Contoh Anda sangat berguna, saya akan kembali dan memeriksa pengalihan konteks pada khususnya. Oh dan semua server kami menggunakan CPU yang persis sama (X5690) dengan EVC yang diatur secara seragam, tapi terima kasih lagi.
Chopper3

2

Saya telah melihat masalah yang sama dengan VMware ESX + Debian 6 + OpenLDAP 2.4.x (apa pun versi tepat OpenLDAP adalah apt-gettable ...).

Di bawah operasi sehari-hari berfungsi dengan baik, tetapi hal-hal seperti mengimpor file LDIF besar dengan 400.000 atau lebih entri sangat lambat (50-100x lebih lambat daripada dengan server fisik). Juga dengan durasi panjang, pembandingan volume tinggi, semuanya berjalan lancar dengan beberapa waktu respons milidetik, tetapi kadang-kadang ada puncak aneh mulai dari 500 hingga 25.000 (!) Milidetik.

Dengan server fisik saya tidak dapat mereproduksi masalah ini. Dan ya, saya menghabiskan sekitar tiga minggu mencoba untuk mengisolasi masalah, menyetel semua jenis parameter dari parameter sistem operasi ke nilai slapd ke nilai BerkeleyDB ... tidak ada yang membantu.


Terima kasih banyak untuk berbagi pengalaman Anda, saya tidak bisa mengatakan saya tidak menemukan semua ini sedikit aneh - Saya seorang virtualisasi pengalaman geek dan saya sangat terbiasa dengan hal-hal yang hanya berfungsi sehingga menemukan aplikasi yang melakukan ini telah mengguncang kepercayaan saya, jadi ada baiknya mendengar saya tidak dalam posisi terisolasi. Terima kasih.
Chopper3

1
Dua contoh lain: Atlassian mengatakan bahwa keduanya Jiradan Confluencetidak direkomendasikan untuk berjalan di lingkungan VM (ware). Harus ada pola untuk pengecualian ini, saya hanya belum tahu apa itu. Instalasi OpenLDAP saya tidak terlalu intensif I / O (tulis 3 MB / s dan tidak terlalu banyak IOPS di puncak selama benchmark), mungkin menggunakan CPU 20-40%, dan sekitar 150 MB RAM. Seharusnya tidak terlalu sulit untuk ditangani. Mungkin ada hubungannya dengan threading, tetapi konteks laporan vmstat beralih dll menjadi pada tingkat normal.
Janne Pikkarainen

Teori saya saat ini adalah bahwa ini ada hubungannya dengan menjaga waktu OS. VMware telah memiliki semua jenis masalah jam aneh di masa lalu dan bahkan sekarang kadang-kadang Anda harus melewati beberapa tsc=pitparameter gaya selama boot, dan setidaknya OpenLDAP SANGAT sensitif terhadap akurasi jam sistem. Mungkin saya harus mengunci semua aplikasi yang bermasalah dan melihat apakah mereka semua banyak menggunakan gettimeofday()atau lebih.
Janne Pikkarainen

Terima kasih sekali lagi, Anda benar tentang waktu di-VM, ini sudah melekat di mana-mana jadi saya akan mengerti ini tetapi saya tidak bisa tidak berpikir bahwa meskipun itu adalah masalah, itu akan menjadi masalah yang sangat cepat untuk vendor kami melihat kode mereka, ingat itu sebenarnya bukan aplikasi yang sensitif waktu, hanya mengambil konten video dan memprosesnya, hmmm. Terima kasih lagi.
Chopper3
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.