Architecture Proxmox du I11

-> Interface graphique

À Brest, le groupe principal est composé de 3 hyperviseurs (Camille, Nikita et Proxima) qui partagent tous un même espace de stockage sur le SAN. Cette architecture permet un load balancing de la charge et un fail over en cas de perte d'un noeud.

Architecture montée par Alexandre Levavasseur FIP 2016 en février-mars 2015, puis mise à jour en 2016.

Image de l'archi à ajouter. https://sandstorm.resel.fr/shared/W65mdEUXHx9quIuNaWQckm1eCOPNcrqBKOmjT5nZfT9

Configuration Réseau

La première chose à configurer, via l'interface graphique, c'est le réseau ( https://pve.proxmox.com/wiki/Open_vSwitch ).

  • désactiver vmbr0 (par défaut) en décochant l'autoboot, retirant la passerelle (sinon conflit dans les étapes suivantes), mettant eth0.997 au lieu de eth0 warning Il faut aller jusqu'au bout de la manœuvre sinon votre machine deviendra probablement inaccessible après reload du service networking. Il faut restaurer la conf par défaut/ faire les ajustements à la main
  • créer 2 OVS Bridge vmbr1 et vmbr2, aucune option
  • créer 2 OVS Bond bond1 (attention au nom !) prenant eth0 et eth1, puis bond2 prenant eth2 et eth3, les 2 en mode balance-tcp
  • Créer 2 OVS IntPort :
    • mgr portant l'adresse de management (reprendre les paramètres de l'install), dans le vlan 997
    • sto portant une adresse dans le vlan stockage, seuls adresse et masque sont renseignés

Un différentiel est disponible dans le cadre du bas. Lorsque vous avez bien tout configuré et vérifié, il faudra mettre en place les jumbo frames sur l'interface de stockage (possible avant le reboot de changement des interfaces en modifiant interfaces.new), en éditant `/etc/netwok/interfaces : 

iface sto inet static
[..]
        mtu 9000

iface bond2 inet manual
[..]
        pre-up ( ifconfig eth2 mtu 9000 && ifconfig eth3 mtu 9000 )
        mtu 9000

iface vmbr2 inet manual
[..]
        mtu 9000

Les hyperviseurs sont connectés aux switch sur le VLAN 5 qui sert uniquement pour le stockage à l'aide de 2 liens LACP Gi.
Le Port Channel configuré par interface sur Laetitia:

  • PC 5 : LACP SAN - Laetitia (eth2 : Gi0/35, eth3 : Gi0/34)
  • PC 10 : LACP SAN - Camille (eth2 : Gi0/32, eth3 : Gi0/33)
  • PC 11 : LACP SAN - Nikita (eth2 : Gi0/28, eth3 : Gi0/29)
  • PC 20 : LACP Core - Camillle (eth0 : Gi0/30, eth1 : Gi0/31)
  • PC 21 : LACP Core - Nikita (eth0 : Gi0/26, eth1 : Gi0/27)

Le LACP est un protocole permettant d'agréger des liens sur un même switch afin d'avoir une résistance en cas de chute de lien, mais également plus de débit. Documentation Cisco sur le LACP.

Alternative au LACP iSCSI Multipath

Il faut adapter la configuration des ports du switch en face ; un exemple :

Attention, cette documentation peut évoluer (car les confs des sw c'est facile à changer), n'hésitez pas à aller voir la configuration de Laetitia en cas de doute.

!
interface GigabitEthernet0/26
 description Nikita LACP CORE 1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 storm-control broadcast level pps 300 250
 storm-control action trap
 channel-protocol lacp
 channel-group 21 mode passive
!
interface GigabitEthernet0/27
 description Nikita LACP CORE 2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip access-group 101 in
 mls qos trust dscp
 snmp trap mac-notification change added
 snmp trap mac-notification change removed
 storm-control broadcast level pps 300 250
 storm-control action trap
 channel-protocol lacp
 channel-group 21 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
 ip dhcp snooping trust
!
interface GigabitEthernet0/28
 description Nikita LACP SAN 1
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 11 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
!
interface GigabitEthernet0/29
 description Nikita LACP SAN 2
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 11 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
!
interface GigabitEthernet0/30
 description Camille LACP CORE 1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip access-group 101 in
 mls qos trust dscp
 storm-control broadcast level pps 300 250
 storm-control action trap
 channel-protocol lacp
 channel-group 20 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
 ip dhcp snooping trust
!
interface GigabitEthernet0/31
 description Camille LACP CORE 2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip access-group 101 in
 mls qos trust dscp
 snmp trap mac-notification change added
 snmp trap mac-notification change removed
 storm-control broadcast level pps 300 250
 storm-control action trap
 channel-protocol lacp
 channel-group 20 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
 ip dhcp snooping trust
!
interface GigabitEthernet0/32
 description Camille LACP SAN 1
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 10 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
!
interface GigabitEthernet0/33
 description Camille LACP SAN 2
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 10 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
!
interface GigabitEthernet0/34
 description Sanizator LACP 2
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 5 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable
!
interface GigabitEthernet0/35
 description Sanizator LACP
 switchport access vlan 5
 storm-control broadcast level pps 200 5
 storm-control action trap
 channel-protocol lacp
 channel-group 5 mode passive
 spanning-tree portfast
 spanning-tree bpdufilter enable

Uniquement pour promox 3 : Enfin, pour la partie réseau, il reste un détail (à mettre en place au bon moment de l'installation mais décrit ici) : le passage dans un état réellement fonctionnel des interfaces tels que sw semble pouvoir mettre beaucoup de temps au boot, or entre l'initialisation du réseau et la tentative de formation du cluster il ne s'écoule que quelques secondes au plus, ce qui peut poser des problèmes (notamment, le problème a été diagnostiqué parce que le noeud tente de s'unfencer -> fail -> pas de join du domain de fence -> pas de rmanager). Il faut donc attendre que le réseau soit bien prêt avant de continuer, j'ai pour cela créé un petit script qui va vérifier que les adresses fournies (et choisie pour permettre de vérifier l'état de l'interface) sont bien opérationnelles avant de continuer : 

echo > /etc/network/if-up.d/z-boot-wait <<EOF
#!/usr/bin/env sh
#
# Script d'attente au boot par Alexandre Levavasseur, FIP16
# --
# Attend que les réseaux nécessaires, ici lien avec laetitia et avec le san, soient
# prêts avant de continuer le boot ; si délai > 5 minutes le script laisse quand
# même le système booter (pour éviter les erreurs humaines).

log() {
  echo "[boot-wait] $*" 
}

NEEDED="172.22.5.5 172.22.0.115" 
MAX_WAIT=300

t=0
if [ "$IFACE" = "--all" ] && [ "$PHASE" = "post-up" ]; then
  for addr in $NEEDED; do
    echo -n "[boot-wait] Waiting for $addr .. " 
    until [ $t -gt $MAX_WAIT ] || ping -c1 -W1 $addr > /dev/null; do
      t=$((t+1))
    done
    echo "exited at t=$t" 
  done

  if [ $t -gt $MAX_WAIT ]; then
    log "Failed, deadline expired" 
    exit 1
  else
    log "Ok :)" 
  fi
fi
EOF

puis

chmod +x /etc/network/if-up.d/z-boot-wait

Reverse proxy

Pour profiter du HA du pool, les trois hyperviseurs peuvent proposer l'interface graphique de proxmox. Ceux-ci sont situés derrière le reverse proxy situs en round robin. L'option ip_hash est très importante pour éviter de se connecter sur les 3 serveurs à tour de rôle, cela pose des problèmes lors de l'ouverture de la console qui va s'ouvrir sur un autre hyperviseur.

Voici la configuration (au 2017-01-29): 

upstream proxmox {
    ip_hash;
    server 172.22.2.42:8006; # Nikita
    server 172.22.2.58:8006; # Camille
    server 172.22.2.63:8006; # Proxima
}

server {
    listen 80;
    server_name proxmox.resel.fr;
    return  301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name proxmox.resel.fr;

    access_log /var/log/nginx/proxmox.resel.fr/access.log;
    error_log  /var/log/nginx/proxmox.resel.fr/errors.log;

    proxy_redirect off;
    location / {
        proxy_http_version 1.1;
        proxy_set_header        Upgrade $http_upgrade;
        proxy_set_header        Connection "upgrade";
        proxy_pass              https://proxmox;
    }
}

Stockage

Le stockage se fait sur le SAN Sanizator qui exporte des volumes en iSCSI (tcp).

Création des volumes

TODO

Configuration des volumes dans proxmox

La configuration dans proxmox 4 se fait depuis l'interface graphiques. On commence par ajouter les volumes iSCSI, l'ID sera le nom attribué, le portal l'adresse du SAN, la target la cible contenant les volumes voulus. Pas de restriction sur les noeuds.

ID Portal Target Direct*
SAN-VMs 172.22.5.5 iqn.2015-02.fr.resel:promox Non
VM-SAN-Clubs 172.22.5.5 iqn.2015-02.fr.resel:clubs Oui
VM-SAN-Miroir 172.22.5.5 iqn.2015-02.fr.resel:miroir Oui
VM-SAN-Reloaded 172.22.5.5 iqn.2017-01.fr.resel:proxmox-reloaded Non

Direct* indique que les volumes pourront être utilisés directement par les VMs. Pour le moment Proxmox ne protège pas ces accès direct contre les accès multiples ni dans le reste de l'interface Proxmox, il font donc savoir qu'ils ne doivent pas être utilisés. Ils sont préfixés par VM pour indiquer que leur usage est réservé aux VMs.

Ensuite, dans le LUN (volume) 1 de la target promox, crée les VG qui accueillent les VMs. Add>LVM :

ID Base Storage Base Volume Volume Group Shared
Disks-VMs SAN-VMs LUN00 vms Oui
Disks-ViM-Reloaded VM-SAN-Reloaded LUN01 vg-reloaded Oui

On peut vérifier la prise en compte avec la commande vgs : 

lcarr@camille:~$ sudo vgs
  VG          #PV #LV #SN Attr   VSize    VFree  
  clubs         1   1   0 wz--n- 1024.00g      0 
  miroir        1   4   0 wz--n-  900.00g  30.00g
  pve           1   3   0 wz--n-  136.00g  15.84g
  vg-reloaded   1  29   0 wz--n- 1024.00g 595.50g
  vms           1  44   0 wz--n- 1024.00g 500.50g

Informations sur le CLVM

Des liens en vrac en attendant plus de doc :

Mise en place de la HA

Explications

La haute disponibilité est la technologie permettant d'avoir un service constant malgré la chute de noeuds. Elle est enforcée ici par le fait qu'il y ait 3 noeuds en concurrence.

Quorum : Un quorum est le principe qui permet de vérifier l'état d'un service distribué à l'aide d'un vote. Chacun des noeuds du service possède un (ou plusieurs) votes et si le quorum est atteint (généralement la majorité) le noeud considère qu'il est dans une partition fonctionnelle. Si il le quorum n'est pas atteint, le noeud considère qu'il est isolé ou dysfonctionnel.

Fencing : Le fencing est le processus permettant d'isoler du système un noeud qui est dysfonctionnel.

Mise en cluster

Nous créons un cluster nommé lyoko-cluster : 

root@camille:~# pvecm create lyoko-cluster
Restarting pve cluster filesystem: pve-cluster[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'
.
Starting cluster:
   Checking if cluster has been disabled at boot... [  OK  ]
   Checking Network Manager... [  OK  ]
   Global setup... [  OK  ]
   Loading kernel modules... [  OK  ]
   Mounting configfs... [  OK  ]
   Starting cman... [  OK  ]
   Waiting for quorum... [  OK  ]
   Starting fenced... [  OK  ]
   Starting dlm_controld... [  OK  ]
   Tuning DLM kernel config... [  OK  ]
   Unfencing self... [  OK  ]

Ajout des noeuds au quorum : 

root@nikita:~# pvecm add 172.22.2.58  # Nikita
The authenticity of host '172.22.2.58 (172.22.2.58)' can't be established.
ECDSA key fingerprint is 0d:f2:dd:e1:bb:ae:e4:71:86:ad:ed:5e:02:78:cf:7c.
Are you sure you want to continue connecting (yes/no)? yes
root@172.22.2.58's password:
copy corosync auth key
stopping pve-cluster service
Stopping pve cluster filesystem: pve-cluster.
backup old database
Starting pve cluster filesystem : pve-cluster.
Starting cluster:
   Checking if cluster has been disabled at boot... [  OK  ]
   Checking Network Manager... [  OK  ]
   Global setup... [  OK  ]
   Loading kernel modules... [  OK  ]
   Mounting configfs... [  OK  ]
   Starting cman... [  OK  ]
   Waiting for quorum... [  OK  ]
   Starting fenced... [  OK  ]
   Starting dlm_controld... [  OK  ]
   Tuning DLM kernel config... [  OK  ]
   Unfencing self... [  OK  ]
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
Restarting PVE Daemon: pvedaemon.
Restarting PVE API Proxy Server: pveproxy.
successfully added node 'nikita' to cluster.


root@nikita:~# pvecm add 172.22.2.63  # Proxima

Pour voir l'état du cluster : 

 root@camille ~ # pvecm status     
Quorum information
------------------
Date:             Sun Jan 29 01:36:56 2017
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000002
Ring ID:          1/25104
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate 

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 172.22.2.42
0x00000002          1 172.22.2.58 (local)
0x00000004          1 172.22.2.63
zsh: exit 1     pvecm status

La liste des noeuds : 

root@camille ~ # pvecm nodes 

Membership information
----------------------
    Nodeid      Votes Name
         1          1 nikita
         2          1 camille (local)
         4          1 proxima

Liens (concernant la mise en quorum):