Ce que nous faisons · Réseau: Fabric du datacenter : EVPN/VXLAN sur Cisco Nexus
Chez Digital Realty Athens, chaque serveur, châssis de blades, hôte de stockage et firewall client que nous exploitons se connecte à un fabric leaf et spine Cisco Nexus 9000 qui fait tourner BGP EVPN avec VXLAN. Chaque hôte est double-attaché, n'importe quel VLAN peut vivre sur n'importe quel leaf, et votre passerelle porte la même adresse partout : vos charges de travail se déplacent et basculent sans changer d'adresse.
De quoi il s'agit
Un fabric Clos : des spines au sommet, des paires de leaves en dessous, des border leaves qui remettent le trafic routé à nos routeurs de bordure. EVPN est le plan de contrôle : les commutateurs apprennent par BGP où vit chaque adresse, au lieu d'inonder le réseau pour le découvrir. VXLAN transporte chaque segment de niveau 2 à travers le fabric, ce qui signifie que votre réseau n'est pas lié au rack où votre serveur se trouve par hasard.
Comment nous le construisons
- Des spines comme purs route reflectors. Aucun point de terminaison de tunnel ne vit sur les spines, par conception.
- Des leaves en paires vPC. Les serveurs se raccordent par des port-channels LACP qui sont de vrais port-channels virtuels répartis sur les deux commutateurs d'une paire.
- Un câblage de blades déterministe. Les châssis HPE c7000 se raccordent par des extenseurs de fabric Cisco Nexus 2000, un par côté du fabric.
- Des passerelles anycast. Sur chaque leaf.
- Aucune dépendance au multicast. Le trafic de diffusion et le trafic inconnu sont répliqués par BGP ingress replication, ce qui garde l'underlay simple et prévisible.
- Une règle de numérotation appliquée par la machine. L'identifiant VXLAN de chaque segment est dérivé de son VLAN local par une règle fixe, avec des route targets explicites. Un contrôle automatisé lit la carte complète de chaque leaf toutes les heures, confirme que les leaves sont identiques et respectent la règle, et compare une empreinte cryptographique de toute la carte à une référence signée dans le gestionnaire de versions. Toute dérive alerte un ingénieur. Un changement voulu doit être signé à nouveau, de sorte que chaque changement du fabric porte un auteur et une trace d'audit.
- Un routage natif pour les plateformes de conteneurs. Les clusters Kubernetes et OpenShift annoncent leurs adresses de service publiques dans le fabric en eBGP, depuis chaque nœud vers les deux leaves de sa paire, avec BFD pour une détection de panne en moins de deux secondes et des listes de préfixes resserrées sur des routes d'hôte exactes.
- Des bonds qui utilisent les deux liens. Chaque serveur en bond que nous construisons hache sur les couches 3 et 4, avec le côté commutateur réglé à l'identique, de sorte que les flux parallèles se répartissent réellement sur les deux membres.
Ce dont il vous protège
- D'une panne d'un seul commutateur, lien, extenseur de fabric ou carte réseau qui mettrait votre hôte hors ligne.
- D'un identifiant VLAN ou VXLAN mal saisi qui ponterait discrètement les réseaux de deux clients.
- D'une bascule lente, où une adresse publique met des minutes à se déplacer au lieu de secondes.
- D'un ajout de VLAN de routine qui retirerait les VLAN existants d'un trunk en production.
- De payer deux liens et d'en utiliser un seul.
En pratique
Une bascule prouvée par le test. Lors d'un test de panne contrôlé, nous avons redémarré un nœud de cluster de conteneurs pendant qu'il était le chemin préféré d'une adresse publique en production. Le fabric a convergé vers un nœud sain environ trois secondes plus tard, et l'adresse publique n'a jamais quitté la table de routage du fabric.
Un rack de blades câblé avant l'arrivée des blades. Avant le lancement de nouvelles plateformes clients, nous avons construit en un seul lot la topologie complète de port-channels et de vPC d'un rack de blades entier, avant que la plupart des blades n'existent physiquement. Chaque cluster de bases de données a été placé avec chaque réplica dans un châssis différent, de sorte qu'aucun châssis ne peut à lui seul casser le quorum. Le jour du lancement a été une mise sous tension, pas un chantier de câblage.
Les deux liens de chaque bond en service. Après chaque construction en bond, nous lisons les compteurs par port pour prouver que les deux liens portent du trafic.
Pourquoi EuroVPS
- Un vrai fabric EVPN/VXLAN sur Cisco Nexus 9000, la même architecture que celle des grandes entreprises et des opérateurs.
- Le double attachement pour chaque hôte, pas seulement pour les plus chers.
- L'isolation entre clients vérifiée par la machine toutes les heures, contre un enregistrement signé de ce que le fabric doit être.
- Une entrée des conteneurs routée nativement avec BFD, et non greffée sur un unique load balancer.
Questions fréquentes
Mon trafic est-il isolé de celui des autres clients ? Oui. Vos segments portent leurs propres identifiants et route targets, et le contrôle d'intégrité horaire existe précisément pour qu'un pont accidentel entre clients ne puisse pas passer inaperçu.
Que se passe-t-il si un commutateur tombe en panne ? Votre serveur est en bond sur les deux commutateurs d'une paire et votre passerelle existe sur chaque leaf. Le trafic continue sur le commutateur restant.
Puis-je avoir mes propres VLAN et sous-réseaux ? Oui. Les segments dédiés et les sous-réseaux publics sont construits comme des passerelles anycast à travers le fabric, sans toucher à la configuration de qui que ce soit d'autre.
Mon cluster Kubernetes peut-il annoncer ses propres adresses de service ? Oui. Nous mettons chaque nœud en session avec le fabric en eBGP avec BFD, de sorte qu'un nœud en panne est contourné en quelques secondes.
Si vous voulez vos serveurs sur un fabric construit et vérifié ainsi, parlez à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.