Virtualisation avec OpenStack pour TP GIS
Sommaire
Virtualiser dans une VM
Création de une VM avec kvm et libvirt
Kernel-based Virtual Machine (KVM) est un logiciel hyperviseur pour Linux. Il fonctionne originellement sur les processeurs à architectures x86, x86_64 disposant des instructions de Virtualisation Intel VT ou AMD-V. QEMU est capable, grâce à son module KQEMU (K pour Kernel, « noyau » en anglais), d'exécuter du code machine directement sur le processeur hôte afin d'accélérer l'émulation.
libvirt est une bibliothèque, une API, un daemon et des outils en logiciel libre de gestion de la virtualisation. Elle est notamment utilisée par KVM, Xen, VMware ESX, QEMU et d'autres solutions de virtualisation. Elle est notamment utilisée par la couche d'orchestration des hyperviseurs.
Les paquetages à installer installer:
apt-get install qemu-kvm libvirt-bin
Créer une image de disque
Pour commencer il faut créer les image de disque dans les quelles les VMs stockeront les donnée. Pour créer une image de disque de format RAW il est suffit de lancer le command
qemu-img create -f raw disk.img 8G
Il est aussi possible de créer une image de format QCOW2 qui supporter les technologies "copy on write" et "snapshot" pour les VMs.
qemu-img create -f qcow2 disk.img 8G
Il est pratique de créer une image de swap
dd if=/dev/zero of=/swapfile1 bs=1024 count=524288
Comm:
if=/dev/zero : Read from /dev/zero file. /dev/zero is a special file in that provides as many null characters. of=/swapfile1 : Read from /dev/zero write storage file to /swapfile1. bs=1024 : Read and write 1024 BYTES bytes at a time. count=524288 : Copy only 523288 BLOCKS input blocks.
Il est possible que le image init n'est pas assi pour app donc pour grandir la disque, il faut
- installer le package
apt-get install libguestfs-tools
- Make a bigger img
qemu-img create -f qcow2 disk_new.img 20G
- Copy the data
virt-resize --expand /dev/sda1 disk.img disk_new.img
Fichier de configuration libvirt
Une VM gérée par libvirt est définie par un fichier XML. Ici une exemple qui définie un VM.Fichier:Lisa.xml.zip Vous prouvez trouvez le définition de ce fichier au site web de libvirt.
Gréer les VMs avec libvirt
Commande à utiliser: virsh Lancer une VM:
virsh --connect qemu:///system create <fichier.xml>
Lister les VMs:
virsh --connect qemu:///system list
Arrêter une VM:
virsh --connect qemu:///system shutdown <nom de la VM>
Connecter ver les VMs
Vous prouvez connecter ver vnc. La package à installer: vncviewer. Commande à utiliser: vncviewer localhost
Établir des ponts entre les connexions réseaux
Pour que les VMs peuvent être une partie de la réseaux d’école il faut de creer un pont virtuel.
Configure dans les machine physique
Le programme dont vous allez avoir besoin s'appelle brctl et fait parti de bridge-utils.
apt-get install bridge-utils
Pour créer le pont il faut modifier le fichier de configuration des interface: /etc/network/interfaces ici une exemple qui créera un pont nommé br0 a partir de la .
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
Le création du pont configurer le carte réseau à la mode promiscuité. Les relus dans le filtres iptables bloquera les package redirecté. Donc il nécessaire de modifier le fichier de configuration de iptables /etc/iptables.up.rules il faut que dans le section filter il y a FORWARD ACCEPT [0:0].
Il faut faire un reboot après les configurations. Il faut que vous trouvez avec ifconfig, le br0 prend une adresse ipv4 du réseau INSECURE donc 172.26.*.* et la interface eth0 ne prend pas un adresse ipv4.
Configure dans les VMs
Il faut fixer l'adresse à la main dans les VMs. Vous prouvez modifier le fichier /etc/network/interfaces et le fichier /etc/resolv.conf dans le fenêtre de vncviewer. Il faut aussi configure les proxy de ecole avec le commande
export http_proxy=http://proxy.polytech-lille.fr:3128
Activer le mod nested
Pour faire une virtualisation imbriqué avec kvm il faut activer le fonction VT-x dans les cpus avec les commande suivent:
echo "options kvm-intel nested=1" >> /etc/modprobe.d/kvm-intel.conf rmmod kvm_intel modprobe kvm-intel nested=1 cat /sys/module/kvm_intel/parameters/nested
Pour les VMs il fut que les vcpus supporter VT-x. Donc dans le xml on fixer le model de vcpus, ici une example de la section cpu dans le xml ou on utiliser les vcpus de model SandyBridge et fonction vmx (VT-x) activé.
<vcpu>4</vcpu> <cpu mode='custom' match='exact'> <model fallback='allow'>SandyBridge</model> <vendor>Intel</vendor> <topology sockets='2' cores='1' threads='2'/> <feature policy='require' name='vmx'/> </cpu>
Noede nœud calcul virtuel
Une fois que une VM a lancer vous prouvez suivre les guides sur http://rex.plil.fr/Enseignement/Reseau/AtelierInfonuagique.GIS4/atelier_infonuagique.html pour configure un nœud de calcul. Ici, dans cette section nous allons créer un système automatique pour configure les nœuds.
Pour creer les fichier de nœud calcul virtuel il est suffit de lancer le commande:
source deploy.sh
Le script deploy.sh créera une structure de fichier d’après le route dirWD:
(dirWD)
├── img
│ ├── kvm-lisaB.img
│ ├── kvm-lisaBSwap.img
├── temp
│ └── kvm-lisaB
│ ├── conf.d
│ │ ├── hostname
│ │ ├── hosts
│ │ ├── interfaces
│ │ ├── kvm.xml
│ │ ├── ml2_conf.ini
│ │ ├── neutron.conf
│ │ ├── nova.conf
│ │ ├── ovs_neutron_plugin.ini
│ │ └── sysctl.conf
│ └── imgRoot
└── xml
└── kvm-lisaB.xml
Montre les image
Nous avons utiliser les images de formule QCOW2 pour créer les nœuds donc pour modifier les images il faut utiliser qemu-nbd. Il faut activer le module nbd de linux avec le commande modprobe nbd. Pour montre une image qcow2 il faut
qemu-nbd -c /dev/nbd0 disk.img --format=qcow2 kpartx -a /dev/nbd0 mkdir /media/diskqcow2 mount /dev/mapper/nbd0p1 /media/diskqcow2
Pour déconnecter
umount /media/diskqcow2 qemu-nbd -d /dev/nbd0
Modifier les fichier de configuration
Pour les nœud de calcul les fichier suivent droit être modifier:
/etc/hostname # nom du nœud /etc/hosts # nom du nœud /etc/network/interfaces # adresse ip etc. kvm.xml # configuration de VM /etc/neutron/plugins/ml2/ml2_conf.ini # configuration de ml2 /etc/neutron/neutron.conf # configuration de neutron /etc/nova/nova.conf # configuration de nova /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini # configuration de ovs /etc/sysctl.conf # configuration de flitre
Nous allons modifier les fichiers avec "sed". Le script créera d'abord une copie des modeles de fichiers de configuration dans (dirWD)/temp/(nomDeVM)/conf.d apres, il modifiera les paramètres dans les fichiers.
Une fois le modification a fini le script copiera les fichier dans le image. Vous prouvez trouvez ici une example de script.Fichier:Deploy.sh.zip. A la fin pour lancer les VMs il est suffit de faire
virsh --connect qemu:///system create (dirWD)/xml/(nomDeVM).xml
Configuration Internet OpenStack
Dans le système un noeud de contrôle et un noeud de réseau a deja installé (Il sont des VM xen). Les nœud de calcul sont des VM KVM. Le graph topology du système openStack est ci-dessus.
Il y a deux réseaux virtuel un réseau privaté 192.168.100.0/24 et un réseau public 193.48.65.192/26. Les réseaux sont connecté par un routeur virtuel. Deux instances sont commencé et connecté ver le réseau privaté. Pour les instance l’adresse IP sont vient du service DHCP.
Création de réseau public
Pour communiquer avec les machines dans le réseau physique il faut créer un réseau public virtuel dans openstack. Les instances ne peut pas être connecté directement avec le réseau public. Les communication du reseau private au réseau public droit être routé par un routeur virtuel. Pour creer un reseau public il faut utiliser le commande "neutron net-create" sur le nœud de contrôle. Le paramètre router:external droit être configuré à True.
neutron net-create netPublic --router:external=True
Nous allons avoir un résultat comme ça:
+---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 31***740-****-****-****-4f7*****7827 | | name | netPublic | | provider:network_type | gre | | provider:physical_network | | | provider:segmentation_id | 1 | | router:external | True | | shared | False | | status | ACTIVE | | subnets | d4cf35f**********************55d7533 | | tenant_id | 4889d70c****************8f15f670 | +---------------------------+--------------------------------------+
Dans notre environnement, eth2 de noeud de reseau est connecé avec le pont "bridgeInternet". Nous allons l'utiliser pour connecter avec le réseau physique. Donc nous ajoutons cette carte dans le pont OVS "br-ex", Neutron routera les données de instances au reseau physique ver ce pont.
ovs-vsctl add-port br-ex eth2 ovs-vsctl show
Il faut de avoir les résultat suivent:
Bridge br-ex
Port br-ex
Interface br-ex
type: internal
Port "eth2"
Interface "eth2"
....
Le réseau physique, connecté sur eth2, nous allons utiliser est 193.48.65.192/26, les machines dans ce réseau peut communiquer avec les mechines dans l'internet ver le gateway 193.48.65.254. Pour connecter cette réseau avec l'environnement openstack, il faut créer un sous-réseau avec le mémé range de adresse IP et gateway.
neutron subnet-create netPublic 193.48.65.192/26 --name public_subnet --enable_dhcp=False --allocation-pool start=193.48.65.193,end=193.48.65.250 --gateway=193.48.65.254
Nous allons avoir un résultat comme ça:
+------------------+----------------------------------------------------+
| Field | Value |
+------------------+----------------------------------------------------+
| allocation_pools | {"start": "193.48.65.193", "end": "193.48.65.250"} |
| cidr | 193.48.65.192/26 |
| dns_nameservers | |
| enable_dhcp | False |
| gateway_ip | 193.48.65.254 |
| host_routes | |
| id | d4cf35**********a5-9c******7c55d7533 |
| ip_version | 4 |
| name | public_subnet |
| network_id | 31af97********************7da9f57827 |
| tenant_id | 4889d7*********************5f670 |
+------------------+----------------------------------------------------+
A la fin il faut connecter le routeur avec notre réseau public.
neutron router-gateway-set routerPublic netPublic
Il est peut-être nécessaire de configurer les ponts et cartes "UP" sur le nœud réseau.
ip link set dev br-ex up ip link set dev br-tun up ip link set dev br-int up ip link set dev eth2 up
Floating IP
Les instances ont déjà pu connecter avec les machines sur l'internet. En suit pour que les machines d'hors pouvoir connecter ver les instance il faut utiliser floating IP. Les floatings IPs sont donné par le réseau physique, est peuvent être donné aux instances. Nous pouvons faire ça avec le GUI. Il faut d'abord ajouter un adresse IP dans le projet.
Encore il faut donne le adresse IP à la instance.
Connecter de dans les instances
Les instance sont protégé par les réglés.
Les réglés Security Group
Les security groups sont des réglés contrôler les communication entre les instance et les machine dehors. Par défaut des communications "incoming" sont refusé et des communications "outgoing" sont accepté.
Les commandes suivent creer un Security Group nomé "terry" avec les réglés qui accepte les communications "incoming" de port 22(SSH), 80(HTTP), 443(HTTPS) et ICMP(ping).
# Creer le secgroup nova secgroup-create terry # ICMP nova secgroup-add-rule terry icmp -1 -1 0.0.0.0/0 # SSH nova secgroup-add-rule terry tcp 22 22 0.0.0.0/0 # HTTP nova secgroup-add-rule terry tcp 80 80 0.0.0.0/0 # HTTPS nova secgroup-add-rule terry tcp 443 443 0.0.0.0/0
Le commande suivent applique le Security Group "secgroup" à la instance "server"
nova add-secgroup <server> <secgroup>
Vous prouvez aussi faire ça avec GUI.
SSH
En raison de sécurité pour la majorité de images il est interdire de connecter dans les instances avec SSH avec mot de passe. Pendant le création de instance il faut créer ou choisir un Key pair.
et pour connecter il faut utiliser le commande suivent(ici on utiliser le image debian):
ssh -i <fichierKey> debian@<adresseFloatingIpDeInstance>
Add Object Storage
Vous prouvez suivire le guide sur http://docs.openstack.org/icehouse/install-guide/install/apt-debian/content/ch_swift.html jusqu’à "Start services on the storage nodes ". Le "proxy node" est sur le meme vm que "contrôle node". Après, il faut midifier les ficiher de conf sur le node de stockage. examples:
root@gis4-chouchinois-swifit-storage:/etc/swift# cat /etc/swift/account-server.conf | grep -v ^# | grep -v ^# [DEFAULT] bind_ip = 0.0.0.0 bind_port = 6002 devices = /srv/node workers = auto [pipeline:main] pipeline = healthcheck recon account-server [app:account-server] use = egg:swift#account [filter:healthcheck] use = egg:swift#healthcheck [filter:recon] use = egg:swift#recon [account-replicator] [account-auditor] [account-reaper] [filter:xprofile] use = egg:swift#xprofile
root@gis4-chouchinois-swifit-storage:/etc/swift# cat /etc/swift/object-server.conf | grep -v ^# | grep -v ^# [DEFAULT] bind_ip = 0.0.0.0 bind_port = 6000 devices = /srv/node [pipeline:main] pipeline = healthcheck recon object-server [app:object-server] use = egg:swift#object [filter:healthcheck] use = egg:swift#healthcheck [filter:recon] use = egg:swift#recon [object-replicator] [object-updater] [object-auditor] [filter:xprofile] use = egg:swift#xprofile
root@gis4-chouchinois-swifit-storage:/etc/swift# cat /etc/swift/container-server.conf | grep -v ^# | grep -v ^# [DEFAULT] bind_ip = 0.0.0.0 bind_port = 6001 devices = /srv/node [pipeline:main] pipeline = healthcheck recon container-server [app:container-server] use = egg:swift#container [filter:healthcheck] use = egg:swift#healthcheck [filter:recon] use = egg:swift#recon [container-replicator] [container-updater] [container-auditor] [container-sync] [filter:xprofile] use = egg:swift#xprofile
Il faut aussi modifier le "Owner" de /srv/node
chown -R swift:swift /srv/node
Apres il faut relancer les service sur node de stockage
swift-init all restart
Docker
http://www.cnblogs.com/MicroTeam/p/see-docker-run-in-debian-with-aliyun-ecs.html
installer docker
## installer curl apt-get install curl ## installer docker curl -sSL https://get.docker.com/ | sh ## service docker restart ## run hello world docker run hello-world
install images
Autre
- Les ressources dans les nœuds de calcule virtuels sont vraiment limités. Donc le nombre de instances droit être limités.
- Le flavor m1.tiny n'est pas suffit pour les instances à partir des image Debian. Donc il faut créer un flavor avec un disque au moins 4GB.
- Le image cirros034 est bonne pour tester mais pour application c'est mieux de utiliser les images complet Debian par exemple.
- Il faut modifier le fichier de /etc/resolv.conf pour que il n'a pas de service de domine dans nœud reseau.
- Pour grandir la disque de VM http://speakingbaicai.blog.51cto.com/5667326/1319570
