Substitusi impor dalam praktek. Bagian 2. Awal. Hypervisor

Dalam artikel sebelumnya, opsi dipertimbangkan dimana sistem yang ada dapat diganti sebagai bagian dari pelaksanaan perintah substitusi impor. Artikel selanjutnya akan fokus pada pemilihan produk spesifik untuk menggantikan yang saat ini digunakan. Mari kita mulai dari titik awal - sistem virtualisasi.

1. Tepung pilihan

Jadi apa yang bisa Anda pilih? Dalam daftar Kementerian Komunikasi ada pilihan :

• Sistem virtualisasi server " R-Virtualisasi " (libvirt, KVM, QEMU)
• Paket perangkat lunak " Brest Virtualization Tools " (libvirt, KVM, QEMU)
• Platform manajemen dan pemantauan untuk lingkungan virtualisasi Sharx Stream (solusi cloud yang tidak cocok untuk sektor publik dalam 95% kasus (privasi, dll.)
• Perangkat lunak virtualisasi HOST untuk server, desktop, dan aplikasi (KVM x86)
• Sistem manajemen yang aman dari lingkungan virtualisasi " Z | virt " (alias oVirt + KVM)
• Sistem manajemen lingkungan virtualisasi ROSA Virtualisasi (alias oVirt + KVM)
• QP VMM Hypervisor (terlalu mirip dengan Oracle Virtual Box untuk menjadi hal lain)

Anda juga dapat memperhitungkan hypervisor akun yang merupakan bagian dari pengiriman OS, atau berada di repositori mereka. Sebagai contoh, Astra Linux yang sama memiliki dukungan KVM. Dan karena ini termasuk dalam repositori OS, itu dapat dianggap "sah" untuk instalasi dan penggunaan. Fakta bahwa "apa yang dapat digunakan dalam kerangka substitusi impor dan apa yang tidak" dibahas dalam artikel sebelumnya, jadi saya tidak akan membahas masalah ini.

1.2. Ada satu NAMUN

Setelah pemeriksaan lebih dekat, kami menyimpulkan bahwa kami harus berurusan dengan hanya beberapa hypervisor terkenal, yaitu:

1. Kvm
2. Virtualbox
3. QEMU
4. bhyve

QEMU adalah program open-source gratis untuk meniru perangkat keras dari berbagai platform yang dapat bekerja tanpa menggunakan KVM, tetapi penggunaan virtualisasi perangkat keras secara signifikan mempercepat sistem tamu, jadi menggunakan KVM di QEMU (-able-kvm) adalah pilihan yang lebih disukai. (c) Yaitu, QEMU adalah hypervisor tipe 2, yang tidak dapat diterima dalam lingkungan produk. Ini dapat digunakan dengan KVM, tetapi dalam hal ini, QEMU akan digunakan sebagai alat manajemen KVM.

bhyve - hipervisi dari tipe kedua. Itu ditandai.

Menggunakan VirtualBox asli dalam perdagangan sebenarnya merupakan pelanggaran terhadap lisensi : “Dimulai dengan versi 4, dirilis pada Desember 2010, sebagian besar produk didistribusikan secara gratis di bawah lisensi GPL v2. Paket tambahan yang diinstal di atasnya, yang mendukung perangkat USB 2.0 dan 3.0, Remote Desktop Protocol (RDP), enkripsi drive, boot dari NVMe dan PXE, didistribusikan di bawah lisensi PUEL khusus ("untuk penggunaan pribadi dan sosialisasi"), di mana sistem "gratis untuk penggunaan pribadi, untuk tujuan pendidikan, atau untuk evaluasi sebelum memutuskan untuk membeli versi komersial." (c) Plus VirtualBox juga merupakan hypervisor tipe 2, sehingga juga menghilang.

Total: dalam bentuk murni kami hanya memiliki KVM .

2. Selebihnya: KVM atau KVM?

Jika Anda masih perlu beralih ke hypervisor "domestik", Anda memiliki, sejujurnya, sebuah pilihan kecil. Ini akan menjadi KVM dalam satu atau pembungkus lain, dengan berbagai modifikasi, tetapi masih akan menjadi KVM. Baik atau buruk - pertanyaannya berbeda, toh tidak ada alternatif.

Jika kondisinya tidak begitu ketat, maka, sebagaimana dinyatakan dalam artikel sebelumnya: “Kita perlu membawa indikator ke batas yang ditetapkan. Faktanya, ini berarti bahwa kita harus mengganti sistem operasi yang ada dengan produk dari registri Kementerian Komunikasi dan Komunikasi dan membawa jumlah sistem operasi yang diganti menjadi 80% ... Jadi, kita dapat dengan aman meninggalkan cluster di Hyper-V, karena kita sudah memilikinya dan kita menyukainya. .. "(c) Jadi kita dihadapkan dengan pilihan: Microsoft Hyper-V atau KVM . KVM mungkin dengan kontrol "melesat" untuk itu, tetapi masih akan tetap KVM yang sama.

Produk-produk ini dibandingkan jauh lebih dari sekali , tidak dua kali , tidak tiga kali ... Ya, Anda mengerti ...

Tentang penyebaran dan konfigurasi KVM, itu juga ditulis lebih dari sekali , tidak dua kali , tidak tiga kali dan tidak empat kali ... Singkatnya, mereka berhasil .

Hal yang sama berlaku untuk Microsoft Hyper-V ..

Saya tidak melihat alasan untuk mengulang dan menjelaskan sistem ini, membandingkan, dll. Anda bisa, tentu saja, menarik poin-poin penting dari artikel-artikel itu, tetapi ini akan menjadi rasa tidak hormat bagi para penulis, saya pikir. Siapa yang harus memilih - dia akan membaca tidak hanya ini, tetapi juga segunung informasi untuk memutuskan.

Satu-satunya perbedaan yang ingin saya fokuskan adalah failover clustering. Jika Microsoft memiliki ini dibangun ke dalam OS dan fungsi hypervisor, maka dalam kasus KVM, Anda harus menggunakan perangkat lunak pihak ketiga, yang harus dimasukkan dalam repositori OS. Kelompok yang sama dari Corosync + Pacemaker, misalnya. (Hampir semua OS dalam negeri memiliki banyak ini ... mungkin semua orang memilikinya, tetapi saya tidak memeriksa 100%.) Ada juga banyak manual untuk mengkonfigurasi pengelompokan.

3. Kesimpulan

Yah, seperti biasa, Kulibin kami tidak repot, mereka mengambil apa yang terjadi, mengacaukan sedikit dari mereka sendiri, dan membagikan "produk", yang menurut dokumen adalah domestik, tetapi pada kenyataannya - OpenSource. Apakah masuk akal untuk mengeluarkan uang dari anggaran untuk sistem virtualisasi "terpisah" (baca tidak termasuk dalam OS)? Saya kira tidak. Karena Anda masih akan menerima KVM yang sama, Anda hanya perlu membayar untuk itu.

Dengan demikian, pilihan penggantian untuk hypervisor diturunkan ke OS server mana yang ingin Anda beli dan operasikan untuk Enterprise. Atau, seperti dalam kasus saya, Anda akan tetap pada apa yang sudah Anda miliki (Hyper-V \ ESXi \ enter_n diperlukan).

Juga pada topik yang dapat Anda baca:

Artikel sebelumnya tentang perencanaan substitusi impor.

Dan selanjutnya:

Artikel tentang sistem operasi "domestik".

Artikel tentang sistem dan layanan.

Dan tentang QP OS juga.