introduction
projet open source est une plate-forme de virtualisation gratuite de niveau entreprise. En parcourant habr, j'ai trouvé que n'est pas couvert aussi largement qu'il le mérite.
oVirt est en fait en amont du système commercial Red Hat Virtualization (RHV, anciennement RHEV), qui se développe sous l'aile de Red Hat. Pour éviter toute confusion, cette aucun identique à CentOS vs RHEL, modèle plus proche de Fedora vs RHEL.
Sous la capuche - , l'interface Web est utilisée pour la gestion. Basé sur le système d'exploitation RHEL/CentOS 7.
oVirt peut être utilisé à la fois pour la virtualisation "traditionnelle" des serveurs et des postes de travail (VDI), contrairement à la solution VMware, les deux systèmes peuvent coexister dans un même complexe.
Bien projeter , a depuis longtemps atteint sa maturité pour une utilisation productive et est prêt pour des charges élevées.
Cet article est le premier d'une série sur la création d'un cluster de basculement fonctionnel. Après les avoir parcourus, en peu de temps (environ 2 heures), nous obtiendrons un système entièrement fonctionnel, bien qu'un certain nombre de problèmes, bien sûr, ne puissent pas être divulgués, je vais essayer de les couvrir dans les articles suivants.
Nous l'utilisons depuis plusieurs années, nous avons commencé avec la version 4.1. Notre système industriel repose désormais sur des calculs HPE Synergy 480 et ProLiant BL460c de 10e génération avec des processeurs Xeon Gold.
Au moment de la rédaction, la version actuelle est la 4.3.
Articles
- Présentation (nous sommes là)
Caractéristiques fonctionnelles
Il existe 2 entités principales dans oVirt : ovirt-engine et ovirt-host(s). Pour ceux qui connaissent les produits VMware, oVirt dans son ensemble en tant que plate-forme est vSphere, ovirt-engine - la couche de contrôle - remplit les mêmes fonctions que vCenter, et ovirt-host est un hyperviseur, comme ESX (i). Parce que vSphere est une solution très populaire, parfois je vais la comparer avec elle.
Riz. 1 - Panneau de contrôle oVirt.
La plupart des distributions Linux et des versions Windows sont prises en charge en tant que machines invitées. Pour les machines invitées, il existe des agents et des périphériques virtuels optimisés et des pilotes virtio, principalement un contrôleur de disque et une interface réseau.
Pour implémenter une solution tolérante aux pannes et toutes les fonctionnalités intéressantes, vous aurez besoin d'un stockage partagé. Les stockages bloc FC, FCoE, iSCSI et NFS de fichiers sont pris en charge, etc. Pour mettre en œuvre une solution tolérante aux pannes, le système de stockage doit également être tolérant aux pannes (au moins 2 contrôleurs, multipassage).
L'utilisation de stockages locaux est possible, mais par défaut seuls les stockages partagés conviennent à un vrai cluster. Les stockages locaux font du système un ensemble disparate d'hyperviseurs, et même avec un stockage partagé, un cluster ne peut pas être assemblé. La méthode la plus correcte consiste à utiliser des machines sans disque avec démarrage à partir du SAN ou des disques de taille minimale. Probablement, via le crochet vdsm, il est possible de construire à partir de disques locaux de stockage défini par logiciel (par exemple, Ceph) et de présenter sa VM, mais je ne l'ai pas sérieusement envisagé.
Architecture
Riz. 2 - Architecture oVirt.
Plus d'informations sur l'architecture peuvent être trouvées dans développeur.
Riz. 3 - Objets oVirt.
L'élément supérieur de la hiérarchie - Centre de données. Il détermine si le stockage partagé ou local est utilisé, ainsi que l'ensemble de fonctionnalités utilisé (compatibilité, 4.1 à 4.3). Il peut y en avoir un ou plusieurs. Pour de nombreuses options, l'utilisation du centre de données par défaut est Par défaut.
Le centre de données se compose d'un ou plusieurs Clusters. Le cluster détermine le type de processeur, les politiques de migration, etc. Pour les petites installations, vous pouvez également vous limiter au cluster par défaut.
Le cluster, à son tour, se compose de Hôte's qui effectuent le travail principal - ils transportent des machines virtuelles, des stockages leur sont connectés. Le cluster suppose 2 hôtes ou plus. Bien qu'il soit techniquement possible de créer un cluster avec 1 hôte, cela n'est pas d'une utilité pratique.
oVirt prend en charge de nombreuses fonctionnalités, incl. migration en direct de machines virtuelles entre hyperviseurs (migration en direct) et stockages (migration de stockage), virtualisation de bureau (infrastructure de bureau virtuel) avec pools de VM, VM avec et sans état, prise en charge de NVidia Grid vGPU, importation depuis vSphere, KVM, il existe un puissant et beaucoup plus. Toutes ces fonctionnalités sont disponibles sans redevance et, si nécessaire, une assistance peut être achetée auprès de Red Hat via des partenaires régionaux.
À propos des prix RHV
Le coût n'est pas élevé par rapport à VMware, seul le support est acheté - sans qu'il soit nécessaire d'acheter la licence elle-même. Le support est acheté uniquement pour les hyperviseurs, ovirt-engine, contrairement à vCenter Server, ne nécessite aucune dépense.
Exemple de calcul pour la 1ère année de détention
Considérez un groupe de 4 machines à 2 sockets et les prix de détail (pas de remises de projet).
Abonnement Standard RHV par socket/an (premium 365/24/7 - 1499 $), total 4*2*999 $=$7992.
:
- VMware vCenter Server Standard 10,837.13 2,625.41 $ par instance plus abonnement de base 3,125.39 XNUMX $ (Production XNUMX XNUMX $) ;
- VMware vSphere Standard 1,164.15 552.61 $ + Abonnement de base 653.82 $ (Production XNUMX $) ;
- VMware vSphere Enterprise Plus 6,309.23 1,261.09 $ + Abonnement de base 1,499.94 XNUMX $ (Production XNUMX XNUMX $).
Total : 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = 27 $ 196,62 pour la plus petite option. La différence est d'environ 3,5 fois !
Dans oVirt, toutes les fonctions sont disponibles sans restriction.
Brèves caractéristiques et maximums
Системные требования
L'hyperviseur nécessite un processeur avec la virtualisation matérielle activée, la quantité minimale de RAM pour démarrer est de 2 Gio, la quantité de stockage recommandée pour l'OS est de 55 Gio (principalement pour les journaux, etc., l'OS lui-même prend peu).
Plus de détails - .
Pour configuration minimale requise 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 pour tout système, il existe des limites de volumes et de quantités, dont la plupart dépassent les capacités des serveurs commerciaux de masse disponibles. Oui, un couple. peut adresser 2 TiB de RAM et donne 40 cœurs (80 threads), ce qui est encore moins que les limites d'une VM.
Maximums de machines virtuelles :
- Nombre maximal de machines virtuelles exécutées simultanément : illimité ;
- CPU virtuels maximum par machine virtuelle : 384 ;
- Mémoire maximale par machine virtuelle : 4 Tio ;
- Taille maximale de disque unique par machine virtuelle : 8 Tio.
Maximums d'hôte :
- Cœurs ou threads de CPU logiques : 768 ;
- RAM : 12 Tio
- Nombre de machines virtuelles hébergées : 250 ;
- Migrations dynamiques simultanées : 2 entrantes, 2 sortantes ;
- Bande passante de migration en direct : par défaut, 52 Mio (~436 Mo) par migration lors de l'utilisation de la politique de migration héritée. D'autres politiques utilisent des valeurs de débit adaptatives basées sur la vitesse de l'appareil physique. Les politiques de QoS peuvent limiter la bande passante de migration.
Nombre maximal d'entités logiques du gestionnaire :
En 4.3 il y a .
- Centre de données
- Nombre maximal de centres de données : 400 ;
- Nombre maximum d'hôtes : 400 pris en charge, 500 testés ;
- Nombre maximal de machines virtuelles : 4000 5000 prises en charge, XNUMX XNUMX testées ;
- Grappe
- Nombre maximal de clusters : 400 ;
- Nombre maximum d'hôtes : 400 pris en charge, 500 testés ;
- Nombre maximal de machines virtuelles : 4000 5000 prises en charge, XNUMX XNUMX testées ;
- Réseau
- Réseaux logiques/cluster : 300
- SDN/réseaux externes : 2600 XNUMX testés, aucune limite imposée ;
- Stockage
- Domaines maximum : 50 pris en charge, 70 testés ;
- Hôtes par domaine : Aucune limite ;
- Volumes logiques par domaine de bloc (plus) : 1500 XNUMX ;
- Nombre maximum de LUN (plus) : 300 ;
- Taille maximale du disque : 500 Tio (limité à 8 Tio par défaut).
Options de mise en œuvre
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é à la fois en dehors de la plate-forme elle-même (gestionnaire autonome - il peut s'agir d'une machine virtuelle exécutée sur une autre plate-forme ou d'un hyperviseur séparé, voire d'une machine physique) et sur la plate-forme elle-même (moteur auto-hébergé, similaire au VCSA de VMware approche).
L'hyperviseur peut être installé sur (hôte EL) et (oVirt-Node, basé sur el7).
La configuration matérielle requise pour toutes les variantes est approximativement la même.
Riz. 4 - Architecture standard.
Riz. 5 - Architecture du moteur auto-hébergé.
Pour ma part, j'ai choisi l'option autonome Manager et EL Hosts :
- le gestionnaire autonome est un peu plus facile avec les problèmes de démarrage, il n'y a pas de dilemme de la poule et de l'œuf (comme pour VCSA - vous ne démarrerez pas 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, le dépannage, etc.
* Cependant, cela n'a pas été nécessaire pendant toute la période de fonctionnement, même après une grave panne de courant.
Mais plus au point!
Pour l'expérimentation, il est possible de sortir une paire de lames ProLiant BL460c G7 avec CPU Xeon®. Nous y reproduirons le processus d'installation.
Nommons les nœuds ovirt.lab.example.com, kvm01.lab.example.com et kvm02.lab.example.com.
Passons directement à .
Source: habr.com