Ola a todos. Este artigo foi escrito para aqueles que aínda están divididos entre escoller plataformas de virtualización e despois de ler o artigo da serie "Instalamos proxmox e, en xeral, todo está ben, 6 anos de tempo de actividade sen unha soa pausa". Pero despois de instalar unha ou outra solución lista, xorde a pregunta: como podo corrixir isto aquí, para que a vixilancia sexa máis comprensible, e aquí, para controlar as copias de seguridade... E entón chega o momento e dás conta de que queres algo máis funcional, ou queres que todo o interior do teu sistema quede claro, e non esta caixa negra, ou queres usar algo máis que un hipervisor e unha morea de máquinas virtuais. Este artigo conterá algunhas reflexións e prácticas baseadas na plataforma Opennebula; escollíno porque. non é esixente en recursos e a arquitectura non é tan complexa.
E así, como vemos, moitos provedores de nube traballan en kvm e fan conexións externas para controlar máquinas. Está claro que os grandes servidores escriben os seus propios marcos para a infraestrutura na nube, o mesmo YANDEX por exemplo. Alguén usa openstack e fai unha conexión sobre esta base: SELECTEL, MAIL.RU. Pero se tes o teu propio hardware e un pequeno equipo de especialistas, normalmente elixes algo preparado: VMWARE, HYPER-V, hai licenzas gratuítas e de pago, pero non estamos a falar agora. Falemos dos entusiastas: estes son aqueles que non teñen medo de ofrecer e probar algo novo, a pesar de que a empresa deixou claro: "Quen vai atender isto despois de ti?" "Imos lanzar isto á produción máis tarde? ? Asustado". Pero primeiro podes aplicar estas solucións nun banco de probas e, se a todos lles gusta, podes plantexar a cuestión dun maior desenvolvemento e uso en ambientes máis serios.
Tamén aquí tedes unha ligazón ao informe dun participante activo no desenvolvemento desta plataforma.
Quizais neste artigo algo sexa superfluo e xa comprensible para un especialista experimentado, e nalgúns casos non describirei todo porque hai comandos e descricións similares dispoñibles en Internet. Esta é só a miña experiencia con esta plataforma. Espero que os participantes activos engadan nos comentarios o que se podería facer mellor e os erros que cometín. Todas as accións desenvolvéronse nun stand doméstico composto por 3 PCs de diferentes características. Ademais, específicamente non indiquei como funciona este software e como instalalo. Non, só experiencia administrativa e os problemas que atopei. Quizais isto sexa útil para alguén na súa elección.
Entón, imos comezar. Como administrador do sistema, os seguintes puntos son importantes para min, sen os cales é pouco probable que use esta solución.
1. Repetibilidade da instalación
Hai moitas instrucións para instalar opennebula, non debería haber ningún problema. De versión en versión, aparecen novas funcións que non sempre funcionarán ao pasar de versión en versión.
2. Seguimento
Seguiremos o propio nodo, kvm e opennebula. Afortunadamente, xa está listo. Hai moitas opcións sobre a vixilancia de hosts Linux, o mesmo Zabbix ou exportador de nodos -a quen lle guste o que mellor-, polo momento defíminoo como métricas de monitorización do sistema (temperatura onde se pode medir, consistencia da matriz de discos), a través de zabbix. , e en canto ás solicitudes a través do exportador Prometheus. Para o seguimento de kvm, por exemplo, pode levar o proxecto e configúrao para que se execute a través de systemd, funciona bastante ben e mostra as métricas de kvm, tamén hai un panel preparado .
Por exemplo, aquí está o meu ficheiro:
/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 entón temos 1 exportador, necesitamos un segundo para supervisar a propia nebulosa, usei isto
Pódese engadir ao normal para supervisar o sistema o seguinte.
No ficheiro node_exporter cambiamos o inicio así:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorCree un directorio mkdir -p /var/lib/opennebula_exporter
script bash presentado anteriormente, primeiro comprobamos o traballo a través da consola, se mostra o que necesitamos (se dá un erro, entón instala xmlstarlet), cópiao en /usr/local/bin/opennebula_exporter.sh
Engade unha tarefa cron por cada minuto:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Comezaron a aparecer métricas, podes tomalas como un prometeo e construír gráficos e facer alertas. En Grafana pódese debuxar, por exemplo, un panel tan sinxelo.
(Está claro que aquí sobrecomito cpu, ram)
Para os que aman e usan Zabbix, hai
No que a vixilancia se refire, o principal é que estea aí. Por suposto, podes, ademais, usar as ferramentas integradas de monitorización da máquina virtual e cargar datos á facturación, aquí cada un ten a súa propia visión, aínda non comecei a traballar nisto máis de preto.
Aínda non comecei a rexistrar. A opción máis sinxela é engadir td-agent para analizar o directorio /var/lib/one con expresións regulares. Por exemplo, o ficheiro sunstone.log coincide coa expresión regular nginx e outros ficheiros que mostran o historial de acceso á plataforma. Cal é a vantaxe disto? Ben, por exemplo, podemos rastrexar explícitamente o número de "Erro, erro" e rastrexar rapidamente onde e en que nivel hai un mal funcionamento.
3. Backups
Tamén hai proxectos rematados de pago, por exemplo, o sept :OpenNebula_Backup. Aquí debemos entender que simplemente facer unha copia de seguranza dunha imaxe de máquina non é para nada o mesmo neste caso, porque as nosas máquinas virtuais deben funcionar cunha integración total (o mesmo ficheiro de contexto que describe a configuración da rede, o nome da máquina virtual e a configuración personalizada das súas aplicacións). . Polo tanto, aquí decidimos que e como copiaremos. Nalgúns casos é mellor facer copias do que hai na propia vm. E quizais só necesites facer unha copia de seguridade dun disco dunha determinada máquina.
Por exemplo, determinamos que todas as máquinas comezan con imaxes persistentes, polo tanto, despois de ler
Isto significa que primeiro podemos cargar a imaxe da nosa vm:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Tamén atopei en Internet e hai máis , pero só hai almacenamento para qcow2.
Pero como todos sabemos, tarde ou cedo chega un momento no que queres facer copias de seguridade incrementais, aquí é máis difícil e quizais a dirección destinará cartos a unha solución de pago, ou vaia ao outro lado e entendemos que aquí só estamos recortando recursos, e facer copias de seguridade a nivel de aplicación e engadir unha serie de novos nodos e máquinas virtuais; si, aquí digo que usar a nube só para lanzar clústeres de aplicacións e lanzar a base de datos noutra plataforma ou tomar unha xa preparada. do provedor, se é posible.
4. Facilidade de uso
Neste parágrafo describirei os problemas que atopei. Por exemplo, segundo as imaxes, como sabemos, hai persistente: cando esta imaxe se monta nunha máquina virtual, todos os datos escriben nesta imaxe. E se non é persistente, entón a imaxe cópiase no almacenamento e os datos escríbense no que se copiou da imaxe de orixe; así funcionan os modelos de modelos. Causeime repetidamente problemas ao esquecerme de especificar persistente e copiouse a imaxe de 200 GB, o problema é que este procedemento certamente non se pode cancelar, tes que ir ao nodo e matar o proceso "cp" actual.
Unha das desvantaxes importantes é que non pode cancelar accións simplemente usando a interface gráfica. Ou mellor dito, cancelalas e verás que non pasa nada e volveras a comezar, cancelalas e de feito xa haberá 2 procesos cp que copien a imaxe.
E entón trátase de entender por que opennebula numera cada nova instancia cun novo id, por exemplo, no mesmo proxmox creou unha máquina virtual co id 101, eliminouno, despois críao de novo e id 101. En opennebula isto non sucederá, cada nova instancia crearase cun novo ID e isto ten a súa propia lóxica, por exemplo, borrar datos antigos ou instalacións sen éxito.
O mesmo ocorre co almacenamento; sobre todo, esta plataforma está dirixida ao almacenamento centralizado. Hai complementos para usar local, pero non é o que estamos a falar neste caso. Creo que no futuro alguén escribirá un artigo sobre como conseguiron usar o almacenamento local en nós e usalo con éxito na produción.
5. Máxima sinxeleza
Por suposto, canto máis lonxe vaias, menos serán os que te entenderán.
Baixo as condicións do meu stand - 3 nodos con almacenamento nfs - todo funciona ben. Pero se realizamos experimentos que impliquen un corte de enerxía, por exemplo, ao executar unha instantánea e apagar a alimentación do nodo, gardamos a configuración na base de datos de que hai unha instantánea, pero en realidade non a hai (ben, todos entendemos que inicialmente escribiu a base de datos sobre esta acción en sql , pero a operación en si non foi exitosa). A vantaxe é que ao crear unha instantánea, fórmase un ficheiro separado e hai un "pai", polo tanto, en caso de problemas e aínda que non funcione a través da gui, podemos recoller o ficheiro qcow2 e restauralo por separado
Nas redes, por desgraza, non todo é tan sinxelo. Ben, polo menos é máis fácil que en openstack, usei só vlan (802.1Q): funciona bastante ben, pero se fai cambios na configuración desde a rede de modelos, esta configuración non se aplicará ás máquinas que xa están en execución, é dicir. cómpre eliminar e engadir unha tarxeta de rede, entón aplicarase a nova configuración.
Se aínda queres comparalo con openstack, podes dicir isto: en opennebula non hai unha definición clara de que tecnoloxías usar para almacenar datos, xestionar a rede, recursos - cada administrador decide por si mesmo o que é máis conveniente para el.
6. Complementos e instalacións adicionais
Despois de todo, segundo entendemos, a plataforma na nube pode xestionar non só kvm, senón tamén vmware esxi. Desafortunadamente, non tiña unha piscina con Vcenter, se alguén o intentou, escriba.
Indícase o soporte para outros provedores de nube
AWS, AZUR.
Tamén tentei conectar Vmware Cloud desde Selectel, pero nada funcionou; en xeral, bloqueouse porque hai moitos factores e non ten sentido escribir ao soporte técnico do provedor de hospedaxe.
Ademais, agora a nova versión ten firecracker: este é o lanzamento de microvm, un tipo de arnés kvm sobre docker, que dá aínda máis versatilidade, seguridade e maior produtividade porque non hai que desperdiciar recursos en emular equipos. A única vantaxe que vexo sobre Docker é que non ocupa un número adicional de procesos e non hai sockets ocupados ao usar esta emulación, é dicir. É moi posible usalo como equilibrador de carga (pero probablemente paga a pena escribir un artigo separado sobre isto ata que teña realizado todas as probas).
7. Experiencia positiva de uso e depuración de erros
Quería compartir as miñas observacións sobre a obra, describín algunhas delas arriba, gustaríame escribir máis. De feito, probablemente non sexa o único que ao principio pensa que este non é o sistema correcto e, en xeral, todo aquí é unha muleta, como funcionan con isto? Pero entón chega a entender que todo é bastante lóxico. Por suposto, non pode agradar a todos e algúns aspectos requiren melloras.
Por exemplo, unha operación sinxela de copiar unha imaxe de disco dun almacén de datos a outro. No meu caso, hai 2 nodos con nfs, mando a imaxe - a copia prodúcese a través da opennebula frontend, aínda que todos estamos afeitos a que os datos se copien directamente entre hosts - no mesmo vmware, hyper-v estamos afeito a isto, pero aquí a outro. Hai un enfoque diferente e unha ideoloxía diferente, e na versión 5.12 eliminaron o botón "migrar ao almacén de datos": só se transfire a máquina en si, pero non o almacenamento porque significa almacenamento centralizado.
O seguinte é un erro popular con varios motivos: "Erro ao implementar a máquina virtual: non se puido crear o dominio desde /var/lib/one//datastores/103/10/deployment.5" Abaixo está o principal que hai que ver.
- Dereitos de imaxe para o usuario oneadmin;
- Permisos para que o usuario oneadmin execute libvirtd;
- O almacén de datos está montado correctamente? Vaia e comprobe o camiño no propio nodo, quizais se caeu algo;
- Rede configurada incorrectamente, ou máis ben na interface é na configuración de rede onde a interface principal para vlan é br0, pero no nodo está escrito como bridge0 - debe ser o mesmo.
O almacén de datos do sistema almacena metadatos para a túa máquina virtual, se executas a máquina virtual cunha imaxe persistente, entón a máquina virtual debe ter acceso á configuración creada inicialmente no almacenamento onde creaches a máquina virtual; isto é moi importante. Polo tanto, ao transferir unha máquina virtual a outro almacén de datos, cómpre comprobar todo.
8. Documentación, comunidade. Desenvolvemento posterior
E o resto, boa documentación, comunidade e o principal é que o proxecto siga vivindo no futuro.
En xeral, todo está bastante ben documentado e mesmo usando unha fonte oficial non será un problema para instalar e atopar respostas ás preguntas.
Comunidade, activa. Publica moitas solucións preparadas que podes usar nas túas instalacións.
Polo momento, algunhas políticas na empresa cambiaron desde o 5.12 Será interesante ver como se desenvolve o proxecto. Ao principio, apuntei especificamente algúns dos provedores que usan as súas solucións e o que ofrece a industria. Por suposto, non hai unha resposta clara sobre o que usar. Pero para as organizacións máis pequenas, manter a súa pequena nube privada pode non ser tan caro como parece. O principal é saber exactamente o que necesitas.
Como resultado, independentemente do que elixas como sistema na nube, non debes deterte nun produto. Se tes tempo, paga a pena botar unha ollada a outras solucións máis abertas.
Hai unha boa charla Axudan activamente e non che envían a buscar unha solución ao problema en Google. Únete a nós.
Fonte: www.habr.com