Virtualisation avec Proxmox

Le but de la virtualisation est de s'abstraire du matériel pour pouvoir fournir des serveurs virtuels pour fournir les services de l'association, ou pour des adhérents qui en expriment le besoin.

L'accès à l'interface de gestion se fait ici : https://virtu.faimaison.net/

La solution de sauvegarde de PROXMOX est détaillé ici —-

PROXMOX

Le choix de Proxmox a été fait en considérant la nécessité de rendre accessible via une interface Web la plate-forme de virtualisation, tout en s'appuyant sur un produit libre, et bien maintenu.

Nous disposons pour cette plate-forme des machines suivantes :

• Une baie de stockage IBM V7000 (420W/tiroir)
  • de 2U avec 24 emplacements de disques 2,5 ports de connexions 2 x 4FC 8Gb/s + 2 x 2ETH 1Gb/s
  • 24 x disques de 300GB à 10KTPM
  • 3 x extensions de disques disponibles (24 emplacements par extensions)
  • 32 x disques disponibles de 300GB
• 3 hyperviseurs (skumenn, gueuza, kurun) HPe DL360G7(120W) avec :
  • 2 CPU E5645 / 6 CORE @ 2.40GHz
  • 64 Go de RAM
  • 2 disques 73GB en RAID1
  • 8 ports ETH 1Gb/s, 2 ports FC 8Gb/s
• 1 autre serveur disponible HPe DL360G7(120W) avec 2 CPU E5645 / 6 CORE @ 2.40GHz et 24 Go de RAM + 1 disque 73GB

Soit à disposition 72 CPUs, 172 Go de RAM, 4 To de stockage actif. En considérant qu'on veut pouvoir survenir à la panne d'un hyperviseur à tout moment, il faut considérer environ 2/3 des ressources comme le maximum. La RAM ne devrait pas être sur-allouée, idéalement, le stockage non plus. Le CPU selon le besoin peut l'être, mais il vaut mieux ne pas dépasser un rapport de 3 à 4x le nombre de cœurs alloués en vCPU, selon la charge des VMs.

Utilisation de la baie de stockage IBM V3700:

• 1 tiroir de 2U
• 24 disques de 900GB soit 21To brutes
• 4 x 4FC 8Gb/s + 2 x 2ETH 1Gb/s / connexion FC et/ou iSCSI

La baie a été découpée en :

• 1 LUN partagé entre les hyperviseurs de 10 To (lvm_noluks_shared) ne supportant pas les snapshots, mais du coup en HA
• 1 LUN partagé entre les hyperviseurs et chiffré de 2 To (lvm_luks_shared) ne supportant pas les snapshots, mais en HA
• 1 LUN pour chaque hyperviseur(à faire), de 300 Go (lvmthin_luks_local) qui n'est pas partagé (et donc, pas de HA) qui supporte :
  • provisionnement dynamique
  • snapshots containers/VMs

—-

Une configuration de base pour les VMs pourrait être : 1 Go de RAM, 20 Go de disque dur, 1 vCPU. L'infrastructure peut accueillir sereinement 100 VMs de ce type.

Les machines adhérents seront toujours des VMs, celles de l'asso peuvent être des containers ou des VMs selon leurs besoins. Les containers ne peuvent pas être migrés à chaud, et sont parfois limités pour les accès à certaines fonctionnalités du noyau, mais ils ont l'avantage d'être particulièrement légers pour les hyperviseurs.

De manière à identifier clairement les machines de Faimaison, et celles des adhérents, les identifiants des machines seront :

• De 1000 à 1999 pour les VMs FMA
• De 2000 à 2999 pour les VMs adhérents

En plus de l'identifiant, les machines ont un nom, qui est utilisé comme hostname pour les containers. Pour les VMs adhérents, on utilisera la référence en interne (REF-VM-XX), pour les VM/CTs FMA, le nom de la machine tel qu'utilisé dans l'inventaire ansible.

Le stockage dépendra du besoin en terme de chiffrement, on peut recommander :

• partagé, chiffré (lvm_luks_shared) pour les VMs de l'asso, pour ne pas gérer le chiffrement dans la VM
• partagé, non chiffré (lvm_noluks_shared) pour les VMs adhérents souhaitant de la haute disponibilité et chiffrer eux-mêmes leur machine virtuelle
• non-partagé, chiffré (lvmthin_luks_local) pour ceux qui veulent bénéficier de la possibilité de faire des snapshots, mais pas de la HA, en chiffrant ou non leur VMs de leur côté

Les VMs adhérents seront rattachées au pont vmbr3. Les IPs seront conformes au plan d'adressage, dans 89.234.177.128/26

Les VMs et containers FMA seront rattachées au pont vmbr2. Les IPs seront conformes au plan d'adressage, dans 89.234.177.192/27

Les machines se partagent selon leur segment un sous-réseau, et ne sont pas complètement isolées comme dans la précédente infrastructure (notamment car il n'est pas simple d'obtenir une annonce simple des routes avec Proxmox, même si ça n'est pas impossible, peut-être avec OpenVSwitch ou avec le support de VXLAN dans Proxmox 6…).

Il est donc primordial de sécuriser les machines et containers en utilisant le pare-feu de Proxmox.

• Renseigner l'IP de la VM (pas nécessaire pour les containers) en cliquant sur la VM, puis Firewall → IPSet → Create, Name : ipfilter-net0, Save. Ensuite, « Add » à droite, IP/CIDR : l'IP voulue, et OK !
• dans Firewall → Options : passer Firewall, MAC Filter, IP Filter à Yes et DHCP et Router Advertisement à No
• Au moins pour les machines adhérentes, passez Input Policy à ACCEPT

Normalement, c'est bon !

Chaque hyperviseur a donc :

• une partition racine chiffrée (accueillant le vg pve), déverouillée via dropbear
• un LUN spécifique chiffré
• le LUN partagé entre tous les hyperviseurs, chiffré

Les clés sont stockés dans keyringer, trousseau noyau.

Rotation de clé :

• Ajout de la nouvelle clé

cryptsetup luksAddKey /dev/sda5
Entrez une phrase secrète existante : <ANCIENNE_CLÉ>
Entrez une nouvelle phrase secrète pour l'emplacement de clé :  <NOUVELLE_CLÉ>
Vérifiez la phrase secrète : <NOUVELLE_CLÉ>
 

• Validation de la clé (reboot / dropbear / ou test direct :)

cryptsetup luksOpen --test-passphrase /dev/sda5 && echo "Passphrase OK"
Saisissez la phrase secrète pour /dev/sda5 : <NOUVELLE_CLÉ>
Passphrase OK

• Suppression de l'ancienne clé :

root@skumenn:/home/gilou# cryptsetup luksRemoveKey /dev/sda5
Entrez la phrase secrète à effacer : <ANCIENNE_CLÉ>

Les mises à jour se font via les outils apt Debian, mais les hyperviseurs ont été installé avec une partition /boot un peu petites. Il faut donc avant de lancer l'install vérifier qu'il reste environ 70 Mo dans /boot.

Pour les mises à jour majeures, il faut se référer aux instructions de Proxmox généralement listées ici : https://pve.proxmox.com/wiki/Downloads

Chaque redémarrage suit la procédure de redémarrage planifié ensuite !

• Migration de VMs et redémarrage des containers sur un autre hyperviseur : clic sur l'hyperviseur, bulk actions, bulk migrate (nécessite l'accès adminsys à Proxmox)
• Arrêt VM non migrables
• reboot (via l'interface, ou en SSH, nécessite alors d'être dans les root_users)
• attendre le reboot de la machine physique, peut prendre 2 à 5 minutes
• Connexion SSH dropbear pour déverrouiller le disque système (nécessite d'être dans les dropbear_fde_users et de connaître la clé de la racine via keyringer/machines) :

ssh root@10.10.10.24
To unlock root partition, and maybe others like swap, run `cryptroot-unlock`


BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # cryptroot-unlock 
Please unlock disk sda5_crypt: 
cryptsetup: sda5_crypt set up successfully

• Connexion SSH hyperviseur pour déverrouillage disques réseaux (nécessite d'être root_users et la connaissance des clés dans keyringer/machines) :

# blkid | grep LUKS
/dev/sda5: UUID="43b0c19b-977b-4fc7-838a-c38494a7681c" TYPE="crypto_LUKS" PARTUUID="46a561e0-05"
/dev/sdb: UUID="b93272fd-e26f-407f-aa3b-a85c388e89ab" TYPE="crypto_LUKS"
/dev/sdd: UUID="0c5a3449-73bd-4e2b-a00f-d807b1bb74ad" TYPE="crypto_LUKS"
/dev/sde: UUID="b93272fd-e26f-407f-aa3b-a85c388e89ab" TYPE="crypto_LUKS"
/dev/sdg: UUID="0c5a3449-73bd-4e2b-a00f-d807b1bb74ad" TYPE="crypto_LUKS"
/dev/mapper/36005076802810cce880000000000002d: UUID="0c5a3449-73bd-4e2b-a00f-d807b1bb74ad" TYPE="crypto_LUKS"

root@skumenn:/home/gilou# cryptsetup luksOpen /dev/mapper/36005076802810cce880000000000002d vg_fma_luks
Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002d : <passphrase dique chiffre partage>

• Validation retour de l'hyperviseur, migration retour éventuelle des VMs