Teori Umum dan Arkeologi Virtualisasi x86

Pendahuluan

Tim penulis

Diposting oleh Anton Zhbankov ( AntonVirtual , cloudarchitect.cc )
Rekan penulis: Grigory Pryalukhin , Evgeny Parfenov

Konsep Virtualisasi Umum

Saya harus melihat banyak interpretasi tentang apa itu virtualisasi dan mendengarkan banyak kontroversi, tidak sedikit lebih dekat dengan memperdebatkan hasil praktisnya. Dan seperti yang Anda tahu, argumen dua orang pintar datang ke perdebatan tentang definisi. Mari kita tentukan apa itu virtualisasi dan apa yang berasal darinya.

Mungkin definisi terdekat dari virtualisasi adalah “abstrak” dari pemrograman berorientasi objek. Atau, jika diterjemahkan ke dalam bahasa Rusia normal, ini menyembunyikan implementasi di balik antarmuka abstrak. Yang tentu saja menjelaskan semuanya sekaligus. Mari kita coba lagi, tetapi bagi yang belum mempelajari pemrograman.

Virtualisasi - menyembunyikan implementasi spesifik di balik metode standar universal untuk mengakses sumber daya / data.

Jika Anda mencoba menerapkan definisi ini, ternyata definisi ini berfungsi pada subjek yang benar-benar tidak terduga. Katakanlah jamnya. Jadi, jam matahari diciptakan beberapa ribu tahun yang lalu, dan pada Abad Pertengahan sebuah jam mekanik diciptakan. Apa persamaannya? Matahari dan beberapa gigi? Semacam omong kosong. Dan kemudian kuarsa osilator dan yang lainnya.
Intinya adalah bahwa kita memiliki antarmuka standar - pointer atau pointer digital, yang dalam bentuk standar universal menunjukkan waktu saat ini. Tetapi apakah penting bagi kita seberapa spesifik mekanisme ini diterapkan di dalam kotak, jika waktunya ditunjukkan dengan akurasi yang cukup untuk kita?
“Biarkan saya,” Anda dapat mengatakan, “tetapi saya berpikir bahwa virtualisasi adalah tentang mesin, prosesor di sana, dan seterusnya!
Ya, ini tentang mobil dan prosesor, tetapi ini hanya kasus khusus. Mari kita lihat lebih luas, karena artikel itu dengan berani mengklaim teori umum.

POZOR!

Uwaga! Achtung! Pozor!

Artikel ini memiliki tujuan pendidikan umum untuk menghubungkan sejumlah teknologi dan kata-kata menakutkan bersama dengan sejarah ke dalam struktur tertentu, dan karena keadaan ini mengandung sejumlah besar penyederhanaan yang disengaja . Tentu saja, itu juga mengandung sejumlah besar kelalaian yang mengganggu, dan bahkan kesalahan kecil dengan kesalahan ketik. Kritik konstruktif hanya disambut, terutama dalam bentuk "Biarkan saya membawa Anda bagian ini ke dalam pikiran."

Jenis-jenis Virtualisasi

Mari kita kembali dari konsep yang sepenuhnya abstrak ke yang lebih akrab dengan komputer kita tercinta.

Virtualisasi penyimpanan

Yang pertama, mungkin, adalah jenis virtualisasi yang ditemui geek pemula - virtualisasi sistem penyimpanan data. Dalam hal ini, sistem penyimpanan tidak digunakan dalam arti array besar dengan disk yang terhubung melalui saluran serat, tetapi sebagai subsistem logis yang bertanggung jawab untuk penyimpanan data jangka panjang.

FS -> LBA -> CHS

Ambil wadah sistem penyimpanan yang paling sederhana pada satu hard magnetic disk. Format biasa untuk bekerja dengan data adalah file yang ada di drive logis. File dapat dibuka, dibaca, ditutup. Tapi objek seperti file tidak ada secara fisik - hanya ada cara untuk mengakses blok data tertentu menggunakan metode pengalamatan bentuk "drive: \ folder1 \ folder2 \ file". Yaitu kami memenuhi lapisan pertama virtualisasi - dari mnemonik dan dapat dipahami oleh manusia, kami menerjemahkan semuanya menjadi alamat yang dapat dimengerti sistem. Dalam tabel metadata, pengandar sistem file mencari jenis blok data apa yang ada di sana, dan kami mendapatkan alamat dalam sistem pengalamatan blok logis (LBA). Dalam sistem LBA, blok memiliki ukuran tetap dan mengikuti satu sama lain secara linear, yaitu entah bagaimana itu mungkin ada hubungannya dengan menyimpan data pada pita magnetik, tetapi hard disk entah bagaimana sangat berbeda! Dan di sini kita pergi ke lapisan kedua virtualisasi - terjemahan pengalamatan LBA ke CHS (silinder / kepala / sektor).



CHS, pada gilirannya, sudah di dalam pengontrol hard disk mulai menerjemahkan ke dalam parameter fisik untuk membaca, tetapi ini adalah cerita yang sama sekali berbeda.
Bahkan dalam akses sederhana ke file untuk, katakanlah, melihat vidosik dengan memasics, kami bertemu dengan tiga lapisan virtualisasi segera.
Semuanya akan terlalu sederhana jika lapisan tidak mulai tumpang tindih dalam urutan acak dan dalam berbagai cara.

RAID

Lapisan berikutnya dari virtualisasi, yang banyak orang tidak menganggapnya sebagai virtualisasi, adalah RAID (redundant array of cheap / independent disks).

Fitur utama RAID dalam konteks konsep yang dibahas bukanlah kemampuannya melindungi data dari kegagalan disk fisik tertentu. RAID menyediakan tingkat kedua pengalamatan LBA di atas beberapa (kadang-kadang sangat banyak) alamat LBA independen. Karena kita dapat mengakses RAID, terlepas dari tingkat RAID, dengan cara yang persis sama seperti disk tunggal tanpa RAID, kita dapat mengatakan dengan percaya diri:

RAID adalah virtualisasi disk.

Selain itu, pengontrol RAID tidak hanya membuat satu disk virtual besar dari beberapa disk fisik, tetapi dapat membuat jumlah yang sewenang-wenang dengan menambahkan lapisan virtualisasi lainnya.

Lihat virtualisasi

Jenis virtualisasi berikutnya, yang kebanyakan kita gunakan hampir setiap hari, tetapi tidak menganggapnya virtualisasi, adalah koneksi jarak jauh ke desktop.

Terminal server, VDI, dan bahkan hanya RDP via VPN ke server semuanya adalah virtualisasi sesi. Menggunakan antarmuka standar (monitor, keyboard, mouse), kami bekerja dengan mesin sungguhan, atau dengan desain yang tidak dapat dipahami dari desktop virtual pada klon tertaut dengan aplikasi kemas, dari mana kami mentransfer data melalui buffer ke aplikasi dengan pengiriman streaming. Atau tidak, siapa yang akan mencari tahu, selain orang yang mendesainnya?

Pengantar Virtualisasi x86

Sejarah dan ikhtisar prosesor

Eksekusi program

Pada pelajaran pertama dalam kursus pemrograman khusus, Vladimir Denisovich Lelyukh (tenang untuknya) memberi tahu siswa: komputer, terlepas dari namanya, tidak dapat dihitung, ia dapat berpura-pura dapat menghitung. Tetapi jika sesuatu terlihat seperti bebek, berjalan seperti bebek dan dukun seperti bebek, dari sudut pandang praktis itu adalah bebek.

Mari kita coba untuk mengingat ini untuk penggunaan praktis lebih lanjut.

Komputer, dan khususnya prosesor, sebenarnya tidak melakukan apa-apa - hanya mengharapkan beberapa parameter input di tempat-tempat tertentu, dan kemudian, melalui sihir hitam yang mengerikan, memberikan beberapa hasil di tempat-tempat tertentu.

Program dalam hal ini adalah aliran perintah tertentu yang dijalankan secara berurutan, sebagai akibatnya kami berharap untuk melihat hasil tertentu.
Tetapi jika program sedang dieksekusi, lalu bagaimana data bisa dimasukkan sama sekali? Dan secara umum, entah bagaimana berinteraksi di komputer?

Untuk ini, interupsi perangkat keras ditemukan. Pengguna menekan tombol - pengontrol keyboard memberi sinyal ini, dan eksekusi string kode saat ini terputus. Alamat penangan interupsi direkam dalam area memori tertentu, dan setelah menyimpan keadaan saat ini, kontrol ditransfer ke penangan interupsi. Pada gilirannya, pawang harus, secara teori, dengan cepat memproses semuanya, kemudian ia dan pawang, menuliskan kunci yang ditekan dalam buffer yang diinginkan, dan mengembalikan kendali. Dengan demikian, aplikasi sepertinya sedang berjalan, dan kita dapat berinteraksi dengan sistem.

Penangan interupsi (dan jenis penangan utama adalah penggerak perangkat) memiliki kesempatan untuk memasuki mode prosesor khusus, ketika interupsi lain tidak dapat diimplementasikan sebelum keluar dari mode ini. Yang pada akhirnya sering menyebabkan masalah hangup - kesalahan pada driver tidak memungkinkan untuk keluar dari gangguan.

Multitasking

Apa yang harus dilakukan dalam situasi jika perlu menjalankan beberapa program (stream kode dengan data dan struktur memori) pada saat yang sama? Jelas, jika ada lebih banyak stream kode daripada perangkat yang mampu mengeksekusinya, maka ini merupakan masalah.

Pseudo-multitasking muncul saat tugas dijalankan saat beralih langsung ke sana.

Di masa depan, sebuah koperasi (non-preemptive multitasking) muncul - tugas yang dapat dijalankan itu sendiri memahami bahwa ia tidak lagi membutuhkan sumber daya prosesor dan memberikan kontrol kepada orang lain. Tetapi semua ini tidak cukup.

Dan di sini lagi gangguan + kemampuan untuk berpura-pura datang untuk menyelamatkan kita. Tidak masalah bagi pengguna bahwa mereka dieksekusi secara bersamaan, itu cukup untuk terlihat seperti itu.
Oleh karena itu, seorang pawang hanya menutup telepon untuk menghentikan timer, yang mulai mengontrol aliran kode mana yang harus dieksekusi selanjutnya. Jika timer dipicu cukup sering (katakanlah 15 ms), maka bagi pengguna semuanya tampak seperti operasi paralel. Dan ada multitasking modern crowding out.

Mode nyata

Mode prosesor sebenarnya dalam artikel ini dapat dijelaskan dengan cukup sederhana - semua memori tersedia untuk semua orang. Aplikasi apa pun, termasuk malware (malware, perangkat lunak jahat), dapat mengakses di mana saja, baik untuk membaca dan menulis.

Ini adalah mode operasi awal keluarga prosesor Intel x86.

Mode yang dilindungi

Pada tahun 1982, sebuah inovasi muncul dalam prosesor Intel 80286 (selanjutnya hanya 286) - sebuah mode operasi yang dilindungi, yang membawa serta inovasi dalam pengorganisasian kerja dengan memori (misalnya, alokasi jenis segmen memori - kode, data, tumpukan). Tetapi hal terpenting yang dibawa prosesor 286 ke dunia x86 adalah konsep cincin perlindungan, yang masih kami gunakan.

Konsep cincin perlindungan awalnya muncul di OS Multics untuk mainframe GE645 (1967) dengan implementasi sebagian perangkat lunak, dan sepenuhnya perangkat keras sudah pada tahun 1970 dalam sistem Honeywell 6180.



Ide dasar cincin pertahanan menyerupai benteng abad pertengahan multi-level, yang paling berharga terletak di pusat di balik banyak dinding. Dalam hal ini, hal yang paling berharga adalah akses langsung tanpa batas ke area RAM mana pun dan kontrol atas semua proses. Mereka dimiliki oleh proses yang beroperasi di lingkaran perlindungan nol. Di belakang dinding, pada dering pertama, proses yang kurang penting bekerja, seperti driver perangkat, dan yang terakhir, aplikasi pengguna. Prinsipnya sederhana - dari dalam kamu bisa keluar, tapi dari luar ke dalam dilarang. Yaitu tidak ada proses pengguna yang dapat mengakses memori kernel OS, seperti yang dimungkinkan dalam mode real sebelumnya.

Dalam implementasi penuh pertama Honeywell 6180, 8 cincin perlindungan diterapkan, tetapi Intel memutuskan untuk menyederhanakan sirkuit menjadi 4, yang dalam praktiknya produsen OS mulai menggunakan hanya dua - nol dan ketiga.

32 bit

Pada tahun 1985, prosesor lain yang sangat penting secara arsitektur di jalur x86 dirilis - 80386 (selanjutnya 386), yang mengimplementasikan pengalamatan memori 32-bit dan menggunakan instruksi 32-bit. Dan tentu saja, virtualisasi memori. Seperti yang telah disebutkan, virtualisasi adalah penyembunyian implementasi aktual melalui penyediaan sumber daya "virtual" buatan. Dalam hal ini, kita berbicara tentang pengalamatan memori. Segmen memori memiliki pengalamatan sendiri, yang tidak ada hubungannya dengan lokasi sebenarnya dari sel memori.
Prosesor itu ternyata sangat laris sehingga diproduksi sebelum 2007.
Arsitektur dalam hal Intel disebut IA32.

64bit

Tentu saja, bahkan tanpa virtualisasi pada pertengahan 2000-an, industri sudah berjalan ke batas 32 bit. Ada beberapa penyelesaian dalam bentuk PAE (Extension Alamat Fisik), tetapi mereka rumit dan memperlambat kode. Transisi ke 64 bit adalah kesimpulan terdahulu.

AMD memperkenalkan versi arsitekturnya, yang disebut AMD64. Di Intel, mereka berharap untuk platform IA64 (Intel Architecture 64), yang juga kita kenal dengan nama Itanium. Namun, pasar bertemu arsitektur ini tanpa banyak antusiasme, dan sebagai hasilnya, Intel terpaksa menerapkan dukungan mereka sendiri untuk instruksi AMD64, yang pertama kali disebut EM64T, dan kemudian hanya Intel 64.

Pada akhirnya, kita semua tahu arsitektur ini sebagai AMD64, x86-64, x86_64, atau kadang-kadang x64.

Karena penggunaan utama server pada waktu itu seharusnya bersifat fisik, tanpa virtualisasi, hal lucu teknis terjadi dengan prosesor 64-bit pertama dalam virtualisasi. Hypervisor bersarang sering digunakan sebagai server laboratorium, tidak semua orang mampu membeli beberapa kluster server fisik. Dan pada akhirnya ternyata VM beban di hypervisor tertanam hanya bisa bekerja dalam mode 32bit.

Dalam prosesor x86-64 pertama, pengembang, sambil mempertahankan kompatibilitas penuh dengan mode operasi 32-bit, membuang sebagian besar fungsi dalam mode 64-bit. Dalam hal ini, masalahnya adalah menyederhanakan segmentasi memori. Kemampuan untuk menjamin tidak dapat diganggu gugat dari sepotong kecil memori di VM di mana pengendali pengecualian hypervisor bekerja dihapus. Dengan demikian, OS tamu dapat memodifikasinya.
Selanjutnya, AMD mengembalikan kemungkinan membatasi segmen, dan Intel hanya menunggu pengenalan virtualisasi perangkat keras.

UMA

Sistem multiprosesor X86 mulai bekerja dengan mode UMA (Uniform Memory Access), di mana jarak dari prosesor apa pun (keterlambatan mengakses sel memori) ke bilah memori sama. Dalam prosesor Intel, skema kerja ini dipertahankan bahkan setelah munculnya prosesor multi-core hingga generasi 54xx (Harpertown). Dimulai dengan generasi 55xx (Nehalem), prosesor telah beralih ke arsitektur NUMA.

Dari sudut pandang logika eksekusi, ini adalah tampilan utas perangkat keras tambahan, di mana Anda dapat menetapkan stream kode untuk eksekusi secara paralel.

NUMA

NUMA (Non Uniform Memory Access) - arsitektur dengan akses memori yang tidak merata. Dalam arsitektur ini, setiap prosesor memiliki memori lokal sendiri, yang diakses langsung dengan latensi rendah. Memori prosesor lain diakses secara tidak langsung dengan penundaan yang lebih tinggi, yang mengarah pada penurunan kinerja.

Untuk prosesor Intel Xeon Scalable v2 untuk 2019, arsitektur internal masih tetap UMA di dalam soket, berubah menjadi NUMA untuk soket lain (meskipun tidak benar-benar, dan itu hanya berpura-pura). Prosesor AMD Opteron memiliki arsitektur NUMA bahkan selama masa UMA Xeon tertua, dan kemudian NUMA menjadi bahkan di dalam soket sampai generasi terakhir Roma, di mana mereka kembali ke NUMA = soket.

Mesin virtual

Mesin virtual (VM, dari mesin virtual bahasa Inggris) - perangkat lunak dan / atau sistem perangkat keras yang mengemulasi perangkat keras dari beberapa platform (target adalah target atau platform tamu) dan menjalankan program untuk platform target pada platform host (host adalah platform host , platform host), atau virtualisasi beberapa platform dan menciptakan lingkungan di atasnya yang mengisolasi program dan bahkan sistem operasi satu sama lain. Wikipedia
Pada artikel ini kita akan mengatakan "mesin virtual", yang berarti "sistem mesin virtual", memungkinkan untuk sepenuhnya mensimulasikan semua sumber daya dan perangkat keras dalam bentuk konstruksi perangkat lunak.
Ada dua jenis utama perangkat lunak untuk membuat mesin virtual - dengan penuh dan resp. virtualisasi tidak lengkap.

Virtualisasi penuh adalah pendekatan di mana semua perangkat keras, termasuk prosesor, ditiru. Memungkinkan Anda untuk membuat lingkungan yang tidak tergantung pada perangkat keras, dan menjalankannya sebagai contoh OS dan perangkat lunak aplikasi untuk platform x86 pada sistem SPARC, atau emulator Spectrum yang terkenal dengan prosesor Z80 pada prosesor x86 yang sudah dikenal. Sisi lain dari kemandirian total adalah overhead yang tinggi untuk virtualisasi prosesor dan kinerja keseluruhan yang rendah.

Virtualisasi tidak lengkap adalah pendekatan di mana tidak 100% perangkat keras divirtualisasikan. Karena virtualisasi yang tidak lengkap adalah yang paling umum di industri, kami akan membicarakannya. Tentang platform dan teknologi mesin virtual sistem dengan virtualisasi yang tidak lengkap untuk arsitektur x86. Dalam kasus ini, ada virtualisasi prosesor yang tidak lengkap, mis. dengan pengecualian substitusi parsial atau menyembunyikan panggilan sistem tertentu, kode biner dari mesin virtual dieksekusi langsung oleh prosesor.

Virtualisasi perangkat lunak

Konsekuensi yang jelas dari arsitektur prosesor dan kebiasaan sistem operasi untuk bekerja di cincin nol adalah masalah - kernel OS tamu tidak dapat bekerja di tempat biasa. Cincin nol ditempati oleh hypervisor, dan Anda hanya perlu membiarkan OS tamu sampai di sana juga - di satu sisi kami kembali ke mode nyata dengan semua konsekuensinya, dan di sisi lain, OS tamu tidak mengharapkan siapa pun di sana, dan akan langsung menghancurkan semua struktur data dan menjatuhkan mobil.

Tapi semuanya diputuskan cukup sederhana: karena untuk hypervisor OS tamu hanyalah satu set halaman memori dengan akses langsung penuh, dan prosesor virtual hanyalah antrian perintah, mengapa tidak menulis ulang? Tepat saat itu, hypervisor mengeluarkan dari antrian instruksi untuk dieksekusi pada prosesor virtual semua instruksi yang memerlukan hak istimewa cincin nol, menggantikannya dengan yang kurang istimewa. Tetapi hasil dari instruksi ini disajikan dengan cara yang persis sama seolah-olah OS tamu berada di nol cincin. Dengan demikian, Anda dapat memvirtualkan apa saja, hingga tidak adanya OS tamu.
Pendekatan ini diimplementasikan oleh tim pengembangan pada tahun 1999 dalam produk VMware Workstation, dan kemudian pada tahun 2001 di hypervisor server GSX (tipe kedua, seperti Workstation) dan ESX (tipe pertama).

Paravirtualization

Paravirtualization adalah konsep yang sangat sederhana, yang mengasumsikan bahwa OS tamu tahu bahwa itu ada di mesin virtual, dan tahu cara mengakses OS host untuk fungsi sistem tertentu.Ini menghilangkan masalah emulasi dari cincin nol - OS tamu tahu bahwa itu tidak di nol dan berperilaku sesuai.
Paravirtualization di x86 muncul pada tahun 2003 dengan proyek Linux Xen.

Fungsi paravirtualized tertentu juga diterapkan di hypervisors dengan virtualisasi penuh melalui driver virtual khusus di OS tamu yang berkomunikasi dengan hypervisor untuk mengurangi overhead virtualisasi. Sebagai contoh, VMware ESXi untuk VM memiliki adapter SCSI PVSCSI paravirtual, yang meningkatkan kinerja keseluruhan untuk VM dengan operasi disk intensif, seperti DBMS yang dimuat. Driver untuk perangkat paravirtual datang dalam paket tambahan (misalnya VMware Tools), atau sudah termasuk dalam distribusi Linux (open-vm-tools).

Virtualisasi perangkat keras

Dengan perkembangan dan pertumbuhan popularitas virtualisasi, muncul keinginan untuk kedua produsen platform untuk mengurangi biaya dukungan mereka, dan dari sudut pandang keamanan, untuk menjamin perlindungan dalam perangkat keras.

Masalahnya dipecahkan dengan cara yang sangat sederhana - teknologi virtualisasi perangkat keras berpemilik Intel VT-x dan AMD-V ditambahkan, jika kita membuang detail teknis yang mendalam, minus cincin perlindungan pertama untuk hypervisor. Dengan demikian, situasi kerja di cincin nol yang akrab dengan OS akhirnya ditetapkan.

Jenis-jenis Hypervisor

Tipe 2 (dihosting)

Hypervisor dari tipe kedua adalah aplikasi yang berjalan di atas sistem operasi host. Semua panggilan mesin virtual ditangani oleh sistem operasi host hulu. Hypervisor dari tipe kedua sangat terbatas dalam kinerjanya, karena aplikasi hypervisor, yang tidak memiliki hak untuk alokasi sumber daya komputasi yang eksklusif, terpaksa bersaing untuk mereka dengan aplikasi pengguna lain. Dalam hal keamanan, hypervisor tipe 2 secara langsung tergantung pada kebijakan keamanan OS pengguna dan kerentanannya terhadap serangan. Saat ini, ada pendapat bulat di industri bahwa platform virtualisasi semacam itu untuk tingkat perusahaan tidak cocok. Namun, mereka sangat cocok untuk pengembangan lintas-platform dan penyebaran tegakan langsung pada mesin pengembang perangkat lunak, karena mereka mudah untuk dikelola dan digunakan.

Contoh dari tipe kedua dari hypervisor: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

Tipe 1 (bare-metal)

Hypervisor dari tipe pertama tidak memerlukan OS untuk tujuan umum, tidak seperti yang sebelumnya. Hypervisor itu sendiri adalah monolit yang mengontrol alokasi sumber daya komputasi dan I / O. Di cincin pengaman nol, ada inti mikro, di atasnya semua struktur kontrol bekerja. Dalam arsitektur ini, hypervisor mengontrol distribusi sumber daya komputasi dan mengontrol semua panggilan mesin virtual ke perangkat. VMware ESX dianggap sebagai hypervisor pertama dari tipe pertama untuk x86 untuk waktu yang lama, meskipun sekarang kami akan mengaitkannya dengan 1+. Satu-satunya perwakilan "jujur" dari jenis ini hari ini adalah VMware ESXi - penerus ESX, setelah itu menggigit bagian induk dengan RHEL.

Sebagai contoh, perhatikan arsitektur ESXi. Perintah manajemen hypervisor dijalankan melalui API agen, yang berjalan di atas VMkernel. Ini mungkin tampak seperti koneksi langsung ke hypervisor, tetapi tidak. Tidak ada akses langsung ke hypervisor, yang membedakan jenis hypervisor dari jenis kedua hypervisor dalam hal keamanan.



Kerugiannya di sini adalah driver perangkat: untuk memastikan “ketipisan” platform dan menghilangkan komplikasi yang tidak perlu dari versi ke versi, driver perangkat diputar, yang membuat infrastruktur fisik bergantung pada HCL (daftar kompatibilitas perangkat keras).

Tipe 1+ (Hybrid Hypervisor)

Hypervisor tipe hybrid (mereka juga tipe 1+, 1a, 1.5) ditandai dengan isolasi OS dasar ke dalam entitas khusus yang disebut partisi induk (partisi induk dalam terminologi Microsoft Hyper-V) atau domain induk (domain dom0 dalam terminologi Xen). Jadi, setelah menginstal peran hypervisor, kernel memasuki mode dukungan virtualisasi dan hypervisor bertanggung jawab untuk mengalokasikan sumber daya pada host. Tetapi bagian induk mengambil alih fungsi pemrosesan panggilan ke driver perangkat dan operasi I / O.

Bahkan, bagian induk menjadi semacam penyedia antara semua entitas tumpukan virtualisasi. Pendekatan ini nyaman dari sudut pandang kompatibilitas dengan peralatan: Anda tidak perlu menanamkan driver perangkat di hypervisor, seperti halnya dengan ESXi, yang berarti bahwa daftar perangkat berkembang banyak dan kurang tergantung pada HCL. Keuntungannya termasuk pembongkaran hypervisor dari tugas memproses panggilan ke driver perangkat, karena semua panggilan ditangani oleh bagian induk.

Arsitektur tingkat atas dari hypervisor tipe 1+ terlihat seperti ini:



Hypervisor jenis ini meliputi: VMware ESX yang telah meninggal, Microsoft Hyper-V, hypervisor berbasis Xen (Citrix XenServer dan implementasi Xen di berbagai distribusi Linux). Ingatlah bahwa Citrix XenServer adalah OS berbasis RHEL yang sedikit terpotong, dan versi serta fungsinya secara langsung bergantung pada versi Red-Hat Enterprise Linux saat ini. Dalam kasus implementasi Xen lainnya, situasinya tidak jauh berbeda: itu adalah kernel Linux yang sama dalam mode hypervisor Xen dan OS dasar dalam domain dom0. Ini mengarah pada kesimpulan yang tidak ambigu bahwa hypervisor berbasis Xen adalah tipe hybrid dan bukan hypervisor tipe 1 yang jujur.

Teknologi utama platform industri

Dasarnya akan diambil terminologi VMware, sebagai platform virtualisasi yang paling berteknologi maju. Pada artikel ini, kami membatasi diri pada teknologi hypervisor itu sendiri dan sistem kontrol dasar. Semua fungsionalitas canggih yang diterapkan oleh produk tambahan untuk uang tambahan akan ditinggalkan. Teknologi dikelompokkan ke dalam kelompok bersyarat untuk tujuan utama, seperti yang terlihat oleh penulis, dengan siapa Anda berhak untuk tidak setuju.

SLA

Ini adalah kumpulan teknologi yang terutama mempengaruhi kinerja SLA untuk aksesibilitas (RPO / RTO).

HA

Ketersediaan Tinggi - teknologi untuk memastikan ketersediaan VM yang tinggi dalam sebuah cluster oleh hypervisor. Dalam hal terjadi kematian host, VM secara otomatis restart pada host yang masih hidup. Efek: meminimalkan RTO sebelum batas waktu HA + restart OS / layanan.

FT

Fault Tolerance - teknologi untuk memastikan operasi VM yang berkelanjutan bahkan dalam kasus kematian host. Shadow VM dibuat pada host kedua, benar-benar identik dengan host utama dan mengulangi instruksi di baliknya. Dengan demikian, perbedaan dalam status VM diukur dalam puluhan atau ratusan milidetik, yang cukup dapat diterima untuk banyak layanan. Ketika tuan rumah meninggal, eksekusi secara otomatis beralih ke bayangan VM. Efek: meminimalkan RTO menjadi nol.

Tco

Ini adalah kumpulan teknologi yang terutama memengaruhi TCO.

vMotion

vMotion adalah teknologi untuk migrasi langsung dari titik eksekusi VM dari satu host yang berfungsi penuh ke yang lain. Pada saat yang sama, titik peralihan dari titik eksekusi kurang dari batas waktu koneksi jaringan, yang memungkinkan kita untuk mempertimbangkan migrasi sebagai siaran langsung, mis. tanpa gangguan dalam pekerjaan layanan produktif. Efek: mengurangi RTO ke nol untuk pemadaman yang direncanakan untuk pemeliharaan server dan, sebagai akibatnya, penghapusan sebagian pemadaman itu sendiri.

Penyimpanan vMotion

Storage vMotion adalah teknologi untuk migrasi langsung dari titik penyimpanan VM dari satu penyimpanan yang berfungsi penuh ke yang lainnya. Pada saat yang sama, bekerja dengan sistem disk tidak berhenti, yang memungkinkan migrasi dianggap hidup. Efek: mengurangi RTO menjadi nol untuk pemadaman yang direncanakan untuk pemeliharaan penyimpanan dan, sebagai hasilnya, menghilangkan sebagian pemadaman itu sendiri.

DPM

Manajemen Daya Terdistribusi - teknologi untuk mengendalikan tingkat beban host dan daya hidup / mati host saat beban pada gugus berubah. Membutuhkan DRS untuk operasinya. Efek: pengurangan konsumsi daya secara keseluruhan.

VSwitch yang didistribusikan

VSwitch Terdistribusi adalah teknologi untuk manajemen terpusat pengaturan jaringan switch host virtual. Efek: mengurangi volume dan kompleksitas pekerjaan dalam mengkonfigurasi ulang subsistem jaringan, mengurangi risiko kesalahan.

EVC

Enhanced vMotion Compatibility adalah teknologi yang memungkinkan menutupi instruksi prosesor yang tersedia untuk VM dalam mode otomatis. Ini digunakan untuk menyelaraskan pekerjaan VMs dalam cluster yang tidak merata dengan keluarga prosesor tertua, memberikan kemampuan untuk memigrasikan VMs ke host mana pun. Efek: menghemat kompleksitas infrastruktur sementara secara bertahap meningkatkan kapasitas / meningkatkan sebagian kluster.

QoS

Ini adalah kumpulan teknologi yang terutama mempengaruhi kinerja SLA dalam hal kualitas layanan.

vNUMA

vNUMA adalah teknologi yang memungkinkan OS tamu untuk berkomunikasi dengan topologi virtual VM NUMA untuk mesin lebar (vCPU atau vRAM> NUMA node). Efek: Kurangnya penalti pada kinerja perangkat lunak aplikasi yang mendukung NUMA.

Kumpulan sumber daya

Kumpulan sumber daya - teknologi yang menggabungkan beberapa VM menjadi satu kumpulan sumber daya tunggal untuk mengendalikan konsumsi atau menjamin alokasi sumber daya. Efek: menyederhanakan administrasi, memberikan tingkat layanan.

Batas / cadangan

Prosesor / memori yang membatasi dan berlebihan memungkinkan Anda membatasi alokasi sumber daya, atau sebaliknya, untuk menjamin alokasi mereka dalam situasi kelangkaan dan persaingan untuk memastikan pemeliharaan VM / kelompok prioritas tinggi.

DRS

Penjadwal Sumber Daya Dinamis - menyeimbangkan VM secara otomatis oleh penghuni tergantung pada beban untuk mengurangi fragmentasi sumber daya di kluster dan menyediakan tingkat layanan untuk para VM. Membutuhkan dukungan vMotion.

Penyimpanan Kontrol IO

Penyimpanan Kontrol IO adalah teknologi yang membatasi "tetangga yang bising", mesin prioritas rendah dengan beban disk yang tinggi untuk menjaga kinerja sistem penyimpanan yang mahal tersedia untuk beban kerja produktif. Sebagai contoh, sistem pengindeksan / mesin pencari internal dan DBMS yang produktif.

Kontrol IO Jaringan

Network IO Control adalah teknologi untuk membatasi "tetangga yang bising", mesin prioritas rendah dengan beban jaringan tinggi.

Integrasi Penyimpanan (VAAI dll)

Dua kategori teknologi termasuk dalam bagian integrasi:

• Integrasi sistem manajemen virtualisasi dengan sistem manajemen penyimpanan dapat sangat menyederhanakan pemilihan dan penyajian volume / balon penyimpanan ke hypervisor, mengurangi risiko kesalahan dan kompleksitas pekerjaan.
• Integrasi Tingkat Protokol - VAAI, ODX. Teknologi ini memungkinkan Anda untuk membongkar subsistem disk, memindahkan sebagian dari beban standar ke pembuangan penyimpanan cerdas. Misalnya, kategori ini mencakup operasi seperti zeroing block, kloning VM, dll. Karena ini, saluran ke sistem penyimpanan diturunkan secara signifikan, dan sistem penyimpanan itu sendiri melakukan operasi disk dengan cara yang lebih optimal.

Keamanan

Mikrosegmentasi

Microsegmentation dari jaringan virtual dalam penggunaan praktis adalah kemampuan untuk membangun firewall terdistribusi virtual yang mengontrol jaringan virtual di dalam host. Sangat meningkatkan keamanan jaringan virtual.

AV tanpa agen

Teknologi mendukung antivirus tanpa agen. Alih-alih diperiksa oleh agen di OS tamu, lalu lintas operasi disk VM diarahkan oleh hypervisor ke VM layanan yang dipilih. Secara signifikan mengurangi beban pada prosesor dan sistem disk, secara efektif membunuh "badai anti-virus".

Sistem Konvergen Hiper

Sistem konvergen, seperti namanya, adalah sistem dengan kombinasi fungsi. Dan dalam hal ini, yang kami maksud adalah kombinasi dari penyimpanan dan eksekusi VM. Tampaknya sederhana, tetapi pemasaran tiba-tiba masuk.

Untuk pertama kalinya dengan istilah sistem konvergen, pemasar masuk ke pasar. Sistem konvergen menjual server klasik biasa + penyimpanan + sakelar. Hanya di bawah satu nomor mitra. Atau mereka bahkan tidak menjual, tetapi sebuah makalah yang disebut "arsitektur referensi" diproduksi. Kami dengan tulus mengutuk pendekatan ini dan beralih ke pertimbangan arsitektur.

Arsitektur

Menjaga konvergensi sebagai prinsip arsitektur, kami memperoleh kombinasi titik penyimpanan dan titik eksekusi VM dalam satu sistem.

Arsitektur terkonvergensi, dengan kata lain, menyiratkan penggunaan layanan perangkat keras yang sama baik untuk mengeksekusi VM dan untuk menyimpannya di disk lokal. Nah, karena harus ada toleransi kesalahan - dalam arsitektur terkonvergensi ada lapisan SDS terdistribusi.

Kami mendapatkan:

• Sistem klasik - perangkat lunak, penyimpanan, switching dan server berasal dari tempat yang berbeda, dikombinasikan oleh tangan pelanggan / integrator. Pisahkan kontrak dukungan.
• Sistem konvergen - semua dari satu sumber, satu dukungan, satu nomor mitra. Jangan bingung dengan perakitan sendiri dari satu vendor.

Dan ternyata istilah untuk arsitektur terkonvergensi kita sudah dipakai. Situasi yang sama persis dengan supervisor.

Hyperconverged System - Sistem konvergen dengan arsitektur konvergen.
Tentu saja, itu bukan tanpa kedatangan kedua pemasar. Sistem konvergen muncul di mana tidak ada kombinasi penyimpanan, tetapi ada node penyimpanan khusus di bawah kendali SDS terdistribusi. Dalam kerangka perang pemasaran, bahkan istilah khusus HCI terpilah (infrastruktur hypervergenic terpilah) muncul. Secara khusus, misalnya, NetApp dengan sistem yang serupa pada awalnya cukup intensif memperjuangkan hak untuk memanggil sistemnya hiper-konvergen, tetapi akhirnya menyerah. NetApp HCI hari ini (akhir 2019) - infrastruktur cloud hybrid.

Opsi implementasi

Karena kenyataan bahwa sistem hyperconverged bekerja dengan virtualisasi, sebenarnya ada dua setengah opsi untuk implementasi.

• 1. Modul kernel. SDS berfungsi sebagai monolit di inti hypervisor, misalnya vSAN + ESXi
• 1.5 Modul bagian induk. SDS berfungsi sebagai layanan sebagai bagian dari bagian induk dari hypervisor, misalnya S2D + Hyper-V
• 2. Mesin virtual. SDS diimplementasikan sebagai mesin virtual khusus pada setiap host. Nutanix, Cisco Hyperflex, HPE Simplivity.

Jelas, selain masalah yang dibahas dengan efek embedding pada kinerja, ada masalah yang sangat penting tentang isolasi dan dukungan dari hypervisor pihak ketiga. Dalam kasus 1, jelas bahwa ini hanya dapat menjadi sistem tunggal dari penyedia hypervisor, sementara 2 berpotensi dapat bekerja di hypervisor apa pun.

Wadah

Virtualisasi kemas, walaupun secara teknis sangat berbeda dari virtualisasi penuh, strukturnya terlihat sangat sederhana. Seperti halnya model jaringan OSI, pertanyaannya adalah level. Virtualisasi kontainer adalah tingkat yang lebih tinggi - pada tingkat lingkungan aplikasi, dan bukan pada fisika.

Tugas utama dari virtualisasi wadah adalah untuk membagi OS menjadi potongan-potongan independen, dari mana aplikasi yang terisolasi tidak dapat saling mengganggu. Virtualisasi penuh dibagi bukan oleh OS, tetapi oleh server fisik.

VM vs Container

Pro dan kontra dari kedua pendekatan ini cukup sederhana dan berlawanan secara langsung.

Virtualisasi penuh (VM) memberikan independensi penuh ke tingkat besi, termasuk OS, disk, dan tumpukan jaringan yang sepenuhnya independen. Di sisi lain, setiap aplikasi, karena kami mematuhi skema 1 aplikasi = 1 server, membutuhkan OS sendiri, disk sendiri dan tumpukan jaringan. yaitu ada banyak pengeluaran sumber daya.

Wadah tersebut memiliki tumpukan disk dan jaringan bersama dengan OS host, dan semuanya menggunakan satu inti pada seluruh server fisik (baik, atau virtual, baru-baru ini), yang secara keseluruhan memungkinkan Anda menghemat sumber daya secara signifikan pada lanskap homogen.

Secara historis, x86 awalnya memiliki wadah untuk semuanya, bersama dengan server fisik. Setelah munculnya virtualisasi penuh, pentingnya kontainer turun secara dramatis selama hampir 15 tahun, dan para VM yang tebal memerintah di dunia perusahaan. Pada saat itu, kontainer menemukan diri mereka di hosters yang menyediakan ratusan jenis server web yang sama, di mana ringannya permintaan. Tetapi dalam beberapa tahun terakhir, sejak sekitar 2015, kontainer telah kembali ke realitas perusahaan dalam bentuk aplikasi cloud-native.

Wadah 0,1

chroot

Prototipe wadah pada tahun 1979 adalah chroot.

“Chroot adalah operasi mengubah direktori root pada sistem operasi mirip Unix. Program yang diluncurkan dengan direktori root yang dimodifikasi hanya akan memiliki akses ke file yang terdapat dalam direktori ini. "

Yaitu pada kenyataannya, isolasi hanya pada tingkat sistem file, jika tidak, itu hanya proses normal dalam OS.

Penjara freebsd

Jauh lebih maju adalah penjara dari BSD gratis, yang muncul pada tahun 1999. Penjara memungkinkan Anda untuk membuat instance OS virtual penuh dengan set aplikasi mereka sendiri dan file konfigurasi berdasarkan FreeBSD dasar. Tentunya ada yang mengatakan - dan apa yang dilakukan penjara dalam wadah, karena ini adalah paravirtualization! Dan mereka akan sebagian benar.

Namun, sebelum virtualisasi penuh (dan variannya dalam bentuk paravirtualization) penjara tidak memiliki kemampuan untuk menjalankan kernel dari versi yang berbeda di VM tamu dan mengelompokkan dengan migrasi VM ke sistem host lain.

Zona solaris

Solaris Zones adalah teknologi virtualisasi sistem operasi (virtualisasi wadah), yang diperkenalkan pada 2004 di Sun Solaris. Prinsip dasarnya adalah overhead virtualisasi yang rendah.

Tidak mendapatkan banyak popularitas, bermigrasi ke OpenSolaris dan distribusi berdasarkan itu, tersedia pada tahun 2019.

Wadah 1.0

Di era container 1.0, dua arah utama containerization telah muncul - ini adalah produk komersial untuk penyedia hosting, dan containerisasi aplikasi.

Virtuozzo / OpenVZ

SWsoft Rusia pada tahun 2001 memperkenalkan versi pertama virtualisasi kontainer Virtuozzo, yang ditujukan untuk pasar penyedia hosting. Karena tekad dan target audiens komersial tertentu, produk ternyata cukup sukses dan mendapatkan popularitas. Secara teknologi, pada tahun 2002, operasi simultan 2500 kontainer pada server 8 prosesor diperlihatkan.

Pada tahun 2005, versi terbuka dari wadah Virtuozzo untuk Linux bernama OpenVZ muncul. Dan hampir menjadi standar emas untuk hosting VPS.

Lxc

LinuX Containers (LXC) adalah virtualisasi kontainer terkenal lainnya berdasarkan ruang nama dan kelompok, yang muncul pada tahun 2008. LinuX mendasari para buruh pelabuhan yang saat ini populer, dll.

Wadah 1.1 (Virtualisasi Aplikasi)

Jika wadah yang tersisa dirancang untuk membagi OS dasar menjadi segmen-segmen, maka mengapa tidak merobek lapisan sistem ini dan kemas dalam satu kotak dengan aplikasi dan dengan semua lingkungannya. Dan kemudian paket siap pakai ini dapat diluncurkan sebagai aplikasi tingkat pengguna biasa.

Aplikasi-v

Microsoft Application Virtualization (App-V), sebelumnya Softricity SoftGrid - teknologi untuk menyimpan aplikasi tertentu (wadah adalah sebaliknya) di kotak pasir yang terisolasi, kemudian Microsoft. Pada tahun 2006, Microsoft mengakuisisi startup Softricity, yang sebenarnya membalikkan kontainer.

Thinapp

VMware ThinApp (sebelumnya Thinstall) adalah produk kontainerisasi aplikasi dari Jilt yang diakuisisi oleh VMware pada 2008. VMware memperkirakan bahwa 90-95% dari semua aplikasi paket di dunia menggunakan teknologi ini.

Wadah 2.0

Sejarah kemunculan kontainer 2.0 sangat terkait dengan perubahan dalam proses pengembangan perangkat lunak. Keinginan bisnis untuk mengurangi parameter penting seperti Time-to-market memaksa pengembang untuk mempertimbangkan kembali pendekatan untuk menciptakan produk perangkat lunak. Metodologi pengembangan Waterfall (siklus rilis panjang, seluruh aplikasi diperbarui) digantikan oleh Agile (siklus rilis pendek, waktu-tetap, komponen aplikasi diperbarui secara independen) dan memaksa pengembang untuk memisahkan aplikasi monolitik menjadi komponen. Sementara komponen aplikasi monolitik masih cukup besar dan tidak banyak dari mereka dapat ditempatkan di mesin virtual, tetapi ketika satu aplikasi terdiri dari puluhan atau ratusan komponen, mesin virtual tidak terlalu cocok. Selain itu, masalah versi perangkat lunak tambahan, perpustakaan, dan dependensi juga muncul, sering kali ada situasi di mana komponen yang berbeda memerlukan versi yang berbeda atau variabel lingkungan yang dikonfigurasi secara berbeda. Komponen seperti itu harus didistribusikan ke mesin virtual yang berbeda, karena hampir tidak mungkin menjalankan beberapa versi perangkat lunak secara bersamaan dalam OS yang sama. Jumlah VM mulai tumbuh seperti longsoran salju. Di sini, wadah muncul di atas panggung, memungkinkan dalam kerangka satu OS tamu untuk membuat beberapa lingkungan terisolasi untuk meluncurkan komponen aplikasi. Kontainer aplikasi memungkinkan Anda untuk melanjutkan segmentasi aplikasi monolitik ke dalam komponen yang lebih kecil dan beralih ke paradigma satu tugas = satu komponen - wadah, ini disebut pendekatan layanan-mikro, dan masing-masing komponen tersebut adalah layanan-mikro.

Wadah di bawah tenda

Jika Anda melihat wadah dengan pandangan sekilas dari administrator sistem, maka ini hanyalah proses Linux yang memiliki pids sendiri, dll. Apa yang memungkinkan untuk mengisolasi proses yang berjalan dalam wadah satu sama lain dan menggunakan sumber daya OS tamu bersama? Dua mekanisme standar hadir dalam kernel dari setiap distribusi Linux modern. Yang pertama, Linux Namespaces, yang memastikan bahwa setiap proses melihat representasi OS sendiri (sistem file, antarmuka jaringan, nama host, dll.) Dan yang kedua, Linux Control Groups (cgroups), membatasi proses untuk mengonsumsi sumber daya OS tamu (CPU, memori) bandwidth jaringan, dll.).

Linux Namespaces

Secara default, setiap sistem Linux mengandung satu namespace tunggal. Semua sumber daya sistem, seperti sistem file, pengidentifikasi proses (ID Proses), pengidentifikasi pengguna (ID Pengguna), antarmuka jaringan milik namespace ini. Tetapi tidak ada yang menghentikan kita dari menciptakan ruang nama tambahan dan mendistribusikan kembali sumber daya sistem di antara mereka.

Ketika proses baru dimulai, itu dimulai dalam namespace, standar sistem, atau salah satu yang dibuat. Dan proses ini hanya akan melihat sumber daya yang tersedia di namespace yang digunakan untuk menjalankannya.

Tetapi tidak semuanya begitu sederhana, setiap proses tidak termasuk dalam satu namespace tunggal, tetapi untuk satu namespace di masing-masing kategori:

• Mount (mnt)
• ID proses (pid)
• Jaringan (bersih)
• Komunikasi antar proses (IPC)
• UTS
• ID pengguna (pengguna)

Setiap jenis namespace mengisolasi grup sumber daya yang sesuai. Sebagai contoh, ruang UTS mendefinisikan nama host dan nama domain yang terlihat oleh proses. Dengan demikian, dua proses dalam OS tamu dapat mengasumsikan bahwa mereka berjalan pada server yang berbeda.

Namespace jaringan menentukan visibilitas antarmuka jaringan, proses di dalamnya hanya akan melihat antarmuka milik namespace ini.

Linux Control Groups (cgroups)

Linux Control Groups (cgroups) adalah mekanisme sistem kernel (Kernel) sistem Linux yang membatasi konsumsi sumber daya sistem melalui proses. Setiap proses atau kelompok proses tidak akan bisa mendapatkan lebih banyak sumber daya (CPU, memori, bandwidth jaringan, dll.) Daripada yang dialokasikan, dan tidak akan dapat menangkap sumber daya "lain" - sumber daya dari proses tetangga.

Docker

Seperti yang dinyatakan di atas, Docker tidak menciptakan wadah seperti itu. Kontainer sudah ada selama bertahun-tahun (termasuk yang berbasis LXC), tetapi Docker membuatnya sangat populer dengan menciptakan sistem pertama yang membuatnya mudah dan sederhana untuk mentransfer kontainer antara mesin yang berbeda. Docker telah menciptakan alat untuk membuat wadah - mengemas aplikasi dan dependensinya, dan menjalankan wadah pada sistem Linux dengan Docker diinstal.

Fitur penting Docker adalah portabilitas tidak hanya aplikasi itu sendiri dan ketergantungannya antara distribusi Linux yang sama sekali berbeda, tetapi juga portabilitas lingkungan dan sistem file. Sebagai contoh, sebuah wadah yang dibuat di CentOS dapat dijalankan pada sistem Ubuntu. Dalam hal ini, di dalam wadah yang diluncurkan, sistem file akan diwarisi dari CentOS, dan aplikasi akan menganggapnya berjalan di atas CentOS. Ini agak mirip dengan gambar OVF dari mesin virtual, tetapi konsep gambar Docker menggunakan lapisan. Ini berarti bahwa ketika memperbarui hanya bagian dari gambar, tidak perlu mengunduh seluruh gambar lagi, cukup untuk mengunduh hanya lapisan yang diubah, seolah-olah gambar OVF dapat memperbarui OS tanpa memperbarui seluruh gambar.

Docker telah menciptakan ekosistem untuk membuat, menyimpan, mentransfer, dan meluncurkan kontainer. Ada tiga komponen utama ke dunia Docker:

• Gambar - gambar, ini adalah entitas yang berisi aplikasi Anda, lingkungan yang diperlukan dan metadata lain yang diperlukan untuk meluncurkan wadah;
• Register - repositori, tempat penyimpanan untuk gambar Docker. Ada berbagai repositori, mulai dari yang resmi - hub.docker.com dan diakhiri dengan yang pribadi yang ditempatkan di infrastruktur perusahaan;
• Containers - sebuah wadah, wadah Linux yang dibuat dari gambar Docker. Seperti disebutkan di atas, ini adalah proses Linux yang berjalan pada sistem Linux dengan Docker diinstal, terisolasi dari proses lain dan OS itu sendiri.

Pertimbangkan siklus hidup wadah. Awalnya, pengembang membuat gambar Docker dengan aplikasinya (docker build command), sepenuhnya dari awal atau menggunakan gambar yang sudah dibuat sebagai dasar (ingat tentang lapisan). Selanjutnya, gambar ini dapat diluncurkan oleh pengembang langsung pada mesinnya sendiri atau dapat ditransfer ke mesin lain - server. Untuk portabilitas, repositori sering digunakan (perintah push buruh pelabuhan) - mereka memuat gambar ke dalam repositori. Setelah itu, gambar dapat diunduh ke mesin atau server lain (docker pull). Akhirnya, buat wadah yang berfungsi (buruh pelabuhan) dari gambar ini.

Kubernetes

Seperti yang telah kami katakan, konsep layanan-mikro berarti membagi aplikasi monolitik menjadi banyak layanan kecil, biasanya melakukan satu fungsi tunggal. Nah, ketika ada puluhan layanan seperti itu, mereka masih dapat dikelola secara manual, misalnya, Docker. Tetapi apa yang harus dilakukan ketika ada ratusan dan ribuan layanan seperti itu? Selain lingkungan industri, Anda memerlukan lingkungan pengujian dan lingkungan tambahan untuk versi produk yang berbeda, yaitu. kalikan dengan 2, dengan 3 atau bahkan lebih. Google juga menghadapi masalah yang sama, para insinyurnya adalah yang pertama menggunakan kontainer dalam skala industri. Jadi Kubernetes (K8s) lahir, dibuat dengan nama Borg di dinding produk Google, kemudian diberikan kepada masyarakat umum dan diganti namanya.

K8s adalah sistem yang membuatnya mudah digunakan, dikelola, dan dipantau aplikasi kemas (microservices). Seperti yang telah kita ketahui, setiap mesin Linux cocok untuk meluncurkan wadah dan wadah diisolasi satu sama lain, dan K8 dapat mengelola server yang berbeda dengan perangkat keras yang berbeda dan di bawah kendali distribusi Linux yang berbeda. Semua ini membantu kita menggunakan perangkat keras yang tersedia secara efektif. Seperti virtualisasi, K8 menyediakan sumber daya bersama untuk meluncurkan, mengelola, dan memantau layanan microser kami.

Karena artikel ini terutama ditujukan untuk insinyur virtualisasi, untuk pemahaman umum tentang prinsip-prinsip operasi dan komponen utama K8, kami sarankan Anda membaca artikel yang menarik paralel antara K8 dan VMware vSphere: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- users-232cc2f69c58

Sejarah Virtualisasi Industri X86

VMware

VMware muncul pada tahun 1998, dimulai dengan pengembangan jenis hypervisor kedua, yang kemudian dikenal sebagai VMware Workstation.

Perusahaan memasuki pasar server pada tahun 2001 dengan dua hypervisor - GSX (Ground Storm X, tipe kedua) dan ESX (Elastic Sky X, tipe pertama). Seiring waktu, prospek tipe kedua dalam aplikasi server telah menjadi jelas, yaitu. Tidak ada Dan GSX berbayar pertama-tama diubah menjadi Server VMware gratis, dan kemudian sepenuhnya berhenti dan dikubur.

Pada tahun 2003, sistem manajemen pusat Pusat Virtual, teknologi vSMP, dan migrasi langsung mesin virtual muncul.

Pada tahun 2004, VMware diakuisisi oleh EMC, raksasa penyimpanan, tetapi tetap beroperasi secara independen.

Pada tahun 2008, menjadi standar industri de facto, VMware menstimulasi pertumbuhan pesat penawaran kompetitif - Citrix, Microsoft, dll. Menjadi jelas kebutuhan untuk mendapatkan versi gratis dari hypervisor, yang tidak mungkin - karena bagian induk dalam ESX menggunakan RHEL yang cukup komersial. Proyek untuk mengganti RHEL dengan sesuatu yang lebih mudah dan gratis diimplementasikan pada 2008 dengan sistem busybox. Hasilnya adalah ESXi, yang diketahui semua hari ini.

Secara paralel, perusahaan berkembang melalui proyek-proyek internal dan akuisisi startup. Beberapa tahun yang lalu, daftar produk VMware mengambil beberapa halaman A4, jadi katakan saja. VMware untuk 2019 masih merupakan standar de facto di pasar virtualisasi penuh korporat di lokasi dengan pangsa pasar lebih dari 70% dan pemimpin teknologi absolut, dan tinjauan terperinci tentang sejarah layak mendapatkan artikel terpisah yang sangat besar.

Connectix

Didirikan pada tahun 1988, Connectix bekerja pada berbagai utilitas sistem hingga mengambil virtualisasi. Pada tahun 1997, produk VirtualPC pertama untuk Apple Macintosh dibuat, memungkinkan Windows untuk berjalan di mesin virtual. Versi pertama VirtualPC untuk Windows muncul pada tahun 2001.

Pada tahun 2003, Microsoft membeli VirtualPC dan, berdasarkan perjanjian dengan Connectix, para pengembang beralih ke Microsoft. Setelah itu, Connectix ditutup.

Format VHD (virtual hard disk) dikembangkan oleh Connectix untuk VirtualPC, dan sebagai pengingat, disk virtual mesin Hyper-V berisi "conectix" dalam tanda tangan mereka.
VIrtual PC, seperti yang Anda duga, adalah hypervisor desktop klasik dari tipe kedua.

Microsoft

Perjalanan Microsoft ke dalam virtualisasi industri dimulai dengan pembelian Connectix dan rebranding Connectix Virtual PC di Microsoft Virtual PC 2004. Virtual PC dikembangkan untuk sementara waktu, dimasukkan dengan nama Windows Virtual PC di Windows 7. Di Windows 8 dan kemudian, Virtual PC digantikan oleh versi desktop Hyper-V.

Berdasarkan pada PC Virtual, hypervisor server Server Virtual telah dibuat, yang ada hingga awal 2008. Karena kerugian teknologi yang jelas sebelum VMware ESX, diputuskan untuk mengurangi pengembangan tipe kedua hypervisor demi jenis hypervisor pertama, yang menjadi Hyper-V. Ada pendapat tidak resmi di industri bahwa Hyper-V secara mengejutkan mirip dengan Xen dalam arsitektur. Kira-kira sama dengan .Net di Jawa.

"Tentu saja, Anda mungkin berpikir bahwa Microsoft mencuri ide Java." Tapi ini tidak benar, Microsoft menginspirasinya! - (dari pidato oleh perwakilan Microsoft pada presentasi Windows 2003 Server)

Dari saat-saat yang aneh, dapat dicatat bahwa di dalam Microsoft, penggunaan produk-produk virtualisasi eksklusif dalam nol tahun adalah, secara sederhana, opsional. Ada tangkapan layar Technet dari artikel tentang virtualisasi, di mana logo VMware Tools jelas ada di baki. Juga, Mark Russinovich di Platform 2009 di Moskow melakukan demonstrasi dengan VMware Workstation.

Dalam upaya untuk memasuki pasar baru, Microsoft menciptakan cloud publiknya sendiri, Azure, menggunakan Server Nano yang sangat dimodifikasi dengan dukungan Hyper-V, S2D, dan SDN sebagai platformnya. Perlu dicatat bahwa pada awalnya, Azure di beberapa titik jauh di belakang sistem on-premise. Misalnya, dukungan untuk mesin virtual generasi kedua (dengan dukungan untuk Boot Aman, boot dari partisi GPT, boot PXE, dll.) Muncul di Azure hanya pada 2018. Sementara di On-Premise, VM generasi kedua sudah dikenal sejak Windows Server 2012R2. Hal yang sama berlaku untuk solusi portal: hingga 2017, Azure dan Windows Azure Pack (solusi cloud Multi-Tenancy dengan dukungan SDN dan Shielded VM, yang menggantikan System Center App Controller pada 2013) menggunakan desain portal yang sama. Setelah Microsoft mengumumkan kursus tentang cloud publik, Azure melangkah maju untuk mengembangkan dan mengimplementasikan berbagai pengetahuan. Sekitar tahun 2016, Anda dapat mengamati gambar yang sepenuhnya logis: sekarang semua inovasi di Windows Server berasal dari Azure, tetapi tidak dengan arah yang berlawanan. Fakta menyalin bagian-bagian dokumentasi dari Azure ke tempat "sebagaimana adanya" menunjukkan ini (lihat dokumentasi tentang Azure SDN dan Pengontrol Jaringan), yang di satu sisi mengisyaratkan sikap terhadap solusi di tempat, dan di sisi lain, menunjukkan hubungan solusi dalam hal entitas dan arsitektur. Siapa yang menyalin dari siapa dan bagaimana sebenarnya - pertanyaan yang bisa diperdebatkan.

Pada bulan Maret 2018, Satya Nadela (CEO Microsoft) secara resmi mengumumkan bahwa cloud publik menjadi prioritas perusahaan. Yang, jelas, melambangkan pelipatan bertahap dan memudar dari garis server untuk produk di tempat (namun, stagnasi diamati pada tahun 2016, tetapi dikonfirmasi dengan beta Windows Server pertama dan lini produk di tempat lainnya), dengan pengecualian Azure Edge - server minimum yang diperlukan Infrastruktur di kantor pelanggan untuk layanan yang tidak dapat dibawa ke cloud.

Setrika virtual

Didirikan pada tahun 2003, Virtual Iron menawarkan versi komersial Xen dan merupakan salah satu yang pertama menawarkan pasar dukungan virtualisasi perangkat keras penuh.
Pada 2009, Oracle diambil alih untuk mengembangkan lini virtualisasi sendiri Oracle VM dan memperluasnya di x86. Sebelum ini, Oracle VM hanya ditawarkan pada platform SPARC.

Innotek

Pada awal 2007, Innotek GmbH merilis hypervisor desktop jenis kedua, VirtualBox, yang gratis untuk penggunaan non-komersial. Pada tahun yang sama, versi open source dirilis.

Pada 2008, diakuisisi oleh Sun, yang pada gilirannya diakuisisi oleh Oracle. Oracle telah mempertahankan penggunaan produk secara gratis untuk tujuan non-komersial.
VirtualBox mendukung tiga format disk virtual - VDI (asli), VMDK (VMware), VHD (Microsoft). Sebagai host OS, Windows, macOS, Linux, Solaris dan OpenSolaris didukung. Garpu VirtualBox untuk FreeBSD dikenal.

Ibm

Mainframe adalah komputer utama dari pusat data dengan sejumlah besar memori internal dan eksternal (untuk referensi: pada 60-an, 1MB memori dianggap sangat besar). Sebenarnya, mainframe adalah pusat komputasi: komputer pertama menempati seluruh ruang mesin dan terdiri dari rak besar. Saat ini disebut pusat data. Tetapi di pusat data di ruang mesin yang sama bisa ribuan komputer, dan pada awal teknologi komputasi, satu komputer menempati seluruh ruangan. Setiap rak menjual satu (!) Perangkat komputer (rak terpisah dengan memori, rak terpisah dengan perangkat penyimpanan, dan perangkat periferal terpisah). Inti dari mesin besar ini adalah rak dengan prosesor - itu disebut mainframe.Setelah beralih ke sirkuit terpadu transistor, ukuran keajaiban pemikiran ilmiah dan teknik ini menurun secara signifikan, dan mainframe IBM dan analognya mulai dipahami sebagai mainframe.

Pada 60-an abad XX, sewa daya komputasi seluruh mainframe, belum lagi pembeliannya, menghabiskan banyak uang. Sangat sedikit perusahaan dan institusi yang mampu mendapatkan kemewahan seperti itu. Menyewa daya komputasi adalah setiap jam (prototipe Pay modern saat Anda menjadi model di cloud publik, bukan?). Akses ke penyewa untuk komputasi diberikan secara berurutan. Solusi logis adalah untuk memaralelkan beban komputasi dan mengisolasi perhitungan penyewa satu sama lain.

Untuk pertama kalinya, gagasan mengisolasi beberapa mesin virtual pada satu kerangka kerja diusulkan oleh IBM Cambridge Science Centre berdasarkan pada kerangka sistem IBM / 360-67. Pengembangan itu disebut CP / CMS dan, pada kenyataannya, adalah hypervisor pertama dan menyediakan paravirtualization. CP (Program Kontrol) - hypervisor itu sendiri, yang menciptakan beberapa "mesin virtual" (VM) independen. CMS (awalnya Cambridge Monitor System, kemudian berganti nama menjadi Conversational Monitor System) adalah sistem operasi single-user yang ringan. Anehnya, CMS masih hidup dan masih digunakan pada generasi terbaru dari mainframe z / VM. Perlu dicatat bahwa pada waktu itu dan hingga tahun 90-an, mesin virtual berarti pemisahan logis dari disk fisik (disk atau perangkat penyimpanan dibagikan,hypervisor tidak menyediakan penyimpanan untuk kebutuhannya sendiri) dengan memori virtual khusus dan waktu prosesor menggunakan teknologi Time-Sharing. VM tidak menyediakan interaksi jaringan, karena VM saat itu adalah tentang komputasi dan menyimpan data, dan bukan tentang mentransfernya. Dalam hal ini, VM pada saat itu lebih seperti wadah daripada VM dalam arti modern.

Hypervisor komersial pertama berdasarkan CP / CMS, yang disebut VM / 370, muncul pada mainframe seri System / 370 pada 2 Agustus 1972. Nama umum keluarga sistem operasi ini adalah VM, dan sebagai bagian dari bagian ini, VM akan dipahami sebagai hypervisor IBM. Kemampuan untuk menjalankan beberapa sistem operasi secara bersamaan, menjamin stabilitas sistem dan mengisolasi pengguna dari satu sama lain (kesalahan dalam OS satu pengguna tidak dapat mempengaruhi perhitungan pengguna lain) - bersifat revolusioner dan menjadi faktor kunci dalam keberhasilan komersial VM / 370. Fakta yang aneh: pada saat itu di Uni Soviet upaya dari Lembaga Penelitian Ilmiah Ilmu Komputer (Minsk) sangat berhasil mengkloning arsitektur System / 370 dan membuat sendiri VM / 370 analog dengan nama komputer UE (dengan dukungan untuk virtualisasi tertanam! - untuk kemungkinan mengembangkan OS paling dasar).Mainframe semacam itu digunakan oleh lembaga penelitian dan perusahaan pertahanan di kubu sosialis.

Tahun 80-an dapat dengan aman disebut sebagai "era mainframe." VM sukses dengan pengembang sistem operasi, aplikasi ditulis untuk itu dan perhitungan dibuat. Ini adalah dekade ketika pangsa basis data yang didominasi oleh VM OS mulai berlaku di mainframe. Salah satu perubahan terpenting adalah Sumber Akses Partisi Logikal (LPAR), yang sebenarnya menyediakan dua tingkat virtualisasi. Klien sekarang dapat menggunakan serangkaian prosesor, perangkat I / O yang sama, dan modem dalam sistem VM yang berjalan di LPAR yang berbeda dan memungkinkan sumber daya untuk dimigrasi dari satu sistem VM ke yang lain. Ini memungkinkan organisasi TI untuk memberikan kinerja yang konsisten saat memproses lonjakan beban kerja. Untuk merampingkan basis pelanggan yang berkembang, VM dibagi menjadi tiga produk terpisah,tersedia di akhir 80-an:

VM / SP - sistem operasi virtualisasi multi guna biasa untuk server System z
HPO (Opsi Kinerja Tinggi) - VM / SP berkinerja tinggi untuk model server System z yang lebih lama
VM / XA (arsitektur tambahan) - Varian VM dengan dukungan untuk arsitektur S / S yang diperluas 370

Pada awal 90-an, kesederhanaan dan kenyamanan arsitektur x86 menjadi lebih menarik bagi pelanggan, dan mainframe dengan cepat kehilangan relevansi. Mainframe telah digantikan oleh sistem cluster, seperti grunge, yang menggantikan logam glam secara bersamaan. Namun, untuk kelas tugas tertentu, misalnya, ketika membangun gudang data terpusat, mainframe membenarkan diri mereka sendiri dalam hal produktivitas dan dari sudut pandang ekonomi. Karena itu, beberapa perusahaan masih menggunakan mainframe dalam infrastruktur mereka, dan IBM merancang, merilis, dan mendukung generasi baru.

Linux Xen

Xen (diucapkan zen) adalah hypervisor yang dikembangkan di University of Cambridge Computer Lab di bawah arahan Ian Pratt dan didistribusikan di bawah GPL. Versi publik pertama muncul pada tahun 2003. Selanjutnya, Ian terus bekerja pada hypervisor dalam versi komersialnya, mendirikan perusahaan XenSource.
Pada 2013, Xen berada di bawah kendali Linux Foundation.

XenSource

Telah ada selama beberapa tahun di pasar dengan produk XenServer dan XenEnterprise, pada akhir 2007 diakuisisi oleh Citrix.

Citrix XenServer

Setelah menyerap XenSource sebesar $ 500 juta, Citrix tidak dapat mengkomersialkan masalah ini. Lebih tepatnya, saya tidak benar-benar mencoba melakukannya, tidak menganggap XenServer sebagai produk utama, dan mengandalkan murahnya lisensi permanen. Setelah penjualan yang gagal di tengah-tengah VMware ESX yang sangat sukses, diputuskan untuk merilis XenServer ke dunia secara gratis dan dengan open source penuh pada tahun 2009. Namun, kode sistem manajemen kepemilikan XenCenter tidak terbuka.
Perlu dicatat suatu kebetulan kronologis yang menarik dari inisiatif Citrix dan Microsoft di bidang virtualisasi industri, meskipun pada kenyataannya perusahaan selalu sangat dekat.

Terlepas dari nama pemasaran mereka yang umum, Citrix XenApp dan XenDesktop tidak ada hubungannya dengan hypervisor Xen.

Amazon

Amazon memperkenalkan penawaran cloud IaaS publik yang disebut EC2 (Elastic Compute) pada tahun 2006. Awalnya, platform EC2 menggunakan hypervisor Xen, dan kemudian Amazon membagi platform menjadi tiga bagian, yang masing-masing menggunakan cabang terpisah dan versi hypervisor untuk meminimalkan efek kesalahan dalam kode pada ketersediaan layanan.

Pada 2017, KVM untuk beban berat muncul sebagai hypervisor tambahan di EC2. Ada pendapat bahwa ini mengindikasikan transfer bertahap EC2 ke KVM sepenuhnya di masa depan.

Linux QEMU / KVM

QEMU (Quick EMUlator) adalah perangkat lunak universal untuk meniru perangkat keras dari berbagai platform, didistribusikan di bawah lisensi GPL v2. Selain x86, ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64 juga didukung. Dengan fleksibilitas platform dengan virtualisasi penuh, QEMU tidak memiliki kinerja yang sebanding dengan sistem non-virtual. Untuk mempercepat kerja QEMU pada x86, dua opsi utama ditawarkan, yang akhirnya ditolak demi pengembangan KVM (Mesin Virtual Berbasis Kernel) Qumranet.

Kami katakan KVM - maksud kami QEMU KVM, dan karenanya kami mendapatkan format disk virtual qcow2 (QEMU copy-on-write 2) untuk semua platform berdasarkan hypervisor KVM.
Meskipun QEMU awalnya berfungsi sebagai tipe kedua dari hypervisor, QEMU / KVM adalah tipe pertama dari hypervisor.

Qumranet

Perusahaan Israel, mantan pengembang dan sponsor utama hypervisor KVM dan protokol SPICE. Didirikan pada tahun 2005, memperoleh ketenaran setelah memasukkan KVM ke dalam kernel Linux. 4 September 2008, diakuisisi oleh Red Hat.

Topi merah

Seperti semua produsen distribusi GNU / Linux, hingga 2010, Red Hat memiliki dukungan bawaan untuk hypervisor Xen dalam distribusi mereka. Namun, sebagai pemain utama di pasar dan merek yang serius, saya memikirkan implementasi hypervisor saya sendiri. Dasarnya kemudian diambil oleh hypervisor KVM yang biasa-biasa saja, tetapi menjanjikan. Versi pertama Red Hat Enterprise Virtualization 2.2 (RHEV) diperkenalkan pada 2010 dengan klaim untuk bersaing memperebutkan pasar solusi VDI dengan Citrix dan VMware karena pengembangan Qumranet, yang diakuisisi dua tahun sebelumnya. Di luar kotak, kluster ketersediaan tinggi, Live Migration, dan alat migrasi M2M (khusus RHEL) tersedia. Perlu dicatat bahwa, dilihat dari dokumentasi pada waktu itu, Red Hat mempertahankan notasi Xen ketika menggambarkan arsitektur solusi.

Pada 28 Oktober 2018, IBM mengumumkan pembelian Red Hat.

Openstack

Secara historis, proyek OpenStack muncul sebagai sebuah inisiatif untuk membandingkan sesuatu dengan monopoli aktual VMware di bidang virtualisasi server berat x86. Proyek ini muncul pada 2010 berkat upaya bersama Rackspace Hosting (penyedia cloud) dan NASA (yang membuka kode untuk platform Nebula sendiri). Kesedihan situasi ini diberikan oleh fakta bahwa pada tahun 2012 VMware bergabung dengan manajemen proyek OpenStack dan menyebabkan gelombang kemarahan di antara para aktivis pendiri.

Seiring waktu, Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle bergabung dengan proyek ini.

Namun, tidak semuanya lancar. Pada 2012, NASA meninggalkan proyek, memilih AWS. Pada awal 2016, HPE benar-benar menutup proyek Helion berdasarkan OpenStack.

Sebagai bagian dari proyek OpenStack, KVM telah diadopsi sebagai hypervisor standar. Namun, karena modularitas dari pendekatan tersebut, sistem berbasis OpenStack dapat diimplementasikan menggunakan hypervisor lain, meninggalkan, misalnya, hanya sistem kontrol dari OpenStack.

Ada banyak pendapat mengenai proyek OpenStack, dari ibadat antusias hingga skeptisisme serius dan kritik keras. Kritik itu bukannya tanpa alasan - sejumlah besar masalah dan kehilangan data dicatat saat menggunakan OpenStack. Yang, bagaimanapun, tidak menghentikan penggemar dari menyangkal segalanya dan mengacu pada kelengkungan dalam implementasi dan pengoperasian sistem.

Proyek OpenStack tidak terbatas hanya pada virtualisasi, tetapi seiring waktu telah berkembang menjadi sejumlah besar berbagai sub-proyek dan komponen untuk ekspansi di bidang tumpukan layanan cloud publik. Selain itu, pentingnya OpenStack mungkin harus dievaluasi secara tepat di bagian ini - komponen ini telah menjadi kunci dalam banyak produk dan sistem komersial baik di bidang virtualisasi dan seterusnya.

Di Rusia, OpenStack di luar cloud publik sebagian besar dikenal terutama karena perannya dalam substitusi impor. Sebagian besar solusi dan produk virtualisasi, termasuk sistem hyperconverged, dikemas oleh OpenStack dengan berbagai tingkat penyempurnaan.

Nutanix AHV

Sejak awal, Nutanix telah menjadi produk dan platform khusus untuk VMware vSphere. Namun, sebagian karena keinginan untuk memperluas tawaran untuk hypervisor lain, sebagian karena krisis politik dalam hubungan dengan VMware, diputuskan untuk mengembangkan hypervisor mereka sendiri yang akan melengkapi platform kotak dan memungkinkan untuk meninggalkan produk pihak ketiga. KVM dipilih sebagai hypervisor sendiri, yang dalam kerangka platform disebut AHV (Acropolis HyperVisor).

Paralel

Dalam Virtuozzo versi 7, perusahaan beralih dari hypervisor sendiri ke KVM.

Proxmox

Proxmox VE (Virtual Environment) adalah proyek open source dari perusahaan Austria Proxmox Server Solutions GmbH yang berbasis di Debian Linux. Rilis pertama adalah pada tahun 2008.
Produk ini mendukung virtualisasi wadah LXC (sebelumnya OpenVZ), dan virtualisasi penuh dengan hypervisor KVM.

Parallels / Virtuozzo / Rosplatform

Didirikan pada tahun 1999 oleh Sergey Belousov, SWsoft mengambil perangkat lunak manajemen hosting. Pada tahun 2003, perusahaan saingan Novosibirsk Plesk diakuisisi.

Pada tahun 2004, SWsoft mengakuisisi perusahaan Rusia Parallels Nikolai Dobrovolsky dengan produknya Parallels Workstation (desktop hypervisor dari tipe kedua di bawah Windows).
Perusahaan gabungan mempertahankan namanya Parallels dan akan segera meledak pasar dengan Parallels Desktop for Mac (hypervisor desktop tipe kedua untuk MacOS).

Sebagai bagian dari virtualisasi server, fokus berlanjut pada penyedia hosting dan pusat data, daripada penggunaan perusahaan. Karena kekhasan pasar khusus ini, kontainer Virtuozzo dan OpenVZ, dan bukannya mesin virtual sistem, menjadi produk utama. Selanjutnya, Parallels, tanpa banyak keberhasilan, mencoba memasuki pasar virtualisasi server perusahaan dengan produk Parallels Bare Metal Server (kemudian Parallels Hypervisor dan Cloud Server, dan kemudian Virtuozzo), menambah hyper-konvergensi dengan Cloud Storage-nya. Pekerjaan berlanjut pada otomatisasi dan pengaturan penyedia hosting.

Pada 2015, berdasarkan produk virtualisasi server, proyek platform Rosplatform dibuat - secara teknis (menghilangkan masalah hukum dan organisasi) Virtuozzo yang sama, hanya dengan wallpaper yang dimodifikasi dan dalam registri perangkat lunak Rusia. Berdasarkan pada perangkat lunak platform Rosplatform dan peralatan Depo, IBS menciptakan tawaran paket scala-R hyperconverged.

Sebelum versi 7, Virtuozzo menggunakan hypervisor dari desainnya sendiri, dalam versi 7, transisi ke KVM dibuat. Karenanya, Rosplatform juga didasarkan pada KVM.
Setelah beberapa merger, akuisisi, dan rebranding, gambar berikutnya dibentuk pada 2019.

Parallels Desktop adalah anak perusahaan dari Parallels dan dijual ke Corel. Semua otomatisasi pergi ke Odin dan dijual ke IngramMicro. Virtualisasi server tetap berada di bawah merek platform Virtuozzo / Rosplatform.