Chaque locataire isolé sur une seule fabric GPU partagée.
Une fabric de centre de données multi-locataire maintient chaque locataire isolé sur des commutateurs et des pods GPU partagés, chacun dans sa propre VRF et VXLAN VNIs. Lorsque des locataires ont besoin d'un service partagé, la fuite de routes inter-VRF sur VXLAN-EVPN n'ouvre que les préfixes que vous autorisez. IP Infusion le fournit comme un système unique : des commutateurs ouverts validés exécutant OcNOS-DC, supported under one contract.
Un système validé, avec l'isolation intégrée.
IP Infusion valide le commutateur complet sur 18 plateformes data center ouvertes, précharge OcNOS-DC et le prend en charge sous un seul contrat. L'isolation par locataire est une capacité validée de ce système, répertoriée dans la matrice de fonctionnalités OcNOS, et non un module complémentaire à assembler vous-même.
18 plateformes data center validées
Chaque commutateur leaf, spine et border est qualifié en laboratoire par stepping d'ASIC avec OcNOS-DC préchargé : la fabric que vous concevez est celle qui est livrée.
VRF et VNI par locataire dans la matrice
La VRF par locataire, les VNI de couche 2 et de couche 3, la passerelle anycast et la fuite de routes inter-VRF sont chacun associés aux plateformes qui les prennent en charge.
Un seul système, un seul contrat de support
Une seule équipe est responsable de la le logiciel, le commutateur et le RMA, et vous continuez à renouveler le matériel et OcNOS-DC selon des cycles indépendants.
Un historique solide derrière le système. IP Infusion livre des systèmes réseau de production depuis 1999, et OcNOS fonctionne en production chez plus de 600 opérateurs dans plus de 60 pays, de sorte que la fabric multi-locataires arrive comme un système complet fort d'un long historique sur le terrain.
Choisissez un locataire et voyez son couloir s'allumer.
Trois locataires partagent les mêmes leaves et pods GPU. Sélectionnez-en un pour voir sa VRF, ses VNI de couche 2 et de couche 3, et l'unique chemin de fuite de routes qui atteint un service partagé.
Locataire A. Le locataire A fonctionne dans la VRF-A sur le VNI L2 10010 et le VNI L3 50010, et atteint la même passerelle anycast distribuée sur chaque leaf. Il partage les leaves, le spine et les pods GPU avec les locataires B et C, tout en restant isolé des deux, car son trafic est encapsulé par VNI et routé dans sa propre VRF.
Locataire A. Le locataire A fonctionne dans la VRF-A sur le VNI L2 10010 et le VNI L3 50010, et atteint la même passerelle anycast distribuée sur chaque leaf. Il partage les leaves, le spine et les pods GPU avec les locataires B et C, tout en restant isolé des deux, car son trafic est encapsulé par VNI et routé dans sa propre VRF. Locataire B. Le locataire B partage les mêmes leaves, spine et pods GPU que les autres, mais son trafic ne se mélange jamais à celui du locataire A ou du locataire C. Il fonctionne dans la VRF-B sur le VNI L2 10020 et le VNI L3 50020 : c'est une VRF distincte, sur ses propres VNI, au sein de la fabric partagée. Locataire C, services partagés. Le locataire C fonctionne dans la VRF-C sur le VNI L2 10030 et le VNI L3 50030 et héberge des services partagés tels que le stockage et un réseau de gestion. Les autres locataires ne l'atteignent que par une fuite de routes inter-VRF explicite qui ne transporte que les préfixes autorisés. Fuite de routes inter-VRF, de A vers C. Un chemin explicite transporte uniquement les préfixes autorisés du locataire A vers la VRF de services partagés du locataire C : le locataire A atteint le service partagé tandis que tout le reste demeure isolé. Aucun autre chemin entre locataires n'est tracé, car l'isolation est le comportement par défaut.Sélectionnez un locataire pour allumer son couloir, et activez la fuite pour voir l'unique chemin autorisé. Survolez un nœud pour afficher le détail.
Quatre éléments séparent les locataires.
Chaque locataire dispose de sa propre VRF et de ses propres VNI, de sorte que son trafic est encapsulé et routé séparément de celui de tous les autres locataires. Une passerelle anycast distribuée donne à chaque locataire la même passerelle sur n'importe quel leaf, et le multihoming EVPN maintient un locataire connecté en cas de panne d'une liaison ou d'un leaf.
Une table de routage privée par locataire
Vous attribuez à chaque locataire sa propre VRF, de sorte que sa table de routage reste séparée de celle de tous les autres locataires sur la fabric partagée. L'isolation est la règle par défaut, et atteindre un autre locataire exige une fuite de routes explicite que vous configurez.
Chaque locataire encapsulé sur ses propres VNI
Chaque locataire traverse la fabric avec ses propres identifiants : un VNI de couche 2 transporte son trafic ponté et un VNI de couche 3 transporte son trafic routé, en utilisant la route de préfixe pour l'EVPN IRB, de sorte que deux locataires ne partagent jamais une encapsulation sur les commutateurs partagés.
La même passerelle sur chaque leaf
Chaque leaf présente la même IP et même MAC de passerelle pour le sous-réseau d'un locataire, de sorte qu'une charge de travail est toujours à un saut de sa passerelle et conserve sa route par défaut lorsqu'elle se déplace entre leaves ou pods.
Un locataire reste actif en cas de panne d'un leaf
Multihoming EVPN de couche 2 pour VXLAN raccorde un locataire à deux leaves ou plus en mode actif-actif via un Ethernet Segment : les deux liaisons transmettent et une panne de leaf est transparente pour ce locataire.
Cette solution s'appuie sur la fabric leaf-spine EVPN-VXLAN de base. Consultez la page fabric data center pour voir comment s'articulent les leaves, les spines et l'underlay →
Partager un service entre locataires, de façon délibérée.
L'isolation est la règle par défaut : aucun locataire n'en atteint un autre sans votre autorisation. La fuite de routes inter-VRF sur VXLAN-EVPN ne laisse passer entre deux VRF de locataires que les préfixes précis que vous autorisez, de sorte qu'un service partagé comme le stockage ou un réseau de gestion est accessible tandis que le reste de chaque locataire reste privé.
Ne faire fuiter que les préfixes que vous désignez
Avec la fuite de routes inter-VRF pour les VRF définies par l'utilisateur, vous annoncez un ensemble nommé de préfixes d'une VRF de locataire vers une autre : seul ce service est accessible et chaque chemin entre locataires est un chemin que vous avez configuré.
Elle s'exécute sur l'overlay VXLAN-EVPN lui-même, ce qui maintient la fuite dans l'overlay existant.
Stockage et services partagés
Placez un service partagé, comme le stockage ou un réseau de gestion dans sa propre VRF, et ne faites fuiter ses préfixes que vers les locataires autorisés à l'atteindre : les locataires partagent le service sans s'atteindre entre eux.
Les mêmes commutateurs ouverts exécutent aussi l'ensemble RoCEv2 sans perte pour le trafic GPU, détaillé sur la page fabric IA.
Conçu pour les opérateurs neocloud et souverains.
Les opérateurs neocloud et souverains exploitent de nombreux locataires sur du matériel GPU et de calcul partagé, et veulent que chaque locataire soit isolé et que leurs achats ne dépendent pas d'un fournisseur unique. Une fabric multi-locataires ouverte leur apporte les deux : l'isolation par locataire sur des commutateurs à silicon marchand de plusieurs fournisseurs, livrée et prise en charge comme un seul système.
Matériel ouvert multifournisseur
La fabric fonctionne sur des commutateurs ouverts à silicon marchand de plusieurs fournisseurs de matériel, de sorte que vos achats ne sont pas liés à un fournisseur unique.
Un seul fournisseur responsable de tout le système
IP Infusion valide et prend en charge le commutateur, OcNOS-DC et le RMA comme un seul système, de sorte qu'un seul fournisseur est responsable de la fabric intégrée.
Renouvellement selon des cycles indépendants
Vous renouvelez le commutateur et OcNOS-DC selon des cycles indépendants, de sorte qu'un renouvellement matériel et une mise à niveau logicielle sont des décisions distinctes.
Des achats sans dépendance propriétaire
Comme le matériel est ouvert et que le logiciel est portable d'une plateforme à l'autre, vous évitez la dépendance propriétaire tout en conservant une seule relation de support.
Commutateurs validés pour la fabric multi-locataires.
IP Infusion fournit la fabric sur 18 plateformes data center validées d'Edgecore et UfiSpace, chacune qualifiée en laboratoire par plateforme avec OcNOS-DC préchargé. Les leaves raccordent les locataires et hébergent la passerelle anycast, les spines portent l'underlay, et un commutateur border remet les préfixes des locataires vers l'extérieur.
| Rôle | Commutateur validé | Silicon et capacité | Pourquoi cela convient au rôle |
|---|---|---|---|
| Leaf : raccordement des locataires et VTEP | Edgecore AS9726-32DB / UfiSpace S9300-32D | Broadcom Trident 4, 12,8 Tbps, 400G | Là où les locataires se raccordent : le VTEP, la VRF et les VNI par locataire, la passerelle anycast distribuée et le multihoming EVPN. |
| Spine : underlay et réflexion de routes | Edgecore AS9736-64D | Broadcom Tomahawk 4, 25,6 Tbps, 400G | Porte l'underlay de tous les locataires avec l'ECMP d'overlay et la réflexion de routes EVPN ; il ne porte aucune extrémité de tunnel, de sorte que tout l'état par locataire reste sur les leaves. |
| Spine / super-spine (800G) | Edgecore AIS800-64D / UfiSpace S9321-64E | Broadcom Tomahawk 5, 51,2 Tbps, 800G | Scale-out 800G pour les plus grandes fabrics partagées. L'AIS800-64D utilise des optiques QSFP-DD800. |
| Border : remise externe des préfixes de locataires | UfiSpace S9321-64EO | Broadcom Tomahawk 5, 51,2 Tbps, 800G plus ZR+ | Remet les préfixes de chaque locataire vers l'extérieur et allume directement une longueur d'onde d'interconnexion avec des optiques enfichables cohérentes ZR+. |
| Leaf 100G / ToR | Edgecore AS7726-32X / UfiSpace S9110-32X | Broadcom Trident 3, 3,2 Tbps, 100G | Raccordement des locataires au niveau accès pour les racks de serveurs et de pods 25G et 100G. |
18 plateformes data center validées. Consultez toutes les plateformes validées dans la liste de compatibilité matérielle, et faites correspondre les fonctionnalités au matériel dans la matrice de fonctionnalités.
Quel commutateur pour quel rôle de locataire
- Leaf, raccordement des locataires. Placez les leaves côté locataires sur des Trident 4 400G pour le VTEP, la VRF et les VNI par locataire, la passerelle anycast et le multihoming EVPN, ou sur un leaf Trident 3 100G pour les racks 25G et 100G.
- Spine, underlay et réflexion de routes. Placez les spines sur des Tomahawk 4 400G, ou sur des Tomahawk 5 800G lorsque la fabric partagée s'élargit, et ajoutez des spines plutôt que de toucher aux leaves.
- Border, remise externe. Utilisez le S9321-64EO pour remettre les préfixes de chaque locataire vers l'extérieur et, lorsqu'un locataire s'étend sur plusieurs sites, pour allumer directement la longueur d'onde d'interconnexion.
- Un seul contrat. IP Infusion valide et prend en charge chaque rôle comme un seul système, et le commutateur et OcNOS-DC se renouvellent sur des cycles indépendants.
Solution brief et fiche technique.
Le brief sur la fabric EVPN-VXLAN et la fiche technique OcNOS-DC à partager avec votre équipe. Formulaire court, et le PDF se télécharge immédiatement.
Fabric DC EVPN-VXLAN
Comment la fabric isole les locataires : VRF par locataire, VNI de couche 2 et de couche 3, et fuite inter-VRF contrôlée sur des commutateurs ouverts.
Obtenir le briefDatasheet OcNOS-DC
La vue d'ensemble OcNOS-DC : l'ensemble des fonctionnalités de fabric, le matériel de centre de données validé et l'exploitation, dans un seul PDF.
Obtenir la fiche techniqueQuestions sur l'isolation des locataires.
Concevez votre fabric multi-locataires.
Découvrez comment IP Infusion livre la fabric multi-locataires comme un seul système, ou contactez-nous pour associer vos locataires, services partagés et plateformes aux commutateurs validés adaptés.
Fabric DC EVPN-VXLAN
Formulaire court. votre PDF se télécharge immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet.
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
Datasheet OcNOS-DC
Formulaire court. votre PDF se télécharge immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet.
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
À lire aussi sur le blog
ECMP overlay dans une fabric EVPN-VXLAN Leaf-Spine, Partie 1
Comment l'ECMP d'overlay EVPN-VXLAN répartit la charge du trafic des locataires sur une fabric leaf-spine Clos
Lire l'article →ECMP overlay dans une fabric EVPN-VXLAN Leaf-Spine, Partie 2
La deuxième partie du guide sur l'ECMP d'overlay EVPN-VXLAN pour la fabric partagée
Lire l'article →