Pengguna sistem tervirtualisasi, dan khususnya penyedia layanan, sangat sering bertanya pada diri sendiri: "bagaimana cara memaksimalkan perangkat keras yang tersedia?" Dan dalam konteks ini, kita sering harus mendiskusikan hypervisor KVM dan perbedaan antara versi Virtuozzo yang berbeda. Dalam posting ini, kita akan berbicara tentang serangkaian tes dari sistem virtualisasi terbaru bersama dengan perkiraan kinerja nyata di bawah beban umum, serta memperhitungkan patch Meltdown dan Specter.
Apa yang paling penting untuk perusahaan hosting atau untuk departemen TI yang perlu mengatur dukungan untuk jumlah tugas maksimum pada peralatan yang ada? Jika sebuah perusahaan bekerja sesuai dengan model yang berorientasi layanan atau menjual layanan, maka praktiknya menunjukkan bahwa hal utama adalah indikator laba per server. Teknologi apa yang digunakan pada saat yang sama dan karena kepadatan distribusi tercapai, perwakilan bisnis tidak begitu khawatir.
Namun, pertanyaan mengapa kami menggunakan KVM sebagai hypervisor di Virtuozzo 7, dan bagaimana kami berbeda dari sistem virtualisasi OpenSource sederhana dalam kasus ini, sering ditanyakan. Dan hari ini saya ingin memberikan jawaban untuk itu.
Di masa lalu, Virtuozzo bekerja dengan hypervisor miliknya sendiri, tetapi beberapa tahun yang lalu kami menyadari bahwa mengembangkannya lebih mahal dan lebih sulit daripada mengoptimalkan KVM yang cukup berhasil dan efisien. Namun, KVM bukan tolok ukur untuk kinerja, dan seperti platform OpenSource lainnya, itu perlu diperbarui dengan file. Ini adalah bagian dari departemen pengembangan kami. Kami mengoptimalkan kode, mengintegrasikannya dengan platform penyimpanan data dan komponen lainnya, sehingga meningkatkan produktivitas dan kepadatan.
Perbandingan dengan hypervisor lainnya
Salah satu tes yang kami gunakan untuk mengukur kinerja adalah DVD Store. Menggunakan seperangkat perangkat lunak server klasik: Linux, Apache, MySQL, PHP (LAMP). Di dalam setiap mesin virtual, tes ini mengemulasi operasi toko DVD online. Hasil dari pengujian ini adalah jumlah transatal yang dilakukan secara total di semua mesin virtual (sumbu ordinasi). Jumlah mesin virtual yang terlibat dalam pengujian meningkat secara berurutan dari 1 hingga 100 (sumbu absis).
LAMP: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (mesin virtual)
Seperti yang dapat Anda lihat dalam grafik di atas, kinerja mesin virtual dengan CentOS Linux 7.4 yang berjalan pada Virtuozzo 7 hypervisor hingga 30% lebih tinggi daripada ketika memulai beban serupa pada KVM standar. Perbedaan terbesar diamati pada titik over-commit CPU, di mana jumlah total core prosesor yang dialokasikan untuk semua mesin virtual mencapai jumlah core fisik server CPU. Untuk server ini, titik ini terkait dengan 20 mesin virtual. Selain itu, Virtuozzo 7 inti dan kebijakan manajemen memori adaptif memastikan operasi mesin virtual yang stabil setelah titik over-komitmen RAM, di mana jumlah total RAM yang dialokasikan untuk semua mesin virtual melebihi ukuran memori fisik server. Dengan beban seperti itu, KVM standar tidak dapat membuat kondisi untuk operasi normal.
Perbandingan lain dibuat antara Virtuozzo 7 hypervisor dan Microsoft Hyper-V 3.0. Di sini, kinerja dievaluasi menggunakan uji vConsolidate, dan Windows Server 2012 R2 digunakan sebagai sistem operasi tamu untuk mesin virtual.
vConsolidate: Hyper-V vs Virtuozzo @ Windows 2012 R2 (mesin virtual)
Berbeda dengan Toko DVD, dalam vConsolidate bebannya tidak sama untuk semua mesin virtual. Dalam tes ini, mereka dibagi menjadi yang disebut CSU (Consolidation Stack Units). Setiap CSU adalah sekelompok empat mesin virtual yang memuat SPECjbb, WebBench, dan SysBench (OLTP). VM keempat di setiap CSU idle, yaitu tanpa beban. Hasil kuantitatif adalah rata-rata geometrik dari hasil tiga tes yang disebutkan di atas yang diperoleh secara total dari semua mesin virtual (sumbu ordinasi). Jumlah CSU yang terlibat dalam tes meningkat secara berurutan dari 1 menjadi 24 (absis).
Untuk kedua hypervisor, tes dilakukan dua kali: dengan tambalan untuk kerentanan Meltdown dan Specter diinstal, serta tanpa mereka. Perkiraan hasil menunjukkan bahwa Virtuozzo 7 rata-rata menunjukkan kinerja 15% lebih tinggi daripada hypervisor Microsoft "asli".
Meltdown dan Spectre
Seperti yang Anda ketahui, pada tanggal 4 Januari 2018, seluruh komunitas TI sangat senang dengan penemuan kerentanan konseptual skala besar di semua prosesor Intel, dengan pengecualian Itanium dan Atom yang lebih lama (hingga 2013). Menggunakan kerentanan ini memungkinkan setiap proses yang tidak terprivatisasi dalam sistem untuk mengakses data kernel (Meltdown) atau data dari proses lain (Spectre). Pengembang perangkat lunak berfokus pada merilis pembaruan perangkat lunak untuk mengatasi kerentanan ini. Namun, pengguna tentu memiliki pertanyaan tentang bagaimana pembaruan ini memengaruhi kinerja sistem.
Kami memeriksa bagaimana tambalan untuk Meltdown dan Specter mempengaruhi kinerja kontainer dengan CentOS Linux 7.4 menggunakan tes vConsolidate sebagai contoh. Kemudian kami melakukan pengukuran lain - dengan kernel kompiler yang dimodifikasi yang dikompilasi dengan opsi "Retpoline" (misalnya, GCC dan Dentang / LLVM menawarkan opsi ini).
Performa dengan Retpoline: vConsolidate @ CentOS 7.4 (wadah)
Seperti yang dapat Anda lihat dalam grafik di atas, menerapkan tambalan terhadap Meltdown dan Specter secara signifikan mengurangi kinerja wadah. Selain itu, tambalan yang paling "sulit" adalah untuk Specter-V2. Namun, menggunakan kompiler dengan opsi Retpoline baru memungkinkan Anda untuk meninggalkan patch ini dengan aman pada sistem dengan prosesor yang lebih tua dari Skylake dan memenangkan kembali sebanyak 25% dari kinerja. Namun, kami masih kehilangan sekitar 5% karena tambalan untuk Meltdown dan Specter-V1.
Performa dengan Retpoline: vConsolidate @ CentOS 7.4 (mesin virtual)
Dalam kasus CentOS Linux 7.4, situasi di dalam mesin virtual sedikit lebih cerah: tambalan untuk Meltdown dan Specter menurunkan kinerja hanya 15%, dan perbedaan kinerja antara kernel yang tidak ditonton dan kernel yang dikompilasi dengan Retpoline hanya 1-2%. Dengan demikian, penggunaan kompiler baru memungkinkan untuk hampir sepenuhnya mengimbangi penurunan kinerja. Namun, perlu mempertimbangkan bahwa ketiga pengukuran dilakukan pada mesin virtual yang sama - dengan kernel OS tamu yang belum ditambal. Memperbarui OS tamu akan menghasilkan penurunan kinerja tambahan untuk aplikasi pengguna.
Performa dengan Retpoline: vConsolidate @ Windows 2012 R2 (mesin virtual)
Bagan terbaru untuk hari ini adalah perbandingan yang serupa, tetapi dengan mesin virtual Windows Server 2012 R2. Di sini perlambatan dari tambalan tidak begitu besar dan berjumlah sekitar 10%, dan menggunakan kernel dengan Retpoline diperbolehkan untuk mengurangi perbedaan menjadi 2-3% relatif terhadap kernel yang belum ditambal.
Kesimpulan
Tentu saja, KVM yang tidak dimodifikasi memiliki kelebihannya, dan keunggulan utamanya adalah gratis. Tetapi tes yang dilakukan membuktikan bahwa perbaikan pribadi dan modernisasi dapat meningkatkan pengembalian infrastruktur yang digunakan. Artinya, jika Anda perlu menempatkan maksimal kontainer dan mesin virtual, memastikan penyimpanan permanen untuk mereka - semua pada platform yang sama dan dengan tarian perdukunan minimum - KVM yang ditingkatkan jauh lebih efektif, terutama jika layanan yang berjalan pada platform menunjukkan margin yang baik dan membawa nyata uang Dalam hal ini, biaya lisensi dan dukungan lebih dari terbayar dalam waktu sesingkat mungkin.
Kekuatan VZ7 tetap mendukung berbagai jenis VM dan wadah pada platform yang sama, dan dengan kinerja yang lebih tinggi untuk setiap kategori objek virtual. Namun, orang tidak dapat berbicara tentang obat mujarab di sini. Misalnya, jika peningkatan kepadatan tidak membawa organisasi tambahan keuangan, dan staf Anda sendiri dapat dengan mudah mengelola dan menyelesaikan solusi OpenSource, maka logikanya cenderung menggunakan alat terbuka, termasuk CentOS dan KVM asli.
Ngomong-ngomong, di posting berikutnya kita akan berbicara tentang evolusi penyimpanan terdistribusi dan kemampuan nyata untuk bekerja dengan VM dan wadah.