Skip to content

GitLab

Last edited by Baptiste Jonglez
Page history

Hyperviseur Proxmox

But de la page

Cette page recense les étapes de mise en place d'un cluster Proxmox pour Grésille.

Pour l'administration au jour le jour, voir Administration Proxmox.

Mise en place des certificats LetsEncrypt pour l'interface web de Proxmox

Les certificats sont gérés avec Certbot, ceux-ci sont créé avec la commande :

certbot certonly --cert-name proxmox.gresille.org -d proxmox.gresille.org

Cette commande, avec l'option certonly, va juste créer les certificats dans le dossier /etc/letsencrypt/live/proxmox.gresille.org.

Il est nécessaire ensuite de placer ceux-ci dans le dossier de l'interface PVE de Proxmox, ce qui rapidement fait avec les commandes

cp /etc/letsencrypt/live/proxmox.gresille.org/fullchain.pem /etc/pve/nodes/proxmox/pve-ssl.pem
cp /etc/letsencrypt/live/proxmox.gresille.org/privkey.pem /etc/pve/nodes/proxmox/pve-ssl.key

Enfin il faut redémarrer PVE Proxmox pour que celui-ci charge les nouveaux certificats :

service pveproxy restart

Ensuite ces certificats doivent être renouvelés quand ceux-ci arrivent à expiration. Certbot, ayant été installé via le paquet des dépôts Debian, est configuré pour les renouveler automatiquement (plus d'infos sur les renouvellement ici). Il est nécessaire d'ajouter quelques commandes à executer avant les tentatives de renouvellement (par exemple arréter un service qui pourrait géner la tentative) ou après (ici, on veut pouvoir placer les nouveaux certificats au bon endroit et redémarer pveproxy).

Les commandes peuvent être placées dans les sous-dossiers pre (commandes avant la tentative de renouvellement), post (commandes après la tentative de renouvellement), deploys (commandes après une tentative réussie de renouvellement) du dossier /etc/letsencrypt/renewal-hooks/. Dans notre cas nous allons ajouter un script à exécuter après un renouvellement réussi :

#! /bin/sh
#
cp /etc/letsencrypt/live/proxmox.gresille.org/fullchain.pem /etc/pve/nodes/proxmox/pve-ssl.pem
cp /etc/letsencrypt/live/proxmox.gresille.org/privkey.pem /etc/pve/nodes/proxmox/pve-ssl.key
service pveproxy restart

Il ne faut pas oublier de rendre executable le script avec la commande :

chmod a+x /chemin/vers/script

Enfin on peut tester la validité de notre configuration en executant un renouvelement test pour voir si tout fonctionne :

certbot renew --dry-run

Lors de cette tentative, l'execution (du moins, la non-exécution) des scripts de pré-post-deploy doit apparaître en rouge.

Et c'est tout...

Clustering

La mise en "cluster" permet aux hyperviseurs de communiquer entre eux et de migrer des VM d'un serveur à l'autre. Une fois le cluster activé, les hyperviseurs synchronisent leur configuration : utilisateurs, liste des VM... L'exception est le stockage puisque c'est une notion locale (mais certaines opérations comme la réplication demandent que le nom des pools de stoackage soient cohérent).

On peut se connecter indifféremment sur n'importe quel machine du cluster pour administrer l'ensemble des machines.

Mise en place d'un réseau dédié

Il est très fortement conseillé de mettre en place un réseau dédié entre les serveurs. Il sera utilisé pour le traffic de "contrôle" (corosync pour la détection de panne, SSH) et également pour la migration de VM. Si vous avez des SSD ou disques rapides, il est conseillé que ce réseau soit en 10 Gbit/s, mais pour des besoins basiques un réseau 1 Gbit/s peut suffir.

Configurer ce réseau en IP statique avec la conf Debian standard (/etc/network/interfaces).

Activation du clustering

La documentation officielle est plutôt claire : https://pve.proxmox.com/wiki/Cluster_Manager

Bien choisir la bonne interface réseau (réseau dédié).

Attention : il faut que les hyperviseurs "secondaires" qui rejoignent le cluster n'aient aucune VM.

Une fois le cluster formé, il ne semble y avoir aucune différence entre la machine qui a créé le cluster et celles qui ont rejoint le cluster : elles ont toutes le même rôle à la fin.

Gestion des comptes proxmox

TODO: pour l'instant, les comptes utilisateurs sont créés manuellement (en mode PVE), mais il faudrait automatiser / relier ça à une base utilisateur genre Epeire.

Droits d'accès

Chaque utilisateur a accès à sa machine virtuelle sur l'interface web de Proxmox. Il peut accéder à la console (VNC / série), rebooter sa machine, mettre un CD virtuel...

Comment ça marche ?

Référence : la doc officielle (en anglais)

Proxmox propose tout un tas de privilèges (Privileges), pour que chaque action dans l'interface soit contrôlable. Elle propose un ensemble de rôles (Roles) prédéfinis, qui ont chacun un ensemble de privilèges pour un usage spécifique. Par exemple :

  • Administrator : le super-utilisateur, qui a tous les droits ;
  • PVEUserAdmin : il peut gérer les utilisateurs et groupes ;
  • PVEVMAdmin : il a tous les droits sur une (ou plusieurs) machines virtuelles ;
  • PVEVMUser : il peut voir tous les paramètres d'une VM, la sauvegarder, accéder à la console pour la redémarrer et booter sur un CD ;
  • GresilleUser : même chose que PVEVMUser, et peut gérer
  • etc.

Le rôle GresilleUser sera le rôle de base des utilisateurs, car il permet l'utilisation courante d'une machine virtuelle sans risque d'erreur. On peut envisager ajouter des droits pour les utilisateurs avancés, ou même de réévaluer les droits pour tous.

Mais ces rôles doivent ensuite être associés à un objet (Object), un stockage (Storage) ou un pool de ressources (Pool). Le rôle GresilleUser n'a de sens qu'une fois associé à une (ou plusieurs) VM. Les droits spécifiques à la gestion des disques se font sur les stockages. Les pools ne sont actuellement pas utilisés chez Grésille.

Exemple pratique

Nous allons créer un utilisateur lambda, qui aura juste les droits GresilleUser sur sa machine virtuelle.

Dans la vue Server View, aller sur Datacenter dans le panneau de gauche, puis sélectionner Permissions > Users. Remplir le username avec le login souhaité, Realm à "Proxmox VE Authentication server", un mot de passe (qui pourra devra être changé), le mettre dans le groupe "users", et vérfier que la case Enabled est cochée. Idéalement, prendre une adresse mail ou autre moyen de contact.

On peut ensuite lui créer une machine virtuelle (bouton "Create VM" en haut à droite), en remplissant les différents éléments (TODO: faire une doc pour la création des VM, surtout sur l'aspect réseau).

Enfin, dans le panneau de gauche, chercher la nouvelle machine. Aller dans ses permissions, et ajouter notre nouvel utilisateur en User, et lui mettre le rôle de GresilleUser. Si l'utilisateur est déjà connecté, il devra se reconnecter pour que les permissions soient bien relues, et qu'il récupère bien tous les droits.

Configuration réseau

Principe

On aimerait isoler le réseau des VM entre elles, comme pour les machines physiques. Voir Fonctionnement du réseau pour le contexte.

Plusieurs pistes :

  • soit un VLAN par VM qui remonte jusqu'au routeur principal. Ça peut faire beaucoup de VLAN mais au moins c'est uniformisé : ça marche pareil pour les machines physiques et virtuelles
  • soit un VLAN unique qui remonte au routeur principal pour toutes les VM, mais on isole les VM entre elles (isolation des ports clients d'un bridge possible sous Linux ? un peu comme private VLAN)
  • soit un bridge séparé par VM, et l'hyperviseur sert de routeur/gateway pour les VM. On peut faire du BGP entre le routeur principal et les hyperviseurs, à la tetaneutral.

On est parti sur la solution 1, la plus uniforme.

Configuration avec un bridge unique et des VLAN

On décide de mettre un seul bridge vmbr0, bridgé avec l'interface physique de la machine physique, pour des questions de simplicité (cf paragraphe suivant)

Ensuite, à la création de la VM, on l'associe à ce bridge unique mais on spécifie un tag VLAN dans la configuration réseau.

Il faut évidemment que le port du switch connecté à l'hyperviseur soit en mode "trunk" pour autoriser les paquets avec un tag VLAN.

Pour info : configuration avec un bridge par VM

Sur la machine physique, pour chaque VM, créer un bridge vmbrXXX bridgé avec une interface virtuelle eno1.XXX. Dans /etc/network/interfaces:

auto vmbrXXX
iface vmbrXX inet manual
	bridge-ports eno1.XXX
	bridge-stp off
	bridge-fd 0

Lors de la création de la VM, l'associer au bridge vmbrXXX correspondant à son numéro de VLAN.

Problème de cette méthode : il faut créer tous les bridges sur toutes les proxmox du cluster pour pouvoir migrer les VM entre les différents proxmox. C'est donc pénible.

Configuration du stockage

Architecture

On stocke les disques des VM sur du ZFS local à chaque hyperviseur. On construit deux pools ZFS sur chaque hyperviseur selon le type de disques :

  • zpool-ssd : SSD
  • zpool-hdd : disque dur mécanique

Autant que possible, les pools sont construits sur des paires de disque en mode "miroir" (équivalent de RAID-1).

Le stockage est uniquement local, mais on peut configurer de la réplication des disques de VM à intervalle régulier. C'est efficace puisque ZFS n'envoie que les données qui ont été modifiées. Il y a deux avantages à la réplication :

  • si on veut migrer une VM d'un hyperviseur à l'autre, c'est beaucoup plus rapide parce qu'il y a juste à resynchroniser la copie pré-répliquée
  • en cas de grosse panne, on a une copie à peu près à jour des données sur un autre hyperviseur. Il est alors possible de relancer manuellement les VMs sur l'autre hyperviseur : https://pve.proxmox.com/wiki/Storage_Replication#_error_handling

Configuration lors de l'installation d'un hyperviseur

Pour que la réplication fonctionne, il faut absolument que les pools ZFS aient le même nom sur tous les hyperviseurs. L'interface web proxmox n'est pas très intuitive, elle empêche cela par défaut (voir https://forum.proxmox.com/threads/replication-not-possible-cluster-zfs.56257/)

Création du pool ZFS :

  • S'assurer qu'il y a bien des disques dédiés à ZFS dans la machine
  • Aller sur la machine / ZFS. Choisir "miroir" si il y a deux disques, sinon "Single disk".
  • Décocher la case "Add Storage" (sauf si c'est la première fois qu'on crée le pool au sein du cluster).
  • Aller sur Datacenter / Storage. Editer le pool, et ajouter le nouvel hyperviseur dans "Nodes"

Configuration du stockage local pour ne pas y stocker de disque de VM :

  • Dans Datacenter / Storage, éditer le pool "local", et désactiver "Disk image" dans "Content"

Réplication

Le but est de répliquer le disque d'une VM à intervalle régulier vers un autre hyperviseur. Cela permet des migrations beaucoup plus rapides.

  • aller sur la VM, menu "Replication"
  • ajouter une entrée, choisir l'hyperviseur de destination
  • on ne peut pas choisir le pool de destination : ce sera celui du même nom que le pool de départ
  • limiter le débit à 20 MB/s pour éviter de surcharger le réseau

Tuning

Si on est un peu short en mémoire sur les hyperviseurs, penser à baisser la taille du cache ZFS. Il faut rebooter pour que ce changement s'applique.

Gestion des machines virtuelles

Voir Administration Proxmox.