A substitución de importacións na práctica. Parte 2. Inicio. Hipervisor

No anterior Artigo consideráronse as opcións polos que se poderían substituír os sistemas existentes como parte da aplicación da orde de substitución de importacións. Os artigos seguintes centraranse na selección de produtos específicos para substituír os que se están a implementar actualmente. Comecemos co punto de partida: o sistema de virtualización.

1. A agonía da elección

Entón, que podes escoller? EN rexistro do Ministerio de Telecomunicacións e Comunicacións de masas hai unha opción:

• Sistema de virtualización de servidores "R-Virtualización» (libvirt, KVM, QEMU)
• paquete de software"Ferramentas de virtualización de Brest» (libvirt, KVM, QEMU)
• Plataforma de xestión e seguimento do contorno de virtualización "Sharx Stream" (unha solución na nube que non é adecuada para oficinas gobernamentais no 95 % dos casos (segredo, etc.)
• Paquete de software para virtualización de servidores, escritorios e aplicacións "HOST" (KVM x86)
• Sistema de xestión segura do entorno de virtualización "Z|virt"(tamén coñecido como oVirt+KVM)
• Sistema de xestión de entornos de virtualización "Virtualización ROSA"(tamén coñecido como oVirt+KVM)
• Hipervisor QP VMM (demasiado semellante a Oracle Virtual Box para ser outra cousa)

Tamén podes ter en conta os hipervisores incluídos na distribución do SO ou localizados nos seus repositorios. Por exemplo, Astra Linux ten soporte KVM. E dado que está incluído nos repositorios do SO, pódese considerar "lexítimo" para a súa instalación e uso. "O que se pode usar como parte da substitución de importacións e o que non" foi discutido no anterior Artigo, polo que non vou determe neste tema.

De feito, aquí lista de ferramentas de virtualización de Astra Linux:

• VirtualBox
• Virt-xestor (KVM) Corrente de aguia
• libvirt a través de KVM

ROSA Linux non ten esa lista, pero podes atopala na wiki os seguintes paquetes:

• Virtualización ROSA sobre oVirt sobre KVM
• QEMU a través de KVM
• oVirt 3.5 a través de KVM

Calcular ten isto QEMU a través de KVM

Alt Linux ten o mesmo KVM

1.2. Hai un PERO

Tras un exame máis detallado, concluímos que só teremos que tratar con algúns hipervisores coñecidos, a saber:

1. KVM
2. VirtualBox
3. QEMU

QEMU é un programa gratuíto e de código aberto para emular hardware de varias plataformas, que pode funcionar sen utilizar KVM, pero o uso da virtualización de hardware acelera significativamente o rendemento dos sistemas convidados, polo que usar KVM en QEMU (-enable-kvm) é a opción preferida. (c) É dicir, QEMU é un hipervisor de tipo 2, que é inaceptable nun ambiente de produto. Con KVM pódese usar, pero neste caso QEMU empregarase como ferramenta de xestión KVM...

Usando o orixinal VirtualBox no comercio é en realidade infracción da licenza: "A partir da versión 4, publicada en decembro de 2010, a parte principal do produto distribúese gratuitamente baixo a licenza GPL v2. Un paquete adicional instalado encima, que ofrece soporte para dispositivos USB 2.0 e 3.0, protocolo de escritorio remoto (RDP), cifrado de unidades, arranque desde NVMe e PXE, distribúese baixo unha licenza PUEL especial ("para uso persoal e avaliación"). , baixo o cal o sistema é gratuíto para uso persoal, con fins de formación ou para avaliar antes de decidirse a mercar a versión comercial." (c) Plus VirtualBox tamén é un hipervisor de tipo 2, polo que tamén desaparece.

Total: na súa forma pura só temos KVM.

2. O resto: KVM ou KVM?

Se aínda necesitas cambiar a un hipervisor "doméstico", a túa elección, francamente, é pequena. Será KVM nun wrapper ou noutro, con certas modificacións, pero seguirá sendo KVM. Se isto é bo ou malo é outra cuestión; aínda non hai alternativa.

Se as condicións non son tan estritas, entón, como se comentou no anterior Artigo: “Hai que levar os indicadores aos límites establecidos. De feito, isto significa que debemos substituír o sistema operativo existente por produtos do rexistro do Ministerio de Telecomunicacións e Comunicacións Masivas e aumentar o número de sistemas operativos substituídos ata o 80 %... Así, podemos deixar o clúster con seguridade en Hyper-V. , xa que o temos e gústanos... "(c) Entón estamos ante unha elección: Microsoft Hyper-v ou KVM. KVM quizais con controis "aparafusados", pero seguirá sendo o mesmo KVM.

Estes produtos están lonxe de ser comparables unha vezNon dúas vecesNon tres veces...Pois entendes...

Acerca da implantación e configuración KVM non estaba escrito da mesma maneira unha vezNon dúas vecesNon tres veces non catro veces... Nunha palabra, esvaecido.

O mesmo ocorre Microsoft Hyper-V..

Non vexo sentido repetirme e describir estes sistemas, comparar, etc. Por suposto, podes sacar puntos clave dos artigos, pero creo que sería unha falta de respecto aos autores. Quen teña que escoller lerá non só isto, senón tamén unha montaña de información para decidirse.

A única diferenza na que quero centrarme é no clustering de failover. Se Microsoft ten isto integrado no sistema operativo e na funcionalidade do hipervisor, no caso de KVM terás que usar software de terceiros, que debería incluírse nos repositorios do sistema operativo. A mesma combinación de Corosync+Pacemaker, por exemplo. (Case todos os sistemas operativos domésticos teñen esta combinación... quizais todos, pero non comprobei o 100 % deles.) Tamén están dispoñibles en abundancia os manuais para configurar a agrupación.

3. Conclusión

Ben, como é habitual, os nosos Kulibins non se molestaron, colleron o que tiñan, engadiron un pouco de seu e elaboraron un "produto" que, segundo os documentos, é doméstico, pero en realidade é OpenSource. Ten sentido gastar cartos do orzamento en sistemas de virtualización "separados" (léase: non incluído no SO)? Non penses. Dado que seguirás recibindo o mesmo KVM, só terás que pagar por el.

Así, a elección dun substituto para un hipervisor depende do sistema operativo do servidor que vai mercar para o Enterprise e operar. Ou, como no meu caso, quedarás co que xa tes (Hyper-VESXi insert_needed).

Fonte: www.habr.com