Une migration tournée vers l’open-source
Afin d’assurer la pérennité et la stabilité dans mon infrastructure j’ai choisi KVM : standard ouvert, inter-opérable, aux fonctionnalitées immenses. Plus précisément, ce nouveau projet s’inscrit dans ma volonté d’être au plus proche de mon système Linux. KVM est présent dans les plus grands projets de cloud computing : openstack, opennebula, ovirt ainsi que bien d’autres.
En plus de KVM, il existe aussi ce fabuleux système de conteneur appelé docker, qui se base lui aussi intégralement sur Linux. Ils représentent à tous les deux de merveilleuses possibilités d’apprentissage pour comprendre le cloud. La gestion de KVM se fera en grande partie avec une interface en HTML5. Pour docker il existe Shipyard que je n’évoquerai pas dans l’article.
L’ensemble de mon article se base principalement sur le wiki de KVM, de WebVirtMgr ainsi que de libvirt.
La solution SaaS : WebVirtMgr
WebVirtMgr se présente sous la forme d’une interface web développée en bootstrap. Elle utilise l’API libvirt pour la gestion du ou des hyperviseurs, des réseaux, des interfaces, des stockages et des VM. L’accès à la VM se fera quant à elle via une console en VNC (novnc) ou html5 « spice ».
Plus d’informations sur : webvirtmgr.
Voici une illustration de mon infrastructure :
WebVirtMgr et l’hyperviseur KVM/QEMU
KVM (Kernel Virtual Machine) est un module du noyau Linux qui permet à un programme de l’espace utilisateur d’utiliser les fonctionnalités de virtualisation matérielle de différents processeurs. Aujourd’hui, il prend en charge les processeurs Intel récents et processeurs AMD (x86 et x86_64), PPC 440, PPC 970, S / 390, ARM (Cortex A15), et MIPS32 (emulation processeur).
QEMU peut faire usage de KVM lors de l’exécution d’une architecture cible qui est la même que l’architecture de l’hôte. Par exemple, lors de l’exécution qemu-system-x86 sur un processeur compatible x86, vous pouvez profiter de l’accélération de KVM – donnant vous bénéficiez pour votre accueil et votre système invité (émulation de machine virtuelle).
Source : http://wiki.qemu.org/KVM
Pré-requis avant l’installation
- Le processeur doit être compatible avec les technologies de virtualisation :
egrep '^flags.*(vmx|svm)' /proc/cpuinfo
Si un résultat apparaît alors votre processeur est opérationnel. Sinon c’est que votre processeur ne supporte pas la virtualisation.
Pas de panique ! Il existe webvirtmgr avec lxc et docker bien-entendu : découvrez-le !
- Installer les paquets suivants :
apt-get install kvm libvirt-bin bridge-utils sasl2-bin
- Télécharger le script de retspen et exécutez-le :
wget http://retspen.github.io/libvirt-bootstrap.sh sh libvirt-bootstrap.sh
Pour information, à la fin du script vous deviez avoir les services suivants en fonctionnement :
- [ ok ] Starting system message bus: dbus.
- [ ok ] Starting libvirt management daemon: libvirtd.
Installation de WebVirtMgr
WebVirtMgr a besoin des paquets suivants pour fonctionner :
apt-get install git python-pip python-libvirt python-libxml2 novnc supervisor
Durant (la longue) installation, différentes questions feront leurs apparitions :
faut-il installer une base de données pour NOVA : oui
faut-il configurer la base de données de nova-common avec dbconfig-common : oui
type de serveur de base de données à utiliser avec nova-common ! sqlite3
La prochaine étape consiste à configurer python et l’environnement « django » :
mkdir /var/www
Déplacer vous dans le répertoire www :
cd /var/www
Télécharger le git de WebVirtMgr :
git clone git://github.com/retspen/webvirtmgr.git
Rendez-vous dans le répertoire suivant :
cd webvirtmgr
L’outil pip est utilisé car il installera rapidement et téléchargera automatiquement les dépendances nécessaires :
sudo pip install -r requirements.txt
Downloading/unpacking django==1.5.5 (from -r requirements.txt (line 1))
Downloading Django-1.5.5.tar.gz (8.1MB): 8.1MB downloaded
Running setup.py (path:/tmp/pip_build_root/django/setup.py) egg_info for package django
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Downloading/unpacking gunicorn==18.0 (from -r requirements.txt (line 2))
Downloading gunicorn-18.0.tar.gz (366kB): 366kB downloaded
Running setup.py (path:/tmp/pip_build_root/gunicorn/setup.py) egg_info for package gunicorn
warning: no previously-included files matching '*.pyc' found under directory 'docs'
warning: no previously-included files matching '*.pyo' found under directory 'docs'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
warning: no previously-included files matching '*.pyo' found under directory 'tests'
warning: no previously-included files matching '*.pyc' found under directory 'examples'
warning: no previously-included files matching '*.pyo' found under directory 'examples'
Downloading/unpacking lockfile>=0.9 (from -r requirements.txt (line 5))
Downloading lockfile-0.10.2-py2-none-any.whl
Installing collected packages: django, gunicorn, lockfile
Running setup.py install for django
changing mode of build/scripts-2.7/django-admin.py from 644 to 755
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
changing mode of /usr/local/bin/django-admin.py to 755
Running setup.py install for gunicorn
warning: no previously-included files matching '*.pyc' found under directory 'docs'
warning: no previously-included files matching '*.pyo' found under directory 'docs'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
warning: no previously-included files matching '*.pyo' found under directory 'tests'
warning: no previously-included files matching '*.pyc' found under directory 'examples'
warning: no previously-included files matching '*.pyo' found under directory 'examples'
Installing gunicorn_paster script to /usr/local/bin
Installing gunicorn script to /usr/local/bin
Installing gunicorn_django script to /usr/local/bin
Found existing installation: lockfile 0.8
Uninstalling lockfile:
Successfully uninstalled lockfile
Successfully installed django gunicorn lockfile
Cleaning up...
Lancer la création de la base de données via django :
./manage.py syncdb
WARNING:root:No local_settings file found. Creating tables ... Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table auth_user_groups Creating table auth_user_user_permissions Creating table auth_user Creating table django_content_type Creating table django_session Creating table django_site Creating table servers_compute Creating table instance_instance Creating table create_flavor You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): yes Please enter either "yes" or "no": yes Please enter either "yes" or "no": yes Username (leave blank to use 'root'): kassianoff Email address: [email protected] Password: Password (again): Superuser created successfully. Installing custom SQL ... Installing indexes ... Installed 6 object(s) from 1 fixture(s)
On recommence avec cette fois-ci collectstatic :
./manage.py collectstatic Type 'yes' to continue, or 'no' to cancel: yes 75 static files copied
Donner les droits au serveur web dans le répertoire de WebVirtMgr :
chown -R www-data:www-data /var/www/webvirtmgr/
Modification du script et du lancement de VNC :
sudo service novnc stop [ ok ] Stopping OpenStack NoVNC proxy: nova-novncproxy.
Suppression du script au lancement de notre distribution debian :
update-rc.d -f novnc remove update-rc.d: using dependency based boot sequencing
Suppression du script dans init.d :
rm /etc/init.d/novnc
Renseigner des paramètres de lancement dans le fichier webvirtmgr.conf :
nano /etc/supervisor/conf.d/webvirtmgr.conf
[program:webvirtmgr] command=/usr/bin/python /var/www/webvirtmgr/manage.py run_gunicorn -c /var/www/webvirtmgr/conf/gunicorn.conf.py directory=/var/www/webvirtmgr autostart=true autorestart=true stdout_logfile=/var/log/supervisor/webvirtmgr.log redirect_stderr=true user=www-data
[program:webvirtmgr-console]
command=/usr/bin/python /var/www/webvirtmgr/console/webvirtmgr-console directory=/var/www/webvirtmgr autostart=true autorestart=true stdout_logfile=/var/log/supervisor/webvirtmgr-console.log redirect_stderr=true user=www-data
On arrête le service supervisor et on le démarre :
service supervisor stop service supervisor start
L’installation est terminée et nous pouvons désormais accéder à l’interface WebVirtMgr via le port 8000 de notre machine.
Le tunneling SSH sous linux
La méthode du tunnelling SSH permet la redirection des ports 8000 et 6080 (novnc) vers notre poste client (sécurisé) :
ssh [email protected]:port -L localhost:8000:localhost:8000 -L localhost:6080:localhost:6080
Rendez-vous sur l’url : localhost:8000 et rentrer vos identifiants de connexion configurés lors du ./manage.py syncdb :
Connexion entre WebVirtMgr et KVM/QEMU
Plusieurs étapes seront nécessaire avant de pouvoir configurer l’infrastructure.
- Créer vos identifiants de connexion TCP comme ceci :
saslpasswd2 -a libvirt kassianoff.fr Password: Again (for verification):
- Déclarer votre hyperviseur dans virsh :
virsh -c qemu+tcp://localhost/system nodeinfo Please enter your authentication name: kassianoff.fr Please enter your password: CPU model: x86_64 CPU(s): 8 CPU frequency: 1632 MHz CPU socket(s): 1 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 1 Memory size: 32917020 KiB
Désormais ajoutons notre connexion TCP en cliquant sur le bouton : « Add connection »
Le résultat est le suivant :
Prise en main de la solution WebVirtMgr
Il me semble important de comprendre les différentes rubriques qui composent WebirtMgr :
- Instances : Gestion et création de machines virtuelles, ce sont nos instances.
- Storages : Gestion et création des différents pools de stockage (repertoire, iso, nfs, lvm…).
- Networks : Gestion et création des réseaux (bridge, route, nat…).
- Interfaces : Gestion et création des différentes interfaces que peuvent utiliser les réseaux.
- Secrets : Je n’ai pas eu d’informations la concernant, si un visiteur a des informations je suis preneur !
- Overview : Superviser l’ensemble de notre infrastructure : ressouces utilisées (cpu, mémoire etc…).
J’ai utilisé toutes les rubriques (excepté Secrets), commencez par suivre les étapes ci-dessous pouvoir créer une instance.
Création des pools de stockage
Avant de démarrer la création d’une machine, nous aurons besoin de pools de stockage, cliquez sur Storages puis sur New storages la configuration est la suivante :
Création d’un repertoire DIR avec le chemin /var/lib/libvirt/images.
Création du répertoire ISO avec le chemin /var/www/webvirtmgr/images :
Sur un OVH dédié, utilisez NFS-common, et créez un répertoire nfs pour le connecter au NFS backup storage
apt-get install nfs-common mkdir /var/lib/libvirt/nfs/ mount -t nfs ftpback-rbxX-XXX.ovh.net:/export/ftpbackup/nsXXXXXXX.ovh.net /var/lib/libvirt/nfs/
Dans la création du poo » il existe le mode NETFS compatible avec NFS, cependant le format n’est pas pris en compte.
La solution consiste à utiliser le mode dir en spécifiant le répertoire nfs précédemment monté :
Vérifiez vos différents pools de storage dit : nfs, iso, images :
Je ne vais pas évoquer la création d’une machine dans le menu images ni même l’ajout d’un fichier ISO via WebVirtMgr.
La raison est simple, j’utilise le terminal pour ces tâches là. Concentrons-nous sur les réseaux avant de créer notre VM.
La rubriques networks dans WebVirtMgr
L’ajout de réseaux se fait via l’onglet networks. Ajoutez deux réseaux bridge lbr0 et lbr1 :
Reproduisez la manipulation ci-dessus pour créer la seconde interface bridge, ce qui donnera :
Interfaces et réseaux bridgés sous linux
La rubrique interfaces affiche le fichier de configuration /etc/networks/interface on y retrouvera lo,br0, lbr0, lbr1.
Mais avant de configuer nos interfaces bridge, voyons la configuration actuelle :
ifconfig
eth0 Link encap:Ethernet HWaddr 08:60:6e:e5:bd:47
inet adr:XX.XXX.XXX.XXXX Bcast:XX.XXX.XXX.XXX Masque:255.255.255.0
adr inet6: XXXX:XXXX:X:XXXX::/xx Scope:Global
adr inet6: XXXX::XXX:XXXX:XXXX:XXXX/xx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:2243 erreurs:0 :0 overruns:0 frame:0
TX packets:1618 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:490019 (490.0 KB) Octets transmis:243883 (243.8 KB)
lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
Packets reçus:140 erreurs:0 :0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:22966 (22.9 KB) Octets transmis:22966 (22.9 KB)
virbr0 Link encap:Ethernet HWaddr 22:e2:0b:e7:c2:d1
inet adr:192.168.122.1 Bcast:192.168.122.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
On remarque la configuration suivante : l’interface eth0 qui représente l’adresse IP publique du serveur, l’interface loopback (logique) ainsi que l’interface virbr0 qui est créée automatiquement en mode NAT.
Dans la mise en place de mon infrastructure, le réseau à une place importante. J’ai donc créé trois interfaces :
- br0 = bridgé vers l’interface principale eth0 de mon hôte debian (utilisé pour mes IPO failover OVH).
- lbr1 = une interface bridge utilisée par VyOS pour mes services web.
- lbr2 = une interface bridge utiliser par VyOS pour mes dockers et VM avec possibilité d’inter-connexions docker/kvm.
Mon routeur/pare-feu manage mes différentes interfaces br0, lbr1, lbr2. Voici un schéma d’illustration :
Commençons par configurer l’interface br0 : (Wiki de debian)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address XX.XXX.XXX.XXX
netmask 255.255.255.0
network XX.XXX.XXX.0
broadcast XX.XXX.XXX.255
gateway XX.XXX.XXX.254
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
iface eth0 inet6 static
address XXXX:XXXX:X:XXXX::
netmask 64
post-up /sbin/ip -family inet6 route add XXXX:XXXX:X:XXXX:XX:XX:XX:XX dev eth0
post-up /sbin/ip -family inet6 route add default via XXXX:XXXX:X:XXXX:XX:XX:XX:XX
pre-down /sbin/ip -family inet6 route del default via XXXX:XXXX:X:XXXX:XX:XX:XX:XX
pre-down /sbin/ip -family inet6 route del XXXX:XXXX:X:XXXX:XX:XX:XX:XX dev eth0
Redémarrer l’interface (la connexion en SSH avec votre serveur ne devrait pas être interrompue) :
/etc/init.d/network restart
Vérifier la configuration de l’interface bridge sur l’hôte :
ifconfig br0
br0 Link encap:Ethernet HWaddr 08:60:6e:e5:bd:47
inet adr:XX.XXX.XXX.XXX Bcast:XX.XXX.XXX.255 Masque:255.255.255.0
adr inet6: XXXX::XXX:XXXX:XXXX:XXXX/xx Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2344432 errors:0 dropped:0 overruns:0 frame:0
TX packets:1599970 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:9383508945 (8.7 GiB) TX bytes:312106046 (297.6 MiB)
La commande pour visualiser l’interface bridgée :
btctl show br0 8000.08606ee5bd47 no eth0
Le paquet bridge nous offre la possibilité de créer directement nos interfaces telles que :
brctl addbr lbr0 brctl addbr lbr1
Ensuite, il nous faut démarrer les interfaces bridgées lbr0 et lbr1 :
ip link set dev lbr0 up ip link set dev lbr1 up
Cependant, la méthode de libvirt ne rend pas permanente nos interfaces ! Ajoutez les deux interfaces de façon définitive :
nano /etc/network/interface
auto lbr0
iface lbr0 inet manual
bridge_ports none
bridge_stp off
auto lbr1
iface lbr1 inet manual
bridge_ports none
bridge_stp off
/etc/init.d/network restart
brctl show br0 8000.08606ee5bd47 no eth0 lbr0 8000.fe5400047801 no lbr1 8000.fe54000a522b no virbr0 8000.000000000000 yes
Le serveur hôte peut redémarrer sans crainte de perdre sa configuration désormais. Voici les différentes interfaces bridgées :
Vous avez la possibilité de désactiver l’interface au démarrage :
virsh net-autostart --disable default
Ou encore de supprimer définitivement l’interface default :
virsh net-destroy default
Création d’une instance dans WebVirtMgr
Dans la rubrique instances, cliquez sur le bouton New Instance et plusieurs possibilités s’offre à vous.
- Instance personnalisée, Template ou fichier de configuration XML.
Ci-dessous on retrouve aussi des templates pré-définis et numérotés de 1 à 6 qui permettent de créer une image.
Dans ce cas précis, je vais utiliser une instance personnalisée. Mais avant il faudra créer un disque pour la VM.
Comme expliqué précédemment je préfère utiliser le mode cli pour créer le disque de ma future machine :
qemu-img create -f qcow2 vdisk 10G
Pour ceux qui souhaite convertir une machine VMware vers KVM :
qemu-img convert vm1-flat.vmdk -O qcow2 vm1
Afficher des informations concernant notre machine :
qemu-img info vdisk file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 136K cluster_size: 65536
Utiliser maintenant le HDD vdisk pour créer une VM vdisk :
Lancer la création en cliquant sur le bouton create : la gestion de la machine « vdisk » apparaît avec ses options :
A ce moment précis, libre à vous de découvrir les rubriques ci-dessus mais n’oubliez pas :
- « Access » pour sélectionner votre type de console, puis modifié la disposition du clavier (si mode : novnc).
- « Settings » pour l’ajout d’un Media ISO à la machine virtuelle.
- Dans « Settings » éditer la configuration du xml de la machine vdisk. Uniquement si vous souhaitez attribuer une Failover OVH à votre VM. La partie interfaces de la machine doit contenir (exemple sur mon routeur/pare-feu) :
<interface type='bridge'> <mac address='xx:xx:xx:xx:xx:xx'/> <source bridge='br0'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
- Lancement de la machine : Power puis Start, l’accès à la console ce fera via Accès/Console
- Une pop-up s’ouvre avec novnc et l’accès à la VM :
C’est terminé, vous êtes désormais prêt à utiliser les ressources de votre infrastructure et votre VM !
Mais avant sauvegardez à chaud votre VM.
Sauvegarder vos machines KVM à chaud
La sauvegarde peut se faire par clone via l’interface webvirtmgr ou encore via un simple cp : (vers NFS)
cp /var/lib/libvirt/images/vdisk /var/lib/libvirt/nfs/vdisk.02.03.2015
Vue d’ensemble de l’infrastructure
La charge d’utilisation de l’infrastructure est disponible dans la rubrique overview ce qui permet d’obtenir une vue d’ensemble en temps réel. Voici l’utilisation de mon infrastructure webvirt-kassianoff une fois en place :
Mise à jour de WebVirtMgr
Les mise à jours technologiques et de sécurité sont bien entendu très importantes, pour cela rien de plus simple :
Rendez-vous dans le répertoire de WebVirtMgr :
cd /var/www/webvirtmgr
Puis lancez les commandes suivantes :
remote: Counting objects: 27, done. remote: Compressing objects: 100% (14/14), done. remote: Total 27 (delta 7), reused 6 (delta 6), pack-reused 7 Unpacking objects: 100% (27/27), done. From git://github.com/retspen/webvirtmgr ed176e4..c875e0d master -> origin/master Updating ed176e4..c875e0d Fast-forward console/views.py | 3 ++- create/views.py | 7 ++++--- hostdetail/views.py | 5 +++-- instance/views.py | 15 ++++++++------- interfaces/views.py | 7 ++++--- networks/views.py | 9 +++++---- secrets/views.py | 3 ++- servers/views.py | 9 +++++---- storages/views.py | 9 +++++---- templates/base.html | 2 +- templates/base_auth.html | 2 +- templates/login.html | 2 +- 12 files changed, 41 insertions(+), 32 deletions(-)
./manage.py collectstatic
WARNING:root:No local_settings file found. You have requested to collect static files at the destination location as specified in your settings. This will overwrite existing files! Are you sure you want to do this? Type 'yes' to continue, or 'no' to cancel: yes 0 static files copied, 75 unmodified.
service supervisor stop
Je termine ma migration et j’espère que votre nouvelle infrastructure vous plaît !