L'hypervision au ResEl

Le ResEl à ce jour repose principalement sur des machines virtuelles, quasiment tous les serveurs et services sont virtualisés. L'hypervision permet de gérer facilement les machines sans avoir de conflit entre les différents services.

Pour le moment toute la stack d'hypervision est gérée par Proxmox qui permet d'administrer facilement les serveurs et propose tout ce dont on a besoin haute disponibilité, stockage sur le SAN en iSCSI.

Le ResEl possède actuellement 3 groupes d'hyperviseurs, 1 au I11 à Brest qui est l'hyperviseur principal, 1 au I1 à Brest qui est de secours et 1 à Rennes pour les services rennais.

Attention : Même si toutes les informations ici ne sont pas forcément importantes pour la tâche que vous allez exécuter, il est important de tout lire et d'aller voir vers les liens donnés avant d'entreprendre la moindre action sur les hyperviseurs. Trop souvent cette année (2016) nous nous sommes retrouvés avec des problèmes car la compréhension des hyperviseurs était limitée.

Architecture à Brest I11

À 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 (Sanizator). 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

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)

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.

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

Configuration Réseau

TODO: https://redmine.resel.fr/projects/proxmox/wiki/MiseEnPlace#R%C3%A9seau

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

Informations générales sur Proxmox

Dépendant de l'hyperviseur, vous pouvez vous connecter sur les 3 interfaces web de Proxmox :

Intégration du LDAP

L'intégration du LDAP à proxmox est aujourd'hui minimale, il faut quand même ajouter les personnes au groupe administrators pour qu'ils puissent faire des choses utiles sur Proxmox. Celui-ci ne fait que la vérification du mot de passe. C'est un bug connu.

Configuration du LDAP :

Realm Base DN UID Attribute Default Server SSL Comment (nom au login)
admin.resel.fr ou=admins,dc=resel,dc=enst-bretagne,dc=fr uid oui ldap.adm.resel.fr non (TODO!) LDAP Admin
resel.fr ou=people,dc=maisel,dc=enst-bretagne,dc=fr uid non ldap.adm.resel.fr non (TODO!) LDAP Utilisateur

Voir : http://wiki.ucc.asn.au/Proxmox#Info_for_Administrators

Outils de ligne de commande utiles :

  • pve*
  • *_tools
  • clustat
  • clusvcadm

Configuration diverses

La plus part des services du ResEl (backuppc, ntp, syslog, icinga, dns se configurent comme sur toutes les autres machines au ResEl. Je vous recommande d'aller voir pour ceci le guide d'installation d'un serveur

Configuration DNS

Pour éviter que le cluster tombe en cas de problème DNS il est recommandé d'ajouter les entrées statiques du cluster sur les noeuds. Modfifier le fichier /etc/host/ et mettre les entrées suivantes : 

# Cluster
172.22.5.10 camille camille.sto
172.22.5.11 nikita nikita.sto
172.22.5.13 proxima proxima.sto

172.22.5.5 sanizator sanizator.sto

Configuration SSH

Il faut créer des comptes utilisateurs dédiés pour les administrateurs de l'hyperviseur (pas besoin de compte pour gérer simplement proxmox). Les droits root sont donnés par sudo (à installer). Attention cependant, les noeuds échangent entre eux en SSH (à priori avec le compte root), il faut faire attention à ne pas les bloquer en autorisant qu'un certain groupe à se connecter ou en refusant complètement une connexion root. L'option sshd PermitRootLogin without-password devrait fonctionner.

Ressources utiles

TODO (rédacteur)

  • détailler un peu plus sur le CLVM