vSphere education - Apa kerugian konfigurasi VM dengan * terlalu banyak RAM?

Manajemen memori VMware tampaknya menjadi tindakan penyeimbang yang rumit. Dengan cluster RAM, Resource Pools, teknik manajemen VMware (TPS, ballooning, host swapping), pemanfaatan RAM di dalam tamu, swapping, pemesanan, pembagian, dan batasan, ada banyak variabel.

Saya dalam situasi di mana klien menggunakan sumber daya kluster vSphere khusus. Namun, mereka mengkonfigurasi mesin virtual seolah-olah mereka menggunakan perangkat keras fisik. Pada gilirannya, ini berarti membangun VM standar mungkin memiliki 4 vCPU dan 16GB atau lebih RAM. Saya datang dari sekolah mulai dari kecil (1 vCPU, RAM minimal), memeriksa penggunaan dunia nyata dan menyesuaikan sesuai kebutuhan. Sayangnya, banyak persyaratan vendor dan orang yang tidak terbiasa dengan virtualisasi meminta lebih banyak sumber daya daripada yang diperlukan ... Saya tertarik untuk mengukur dampak keputusan ini.

Beberapa contoh dari kluster "masalah".

Ringkasan kumpulan sumber daya - Kelihatannya hampir 4: 1 terlalu berkomitmen. Perhatikan tingginya jumlah RAM yang menggelembung.

Alokasi sumber daya - Kolom Alokasi Kasus Terburuk menunjukkan bahwa VM ini akan memiliki akses ke kurang dari 50% RAM yang dikonfigurasikan dalam kondisi terbatas.

Grafik pemanfaatan memori real-time dari VM teratas dalam daftar di atas. 4 vCPU dan 64GB RAM dialokasikan. Ini rata-rata di bawah penggunaan 9GB.

Ringkasan dari VM yang sama

• Apa kerugian dari sumber daya yang terlalu banyak berkomunikasi dan konfigurasi berlebihan (khususnya RAM) di lingkungan vSphere?

• Dengan asumsi bahwa VM dapat berjalan dalam lebih sedikit RAM, apakah adil untuk mengatakan bahwa ada overhead untuk mengkonfigurasi mesin virtual dengan lebih banyak RAM daripada yang sebenarnya mereka butuhkan?

• Apa argumen kontra untuk: "jika VM memiliki 16GB RAM yang dialokasikan, tetapi hanya menggunakan 4GB, apa masalahnya ?? "? Misalnya apakah pelanggan perlu dididik bahwa VM tidak sama dengan perangkat keras fisik?

• Metrik spesifik apa yang harus digunakan untuk mengukur penggunaan RAM. Melacak puncak "Aktif" versus waktu? Menonton "Dikonsumsi"?

Pembaruan: Saya menggunakan vCenter Operations Manager untuk profil lingkungan ini dan mendapatkan beberapa detail pada statistik cluster yang tercantum di atas. Sementara hal-hal yang pasti overkomit, VMs sebenarnya sangat overconfigured dengan RAM yang tidak perlu bahwa jejak memori (kecil) nyata tidak menunjukkan pertengkaran memori di tingkat cluster / host ...

Takeaway saya adalah bahwa VMs harus benar-benar berukuran tepat dengan sedikit buffer untuk caching level OS. Komitmen berlebihan karena ketidaktahuan atau "persyaratan" vendor mengarah pada situasi yang disajikan di sini. Balon memori tampaknya buruk dalam setiap kasus, karena ada dampak kinerja, sehingga ukuran yang tepat dapat membantu mencegah hal ini.

Pembaruan 2: Beberapa VM ini mulai macet dengan:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware menggambarkan ini sebagai gejala overcommitment memori yang besar . Jadi saya kira itu menjawab pertanyaan.

Laporan vCops "Mesin Virtual Oversized" ...

vCops "Limbah Dapat Diklaim" grafik ...

Manajemen memori vSphere cukup baik, meskipun istilah yang digunakan sering menyebabkan banyak kebingungan.

Secara umum, komitmen berlebihan memori harus dihindari karena justru menciptakan masalah jenis ini. Namun, ada saat-saat di mana hal itu tidak dapat dihindari, jadi diperingatkan terlebih dahulu!

Apa kerugian dari sumber daya yang terlalu banyak berkomunikasi dan konfigurasi berlebihan (khususnya RAM) di lingkungan vSphere?

Kelemahan utama dari sumber daya yang berlebihan adalah bahwa jika Anda memiliki pendapat, host Anda akan dipaksa untuk menggelembung, bertukar, atau secara cerdas menjadwalkan / menduplikasi duplikat di balik layar untuk memberikan setiap VM RAM yang dibutuhkan.

Untuk ballooning, vSphere akan mengembang "balon" RAM di dalam VM yang dipilih, lalu memberikan RAM yang menggelembung itu kepada tamu yang membutuhkannya. Ini tidak benar-benar "buruk" - VM saling mencuri RAM, jadi tidak ada pertukaran disk yang terjadi - tetapi bisa menyebabkan peringatan yang salah dan metrik yang miring jika ini bergantung pada analisis penggunaan RAM VM, saat RAM menang dapat ditandai sebagai "menggelembung", hanya saja "sedang digunakan" oleh OS.

Fitur lain yang dapat digunakan vSphere adalah Transparent Page Sharing (TPS) - yang pada dasarnya adalah de-duplikasi RAM. vSphere akan secara berkala memindai semua RAM yang dialokasikan, mencari halaman yang digandakan. Ketika ditemukan, itu akan menghapus duplikat dan membebaskan halaman yang digandakan.

Lihatlah whitepaper Manajemen Memori vSphere (PDF) - khususnya "Reklamasi Memori dalam ESXi" (halaman 8) - jika Anda memerlukan penjelasan yang lebih mendalam.

Dengan asumsi bahwa VM dapat berjalan dalam RAM lebih sedikit, apakah adil untuk mengatakan bahwa ada overhead untuk mengkonfigurasi mesin virtual dengan lebih banyak RAM daripada yang mereka butuhkan?

Tidak ada overhead yang terlihat - Anda dapat mengalokasikan 100GB RAM pada host dengan 16 GB (namun, itu tidak berarti Anda harus , karena alasan di atas).

Total memori yang digunakan oleh semua VM Anda adalah kurva "Aktif" yang ditunjukkan dalam grafik Anda. Tentu saja, Anda tidak boleh hanya mengandalkan angka itu ketika menghitung berapa banyak Anda ingin overcommit, tetapi jika Anda memiliki metrik historis seperti yang Anda miliki, Anda dapat menganalisis dan mengatasinya berdasarkan penggunaan aktual.

Perbedaan antara RAM "Aktif" dan "Dikonsumsi" dibahas dalam utas Komunitas VMWare ini .

Apa argumen kontra untuk: "jika VM memiliki 16GB RAM yang dialokasikan, tetapi hanya menggunakan 4GB, apa masalahnya ??" ? Misalnya apakah pelanggan perlu dididik?

Jawaban singkatnya adalah ya - pelanggan harus selalu dididik dalam praktik terbaik, terlepas dari alat yang mereka miliki.

Pelanggan harus dididik untuk mengukur VM mereka sesuai dengan apa yang mereka gunakan , bukan apa yang mereka inginkan . Banyak waktu, orang akan menentukan VM mereka secara berlebihan hanya karena mereka mungkin membutuhkan 16 GB RAM, bahkan jika mereka secara historis bertele-tele pada 2 GB hari demi hari. Sebagai administrator vSphere, Anda memiliki pengetahuan, metrik, dan kekuatan untuk menantang mereka dan bertanya apakah mereka benar-benar membutuhkan RAM yang telah mereka alokasikan.

Yang mengatakan, jika Anda menggabungkan manajemen memori vSphere dengan batas overcommit yang dikontrol dengan hati-hati, Anda seharusnya jarang memiliki masalah dalam praktiknya, kemungkinan kehabisan RAM untuk waktu yang lama relatif jauh.

Selain itu, vMotion otomatis (disebut Penjadwalan Sumber Daya Terdistribusi oleh VMware) pada dasarnya adalah penyeimbang beban untuk VM Anda - jika satu VM menjadi babi sumber daya, DRS harus memigrasikan para VM sekitar untuk memanfaatkan sumber daya gugus dengan sebaik-baiknya.

Metrik spesifik apa yang harus digunakan untuk mengukur penggunaan RAM. Melacak puncak "Aktif" versus waktu?

Sebagian besar dibahas di atas - perhatian utama Anda harus penggunaan RAM "Aktif", meskipun Anda harus hati-hati menentukan batas overcommit Anda sehingga jika Anda mencapai rasio tertentu ( ini adalah contoh yang layak , meskipun mungkin sedikit usang). Biasanya, saya pasti akan tetap dalam 120% dari total cluster cluster, tetapi terserah Anda untuk memutuskan rasio apa yang Anda merasa nyaman.

Beberapa artikel / diskusi yang baik tentang komitmen berlebihan memori:

• Memori terlalu banyak dalam produksi? YA YA YA
• vSphere - Memori Berlebih-lebihan?
• Memori terlalu banyak di vSphere

Selain jawaban yang sangat bagus dari Craig Watson, saya ingin menambahkan yang berikut:

Memori yang berlebihan pada VMware bukanlah sesuatu yang harus Anda lakukan dengan sengaja. Secara umum ini menunjukkan bahwa Anda atau pelanggan Anda kelebihan langganan perangkat keras.

Jika komitmen berlebihan adalah satu-satunya pilihan, maka saya sangat menyarankan Anda untuk menegakkan aturan prioritas. Jika seseorang bertekad untuk memberikan VM 16GB vRam yang tidak penting ketika hanya membutuhkan 4GB - setidaknya masukkan VM itu ke dalam kumpulan sumber daya yang rendah atau berikan prioritas rendah. Anda benar-benar tidak ingin database produksi penting ditukar oleh hypervisor. Tidak hanya kinerja akan sia-sia, itu juga akan memakan antrian I / O terhadap penyimpanan backend Anda.

Jika Anda menjalankan penyimpanan yang sangat cepat (FusionIO, Violin, SSD lokal, dll.) Maka bertukar mungkin bukan masalah besar, tetapi dengan penyimpanan SAN tradisional Anda pada akhirnya akan memengaruhi setiap VM dan host yang terhubung ke array / controller yang sama.