Plan réseau type : management, Corosync, Ceph public/cluster, migration, VM, backup¶
Un cluster Proxmox stable sépare ses flux : Corosync sur un lien dédié à faible latence avec un second lien de secours, Ceph sur un réseau rapide séparé, et migration, sauvegarde et VM isolés pour qu'aucun flux massif n'affame le cluster. Objectif : disposer d'un plan d'adressage type, à adapter avec le MSP au moment du Day 0.
Notions clés¶
Les flux d'un cluster¶
| Flux | Besoin | Sensibilité | Débit conseillé |
|---|---|---|---|
| Management (GUI, API, SSH) | Accès admin, mises à jour | Faible | 1 Gb/s |
| Corosync link0 | Quorum, verrous, état HA | Latence et gigue (< 5 ms exigés) | 1 Gb/s dédié suffit |
| Corosync link1 | Secours de link0 | Idem | Réseau existant (management) |
| Ceph public | Accès des clients RBD (VM) aux OSD, moniteurs | Latence, débit | 25 Gb/s ou plus |
| Ceph cluster | Réplication et reconstruction entre OSD | Débit | 25 Gb/s ou plus |
| Migration | Copie de la RAM (et des disques locaux) | Débit, rafales | 10 Gb/s ou plus |
| Sauvegarde | PVE → pbs-local, sync vers le PBS du MSP |
Débit, la nuit | 10 Gb/s |
| VM | Trafic des applications | Selon usage | Bond 2 × 10/25 Gb/s |
| Stockage externe | iSCSI, NFS (architecture SAN) | Latence | 2 chemins dédiés |
Corosync supporte jusqu'à 8 liens (kronosnet) et bascule seul entre eux : il n'a pas besoin de bond. La documentation officielle recommande au moins une carte physique dédiée pour le lien principal et déconseille de partager ce réseau avec le stockage, sauf comme lien de secours de faible priorité.
Plan d'adressage type (cluster Ceph HCI 3 nœuds)¶
| Réseau | VLAN | Sous-réseau | pve01 / pve02 / pve03 | Support physique |
|---|---|---|---|---|
| Management + Corosync link1 | 10 | 10.10.10.0/24 | .11 / .12 / .13 | bond0 → vmbr0.10 |
| Corosync link0 | — (dédié) | 10.10.20.0/24 | .11 / .12 / .13 | eno3 seule, switch dédié ou accès |
| Ceph public | 30 | 10.10.30.0/24 | .11 / .12 / .13 | bond1 2 × 25 Gb/s |
| Ceph cluster | 31 | 10.10.31.0/24 | .11 / .12 / .13 | bond1 (ou cartes séparées) |
| Migration | 40 | 10.10.40.0/24 | .11 / .12 / .13 | bond1 ou bond0 |
| Sauvegarde | 50 | 10.10.50.0/24 | .11 / .12 / .13 ; PBS .20 | bond0 |
| VM | 100-199 | selon client | — | bond0 → vmbr0 (tags) |
Schéma¶
flowchart LR
subgraph Nœud pve01
E3[eno3] --> C0[Corosync link0<br/>10.10.20.11]
B0[bond0 2x10G] --> V0[vmbr0 VLAN-aware]
V0 --> M[vmbr0.10 mgmt + link1]
V0 --> BK[vmbr0.50 backup]
V0 --> VMS[VM tags 100-199]
B1[bond1 2x25G] --> CP[Ceph public VLAN 30]
B1 --> CC[Ceph cluster VLAN 31]
B1 --> MG[Migration VLAN 40]
end
C0 --> SWC[Switch Corosync]
B0 --> SWA[Switchs accès empilés]
B1 --> SWS[Switchs stockage 25G]
BK -.-> PBS[pbs-local] -.-> MSP[PBS du MSP]Où se règle chaque réseau¶
| Réseau | Paramètre | Moment |
|---|---|---|
| Corosync | Liens choisis à la création du cluster (pvecm create ... --link0 ... --link1 ...), puis /etc/pve/corosync.conf |
Day 1, voir Créer un cluster multi-liens |
| Ceph | public_network, cluster_network dans /etc/pve/ceph.conf (assistant pveceph init) |
Day 1, ne se change plus facilement |
| Migration | Datacenter → Options → Migration Settings → réseau 10.10.40.0/24 ; dans /etc/pve/datacenter.cfg : migration: secure,network=10.10.40.0/24 |
Day 1, modifiable |
| Sauvegarde | Adresse du PBS utilisée dans le stockage pbs-local |
Day 1 |
| VM | Tag VLAN sur chaque carte de VM | Au fil de l'eau, par le client |
Variantes selon l'architecture livrée¶
| Architecture | Adaptation |
|---|---|
| Ceph HCI 3+ nœuds | Plan complet ci-dessus. Full-mesh possible à 3 nœuds pour Ceph, voir Réseaux Ceph |
| ZFS répliqué 2 nœuds + QDevice | Pas de Ceph. Réseau de réplication ZFS = réseau de migration. Le QDevice doit joindre les deux nœuds sur un lien Corosync |
| SAN externe | Remplacer Ceph par deux réseaux iSCSI distincts (sans bond, multipath) ou FC |
| Mono-nœud ZFS | Pas de Corosync. Management, sauvegarde et VM suffisent |
Recommandations MSP¶
- Fixez le plan avant l'installation : changer l'IP d'un nœud ou le réseau Ceph après coup est une opération lourde, confiée au MSP.
- Corosync link0 sur une carte dédiée, link1 sur le management : deux liens indépendants, jamais deux VLAN d'un même bond.
- MTU 9000 seulement sur des réseaux fermés (Ceph, stockage, migration), configurée de bout en bout et testée avec
ping -M do -s 8972. - Documentez le plan dans le dossier d'exploitation et dans le ticket de livraison iTop.
Pièges vus en support
- Corosync et Ceph sur le même lien : une reconstruction Ceph sature le réseau, Corosync perd des messages, les nœuds HA se fencent.
- Migration sans réseau dédié : la copie de RAM passe par le management et ralentit l'accès à la GUI.
- Sauvegarde nocturne et sync vers le MSP sur le même lien que les VM en production.
- Deux liens Corosync qui passent par le même switch : pas de vraie redondance.
- Bond LACP pour Corosync sans
bond-lacp-rate fast: bascule trop lente, déclenchement de fencing.
Testez-vous¶
-
Pourquoi Corosync n'a-t-il pas besoin d'un bond ?
Réponse
Il gère plusieurs liens (kronosnet) et bascule seul de l'un à l'autre. On lui donne deux réseaux physiquement indépendants.
-
Quelle latence maximale le cluster Proxmox exige-t-il ?
Réponse
Moins de 5 ms (latence de LAN), avec une faible gigue.
-
Où définit-on le réseau de migration ?
Réponse
Datacenter → Options → Migration Settings, enregistré dans
/etc/pve/datacenter.cfg(migration: secure,network=...). -
Quels flux Ceph faut-il distinguer ?
Réponse
Le réseau public (clients et moniteurs) et le réseau cluster (réplication et reconstruction entre OSD).