Proxmox VE
- Proxmox Openvz
- Proxmox : migration KVM - OpenVZ
- Proxmox sécurisation certificats SSL clients
- KVM backup - snapshot - restore
- Proxmox - Monter une image qcow2
- Proxmox 4 - configuration de VLANs
- Proxmox 4 - configuration bonding + bridge
- Proxmox - Migration VMWare ESXi - Proxmox
- Proxmox - convertir disque IDE vers Virtio
- Proxmox - Installation d'une VM Windows server 2008R2
- Proxmox 2.x - Installation, cluster (avec GlusterFS)
- Proxmox 3.3 - Installation, configuration cluster
- Proxmox 4.0 - Installation, configuration cluster
Proxmox Openvz
Container BlueOnyx
- Télécharger un template de http://devel.blueonyx.it/openvz/ dans /var/lib/vz/template/cache
- Le renommer (<OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz) pour que Proxmox le voit
- S'assurer qu'un fichier de config existe pour la blueonyx (dans /etc/vz/dists il cherche <OS>.conf)
- S'il n'existe pas : cp /etc/vz/dists/centos.conf /etc/vz/dists/blueonyx.conf
- Créer la VZ :
- container (openVZ) et choisir le modèle (template)
- nom, RAM, disque, swap et mot de passe
- ethernet bridgé
- AVANT DE LA DEMARRER LA PREMIERE FOIS
- aller dans l'onglet Options de la VM, activer les quotas (sinon le container BlueOnyx ne finit pas sa configuration, il manquera entre autres l'utilisateur admin), sauvegarder.
- paraméter le réseau : vzctl set 211 --ifname eth0 --ipadd 192.168.0.3 --save
- activer sys_time pour pouvoir changer la date/heure dans le container ensuite (voir ci-dessous)
Lancer la VM
Faire le premier paramétrage Blueonyx par l'interface web en :444
Activation sys_time
Activer la capacité sys_time (sinon on ne peut pas changer la date du container)
Arrêter la VM et activer sys_time :
vzctl stop 211 vzctl set 211 --capability sys_time:on --save
Relancer :
vzctl start 211
On peut modifier directement le fuseau horaire depuis la machine hote :
On entre dans le container :
vzctl enter 211
On définit par exemple le fuseau horaire de Paris:
mv /etc/localtime /etc/localtime.old ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime
Modules IPTABLES
Si on veut utiliser un "stateful firewall" dans une machine virtuelle ("VE"), il faut que 'ipt_state' soit déclaré dans l'option IPTABLES du fichier /etc/vz/vz.conf du serveur physique ("HN") :
IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state"
S'assurer que le module 'xt_state' est chargé aussi :
modprobe xt_state
et l'ajouter dans /etc/modules pour qu'il soit rechargé au redémarrage du HN.
migration KVM vers openVZ
https://kb.systea.fr/books/proxmox-ve/page/proxmox-migration-kvm-openvz
Templates
Site de templates :
https://src.openvz.org/projects/OVZT
http://wiki.openvz.org/Download/template/precreated
http://download.openvz.org
Le nom des templates doit obligatoirement respecter cette régle : <OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz
EX :
archinux-2010.05-minimal_2010.05-1_amd64.tar.gz blueonyx-5106R-standard_5.6-1_i386.tar.gz debian-6.0-standard_6.0-4_i386.tar.gz
ATTENTION : Dans le menu Gestionnaire de VM => Modèles d'Appliance. Si la description des templates est -- unknown --
cela ne veut pas dire qu'il ne fonctionne pas
Proxmox : migration KVM - OpenVZ
Créer une machine virtuelle (VM) OpenVZ de mêmes caractéristiques que la VM KVM. Sur la VM KVM, stopper tous les services.
Debian
Sur le serveur Proxmox, si la VM KVM est accessible à l'adresse 192.168.0.100, et la VM OpenVZ a pour ID 211 :
rsync -avz --numeric-ids --exclude dev --exclude proc --exclude sys --exclude boot --exclude tmp -e "ssh -l root@192.168.0.100" root@192.168.0.100:/ /vz/private/211/ > migr2vz.log
Arrêter la VM OpenVZ. Activer la capacité sys_time (sinon on ne peut pas changer la date du container) :
vzctl stop 211 vzctl set 211 --save --capability sys_time:on
Relancer
vzctl start 211
Supprimer les paquets en trop :
apt-get remove grub-pc linux-image-* acpid
Relancer encore une fois par sécurité.
CentOS
TODO
Proxmox sécurisation certificats SSL clients
L'interface d'administration Proxmox est accessible en HTTPS, donc échanges cryptés et sécurisés par SSL. Les login/mot de passe demandés à la connexion ne passent donc pas en clair.
Pour encore plus de sécurité, on peut forcer le serveur à n'autoriser que les clients disposant d'un certificat local. Sans ce certificat généré avec le CA du serveur, le client n'arrive pas jusqu'à la page de login et reçoit une erreur (certificat erroné, ou certificat client requis, selon les navigateurs).
Sommaire
Installation
Création du certificat client
Eventuellement, modifier
/usr/share/ssl-cert/ssleay.cnf
pour intégrer le nom du serveur ("@HostName@" ne revoit pas toujours le hostname en question). Puis :
cd /tmp mkdir ssl cd ssl/ openssl genrsa -out proxmox-cli-cert.key 2048 openssl req -config /usr/share/ssl-cert/ssleay.cnf -new -key proxmox-cli-cert.key -out proxmox-cli-cert.req openssl x509 -req -in proxmox-cli-cert.req -CA /etc/pve/pve-root-ca.pem -CAkey /etc/pve/pve-root-ca.key -set_serial 101 -days 3650 -outform PEM -out proxmox-cli-cert.pem
Puis on exporte ce certificat dans un format lisible par les navigateurs
openssl pkcs12 -export -inkey proxmox-cli-cert.key -in proxmox-cli-cert.pem -out proxmox-cli-cert.p12
Donner un mot de passe ET S'EN SOUVENIR !
Le fichier P12 contient tout ce qu'il faut, on peut supprimer le reste.
rm proxmox-cli-cert.req proxmox-cli-cert.key proxmox-cli-cert.pem
Configuration d'Apache
Editer /etc/apache2/sites-enabled/pve.conf. Après les lignes "SSLCertificate..." ajouter :
SSLVerifyClient require SSLVerifyDepth 4 SSLCACertificateFile /etc/pve/pve-root-ca.pem
Et ne pas oublier
/etc/init.d/apache2 reload
Utilisation
A partir d'un client sans certificat, vérifier que Proxmox interdit l'accès à l'interface web (on doit avoir une erreur du type "connexion réinitialisée").
Télécharger le fichier p12 (par FTP, SCP, ou tout autre moyen). L'importer dans le navigateur.
- Firefox
Edition / Préférences / Avancé / Chiffrement / Afficher les certificats / Vos certificats / Importer...
- Chrome
Préférences / Options avancées / HTTPS/SSL / Gérer les certificats / Importer...
Une fois importé, vérifier que le navigateur accède (après validation) à la page de login
JAVA (pour les consoles VNCviewer)
Problème à résoudre : la console VNC ne fonctionne plus avec ces certificats.
Résolution temporaire : -> private.
Notes
- Les certificats Proxmox (pve-root-ca) étant générés à l'installation, il contiennent un nom d'hôte générique "@HostName". C'est ce nom qui apparaitra dans le gestionnaire de certificats des navigateurs pour tous les serveur Proxmox.
KVM backup - snapshot - restore
Le backup des machines virtuelles KVM peut se faire de deux façons :
- par snapshot LVM si la machine virtuelle est elle-même dans un volume logique, et qu'il existe un volum group LVM séparé pour les snapshots.
(En effet LVM refuse de créer le snapshot dans le même VG). Par défaut, Proxmox prend le volume pve qu'il a créé à l'installation pour le système : malheureusement, le volume logique "root" prend souvent déjà toute la place.
- par suspension (ou arrêt) de la VM, puis copie tar.gz du disque virtuel vers un répertoire de backup.
Ce répertoire doit exister et avoir été ajouté comme emplacement dans storage, en paramétrant le contenu comme "VZDump backups".
Sauvegarde
Manuellement, VM arrêtée
vzdump --dumpdir /var/lib/vz/backup <ID de la VM>
Snapshot
- par l'interface Proxmox, menu "Sauvegardes", cliquer sur la flèche et "ajouter un nouveau job".
Paramétrer les heures, la destination, les machines à sauvegarder. Indiquer le mode "snapshot".
- Ou, pour une sauvegarde ponctuelle, en ligne de commande, par
vzdump --compress --dumpdir /var/lib/vz/backup --snapshot <ID de la VM>
Tar.gz
- par l'interface Proxmox, menu "Sauvegardes", cliquer sur la flèche et "ajouter un nouveau job". Indiquer le mode "suspend".
- Ou, pour une sauvegarde ponctuelle, en ligne de commande, par
vzdump --suspend <ID de la VM>
Restauration
Snapshot
TODO -
Tar.gz
Le backup se remonte en ligne de commande par :
qmrestore vzdump-qemu-103-2011_03_31-12_07_01.tgz 106
où le fichier tgz est celui créé par le backup, et "106" un ID de machine virtuelle disponible (elle n'a pas besoin d'être créée avant, qemu se débrouille de tout).
Si on souhaite remonter cette sauvegarde dans la même VM qu'avant, il faut d'abord supprimer celle-ci via l'interface puis lancer qmrestore avec son ancien ID.
NOTE : la configuration est restaurée aussi, donc si on utilise cette méthode pour cloner des VMs, attention aux adresses MAC des interfaces réseau qui sont restaurées à l'identique sur les clones !
Pour régénérer une nouvelle adresse MAC, supprimer et recréer l'interface réseau dans la configuration de la VM (Virtual machines/ double-clic sur la VM / onglet Hardware).
Ensuite plusiuers fichiers de conf peuvent devoir être modifiés :
CentOS
Modifier le fichier /etc/udev/rules.d/70-persistent-net.rules. On doit ici supprimer la ligne correspondant à l'interface copiée de l'ancienne vm (se référer aux adresses mac) et changer le champ "NAME=eth1" de la seconde en "NAME=eth0".
Enfin, dans le fichier /etc/sysconfig/network-scripts/ifcfg-eth0, changer la ligne HWADDR= avec l'adresse mac de la nouvelle interface.
Proxmox - Monter une image qcow2
Monter une image qcow2 comme un disque sur le host
# modprobe nbd # qemu-nbd -c /dev/nbd0 /path/to/image.qcow2
ça charge le module Network Block Device kernel module et crée un device NBD.
Identifier la partition :
# fdisk -l /dev/nbd0
Et la monter :
# mount /mnt/vmroot /dev/nbd0p3
Une fois terminé, démonter la partition et décharger le module :
# umount /mnt/vmroot # qemu-nbd -d /dev/nbd0 # rmmod nbd
NOTE: S'il y a des erreurs I/O, essayer l'option ‘-n’ de qemu-nbd pour désactiver le cache du host.
Proxmox 4 - configuration de VLANs
Contrairement à VMware qui propose de créer des "interfaces virtuelles" et des "réseaux virtuels", Proxmox/KVM a besoin de s'appuyer sur les interfaces physiques de l'hôte.
Pour créer des réseaux internes, on a donc deux possibilités :
- une carte inutilisée sur l'hôte, qui sert de base au réseau "internal only"
- des VLANs sur les cartes physiques, qui permettent de déclarer plusieurs adresses par cartes.
Pour ces VLANs, éditer /etc/network.interfaces, créer les VLANs, et déclarer des bridges dessus. Exemple :
auto vlan51 iface vlan51 inet manual vlan_raw_device eth1 auto vmbr1 iface vmbr1 inet static address 192.168.2.128 netmask 255.255.255.0 bridge_ports vlan51 bridge_stp off bridge_fd 0
L'interface eth1 utilisée ci-dessus peut très bien avoir sa propre IP utilisable par l'hôte ou des VM pour accéder au "vrai" réseau.
Proxmox 4 - configuration bonding + bridge
NETWORK : Attention !
Si plusieurs cartes de l'hôte doivent être sur le même réseau, elles doivent être liée par bonding (voir ci-dessous), sinon ça pose un problème de route (il a la même route pour un network donné vers plusieurs interfaces. C'est la dernière configurée qui gagne, mais dans ce cas les interfaces précédentes ne répondent plus car elles ne savent plus router). On aurait pu imaginer répartir les VMs sur différentes interfaces physique de l'hôte pour faire de la répartition de charge, mais ça ne passe pas au niveau paramétrage.
Il faut mettre en place du bonding dans ce cas. Dans l'exemple suivant, eth0 et eth1 sont en bonding sur le réseau local, ET eth2 est connectée à un réseau publique. Le bonding sert de bridge aux machines virtuelles sur le réseau local, eth2 sert de bridge aux machines devant avoir accès au réseau publique (et pour un firewall par exemple, il accèdera aux 2 bridges).
Toute la configuration a été faite par l'interface, seule la gateway de vmbr1 a été ajoutée manuellement (le champ gateway n'apparaissait pas au départ dans l'interface web) :
# network interface settings auto lo iface lo inet loopback iface eth0 inet manual iface eth1 inet manual iface eth2 inet manual iface eth3 inet manual auto bond0 iface bond0 inet manual slaves eth0 eth1 bond_miimon 100 bond_mode active-backup auto vmbr0 iface vmbr0 inet static address 192.168.1.110 netmask 255.255.255.0 bridge_ports bond0 bridge_stp off bridge_fd 0 auto vmbr1 iface vmbr1 inet static address 10.12.0.2 netmask 255.255.255.0 gateway 10.12.0.254 bridge_ports eth2 bridge_stp off bridge_fd 0
Proxmox - Migration VMWare ESXi - Proxmox
Migration VMware -> KVM
La transformation varie selon que la VM KVM de destination fonctionne en fichier qcow2 ou dans un volume logique (utile pour le cluster avec LVM).
Noter la taille du disque d'origine, le type de contrôleur, le nombre de CPU, la taille mémoire en prévision de la re-création de la VM KVM.
Arrêter la VM VMware. Le fichier d'origine ne sera pas touché, une sauvegarde n'est donc pas obligatoire.
Copier le disque de la VM vers le serveur Proxmox, avec vmkfstools (plus sûr et plus rapide que cp)
- Migration en fichier qcow2
qemu-img convert -O qcow2 VM_vmware.vmdk VM_kvm.qcow2
- Transfert dans un volume logique
Créer la machine virtuelle par l'interface (attention à la taille disque qui doit correspondre à la taille de la VM d'origine ! On peut la voir après conversion en raw, le fichier aura la taille exacte finale), de façon à ce que le volume logique existe. Puis :
dd if=VM_vmware.vmdk of=/dev/pve/vm-102-disk-1
Créer une VM proxmox, full virtualized, avec un disque de taille correspondante. Copier le disque migré dans le répertoire
NOTE : si la VM ne démarre pas ensuite (que ce soit en qcow2 ou en LVM, message "booting from hard disk...boot failed: not a bootable disk"), changer le disque vmdk en "preallocated". Le mode "single growable" (dynamique) peut poser problème lors de la migration. Sur une machine vmware (Server ou ESX) modifier le fichier avec :
vmware-vdiskmanager -r VM_vmware.vmdk -t 2 VM_vmware-pa.vmdk
Et retenter la conversion en qcow2 ou la copie vers le volume logique.
Proxmox - convertir disque IDE vers Virtio
Si on a monté une machine virtuelle linux en déclarant un disque IDE (ou si on récupère une image d'un autre hyperviseur), on peut vouloir monter le disque en VIRTIO pour augmenter les performances.
Problème : sur linux (CentOS au moins, à tester sur Debian), on a un kernel panic au boot car la machine virtuelle ne retrouve pas ses partitions. Le problème vient de l'initrd. Solution :
- Machine virtuelle démarrée normalement, aller dans /boot
- Vérifier dans /boot/grub/menu.lst quel est le noyau et l'initrd utilisés au boot (attention à l'option "default" ! On ne fera pas de cours sur Grub ici, ce n'est pas le sujet)
- Sauvegarder l'initrd en question par "cp"
- Générer un nouvel initrd (en s'assurant qu'il retrouve un nom compatible avec le menu.lst !) :
mkinitrd -f --with=virtio_pci --with=virtio_blk --with=virtio -f /boot/initrd-$(uname -r).img $(uname -r)
- Eteindre la machine virtuelle
- Dans l'onglet "Matériel" de Proxmox, supprimer le disque (par un clic sur la flèche à gauche du disque), puis re-ajouter ce même disque en virtio (sur la flèche de "Liste des interfaces matériel...", "ajouter un disque dur", dans la partie basse du tableau qui doit lister le disque en question, choisir VIRTIO et cliquer sur "add").
- Lancer la VM
Proxmox - Installation d'une VM Windows server 2008R2
Drivers invité : https://github.com/YanVugenfirer/kvm-guest-drivers-windows
Direct 3D : http://www.nongnu.org/wined3d/
Utilisation du drivers graphique vmware : http://www.linux-kvm.com/content/using-vmware-vga-kvm-windows-guests
Proxmox 2.x - Installation, cluster (avec GlusterFS)
Installation à partir des ISO
Le problème de l'installation à partir des CD est que le partitionnement est automatique, et impossible à modifier. Jusqu'à la version 2, la partition root était un pourcentage de l'espace total, ce qui pouvait amener à avoir des centaines de Go pour le système ! Depuis la version 2.xx, la partition racine semble être dimensionnée à une centaine de Go quelque soit la taille disponible. Mais c'est encore énorme, pour un système qui n'a besoin que d'à peine 800Mb de base ! Mais admettons...
L'installation est on ne peut plus simple : graver l'ISO téléchargée chez Proxmox (http://pve.proxmox.com/wiki/Downloads), booter sur le CD, suivre les indications... Voilà.
Installation manuelle sur Squeeze par les paquets deb
D'après http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Squeeze
Installer une Squeeze de base, avec une partition root (10Go minimum) et une partition LVM (Volum Group "pve", et un volume logique "data" pour respecter leurs nommages) montée sur /var/lib/vz qui recevra les machines virtuelles. Avec la Squeeze, on peut utiliser ext3 ou ext4.
Editer /etc/apt/sources.list
- Ajouter "contrib" aux lignes "[...] squeeze main" s'il n'y est pas déjà
- Ajouter :
# PVE packages provided by proxmox.com deb http://download.proxmox.com/debian squeeze pve
Charger la clé de signature des paquets Proxmox
wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add - apt-get update aptitude full-upgrade
Activer l'IP forwarding :
echo 1 > /proc/sys/net/ipv4/ip_forward
Et enregistrer la modification dans /etc/sysctl.conf pour les prochains redémarrages :
net.ipv4.ip_forward=1
Installer le noyau Proxmox
aptitude search pve-kernel # trouver le noyau pve le plus récent aptitude install pve-firmware aptitude install pve-kernel-2.6.32-19-pve reboot uname -a # vérifier que le noyau PVE est chargé Linux proxmox1 2.6.32-19-pve #1 SMP [.....] x86_64 GNU/Linux
IMPORTANT : vérifier que le nom du serveur correspond bien à son ip dans le fichier /etc/hosts, exemple :
10.0.0.2 proxmox1.localdomain proxmox1
L'installation de Proxmox cherche l'adresse IP et le nom de serveur dans /etc/hosts.
Installer Proxmox VE
aptitude install proxmox-ve-2.6.32
Si quelque chose s'est mal passé pendant l'installation, corriger le problème et finir l'installation par
apt-get install -f
Activer l'interface webUI
a2ensite pve-redirect.conf /etc/init.d/apache2 restart
Installer le reste des paquets nécessaires
aptitude install ntp ssh lvm2 postfix ksm-control-daemon vzprocps open-iscsi
Accepter le remplacement d'Exim, paramétrer Postfix selon le réseau ("site internet" par défaut)
Accéder à l'interface d'admin (login root du serveur)
https://<adresse du serveur>:8006/
Dans l'onglet réseau, enlever les paramètres d'eth0, paramétrer le bridge vmbr0 (eth0 en "bridge port")
Note : Proxmox VE copie le fichier de configuration (ici /etc/network/interfaces, mais c'est ne même principe pour les fichiers proxmox eux-mêmes dans /etc/pve) en <nom_du_fichier>.new. Au prochain redémarrage, ces fichiers prendront la place des fichiers des "vrais" et la nouvelle configuration sera prise en compte durant le boot du système.
Le fichier interfaces.new doit ressembler à ça (ATTENTION AU "bridge_stp on" et pas "off") :
# network interface settings auto lo iface lo inet loopback iface eth0 inet manual broadcast 10.255.255.255 network 10.0.0.0 dns-nameservers 10.0.0.254 dns-search local.systea.net # dns-* options are implemented by the resolvconf package, if installed iface eth1 inet manual auto vmbr0 iface vmbr0 inet static address 10.0.0.2 netmask 255.0.0.0 gateway 10.0.0.254 bridge_ports eth0 bridge_stp on bridge_fd 0
TIPS : Pour lier 2 cartes réseau et faire du "bonding", éditer manuellement ce fichier (au besoin, le créer en copiant le fichier interfaces) et modifier la configuration en ajoutant "bond0" pour lier eth0 et eth1 par exemple, et lier vmbr0 à cette nouvelle interface :
# network interface settings auto lo iface lo inet loopback
iface eth0 inet manual
iface eth1 inet manual
auto bond0 iface bond0 inet manual slaves eth0 eth1 bond_miimon 100 bond_mode active-backup auto vmbr0 iface vmbr0 inet static address 10.0.0.2 netmask 255.0.0.0 gateway 10.0.0.254 bridge_ports bond0 bridge_stp off bridge_fd 0
Activer la configuration :
reboot
Mise en cluster
Création du cluster
D'après http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster
Si les DNS ne sont pas disponibles sur le réseau, paramétrer /etc/hosts sur chaque serveur du cluster pour qu'ils se reconnaissent entre eux (IP et nom).
Créer le cluster sur un des noeuds
pvecm create YOUR-CLUSTER-NAME
Et vérifier :
pvecm status
Aller sur chacun des autres noeuds et les ajouter au cluster
pvecm add IP-DU-PREMIER-NOEUD-DU-CLUSTER
Après échange de clés, le nouveau noeud doit apparaitre dans l'interface web.
Attention, les clés SSL des noeuds "secondaires" ont changé pendant ce processus (identiques sur tous les noeuds à celles du premier noeud), vider le cache du navigateur et se reconnecter à l'interface.
Fencing
le "fencing" est l'action pour une machine d'interagir sur une autre host en l'arrêtant, ou le redémarrant, via un "fencing device" souvent implémenté par les contructeurs sur des "management cards" (BMC, DRAC, ILO, ...).
La configuration des fencing devices sur Proxmox est manuelle.
D'abord, tester si les fencing device sont joignables et si on a les bons paramètres. Proxmox installe les outils pour la plupart des cartes connues, exemple :
(On utilise fence_ilo ici, mais cette commande varie en fonction de la marque du matériel (ex: fence_drac, fence_ipmi...). fence_ilo est associé au matériel HP)
fence_ilo -o status -a 192.168.0.2 -l admin -p mot_de_passe Status: ON
Pour un matériel IPMI (par exemple Dell iDrac), installer ipmitool
apt-get install ipmitool
Puis:
fence_ipmilan -a 192.168.0.2 -l admin -p mot_de_passe -o status Getting status of IPMI:192.168.0.2...Chassis power = On
Pour un Dell iDrac7, ajouter les argument "-P" et "-C 2"
fence_ipmilan -a 192.168.0.2 -l root -p root -o status -P -C 2
Sur tous les noeuds : vi /etc/default/redhat-cluster-pve
FENCE_JOIN="yes"
Joindre le noeud au domaine de fencing
fence_tool join fence_tool ls
Sur un des noeuds, on va modifier cluster.conf. On commence par le copier en .new et on édite celui-ci
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new vi /etc/pve/cluster.conf.new
Première chose : augmenter le "config_version", sinon le fichier ne sera pas répliqué sur les autres noeuds !
<cluster name="hpiloclust" config_version="2">
Ajouter la definition des fencing devices à utiliser, juste après </clusternodes>
<fencedevices> <fencedevice agent="fence_ipmilan" hostname="nomDNS_du_fencing_device_nodeA" login="admin" name="fenceNodeA" passwd="mot_de_passe"/> <fencedevice agent="fence_idrac" ipaddr="IP_du_fencing_device_nodeB" login="admin" name="fenceNodeB" passwd="mot_de_passe"/> </fencedevices>
Noter l'utilisation de "hostname" ou "ipaddr" selon ce qu'on choisit d'indiquer.
Puis, enlever le "/" à la fin de chaque stanza "clusternode" (au singulier) et lier le "fence device" au "clusternode" :
<clusternode name="nodeA.your.domain" nodeid="1" votes="1"> <fence> <method name="1"> <device name="fenceNodeA" action="reboot"/> </method> </fence> </clusternode> <clusternode name="nodeB.your.domain" nodeid="2" votes="1"> <fence> <method name="1"> <device name="fenceNodeB" action="reboot"/> </method> </fence> </clusternode>
Valider la nouvelle configuration :
ccs_config_validate -v -f /etc/pve/cluster.conf.new
Aller sur l'interface graphique, sélectionner le datacenter à gauche puis l'onglet HA.
Il charge alors le cluster.conf.new, vérifie la syntaxe (corriger les erreurs éventuelles qu'il affiche avec numéro de ligne et colonne) et affiche en bas les modifications à faire. Si c'est OK, cliquer sur Activer (bouton "Activate" dans la barre de menu).
Haute disponibilité
Pour qu'une VM soit prise en compte dans la haute dispo (migration en cas de crash), sélectionner le datacenter à gauche, onglet "HA", bouton "Ajouter", une "VM/CT gérée par HA"
Indiquer l'ID de la VM à prendre en compte.
Valider, Activer la modification.
Des erreurs de migrations (mauvaise configuration, etc...) peuvent "verrouiller" la VM et empêcher des migrations futures (erreur 254 en général). Pour débloquer il faut stopper la VM proprement pour ne rien perdre, puis clic droit sur la VM à gauche et "Stopper" (le bouton Stopper n'est pas disponible en haut à droite à ce moment, que dans le menu contextuel)
GLusterFS
Glusterfs permet très simplement et de façon fiable d'avoir un système de fichiers partagé, répliqué et/ou distribué entre plusieurs serveurs. Le répertoire géré par GlusterFS sera vu comme un partage NFS dans Proxmox.
http://gluster.org/community/documentation//index.php/Main_Page
Sur tous les noeuds :
Ajouter la clé gluster.org :
wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key | apt-key add -
Ajouter le dépôt Glusterfs :
vi /etc/apt/sources.list.d/glusterfs.list deb http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo squeeze main
Et installer le serveur (le client suivra en dépendance) :
aptitude install glusterfs-server
Préparer le terrain :
mkdir /var/lib/glusterfs
Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :
gluster peer probe node2 gluster volume create glusterstorage replica 2 node1:/var/lib/glusterfs node2:/var/lib/glusterfs gluster volume start glusterstorage
Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :
gluster peer probe node3 gluster volume add-brick glusterstorage replica 3 proxmox3:/var/lib/glusterfs gluster volume info
Dans l'interface, Créer un stockage NFS, sur localhost : le volume gluster est vu tout de suite comme partage NFS, et monté en localhost sur tous les noeuds.
Fonctionnement du cluster
le répertoire /etc/pve est en réalité un device FUSE (monté en mémoire, en espace utilisateur) afin d'être répliqué par Corosync et sauvegardé sur disque dans une base SQLite.
On modifie (ou l'interface modifie) les fichiers en créant une copie en .new. Au moment de la validation (ou du reboot, comme pour la configuration réseau) ce fichier remplace le "vrai" et celui-ci est répliqué sur tous les noeuds.
Pour basculer toutes les VM sur un autre host (pour maintenance par exemple) arrêter le Resource Group manager (par l'interface, onglet Services, ou en ligne de commande "/etc/init.d/rgmanager stop").
Ligne de commande
clustat # Etat du cluster
ccs_config_validate -v -f /etc/pve/cluster.conf.new # Validation des modifications apportées
ccs_tool lsnode -v # Détail des noeuds
Migration à froid (arrêt de la VM avant migration, ou pour une VM déjà arrêtée)
clusvcadm -r pvevm:101 -m proxmox2
Migration à chaud
clusvcadm -M pvevm:101 -m proxmox2
TIPS
Drivers virtio pour Windows
Charger l'iso virtio-win : http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers
pendant l'install de Windows dans la VM, l'écran de sélection de disque n'affiche aucun préiphérique. Sur la VM, dans l'interface web, changer le CD et charger virtio-win. Demander à l'installateur windows de parcourir ce CD, sélectionner la version win voulue et charger les drivers redhat*. Une fois chargés, Windows doit voir le disque. Remettre le CD Windows dans le lecteur virtuel.
Clavier français dans les consoles VNC
Dans l'onglet options du datacenter, forcer le clavier en French. Si ça ne suffit pas, sur les VM dans l'onglet Matériel, faire de même (il faut redémarrer la VM dans ce cas)
Proxmox 3.3 - Installation, configuration cluster
Installation
L'installation se fait à partir de l'image ISO (http://www.proxmox.com/downloads). L'installation est simple, se fait par une interface graphique mais ne propose toujours pas de partitionner manuellement les disques.
Une fois installé, l'accès à l'interface web se fait à l'adresse https://<IP du serveur>:8006
Configuration
Mises à jour
Depuis la version 3, les éditeurs de Proxmox ont modifié les dépôts. Les dépôts configurés de base sont réservés aux clients qui ont souscrit au support de Proxmox. N'étant pas notre cas, il faut modifier les sources pour accéder aux dépôts gratuits. REMPLACER le contenu du fichier source.list
# vi /etc/apt/sources.list
Par :
deb http://ftp.debian.org/debian wheezy main contrib # PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use deb http://download.proxmox.com/debian wheezy pve-no-subscription # security updates deb http://security.debian.org/ wheezy/updates main contrib
Puis supprimer le fichier qui contient le dépôt par défaut. Ceci évite des messages d'erreurs (connection refusée) lors des "apt-get update".
rm /etc/apt/sources.list.d/pve-enterprise.list
On peut maintenant effectuer les mises à jour
apt-get update apt-get install debian-keyring debian-archive-keyring apt-get upgrade
IMPORTANT : upgrade met à jour les paquets mais pas le noyau. Si celui-ci doit être mis à jour (exemple : zfs 0.6.4-4~wheezy demande le noyau 2.6.32-40 spécialement adapté pour cette version), lancer plutôt :
apt-get dist-upgrade
Fichiers hosts
Il faut modifier les fichiers /etc/hosts sur chacun des noeuds qui seront ajoutés au cluster. Ceux-ci doivent contenir les adresses et noms de tous les noeuds. Exemple :
Sur le noeud "pm0" :
root@pm0 : #cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 10.10.168.5 pm0.local pm0 pvelocalhost 10.10.168.10 pm1.local pm1 10.10.168.15 pm2.local pm2
Sur un second noeud :
root@pm2 : #cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 10.10.168.5 pm0.local pm0 10.10.168.10 pm1.local pm1 10.10.168.15 pm2.local pm2 pvelocalhost
Mise en cluster
On considère ici deux machines Proxmox fraîchement installées à l'identique. Pour fonctionner en cluster, il faut définir un noeud Maître. Sur une des deux machines éxecuter
pvecm create <nom_du_cluster>
Pour vérifier la création du cluster, lancer
# pvecm status Version: 6.2.0 Config Version: 1 Cluster Name: FWCluster Cluster Id: 40372 Cluster Member: Yes Cluster Generation: 4 Membership state: Cluster-Member Nodes: 1 Expected votes: 1 Total votes: 1 Node votes: 1 Quorum: 1 Active subsystems: 5 Flags: Ports Bound: 0 Node name: herrena Node ID: 1 Multicast addresses: 239.192.157.82 Node addresses: 192.168.37.11
Une fois le cluster créé, il faut ajouter la seconde machine. Pour cela, sur le second Proxmox, lancer la commande :
(où l'adresse IP correspond à celle du nœud Maître)
pvecm add <adresse_du_maitre>
Echangez les clés, puis vérifier l'ajout
pvecm status
Si cette commande fonctionne sur le second nœud, l'ajout a fonctionné. On peut s'en assurer en regardant dans la sortie de la commande précédente, la ligne :
Nodes: 2
Fencing
le "fencing" est l'action pour une machine d'interagir sur une autre host en l'arrêtant, ou le redémarrant, via un "fencing device" souvent implémenté par les contructeurs sur des "management cards" (BMC, DRAC, ILO, ...).
La configuration des fencing devices sur Proxmox est manuelle.
D'abord, tester si les fencing device sont joignables et si on a les bons paramètres. Proxmox installe les outils pour la plupart des cartes connues, exemple :
(On utilise fence_ilo ici, mais cette commande varie en fonction de la marque du matériel (ex: fence_drac, fence_ipmi...). fence_ilo est associé au matériel HP)
fence_ilo -o status -a 192.168.0.2 -l admin -p mot_de_passe Status: ON
Pour un matériel IPMI (par exemple Dell iDrac), installer ipmitool
apt-get install ipmitool
Puis:
fence_ipmilan -a 192.168.0.2 -l admin -p mot_de_passe -o status Getting status of IPMI:192.168.0.2...Chassis power = On
Pour un Dell iDrac7, ajouter les argument "-P" et "-C 2"
fence_ipmilan -a 192.168.0.2 -l root -p root -o status -P -C 2
Sur tous les noeuds : vi /etc/default/redhat-cluster-pve
FENCE_JOIN="yes"
Joindre le noeud au domaine de fencing
fence_tool join fence_tool ls
Sur un des noeuds, on va modifier cluster.conf. On commence par le copier en .new et on édite celui-ci
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new vi /etc/pve/cluster.conf.new
Première chose : augmenter le "config_version", sinon le fichier ne sera pas répliqué sur les autres noeuds !
<cluster name="hpiloclust" config_version="2">
Ajouter la definition des fencing devices à utiliser, juste après </clusternodes>
<fencedevices> <fencedevice agent="fence_ipmilan" hostname="nomDNS_du_fencing_device_nodeA" login="admin" name="fenceNodeA" passwd="mot_de_passe"/> <fencedevice agent="fence_idrac" ipaddr="IP_du_fencing_device_nodeB" login="admin" name="fenceNodeB" passwd="mot_de_passe" cipher="2" lanplus="on"/> </fencedevices>
Noter l'utilisation de "hostname" ou "ipaddr" selon ce qu'on choisit d'indiquer. Noter également la présence de paramètre supplémentaires, ajoutés selon les besoins, comme par exemple cipher="2" et lanplus="on" (IDrac 7).
Puis, enlever le "/" à la fin de chaque stanza "clusternode" (au singulier) et lier le "fence device" au "clusternode" :
<clusternode name="nodeA.your.domain" nodeid="1" votes="1"> <fence> <method name="1"> <device name="fenceNodeA" action="reboot"/> </method> </fence> </clusternode> <clusternode name="nodeB.your.domain" nodeid="2" votes="1"> <fence> <method name="1"> <device name="fenceNodeB" action="reboot"/> </method> </fence> </clusternode>
Valider la nouvelle configuration :
ccs_config_validate -v -f /etc/pve/cluster.conf.new
Aller sur l'interface graphique, sélectionner le datacenter à gauche puis l'onglet HA.
Il charge alors le cluster.conf.new, vérifie la syntaxe (corriger les erreurs éventuelles qu'il affiche avec numéro de ligne et colonne) et affiche en bas les modifications à faire. Si c'est OK, cliquer sur Activer (bouton "Activate" dans la barre de menu).
GLusterFS
Glusterfs permet très simplement et de façon fiable d'avoir un système de fichiers partagé, répliqué et/ou distribué entre plusieurs serveurs. Le répertoire géré par GlusterFS sera vu soit comme une partition GlusterFS (Proxmox 3, par la librairie glusterfs), soit comme un partage NFS (fourni par GlusterFS).
http://gluster.org/community/documentation//index.php/Main_Page
Sur tous les noeuds :
Ajouter la clé gluster.org :
wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key | apt-key add -
Ajouter le dépôt Glusterfs :
vi /etc/apt/sources.list.d/glusterfs.list deb http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo squeeze main
Et installer le serveur (le client suivra en dépendance) :
aptitude install glusterfs-server
Préparer le terrain (la partition partagée sera dans le volume des VMs de Proxmox):
mkdir /var/lib/vz/glusterfs
Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :
gluster peer probe node2 gluster volume create glusterstorage replica 2 node1:/var/lib/vz/glusterfs node2:/var/lib/vz/glusterfs gluster volume start glusterstorage
Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :
gluster peer probe node3 gluster volume add-brick glusterstorage replica 3 node3:/var/lib/vz/glusterfs gluster volume info
Accès par la librairie glusterfs
Dans l'interface, Créer un stockage GlusterFS, remplissez les champs Serveur principal et Serveur secondaire avec les noms de vos serveurs. Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").
Accès en NFS
Dans l'interface, Créer un stockage NFS, remplissez le champ Serveur avec "localhost". Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").
Benchmark librairie glusterfs / NFS
La différence est notable. En fonctionnement en HA, proxmox est capable de migrer une machine, lorsqu'il perd un noeud du cluster, sur un second. Ceci est vrai seulement avec la librairie NFS. De notre expérience, non seulement les machines ne sont pas migrées, mais les disques virtuels sont parfois endommagés !
Quorum
Le Quorum est une partition partagée, à partir d'une troisième machine, qui permet d'utiliser la HA. Cette machine sert en fait de référent aux Proxmox, qui ont parfois du mal à déterminer s'il y a une panne ou non dans un configuration avec uniquement 2 noeuds Proxmox. On ajoute donc de la stabilité et une couche de sécurité pour les VMs/données.
Cette troisième machine sera ici une CentOS 6.5.
iSCSI
iSCSI est choisi pour partager la partition entre les différents noeuds du cluster.
Pour commencer, créer la partition. (Réduire une autre si cela est nécessaire, en théorie QDisk n'utilise qu'une partition de 10Mo)
lvcreate -n quorumdisk -L 10M vg_QUORUM
Installer le serveur iSCSI :
yum -y install scsi-target-utils # (nom du paquet sous CentOS)
Important ! : le port 3260 doit être ouvert pour permettre les connexions à la cible iSCSI.
Créer ensuite la cible iSCSI (Des conventions de nommage ont été mises en place. Il est recommandé de les utiliser : http://en.wikipedia.org/wiki/ISCSI#Addressing)
# vim /etc/tgt/targets.conf <target iqn.2012-06.com.domain.hostname:server.p1qdisk> backing-store /dev/vg_QUORUM/quorumdisk initiator-address <IP_du_noeud_1> initiator-address <IP_du_noeud_2> </target>
Démarrer ensuite le service tgt, et le paramétrer pour le démarrage automatique :
service tgtd start chkconfig tgtd on tgt-admin -s #notre volume doit apparaître ici
Il faut maintenant monter la cible sur les Proxmox. Installer tgt (il installe open-iscsi en dépendance sur le client, c'est lui dont on a besoin) :
apt-get install tgt # (nom du paquet sous Debian / Proxmox).
Modifier ensuite le fichier /etc/iscsi/iscsid.conf. Le champ node.startup doit être configuré en automatic
#vim /etc/iscsi/iscsid.conf ... #***************** # Startup settings #***************** # To request that the iscsi initd scripts startup a session set to "automatic". # node.startup = automatic # # To manually startup the session set to "manual". The default is manual. node.startup = automatic ...
Redémarrer le client iscsi :
service open-iscsi restart
On peut maintenant tester quelles cibles les clients voient :
iscsiadm --mode discovery --type sendtargets --portal <IP_du_ serveur iSCSI>
Puis se connecter à la cible qui nous interesse :
iscsiadm -m node -T iqn.BLAHBLAH -p <IP_du_serveur_iSCSI> -l
Configurer QDisk
Il faut identifier la partition qui correspond au volume logique précédemment créé. On crée ensuite une partition sur celui-ci, via fdisk (ici sdc1 mais peut varier suivant la configuration de votre système). Une fois ceci fait on peut créer le disque de Quorum :
mkqdisk -c /dev/sdc1 -l qdisk_proxmox #Noter que le paramètre -l est suivi du nom que vous souhaitez donner à votre disque de Quorum
Déconnecter et reconnecter les clients pour voir les changements :
iscsiadm --mode node --target <IQN> --portal x.x.x.x --logout iscsiadm --mode node --target <IQN> --portal x.x.x.x --login
Ajouter QDisk au cluster
Sur un des deux noeuds :
Copier le fichier cluster.conf en cluster.conf.new
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
Editer ce fichier en prenant soins de :
1) Incrémenter "config_version" de 1
2) Supprimer 2node="1"
3) Ajouter la définition du Quorum
Cela doit ressembler à peu près à ceci :
<cman expected_votes="3" keyfile="/var/lib/pve-cluster/corosync.authkey"/> <quorumd votes="1" allow_kill="0" interval="1" label="qdisk_proxmox" tko="10"/> <totem token="54000"/>
Activer les modifications : Sur l'interface Web de Proxmox, selectionner le datacenter (dans le menu de gauche) puis sélectionner l'onglet HA. On voit ici apparaître le fichier fraîchement modifié. cliquer sur Activate pour charger les modifications dans le cluster.
Lancer la commande pvecm s et vérifier que les deux noeuds on bien reçu les modifications du cluster.conf. Puis sur chacun des noeuds, un à la fois :
service rgmanager stop service cman reload
la dernière commande devrait reancer rgmanager, si non, relancez le manuellement.
Vérification On peut utiliser la commande clustat pour vérifier que le quorum est présent et connecté
#clustat Cluster Status for proxmox1 @ Mon Nov 24 16:46:23 2014 Member Status: Quorate Member Name ID Status ------ ---- ---- ------ proxmox1 1 Online, Local, rgmanager proxmox2 2 Online, rgmanager /dev/block/8:16 0 Online, Quorum Disk
Astuces et notes
Supprimer l'avertissement de souscription
Lorsqu'on utilise Proxmox 3 sans souscription, un message apparrait à chaque login sur l'interface web. Pour se débarrasser de ce message, il faut modifier le fichier pvemanagerlib.js. On commence par sauvegarder le fichier d'origine :
# cp /usr/share/pve-manager/ext4/pvemanagerlib.js /usr/share/pve-manager/ext4/pvemanagerlib.js.OLD
Puis on édite
# vim /usr/share/pve-manager/ext4/pvemanagerlib.js
Il faut chercher l'instruction IF de la forme suivante :
if (data.status !== 'Active') { Ext.Msg.show({ title: gettext('No valid subscription'), icon: Ext.Msg.WARNING, msg: PVE.Utils.noSubKeyHtml, buttons: Ext.Msg.OK,
En fait, Proxmox teste si on a un abonnement non actif, auquel cas, il affiche le message. Il nous suffit donc de remplacer le test par false
if (false) { Ext.Msg.show({ title: gettext('No valid subscription'), icon: Ext.Msg.WARNING, msg: PVE.Utils.noSubKeyHtml, buttons: Ext.Msg.OK,
Problèmes connus avec QDisk
Les noeuds Proxmox utilisent iSCSI pour se connecter au disque de Quorum partagé. Les machines proxmox, au démarrage, lancent une connexion à la cible iSCSI. Or, si la machine de Quorum n'est pas présente lors de cette étape, les connexion échouent logiquement. Les proxmox ne sont ensuite pas capables de se reconnecter automatiquement au disque de quorum, il faut soit les redémarrer, soit connecter la cible manuellement, en ligne de commande. Bien que ce soit un scénario plus rare, il est toujours bon de savoir quoi faire.
Proxmox 4.0 - Installation, configuration cluster
Installation
L'installation se fait à partir de l'image ISO (http://www.proxmox.com/downloads). L'installation est simple, se fait par une interface graphique mais ne propose toujours pas de partitionner manuellement les disques. La particularité de la version 4 est qu'on peu (enfin !) décider de la taille de la partition root et de celle des données. Au moment de sélectionner le disque où sera installé Proxmox, cliquer sur "options", indiquer au moins : taille de la swap (en Go, idéalement 2*taille de la RAM) et taille de la partition root (20Go doivent suffire au système).
Une fois installé, l'accès à l'interface web se fait à l'adresse https://<IP du serveur>:8006
Configuration
Mises à jour
Depuis la version 3, les éditeurs de Proxmox ont modifié les dépôts. Les dépôts configurés de base sont réservés aux clients qui ont souscrit au support de Proxmox. N'étant pas notre cas, il faut modifier les sources pour accéder aux dépôts gratuits. Dans source.list :
# vi /etc/apt/sources.list
Ajouter :
# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use deb http://download.proxmox.com/debian jessie pve-no-subscription
Puis supprimer le fichier qui contient le dépôt par défaut. Ceci évite des messages d'erreurs (connection refusée) lors des "apt-get update".
rm /etc/apt/sources.list.d/pve-enterprise.list
On peut maintenant effectuer les mises à jour
apt-get update apt-get install debian-keyring debian-archive-keyring apt-get dist-upgrade
"apt-get upgrade" met à jour les paquets mais pas le noyau. C'est pourquoi on lui préfère dist-upgrade au moment de l'installation.
Fichiers hosts
Il faut modifier les fichiers /etc/hosts sur chacun des noeuds qui seront ajoutés au cluster. Ceux-ci doivent contenir les adresses et noms de tous les noeuds. Exemple :
Sur le noeud "pm0" :
root@pm0 : #cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 10.10.168.5 pm0.local pm0 pvelocalhost 10.10.168.10 pm1.local pm1 10.10.168.15 pm2.local pm2
Sur un second noeud :
root@pm2 : #cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 10.10.168.5 pm0.local pm0 10.10.168.10 pm1.local pm1 10.10.168.15 pm2.local pm2 pvelocalhost
Mise en cluster
On considère ici deux machines Proxmox fraîchement installées à l'identique. Pour fonctionner en cluster, il faut définir un noeud Maître. Sur une des deux machines éxecuter
pvecm create <nom_du_cluster>
Pour vérifier la création du cluster, lancer
# pvecm status Version: 6.2.0 Config Version: 1 Cluster Name: FWCluster Cluster Id: 40372 Cluster Member: Yes Cluster Generation: 4 Membership state: Cluster-Member Nodes: 1 Expected votes: 1 Total votes: 1 Node votes: 1 Quorum: 1 Active subsystems: 5 Flags: Ports Bound: 0 Node name: herrena Node ID: 1 Multicast addresses: 239.192.157.82 Node addresses: 192.168.0.5
Une fois le cluster créé, il faut ajouter la seconde machine. Pour cela, sur le second Proxmox, lancer la commande :
(où l'adresse IP correspond à celle du nœud Maître)
pvecm add <adresse_du_maitre>
Echangez les clés, puis vérifier l'ajout
pvecm status
Si cette commande fonctionne sur le second nœud, l'ajout a fonctionné. On peut s'en assurer en regardant dans la sortie de la commande précédente, la ligne :
Nodes: 2
Fencing
le "fencing" est l'action pour une machine d'interagir sur une autre host en l'arrêtant, ou le redémarrant, via un "fencing device" souvent implémenté par les contructeurs sur des "management cards" (BMC, DRAC, ILO, ...). Depuis la version 4, le fencing est géré par Watchdog et est automatiquement configuré. Joie et bonheur. Si le matériel dispose d'un watchdog, il est détecté et utilisé. Sinon Proxmox utilise le module linux softdog.
GLusterFS
Glusterfs permet très simplement et de façon fiable d'avoir un système de fichiers partagé, répliqué et/ou distribué entre plusieurs serveurs. Le répertoire géré par GlusterFS sera vu soit comme une partition GlusterFS (Proxmox 3, par la librairie glusterfs), soit comme un partage NFS (fourni par GlusterFS).
http://gluster.org/community/documentation//index.php/Main_Page
Sur tous les noeuds :
Ajouter la clé gluster.org et le dépôt Glusterfs :
wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/pub.key | apt-key add - echo deb http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/Debian/jessie/apt jessie main > /etc/apt/sources.list.d/gluster.list apt-get update
Et installer le serveur (le client suivra en dépendance) :
aptitude install glusterfs-server
Préparer le terrain (la partition partagée sera dans le volume des VMs de Proxmox):
mkdir /var/lib/vz/glusterfs
Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :
gluster peer probe node2 gluster volume create glusterstorage replica 2 node1:/var/lib/vz/glusterfs node2:/var/lib/vz/glusterfs gluster volume start glusterstorage
Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :
gluster peer probe node3 gluster volume add-brick glusterstorage replica 3 node3:/var/lib/vz/glusterfs gluster volume info
Accès par la librairie glusterfs
Dans l'interface, Créer un stockage GlusterFS, remplissez les champs Serveur principal et Serveur secondaire avec les noms de vos serveurs. Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").
Accès en NFS
Dans l'interface, Créer un stockage NFS, remplissez le champ Serveur avec "localhost". Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").
Benchmark librairie glusterfs / NFS
La différence est notable. En fonctionnement en HA, proxmox est capable de migrer une machine, lorsqu'il perd un noeud du cluster, sur un second. Ceci est vrai seulement avec la librairie NFS. De notre expérience, non seulement les machines ne sont pas migrées, mais les disques virtuels sont parfois endommagés !
Quorum
Le Quorum est une partition partagée, à partir d'une troisième machine, qui permet d'utiliser la HA. Cette machine sert en fait de référent aux Proxmox, qui ont parfois du mal à déterminer s'il y a une panne ou non dans un configuration avec uniquement 2 noeuds Proxmox. On ajoute donc de la stabilité et une couche de sécurité pour les VMs/données.
Cette troisième machine sera ici une CentOS 6.5.
iSCSI
iSCSI est choisi pour partager la partition entre les différents noeuds du cluster.
Pour commencer, créer la partition. (Réduire une autre si cela est nécessaire, en théorie QDisk n'utilise qu'une partition de 10Mo)
lvcreate -n quorumdisk -L 10M vg_QUORUM
Installer le serveur iSCSI :
yum -y install scsi-target-utils # (nom du paquet sous CentOS)
Important ! : le port 3260 doit être ouvert pour permettre les connexions à la cible iSCSI.
Créer ensuite la cible iSCSI (Des conventions de nommage ont été mises en place. Il est recommandé de les utiliser : http://en.wikipedia.org/wiki/ISCSI#Addressing)
# vim /etc/tgt/targets.conf <target iqn.2012-06.com.domain.hostname:server.p1qdisk> backing-store /dev/vg_QUORUM/quorumdisk initiator-address <IP_du_noeud_1> initiator-address <IP_du_noeud_2> </target>
Démarrer ensuite le service tgt, et le paramétrer pour le démarrage automatique :
service tgtd start chkconfig tgtd on tgt-admin -s #notre volume doit apparaître ici
Il faut maintenant monter la cible sur les Proxmox. Installer tgt (il installe open-iscsi en dépendance sur le client, c'est lui dont on a besoin) :
apt-get install tgt # (nom du paquet sous Debian / Proxmox).
Modifier ensuite le fichier /etc/iscsi/iscsid.conf. Le champ node.startup doit être configuré en automatic
#vim /etc/iscsi/iscsid.conf ... #***************** # Startup settings #***************** # To request that the iscsi initd scripts startup a session set to "automatic". # node.startup = automatic # # To manually startup the session set to "manual". The default is manual. node.startup = automatic ...
Redémarrer le client iscsi :
service open-iscsi restart
On peut maintenant tester quelles cibles les clients voient :
iscsiadm --mode discovery --type sendtargets --portal <IP_du_ serveur iSCSI>
Puis se connecter à la cible qui nous interesse :
iscsiadm -m node -T iqn.BLAHBLAH -p <IP_du_serveur_iSCSI> -l
Configurer QDisk
Il faut identifier la partition qui correspond au volume logique précédemment créé. On crée ensuite une partition sur celui-ci, via fdisk (ici sdc1 mais peut varier suivant la configuration de votre système). Une fois ceci fait on peut créer le disque de Quorum :
mkqdisk -c /dev/sdc1 -l qdisk_proxmox #Noter que le paramètre -l est suivi du nom que vous souhaitez donner à votre disque de Quorum
Déconnecter et reconnecter les clients pour voir les changements :
iscsiadm --mode node --target <IQN> --portal x.x.x.x --logout iscsiadm --mode node --target <IQN> --portal x.x.x.x --login
Ajouter QDisk au cluster
Sur un des deux noeuds :
Copier le fichier cluster.conf en cluster.conf.new
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
Editer ce fichier en prenant soins de :
1) Incrémenter "config_version" de 1
2) Supprimer 2node="1"
3) Ajouter la définition du Quorum
Cela doit ressembler à peu près à ceci :
<cman expected_votes="3" keyfile="/var/lib/pve-cluster/corosync.authkey"/> <quorumd votes="1" allow_kill="0" interval="1" label="qdisk_proxmox" tko="10"/> <totem token="54000"/>
Activer les modifications : Sur l'interface Web de Proxmox, selectionner le datacenter (dans le menu de gauche) puis sélectionner l'onglet HA. On voit ici apparaître le fichier fraîchement modifié. cliquer sur Activate pour charger les modifications dans le cluster.
Lancer la commande pvecm s et vérifier que les deux noeuds on bien reçu les modifications du cluster.conf. Puis sur chacun des noeuds, un à la fois :
service rgmanager stop service cman reload
la dernière commande devrait reancer rgmanager, si non, relancez le manuellement.
Vérification On peut utiliser la commande clustat pour vérifier que le quorum est présent et connecté
#clustat Cluster Status for proxmox1 @ Mon Nov 24 16:46:23 2014 Member Status: Quorate Member Name ID Status ------ ---- ---- ------ proxmox1 1 Online, Local, rgmanager proxmox2 2 Online, rgmanager /dev/block/8:16 0 Online, Quorum Disk
Astuces et notes
Supprimer l'avertissement de souscription
Lorsqu'on utilise Proxmox 3 sans souscription, un message apparrait à chaque login sur l'interface web. Pour se débarrasser de ce message, il faut modifier le fichier pvemanagerlib.js. On commence par sauvegarder le fichier d'origine :
# cp /usr/share/pve-manager/ext4/pvemanagerlib.js /usr/share/pve-manager/ext4/pvemanagerlib.js.OLD
Puis on édite
# vim /usr/share/pve-manager/ext4/pvemanagerlib.js
Il faut chercher l'instruction IF de la forme suivante :
if (data.status !== 'Active') { Ext.Msg.show({ title: gettext('No valid subscription'), icon: Ext.Msg.WARNING, msg: PVE.Utils.noSubKeyHtml, buttons: Ext.Msg.OK,
En fait, Proxmox teste si on a un abonnement non actif, auquel cas, il affiche le message. Il nous suffit donc de remplacer le test par false
if (false) { Ext.Msg.show({ title: gettext('No valid subscription'), icon: Ext.Msg.WARNING, msg: PVE.Utils.noSubKeyHtml, buttons: Ext.Msg.OK,
Problèmes connus avec QDisk
Les noeuds Proxmox utilisent iSCSI pour se connecter au disque de Quorum partagé. Les machines proxmox, au démarrage, lancent une connexion à la cible iSCSI. Or, si la machine de Quorum n'est pas présente lors de cette étape, les connexion échouent logiquement. Les proxmox ne sont ensuite pas capables de se reconnecter automatiquement au disque de quorum, il faut soit les redémarrer, soit connecter la cible manuellement, en ligne de commande. Bien que ce soit un scénario plus rare, il est toujours bon de savoir quoi faire.