Substituição de importação na prática. Parte 2. O começo. Hypervisor

Em um artigo anterior, foram consideradas opções para as quais os sistemas existentes podem ser substituídos como parte da implementação da ordem de substituição de importação. Outros artigos se concentrarão na seleção de produtos específicos para substituir os atualmente implantados. Vamos começar do ponto de partida - sistemas de virtualização.

1. Farinha de escolha

Então, o que você pode escolher? No registro do Ministério das Comunicações, há uma opção :

• Sistema de virtualização de servidores " R-Virtualization " (libvirt, KVM, QEMU)
• O pacote de software " Brest Virtualization Tools " (libvirt, KVM, QEMU)
• Plataforma de gerenciamento e monitoramento para o ambiente de virtualização Sharx Stream (uma solução em nuvem que não é adequada para o setor público em 95% dos casos (privacidade etc.)
• Software de virtualização HOST para servidores, desktops e aplicativos (KVM x86)
• O sistema de gerenciamento seguro do ambiente de virtualização " Z | virt " (aka oVirt + KVM)
• O sistema de gerenciamento de ambiente de virtualização ROSA Virtualization (aka oVirt + KVM)
• QP VMM Hypervisor (muito semelhante ao Oracle Virtual Box para qualquer outra coisa)

Você também pode levar em consideração os hipervisores que fazem parte da entrega do SO ou estão em seu repositório. Por exemplo, o mesmo Astra Linux tem suporte a KVM. E como está incluído nos repositórios do SO, pode ser considerado "legítimo" para instalação e uso. O fato de que “o que pode ser usado no âmbito da substituição de importações e o que não é” foi discutido no artigo anterior, por isso não vou me debruçar sobre esse assunto.

1.2 Existe um MAS

Após um exame mais detalhado, concluímos que teremos que lidar apenas com alguns hipervisores conhecidos, a saber:

1. Kvm
2. Virtualbox
3. QEMU
4. bhyve

O QEMU é um programa de código aberto gratuito para emular hardware de várias plataformas que podem funcionar sem o KVM, mas o uso da virtualização de hardware acelera significativamente os sistemas convidados, portanto, usar o KVM no QEMU (-enable-kvm) é a opção preferida. (c) Ou seja, QEMU é um hipervisor tipo 2, o que é inaceitável em um ambiente de produto. Pode ser usado com o KVM, mas, nesse caso, o QEMU será usado como uma ferramenta de gerenciamento do KVM.

bhyve - hipervisões do segundo tipo. Está marcado.

O uso do VirtualBox original no comércio é de fato uma violação da licença : “A partir da versão 4, lançada em dezembro de 2010, a maior parte do produto é distribuída gratuitamente sob a licença GPL v2. O pacote adicional instalado na parte superior, que suporta dispositivos USB 2.0 e 3.0, RDP (Remote Desktop Protocol), criptografia de unidade, inicialização a partir do NVMe e PXE, é distribuído sob uma licença PUEL especial (“para uso pessoal e familiarização”), sob a qual o sistema "gratuito para uso pessoal, para fins educacionais ou para avaliação antes de decidir comprar uma versão comercial." (c) O Plus VirtualBox também é um hipervisor do tipo 2 e, por isso, desaparece.

Total: na sua forma pura, temos apenas KVM .

2. O resto: KVM ou KVM?

Se você ainda precisar mudar para um hipervisor "doméstico", terá, francamente, uma pequena opção. Será o KVM em um ou outro wrapper, com várias modificações, mas ainda será o KVM. Para melhor ou pior - a questão é diferente, de qualquer maneira não há alternativa.

Se as condições não forem tão rigorosas, então, como declarado no artigo anterior: “Precisamos levar os indicadores aos limites estabelecidos. De fato, isso significa que devemos substituir os sistemas operacionais existentes por produtos do registro do Ministério das Comunicações e Comunicações e elevar o número de sistemas operacionais substituídos para 80% ... Portanto, podemos deixar o cluster com segurança no Hyper-V, pois já o temos e gostamos. .. "(c) Portanto, somos confrontados com uma opção: Microsoft Hyper-V ou KVM . O KVM pode estar com os controles "aparafusados" a ele, mas ainda permanecerá o mesmo KVM .

Esses produtos foram comparados muito mais de uma vez , nem duas , nem três vezes ... Bem, você entende ...

Sobre a implantação e configuração do KVM, ele também foi escrito mais de uma vez , não duas , nem três e nem quatro vezes ... Em uma palavra, eles conseguiram .

O mesmo vale para o Microsoft Hyper-V ..

Não vejo razão para repetir e descrever esses sistemas, comparar etc. Você pode, é claro, retirar pontos-chave dos artigos, mas isso será desrespeito aos autores, eu acho. Quem tem que escolher - ele lerá não apenas isso, mas também uma montanha de informações para decidir.

A única diferença que quero focar é o clustering de failover. Se a Microsoft incorporou isso ao sistema operacional e à funcionalidade do hypervisor, no caso do KVM, você precisará usar software de terceiros, que deve ser incluído nos repositórios do sistema operacional. O mesmo grupo de Corosync + Pacemaker, por exemplo. (Quase todos os sistemas operacionais domésticos têm esse grupo ... talvez todos tenham, mas eu não marquei 100%.) Também há muitos manuais para configurar o cluster.

3. Conclusão

Bem, como sempre, nossos Kulibins não se incomodaram, pegaram o que aconteceu, estragaram um pouco e deram um “produto”, que segundo os documentos é doméstico, mas de fato - OpenSource. Faz sentido gastar dinheiro com o orçamento para sistemas de virtualização "separados" (leitura não incluída no sistema operacional)? Eu acho que não. Como você ainda receberá o mesmo KVM, precisará pagar apenas por ele.

Portanto, a escolha da substituição do hypervisor se resume a qual sistema operacional do servidor você pretende comprar e operar para a empresa. Ou, como no meu caso, você permanecerá com o que já possui (Hyper-V \ ESXi \ enter_necessary).

Também sobre o tópico você pode ler:

Artigo anterior sobre o planejamento de substituição de importações.

E mais adiante:

Um artigo sobre sistemas operacionais "domésticos".

Um artigo sobre sistemas e serviços.

E sobre o QP OS , além disso.