Rénovations majeures de 2025
Hello @everyone ! Et oui nouveau VLOG après près de 3 ans de silence…
On est toujours là et on continue toujours d’améliorer l’infra !
C’est d’autant plus vrai ces derniers mois grâce aux nombreuses acquisitions de matériel qu’a pu réaliser @Corentin. Nous avons notamment pu bénéficier d’une subventions auprès de la FSDIE dans le cadre d’un projet de rénovation des infrastructures réseaux et systèmes, mais aussi de dons de matériel que nous avons perçus de la part de différents acteurs.
Ces dernières arrivées ont donc donné un peu de sang neuf à l’infra sur différents aspects, qu’on espère pouvoir vous présenter autour de différents petits VLOG.
On parlera donc de :
- Rénovation de notre infrastructure Cloud publique
- Rénovation de notre infrastructure Core interne
- Rénovation de notre infrastructure Réseau (que je vais présenter aujourd’hui)
À l’issue de ces rénovations, nous aurons plein de matériel à donner ou vendre à petit prix (selon leur provenance), donc restez à l’affût pour ne pas manquer de superbes offres !
Avant de commencer le VLOG technique, on rappelle aussi qu’on recherche toujours des bénévoles afin de bosser avec nous sur l’infra, mais aussi afin de faire parler d’OpenGate sur le campus (communication et commercialisation des offres).
Si vous êtes intéressés, n’hésitez pas à vous manifester !
Place maintenant au vif du sujet…
La refonte réseau
Pour rappel, on a monté le gros de l’infra OpenGate entre 2021 et 2022, et peu de choses ont bougé de ce côté niveau réseau.
La majorité de l’infra repose sur du pure switching L2 très basique (en gros des VLANs qui remontent sur des firewall ou des routeurs). On avait pour cela mis en place une stack basée sur du Cisco NEXUS, une gamme dédiée Datacenter, avec des composants extensibles appelés Fabric Extender.
Nous avions donc installé deux Cisco NEXUS 5520, faisant office de switch de coeurs de réseaux, sur lesquels nous venions connecter plusieurs petits switchs « Extender » dénués d’intelligence, et qui se présentaient grossièrement comme des cartes d’extensions des coeurs de réseaux.
C’était très pratique pour centraliser la configuration des ports, et aussi pour raccorder nos différentes baies à moindre couts (un Fabric Extender 48ports 10G ne coutant que quelques dizaines d’euros).
Les années passent, la taille de l’infra grandit et nos compétences aussi, et on arrive au moment où, en vrai, le switching c’est bien mais c’est chiant…
Ça scale pas, c’est pas moderne, ça repose sur Spanning-Tree (aled), et de nos jours on a de plus en plus tendance à encapsuler le L2 sur du L3 (VxLAN notamment). On s’était déjà intéressé à VxLAN il y a quelques années, mais c’était au-delà de nos compétences, et impossible à mettre en place en l’état (pas adapté à l’archi et les équipements n’étaient pas compatibles). Cependant Proxmox a pas mal changé la donne avec son implémentation native de VxLAN via son module SDN.
En partant du principe qu’on pourrait migrer 100% de notre infra de datacenter sur du VxLAN (encapsulation du L2 sur du L3 pour rappel), il ne nous resterait donc plus qu’à étudier comment migrer notre infra réseau de datacenter (100% switchée) vers du full routé (L3).
Pour faire simple, la seule solution était de remplacer les switchs par des routeurs (ah oui vu que les NEXUS ne routent pas sans cartes et sans licences additionnelles). Le problème c’est que les routeurs ça coûte quand même vachement cher… Et ça vient souvent avec des vices cachés du style achat de licence pour activer le routage dynamique.
Étant déjà pas mal familiers avec les routeurs ARISTA (qu’on avait déjà en prod pour le routage de l’infra, mais qui n’étaient pas compatibles VxLAN), on a donc profité de la subvention FSDIE afin de mettre la main sur trois nouveaux routeurs (deux ARISTA DCS-7050SX, qui serviront pour alimenter les serveurs avec des ports 10G, et un ARISTA DCS-7050TX qui se chargera de toute la partie RJ45).
Ces routeurs ont l’avantage d’être suffisamment perf pour supporter des features avancées telles que VXLAN, et pas trop anciens pour disposer de firmware assez récents et fiables. De plus, la présence de ports 40Gbps sur les trois routeurs nous a permis d’upgrade la capacité « coeur de réseau » anciennement en 10 ou 20Gbps, à 40 voir 80Gbps (plutôt cool pour éviter de saturer les liens avec le stockage).
Avec la réception de ces nouveaux routeurs, on a pu établir un plan de migration à chaud (sans trop de downtime) qui s’est jusque là bien passé. Certaines ressources restent encore à migrer, mais ça viendra !
Les Fabric Extender ont quant à eux pu être totalement décommissionnés (et ça c’est cool).
Mais du coup, comment on a fait pour migrer à chaud 100% de notre infra système (et celle de nos usagers) en causant presque pas de perturbations ?
On a dans un premier temps setup la nouvelle infra réseau en parallèle de l’infra existante (littéralement en parallèle vu qu’on a installé les nouveaux équipements au dessus de la baie), et on a raccordé ce nouvel environnement avec le reste du réseau afin de récupérer l’ensemble des VLANs.
Ensuite on a déplacé un par un les ports des serveurs des anciens switchs vers les nouveaux routeurs. C’était sûrement l’opération la plus longue car il fallait vérifier que les serveurs redevenaient joignables le plus rapidement possible, et pour certains procéder à des changements de configuration afin de pendre en compte VxLAN (et tout ce qui va derrière, on en parlera plus tard).
Enfin, un fois qu’on a pu tout migrer, c’est là que ça devient marrant, parce que les switchs qu’on avait installés au dessus de la baie, bah maintenant il faut les mettre DANS la baie. On a donc dé-racké les anciens switchs, installés les nouveaux rails, et on a déplacé les nouveaux routeurs dans la baie à chaud (sans débrancher quoi que ce soit). Et en vrai, ça s’est super bien passé !
Pour se faire une idée du déploiement des Cisco Fabric Extender avant (ce sont les deux équipements du haut de la baie). Dénués d’intelligence, ils se contentent de tout faire remonter sur les coeurs de réseaux en fibre.
La cohabitation des deux environnements, avec les nouveaux routeurs au dessus de la baie, et la plupart des ports déjà migrés sur les nouveaux routeurs.
Les nouveaux routeurs dans leur emplacement définitif (encore un peu de câble management à faire).
Mais du coup comment ça marche VxLAN chez nous ?
En résumant très grossièrement, le protocole VxLAN se charge d’encapsuler des infos L2 dans des trames L3 en attribuant à chaque hôte L2 qu’il découvre un identifiant VNI (VxLAN Network Identifier) (en gros ça ressemble à des tables de correspondance adresses MAC -> next-hop:id, qui permettent d’indiquer aux autres serveurs comment joindre un hôte).
C’est pas un truc hyper intelligent qui fait le taff tout seul. Afin de distribuer ces VNI sur le réseau, on peut soit tout déclarer à la main sur chaque serveur (aucun intérêt vu qu’on veut un truc qui scale), soit redistribuer ces VNI via BGP en utilisant l’extension BGP EVPN.
Pour cela on va donc configurer des sessions BGP entre les serveurs Proxmox et les nouveaux routeurs, ainsi que des sessions EVPN afin que chaque serveur Proxmox puisse échanger ses infos VxLAN avec les autres serveurs.
Sans rentrer trop dans les détails, grâce à BGP, les serveurs et les routeurs sont en mesure d’échanger le trafic de façon équilibrée, redondée et optimisée. On ne se préoccupe plus du tout du réseau bas niveau comme on le faisait avant avec le L2, le LACP et compagnie.
C’est la fin de ce VLOG sur la rénovation du réseau ! On espère évidemment que ça vous aura intéressé, et on espère revenir rapidement avec la suite !
D’ici là, n’hésitez pas à nous contacter si vous avez des questions concernant OpenGate, l’infra, les projets, etc.
Merci !
Théo
Modifications mineures par Quentin
Cet article a été importé du canal “vlogs” du serveur Discord OpenGate.