Foxency
Administration Système et Infrastructure

Virtualisation réseau avec VMware ou Proxmox

Une plateforme de virtualisation concentre gestion, migration, stockage et trafic des machines virtuelles sur quelques cartes réseau. Bien séparer ces flux conditionne performances et sécurité.

Par Rédaction Foxency Publié le 5 min de lecture

Hôtes de virtualisation reliés à des commutateurs physiques avec flux de gestion, migration, stockage et machines virtuelles séparés

La virtualisation fait tourner de nombreux serveurs sur quelques hôtes physiques. Le réseau de ces hôtes doit alors transporter des flux très différents : administration, migration à chaud, stockage partagé, cluster et trafic des machines virtuelles. Les mélanger sans précaution expose à des problèmes de performance et de sécurité.

Objectif : concevoir le réseau d'un cluster de virtualisation, avec VMware vSphere ou Proxmox VE, en séparant correctement les flux. Le fonctionnement interne des commutateurs virtuels est détaillé dans Commutateurs virtuels et réseaux de machines virtuelles.

Les flux d'une plateforme de virtualisation

Flux Rôle Exigences
Gestion Accès à l'interface et à l'API des hôtes (vCenter, interface web Proxmox) Très restreint, réseau d'administration
Migration à chaud vMotion (VMware), migration en direct (Proxmox) Débit élevé, isolé ; contient la mémoire des VM en transit
Stockage iSCSI, NFS, Ceph, vSAN Faible latence, débit élevé, souvent trames jumbo
Cluster Battements de cœur, quorum (Corosync pour Proxmox) Faible latence, stabilité absolue
Machines virtuelles Trafic applicatif des VM Segmenté par VLAN selon les besoins
Sauvegarde Flux des outils de sauvegarde Volumineux, planifiable

Principe : chaque flux dispose au minimum de son propre VLAN et de son propre sous-réseau. Les flux sensibles (gestion, migration, stockage, cluster) ne sont pas routés vers les réseaux utilisateurs.

Architecture physique type

Avec deux cartes 25 Gbit/s par hôte (ou deux paires de cartes), une conception fréquente :

  • les deux cartes sont reliées à deux commutateurs physiques différents pour la redondance ;
  • elles sont configurées en trunk 802.1Q transportant les VLAN nécessaires ;
  • l'agrégation ou la répartition des flux se fait côté hyperviseur.
                 Commutateur A ──── Commutateur B
                    │   (liaison inter-commutateurs ou MLAG)   │
                 ┌──┴───────────────────────────────────────┴──┐
Hôte 1 : nic0 ───┘                                             └─── nic1
VLAN transportés : 10 (gestion), 11 (migration), 12 (stockage), 13 (cluster), 100-199 (VM)

Si les hôtes disposent de davantage de cartes, on peut dédier physiquement certaines au stockage, ce qui isole complètement ce flux critique.

VMware vSphere

Commutateurs standard et distribués

  • vSphere Standard Switch (vSS) : configuré hôte par hôte.
  • vSphere Distributed Switch (vDS) : configuré une fois dans vCenter et appliqué à tous les hôtes ; il offre des fonctions avancées (NetFlow, mise en miroir de ports, LACP, contrôle d'E/S réseau). Sa disponibilité dépend de l'édition de licence.

Les VM se connectent à des groupes de ports (port groups) associés à un VLAN. L'hôte lui-même communique via des interfaces VMkernel (vmk), chacune dédiée à un service.

Interfaces VMkernel par service

vmk0  Gestion           VLAN 10   10.0.10.11/24
vmk1  vMotion           VLAN 11   10.0.11.11/24   (pile TCP/IP vMotion)
vmk2  Stockage iSCSI    VLAN 12   10.0.12.11/24

Utiliser la pile TCP/IP dédiée vMotion permet de lui attribuer sa propre passerelle et de l'isoler du reste.

Répartition et redondance

L'association des cartes physiques (NIC teaming) d'un groupe de ports définit l'ordre de basculement et la politique de répartition (par port virtuel d'origine par défaut, ce qui ne nécessite aucune configuration côté commutateur). Pour iSCSI, VMware recommande la liaison de ports (port binding) avec une carte active par interface VMkernel, plutôt qu'une agrégation.

Proxmox VE

Proxmox VE s'appuie sur la pile réseau Linux. La configuration est stockée dans /etc/network/interfaces (gérée par ifupdown2) et modifiable par l'interface web.

Pont « VLAN-aware »

L'approche la plus souple consiste à créer un pont unique, sensible aux VLAN, au-dessus d'une agrégation :

# /etc/network/interfaces — exemple de laboratoire
auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

auto vmbr0.10
iface vmbr0.10 inet static
    address 10.0.10.21/24
    gateway 10.0.10.1

Chaque VM reçoit ensuite une carte virtuelle sur vmbr0 avec une étiquette VLAN définie dans ses propriétés. L'hôte lui-même communique sur le VLAN de gestion via vmbr0.10.

Réseau du cluster (Corosync)

Corosync est très sensible à la latence. La documentation Proxmox recommande un réseau dédié pour le cluster, et la configuration de plusieurs liens Corosync pour la redondance. Une saturation du lien partagé par une migration ou une sauvegarde peut provoquer la perte du quorum et des redémarrages de nœuds si la haute disponibilité est active.

SDN Proxmox

Proxmox VE propose une pile SDN (zones simples, VLAN, QinQ, VXLAN, EVPN) qui permet de définir les réseaux virtuels au niveau du cluster plutôt qu'hôte par hôte.

Points de conception communs

  1. Redondance physique : deux cartes, deux commutateurs, deux alimentations électriques.
  2. MTU cohérente : si les trames jumbo sont utilisées pour le stockage ou la migration, elles doivent être configurées sur les interfaces de l'hôte, les commutateurs virtuels et physiques. Testez avec vmkping -d -s 8972 (VMware) ou ping -M do -s 8972 (Proxmox).
  3. Agrégation alignée : le mode LACP de l'hôte doit correspondre à la configuration des commutateurs ; avec deux commutateurs, ceux-ci doivent prendre en charge l'agrégation multi-châssis (MLAG, vPC, empilement).
  4. Gestion isolée : l'interface de gestion des hyperviseurs n'est jamais accessible depuis les réseaux utilisateurs ni depuis Internet.
  5. Documentation : tableau VLAN / sous-réseau / service / MTU par hôte.

Erreurs courantes

  • Tout faire passer sur le VLAN de gestion, y compris la migration et le stockage.
  • LACP configuré côté hôte mais pas côté commutateur (ou l'inverse) : perte de connectivité intermittente.
  • Trames jumbo partielles, créant un trou noir MTU sur le stockage.
  • Réseau du cluster partagé avec la sauvegarde, provoquant des pertes de quorum.
  • Exposer l'interface de gestion de l'hyperviseur sur Internet.

Implications de sécurité

La compromission d'un hyperviseur donne accès à toutes ses VM : la gestion doit être isolée, filtrée et protégée par une authentification forte. Le trafic de migration contient la mémoire des VM et doit rester sur un réseau non routé (ou être chiffré lorsque la plateforme le permet). Appliquez les correctifs de l'hyperviseur, désactivez les services inutiles (SSH permanent sur ESXi, par exemple) et journalisez les accès.

Conclusion

Concevoir le réseau d'une plateforme de virtualisation, c'est d'abord séparer les flux : gestion, migration, stockage, cluster et VM, chacun sur son VLAN, avec une redondance physique et une MTU cohérente. VMware et Proxmox offrent des outils différents pour y parvenir, mais les principes sont identiques.

Références