Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:proxmox [2019/07/14 21:03] – [Procédures] Conf VMs gilou
+++ projets:proxmox [2022/06/11 13:23] (Version actuelle) – [Procédures] jca
@@ Ligne 1: / Ligne 1: @@
-====== Évolution virtualisation: stockage/serveurs ======
+====== Virtualisation avec Proxmox ======
 {{ :projets:faimaisonvirtu.png?400 |}}
+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/
-Le besoin / Les enjeux:
+La solution de sauvegarde de PROXMOX est détaillé [[projets:proxmox:backup|ici]]
 ----
-__**É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
 ==== Solution logicielle ====
@@ Ligne 21: / Ligne 13: @@
 [[https://www.proxmox.com/en/proxmox-ve|PROXMOX]]
-Le besoin: faire évoluer la solution de virtualisation. \\
+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.
-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 [[https://gordon.re/sysadmin/installation-de-proxmox-chiffree.html|LUKS pour le système]]
-  * Un volume en RAID5 hébergé sur la baie de stockage propre à l'hyperviseur [[projets:proxmox:stockagevirtu|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
 ===== Matériel =====
-Avec le nouveau matériel donné, FAImaison va pouvoir héberger des machines virtuelles pour ses adhérents.
+Nous disposons pour cette plate-forme des machines suivantes :
-Le matériel est:
+  * Une baie de stockage IBM V7000 (420W/tiroir)
-  * 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
+    * 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
+    * 24 x disques de 300GB à 10KTPM
-  * 3 x extensions de disques disponibles (24 emplacements par extensions)
+    * 3 x extensions de disques disponibles (24 emplacements par extensions)
-  * 32 x disques disponibles de 300GB
+    * 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
+  * 3 hyperviseurs (skumenn, gueuza, kurun) HPe DL360G7(120W) avec :
-  * 1 x de disponible HPe DL360G7(120W) avec 2 CPU E5645 / 6 CORE @ 2.40GHz et 24 Go de RAM + 1 disque 73GB
+    * 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
-==== stockage ====
+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 V7000:
+==== Stockage ====
+Utilisation de la baie de stockage IBM V3700:
   * 1 tiroir de 2U
-  * 24 disques de 300GB soit 5,7To brutes
+  * 24 disques de 900GB soit 21To brutes
-  * 2 x 4FC 8Gb/s + 2 x 2ETH 1Gb/s / connexion FC et/ou iSCSI
+  * 4 x 4FC 8Gb/s + 2 x 2ETH 1Gb/s / connexion FC et/ou iSCSI
-{{ :projets:cogent-nantes-virtu.png?400 |}}
+{{:projets:image_hyperviseurs_baie.png?nolink&400|}}
 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 :
+  * 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
-  * 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
-==== serveurs ====
-  * 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/
 ----
+===== Création de 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 cas de panne :
+==== VM (machine virtuelle, qemu) ou CT (container, lxc) ====
-- cas : Défaillance de la baie de stockage
-  - effet : arrêt immédiat de toutes les VM quel que soit l'hyperviseur
-  - correction temporaire : néant (= temps d'indispo pour les VM)
-  - correction : remplacement de la baie de stockage par une autre (?ON A UN SPARE OU IL FAUT RACHETER?)
-  - 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
-  - effet : néant dans l'immédiat (un problème se pose si plusieurs disques défaillent)
-  - correction : remplacer par un nouveau disque (?ON A DU SPARE OU IL FAUT RACHETER ?)
-  - probabilité : forte (les disque durs vivent et meurent)
-- cas : Défaillance d'un des hyperviseurs
-  - effet : arrêt de toutes les VM qu'il héberge
-  - correction temporaire : ?LES VM PEUVENT ÊTRE MIGRÉES SUR UN AUTRE HYPERVISEUR?
-  - correction : ?ON A DU SPARE OU IL FAUT RACHETER?
-  - probabilité : moyenne
-- cas : nécessité de redémarrer un des hyperviseurs (ex: mise à jour logicielle ou matérielle)
-  - effet : demande l'arrêt gentiment des VMs et containers, puis plus brutal
-  - correction temporaire : migrer les VMs sur un autre hyperviseur, redémarrer les containers sur un autre
-  - correction : attendre le redémarrage
-  - 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)
-  - effet : arrêt de toutes les VM
-  - correction temporaire : néant (= temps d'indispo pour les VM)
-  - correction : attendre le redémarrage
-  - 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/
-===== Procédures =====
-=== Création de 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.
-== VM (machine virtuelle, qemu) ou CT (container, lxc) ==
 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.
-== Identifiants des machines ==
+==== Identifiants des machines ====
 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
-== Stockage ==
+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.
+==== Stockage ====
 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
@@ Ligne 141: / Ligne 67: @@
   * 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é
-== Réseau ==
+==== Réseau ====
+=== Adressage ===
 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
+=== Sécurité et pare-feu hyperviseur ===
+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 !
+===== Procédures =====
 === Gestion clés LUKS hyperviseurs ===
@@ Ligne 172: / Ligne 112: @@
 Entrez la phrase secrète à effacer : <ANCIENNE_CLÉ>
 </code>
+=== Mises à jour ===
+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 !
 === Redémarrage planifié hyperviseur ===
     * 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)
@@ Ligne 200: / Ligne 148: @@
 /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
+root@skumenn:/home/gilou# cryptsetup luksOpen /dev/mapper/36005076802810cce880000000000002d vg_fma_luks
-Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002a : <passprase disque chhire local>
+Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002d : <passphrase dique chiffre partage>
-root@skumenn:/home/gilou# cryptsetup luksOpen /dev/mapper/36005076802810cce880000000000002d shared_crypt
-Saisissez la phrase secrète pour /dev/mapper/36005076802810cce880000000000002d : <passphrase dique chiffre partag>
 </code>
     * Validation retour de l'hyperviseur, migration retour éventuelle des VMs