Architecture de la plate-forme

Ce thème se concentre sur les principes directeurs et les normes de l'architecture. La pile logicielle et les principaux composants de l'OSS/BSS, ainsi que la "marche des paquets" des appareils virtuels vers le nuage et d'autres destinations sont couverts.

L'architecture Network Edge comprend une pile de matériel, de logiciels et de principes de conception parfaitement adaptés, issus de plusieurs organismes de normalisation et fournisseurs.

Tendances générales et normes

Equinix a construit une plate-forme complète pour le Network Edge basée sur les normes définies par l'ETSI, l'Institut européen des normes de télécommunication. Plus précisément, l'ETSI a créé un groupe de spécification industrielle NFV qui a défini une grande partie du paysage de la virtualisation des fonctions de réseau.

Le cadre NFV de l'ETSI se compose de trois éléments principaux :

• Infrastructure de virtualisation des fonctions du réseau (NFVI) : Un sous-système qui comprend tous les composants matériels (serveurs, stockage et réseau) et logiciels sur lesquels les fonctions de réseau virtuelles (VNF) sont déployées. Cela comprend les ressources de calcul, de stockage et de réseau, ainsi que la couche de virtualisation associée (hyperviseur).
• Gestion et orchestration (MANO) : Sous-système comprenant l'orchestrateur de virtualisation des fonctions de réseau (NFVO), le gestionnaire d'infrastructure virtualisée (VIM) et le gestionnaire de fonctions de réseau virtuel (VNFM).
• Fonctions de réseau virtuel (VNF) : La mise en œuvre logicielle des fonctions de réseau qui sont instanciées sous la forme d'une ou plusieurs machines virtuelles (VM) sur le NFVI.

Sur ce cadre se superposent les systèmes opérationnels et de soutien commercial existants, actuels et nouveaux qu'Equinix a achetés ou construits au fil des ans, ce qui a donné lieu à une architecture normalisée :

Chaque composante comprend plusieurs systèmes, dont certains sont décrits plus en détail ci-dessous.

Le concept de base de la NFV consiste à mettre en œuvre ces fonctions de réseau sous la forme d'un logiciel pur qui s'exécute sur le NFVI. Un VNF est une version virtualisée d'une fonction réseau traditionnelle, comme un routeur ou un pare-feu, mais il peut aussi s'agir d'une action discrète comme NAT ou BGP. Ce concept est radicalement différent de la mise en œuvre du déploiement matériel traditionnel à bien des égards. Le découplage du logiciel et du matériel permet le cycle de vie et le développement de chacune de ces fonctions de réseau dans des cycles distincts. Ce découplage permet un modèle dans lequel les ressources matérielles/infrastructurelles peuvent être partagées entre de nombreuses fonctions réseau logicielles.

La mise en œuvre d'une VNF (comme un routeur virtuel ou un commutateur virtuel) ne modifie généralement pas le comportement fonctionnel essentiel et les interfaces opérationnelles externes d'une fonction de réseau physique (PNF) traditionnelle, comme un routeur traditionnel ou un commutateur.

La VNF peut être mise en œuvre sous la forme d'une machine virtuelle unique, de plusieurs machines virtuelles ou d'une fonction mise en œuvre dans une seule machine virtuelle partagée avec d'autres fonctions.

Architecture et équipement du réseau

C'est dans la composante NFVi de l'architecture que réside la majeure partie du déploiement matériel. Equinix déploie un ensemble complet de nœuds de calcul, de dispositifs de gestion, de commutateurs d'agrégation en haut du rack, de routeurs frontaliers vers d'autres services, de stockage et d'autres aspects qui permettent la mise en œuvre de la suite complète. La profondeur et la taille de chaque déploiement peuvent varier en fonction du marché, des projections, de la capacité et d'autres facteurs.

Nous appelons cette suite complète un point de déploiement (POD). Chaque POD est indépendant de tous les autres POD, même si plusieurs POD sont déployés dans le même métro.

Un POD complet comprend également des commutateurs d'agrégation redondants au sommet du rack et des commutateurs de gestion destinés à un usage interne tel que l'exploitation/le support, la surveillance ou l'orchestration continue de nouveaux actifs.

Au sein du POD, Equinix héberge des machines virtuelles qui exécutent les images logicielles de chaque VNF. Nos VM sont basées sur KVM et l'infrastructure est sur une plateforme Openstack.

Chaque dispositif virtuel est logiquement connecté aux commutateurs d'agrégation et aux plates-formes d'interconnexion situés au-dessus de lui grâce à la technologie VXLAN, et un VPP orchestre le réseau entre eux ainsi qu'à l'intérieur et à l'extérieur du POD :

Le VPP est le logiciel de traitement vectoriel des paquets qui prend des décisions intelligentes en matière de commutation et de routage des paquets. Le VPP transmet le trafic dans les deux sens aux plateformes d'interconnexion Equinix Fabric et EC (Internet) et maintient une redondance complète en cas de défaillance au niveau du POD. Pour plus d'informations sur l'architecture redondante et résiliente, voir Architecting Resiliency.

Architecture système/pile

La suite de gestion et d'orchestration NFV comporte plusieurs composants logiciels clés qui facilitent la plateforme. Cette partie de l'architecture de référence est souvent appelée gestion et orchestration (MANO).

• Gestion de l'infrastructure virtuelle (VIM) - Gère l'instanciation, la configuration, la réservation et d'autres fonctions de calcul, de stockage et d'autres éléments de l'infrastructure traditionnelle.
• Gestionnaire de fonctions de réseau virtuel (VNFM) - Gère le cycle de vie, la surveillance et d'autres activités des dispositifs virtuels actifs. Il exécute le processus de déploiement d'un dispositif, la gestion des modifications et, enfin, le démontage/la suppression des dispositifs.
• Network Functions Virtualization Orchestrator (NFVO) - garantit que les bonnes configurations sont chargées dans les images logicielles, que l'inventaire est récupéré et réservé (comme les adresses IP et les VXLAN), ainsi que d'autres fonctions pour lesquelles une coordination avec d'autres systèmes et OSS/BSS est nécessaire.

Equinix maintient des orchestrateurs redondants dans chaque région. Lorsqu'une demande est faite par l'intermédiaire du portail ou de l'API, elle est transmise à l'orchestrateur concerné qui entame le processus de réservation des ressources, d'inventaire et de sélection d'une configuration et d'une image appropriées pour le dispositif ou le service demandé.

Voici un exemple de flux et d'interaction entre les différents systèmes dans une région spécifique :

Au besoin, l'orchestrateur Network Edge interagit avec l'orchestrateur Equinix Fabric pour coordonner les activités d'activation d'une connexion depuis l'interface d'un VNF vers le cloud ou une autre destination de son choix. Chaque activité consiste à vérifier régulièrement l'inventaire pour voir ce qui est disponible et à réserver de la bande passante, des adresses IP, des VLAN ou d'autres ressources logiques afin qu'elles ne soient pas prises par un autre dispositif de la plateforme.

Equinix propose également une multitude d'outils de gestion et de surveillance internes, dont vous pourrez peut-être voir certains éléments.

Notre suite comprend

• Contrôle

  • Santé et performance des actifs physiques et logiques, tels que l'utilisation de l'unité centrale et de la mémoire vive
  • Vues au niveau du POD des composants et objets actifs physiques et virtuels

• Analyse et rapports

  • L'analyse de l'impact du service pour déterminer les relations entre les différents composants et l'effet de chacun sur l'autre lorsque des changements ou des événements se produisent.
  • Prévision de la capacité POD - permet à nos ingénieurs de savoir à l'avance quand il sera nécessaire d'augmenter les capacités de calcul, le réseau ou d'autres actifs.

• Automatisation

  • Découverte automatique lorsque la capacité est augmentée et ajoutée au POD ou aux liaisons montantes vers d'autres plates-formes, et devient rapidement utilisable.
  • Rapports et réactions sur l'état de santé et les changements au niveau du POD
  • Entièrement intégré au VIM

Stitch It Together : Flux de paquets et de trafic

Network Edge utilise EVPN/VXLAN pour les fonctions des plans de contrôle et de données. L'objectif principal du plan de contrôle de la couche 2 et de l'apprentissage MAC est d'établir la joignabilité de la couche 2 entre le VNF et le routeur CSP respectif. Une fois la connectivité de la couche 2 établie, le peering de la couche 3 peut être établi entre le VNF et son homologue respectif. Par conséquent, seules deux adresses MAC sont apprises dans un seul VNI, car c'est tout ce qui est nécessaire pour la connectivité, alors que de nombreuses adresses MAC sont apprises dans le VTEP (deux pour chaque VNI). La figure suivante montre le flux de données du milieu vers l'extérieur pour établir l'interconnexion des routes.

Le plan de contrôle de l'infrastructure consiste en un EVPN entre le VTEP de calcul et le VTEP Equinix Fabric pour permettre l'apprentissage dynamique des adresses MAC, tandis que VXLAN est utilisé comme plan de données entre les nœuds de calcul et les nœuds Equinix Fabric. En outre, le VNI est mappé au vSwitch du VPP et l'adresse MAC est encapsulée à l'entrée du VPP et étiquetée dans l'exemple ci-dessous avec le VNI de 10.

Avant qu'une session de plan de contrôle superposé entre le cloud privé et le VNF puisse être établie, une autre jambe du plan de contrôle de couche 2 entre la Fabric Equinix et le cloud privé respectif doit exister. Au cours du processus de provisionnement lors de la connexion à un CSP, un VLAN est dynamiquement instancié et connecté au commutateur Equinix Fabric, généralement par le biais d'une connexion .1q. L'adresse MAC du CSP est alors apprise sur ce port trunk .1q, comme indiqué ci-dessous. Dans l'exemple ci-dessous, l'adresse MAC:01B du CSP est apprise sur le port physique du commutateur Equinix Fabric via le VLAN 462. La dernière connexion nécessaire pour achever le plan de contrôle de couche 2 se fait par le biais d'instances de routage (RI) sur le commutateur Equinix Fabric qui forme un lien interne pour la session EVPN. Une fois la dernière étape du plan de contrôle de la couche 2 achevée, le plan de contrôle superposé de la couche 3 pour le peering BGP peut être établi.

L'ensemble de la solution se présente comme suit d'un bout à l'autre :