Voir la source de 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 <nowiki>https://<IP du serveur>:8006</nowiki>

= 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 : <br/>
(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 : <br/>
(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 :
<!--
 echo "deb http://ftp.us.debian.org/debian/ wheezy main contrib non-free" >> /etc/apt/sources.list
 echo "deb http://security.debian.org/ wheezy/updates main contrib non-free" >> /etc/apt/sources.list
 aptitude update
 aptitude download multiarch-support
 aptitude download libssl1.0.0
 wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/5.0.3/glusterfs_3.3.0-1_amd64.deb
 
 dpkg -i multiarch-support_*_amd64.deb
 dpkg -i libssl1.0.0_*_amd64.deb
 dpkg -i glusterfs_3.3.0-1_amd64.deb

Commenter les lignes wheezy ajoutées pour éviter des problèmes de mises à jour par la suite
 sed -iE "s/\(.*wheezy.*\)/#\1/g" /etc/apt/sources.list
 aptitude update -->

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
<!-- service glusterd start
 update-rc.d glusterd defaults -->

'''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 : <br/>
1) Incrémenter "config_version" de 1 <br/>
2) Supprimer 2node="1" <br/>
3) Ajouter la définition du Quorum <br/>

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.