Nel precedente sono state prese in considerazione le opzioni con cui sostituire i sistemi esistenti nell'ambito dell'attuazione dell'ordine di sostituzione delle importazioni. I seguenti articoli si concentreranno sulla selezione di prodotti specifici per sostituire quelli attualmente distribuiti. Cominciamo dal punto di partenza: il sistema di virtualizzazione.
1. L'agonia della scelta
Quindi, cosa puoi scegliere? IN :
- Sistema di virtualizzazione dei server"R-virtualizzazione» (libvirt, KVM, QEMU)
- Pacchetto software "Strumenti di virtualizzazione di Brest» (libvirt, KVM, QEMU)
- Piattaforma per la gestione e il monitoraggio dell'ambiente di virtualizzazione "Streaming Sharx" (una soluzione cloud che nel 95% dei casi non è adatta agli uffici governativi (segretezza, ecc.)
- Pacchetto software per la virtualizzazione di server, desktop e applicazioni "HOST" (KVMx86)
- Sistema per la gestione sicura dell'ambiente di virtualizzazione"Z|virt"(noto anche come oVirt+KVM)
- Sistema di gestione dell'ambiente di virtualizzazione "ROSA Virtualizzazione"(noto anche come oVirt+KVM)
- Hypervisor QPVMM (troppo simile a Oracle Virtual Box per essere qualcos'altro)
Puoi anche prendere in considerazione gli hypervisor inclusi nella distribuzione del sistema operativo o che si trovano nei loro repository. Ad esempio, Astra Linux ha il supporto KVM. E poiché è incluso nei repository del sistema operativo, può essere considerato “legittimo” per l'installazione e l'utilizzo. “Cosa può essere utilizzato come parte della sostituzione delle importazioni e cosa no” è stato discusso in precedenza , quindi non mi soffermerò su questo argomento.
In effetti, qui :
- VirtualBox
- gestore virtuale (KVM) Corrente dell'Aquila
- libvirt su KVM
ROSA Linux non ha un elenco di questo tipo, ma puoi trovarlo sul wiki :
- ROSA Virtualizzazione su oVirt su KVM
- QEMU su KVM
- oVirt 3.5 su KVM
Calcola ha questo
Alt Linux ha lo stesso
1.2. Ce n'è uno MA
Ad un esame più attento, concludiamo che avremo a che fare solo con alcuni hypervisor ben noti, vale a dire:
QEMU è un programma gratuito e open source per emulare hardware di varie piattaforme, che può funzionare senza utilizzare KVM, ma l'utilizzo della virtualizzazione hardware accelera significativamente le prestazioni dei sistemi guest, quindi l'utilizzo di KVM in QEMU (-enable-kvm) è l'opzione preferita. (c) Cioè, QEMU è un hypervisor di tipo 2, il che è inaccettabile in un ambiente di prodotto. Può essere utilizzato con KVM, ma in questo caso QEMU verrà utilizzato come strumento di gestione KVM...
Utilizzando l'originale VirtualBox in commercio è in realtà : “A partire dalla versione 4, rilasciata nel dicembre 2010, la maggior parte del prodotto è distribuita gratuitamente sotto la licenza GPL v2. Un pacchetto aggiuntivo installato sopra di esso, che fornisce supporto per dispositivi USB 2.0 e 3.0, Remote Desktop Protocol (RDP), crittografia delle unità, avvio da NVMe e PXE, è distribuito con una speciale licenza PUEL ("per uso personale e valutazione") , in base al quale il sistema è gratuito per uso personale, per scopi di formazione o per valutazione prima di decidere di acquistare la versione commerciale." (c) Inoltre VirtualBox è anche un hypervisor di tipo 2, quindi scompare anche lui.
Totale: nella sua forma pura abbiamo solo KVM.
2. Il resto: KVM o KVM?
Se hai ancora bisogno di passare a un hypervisor “domestico”, la tua scelta, francamente, è piccola. Sarà KVM in un involucro o nell'altro, con alcune modifiche, ma sarà comunque KVM. Se questo sia un bene o un male è un’altra questione: non c’è ancora alcuna alternativa.
Se le condizioni non sono così rigide, allora, come discusso in precedenza : “Bisogna riportare gli indicatori entro i limiti stabiliti. In realtà, ciò significa che dobbiamo sostituire il sistema operativo esistente con prodotti del registro del Ministero delle Telecomunicazioni e delle Comunicazioni di massa e aumentare il numero di sistemi operativi sostituiti all'80%.... Quindi, possiamo tranquillamente lasciare il cluster su Hyper-V , visto che ce l'abbiamo e ci piace...” (c) Ci troviamo quindi di fronte ad una scelta: Microsoft Hyper-v o KVM. KVM magari con i controlli “avvitati”, ma resterà comunque lo stesso KVM.
Questi prodotti sono tutt’altro che paragonabili Non Non ...Beh, hai capito...
Informazioni sulla distribuzione e sulla configurazione KVM non è stato scritto allo stesso modo Non Non e ... In una parola, .
Lo stesso vale per
Non vedo il motivo di ripetermi e descrivere questi sistemi, confrontare, ecc. Ovviamente puoi estrarre i punti chiave dagli articoli, ma credo che questo sarebbe irrispettoso nei confronti degli autori. Chi dovrà scegliere leggerà non solo questo, ma anche una montagna di informazioni per prendere una decisione.
L'unica differenza su cui voglio concentrarmi è il clustering di failover. Se Microsoft lo ha integrato nel sistema operativo e nella funzionalità dell'hypervisor, nel caso di KVM dovrai utilizzare software di terze parti, che dovrebbe essere incluso nei repository del sistema operativo. La stessa combinazione di Corosync+Pacemaker, per esempio. (Quasi tutti i sistemi operativi domestici hanno questa combinazione... forse tutti, ma non li ho controllati al 100%.) Sono disponibili in abbondanza anche manuali per l'impostazione del clustering.
3. Conclusione
Ebbene, come al solito, i nostri Kulibin non si sono preoccupati, hanno preso quello che avevano, hanno aggiunto un po' del loro e hanno prodotto un "prodotto" che, secondo i documenti, è domestico, ma in realtà è OpenSource. Ha senso spendere soldi dal budget per sistemi di virtualizzazione “separati” (leggi: non inclusi nel sistema operativo)? Non pensare. Poiché riceverai comunque lo stesso KVM, dovrai solo pagarlo.
Pertanto, la scelta di un sostituto per un hypervisor dipende dal sistema operativo del server che acquisterai per l'azienda e che utilizzerai. Oppure, come nel mio caso, rimarrai con quello che già hai (Hyper-VESXi insert_needed).
Fonte: habr.com