Ma solution de Virtualisation

Souhaitant améliorer mon infrastructure serveur et voulant passer à quelque chose de plus robuste et de plus professionnel, j'ai décidé de passer à la virtualisation, car le principe me semblait intéressant même si je n'avais pas tant de connaissances sur le sujet à l'époque.
J'ai eu la chance de pouvoir réalisé ce projet personnel dans le cadre d'un PFE (Projet de fin d'étude) de mes études d'ingénieur informatique à l'ESIREM (Dijon).

Explication de la virtualisation :

Virtualisation fait référence à l’action de créer une version virtuelle de quelque chose, incluant le hardware/stockages/réseau. Utilisé en 1960 pour diviser les ressources par une machine entre différentes applications.

Depuis la découverte du concept de virtualisation, la façon de l'appliquer à beaucoup évoluée, et il y a plusieurs types de virtualisation.

Virtualisation matérielle

Hardware/platform virtualization en Anglais. C'est la création d'une machine virtuelle qui s'execute comme un vrai ordinateur avec son système d'exploitation propre.

En virtualisation matériel on utilise les termes de :

Machine hôte (host en anglais), c'est-à-dire la machine physique "réelle".
Machine invité (guest en anglais), la machine virtuelle (VM : Virtual Machine en anglais).

Les logiciels exécutés sur la VM sont séparés des ressources matériel de la machine physique.
En effet dans le cas d'une virtualisation complète le matériel est (presque) entièrement émulé permettant à l'environnement invité de s’exécuter sans modifier l'hôte.
Ce qui n'est pas le cas de la para-virtualisation.

Un exemple singulier de virtualisation est la virtualisation mobile, c'est-à-dire de la virtualisation matériel sur téléphones ou appareils connectés sans-fils. Cela utilise des hyperviseurs embarqués (embedded hypervisor). Mais aussi la virtualisation des postes de travail, l'infrastructure de bureau virtuel (VDI : virtual desktop infrastructure).

Conteneurisation

C'est de la virtualisation au niveau du système d'exploitation. La conteneurisation, fait référence à une fonctionnalité du système d'exploitation dans laquelle le noyau autorise l'existence de plusieurs instances isolées de l'espace utilisateur.
Ces instances, appelées conteneurs, peuvent ressembler à de vrais ordinateurs du point de vue des programmes qui y sont exécutés. Mais contrairement à une machine virtuelle, plutôt que de créer un OS virtuel entier, les conteneur n'ont pas besoin de dupliquer un système d'exploitation entier, mais seulement les composant individuel dont ils ont besoin pour fonctionner.

Un programme informatique exécuté sur un système d'exploitation ordinaire peut voir toutes les ressources (périphériques connectés, fichiers et dossiers, partages réseau, puissance du processeur, capacités matérielles quantifiables) de cet ordinateur. Toutefois, les programmes exécutés dans un conteneur ne peuvent voir que le contenu du conteneur et les périphériques attribués au conteneur.

L’intérêt envers la conteneurisation est l'apparition de Docker.
Gestion des conteneurs avec Kubernetes qui permet d'automatiser le déploiement, mise à l'échelle et gestion des applications conteneurisées.

Principes de la virtualisation:

Le logiciel qui crée et gère les VM s'appelle un hyperviseur (hypervisor).

Les principales fonctionnalités de la virtualisation sur des solutions de serveurs :

Les Snapshots

Une snapshot est l'état d'une machine virtuelle ainsi que ses données à un moment précis dans le temps. Ce qui permet de restaurer la machine à un état antérieur plus stable en cas de problème.

VM utilise généralement des disques virtuels pour le stockage des données ainsi le disque émulé de 10 Go est en fait un fichier de 10Go sur la machine hôte.

La migration

C'est le fait de déplacer une machine virtuelle entièrement opérationnelle d'une machine hôte à une autre. Cela se passe par un arrêt temporaire, la mise en place d'une sauvegarde (snapshot), le déplacement et la remise en route.
Avec l'utilisation de snapshot, il est même possible de déplacer une VM d'un hôte à un autre sans interruption du service qui tourne sur cette dernière.

Le basculement (failover)

C'est le fait de basculer sur un autre hôte si le présent plante en lançant la VM à partir d'une snapshot plus ou moins récente à celle sur l'hôte qui a planté.
Ainsi le service continue de fonctionner mais sur une autre machine physique.

Emulation de console de jeu vidéo

L'idée est de faire fonctionner une console, ou plutôt le logiciel d'une console, sur un ordinateur quelconque.

Virtualisation imbriquée

C'est le principe d'exécuter une machine virtuelle dans une autre, et cela autant de fois que voulu. C'est donc l'exécution d'un ou plusieurs hyperviseurs dans un autre hyperviseur.
Il est tout a fait possible d’exécuter des VMs dont le type est different de la VM hôte. Par exemple exécuter la virtualisation d'application au sein d'une machine virtuelle créée à l'aide de la virtualisation matérielle.

Avantages et Inconvénients :

La virtualisation à des avantages mais aussi des inconvénients par rapport à l'utilisation classique d'une machine et d'un système.

Avantages :

Les avantages :

moins de machine physique, puisque les serveurs sont virtuels.
augmente la flexibilité => limite/supprime les contraintes matérielles, avec notamment les principes vu ci-dessus. Déploiement rapide d'un nouveau service, sur une nouvelle machine virtuelle.
meilleures performances si répartition de la charge entre serveur ou allocation dynamique des ressources à une VM.
meilleure sécurité en séparant les services sur différentes machines.
facilite la mise-à-jour matériel.
création de nouveau serveur pour effectué des tests, de services ou autres, facilité. Plus besoin de machine de tests.

En clair : évolutif !

Inconvénients :

Les inconvénients :

infrastructure plus complexe.
investissement en temps et en argent supérieur.
si panne de l'unique machine hôte, tout les services sont inaccessibles.

Les rares inconvénients sont soit compensé par les avantages soit annulé par la mise en place de solutions techniques, notamment le cluster en cas de défaillance de la machine physique d'avoir l'ensemble des services inaccessibles, car les VMs sont exécutées sur plusieurs machines physiques en même temps.

Cahier des charges :

Définir le cahier des charges à partir de mes besoins à propos de l'infrastructure système et réseau que je souhaite obtenir à court moyen et long terme.

L'infrastructure souhaité :

Hyperviseur

┬
├► Datas qui monte le disque avec les VMs et les sites (si pas de Git) etc...
├► BDD => MariaDB
├► Web Forwarder & loadbalancing => Nginx
+ Conteneurisation ? => Docker & Kubernetes + Gestion HTTP & HTTPS
+ Infrastructure de développement efficace et automatisé : Dev → Test → Prod
│
├► Mail
├► Cloud (surement dans la partie web ↑), à partir d'un NAS (autre machine physique), documents/contenu multimedia/streaming
├► Git, pour mettre mes développements perso, mes sites (CV, ce BLog, etc..)
├► Jeu(s) : Serveur Minecraft
│
├► Tests : VMs de test
├► Hébergement : VMs pour les copains ou la famille
│
├► TeamSpeak
└► IA (avec Cartes graphique pour la VM)

Mes besoins

Cloud computing

Une forte évolutivité possible.
Système de cluster en cas d'acquisition de matériel supplémentaire (serveurs), accumulation des ressources matérielles pour ne faire qu'un serveur plus gros.
Possibilité d'allocation dynamique des ressources en fonction de la monté en charge des services, si possible, si ça existe.
Virtualisation de Bureau (VDI), possibilité dans un futur plus moyen voir long que court terme.

Infrastructure doit être overkill ! Parce que mes besoins sont pas énormes.

Comparatif solutions :

Classification critères Etude comparative, en fonction des ressources de la machine physique.

Comparatif entre VMs et Conteneurs

Conteneurs ont une amélioration significative des performances et une réduction de la taille de l'application.
Ils fonctionnent également beaucoup plus rapidement, car contrairement à la virtualisation traditionnelle, le processus s’exécute essentiellement de manière native sur son hôte, avec simplement une couche de protection supplémentaire. IBM a comparé les performances KVM vs Docker.
De plus la vitesse de déploiement est plus intéressantes avec Docker.

Mais cela nécessite que chaque application conteneurisée puissent tourner sur le même OS.

La sécurité semble plus fiable avec des VMs.

Les hyperviseurs

Un hyperviseur (hypervisor en anglais) ou moniteur de machine virtuelle (VMM : virtual machine monitor) est un système matériel ou logiciel, normal (software) ou bas-niveau (firmware), qui créer et gère les machines virtuelles.

La classification

Il y a 2 types d'hyperviseurs :

Type-1 : Hyperviseurs natifs (native en anglais), il tourne directement sur la couche matériel de la machine hôte, il est un outil de contrôle de système d'exploitation, un OS peut donc être exécuté au-dessus du matériel. L'hyperviseur type 1 est un noyau hôte allégé et optimisé.
L'OS invité s'exécuterai au 2ème niveau au-dessus du matériel.

Quelques exemples :
- Hyper-V de Microsoft
- ESXi de VMware
- VM Server for x86 de Oracle
- VM Server for SPARC de Oracle
- z/VM de IBM
- Xen Project
- KVM
Type-2 : Hyperviseur hébergé (hosted en anglais), est un logiciel qui s'exécute dans un OS.
L'OS invité s'exécuterai au 3ème niveau au-dessus du matériel.

Quelques exemples :

Cas KVM

Le cas de KVM est particulier, en effet le module noyaux KVM transforme le noyau Linux en hyperviseur de type-1, mais le système global peut être classé en type-2 car l'OS hôte est toujours pleinement fonctionnel et le VMs sont des processus Linux standard de son point de vue.

Conclusion

La typologie des hyperviseurs n'est plus vraiment utile, en effet le limites entre les 2 est très fine et il est difficile de savoir quel est le type d'un hyperviseur à première vue:

Choix de ma solution :

Quoi comparer

Les points à comparer pour choisir une solution dans mon cas personnel :

efficacité, possibilité d'utiliser le maximum du matériel.
évolutivité, (une solution générique) avec possibilité de faire un cluster.
allocation des ressources matériel dynamique, si possible.
utilisation agréable, interface graphique utilisateur disponible.
sécurité.
facilité d'installation.

Le type d'hyperviseur nécessaire

Dans mon cas j'ai plus besoin d'un hyperviseur de type-1.
Le type-1 est plus adapté aux environnements et infrastructures d'entreprises.
Car un hyperviseur de type-1 permet des VMs plus rapide en effet l'hyperviseur agit directement sur le materiel et non sur l'OS, la couche supplémentaire, dans le cas d'un hyperviseur de type-2.

Les solutions possibles

Au final les 2 possibilités gratuit, et/ou open-source, d'hyperviseur de type-1 :

Xen Project, pour les utiliser il y a XenServer (Citrix) ou Oracle VM Server for x86
KVM, et pour les utiliser il y a les système Proxmox, Openvz, oVirt ou SmartOS, sinon l'interface graphique VirtManager.

Comparaison entre Xen et KVM

KVM semble avoir un consensus de la communauté comme étant la meilleur solution.

La solution choisie

KVM avec la possibiliter un gestionnaire de VMs tels que : Proxmox, Openvz, oVirt, SmartOS, ou VirtManager

Proxmox permet de gérer KVM et LXC dans le même environnement.
Proxmox utilise l'outil qemu pour la gestion et la gestion des composants matériels émulés, mais la virtualisation s'effectue via KVM. https://www.reddit.com/r/homelab/proxmox_type_1_hypervisor/
En fait proxmox permet de tout faire.

Voir aussi https://www.reddit.com/r/homelab/comments/aptv59/what_is_the_best_hypervisor_for_a_homelab_in_2019/

Mise en place :

L'avantage de Proxmox est que cela fourni une interface de contrôle web accessible depuis un navigateur. Ce qui facilite l'utilisation en ne nécessitant pas d'accès physique à la machine mais simplement depuis le même réseau, il est même possible d'y accéder depuis internet en configurant correctement la box du FAI, mais ce n'est pas recommandé.
Proxmox permet même de faire une sorte de virtualisation de bureau en affichant dans le navigateur le bureau, ou le terminal si il n'y a pas d'interface graphique, de la même manière que si on branchait un écran.
C'est vraiment super bien fait, j'adore.

Je n'ai donc qu'à me connecter depuis un navigateur sur l'interface web avec les identifiants et je peux donc gérer l'ensemble de mes VMs (et conteneurs).

L'architecture

Je souhaite donc répartir mes services sur différentes VMs et au sein d'une VM, lorsqu'il est nécessaire de séparer encore certains éléments (notamment les applications web) alors j'utiliserai la conteneurisation avec Docker et la gestion avec Kubernetes.

L(es) OS(s)

Mes VMs tournent sous l'OS ArchLinux lorsque c'est possible.
Pour ce faire j'ai commencé par créer une VM et y installer un système d'exploitation le plus léger et le plus "vide" possible (c'est-à- dire avec le moins de paquets possible et notamment pas d'interface graphique). J'ai ensuite configurer cette VM au niveau réseau (netctl) en configurant une IP fixe et avec les éléments basics minimum pour avoir quelque chose d'utilisable.
Une fois cela fait et donc une fois que j'ai une VM utilisable sur laquelle travailler, et bien je la convertie en template afin de pouvoir créer une nouvelle VM sur la base de cette dernière.

Configuration des VMs et déploiement des Conteneurs.

A chaque fois que je souhaite installer un nouveau service, sur une nouvelle VM, je suis une suite d'étape :
* je clone la VM de base depuis le template * je modifie ses ressources hardware et autre paramétrage tel que le démarrage automatique * une fois lancer je modifie le

Serveur, ma Solution de Virtualisation

Virtualisation

Post by Clément, le Thursday 26 September 19