(https://pad.sans-nuage.fr/p/libreto+arn-infra+migration+proxmox) Migration vers proxmox 0. Repérage au datacenter et sur internet Déterminer si on peut avoir au moins un NVMe par serveur Compter le nombre de prise ethernet Voir si on peut ajouter de l'ethernet Gigabit au serveur 1. Décision sur l'agencement du stockage et achat des disques Nous avons actuellement 6To de VPS, 4To de disques dur (HDD) et 2To de disques SSD, il faut donc à minima 6To dans notre grappe de serveurs de destination (cluster). L'offre proposant une redondance sur un autre serveur, il serait logique que nous continuions à le proposer, il faut donc le même stockage sur un autre noeud du cluster. AU vu des capacités des SSD, il semble pertinent d'abandonner le stockage HDD pour les VPS. Ainsi les Nextcloud/peertube seront plus réactifs et les processeurs seront mieux utilisés (en évitant d'attendre des écritures/lectures de disques durs). Par ailleurs, avoir plus de capacité de stockage peut permettre de développer l'offre Nextcloud sur sans-nuage en s'inspirant par exemple du projet frama.space. 1.1 Le choix du type de raid Il faut choisir le type de raid, c'est à dire l'agencement des grappes de disques, que nous souhaitons employer. Ce choix s'arbitre entre plusieurs critères: le prix la capacité utilisable la performance de lecture/écriture (IOPS) la probabilité d'une panne destructrice (difficile à calculer car elle dépend de nombreux facteurs) la minimisation du nombre de disques (= setup + écologique) https://pve.proxmox.com/wiki/ZFS_on_Linux Ce choix dépend forcément des cas d'usages envisagés (vps avec données importantes, vps fiable sans besoin d'être redéployé, vps de dev/test, visio). Pas de raid, 1 pool par disque Les pour: c'est écolo : ratio capacité utilisable/capacité réel = 100% c'est pas cher (6x2To = 1200€ OU 4 disques de 4To = 1680€) c'est simple Les moins: En cas de panne le système peut être perdu (= temps bénévole pour relancer) En cas de panne les VM sur le disque en panne sont perdues (si il n'y a pas de réplication sur un autre nœud) écriture/lecture = 500Mo/s par disque, toutes les VM sur un disque se partagerons ça (il y a mieux en terme de perf voir raidz) ~ Raid0, 1 pool pour plusieurs disques Les pour: c'est écolo : ratio capacité utilisable/capacité réel = 100% c'est pas cher (6x2To = 1200€ OU 4 disques de 4To = 1680€) c'est simple écriture/lecture = 500Mo/s par disque = > 1 pool de 3 disques = 1500Mo/s Les moins: En cas de panne le système peut être perdu (= temps bénévole pour relancer) En cas de panne d'un disque toutes les VM du pool sont perdues (si il n'y a pas de réplication sur un autre nœud) Raid1 - les disques sont par 2 et les données recopiées en miroirs, 1 pool par raid1 Les pour: ça reste simple Vitesse de lecture = 500Mo/s x Nombre de disque en miroir Les moins: le ratio capacité utilisable/capacité réel est de 50% (ou 30% si 3 disques...) c'est cher (12x2To = 2400€ OU 8x4To = 3360€) une panne simultanée des 2 disques est possible (on a déjà vécu), il y a donc un risque de travail bénévole supplémentaire Pas possible de transformer en raidz, il faut faire une nouvelle grappe à côté Raid10 - les disques sont par 2 et les données recopiées en miroirs, plusieurs raid1 par pool Les pour: ça reste simple on peut retirer un raid1 du pool (si il y a la place) Vitesse du pool = 500Mo/s x Nombre de raid1 on peut agrandir chaque sous raid en remplaçant le disque par un plus gros Les moins: le ratio capacité utilisable/capacité réel est de 50% c'est cher (12x2To = 2400€ OU 8x4To = 3360€) une panne simultanée des 2 disques est possible (on a déjà vécu), il y a donc un risque de travail bénévole supplémentaire Pas possible de transformer en raidz, il faut faire une nouvelle grappe à côté RaidZ-1 - les disques sont par 3 ou plus, et chaque données est redondée sur un autre disques de la grappe Les pour: Le ratio capacité utilisable/capacité réel = capacité réel des disques - la capacité d'un disque, donc 66% avec 3 disques, 60% avec 4 disques + 1 spare et 75% avec 7 disques + 1 spare Possibilité de faire grossir la grappe en ajoutant des disques (au prix d'une dégradation des perfs pendant plusieurs heures) Prix abordables (8x2To = 1600€ OU 6x4To = 2520€) Les moins La vitesse d'écriture / lecture est celles du disques le plus lent Le risque de panne rapprochée de 2 disques (avant que le disque de remplacement ait recopié les données) augmente avec le nombre de disques. Pour atténuer on peut faire 2 grappes de 4 disques. Pas possible d'aller vers du raiz-2, mais possibilité d'ajouter un disque de spare RaidZ-2 - les disques sont par 4 ou plus, et chaque données est redondée sur 2 autres disques de la grappe Les pour: Le ratio capacité utilisable/capacité réel = capacité réel des disques - la capacité de 2 disques, donc 50% avec 4 disques, 60% avec 5 disques et 75% avec 8 disques Plus fiable que le raidz-1 = temps bénévoles économisés Même cout que le raidz-1 pour les grosses grappes Possibilité de faire grossir la grappe en ajoutant des disques (au prix d'une dégradation des perfs pendant plusieurs heures) Les moins La vitesse d'écriture / lecture est celles du disques le plus lent Légèrement moins rapide que le raidz-1 Coûte cher (10x2To = 2000€ OU 8x4To = 3360€) NB: les prix indiqué sont pour des configurations initiales pour une capacité de 8 à 10To. les prix indiqués sont pour des VPS redondés (donc porté par 2 noeuds) si on abandonne cette idée, le prix du stockage peut être 50% moins cher sur les scénario pas de raid et raid1. ou 80% moins chers sur les autres Calcul de probabilité de panne simultanée d'un raid0 SI on considère qu'un disque à 1 chance sur 1460 de tomber en panne chaque jour Pour un raid0 de 2 disques: 1-(1-(1-(1-1/1460)^2))^1460 = 87 chances sur 100 d'avoir une panne dans les 4 ans Pour un raid0 de 3 disques: 1-(1-(1-(1-1/1460)^3))^1460 = 95 chances sur 100 d'avoir une panne dans les 4 ans Calcul de probabilité de panne simultanée le même jour pour un RAID1 SI on considére qu'un disque à 1 chance sur 1460 de tomber en panne chaque jour La probabilité que sur 4 ans 2 disques d'un même raid tombe en panne est: 1−(1-1/1460^2)^1460 = 6,8 chances sur 10 000 Calcul de probabilité de panne simultanée d'un raid1 partie prenante d'un raid10 Pour une grappe de 2x2 disques: L'inverse de la probabilité qu'aucune tombe en panne 1-(1-(1-(1-1/1460^2)^2))^1460 = 1,3 chances sur 1000 Pour une grappe de 4x2 disques: 1-(1-(1-(1-1/1460^2)^4))^1460 = 2,7 chances sur 1000 1.2 Choix du type de disques Nous avons actuellement 4x1To (+ 1 disque de spare) et un certains nombre de 512Mo. Les 512Mo pourront être réutilisé comme cache / log pour améliorer les perfs. Il est proposé de prendre soit des disques de 4To soit de 2To. scénario avec des 2To Pour Plus de disques = plus de vitesses d'écriture Légèrement moins cher Contre Plus de disques = plus de consommation électrique Disque plus petit = obsolète plus rapidement scénario avec des 4To Pour Plus économes en énergie et sans doute en ressources Un peu plus long terme (mais attention ce ne sera sans doute pas des M2) Contre Moins de disques = moins de vitesses d'écriture Un disque 2 x plus gros double le risque d'une panne simultannée de 2 disques Je suggère de commencer par 4x4To et 4x2To en raid10 soit 2 640€ à mettre dans 2 serveurs. On peut aussi mettre 1000€ de plus pour 8x4To. 1 Go utilisable en raid10 redondé: 0,44€ (hors élec) 1 Go utilisable en raid10 non redondé: 0,22€ (hors élec) 1 Go sans raid non redondé: 0,11€ (hors élec) On pourra ensuite rajouter petit à petit des 2x4To (800€) 2. Bascule des VPS sur le serveur hwhost-2 sur 10 jours Migrer les VM Définir hw2 comme master ganeti S'assurer que le réseau passe 3. Tests du sata III https://www.sia-informatique.com/flasher-ibm-m1015-lsi-9211-8i-sas2008/ 3. Installation d'un cluster proxmox/zfs à partir des serveurs hwhost-2 et hwhost-3 Bilan de la session: le serveur proxmox est accessible avec une IP, il reste de la configuration réseau pour pallier à l’absence de DHCP, mais ça on peut le faire OKLM En détails: nous avons: créé un vlan 800 dédié au cluster proxmox et utilisé la prise f0a/8 du switch modifié les scripts /etc/carp/vip-up.sh et /etc/carp/vip-down.sh de ucarp pour supporter les vlan commençant par 8 en plus des vlan commençant par 5 créé des interfaces h-proxmox sur les routeur passerelles configuré le serveur 2U HP proxmox avec sa nouvelle IP v4 89.234.141.133 et sa nouvelle IPv6 fait un test de redémarrage et de nombreux tests de connectivité Nous avons perdu du temps en éditant la configuration /etc/network/interfaces et en relançant le réseau sans vérifier l’effectivité avec ip a. On a finit par comprendre ce qui clochait. 4. Création d'une VM de test et travail sur le routage (BGP + routage interne) Mettre du réseau sur une VM méthode à améliorer Dans la VM, mettre la configuration habituelle (celle de ganeti) ``` auto eth0 iface eth0 inet static pre-up /sbin/ip link set $IFACE up pre-up /sbin/ip route add 169.254.42.1 dev $IFACE address 89.234.141.82/32 gateway 169.254.42.1 ``` puis `systemctl restart networking` Sur l'hôte proxmox, Ajouter l'ip de lien local 169.254.42.1 sur l'interface fwbr102i0 ``` ip a a 169.254.42.1 dev fwbr102i0 ``` Router l'ipv4 publique de la VM 89.234.141.82 vers l'interface fwbr102i0 ``` ip r a 89.234.141.82 dev fwbr102i0 scope link src 89.234.141.133 ``` Sur les routeurs de bordure, ajouter une route: ``` ip r a 89.234.141.82 via 89.234.141.133 ``` Test avec une VM ubuntu /etc/netplan/01-netcfg.yaml network: ethernets: eth0: addresses: [89.234.141.81/32] routes: - to: 0.0.0.0/0 via: 169.254.42.1 nameservers: addresses: [89.234.141.66] dhcp4: false dhcp6: false version: 2 5. Migration des VMs internes d'ARN 6. Écriture d'un script de migration capable de migrer les VM des membres sur le nouveau cluster 7. Migration au fur et à mesure (mais rapidement quand même) 8. Extinction du serveur hwhost-1 9. (à un moment) Rachat de disques pour le serveur hwhost-1 et ajout du nœud au cluster 10 Configuration du réseau pour le serveur proxmox Last update 28/6/23 Le serveur proxmox est installé. Une VM test a été montée (Ubuntu 22). Le problème, c'est que la VM n'a pas de réseau. Il faut lors de la création de chaque VM assignée manuellement une IP fixe à cette VM.