Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)

Saturne3

De AJLSM
Aller à la navigation Aller à la recherche

="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.

Récupérée de "https://mediawiki.ajlsm.com/index.php?title=Saturne3&oldid=6065"