oVirt em 2 horas. Parte 1. Abra a Plataforma de Virtualização de Failover

Introdução


Projeto de código aberto oVirt é uma plataforma de virtualização gratuita em nível empresarial. Percorrendo o habr, ele descobriu que o oVirt não é coberto tão amplamente quanto merece.
O oVirt é na verdade um upstream do sistema comercial da Red Hat Virtualization (RHV, anteriormente RHEV), crescendo sob a asa da Red Hat. Para evitar confusão, isso não é o mesmo que CentOS x RHEL, o modelo está mais próximo do Fedora vs RHEL.
Sob o capô - KVM , a interface da web é usada para controle. É baseado no OS RHEL / CentOS 7.
oVirt pode ser usado tanto para virtualização de servidor quanto para desktop (VDI) “tradicional”, ao contrário da solução VMware, ambos os sistemas podem coexistir em um complexo.
Projete bemEstá documentado , alcançou a maturidade para uso produtivo e está pronto para altas cargas.
Este artigo é o primeiro de uma série sobre como criar um cluster de failover em funcionamento. Depois de analisá-los, obteremos um sistema totalmente funcional em um curto espaço de tempo (cerca de 2 horas), embora vários problemas, é claro, não possam ser resolvidos, tentarei abordá-los nos seguintes artigos.
Nós o usamos há vários anos, começamos com a versão 4.1. Nosso sistema industrial agora vive na 10ª geração HPE Synergy 480 e ProLiant BL460c com CPU Xeon Gold.
No momento da redação deste artigo, a versão atual é 4.3.

Artigos


  1. Introdução - Estamos aqui
  2. Instalação do gerenciador (mecanismo de ovirt) e hipervisores (hosts)
  3. Configurações adicionais
  4. Operações básicas


Recursos funcionais


Existem 2 entidades principais no oVirt: mecanismo de ovirt e host (s) de ovirt. Para aqueles familiarizados com os produtos VMware, o oVirt como plataforma como um todo é o vSphere, o ovirt-engine - a camada de controle - desempenha as mesmas funções que o vCenter, e o ovirt-host é um hipervisor como o ESX (i). Porque O vSphere é uma solução muito popular, às vezes vou fazer uma comparação com ele.
Painel oVirt
FIG. 1 - Painel de controle oVirt.

Como máquinas convidadas, a maioria das distribuições e versões do Linux do Windows são suportadas. Para máquinas convidadas, existem agentes e dispositivos virtuais otimizados e drivers virtio, principalmente um controlador de disco e uma interface de rede.
Para implementar uma solução tolerante a falhas e todos os recursos interessantes, você precisará de armazenamento compartilhado. São suportados os blocos FC, FCoE, iSCSI, armazenamento NFS de arquivos etc. Para implementar uma solução tolerante a falhas, o sistema de armazenamento também deve ser tolerante a falhas (pelo menos 2 controladores, multipassagem).
É possível usar armazenamentos locais, mas, por padrão, apenas armazenamentos compartilhados são adequados para um cluster real. Os armazenamentos locais tornam o sistema um conjunto díspar de hipervisores e, mesmo que haja um armazenamento compartilhado, o cluster não pode ser montado. A maneira mais correta são as máquinas sem disco com inicialização a partir da SAN ou discos de tamanho mínimo. Provavelmente, por meio do gancho vdsm, é possível montar a partir de unidades locais de armazenamento definido por software (por exemplo, Ceph) e apresentar sua VM, mas seriamente não a considerou.

Arquitetura


arco
FIG. 2 - arquitetura oVirt.
Para mais informações sobre arquitetura, consulte a documentação do desenvolvedor.

dc
FIG. 3 - Objetos oVirt.

O elemento superior na hierarquia é o Data Center . Determina se o armazenamento compartilhado ou local é usado, bem como o conjunto de funções usadas (compatibilidade, de 4.1 a 4.3). Pode ser um ou mais. Para muitas opções, o uso do Data Center por padrão é Padrão.
O Data Center consiste em um ou mais Clusters . O cluster determina o tipo de processador, políticas de migração etc. Para instalações pequenas, você também pode limitar-se ao cluster Padrão.
O cluster, por sua vez, consiste em Hostestá fazendo o trabalho principal - eles carregam máquinas virtuais, os armazenamentos estão conectados a eles. Um cluster assume 2 ou mais hosts. Embora seja tecnicamente possível criar um cluster com um primeiro host, isso não tem utilidade prática.

OVirt suporta muitas funções, incluindo migração ao vivo de máquinas virtuais entre hipervisores (migração ao vivo) e armazenamento (migração de armazenamento), virtualização de desktops (infraestrutura de desktops virtuais) com pools de VMs, VMs estaduais e sem estado, suporte ao NVidia Grid vGPU, importação do vSphere, KVM, existe uma API poderosa e muito mais . Todos esses recursos estão disponíveis sem royalties e, se necessário, o suporte pode ser obtido da Red Hat através de parceiros regionais.

Sobre os preços do RHV


O custo não é alto comparado ao VMware, apenas o suporte é adquirido - sem a necessidade da compra da licença. O suporte é adquirido apenas em hipervisores; o mecanismo de ovirt, ao contrário do vCenter Server, não requer despesas.

Exemplo de cálculo para o 1º ano de propriedade


Considere um cluster de 4 máquinas de 2 soquetes e preços de varejo (sem descontos no projeto).
Uma assinatura RHV padrão custa US $ 999 por soquete / ano (premium 365/24/7 - US $ 1499), total 4 * 2 * US $ 999 = US $ 7992 .
Preço do VSphere :
  • VMware vCenter Server Standard US $ 10.837,13 por instância, mais assinatura básica de US $ 2.625,41 (Produção - US $ 3.125,39);
  • VMware vSphere Standard $ 1.164,15 + Assinatura básica $ 552,61 (Produção $ 653,82);
  • VMware vSphere Enterprise Plus $ 6.309,23 + Assinatura básica $ 1.261,09 (produção $ 1.499,94).

Total: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = US $ 27 196,62 para a opção mais jovem. A diferença é de cerca de 3,5 vezes!
No oVirt, todas as funções estão disponíveis sem restrições.

Breves especificações e altas


requisitos de sistema


O hipervisor requer uma CPU com a virtualização de hardware ativada, a quantidade mínima de RAM a iniciar é de 2 GiB, a capacidade de armazenamento recomendada para o sistema operacional é de 55 GiB (na maioria das vezes para revistas, etc., o próprio sistema operacional é pequeno).
Mais detalhes aqui .
Para o Engine, os requisitos mínimos são 2 núcleos / 4 GiB de RAM / 25 GiB de armazenamento. Recomendado - de 4 núcleos / 16 GiB de RAM / 50 GiB de armazenamento.
Como em qualquer sistema, há restrições de volumes e quantidades, a maioria das quais excede os recursos dos servidores comerciais em massa disponíveis. Portanto, um par de Intel Xeon Gold 6230 pode endereçar 2 TiB de RAM e fornecer 40 núcleos (80 threads), o que é menor do que os limites de uma VM.

Máximos da máquina virtual:


  • Máximo de máquinas virtuais em execução simultânea: ilimitado;
  • CPUs virtuais máximas por máquina virtual: 384;
  • Memória máxima por máquina virtual: 4 TiB;
  • Tamanho máximo de disco único por máquina virtual: 8 TiB.

Máximo do host:


  • Núcleos ou threads de CPU lógica: 768;
  • RAM: 12 TiB;
  • Número de máquinas virtuais hospedadas: 250;
  • Migrações ao vivo simultâneas: 2 de entrada e 2 de saída;
  • Largura de banda de migração ao vivo: o padrão é 52 MiB (~ 436 Mb) por migração ao usar a política de migração herdada. Outras políticas usam valores de taxa de transferência adaptáveis ​​com base na velocidade do dispositivo físico. As políticas de QoS podem limitar a largura de banda da migração.

Máximos da entidade lógica do gerente:


Em 4.3, existem os seguintes limites .
  • Centro de dados
    • Contagem máxima do datacenter: 400;
    • Contagem máxima de hosts: 400 suportados, 500 testados;
    • Contagem máxima de VMs: 4000 suportados, 5000 testados;
  • Grupo
    • Contagem máxima de cluster: 400;
    • Contagem máxima de hosts: 400 suportados, 500 testados;
    • Contagem máxima de VMs: 4000 suportados, 5000 testados;
  • Rede
    • Redes lógicas / cluster: 300;
    • SDN/external networks: 2600 tested, no enforced limit;
  • Storage
    • Maximum domains: 50 supported, 70 tested;
    • Hosts per domain: No limit;
    • Logical volumes per block domain (more): 1500;
    • Maximum number of LUNs (more): 300;
    • Maximum disk size: 500 TiB (limited to 8 TiB by default).



Como já mencionado, o oVirt é construído a partir de 2 elementos básicos - ovirt-engine (controle) e ovirt-host (hypervisor).
O mecanismo pode estar localizado fora da plataforma (gerenciador independente - pode ser uma VM em execução em outra plataforma ou em um hypervisor separado e até mesmo em uma máquina física) e na própria plataforma (mecanismo auto-hospedado, semelhante à abordagem VCSA da VMware).
O hipervisor pode ser instalado em um SO RHEL / CentOS 7 regular (host EL) e em um SO mínimo especializado (oVirt-Node, com base em el7).
Os requisitos de hardware para todas as opções são aproximadamente os mesmos.
Arquitetura padrão
FIG. 4 - arquitetura padrão.

Arquitetura do mecanismo auto-hospedado
FIG. 5 - Arquitetura do mecanismo auto-hospedado.

Para mim, escolhi a opção Manager independente e os Hosts EL:
  • o Gerenciador autônomo é um pouco mais fácil com problemas de inicialização, não há dilema de ovos e galinhas (como no VCSA, você não o executará até que pelo menos um host tenha subido totalmente), mas existe uma dependência de outro sistema * ;
  • O EL Host fornece todo o poder do sistema operacional, o que é útil para monitoramento externo, depuração, solução de problemas etc.

* No entanto, durante todo o período de operação, isso não foi necessário, mesmo após um grave acidente de energia.
Mas mais perto do ponto!
Para o experimento, é possível liberar um par de blades ProLiant BL460c G7 com a CPU Xeon®. Vamos reproduzir o processo de instalação neles.
Os nós serão nomeados ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com.
Prosseguimos diretamente para a instalação .

All Articles