(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 2×2 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 4×2 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.