|
|
| Ligne 1 : |
Ligne 1 : |
| − | == Conteneurs OpenVZ et LXC == | + | ==[[Proxmox]]== |
| − | | |
| − | Les conteneurs OpenVZ sont équivalent aux Jails du système FreeBSD, ce sont des hyperviseurs de type 2, c'est une technologie basé sur un kernel Linux permettant de compartimenter des processus et leurs descendants, c'est une solution plus lègére que la virtualisation complète via la technologie KVM, les système invités partages le même kernel.
| |
| − | | |
| − | OpenVZ utilise un système de partage de ressources très différent de KVM puisque le kernel est partagé entre les sous-systèmes, par exemple une fois que la limite mémoire assigné par le système hôte à un sous-système est atteinte, le conteneur se réserve le droit de récupérer de la mémoire sur les autres systèmes.
| |
| − | | |
| − | Il est plus difficile de customiser les sous-système lorsqu'ils sont contenus dans des conteneurs OpenVZ car ils sont dépendent du kernel Linux hôte et de la version du kernel.
| |
| − | | |
| − | Un avantage non négligeable est la rapidité et la facilité de créations, d'installation et de configuration des systèmes via les templates OpenVZ intégrés, il est possible de télécharger des versions prête à être utiliser de différentes distributions (Debian, centos, Debian intégrant le CMS Joomla etc.) selon des templates fournies par exemple par la distribution [https://www.turnkeylinux.org/ TurnKey] puis de modifier la configuration de ses templates pour en créer de nouveau s'adaptant aux différents besoins.
| |
| − | | |
| − | '''Note : '''Depuis la version 4, les conteneurs OpenVZ sont remplacés par les conteneurs LXC. (grosso modo similaire dans le concept)
| |
| − | | |
| − | === Avantages : ===
| |
| − | | |
| − | *Faible consommation de ressources (CPU, RAM etc.), pénalité de l'ordre de 1 à 3% par rapport à une machine physique, peut supporter un très (très) grand nombre de sous-système
| |
| − | *Flexibilité accrue pour l'allocation des ressources (réduction/aggrandissement de l'espace disque etc)
| |
| − | *Complexité réduite par rapport aux machines KVM
| |
| − | *Rapidité de démarrage, extinction, création, destruction etc.
| |
| − | *Peut être plus efficace dans le partage des ressources comparé à des machines KVM
| |
| − | *Aisance d'administration, récupération, installation automatique de systèmes via un système de templates, création de templates personnalisés avec différente configurations
| |
| − | *Proxmox dispose d'une intégration quasi-complète des conteneurs LXC dans ses versions récente facilitant l'installation, le monitoring et la configuration.
| |
| − | | |
| − | === Inconvénients : ===
| |
| − | | |
| − | *Dépend du kernel Linux choisi lors de la création du conteneur
| |
| − | *Peu adaptatif
| |
| − | === Recommendations : ===
| |
| − | | |
| − | Il est préférable d'utiliser les conteneurs OpenVZ ou LXC dans un conteneur KVM plutôt que sur le noeud principal Proxmox.
| |
| − | | |
| − | | |
| − | == Virtualisation KVM ==
| |
| − | | |
| − | KVM (Kernel-based Virtual Machine) est un hyperviseur de type 1 pour Linux, contrairement aux conteneurs, ils permettent de booter différent type de systèmes et plus généralement émule une machine quasi-complètement (jusqu'à son matériel)
| |
| − | | |
| − | === Avantages : ===
| |
| − | | |
| − | *Cloisonement/isolation totale (virtualisation complète), 100% des ressources alloués à une machine sont dédiés à cette machine quoiqu'il arrive
| |
| − | *Personnalisation totale de la machine (n'est pas dépendant d'un système d'exploitation type)
| |
| − | *Robuste (les ressources assignés sont garanties)
| |
| − | === Inconvénients : ===
| |
| − | | |
| − | *Performances moindre comparé aux conteneurs OpenVZ ou LXC car la virtualisation est complète
| |
| − | *Complexité de l'infrastructure de communications entre différentes VMs (KVM étant placé sous un paradigme matériel versus logiciel dans le cas des conteneurs)
| |
| − | *Administration et installation un peu plus difficile que les conteneurs OpenVZ ou LXC
| |
| − | === Création de backups automatique régulier (snapshot) : ===
| |
| − | | |
| − | #Cliquer sur le dossier Proxmox racine "Datacenter"
| |
| − | #Cliquer sur l'onglet "backup" pour avoir la liste des tâches concernant les backups
| |
| − | #Cliquer sur "Add"
| |
| − | #Choisir le noeud concerné ainsi que le noeud de stockage
| |
| − | #Planifier le backup
| |
| − | #Séléctionner les VMs assigné au backup automatique
| |
| − | #Choix de la notification, compression, mode "snashot" puis "Create"
| |
| − | === Importation d'une VM au format ouvert ".ova" crée sous VirtualBox : ===
| |
| − | | |
| − | #Upload du fichier ".ova" sur la Proxmox
| |
| − | #Extraction de l'OVA (produisant des fichiers ".vmdk", ".ovf" et ".mf") : tar xvf my.ova
| |
| − | #Conversion des fichiers ".vmdk" obtenus au format par défaut VM de Proxmox ".qcow2" : qemu-img convert -f vmdk myvm-disk1.vmdk -O qcow2 myvm-disk1.qcow2
| |
| − | #Créer une VM dans Proxmox contenant les même propriétés que le contenu du fichier ".ovf" (ouvrir avec un éditeur de texte)
| |
| − | #Remplacer les fichiers ".qcow2" de la VM crée par les images ".qcow2" obtenus lors de l'étape de conversion
| |
| − | #La VM est désormais converti et peut être démarré
| |
| − | | |
| − | | |
| − | == Proxmox ==
| |
| − | | |
| − | === Convertir .qcow2 en .vmdk (VMWare) ===
| |
| − | | |
| − | <code>qemu-img convert -f qcow2 -O vmdk vm-102-disk-1.qcow2 vm-102-disk-1.vmdk</code>
| |
| − | | |
| − | === Restaurer un snapshot KVM ===
| |
| − | | |
| − | 112 = l'ID de la VM qui va être crée
| |
| − | | |
| − | <code>qmrestore /var/lib/vz/dump/snapshot.vma.lzo 112</code>
| |
| − | | |
| − | === Emplacement des conteneurs de stockage : ===
| |
| − | | |
| − | *les conteneurs se trouvent dans /var/lib (ex. dossier des ISOs OpenVZ : /var/lib/vz/template/iso)
| |
| − | *placer les conteneurs .tar.gz dans /var/lib/vz/template/cache
| |
| − | *les VMs se trouvent dans /var/lib/vz/
| |
| − | | |
| − | === Accèder aux VMs : ===
| |
| − | | |
| − | Outre par accès SSH, Proxmox offre trois autres moyens d'accèder aux VMs selon la configuration de la Proxmox :
| |
| − | | |
| − | *noVNC : Solution simple et rapide mais ne disposant pas de fonctionnalités avancés (copier coller)
| |
| − | *VNC : Solution standard, nécessite un client VNC
| |
| − | *SPICE : Utiliser l'installateur spice-guest sous windows pour bénéficier des fonctionnalités avancés
| |
| − | === Cas d'un serveur web tournant dans une VM faisant office de proxy inverse et routant les requêtes vers d'autres VMs : ===
| |
| − | | |
| − | ==== Exemples de redirection de ports via iptable (80 et 443 vers une VM cible 10.0.1.110) : ====
| |
| − | | |
| − | <code>-A PREROUTING -i vmbr0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.1.110:80</code>
| |
| − | | |
| − | <code>-A PREROUTING -i vmbr0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.1.110:443</code>
| |
| − | | |
| − | ==== Mise à jour des règles de routage (iptable) : ====
| |
| − | | |
| − | <code>iptables-restore < /etc/iptables.up.rules</code>
| |
| − | | |
| − | ==== Tester les règles de routage du serveur web reverse proxy au sein de la node Proxmox : ====
| |
| − | | |
| − | <code>curl -v --header 'Host: xyz.tld' 10.0.1.110</code>
| |
| − | | |
| − | ==== Bugs de la version 3.x ====
| |
| − | | |
| − | *Lorsqu'il n'y à plus d'espace de stockage sur la ProxMOX, les VMs sont stoppés et ne peuvent plus démarrer, libérer de l'espace disque est nécessaire pour que les VMs puisse être de nouveau démarré.
| |
| − | | |
| − | === [[Virtualisation d'une machine physique]] ===
| |
| − | | |
| − | '''Cet article as été écrit avec les informations obtenus depuis un système Proxmox v3.x.'''
| |
