Updated Proxmox (markdown)

-

-## Architecture à Brest I11

-

-À Brest, le groupe principal est composé de 3 hyperviseurs ([Camille](/Serveurs/Camille), [Nikita](/Serveurs/Nikita) et [Proxima](/Serveurs/Proxima)) qui partagent tous un même espace de stockage sur le [SAN](/Services/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`

-* 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](https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html).

-

-[Alternative au LACP iSCSI Multipath](https://pve.proxmox.com/wiki/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](https://git.resel.fr/confs/cisco) 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 :

-* https://github.com/proxmox/lvm/blob/master/patchdir/fix-clvm-init.patch

-* http://forum.proxmox.com/threads/5207-shared-storage-LVM2-or-CLVM

-* http://forum.proxmox.com/threads/14703-When-is-CLVM-needed

-* http://forum.proxmox.com/threads/7225-cLVM

-* http://serverfault.com/questions/444043/does-proxmox-ve-support-lvm-as-block-storage-for-kvm-guests

-* http://forum.proxmox.com/threads/12798-Proxmox-VE-2-2-and-clvm

-* http://pve.proxmox.com/wiki/Proxmox_ISCSI_installation + pas de clvm mais resynchro des metas

-

-

-### 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` :

-```bash

-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 :

-```bash

-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 :

-```bash

- 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 :

-```bash

-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):

-* http://blogs.technet.com/b/windowsinternals/archive/2009/03/30/le-quorum-et-le-cluster.aspx

-* http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_perform_a_failover.html#_quorum_and_two_node_clusters

-* http://techthoughts.typepad.com/managing_computers/2007/10/split-brain-quo.html

-* http://linux-ha.org/wiki/Cluster_Concepts

-* http://blogs.msdn.com/b/clustering/archive/2011/05/27/10169261.aspx

-* https://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster#Two_nodes_cluster_and_quorum_issues

-* https://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster

-* http://serverfault.com/questions/371067/how-to-setup-stonith-in-a-2-node-active-passive-linux-ha-pacemaker-cluster

-

-