Saturne3

="84217"}

Installation Proxmox VE 9 sur serveur OVH (Saturne3)

1. Contexte

Migration d’un serveur Proxmox existant (Saturne) vers un nouveau serveur OVH (Saturne3).

Objectifs :

• Moderniser l’infrastructure
• Augmenter la capacité disque
• Préparer une migration propre via vRack
• Conserver la production sans interruption

---

2. Choix du serveur

Configuration :

• 4 × NVMe 960 Go
• 384 Go RAM

---

3. Choix du RAID

Analyse

• RAID0 : capacité maximale mais aucun redondance → rejeté
• RAID1 : capacité insuffisante (~872 Go)
• RAID10 : capacité trop limitée (~1.7 To)
• RAID5 : compromis retenu

Choix final

• RAID5 matériel OVH
• Capacité utile ≈ 2.6 To

Justification :

• espace suffisant (usage actuel ≈ 1.3 To)
• tolérance à 1 disque HS
• bon compromis capacité / sécurité

---

4. Partitionnement

Configuration retenue :

• /boot : 1 Go (ext4, RAID1)
• / : 20 Go (ext4, RAID1)
• swap : 64 Mio (minimum)
• /var/lib/vz : ZFS (RAID5)

Remarque :

• les partitions système sont en RAID1 → sécurité boot
• le stockage principal est en RAID5

---

5. Installation OVH

Options :

• OS : Proxmox Virtual Environment 9
• Disques : JBOD
• Partitionnement personnalisé

SSH :

• ajout de la clé publique du poste client

---

6. Accès initial

Connexion SSH :

ssh root@141.95.206.118

Définition du mot de passe root :

passwd

---

7. Mise à jour système

apt update && apt full-upgrade -y

Remarque :

• dépôt enterprise absent → normal sur ce template

---

8. Configuration ZFS

Vérification

zpool status
 zfs list

Résultat :

• pool : data
• type : raidz1 (équivalent RAID5)
• capacité ≈ 2.4 To

---

9. Optimisation ZFS (ARC)

Avec 384 Go RAM, limitation nécessaire :

echo "options zfs zfs_arc_max=171798691840" > /etc/modprobe.d/zfs.conf
 update-initramfs -u
 reboot

Objectif :

• limiter ARC à ~160 Go
• éviter la saturation mémoire

Vérification :

cat /sys/module/zfs/parameters/zfs_arc_max
171798691840

root@Saturne3:~# cat /proc/spl/kstat/zfs/arcstats | grep -E "size|max"
hash_elements_max               4    44
hash_chain_max                  4    0
c_max                           4    171798691840
size                            4    2742736
compressed_size                 4    161280
uncompressed_size               4    2528768
overhead_size                   4    2391552
hdr_size                        4    23424
data_size                       4    0
metadata_size                   4    2552832
dbuf_size                       4    37168
dnode_size                      4    101088
bonus_size                      4    19520
anon_size                       4    0
mru_size                        4    1639424
mru_ghost_size                  4    0
mfu_size                        4    913408
mfu_ghost_size                  4    0
uncached_size                   4    0
l2_prefetch_asize               4    0
l2_mru_asize                    4    0
l2_mfu_asize                    4    0
l2_bufc_data_asize              4    0
l2_bufc_metadata_asize          4    0
l2_size                         4    0
l2_asize                        4    0
l2_hdr_size                     4    0
l2_log_blk_avg_asize            4    0
l2_log_blk_asize                4    0
l2_rebuild_size                 4    0
l2_rebuild_asize                4    0
arc_raw_size                    4    0
abd_chunk_waste_size            4    8704

---

10. Réseau OVH

Interface publique

vmbr0 :

• IP : 141.95.206.118/32
• Gateway : 100.64.0.1

IPv6

• Préfixe : /56

Remarque :

• configuration OVH standard
• routage via bridge vmbr0

---

11. Mise en place vRack

Objectif :

• communication privée entre serveurs
• migration sans impact prod

Étape OVH

• ajout du nouveau serveur au vRack
• aucune modification de l’ancien serveur

Configuration Proxmox

Ajout du bridge privé :

auto vmbr1
 iface vmbr1 inet manual
     bridge-ports enp193s0f1np1
     bridge-stp off
     bridge-fd 0

Activation :

ip link set enp193s0f1np1 up

---

12. État actuel

• Proxmox installé et fonctionnel
• RAID5 opérationnel
• ZFS actif
• ARC limité
• réseau public OK
• vRack connecté
• bridge privé prêt (sans IP)

---

13. Étapes suivantes

13.1 Configuration IP privée (vRack)

Objectif :

• permettre la communication directe entre serveurs
• isoler le trafic de migration du réseau public

Choix du réseau privé :

• réseau existant : 192.168.123.0/24

Configuration sur le nouveau serveur (Saturne3) :

auto vmbr1
iface vmbr1 inet static
    address 192.168.123.103/24
    bridge-ports enp193s0f1np1
    bridge-stp off
    bridge-fd 0

Application :

systemctl restart networking

Vérification :

ip a

Résultat attendu :

• vmbr1 actif
• IP 192.168.123.103 assignée

---

13.2 Interconnexion avec le serveur existant

Configuration existante sur Saturne :

vmbr1 → 192.168.123.102/24

Test de connectivité :

Sur Saturne3 :

ping 192.168.123.102

Sur Saturne :

ping 192.168.123.103

Résultat attendu :

• ping OK dans les deux sens
• latence < 1 ms (réseau vRack)

Conclusion :

• interconnexion privée fonctionnelle
• réseau prêt pour migration

---

13.3 Préparation à la migration des VM

Analyse des VM :

Classification par criticité

Risque 0 (VM arrêtées) :

• 100 FORMATION
• 106 template
• 114 CANIGO
• 116 MGMT
• 124 Debian11

Faible risque :

• 105 platinebassebretagne
• 107 pleade-com
• 126 Ubuntu24
• 128 vm-altcha-sentinel

Risque moyen :

• Centreon
• Redmine
• autres outils internes

Critique :

• FW1 / FW2 (firewall)
• haproxy-01 / haproxy-02
• modsec-spoa-01 / modsec-spoa-02
• VM clients (AD44, AD53, etc.)

---

13.4 Stratégie de migration

Principe retenu :

• migration hors cluster
• pas de live migration
• arrêt des VM avant transfert

Pourquoi :

• éviter incohérences (bases de données, services)
• garantir intégrité des disques
• simplifier la procédure

---

13.5 Procédure de migration standard

1. Arrêt de la VM

qm shutdown <VMID>

Vérification :

qm list

2. Sauvegarde

vzdump <VMID> --compress zstd --dumpdir /var/lib/vz/dump

3. Transfert via vRack

scp /var/lib/vz/dump/vzdump-qemu-.vma.zst root@192.168.123.103:/var/lib/vz/dump/

4. Restauration sur Saturne3

qmrestore /var/lib/vz/dump/vzdump-qemu-.vma.zst <VMID>

---

13.6 Ordre de migration recommandé

Phase 1 :

• VM arrêtées (risque nul)

Phase 2 :

• VM internes non critiques

Phase 3 :

• services applicatifs

Phase 4 :

• infrastructure réseau (firewall, proxy)
• nécessite plan de bascule spécifique

---

13.7 Points de vigilance

• Vérifier l’espace disque sur le serveur cible
• Vérifier la cohérence des interfaces réseau VM
• Adapter les bridges (vmbr0 / vmbr1)
• Tester chaque VM après restauration

Important :

• migration VM ≠ migration infrastructure
• certains services réseau devront être reconfigurés

---

13.8 Configuration IPv6 (préparation)

État actuel :

• préfixe IPv6 /56 disponible
• non utilisé pour les VM à ce stade

Utilisation prévue :

• attribution future aux VM
• routage ou NAT selon architecture

Remarque :

• configuration IPv6 reportée après migration des VM
• priorité donnée à la stabilité IPv4 et vRack

13.9 Installation et configuration initiale du nouveau firewall OPNsense (saturne3)

13.9.1 Déploiement de la VM

Une nouvelle VM OPNsense a été créée sur le serveur Proxmox saturne3 avec les caractéristiques suivantes :

• BIOS : OVMF (UEFI)
• stockage : local-zfs
• interfaces réseau :
  • WAN → vmbr0
  • LAN → vmbr2
  • PFSYNC → vmbr3
  • VRACK → vmbr1

13.9.2 Plan d’adressage retenu

Le plan d’adressage utilisé pour la nouvelle instance est le suivant :

• Proxmox : 10.0.0.1
• FW1 (nouveau) : 10.0.0.102
• FW2 (prévu) : 10.0.0.103
• VIP HA : 10.0.0.4

Réseaux internes :

• LAN : 10.0.0.0/24
• PFSYNC : 10.20.0.0/24
• vRack : 192.168.123.0/24

13.9.3 Configuration des interfaces OPNsense (console FreeBSD)

Étape critique lors de l’installation.

Menu utilisé :

• 1) Assign Interfaces
• 2) Set interface IP address

Correspondance des interfaces :

• WAN → vtnet0
• LAN → vtnet2
• OPT1 (PFSYNC) → vtnet3
• OPT2 (VRACK) → vtnet1

---

Configuration LAN :

2) Set interface IP address → 1 (LAN)

• DHCP → n
• IP → 10.0.0.102
• masque → 24
• gateway → vide
• IPv6 → n
• DHCP server → n

---

Configuration PFSYNC :

2) Set interface IP address → 2 (OPT1)

• DHCP → n
• IP → 10.20.0.2
• masque → 24
• gateway → vide
• IPv6 → n

---

Configuration VRACK :

2) Set interface IP address → 3 (OPT2)

• DHCP → n
• IP → 192.168.123.104
• masque → 24
• gateway → vide
• IPv6 → n

---

Configuration WAN :

2) Set interface IP address → 4 (WAN)

• DHCP → y (ou laisser non configuré)
• aucune IP statique définie

---

Résultat attendu :

• LAN → 10.0.0.102
• PFSYNC → 10.20.0.2
• VRACK → 192.168.123.104
• WAN → DHCP ou vide

13.9.4 Accès à l’interface OPNsense

Accès via tunnel SSH :

ssh -L 8443:10.0.0.102:443 root@141.95.206.118

Navigateur :

https://localhost:8443

13.9.5 Import de la configuration existante

Une configuration issue du firewall existant a été importée.

Éléments récupérés :

• règles firewall
• NAT
• certificats
• OpenVPN

Adaptations :

• IP LAN conservée en 10.0.0.102
• suppression des éléments HA
• WAN non activé

13.9.6 Particularité du port de l’interface web

Après import :

• port GUI → 453

Correction :

• remise en port 443

13.9.7 État des règles firewall

Règles LAN principales :

• LAN net → any
• OpenVPN net → any
• règles VRACK vers LAN (80/443/22)

Configuration fonctionnelle sans modification majeure.

13.10 Gestion des utilisateurs Proxmox

13.10.1 Création d’un utilisateur dédié

Utilisateur créé :

extra-ajlsm@pam

Caractéristiques :

• utilisateur Linux associé
• accès SSH par clé
• utilisateur Proxmox (RBAC)

13.10.2 Attribution des droits

Création :

pveum useradd extra-ajlsm@pam

Attribution :

pveum aclmod / -user extra-ajlsm@pam -role Administrator

13.10.3 Accès SSH

Clé installée dans :

/home/extra-ajlsm/.ssh/authorized_keys

Accès par clé uniquement.

13.10.4 Accès Proxmox GUI

URL :

https://141.95.206.118:8006

Login :

extra-ajlsm@pam

Mot de passe défini pour accès GUI.

13.11 Gestion des règles firewall OPNsense

Présence de :

• Rules (legacy)
• Rules [new]
• Migration assistant

Décision :

• utilisation des règles legacy
• aucune migration effectuée

Motif :

• stabilité de la configuration importée
• éviter toute modification en phase de préparation

13.12 Configuration des sauvegardes Proxmox sur saturne3

13.12.1 Objectif

La configuration des sauvegardes de saturne3 reprend la logique existante de saturne :

• sauvegarde locale sur local
• sauvegarde distante sur NFS (serveur beotos3)
• sauvegarde sur PBS4

Une adaptation a été mise en place :

• séparation des sauvegardes historiques de saturne et des nouvelles sauvegardes de saturne3 sur le serveur NFS beotos3

---

13.12.2 Stockages configurés sur saturne3

Le fichier /etc/pve/storage.cfg contient les stockages suivants :

dir: local
        path /var/lib/vz
        content iso,backup,vztmpl

zfspool: local-zfs
        pool data
        content images,rootdir
        sparse 1

pbs: PBS4
        datastore pbs-saturne
        server 51.178.245.43
        content backup
        fingerprint 79:e2:df:a6:33:56:1b:22:63:b3:31:a4:09:63:de:c4:50:e3:eb:d5:87:a0:14:f0:c8:9c:fa:ed:df:b0:1a:39
        prune-backups keep-daily=15,keep-monthly=2,keep-weekly=3
        username root@pam

dir: beotos3-import
        path /mnt/pve/beotos3-import
        content backup
        prune-backups keep-daily=1,keep-last=1,keep-monthly=2,keep-weekly=3
        shared 1

dir: beotos3-import-saturne3
        path /mnt/pve/beotos3-import-saturne3
        content backup
        prune-backups keep-daily=1,keep-last=1,keep-monthly=2,keep-weekly=3
        shared 1

Rôle des stockages :

• beotos3-import : accès aux anciennes sauvegardes de saturne
• beotos3-import-saturne3 : nouvelles sauvegardes propres à saturne3

---

13.12.3 Montage NFS du nouvel espace de sauvegarde saturne3

Sur le serveur beotos3, un nouveau répertoire a été créé pour recevoir les sauvegardes de saturne3 :

/data-backup/pbs/import-saturne3/vz/dump

L’export NFS correspondant a été ajouté dans /etc/exports sur beotos3 :

/data-backup/pbs/import-saturne3/vz/dump 141.95.206.118(rw,sync,no_root_squash,no_subtree_check)

Puis rechargé :

exportfs -ra

Sur saturne3, le point de montage a été créé :

mkdir -p /mnt/pve/beotos3-import-saturne3

Le montage NFS a été déclaré dans /etc/fstab :

51.210.192.214:/data-backup/pbs/import-saturne3/vz/dump /mnt/pve/beotos3-import-saturne3 nfs defaults,_netdev 0 0

Montage appliqué :

mount -a

Vérification :

df -h
findmnt /mnt/pve/beotos3-import-saturne3
pvesm status

---

13.12.4 Accès PBS4 depuis saturne3

Le stockage PBS4 a été activé sur saturne3.

L’accès a été validé via :

pvesm set PBS4 --username root@pam
pvesm set PBS4 --password

Vérification :

pvesm status

Résultat attendu :

• PBS4 actif
• beotos3-import actif
• beotos3-import-saturne3 actif
• local actif
• local-zfs actif

---

13.12.5 Jobs de sauvegarde sur saturne3

Les jobs de sauvegarde ont été recréés sur saturne3.

À ce stade, seule la VM 100 est présente sur le serveur.

Les jobs ont donc été créés avec cette VM uniquement, en reprenant la logique de saturne :

• sauvegarde sur PBS4
• sauvegarde sur local
• sauvegarde sur beotos3-import-saturne3

La liste des VM sera enrichie progressivement au fur et à mesure de la migration des VM vers saturne3.

---

13.12.6 Test de sauvegarde sur stockage NFS

Un test de sauvegarde a été réalisé avec succès pour la VM 100 :

vzdump 100 --storage beotos3-import-saturne3 --mode snapshot

Résultat :

• sauvegarde créée sur /mnt/pve/beotos3-import-saturne3/dump/
• archive générée correctement
• rétention appliquée
• sauvegarde validée

---

13.12.7 Principe de restauration avec changement de VMID

Une sauvegarde Proxmox peut être restaurée avec un VMID différent de celui d’origine.

Exemple :

• sauvegarde d’une VM 300 sur saturne
• restauration sur saturne3 en VM 108

Le VMID contenu dans la sauvegarde n’impose pas le VMID de restauration.

Ce principe permet :

• de restaurer des sauvegardes historiques issues de saturne
• tout en utilisant une nouvelle numérotation de VM sur saturne3

---

13.13 Configuration de l’envoi de courriels sur saturne3

13.13.1 Objectif

Le serveur saturne3 doit être capable d’envoyer des emails pour :

• notifications de sauvegardes
• messages système
• alertes Proxmox

L’approche retenue est identique à celle déjà utilisée sur beotos3 :

• envoi direct via Postfix
• sans relais SMTP authentifié
• sans mot de passe SMTP

---

13.13.2 Configuration Postfix

Le serveur Postfix a été installé et configuré sur saturne3.

La configuration retenue est un envoi direct.

Les points principaux du fichier /etc/postfix/main.cf sont :

myorigin = /etc/mailname
myhostname = saturne3.ajlsm.com
mydestination = $myhostname, localhost.localdomain, localhost
relayhost =
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_security_level = may

Le fichier /etc/mailname contient :

saturne3.ajlsm.com

Le fichier des alias a été régénéré :

newaliases

Puis Postfix a été redémarré :

systemctl restart postfix

---

13.13.3 Validation de l’envoi de courriels

Un test d’envoi a été réalisé avec :

echo "Test direct saturne3" | mail -s "TEST DIRECT SMTP" arvers@ajlsm.com

Résultat :

• envoi accepté par le serveur distant OVH
• message remis avec succès
• file d’attente Postfix vide

Vérification :

journalctl -u postfix -n 20 --no-pager -o cat
postqueue -p

Exemple de résultat attendu dans les logs :

• expéditeur sous la forme root@saturne3.ajlsm.com
• statut sent
• code de remise 250 2.0.0 Ok

---

13.13.4 Remarque sur le domaine

Le FQDN saturne3.ajlsm.com a été créé afin de permettre l’utilisation d’une adresse expéditrice pleinement qualifiée.

Cette mise en conformité est nécessaire pour l’acceptation des messages par certains serveurs distants.

---

13.14 État final

À ce stade :

• les stockages de sauvegarde sont configurés sur saturne3
• les deux répertoires NFS saturne et saturne3 coexistent
• l’accès à PBS4 est opérationnel
• les jobs de sauvegarde sont créés
• un test de sauvegarde a été validé
• l’envoi de courriels depuis saturne3 est opérationnel

Le serveur saturne3 dispose donc d’une configuration de sauvegarde et de notification fonctionnelle, cohérente avec l’infrastructure existante.