Introdução
Projeto de código aberto — uma plataforma de virtualização de nível corporativo livre. Ao navegar pelo habr, descobri que não é tão amplamente coberto aqui quanto merece.
oVirt é, na verdade, a fonte upstream para o sistema comercial Red Hat Virtualization (RHV, anteriormente RHEV), que cresce sob a tutela da Red Hat. Para evitar confusões, isso não é o mesmo que CentOS vs RHEL, o modelo é mais parecido com Fedora vs RHEL.
Por trás das cortinas — , é gerenciado através de uma interface web. Baseia-se em RHEL/CentOS 7.
oVirt pode ser utilizado tanto para virtualização de servidores 'tradicional' quanto para virtualização de desktops (VDI), ao contrário da solução da VMware, onde ambos os sistemas podem coexistir em um único ambiente.
O projeto é bem , já alcançou maturidade para aplicações produtivas e está preparado para cargas elevadas.
Este artigo é o primeiro de um ciclo sobre como construir um cluster de alta disponibilidade funcional. Seguindo estas etapas, teremos um sistema totalmente funcional em um curto espaço de tempo (cerca de 2 horas), embora algumas questões, é claro, não possam ser abordadas, tentarei esclarecê-las em artigos futuros.
Usamos ele há alguns anos, começando com a versão 4.1. Nosso sistema industrial agora roda em servidores HPE Synergy 480 e ProLiant BL460c de 10ª geração com CPU Xeon Gold.
No momento da redação, a versão ativa é 4.3.
Artigos
- Introdução (Estamos aqui)
Características funcionais
No oVirt, existem 2 entidades principais: ovirt-engine e ovirt-host(s). Para aqueles que estão bem familiarizados com os produtos da VMware, o oVirt, em geral, como plataforma, é o vSphere; o ovirt-engine — camada de gerenciamento — desempenha as mesmas funções que o vCenter, enquanto o ovirt-host — hipervisor, como ESX(i). Como o vSphere é uma solução muito popular, às vezes farei comparações com ele.
Fig. 1 — painel de controle do oVirt.
A maioria das distribuições Linux e versões do Windows é suportada como máquinas convidadas. Para máquinas convidadas, existem agentes e dispositivos virtuais otimizados e drivers virtio, principalmente o controlador de disco e a interface de rede.
Para implementar uma solução de alta disponibilidade e todas as funcionalidades interessantes, será necessário um armazenamento compartilhado. São suportados tanto armazenamento em bloco FC, FCoE, iSCSI, quanto armazenamento de arquivos NFS e outros. Para implementar uma solução de alta disponibilidade, o sistema de armazenamento também deve ser resiliente (mínimo de 2 controladores, multipath).
O uso de armazenamentos locais é possível, mas, por padrão, apenas os armazenamentos compartilhados são adequados para um cluster real. Armazenamentos locais fazem com que o sistema seja um conjunto fragmentado de hipervisores e, mesmo com um armazenamento compartilhado, não é possível montar um cluster. O caminho mais correto é usar máquinas sem disco com boot a partir de SAN, ou discos de capacidade mínima. Provavelmente, através de um hook do vdsm, é viável criar um armazenamento definido por software (por exemplo, Ceph) a partir de discos locais e apresentá-lo como VM, mas não considerei isso seriamente.
Arquitetura
Figura 2 — arquitetura do oVirt.
Você pode encontrar mais informações sobre a arquitetura em do desenvolvedor.
Figura 3 — objetos do oVirt.
O elemento superior na hierarquia é Centro de Dados. Ele define se os armazenamentos utilizados são compartilhados ou locais, assim como o conjunto de funções utilizadas (compatibilidade, de 4.1 a 4.3). Pode haver um ou vários. Para muitas opções, o uso do Data Center padrão — Default — é adequado.
O Data Center consiste em um ou mais Clusters. O cluster determina o tipo de processador, políticas de migração, entre outros. Para pequenas instalações, também é possível limitar-se ao cluster Default.
O cluster, por sua vez, é composto por Hosthosts que realizam o trabalho principal — eles suportam máquinas virtuais e estão conectados aos armazenamentos. Espera-se que, no cluster, haja 2 ou mais hosts. Embora tecnicamente seja possível criar um cluster com um único host, isso não tem utilidade prática.
O oVirt suporta várias funções, incluindo migração ao vivo de máquinas virtuais entre hipervisores (live migration) e armazenamentos (storage migration), virtualização de desktop (virtual desktop infrastructure) com pools de VMs, VMs stateful e stateless, suporte a NVidia Grid vGPU, importação do vSphere, KVM, e muitos outros recursos. Todas essas funções estão disponíveis sem taxas de licenciamento, e, se necessário, o suporte pode ser adquirido da Red Hat através de parceiros regionais. e muito mais. Todas essas funcionalidades estão disponíveis sem taxas de licenciamento, e, se for necessário suporte, pode ser adquirido da Red Hat através de parceiros regionais.
Sobre os preços do RHV
O custo não é alto em comparação com o VMware; apenas o suporte é adquirido, sem exigir a compra da licença em si. O suporte é adquirido apenas para os hipervisores e o ovirt-engine, ao contrário do vCenter Server, que não requer despesas.
Exemplo de cálculo para o primeiro ano de posse
Vamos considerar um cluster de 4 máquinas com 2 soquetes e preços de varejo (sem descontos de projeto).
A assinatura padrão do RHV por soquete/ano (premium 365/24/7 — $1499), totalizando 4*2*$999=$7992.
:
- VMware vCenter Server Standard $10,837.13 por instância, mais assinatura Basic $2,625.41 (Produção — $3,125.39);
- VMware vSphere Standard $1,164.15 + Assinatura Basic $552.61 (Produção $653.82);
- VMware vSphere Enterprise Plus $6,309.23 + Assinatura Basic $1,261.09 (Produção $1,499.94).
Total: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 para a opção mais básica. A diferença é de cerca de 3,5 vezes!
No oVirt, todas as funções estão disponíveis sem limitações.
Especificações resumidas e máximos
Requisitos do sistema
Para o hipervisor, é necessário um CPU com virtualização de hardware ativada, a quantidade mínima de RAM para iniciar — 2 GiB, a capacidade recomendada de armazenamento para o SO — 55 GiB (principalmente para logs e afins, o próprio SO ocupa pouco).
Saiba mais — .
Para requisitos mínimos 2 núcleos / 4 GiB RAM / 25 GiB armazenamento. Recomendados — de 4 núcleos / 16 GiB RAM / 50 GiB armazenamento.
Como em qualquer sistema, há limitações de capacidades e quantidades, a maioria das quais supera as capacidades dos servidores comerciais disponíveis. Assim, um par pode endereçar 2 TiB de RAM e oferece 40 núcleos (80 threads), que é menos do que os limites de uma única VM.
Máximos de Máquina Virtual:
- Máximo de máquinas virtuais em execução simultaneamente: Ilimitado;
- Máximo de CPUs virtuais por máquina virtual: 384;
- Máxima memória por máquina virtual: 4 TiB;
- Máximo de tamanho único de disco por máquina virtual: 8 TiB.
Máximos do Host:
- Núcleos ou threads lógicos de CPU: 768;
- RAM: 12 TiB;
- Número de máquinas virtuais hospedadas: 250;
- Migrações ao vivo simultâneas: 2 entrantes, 2 saídas;
- Largura de banda de migração ao vivo: Padrão de 52 MiB (~436 Mb) por migração ao usar a política de migração legada. Outras políticas utilizam valores de throughput adaptativos com base na velocidade do dispositivo físico. Políticas de QoS podem limitar a largura de banda de migração.
Máximos de Entidade Lógica do Gerenciador:
Na versão 4.3, existem .
- Data center
- Máximo de contagem de data centers: 400;
- Máximo de contagem de hosts: 400 suportados, 500 testados;
- Máximo de contagem de VMs: 4000 suportadas, 5000 testadas;
- Cluster
- Máximo de contagem de clusters: 400;
- Máximo de contagem de hosts: 400 suportados, 500 testados;
- Máximo de contagem de VMs: 4000 suportadas, 5000 testadas;
- Rede
- Redes lógicas / cluster: 300;
- SDN / redes externas: 2600 testadas, sem limite imposto;
- Storage
- Máximo de domínios: 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 de disco: 500 TiB (limitado a 8 TiB por padrão).
Opções de implementação
Como já mencionado, o 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 plataforma (standalone Manager — isso pode ser uma VM sendo executada em outra plataforma ou em um hipervisor separado e até uma máquina física), quanto na própria plataforma (self-hosted engine, semelhante à abordagem VCSA da VMware).
O hipervisor pode ser instalado tanto em (EL Host), quanto em (oVirt-Node, baseado em el7).
Os requisitos de hardware para todas as opções são aproximadamente os mesmos.
Fig. 4 — arquitetura padrão.
Figura 5 — Arquitetura do Engine auto-hospedado.
Escolhi a opção de Manager autônomo e EL Hosts:
- o Manager autônomo é um pouco mais simples em caso de problemas de inicialização, não há o dilema do ovo e da galinha (assim como para a VCSA — você não consegue iniciar até que pelo menos um host esteja totalmente operacional), 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, etc.
* No entanto, durante todo o tempo de operação, isso não foi necessário, mesmo após uma falha grave de energia.
Mas vamos ao que interessa!
Para o experimento, temos a possibilidade de liberar algumas lâminas ProLiant BL460c G7 com CPU Xeon®. É nelas que iremos reproduzir o processo de instalação.
Vamos nomear os nós como ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com.
Vamos direto ao .
Fonte: habr.com
