În anteriorul au fost luate în considerare opțiunile cu care ar putea fi înlocuite sistemele existente ca parte a implementării ordinului de substituire a importurilor. Următoarele articole se vor concentra pe selectarea anumitor produse care să le înlocuiască pe cele implementate în prezent. Să începem cu punctul de plecare - sistemul de virtualizare.
1. Agonia alegerii
Deci, din ce poți alege? ÎN :
- Sistem de virtualizare server "R-Virtualizarea» (libvirt, KVM, QEMU)
- Pachete software "Instrumente de virtualizare Brest» (libvirt, KVM, QEMU)
- Platformă pentru gestionarea și monitorizarea mediului de virtualizare „Sharx Stream” (o soluție cloud care nu este potrivită pentru birourile guvernamentale în 95% din cazuri (secret etc.)
- Pachet software pentru virtualizarea serverelor, desktop-urilor și aplicațiilor "HOST" (KVM x86)
- Sistem de management securizat al mediului de virtualizare "Z|virt"(alias oVirt+KVM)
- Sistem de management al mediului de virtualizare"Virtualizare ROSA"(alias oVirt+KVM)
- Hypervisor QP VMM (prea similar cu Oracle Virtual Box pentru a fi altceva)
De asemenea, puteți lua în considerare hipervizorii incluși în distribuția OS sau aflați în depozitul lor. De exemplu, Astra Linux are suport KVM. Și, deoarece este inclus în arhivele OS, poate fi considerat „legitim” pentru instalare și utilizare. „Ce poate fi folosit ca parte a substituirii importurilor și ce nu” a fost discutat anterior , așa că nu mă voi opri asupra acestei probleme.
De fapt, aici :
- VirtualBox
- Virt-manager (KVM) Curentul vultur
- libvirt prin KVM
ROSA Linux nu are o astfel de listă, dar o găsiți pe wiki :
- Virtualizare ROSA peste oVirt peste KVM
- QEMU prin KVM
- oVirt 3.5 prin KVM
Calculate are asta
Alt Linux are același lucru
1.2. Există un DAR
La o examinare mai atentă, ajungem la concluzia că va trebui să avem de-a face cu doar câțiva hipervizori bine-cunoscuți, și anume:
QEMU este un program gratuit și open source pentru emularea hardware-ului diverselor platforme, care poate funcționa fără a utiliza KVM, dar utilizarea virtualizării hardware accelerează semnificativ performanța sistemelor oaspeți, astfel încât utilizarea KVM în QEMU (-enable-kvm) este opțiunea preferată. (c) Adică, QEMU este un hypervisor de tip 2, ceea ce este inacceptabil într-un mediu de produs. Cu KVM poate fi folosit, dar în acest caz QEMU va fi folosit ca instrument de management KVM...
Folosind originalul VirtualBox în comerţ este de fapt : „Începând cu versiunea 4, lansată în decembrie 2010, partea principală a produsului este distribuită gratuit sub licența GPL v2. Un pachet suplimentar instalat deasupra acestuia, care oferă suport pentru dispozitivele USB 2.0 și 3.0, protocolul RDP (Remote Desktop Protocol), criptarea unității, pornirea de pe NVMe și PXE, este distribuit sub o licență PUEL specială („pentru uz personal și evaluare”) , conform căruia sistemul este gratuit pentru uz personal, în scopuri de instruire sau pentru evaluare înainte de a decide să achiziționeze versiunea comercială." (c) Plus VirtualBox este, de asemenea, un hypervisor de tip 2, deci dispare și el.
Total: în forma sa pură avem doar KVM.
2. Restul: KVM sau KVM?
Dacă totuși trebuie să treceți la un hypervisor „domestic”, alegerea dvs., sincer vorbind, este mică. Va fi KVM într-un wrapper sau altul, cu anumite modificări, dar tot va fi KVM. Dacă acest lucru este bun sau rău este o altă întrebare; încă nu există alternativă.
Dacă condițiile nu sunt atât de stricte, atunci, așa cum sa discutat anterior : „Trebuie să aducem indicatorii la limitele stabilite. De fapt, asta înseamnă că trebuie să înlocuim sistemul de operare existent cu produse din registrul Ministerului Telecomunicațiilor și Comunicațiilor de Masă și să creștem numărul de sisteme de operare înlocuite la 80%.... Deci, putem lăsa în siguranță clusterul pe Hyper-V , din moment ce îl avem și ne place... „(c) Așa că ne confruntăm cu o alegere: Microsoft Hyper-v sau KVM. KVM poate cu comenzile „înșurubate”, dar va rămâne în continuare la fel KVM.
Aceste produse sunt departe de a fi comparabile Nu Nu ...Ei bine, înțelegi...
Despre implementare și configurare KVM nu a fost scris la fel Nu Nu nu ... Intr-un cuvant, .
Același lucru este valabil și pentru
Nu văd niciun rost să mă repet și să descriu aceste sisteme, să compar etc. Puteți, desigur, să scoateți puncte cheie din articole, dar acest lucru ar fi lipsit de respect față de autori, cred. Cine trebuie să aleagă va citi nu numai asta, ci și un munte de informații pentru a se decide.
Singura diferență pe care vreau să mă concentrez este clusteringul de failover. Dacă Microsoft are acest lucru încorporat în funcționalitatea sistemului de operare și hypervisor, atunci în cazul KVM va trebui să utilizați software terță parte, care ar trebui să fie inclus în arhivele OS. Aceeași combinație de Corosync+Pacemaker, de exemplu. (Aproape toate sistemele de operare autohtone au această combinație... poate toate, dar nu le-am verificat 100%.) Manualele pentru configurarea grupării sunt, de asemenea, disponibile din abundență.
3. Concluzie
Ei bine, ca de obicei, Kulibins noștri nu s-au deranjat, au luat ceea ce aveau, au adăugat puțin de-al lor și au produs un „produs” care, conform documentelor, este autohton, dar în realitate este OpenSource. Are sens să cheltuiți bani din buget pe sisteme de virtualizare „separate” (a se citi: nu este inclus în sistemul de operare)? Nu te gândi. Deoarece veți primi în continuare același KVM, va trebui doar să plătiți pentru el.
Astfel, alegerea unui înlocuitor pentru un hypervisor se reduce la ce sistem de operare server veți cumpăra pentru Enterprise și veți opera. Sau, ca în cazul meu, vei rămâne cu ceea ce ai deja (Hyper-VESXi insert_needed).
Sursa: www.habr.com