Introduction
Projet open source — plateforme de virtualisation libre de niveau entreprise. En parcourant habr, j'ai découvert que il n'est pas couvert ici aussi largement qu'il le mérite.
oVirt est en fait la version amont du système commercial Red Hat Virtualization (RHV, précédemment RHEV), évoluant sous l'égide de Red Hat. Pour éviter toute confusion, c'est ne la même chose que CentOS vs RHEL, le modèle étant plus proche de Fedora vs RHEL.
Sous le capot — , pour la gestion, une interface web est utilisée. Basée sur RHEL/CentOS 7.
oVirt peut être utilisé pour la virtualisation « traditionnelle » des serveurs ainsi que pour la virtualisation de bureau (VDI), contrairement à la solution VMware, les deux systèmes peuvent coexister au sein d'un même complexe.
Le projet est bien , a depuis longtemps atteint une maturité pour une utilisation productive et est prêt pour des charges élevées.
Cet article est le premier d'un cycle sur la manière de construire un cluster tolérant aux pannes. En suivant ces étapes, nous obtiendrons en peu de temps (environ 2 heures) un système entièrement fonctionnel, bien que certaines questions, bien sûr, ne puissent pas être abordées, j'essaierai de les éclaircir dans les prochains articles.
Nous l'utilisons depuis plusieurs années, ayant commencé avec la version 4.1. Notre système industriel fonctionne actuellement sur des calculateurs HPE Synergy 480 et ProLiant BL460c de 10e génération avec des CPU Xeon Gold.
Au moment de la rédaction, la version actuelle est 4.3.
Articles
- Introduction (Nous y sommes)
Fonctionnalités
Dans oVirt, il existe 2 entités principales : ovirt-engine et ovirt-host(s). Pour ceux qui connaissent bien les produits VMware, oVirt en tant que plateforme équivaut à vSphere, ovirt-engine — la couche de gestion — remplit les mêmes fonctions que vCenter, et ovirt-host — l'hyperviseur, comme ESX(i). Étant donné que vSphere est une solution très populaire, je feront parfois des comparaisons avec elle.
Fig. 1 — panneau de contrôle d'oVirt.
Pour les machines invitées, la plupart des distributions Linux et des versions de Windows sont prises en charge. Pour les machines invitées, il existe des agents et des périphériques virtuels optimisés ainsi que des pilotes virtio, principalement le contrôleur de disque et l'interface réseau.
Pour mettre en place une solution tolérante aux pannes et toutes les fonctionnalités intéressantes, un stockage partagé sera nécessaire. À la fois des stockages bloc FC, FCoE, iSCSI et des stockages de fichiers NFS sont pris en charge, entre autres. Pour implémenter une solution tolérante aux pannes, le système de stockage doit également être tolérant aux pannes (au moins 2 contrôleurs, multipathing).
L'utilisation de stockages locaux est possible, mais par défaut, seuls les stockages partagés conviennent pour un véritable cluster. Les stockages locaux rendent le système hétérogène composé d'hyperviseurs, et même avec un stockage partagé, il est impossible de former un cluster. Le chemin le plus juste consiste à utiliser des machines sans disque avec boot from SAN, ou des disques de taille minimale. Il est probablement possible, via vdsm hook, de assembler des disques locaux en un stockage défini par logiciel (comme Ceph) et de le présenter aux VM, mais cela n'a pas été sérieusement considéré.
Architecture
Fig. 2 — architecture d'oVirt.
Pour en savoir plus sur l'architecture, consultez le développeur.
Fig. 3 — objets d'oVirt.
L'élément supérieur de la hiérarchie est Centre de données. Il détermine si des stockages partagés ou locaux sont utilisés, ainsi que l'ensemble des fonctionnalités utilisées (compatibilité, de 4.1 à 4.3). Il peut y en avoir un ou plusieurs. Pour de nombreuses options, l'utilisation du Data Center par défaut est acceptable — Default.
Le Data Center se compose d'un ou plusieurs Clusters. Le cluster définit le type de processeur, les politiques de migration, etc. Pour de petites installations, il est également possible de se contenter du cluster Default.
Le cluster, à son tour, se compose de Hôtehôtes, effectuant le travail principal — ils portent des machines virtuelles, et du stockage leur est connecté. Dans un cluster, il est supposé qu'il y a 2 hôtes ou plus. Bien qu'il soit techniquement possible de créer un cluster avec un seul hôte, cela n'a que peu d'intérêt pratique.
oVirt prend en charge de nombreuses fonctionnalités, y compris la migration en direct des machines virtuelles entre hyperviseurs (live migration) et des stockages (storage migration), la virtualisation de bureau (virtual desktop infrastructure) avec des pools de VM, des VM statefull et stateless, la prise en charge de NVidia Grid vGPU, l'importation à partir de vSphere, KVM, et dispose d'une robuste et bien d'autres. Toutes ces fonctionnalités sont disponibles sans frais de licence, et si un support est nécessaire, il peut être acheté auprès de Red Hat via des partenaires régionaux.
Concernant les prix de RHV
Le coût est faible par rapport à VMware, seule la support est acheté — sans obligation d'achat de la licence elle-même. Le support est seulement acquis pour les hyperviseurs, ovirt-engine, contrairement à vCenter Server qui nécessite des dépenses.
Exemple de calcul pour la première année de possession
Considérons un cluster de 4 machines à 2 sockets et les prix au détail (sans réductions projet).
L'abonnement standard RHV par socket/an (premium 365/24/7 — 1499 $), soit 4*2*999=$7992.
:
- VMware vCenter Server Standard 10 837,13 $ par instance, plus abonnement Basic 2 625,41 $ (Production — 3 125,39 $);
- VMware vSphere Standard 1 164,15 $ + Abonnement Basic 552,61 $ (Production 653,82 $);
- VMware vSphere Enterprise Plus 6 309,23 $ + Abonnement Basic 1 261,09 $ (Production 1 499,94 $).
Total : 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $27 196,62 pour l'option la plus basique. La différence est d'environ 3,5 fois !
Dans oVirt, toutes les fonctionnalités sont disponibles sans restrictions.
Caractéristiques et maximums
Exigences système
Pour l'hyperviseur, un CPU avec virtualisation matérielle activée est nécessaire, la mémoire RAM minimale pour démarrer est de 2 Go, et l'espace de stockage recommandé pour le système d'exploitation est de 55 Go (principalement pour les journaux, le système d'exploitation lui-même occupe peu).
Pour en savoir plus — .
Pour exigences minimales 2 cœurs / 4 Go de RAM / 25 Go de stockage. Recommandé — à partir de 4 cœurs / 16 Go de RAM / 50 Go de stockage.
Comme dans tout système, il existe des limites sur les volumes et les quantités, dont la plupart dépassent les capacités des serveurs commerciaux massifs disponibles. Ainsi, une paire peut adresser 2 To de RAM et fournit 40 cœurs (80 threads), ce qui est même inférieur aux limites d'une VM.
Maximums des machines virtuelles :
- Nombre maximum de machines virtuelles fonctionnant simultanément : Illimité ;
- Nombre maximum de vCPU par machine virtuelle : 384 ;
- Mémoire maximum par machine virtuelle : 4 To ;
- Taille maximum d'un disque unique par machine virtuelle : 8 To.
Maximums de l'hôte :
- Cœurs CPU logiques ou threads : 768 ;
- RAM : 12 To ;
- Nombre de machines virtuelles hébergées : 250 ;
- Migrations en direct simultanées : 2 entrantes, 2 sortantes ;
- Bande passante de migration en direct : Par défaut 52 MiB (~ 436 Mb) par migration lors de l'utilisation de la politique de migration héritée. D'autres politiques utilisent des valeurs de bande passante adaptatives basées sur la vitesse de l'appareil physique. Les politiques de QoS peuvent limiter la bande passante de migration.
Maximums d'entité logique du gestionnaire :
Dans 4.3, il existe .
- Centre de données
- Nombre maximum de centres de données : 400 ;
- Nombre maximum d'hôtes : 400 pris en charge, 500 testés ;
- Nombre maximum de VM : 4000 prises en charge, 5000 testées ;
- Cluster
- Nombre maximum de clusters : 400 ;
- Nombre maximum d'hôtes : 400 pris en charge, 500 testés ;
- Nombre maximum de VM : 4000 prises en charge, 5000 testées ;
- Réseau
- Réseaux logiques / cluster : 300 ;
- Réseaux SDN / externes : 2600 testés, pas de limite imposée ;
- Stockage
- Nombre maximum de domaines : 50 pris en charge, 70 testés ;
- Hôtes par domaine : Pas de limite ;
- Volumes logiques par domaine de bloc (plus) : 1500 ;
- Nombre maximum de LUNs (plus) : 300 ;
- Taille maximum du disque : 500 To (limité à 8 To par défaut).
Options de déploiement
Comme déjà mentionné, oVirt est construit à partir de 2 éléments de base — ovirt-engine (gestion) et ovirt-host (hyperviseur).
Le moteur peut être hébergé soit en dehors de la plateforme elle-même (le standalone Manager — cela peut être une VM exécutée sur une autre plateforme ou un hyperviseur séparé et même une machine physique), soit sur la plateforme elle-même (moteur auto-hébergé, similaire à l'approche VCSA de VMware).
L'hyperviseur peut être installé soit sur (EL Host), soit sur (oVirt-Node, basé sur el7).
Les exigences matérielles pour toutes les options sont à peu près les mêmes.
Fig. 4 — architecture standard.
Fig. 5 — Architecture du moteur auto-hébergé.
J'ai choisi l'option de gestionnaire autonome et EL Hosts :
- Le gestionnaire autonome est un peu plus simple en cas de problèmes de démarrage, il n'y a pas le dilemme de la poule et de l'œuf (comme pour VCSA — on ne peut pas démarrer tant qu'au moins un hôte n'est pas complètement opérationnel), mais il y a une dépendance à un autre système* ;
- EL Host fournit toute la puissance du système d'exploitation, ce qui est utile pour la surveillance externe, le débogage, la recherche de pannes, etc.
* Cependant, au cours de toute son utilisation, cela n'a jamais été nécessaire, même après une panne de courant majeure.
Mais nous y voici !
Pour l'expérience, nous avons la possibilité de libérer quelques lames ProLiant BL460c G7 avec CPU Xeon®. C'est sur elles que nous allons reproduire le processus d'installation.
Nous donnerons aux nœuds les noms ovirt.lab.example.com, kvm01.lab.example.com et kvm02.lab.example.com.
Passons directement à .
Source : habr.com
