Seringkali, instalasi aplikasi berbasis debian-stable kami berjalan di mesin virtual - biasanya di VMware ESXi. Dalam kasus umum, kami tidak memiliki visibilitas ke atau pengaruh atas lingkungan virtualisasi mereka dan tidak memiliki akses ke mis. Klien VMware vCenter atau yang setara. Saya fokus pada VMware di sini, karena sejauh ini adalah yang paling umum yang kita lihat.
Kami ingin:
- Beri tahu admin VMware pelanggan: Anda dapat menjalankan aplikasi kami di misalnya lingkungan VMware ESX Anda, asalkan memenuhi kriteria kinerja X, Y dan Z.
- Dapat menentukan apakah kriteria X, Y dan Z sebenarnya dipenuhi secara terus menerus (misalnya juga sekarang ), bahkan pada sistem yang sedang berjalan (kami tidak dapat menghentikan aplikasi kami dan menjalankan tolok ukur, dan tolok ukur awal tidak akan cukup, karena kinerja dalam lingkungan virtual berubah seiring waktu).
- Yakinlah bahwa jika kriteria X, Y dan Z dipenuhi, kami akan memiliki sumber daya HW virtual yang memadai untuk menjalankan aplikasi kami dengan kinerja yang memuaskan.
Sekarang apa X, Y dan Z?
Kami telah melihat berulang kali, bahwa ketika ada masalah kinerja, masalahnya bukan pada aplikasi kita, tetapi dengan lingkungan virtualisasi. Misalnya mesin virtual lain menggunakan berton-ton CPU, memori, atau SAN tempat disk-disk itu disimpan benar-benar digunakan oleh sesuatu selain aplikasi kita. Kami saat ini tidak memiliki cara untuk membuktikan atau menyangkal hal itu.
Secara teoritis bisa juga bahwa kadang-kadang aplikasi kita lambat ... ;-)
Bagaimana cara menentukan akar penyebab masalah kinerja kami: Lingkungan virtual atau aplikasi kita?
Biasanya ada 3 area untuk masalah kinerja CPU, Memori dan DISK I / O.
CPU
Dalam mis. VMware, administrator dapat menentukan Reservasi dan Batas, dinyatakan dalam MHz, tetapi apakah mis. 512MHz pada satu host ESX persis sama dengan 512MHz pada host ESX lain, mungkin dalam cluster ESX yang sama sekali berbeda?
Dan bagaimana seseorang mengukur apakah kita benar-benar mendapatkannya? Ketika aplikasi kita sedang berjalan, kita mungkin dapat melihat bahwa kita berada pada pemanfaatan CPU 212% pada 4 CPU. Apakah itu karena aplikasi kita banyak melakukan atau karena VM lain pada host yang sama menjalankan tugas intensif CPU dan menggunakan semua CPU?
Memori (Balon?)
Jika kita meminta misalnya 16GB RAM, yang sering dikonfigurasi, tetapi karena balon , kita sebenarnya hanya mendapatkan 4GB, dan mengejutkan, aplikasi kita berkinerja buruk.
Seseorang dapat menanyakan alat-alat VMware tentang balon yang ada saat ini, tetapi kami mendapati bahwa alat itu sering berbohong (atau setidaknya tidak akurat). Kami telah melihat contoh di mana OS mengira ada 16GB total RAM, jumlah memori penduduk (RSS) dari semua proses adalah 4GB RAM, tetapi hanya ada 2GB RAM, bahkan ketika alat VMware memberi tahu kami ada 0 balon: - (
Selain itu, menambahkan RSS secara bersamaan tidak valid, karena ada RAM yang dapat dibagikan dengan mudah, misalnya memori salin saat menulis sehingga 512MB + 512MB tidak selalu berarti 1GB tetapi dapat berarti sesuatu yang kurang. Jadi seseorang tidak bisa hanya mengurangi RSS dari semua proses untuk mendapatkan ukuran berapa banyak RAM yang harus bebas dan dengan demikian mendeteksi balon yang andal. Satu dapat mendeteksi beberapa kasus balon, tetapi ada kasus lain di mana balon terjadi, tetapi tidak terdeteksi oleh metode ini.
Disk I / O
Saya kira kita dapat membuat grafik dari waktu ke waktu jumlah disk membaca dan menulis, jumlah byte yang dibaca dan ditulis, dan IO menunggu%. Tapi apakah itu akan memberi kita gambaran akurat tentang disk I / O? Saya membayangkan bahwa jika ada penambang bitcoin berjalan di VM lain menggunakan semua CPU, IO kami menunggu% akan naik, bahkan jika SAN yang mendasarinya memberikan kinerja yang persis sama, hanya karena sumber daya CPU kami turun, dan karenanya IO menunggu ( yang diukur dalam% ) naik.
Jadi, secara ringkas, bahasa apa yang bisa kita gunakan untuk menggambarkan misalnya admin VMware, kinerja apa yang kita butuhkan, dengan cara yang portabel dan terukur?
sumber
"It runs fine with x, y, and z"tidak cukup tepat. Anda harus bisa memberi tahu pelanggan Anda secara tepat apa yang dibutuhkan aplikasi Anda. Jika mereka memberi Anda sumber daya dan aplikasi berkinerja buruk maka pertanyaannya bukan"What do we need from a resource perspective?", tapi"Why is it performing poorly even though the proper resources have been allocated?"Jawaban:
Serius, kebanyakan administrator VMware tidak pandai dalam hal ini: Pemahaman yang buruk tentang manajemen sumber daya, seringkali tidak ada pengetahuan Linux (itu membantu) dan kurangnya bandwidth waktu. Saya menemukan sebagian besar admin internal mengalami kesulitan mempertahankan pengetahuan virtualisasi yang mendalam.
Untungnya, ada buku yang bisa Anda baca !
Sebagian besar lingkungan VMware tidak bagus: desain cluster yang buruk , perencanaan sumber daya yang buruk , penyimpanan di bawah standar (yaitu Synology NAS), HA salah konfigurasi, tidak ada pemantauan atau penambalan.
VMware sebagai organisasi mengecewakan kami: Mereka sangat buruk dalam menyebarkan informasi terkini dan mempromosikan praktik terbaik. Pencarian dasar untuk pertanyaan umum menghasilkan hasil dari 2009 dan revisi yang lebih lama dari VMware, terlepas dari kenyataan bahwa proses dan desain telah berubah seiring waktu.
Semua hal ini akan merugikan Anda.
Anda harus menentukan persyaratan nyata dari solusi Anda. Untuk dapat secara akurat menyatakan bahwa alat Anda memerlukan: 2 vCPU, 8GB RAM, dan kinerja penyimpanan 500 IOP akan sangat membantu seseorang seperti saya.
Pendekatan lain adalah mengamati lingkungan yang sehat atau ideal dan memperkirakan metrik dari sana.
Anda telah menggambarkan masalah dengan penggunaan tertentu. Apa masalah dan hambatannya?
Contoh VM berukuran tepat:
Server Exchange untuk organisasi 300 pengguna.
Contoh pemantauan sumber daya VM.
Good-ish: - VM berukuran tepat. - CPU overcommitted di seluruh cluster, tapi kami tidak mengalami pertentangan.
Buruk-ish:
sumber