Introdução
projeto de código aberto é uma plataforma gratuita de virtualização de nível empresarial. Percorrendo habr, descobri que não tem a abrangência que merece.
oVirt é, na verdade, upstream para o sistema comercial Red Hat Virtualization (RHV, anteriormente RHEV), crescendo sob a asa da Red Hat. Para evitar confusão, este não o mesmo que CentOS vs RHEL, o modelo está mais próximo do Fedora vs RHEL.
Sob o capô - , a interface da web é usada para gerenciamento. Baseado no sistema operacional RHEL/CentOS 7.
oVirt pode ser usado tanto para servidor "tradicional" quanto para virtualização de desktop (VDI), ao contrário da solução VMware, ambos os sistemas podem coexistir em um complexo.
Projete bem , há muito atingiu 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 funcional. Depois de passar por eles, em pouco tempo (cerca de 2 horas) teremos um sistema totalmente funcional, embora vários problemas, é claro, não possam ser divulgados, tentarei abordá-los nos próximos artigos.
Nós o usamos há vários anos, começamos com a versão 4.1. Nosso sistema industrial agora funciona com computadores HPE Synergy 480 e ProLiant BL460c de 10ª geração com CPUs Xeon Gold.
No momento da escrita, a versão atual é 4.3.
Artigos
- Introdução (Estamos aqui)
Funcionalidades Funcionais
Existem 2 entidades principais no oVirt: ovirt-engine e ovirt-host(s). Para aqueles que estão familiarizados com os produtos VMware, oVirt como um todo como plataforma é vSphere, ovirt-engine - a camada de controle - executa as mesmas funções do vCenter e ovirt-host é um hipervisor, como ESX (i). Porque O vSphere é uma solução muito popular, às vezes vou compará-lo com ele.
Arroz. 1 - Painel de controle oVirt.
A maioria das distribuições Linux e versões do Windows são suportadas como máquinas convidadas. 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 armazenamentos de bloco FC, FCoE, iSCSI e NFS de arquivo, etc. Para implementar uma solução tolerante a falhas, o sistema de armazenamento também deve ser tolerante a falhas (pelo menos 2 controladores, passagem múltipla).
O uso de armazenamentos locais é possível, mas por padrão apenas armazenamentos compartilhados são adequados para um cluster real. Os armazenamentos locais tornam o sistema um conjunto diferente de hipervisores e, mesmo com armazenamento compartilhado, um cluster não pode ser montado. A maneira mais correta são as máquinas sem disco com inicialização da SAN ou discos de tamanho mínimo. Provavelmente, por meio do gancho vdsm, é possível construir a partir de discos locais de armazenamento definido por software (por exemplo, Ceph) e apresentar sua VM, mas não considerei isso seriamente.
Arquitetura
Arroz. 2 - arquitetura oVirt.
Mais informações sobre a arquitetura podem ser encontradas em desenvolvedor.
Arroz. 3 - oVirt objetos.
O elemento superior na hierarquia - Data Center. Ele determina se o armazenamento compartilhado ou local é usado, bem como o conjunto de recursos usado (compatibilidade, 4.1 a 4.3). Pode haver um ou mais. Para muitas opções, usar o Data Center 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 pequenas instalações, você também pode limitar-se ao cluster padrão.
O cluster, por sua vez, é formado por Proprietário's que executam o trabalho principal - eles carregam máquinas virtuais, os armazenamentos são conectados a eles. O cluster assume 2 ou mais hosts. Embora seja tecnicamente possível fazer um cluster com 1 host, isso não é prático.
oVirt suporta muitos recursos, incl. migração ao vivo de máquinas virtuais entre hipervisores (migração ao vivo) e storages (migração de armazenamento), virtualização de desktop (infraestrutura de desktop virtual) com pools de VMs, VMs statefull e stateless, suporte para NVidia Grid vGPU, importação de vSphere, KVM, há um poderoso e muito mais. Todos esses recursos estão disponíveis sem royalties e, se necessário, o suporte pode ser adquirido da Red Hat por meio de parceiros regionais.
Sobre os preços do RHV
O custo não é alto comparado ao VMware, apenas o suporte é adquirido - sem a necessidade de adquirir a própria licença. O suporte é adquirido apenas para hipervisores, o ovirt-engine, ao contrário do vCenter Server, não requer gastos.
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 de projeto).
Assinatura Padrão RHV por soquete/ano (premium 365/24/7 - $1499), total 4*2*$999=$7992.
:
- VMware vCenter Server Standard $ 10,837.13 por instância mais assinatura básica $ 2,625.41 (produção $ 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) = $ 27 196,62 para a menor opção. A diferença é de cerca de 3,5 vezes!
No oVirt, todas as funções estão disponíveis sem restrições.
Breves características e máximos
Системные требования
O hipervisor requer uma CPU com virtualização de hardware habilitada, a quantidade mínima de RAM para iniciar é de 2 GiB, a quantidade de armazenamento recomendada para o SO é de 55 GiB (principalmente para logs, etc., o próprio SO ocupa pouco).
Mais detalhes - .
Para requisitos mínimos 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á limites de volumes e quantidades, a maioria dos quais excede as capacidades dos servidores comerciais em massa disponíveis. Sim, um casal. pode endereçar 2 TiB de RAM e oferece 40 núcleos (80 threads), o que é ainda menor que os limites de uma VM.
Máximos de máquinas virtuais:
- Máximo de máquinas virtuais em execução simultânea: Ilimitado;
- Máximo de CPUs virtuais 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áximos de host:
- Núcleos ou threads de CPU lógicos: 768;
- RAM: 12 TiB
- Número de máquinas virtuais hospedadas: 250;
- Live migrations simultâneas: 2 de entrada, 2 de saída;
- Largura de banda de migração ao vivo: padrão para 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 de migração.
Máximos de entidades lógicas do gerente:
Em 4.3 existem .
- Centro de dados
- Contagem máxima de data center: 400;
- Contagem máxima de hosts: 400 suportados, 500 testados;
- Contagem máxima de VM: 4000 com suporte, 5000 testados;
- Agrupar
- Contagem máxima de clusters: 400;
- Contagem máxima de hosts: 400 suportados, 500 testados;
- Contagem máxima de VM: 4000 com suporte, 5000 testados;
- Network
- Redes lógicas/cluster: 300
- SDN/redes externas: 2600 testados, sem limite imposto;
- Armazenamento
- Domínios máximos: 50 suportados, 70 testados;
- Hosts por domínio: Sem limite;
- Volumes lógicos por domínio de bloco (mais): 1500;
- Número máximo de LUNs (mais): 300;
- Tamanho máximo do disco: 500 TiB (limitado a 8 TiB por padrão).
Opções de implementação
Como já mencionado, oVirt é construído a partir de 2 elementos básicos - ovirt-engine (gerenciamento) e ovirt-host (hipervisor).
O Engine pode ser hospedado tanto fora da própria plataforma (gerenciador autônomo - pode ser uma VM rodando em outra plataforma ou em um hipervisor separado, e até mesmo uma máquina física), quanto na própria plataforma (engenharia auto-hospedada, semelhante ao VCSA da VMware abordagem).
O hipervisor pode ser instalado em (Anfitrião EL) e (oVirt-Node, baseado em el7).
Os requisitos de hardware para todas as variantes são aproximadamente os mesmos.
Arroz. 4 - arquitetura padrão.
Arroz. 5 - Arquitetura do mecanismo auto-hospedado.
Para mim, escolhi a opção Gerenciador autônomo e EL Hosts:
- O gerenciador autônomo é um pouco mais fácil com problemas de inicialização, não há dilema do ovo e da galinha (como no VCSA - você não iniciará até que pelo menos um host esteja totalmente ativo), mas há 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 e muito mais.
* No entanto, isso não foi necessário durante todo o período de operação, mesmo após uma falha grave de energia.
Mas mais ao ponto!
Para experimentação, é possível lançar um par de blades ProLiant BL460c G7 com CPU Xeon®. Iremos reproduzir o processo de instalação neles.
Vamos nomear os nós ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com.
Vamos direto para .
Fonte: habr.com