Le besoin / Les enjeux:

Étape à ce jour:

• Principe d'utilisation de PROXMOX
• Maquette à réaliser
• recette ansible à pousser, cf https://git.faimaison.net/faimaison-adminsys/adminsys/tree/gilou/proxmox
• Atelier à réaliser
• Documentation à faire

PROXMOX

Le besoin: faire évoluer la solution de virtualisation.
La demande: tant faire se peut le chiffrement des disques.

Mise à jour: juillet 2019 :

• La solution CEPH est pour l'instant trop complexe à mettre en place mais surtout à administrer
• Pour être conforme à la volonté de protéger les données: mots clés: proxmox Encryption / luks
• Mise en place d'un PROXMOX avec:
• /boot en clair
• le reste avec LUKS pour le système
• Un volume en RAID5 hébergé sur la baie de stockage propre à l'hyperviseur ici disponible en LVM provisionement dynamique : lvmthin_luks_local
• Un volume en RAID5 hébergé sur la baie de stockage partagé entre tous les hyperviseurs, chiffré : lvm_luks_shared
• Un volume en RAID5 hébergé sur la baie de stockage partagé entre tous les hyperviseurs, non chiffré : lvm_noluks_shared
• Les VM peuvent être en plus chiffrés via le même mécanisme: /boot en clair et le reste en LUKS

Avec le nouveau matériel donné, FAImaison va pouvoir héberger des machines virtuelles pour ses adhérents. Le matériel est:

• 1 x IBM V7000 (420W/tiroir) de 2U et 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 x HPe DL360G7(120W) avec 2 CPU E5645 / 6 CORE @ 2.40GHz et 64 Go de RAM + 2 disques 73GB en RAID1, 8 ports ETH 1Gb/s, 2 ports FC 8Gb/s
• 1 x de disponible HPe DL360G7(120W) avec 2 CPU E5645 / 6 CORE @ 2.40GHz et 24 Go de RAM + 1 disque 73GB

Utilisation de la baie de stockage IBM V7000:

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

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

• 1 LUNs pour chaque hyperviseur, de 300 Go (lvmthin_luks_local) qui n'est pas partagé (et donc, pas de HA) qui supporte :
  • provisionnement dynamique
  • snapshots containers/VMs
• 1 LUN partagé entre les hyperviseurs de 2 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

• 3 x HPe DL360G7(120W) avec
• 2 CPU E5645 / 6 CORE @ 2.40GHz et
• 64 Go de RAM +
• 2 disques 73GB en RAID1, 2 emplacements de disponible
• 4 ports ETH 1Gb/s + 1 carte PCIe avec 4 ports ETH 1Gb/s,
• 2 ports FC 8Gb/s (une carte PCIe)

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.

Installer les packages manquants

root@:~# apt-get install sudo

Installer le multipathing

root@:~# apt-get install multipath-tools

DNS

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_time_synchronization

tonio@proxmox3:~$ more /etc/systemd/timesyncd.conf #FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org FallbackNTP=fr.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Backup /etc/pve https://angristan.fr/la-mesaventure-proxmox/

Les cas de panne :

- cas : Défaillance de la baie de stockage

1. effet : arrêt immédiat de toutes les VM quel que soit l'hyperviseur
2. correction temporaire : néant (= temps d'indispo pour les VM)
3. correction : remplacement de la baie de stockage par une autre (?ON A UN SPARE OU IL FAUT RACHETER?)
4. probabilité : faible (source: expérience de Tonio, qui travaille avec ce matos fréquemment et n'a *jamais* vu une panne matérielle)

- cas : Défaillance d'un disque de la baie de stockage

1. effet : néant dans l'immédiat (un problème se pose si plusieurs disques défaillent)
2. correction : remplacer par un nouveau disque (?ON A DU SPARE OU IL FAUT RACHETER ?)
3. probabilité : forte (les disque durs vivent et meurent)

- cas : Défaillance d'un des hyperviseurs

1. effet : arrêt de toutes les VM qu'il héberge
2. correction temporaire : ?LES VM PEUVENT ÊTRE MIGRÉES SUR UN AUTRE HYPERVISEUR?
3. correction : ?ON A DU SPARE OU IL FAUT RACHETER?
4. probabilité : moyenne

- cas : nécessité de redémarrer un des hyperviseurs (ex: mise à jour logicielle ou matérielle)

1. effet : demande l'arrêt gentiment des VMs et containers, puis plus brutal
2. correction temporaire : migrer les VMs sur un autre hyperviseur, redémarrer les containers sur un autre
3. correction : attendre le redémarrage
4. probabilité : forte (un système Debian, ça se maintient à jour, et des fois, il faut redémarrer pour appliquer les mises à jour)

- cas : nécessité de redémarrer la baie de stockage (ex: mise à jour logicielle ou matérielle)

1. effet : arrêt de toutes les VM
2. correction temporaire : néant (= temps d'indispo pour les VM)
3. correction : attendre le redémarrage
4. probabilité : moyenne (?ÇA NÉCESSITE PARFOIS DES MISES À JOUR AVEC REBOOT NON?)

Config relais SSH iLO : ssh fresk.faimaison.net -L 8443:10.10.10.34:443 -L 17990:10.10.10.34:17990 Accès via https://localhost:8443/

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

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

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

• 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/36005076802810cce880000000000002a: UUID="b93272fd-e26f-407f-aa3b-a85c388e89ab" TYPE="crypto_LUKS"
/dev/mapper/36005076802810cce880000000000002d: UUID="0c5a3449-73bd-4e2b-a00f-d807b1bb74ad" TYPE="crypto_LUKS"

root@skumenn:/home/gilou# cryptsetup luksOpen /dev/mapper/36005076802810cce880000000000002a local_crypt_san
Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002a : <passprase disque chhire local>
root@skumenn:/home/gilou# cryptsetup luksOpen /dev/mapper/36005076802810cce880000000000002d shared_crypt
Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002d : <passphrase dique chiffre partag>

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