Pendant un certain temps, je me suis déconnecté lorsque quelqu'un a mentionné SDN. Le terme est devenu tellement omniprésent et cliché qu'il a perdu presque tout son sens pour moi, en tant qu'ingénieur réseau. Mais finalement, après ce qui semble être des années, le SDN commence à sortir du creux de la désillusion et à entrer dans le domaine de la productivité.
Cisco joue un jeu pour la couche d'accès avec un accès défini par logiciel, le marché SD-WAN est en train de devenir une partie permanente du paradigme de mise en réseau, plusieurs fournisseurs ont des plates-formes bien établies pour le centre de données défini par logiciel et l'automatisation du réseau devient juste une autre partie de la boîte à outils de l'ingénieur réseau.
Le SDN, bien qu'il soit parfois un peu ennuyeux à entendre, commence enfin à prendre une forme pratique en dehors du battage médiatique des fournisseurs et de la marketecture.
Au départ, l'idée d'un réseau défini par logiciel consistait à être indépendant du fournisseur, bien que certains fournisseurs aient développé leurs propres contrôleurs SDN à utiliser avec leurs propres appareils. Et puisque SDN semble signifier quelque chose de différent pour tout le monde, je vais m'en tenir à une définition super générique et dire que SDN est l'abstraction d'un réseau dans un logiciel, qu'il s'agisse du plan de contrôle ou du plan de gestion.
La conversation sur le SDN s'est concentrée sur les organisations dotées d'énormes réseaux et leurs problèmes associés. La discussion n'a souvent pas abordé le fait que la plupart des réseaux sont beaucoup plus petits que nos entreprises Web préférées et ont des problèmes différents à résoudre.
Votre hôpital local peut avoir 12 emplacements, 9,000 XNUMX utilisateurs finaux et deux petits centres de données, et bien qu'il ne s'agisse en aucun cas d'un petit magasin familial, les réseaux de cette taille n'ont tout simplement pas le cycle de rafraîchissement de l'infrastructure et du matériel des entreprises Web d'aujourd'hui. Et je crois que ces types de réseaux avec quelques centaines ou quelques milliers de périphériques réseau constituent la plupart des infrastructures réseau sur lesquelles les ingénieurs travaillent aujourd'hui.
Pensez à votre dernier rafraîchissement du matériel projet. Quelle partie du réseau a été remplacée ? Juste la couche d'accès ? Peut-être seulement les routeurs de périphérie ? Et à quelle fréquence remplacez-vous réellement vos commutateurs principaux ?
La plupart des réseaux sont davantage une infrastructure hybride avec à la fois des composants SDN et des appareils hérités.
C'est pourquoi je vois une superposition de gestion indépendante du fournisseur comme le pont entre les réseaux purement hérités et les réseaux SDN purs. La plupart des organisations utilisent un mélange d'équipements hérités qui doivent être gérés un appareil à la fois et d'équipements SDN qui tirent parti des API ouvertes et des contrôleurs SDN.
Par exemple, une organisation peut mettre en œuvre des solutions SDN telles que Cisco ACI ou VMware NSX dans son centre de données, une solution SD-WAN pour ses succursales et adopter l'automatisation du réseau pour extraire des informations des périphériques. Mais il y a toujours les centaines de commutateurs qui ne peuvent pas être remplacés dans le cycle budgétaire de cette année, les pare-feu de l'année dernière qui n'ont pas encore été complètement amortis et les commutateurs centraux vieux de cinq ans qui, franchement, fonctionnent toujours très bien. .
Alors, comment pouvons-nous tirer parti des avantages du SDN, en particulier de la gestion programmatique d'appareils disparates, dans ce type d'infrastructure hybride ?
C'est pourquoi j'aime l'idée d'un outil de gestion de configuration superposé qui peut accueillir plusieurs fournisseurs, plusieurs plates-formes, via plusieurs interfaces. Il s'agit d'une application pratique et pertinente de la mise en réseau définie par logiciel qui donne aux ingénieurs réseau une réelle valeur ajoutée aujourd'hui.
Je ne parle pas de changer la pile réseau sous-jacente, mais de la gestion programmatique des appareils hérités ainsi que les plateformes les plus récentes.
Je parle d'avoir une visibilité et une gestion des appareils qui ne prennent en charge que SNMP, mais aussi des appareils plus récents qui prennent en charge les API ouvertes.
Je parle d'accéder à une interface pour avoir une visibilité sur mes pare-feu, commutateurs et routeurs, quel que soit le fournisseur et qu'il s'agisse du modèle de l'année dernière ou du dernier et meilleur modèle d'aujourd'hui.
Je parle de pouvoir visualiser et gérer mon environnement Cisco ACI dans la même interface que celle que j'utilise pour gérer mes commutateurs principaux, pare-feu et routeurs.
Et puis la prochaine étape serait d'automatiser complètement les flux de travail. Une superposition de gestion centralisée peut lancer automatiquement des diagnostics basés sur les événements, par exemple, via les API SNMP et RESTful. De cette façon, une solution de pont peut fournir plus qu'une simple visibilité et une gestion programmatique, mais un flux de travail complet de tâches automatisées qui existent dans le logiciel et pas seulement dans l'esprit d'un ingénieur réseau.
Cela fait partie de la mise en réseau définie par logiciel, et c'est ainsi qu'elle peut être introduite dans des réseaux réels avec des cycles de vie matériels, plusieurs fournisseurs et des plans de projet pouvant s'étendre sur plusieurs années.
Le SDN est peut-être un cliché, mais une superposition de programmabilité réseau hautement réglable, mature et indépendante du fournisseur ne l'est certainement pas.