En el anterior Se consideraron opciones sobre con qué podrían reemplazarse los sistemas existentes como parte de la implementación de la orden de sustitución de importaciones. Los siguientes artículos se centrarán en la selección de productos específicos para reemplazar los actualmente implementados. Comencemos con el punto de partida: el sistema de virtualización.
1. La agonía de la elección
Entonces, ¿entre qué puedes elegir? EN :
- Sistema de virtualización de servidores "R-Virtualización» (libvirt, KVM, QEMU)
- Paquete de software "Herramientas de virtualización de Brest» (libvirt, KVM, QEMU)
- Plataforma para la gestión y seguimiento del entorno de virtualización. "Corriente Sharx" (una solución en la nube que no es adecuada para oficinas gubernamentales en el 95% de los casos (secreto, etc.)
- Paquete de software para virtualización de servidores, escritorios y aplicaciones "HOST" (KVMx86)
- Sistema de gestión segura del entorno de virtualización "Z|virtud"(también conocido como oVirt+KVM)
- Sistema de gestión del entorno de virtualización "Virtualización ROSA"(también conocido como oVirt+KVM)
- Hipervisor VMM QP (demasiado similar a Oracle Virtual Box para ser otra cosa)
También puede tener en cuenta los hipervisores incluidos en la distribución del sistema operativo o ubicados en sus repositorios. Por ejemplo, Astra Linux tiene soporte KVM. Y dado que está incluido en los repositorios del sistema operativo, puede considerarse “legítimo” para su instalación y uso. “Qué se puede utilizar como parte de la sustitución de importaciones y qué no” se discutió en el anterior , así que no me detendré en este tema.
De hecho, aquí :
- VirtualBox
- gerente virtual (KVM) Corriente de águila
- libvirt sobre KVM
ROSA Linux no tiene dicha lista, pero puede encontrarla en la wiki :
- Virtualización ROSA sobre oVirt sobre KVM
- QEMU sobre KVM
- oVirt 3.5 sobre KVM
Calcular tiene esto
Alt Linux tiene lo mismo
1.2. Hay uno PERO
Tras un examen más detenido, llegamos a la conclusión de que solo tendremos que lidiar con unos pocos hipervisores conocidos, a saber:
QEMU es un programa gratuito y de código abierto para emular hardware de varias plataformas, que puede funcionar sin usar KVM, pero el uso de la virtualización de hardware acelera significativamente el rendimiento de los sistemas invitados, por lo que usar KVM en QEMU (-enable-kvm) es la opción preferida. (c) Es decir, QEMU es un hipervisor de tipo 2, lo cual es inaceptable en un entorno de producto. Con KVM se puede utilizar, pero en este caso se utilizará QEMU como herramienta de gestión de KVM...
Usando el original VirtualBox en el comercio es en realidad : “A partir de la versión 4, lanzada en diciembre de 2010, la mayor parte del producto se distribuye de forma gratuita bajo la licencia GPL v2. Un paquete adicional instalado encima, que brinda soporte para dispositivos USB 2.0 y 3.0, Protocolo de escritorio remoto (RDP), cifrado de unidad, arranque desde NVMe y PXE, se distribuye bajo una licencia PUEL especial ("para uso y evaluación personal") , según el cual el sistema es gratuito para uso personal, con fines de capacitación o para evaluación antes de decidir comprar la versión comercial". (c) Además, VirtualBox también es un hipervisor de tipo 2, por lo que también desaparece.
Total: en su forma pura solo tenemos KVM.
2. El resto: ¿KVM o KVM?
Si aún necesita cambiar a un hipervisor "doméstico", su elección, francamente, es pequeña. Será KVM en un contenedor u otro, con ciertas modificaciones, pero seguirá siendo KVM. Si esto es bueno o malo es otra cuestión; todavía no hay alternativa.
Si las condiciones no son tan estrictas, entonces, como se discutió en el punto anterior : “Necesitamos llevar los indicadores a los límites establecidos. De hecho, esto significa que debemos reemplazar el sistema operativo existente con productos del registro del Ministerio de Telecomunicaciones y Comunicaciones Masivas y aumentar el número de sistemas operativos reemplazados al 80%.... Entonces, podemos dejar el clúster en Hyper-V de manera segura , ya que lo tenemos y nos gusta... "(c) Entonces nos enfrentamos a una elección: Microsoft Hyper-v o KVM. KVM tal vez con los controles “atornillados”, pero seguirá siendo el mismo KVM.
Estos productos están lejos de ser comparables. no no ...Bueno, ya entiendes...
Acerca de la implementación y la configuración KVM no fue escrito de la misma manera no no y ... En una palabra, .
Lo mismo va para
No veo ningún sentido en repetirme y describir estos sistemas, comparar, etc. Por supuesto, se pueden extraer puntos clave de los artículos, pero creo que esto sería una falta de respeto para los autores. Quien tenga que elegir leerá no sólo esto, sino también una montaña de información para decidirse.
La única diferencia en la que quiero centrarme es en el clustering de conmutación por error. Si Microsoft tiene esto integrado en el sistema operativo y la funcionalidad del hipervisor, entonces, en el caso de KVM, tendrá que utilizar software de terceros, que debe incluirse en los repositorios del sistema operativo. La misma combinación de Corosync+Pacemaker, por ejemplo. (Casi todos los sistemas operativos domésticos tienen esta combinación... tal vez todos, pero no revisé el 100% de ellos). También hay disponibles en abundancia manuales para configurar la agrupación en clústeres.
3. Conclusión
Bueno, como de costumbre, nuestros Kulibins no se molestaron, tomaron lo que tenían, agregaron un poco de lo suyo y produjeron un "producto" que, según los documentos, es nacional, pero en realidad es OpenSource. ¿Tiene sentido gastar dinero del presupuesto en sistemas de virtualización "separados" (léase: no incluidos en el sistema operativo)? No pienses. Como seguirás recibiendo el mismo KVM, sólo tendrás que pagar por él.
Por lo tanto, elegir un reemplazo para un hipervisor depende del sistema operativo de servidor que vaya a comprar y operar para Enterprise. O, como en mi caso, te quedarás con lo que ya tienes (Hyper-VESXi insert_needed).
Fuente: habr.com