Une carte réseau qui part en silence sur un hyperviseur mono-lien (un serveur avec une seule connexion réseau), c’est douze VM injoignables d’un coup et trois heures perdues à chercher un bug logiciel qui n’existe pas. J’ai vécu ce cas. Le réseau Proxmox, sur beaucoup d’installations, est ce qu’on regarde en dernier : les VM tournent, donc « ça marche ». Jusqu’au soir où un lien tombe ou où la réplication sature. Voilà dans quel ordre je pose les choses avant de livrer un nœud.
Trois briques reviennent dans cet article. Le VLAN, d’abord : il découpe un même câble physique en réseaux logiques étanches, comme des couloirs séparés sur une autoroute partagée. Le bonding agrège plusieurs liens en un seul, de quoi survivre à la perte de l’un d’eux. Quant à la MTU, c’est la taille du plus gros paquet réseau qu’une interface accepte d’envoyer d’un coup. Je reviens sur chacune au fil du texte.
Un réseau Proxmox de production repose sur trois choses posées dans l’ordre : un pont VLAN-aware pour segmenter, du bonding pour survivre à la perte d’un lien, et une MTU 9000 cohérente de bout en bout sur le stockage, vérifiée au paquet près avant la mise en charge.
1. Un seul pont VLAN-aware par hyperviseur. Un pont (bridge), c’est le commutateur virtuel interne du serveur, celui auquel les VM se raccordent ; « VLAN-aware » signifie qu’il sait, à lui seul, gérer tous les VLAN au lieu d’en dédier un par réseau. Vous attribuez ensuite un VLAN par usage ou par client sans multiplier les interfaces. C’est la fondation de tout le reste : isolation nette d’un côté, et de l’autre des migrations de VM entre nœuds qui ne réclament aucun recâblage de la cible. Ajouter un client devient une ligne de configuration plutôt qu’un déplacement en salle.
2. Deux liens physiques agrégés en bond. Le bond, c’est ce groupement de liens vu par le système comme une seule interface. Vous gagnez la tolérance de panne, et en LACP de la bande passante en plus. LACP (Link Aggregation Control Protocol), c’est le mode où le serveur et le switch s’accordent pour répartir le trafic sur les deux câbles à la fois, au lieu de simplement basculer de l’un à l’autre. Qu’un câble lâche ou qu’un port meure, le trafic bascule sans que personne s’en aperçoive. Un nœud de production sur un lien unique, je n’en livre pas. C’est précisément ce qui m’a coûté les trois heures évoquées plus haut.
3. MTU 9000 sur le réseau dédié au stockage et à la réplication (Ceph, ZFS send, PBS). Par défaut la MTU vaut 1500 octets ; la pousser à 9000, c’est ce qu’on appelle activer les jumbo frames. L’idée : chaque paquet transporte plus de données, donc il en faut six fois moins pour la même quantité, et la machine passe moins de temps à les traiter. Ce moindre overhead fait monter le débit utile, de l’ordre de 15 à 30 % sur du trafic Ceph soutenu selon le matériel. À une condition : toute la chaîne suit, cartes, switchs, chaque port traversé. Une incohérence ne provoque pas une panne franche mais des pertes silencieuses, des lenteurs qu’on met des heures à rattacher au réseau.
4. La vérification, avant la mise en charge. Personne ne la fait, et c’est là que tout se joue. Le piège classique : MTU à 9000 sur les serveurs, restée à 1500 sur le switch. Les petits paquets passent, donc le SSH répond et le ping marche, tout paraît sain. Les gros, eux, sont jetés ou fragmentés, le stockage rame sans cause visible. On accuse l’application, on retourne le code, on n’y trouve rien. Le test qui tranche : un ping en taille forcée, avec le bit DF (Don’t Fragment) positionné. Ce bit interdit au réseau de découper le paquet en route : s’il est trop gros pour un maillon du chemin, il est rejeté au lieu d’être fragmenté en douce. L’échec devient visible au lieu de rester masqué. On envoie alors un paquet de la taille maximale qu’une MTU 9000 autorise (8972 octets de charge utile, le reste partant dans les en-têtes), puis un petit calibré pour une MTU 1500 (1472 octets). Si le 8972 ne passe pas alors que le 1472 passe, le coupable est sur le chemin, pas dans vos VM : un maillon est resté en 1500.
Cet ordre n’est pas négociable : un bond posé après coup impose une fenêtre de maintenance, une MTU corrigée en production se paie en astreinte. Le 8972 passe, ou il ne passe pas. Tant qu’il ne passe pas, on ne met rien en charge.