Olá a todos. Este artigo é destinado àqueles que ainda estão indecisos entre as plataformas de virtualização e, após ler os artigos da série "Instalamos o Proxmox e tudo está ótimo, 6 anos de uptime sem uma única interrupção". Mas, após instalar uma ou outra solução enlatada, surge a pergunta: como ajustar isso e aquilo, para que a monitorização seja mais clara, e aqui, para controlar os backups... E então chega o momento em que você percebe que deseja algo mais funcional, ou que deseja que todo o seu sistema seja mais compreensível, em vez de um caixa-preta, ou aspira usar algo mais do que um hipervisor e um monte de máquinas virtuais. Este artigo traz algumas reflexões e práticas baseadas na plataforma OpenNebula — escolhi porque não requer muitos recursos e sua arquitetura não é tão complexa.
Assim, como podemos ver, muitos provedores de nuvem trabalham com KVM e criam um sistema externo para gerenciar as máquinas. É claro que grandes provedores de hospedagem desenvolvem suas próprias interfaces para a infraestrutura em nuvem, como a YANDEX, por exemplo. Alguns utilizam OpenStack e desenvolvem interfaces com base nisso — SELECTEL, MAIL.RU. Mas, se você possui seu próprio hardware e uma pequena equipe de especialistas, geralmente escolhe algo já pronto — VMWARE, HYPER-V, que têm licenças gratuitas e pagas, mas isso não é o foco agora. Vamos falar sobre os entusiastas — aqueles que não têm medo de sugerir e experimentar algo novo, apesar das claras advertências da empresa: "Quem vai manter isso depois de você?", "Vamos lançar isso em produção? Que medo." Mas, é possível, inicialmente, aplicar essas soluções em um ambiente de teste, e se funcionar bem para todos, pode-se levantar a questão de um desenvolvimento e uso mais sério.
Aqui está um link para a apresentação de um ativo participante no desenvolvimento desta plataforma.
Pode haver algo nesta artigo que seja redundante e já claro para um especialista, e em alguns casos não descreverei tudo, já que comandos semelhantes e suas descrições estão disponíveis na web. Aqui está apenas minha experiência com esta plataforma. Espero que participantes ativos complementem nos comentários o que pode ser melhorado e quais erros cometi. Todas as ações foram realizadas em um ambiente doméstico com 3 computadores de diferentes configurações. Também não fiz questão de explicar como esse software funciona e como é instalado. Apenas compartilho a experiência de administração e os problemas que encontrei. Talvez isso possa ser útil na sua escolha.
Então, vamos lá. Para mim, como administrador de sistemas, os seguintes pontos são importantes, sem os quais provavelmente não usarei essa solução.
1. Repetibilidade da instalação
Existem muitas instruções sobre como instalar o opennebula, não deve haver problemas. Novos recursos aparecem de versão para versão, que nem sempre funcionam corretamente ao fazer a transição entre versões.
2. Monitoramento
Vamos monitorar o próprio nó, o kvm e o opennebula. Felizmente, já existem soluções disponíveis. Há várias opções para monitorar hosts Linux, como Zabbix ou node exporter — depende de qual você prefere — neste momento, estou definindo que o monitoramento de métricas do sistema (temperatura em locais onde pode ser medida, consistência do array de discos) será feito através do Zabbix, e em relação aos aplicativos, através do exporter no Prometheus. Para monitoramento do kvm, por exemplo, pode-se utilizar o projeto e configurar o início através do systemd, funciona muito bem e exibe métricas do kvm, e também há um dashboard já pronto. .
Por exemplo, aqui está meu arquivo:
/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"
[Install]
WantedBy=multi-user.targetE assim temos 1 exporter, precisamos de um segundo para monitorar o próprio opennebula, utilizei este:
É possível adicionar ao simples para monitorar o sistema, o seguinte.
No arquivo do node_exporter, alteramos a inicialização da seguinte maneira:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorCriamos o diretório mkdir -p /var/lib/opennebula_exporter
O script bash apresentado acima deve ser testado no console primeiro; se mostrar o que é necessário (caso contrário, instalamos o xmlstarlet), copiamos para /usr/local/bin/opennebula_exporter.sh.
Adicionamos uma tarefa no cron para cada minuto:
*\/1 * * * * (\/usr\/local\/bin\/opennebula_exporter.sh > \/var\/lib\/opennebula_exporter\/textfile_collector\/opennebula.prom)As métricas começaram a aparecer, é possível coletá-las com o Prometheus e criar gráficos e alertas. No Grafana, por exemplo, podemos desenhar um painel simples como este.
(é visível que aqui eu fiz overcommit de cpu, ram)
Para quem gosta e usa o Zabbix, há
Sobre monitoramento é isso, o principal é que ele existe. Claro, é possível, além disso, usar as ferramentas de monitoramento integradas das máquinas virtuais e exportar os dados para faturamento, aqui cada um tem sua visão, ainda não me aprofundei muito nisso.
Quanto à logação, ainda não me aprofundei muito. A forma mais simples é adicionar o td-agent para fazer o parsing do diretório \/var\/lib\/one com expressões regulares. Por exemplo, o arquivo sunstone.log se encaixa na regexp do nginx e outros arquivos que mostram o histórico de interações com a plataforma — qual é a vantagem disso? Bem, podemos rastrear claramente a quantidade de "Error, error" e identificar rapidamente onde e em que nível há um problema.
3. Cópias de segurança
Existem também projetos pagos melhorados — por exemplo, sep :OpenNebula_Backup. Aqui, precisamos entender que simplesmente fazer backup da imagem da máquina não é suficiente, pois nossas máquinas virtuais devem operar com total integração (o mesmo contexto para o arquivo que descreve as configurações de rede, nome da vm e configurações personalizadas para suas aplicações). Portanto, definimos o que e como faremos o backup. Em alguns casos, é melhor fazer cópias do que está dentro da própria vm. E talvez seja necessário fazer backup apenas de um disco dessa máquina.
Por exemplo, decidimos que todas as máquinas são iniciadas com imagens persistentes, então, lendo
significa que primeiro, da nossa vm, podemos exportar a imagem:
onevm disk-saveas 74 3 prom.qcow2
ID da imagem: 77
Verificamos sob qual nome ela foi salva
oneimage show 77
\/var\/lib\/one\/\/datastores\/100\/f9503161fe180658125a9b32433bf6e8
E depois copiamos para onde for necessário. Claro, não é o melhor método. Queria apenas mostrar que usando as ferramentas do opennebula podemos construir soluções assim.Também encontrei em várias fontes e ainda há , mas este é apenas para armazenamento qcow2.
Mas como todos sabemos, chega um momento em que se deseja backups incrementais, onde as coisas ficam mais complicadas e talvez a gestão disponibilize recursos para uma solução paga, ou optar por outro caminho, entendendo que aqui estamos apenas consumindo recursos, enquanto o backup deve ser feito no nível das aplicações e aumentando o número de novos nós e virtualizações — sim, estou dizendo que devemos usar a nuvem apenas para executar clusters de aplicações, enquanto os bancos de dados devem ser iniciados em outra plataforma ou obtidos prontos do fornecedor, se isso for viável.
4. Conforto de Uso
Neste ponto, vou descrever os problemas que eu enfrentei. Por exemplo, em relação às imagens, como sabemos, existe a persistent — ao montar essa imagem na VM, todos os dados são gravados nessa imagem. E se for non-persistent, a imagem é copiada para o armazenamento e os dados são escritos naquilo que foi copiado da imagem original — assim funcionam os templates. Muitas vezes eu mesmo criei problemas ao esquecer de especificar persistent, e 200 GB da imagem eram copiados, o problema é que seguramente esse procedimento não pode ser cancelado, é necessário ir até o nó e encerrar o processo atual de "cp".
Um dos grandes inconvenientes é que não se pode cancelar as ações simplesmente usando a GUI. Na verdade, você pode cancelá-las e verá que nada acontece, e então reiniciará, cancelará e, de fato, haverá 2 processos cp em execução, que estão copiando a imagem.
E aqui vem a compreensão do porquê o OpenNebula numerar cada nova instância com um novo ID, por exemplo, no Proxmox você cria uma VM com ID 101, a exclui e depois cria novamente e terá ID 101. No OpenNebula isso não acontecerá; cada nova instância será criada com um novo ID, e há um raciocínio por trás disso — por exemplo, limpeza de dados antigos ou instalações sem sucesso.
O mesmo se aplica ao armazenamento; essa plataforma é mais voltada para armazenamento centralizado. Existem addons para uso local, mas neste caso não é sobre isso. Acredito que no futuro alguém escreverá um artigo sobre como foi possível usar armazenamento local nos nós e utilizá-lo com sucesso em produção.
5. Máxima Simplicidade
Claro, quanto mais você avança, menos pessoas entenderão você.
Nas condições do meu ambiente — 3 nós com armazenamento NFS — tudo funciona bem. Mas se fizermos experimentos de desligamento de energia, por exemplo, durante o lançamento de um snapshot e o desligamento da energia do nó, as configurações na base de dados são mantidas, indicando que há um snapshot, enquanto na verdade não há (sabemos que inicialmente foi registrado na base SQL sobre essa ação, mas a operação em si falhou). O bom é que, ao criar um snapshot, um arquivo separado é gerado e há um 'pai', portanto, em caso de problemas, mesmo que através da interface gráfica não funcione, podemos pegar o arquivo qcow2 e restaurá-lo separadamente.
Quanto às redes, infelizmente, não é tão simples. Pelo menos é mais fácil do que no OpenStack, eu usei apenas VLAN (802.1Q) — funciona bem, mas se você fizer alterações nas configurações a partir do template de rede, essas configurações não se aplicarão às máquinas que já estão funcionando, ou seja, é necessário remover e adicionar a interface de rede, então as novas configurações serão aplicadas.
Se ainda quisermos comparar com o OpenStack, podemos dizer que no OpenNebula não há uma definição clara sobre quais tecnologias usar para armazenamento de dados, gerenciamento de rede, recursos — cada administrador decide por si mesmo o que é mais conveniente.
6. Plugins e instalações adicionais
Pois como sabemos, a plataforma em nuvem pode gerenciar não apenas KVM, mas também VMware ESXi. Infelizmente, eu não tinha um pool com VCenter, se alguém tentou, escreva.
Na assistência de outros provedores de nuvem, é afirmado
AWS, AZURE.
Também tentei integrar o VMware Cloud da Selectel, mas não consegui — no geral, desisti, pois há muitos fatores, e não faz sentido escrever para o suporte técnico do provedor de hospedagem.
Além disso, agora na nova versão há o Firecracker — isso inicia microvms, uma camada sobre KVM e Docker, que oferece ainda mais versatilidade, segurança e aumento de desempenho, pois não é necessário gastar recursos na emulação de hardware. Vejo apenas vantagens em relação ao Docker, pois não ocupa um número adicional de processos e não ocupa sockets quando usando essa emulação, ou seja, pode ser usado como balanceador de carga (mas sobre isso talvez seja necessário escrever um artigo separado, pois ainda não fiz todos os testes plenamente).
7. Experiência positiva de uso e depuração de erros
Queria compartilhar minhas observações sobre o funcionamento, descrevi parte acima, mas gostaria de escrever mais. De fato, provavelmente não sou o único que inicialmente pensa que este não é o sistema certo e que, de maneira geral, tudo aqui é muito improvisado — como lidam com isso? Mas depois vem a compreensão de que tudo faz sentido. É claro que é impossível agradar a todos e alguns pontos precisam de melhorias.
Por exemplo, uma operação simples de copiar uma imagem de disco de um datastore para outro. No meu caso, há 2 nós com NFS, estou enviando a imagem — a cópia ocorre através do frontend do OpenNebula, embora todos nós estejamos acostumados a que os dados sejam copiados diretamente entre os hosts — da mesma forma que no VMware ou Hyper-V, é assim que estamos acostumados, mas aqui funciona de maneira diferente. Aqui a abordagem e a ideologia são distintas, e na versão 5.12 removeram o botão 'migrate to datastore' — apenas a máquina é transferida, não o armazenamento, pois presume-se um repositório centralizado.
Depois, um erro comum com várias causas 'Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5'. Abaixo estará uma lista do que é preciso verificar.
- Permissões da imagem para o usuário oneadmin;
- Permissões para o usuário oneadmin para iniciar o libvirtd;
- O datastore está montado corretamente? Vá e verifique o caminho no próprio nó, talvez algo tenha caído;
- Rede mal configurada, ou melhor, no frontend está na configuração de rede que o br0 é o interface principal para o VLAN, enquanto no nó está escrito — bridge0 — precisa estar igual.
O system datastore armazena os metadados da sua VM. Se você iniciar a VM com uma imagem persistente, a VM precisa ter acesso à configuração originalmente criada no armazenamento onde você criou a VM — isso é muito importante. Portanto, ao mover a VM para outro datastore, tudo deve ser verificado novamente.
8. Documentação, comunidade. Desenvolvimento futuro.
E, além disso, uma boa documentação, uma comunidade e, acima de tudo, que o projeto continue a existir no futuro.
Aqui, de maneira geral, tudo está bem documentado e mesmo pelo fonte oficial não será difícil instalar e encontrar respostas para questões.
Comunidade ativa. Publica muitas soluções prontas que você pode usar em suas instalações.
Atualmente, a partir da versão 5.12, algumas políticas na empresa mudaram. Será interessante saber como o projeto se desenvolverá. No início, mencionei alguns fornecedores que utilizam suas próprias soluções e o que a indústria oferece. Não há uma resposta clara sobre o que você deve usar, mas para pequenas organizações, manter sua própria nuvem privada pode não ser tão caro quanto parece. O principal é saber exatamente o que você precisa.
Em resumo, independentemente do que você escolheu como sistema de nuvem, não deve se limitar a um único produto. Se você tiver tempo, vale a pena explorar outras soluções mais abertas.
Há um bom chat. ajudam ativamente e não mandam você procurar a solução do problema no Google. Junte-se a nós.
Fonte: habr.com
