Ce billet décrit l’installation et la configuration d’un serveur OVH Hybrid (SSD+SATA) pour en faire un hôte Openvz.
De l’interet des serveurs Hybrid
OVH propose depuis peu une gamme de serveurs « hybrid », concrètement la spécificité de ces serveur est d’avoir deux jeux de disques:
- Deux disques SSD de 80 Go
- Deux disques SATA 2 de 750 Go
L’idée est d’avoir de l’espace disque relativement faible en espace mais trés rapide en lecture/écriture (SSD) et de l’espace plus important mais plus lent via les disques classiques. On va donc utiliser les disques de 750 Go en RAID 1 et chaque disque SSD va être utilisé indépendamment l’un de l’autre pour stocker le / pour l’un et le swap pour l’autre (oui vous avez bien lu, le serveur va disposer de 80Go de swap !!!).
Dans le cadre de l’hébergement de machines virtuelles cela va nous permettre de:
- Garantir un minium de sécurité « locale » pour les machines virtuelles. Les machines virtuelles étant stockées sur un volume en RAID 1 il faut que les deux disques soient hors service pour perdre les data (dans un monde idéale en tout cas…). Attention cette sécurité est un plus, elle ne dispense pas de backups réguliers sur une machine distante.
- Avoir un sorte de RAM virtuelle, certes pas aussi performante que de la véritable RAM mais bien plus efficace que du swap « classique » (ie sur disque classique). Pour une machine virtuelle openvz la notion de swap n’existe pas, quand elle en à besoin elle se sert sur la RAM de l’hote (dans la limite de ce que l’on a défini), si l’hote n’a plus de RAM il va swapper pour allouer a la VM ce qu’elle demande. On comprends donc que si on a beaucoup de swap SSD on va pouvoir améliorer l’exploitation des ressources de la machine hôte en poussant un peu plus les limites de chaque VM vers le haut, en se disant que dans le pire des cas ce sera moins pire que quand c’etait plus pire. Vous voyez ce que je veux dire …
- Avoir des espaces temporaires, en lecture/écriture rapide, pour les dump par exemple. Je viens de faire un test sans limite de bw, le dump en mode snapshot d’une vm de base (debian brute de pomme) a pris 12 secondes (sur /tmp). Pas mal pas mal
Matériel et partitionnement
On utilise un EG/MG hybrid OVH. Le partitionnement est le suivant:
- / sur un SSD
- /swap sur l’autre
- les deux disques SATA restant en raid 0 sur lesquel on va creer un LVM
Installation de la machine
Réinstallation après livraison
Apres livraison il faut réinstaller la machine en utilisant un seul disque SSD pour / et /swap, on doit mettre une partition de swap minimale pour que l’installation soit valide.
Creation de la partition de swap sur le second SSD
On va utiliser tout le disque on va donc commencer par supprimer les éventuelles partitions qui s’y trouvent déjà.
fdisk /dev/sdb
Pour supprimer les partitions il faut utiliser l’option d, le numero de la partiction est alors demandé. Pour ajouter on utilise l’option n, le type a configurer est 82.
Il faut a présent activer cette partition. Attention il est nécessaire de rebooter avant:
mkswap -c /dev/sdb1
On desactive l’ancien swap:
swapoff /dev/sda2
On active le nouveau:
swapon /dev/sdb1
Il faut à présent modifier le fstab pour que ces modifications soient permanentes:
nano /etc/fstab
Le fichier devient (on ne supprime pas la conf par defaut, on la commente):
# <sys.fichiers><pt de montage><type> <options> <dump> <pass> /dev/sda1 / ext3 errors=remount-ro 0 1 #/dev/sda2 swap swap defaults 0 0 /dev/sdb1 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0
Je conseille de faire un petit :
mount -a
juste apres la manip pour etre certain de ne pas avoir fait d’erreur
Une petite verification:
# free -m
total used free shared buffers cached
Mem: 16048 378 15670 0 0 16
-/+ buffers/cache: 361 15686
Swap: 76316 0 76316
Création du RAID 1 en utilisant les deux disques SATA de 750 Go
Attention, dans mon cas le RAID sur les deux disks etait configuré, pensez a verifier avant. Si ce n’est pas le cas:
mdadm --create --verbose /dev/md0 --level=linear --raid-devices=2 /dev/sdc1 /dev/sdd1
Mise en place du volume LVM
Nous allons commencer par créer le volume logique:
pvcreate /dev/md0
Puis le groupe de volume:
vgcreate vzvg /dev/md0
On va creer le volume vz qui va etre monté sur /var/lib/vz
Attention il est necessaire de ne pas utiliser tout l’espace disponible, en mode snapshot, vzdump a besoin d’espace sur le VG pour créer le snapshot. Il n’est par contre pas necessaire d’allouer beaucoup d’espace puisque le snapshot n’enregistre que les modifications.
Pour connaitre l’espace disponible sur le VG, on utilise la commande vgdisplay
vgdisplay --- Volume group --- VG Name sysvg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 666.27 GB PE Size 4.00 MB Total PE 170565 Alloc PE / Size 0 / 0 Free PE / Size 170565 / 666.27 GB VG UUID gXabsE-mjAj-27vK-hk3k-ooD5-0vV2-9Yaf3f
On voit que ce volume dispose de 666 GB (Argh la bête !!!) on va créer un volume de 600 GB que l’on va nommer vz:
lvcreate -L 600G -n vz sysvg
On va formater ce volume en reseirf.
Si vous n’avez pas installer les outils necessaires pour gerer reiserf, c’est le moment:
apt-get install reiserfsprogs
et on formate:
mkfs.reiserfs /dev/sysvg/vz -l vz
Il faut a présent pouvoir utiliser ce système de fichier pour y stocker le contenu actuel de /var/lib/vz.
Déplacement des répertoires sur le volume LVM et montage
Pour ça il faut monter /dev/sysvg/vz sur un point de montage temporaire, copier les data, et monter /dev/sysvg/vz sur /var/lib/vz.
C’est parti, on commence par le point de montage temporaire:
mkdir /mnt/tmp
mount /dev/sysvg/vz /mnt/tmp
On copie:
cp -pr /var/lib/vz/* /mnt/tmp/
On unlink le lien vz->/var/lib/vz pour plus de sureté:
unlink /vz
On supprime « l’ancien » /var/lib/vz:
rm -rf /var/lib/vz/*
On édite le fstab pour ajouter le point de montage en ajoutant la ligne:
/dev/sysvg/vz /var/lib/vz reiserfs defaults 1 2
On mount:
mount -a
On supprime le montage /mnt/tmp:
umount /mnt/tmp
On supprime le montage /mnt/tmp:
umount /mnt/tmp
On recrée le lien /vz /var/lib/vz:
ln -s /var/lib/vz /vz
Tests
C’est le moment de vérité….
Tout est bien monté ?
# mount /dev/sda1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/mapper/sysvg-vz on /var/lib/vz type reiserfs (rw)
OK
Peut on créer une VM ?
# vzctl create 101 --ostemplate debian-5.0-minimal_5.0_i386 vzctl create 101 --ostemplate debian-5.0-minimal_5.0_i386 Creating container private area (debian-5.0-minimal_5.0_i386) Performing postcreate actions Container private area was created
OK
On peut la lancer ?
# vzctl start 101 Starting container ... Container is mounted Adding IP address(es): Setting CPU units: 1000 Configure meminfo: 65536 Container start in progress...
OK
On peut la dumper en mode snapshot ?
Attention a bien specifier le repertoire de destination du dump. Avec cette config autant exploiter les avantages du SSD, on va donc écrire le dump dans /tmp/:
# vzdump --snapshot 101 --dumpdir /tmp/ --bwlimit 0
WARN: unable to parse configuration file '/etc/vzdump.conf' - error at line 1
INFO: starting new backup job: vzdump --snapshot 101 --dumpdir /tmp/ --bwlimit 0
INFO: Starting Backup of VM 101 (openvz)
INFO: CTID 101 exist mounted running
INFO: status = CTID 101 exist mounted running
INFO: backup mode: snapshot
INFO: creating lvm snapshot of /dev/mapper/sysvg-vz ('/dev/sysvg/vzsnap-ns211062.ovh.net-0')
INFO: Logical volume "vzsnap-ns211062.ovh.net-0" created
INFO: creating archive '/tmp/vzdump-openvz-101-2010_04_20-17_25_06.tar'
INFO: Total bytes written: 220538880 (211MiB, 26MiB/s)
INFO: archive file size: 210MB
INFO: delete old backup '/tmp/vzdump-openvz-101-2010_04_20-17_16_32.tar'
INFO: Logical volume "vzsnap-ns211062.ovh.net-0" successfully removed
INFO: Finished Backup of VM 101 (00:00:12)
INFO: Backup job finished successfuly
OK et 12 secondes pour faire le dump c’est pas mal du tout… mais bon il est « surement » preferable de limiter le debit en prod si l’on dump souvent…
Enfin le test ultime:
reboot