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

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

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.

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