Contexte historique
Le service vServer de Hetzner, lancé en 2011, reposait sur des ponts Linux natifs, des disques durs classiques et des routes statiques. Chaque hôte offrait une connectivité dual‑stack (IPv4/IPv6) limitée à 1 Gb/s, avec environ 25 000 instances déployées. En septembre 2015, le produit a migré vers une architecture hyper‑convergée basée sur Ceph, introduisant le routage dynamique BGP et un pont Linux utilisant du NAT 1:1 pour IPv4, tandis que les préfixes IPv6 étaient entièrement routés. Cette évolution a permis une mobilité d’adresses IP et une maintenance d’hôte sans interruption client. En 2016, la bande passante physique des liaisons hôte a été portée à 2 × 10 Gb/s, soutenant la croissance jusqu’à 50 000 instances d’ici 2018.
Transition vers Open vSwitch
Le lancement de Hetzner Cloud en 2018 a marqué la suppression du NAT IPv4 au profit d’un routage direct, simplifiant la chaîne de traitement des paquets. En juillet 2019, Hetzner a introduit un plan de données basé sur Open vSwitch (OvS), ajoutant le support des réseaux privés virtuels via l’encapsulation VXLAN. Cette couche logicielle a été progressivement étendue : en novembre 2020, la partie publique du réseau a commencé à être migrée vers OvS, ouvrant la voie à des firewalls d’état gérés par des flux OvS combinés à netfilter, déployés en mars 2021. Chaque étape a été guidée par la volonté de placer les fonctions réseau sur les hôtes plutôt que sur l’infrastructure physique.
Architecture actuelle du stack réseau
Le stack d’un hôte VM se compose d’Open vSwitch orchestré par un moteur propriétaire (« Flusskrebs »). Les flux OvS définissent le traitement du trafic entrant et sortant, incluant les règles de firewall, le routage IPv4 direct et la distribution VXLAN pour les réseaux privés. Chaque réseau privé possède un identifiant VXLAN (VNI) unique, garantissant que seuls les membres du réseau peuvent échanger des paquets encapsulés. Les services d’infrastructure – firewalls, private networks, services auxiliaires – résident sur le même hôte, ce qui limite le « blast radius » à un seul serveur en cas de défaillance. Le plan de contrôle cloud, qui orchestre serveurs, load balancers et réseaux, reste hors du périmètre de cet article, mais il interagit avec OvS via l’API REST interne pour pousser les flux requis.
Analyse des impacts et limites
En plaçant la logique réseau sur les hôtes, Hetzner gagne en flexibilité : les équipes peuvent déployer de nouvelles fonctionnalités (ex. firewalls d’état, segmentation VXLAN) sans dépendre du matériel du fournisseur. La séparation physique‑logique minimise les contraintes de mise à jour du réseau sous‑jacent, car les liens 2 × 10 Gb/s restent stables et ne subissent pas de reconfiguration logicielle. Cependant, cette approche augmente la charge CPU et mémoire sur chaque hôte, notamment lors du traitement de gros volumes de flux VXLAN ou de règles netfilter complexes. La scalabilité dépend donc de la capacité des serveurs à absorber ces coûts, ce qui peut imposer des limites de densité de VM sur les hôtes les plus anciens. De plus, la dépendance à un orchestrateur propriétaire crée un verrouillage interne : toute migration vers une solution tierce (ex. Cilium, Calico) nécessiterait une réécriture substantielle du moteur de flux. Enfin, la visibilité du trafic est concentrée au niveau de l’hôte, ce qui complique la mise en place d’outils de monitoring réseau traditionnels basés sur le spine‑leaf physique.
