Introducción
Proyecto de código abierto — una plataforma de virtualización de nivel empresarial. Al revisar habr, descubrí que no se ha discutido aquí tan ampliamente como merece.
oVirt es básicamente el upstream para el sistema comercial Red Hat Virtualization (RHV, anteriormente RHEV), creciendo bajo el ala de Red Hat. Para evitar confusiones, esto no es lo mismo que CentOS vs RHEL, el modelo es más parecido a Fedora vs RHEL.
Bajo el capó — , se utiliza una interfaz web para la gestión. Está basado en RHEL/CentOS 7.
oVirt puede ser utilizado tanto para virtualización de servidores "tradicional" como de escritorio (VDI), a diferencia de la solución de VMware, ambos sistemas pueden coexistir en un mismo entorno.
El proyecto está bien , ha alcanzado la madurez para aplicaciones productivas y está listo para altas cargas.
Este artículo es el primero de un ciclo sobre cómo construir un clúster redundante en funcionamiento. Siguiendo estos pasos, en un corto período (alrededor de 2 horas) obtendremos un sistema completamente funcional, aunque no se podrán abordar varios temas, trataré de iluminarlos en los siguientes artículos.
Lo hemos estado utilizando durante varios años, comenzamos con la versión 4.1. Nuestro sistema industrial ahora funciona en los servidores HPE Synergy 480 y ProLiant BL460c de 10ª generación con CPU Xeon Gold.
En el momento de escribir esto, la versión activa es la 4.3.
Artículos
- Introducción (Estamos aquí)
Características funcionales
En oVirt hay 2 entidades principales: ovirt-engine y ovirt-host(s). Para aquellos que están familiarizados con los productos de VMware, oVirt en general como plataforma es vSphere, ovirt-engine — la capa de gestión — cumple las mismas funciones que vCenter, y ovirt-host es el hipervisor, como ESX(i). Dado que vSphere es una solución muy popular, a veces haré comparaciones con ella.
Fig. 1 — panel de control de oVirt.
Se admite la mayoría de las distribuciones de Linux y versiones de Windows como máquinas invitadas. Para las máquinas invitadas hay agentes y dispositivos virtuales optimizados y controladores virtio, principalmente el controlador de disco y la interfaz de red.
Para implementar una solución de alta disponibilidad y todas las funciones interesantes se requerirá almacenamiento compartido. Se admiten tanto el almacenamiento en bloque FC, FCoE, iSCSI, como los almacenamiento de archivos NFS, entre otros. Para implementar una solución de alta disponibilidad, el sistema de almacenamiento también debe ser redundante (mínimo 2 controladores, multipathing).
El uso de almacenamiento local es posible, pero por defecto, solo se pueden utilizar almacenamientos compartidos para un clúster real. Los almacenamientos locales convierten el sistema en un conjunto desarticulado de hipervisores, y aunque haya un almacenamiento compartido, no será posible formar un clúster. La opción más adecuada es utilizar máquinas sin disco con arranque desde SAN o discos de volumen mínimo. Probablemente, mediante un vdsm hook, es posible ensamblar almacenamiento definido por software (por ejemplo, Ceph) a partir de discos locales y presentarlo a las máquinas virtuales, aunque no se ha considerado seriamente.
Arquitectura
Fig. 2 — arquitectura de oVirt.
Para más detalles sobre la arquitectura, puedes consultar la documentación del desarrollador.
Fig. 3 — objetos de oVirt.
El elemento superior en la jerarquía es el Centro de Datos. Este define si se utilizan almacenamientos compartidos o locales, así como el conjunto de funciones disponibles (compatibilidad, de 4.1 a 4.3). Puede haber uno o varios. Para muchas opciones, es adecuado utilizar el Centro de Datos por defecto — Default.
El Centro de Datos consta de uno o varios Clústeres. Un clúster define el tipo de procesador, las políticas de migración, entre otros. Para instalaciones pequeñas, también se puede limitar a usar el clúster por defecto.
Un clúster, a su vez, se compone de Hosthosts que realizan el trabajo principal: transportan máquinas virtuales y están conectados a los almacenamientos. Se espera que haya 2 o más hosts en un clúster. Aunque técnicamente es posible hacer un clúster con un solo host, no tiene ninguna utilidad práctica.
oVirt admite muchas funciones, incluida la migración en vivo de máquinas virtuales entre hipervisores (live migration) y entre almacenamientos (storage migration), virtualización de escritorio (virtual desktop infrastructure) con grupos de máquinas virtuales, máquinas virtuales stateful y stateless, soporte para NVidia Grid vGPU, importación desde vSphere, KVM, y muchas más. Todas estas funciones están disponibles sin pagos de licencia, y si se necesita soporte, se puede adquirir a través de Red Hat a través de socios regionales. Sobre los precios de RHV
El costo no es alto comparado con VMware, solo se compra el soporte, sin la obligación de adquirir la licencia en sí. El soporte se compra solo para los hipervisores, ovirt-engine, a diferencia de vCenter Server que requiere gastos adicionales.
Ejemplo de cálculo para el primer año de propiedad
Consideremos un clúster de 4 máquinas de 2 sockets y precios al por menor (sin descuentos por proyecto).
La suscripción estándar de RHV
cuesta $999 Precio de vSphere$7992.
:
- VMware vCenter Server Standard $10,837.13 por instancia, más suscripción Basic $2,625.41 (Producción — $3,125.39);
- VMware vSphere Standard $1,164.15 + Suscripción Básica $552.61 (Producción $653.82);
- VMware vSphere Enterprise Plus $6,309.23 + Suscripción Básica $1,261.09 (Producción $1,499.94).
Total: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 para la opción más básica. ¡La diferencia es de aproximadamente 3.5 veces!
En oVirt, todas las funciones están disponibles sin restricciones.
Características breves y máximos
Requisitos del sistema
El hipervisor requiere un CPU con virtualización por hardware habilitada, un mínimo de RAM para iniciar — 2 GiB, un volumen de almacenamiento recomendado para el SO — 55 GiB (principalmente para registros, etc., el SO ocupa poco).
Más información — .
Para requisitos mínimos 2 núcleos/4 GiB de RAM/25 GiB de almacenamiento. Recomendados — desde 4 núcleos/16 GiB de RAM/50 GiB de almacenamiento.
Como en cualquier sistema, hay limitaciones en los tamaños y cantidades, la mayoría de las cuales superan las capacidades de los servidores comerciales masivos disponibles. Así, un par puede direccionar 2 TiB de RAM y proporciona 40 núcleos (80 hilos), que es menos incluso que los límites de una VM.
Máximos de Máquinas Virtuales:
- Máximo de máquinas virtuales que se pueden ejecutar simultáneamente: Ilimitado;
- Máximo de CPUs virtuales por máquina virtual: 384;
- Máxima memoria por máquina virtual: 4 TiB;
- Máximo tamaño de disco único por máquina virtual: 8 TiB.
Máximos del Host:
- Núcleos o hilos lógicos de CPU: 768;
- RAM: 12 TiB;
- Número de máquinas virtuales alojadas: 250;
- Migraciones en vivo simultáneas: 2 entrantes, 2 salientes;
- Ancho de banda de migración en vivo: Predeterminado a 52 MiB (~436 Mb) por migración al usar la política de migración heredada. Otras políticas utilizan valores de rendimiento adaptativos basados en la velocidad del dispositivo físico. Las políticas de QoS pueden limitar el ancho de banda de migración.
Máximos de Entidad Lógica del Administrador:
En la 4.3 existen .
- Centro de datos
- Máximo de centros de datos: 400;
- Máximo de hosts: 400 soportados, 500 probados;
- Máximo de VM: 4000 soportadas, 5000 probadas;
- Clúster
- Máximo de clústeres: 400;
- Máximo de hosts: 400 soportados, 500 probados;
- Máximo de VM: 4000 soportadas, 5000 probadas;
- Red
- Redes lógicas/clúster: 300;
- Redes SDN/exteriores: 2600 probadas, sin límite impuesto;
- Almacenamiento
- Máximo de dominios: 50 soportados, 70 probados;
- Hosts por dominio: Sin límite;
- Volúmenes lógicos por dominio de bloque (más): 1500;
- Número máximo de LUNs (más): 300;
- Tamaño máximo de disco: 500 TiB (limitado a 8 TiB por defecto).
Opciones de implementación
Como se mencionó anteriormente, oVirt se construye a partir de 2 elementos básicos: ovirt-engine (administración) y ovirt-host (hipervisor).
Engine puede residir fuera de la propia plataforma (el Administrador autónomo puede ser una VM ejecutada en otra plataforma o en un hipervisor separado e incluso una máquina física), así como dentro de la plataforma (motor auto-alojado, similar al enfoque VCSA de VMware).
El hipervisor puede instalarse en (EL Host), así como en (oVirt-Node, basado en el7).
Los requisitos de hardware para todas las opciones son aproximadamente los mismos.
Fig. 4 — arquitectura estándar.
Fig. 5 — Arquitectura de Engine autoalojado.
He elegido la opción de Manager independiente y EL Hosts:
- el Manager independiente es un poco más sencillo en problemas de arranque, no hay el dilema del huevo y la gallina (al igual que para VCSA — no se inicia hasta que al menos un host esté completamente levantado), pero surge una dependencia de otro sistema*;
- EL Host proporciona todo el poder del sistema operativo, lo que es útil para la monitorización externa, depuración, solución de problemas, etc.
* Sin embargo, durante todo el tiempo de operación esto no fue necesario, incluso después de un grave accidente de energía.
¡Pero ya vamos al grano!
Para el experimento, hay posibilidad de liberar un par de cuchillas ProLiant BL460c G7 con CPU Xeon®. En ellas vamos a reproducir el proceso de instalación.
Daremos a los nodos los nombres ovirt.lab.example.com, kvm01.lab.example.com y kvm02.lab.example.com.
Pasemos directamente a .
Fuente: habr.com
