Retour

Un voyage dans le passé : des réseaux traditionnels au SDN

by Paul Campbell Le 26 novembre 2018

Saviez-vous que vous pouviez améliorer votre jeu en tirant parti NetBrain faire plus que simplement fournir une carte de topologie de réseau cool pour impressionner vos amis et collègues ? Parlons maintenant de quelque chose de plus spécifique : les stratégies SDN ne sont bonnes que si ceux qui en comprennent les fondements.

Je sais, je sais, j'entends certains d'entre vous se moquer - et ai-je juste eu un roulement d'yeux? Paul, l'intérêt du SDN est que nous obtenons un seul volet de gestion et une interface graphique qui fait disparaître la complexité. Vous savez quoi, vous avez raison ! Mais que faites-vous si quelque chose ne fonctionne pas comme prévu ?

Radia Perlman nous a apporté le protocole Spanning Tree (STP) en 1985 pour nous aider à résoudre tous nos problèmes de commutation. C'est un excellent protocole qui a fait des merveilles, mais les réseaux ont-ils encore connu des pannes ? Les réseaux ont-ils parfois eu ces pannes à cause du protocole même qui était censé éviter les problèmes ? Oui et oui. Cependant, comme l'expression souvent utilisée pour le plus grand bien, vous devez regarder les avantages plutôt que les inconvénients.

Présentation en une minute de NetBrainGestion SDN de 

 

Si vous avez été dans le centre de données pendant un certain temps au cours des 10 dernières années et plus, vous avez fait l'expérience d'une formation croisée - que la formation croisée soit spécifique et ciblée ou par le biais de votre routine quotidienne d'interaction avec une autre équipe. Vous avez probablement approfondi vos connaissances sur les structures SAN, même si vous ne le vouliez pas. Vous avez dû en savoir plus sur la virtualisation afin de mieux résoudre les problèmes. Les hyperviseurs, les contrôleurs, les commutateurs virtuels et les cartes réseau virtuelles n'étaient pas de votre ressort, mais ils devaient l'être. Apprendre toutes ces choses vous aide à devenir un ingénieur en forme de «T» bien arrondi qui connaît un ou deux sujets comme un pro, mais vous avez un large éventail de connaissances pour couvrir le gambit. Il est devenu impératif que vous ne soyez plus un ingénieur en forme de « I » qui se concentre uniquement sur un seul sujet ; on pourrait dire que cela fait de vous un dinosaure sur le marché et la communauté d'aujourd'hui.

Apprendre toutes ces choses vous aide à devenir un ingénieur en forme de «T» bien arrondi qui connaît un ou deux sujets comme un pro, mais vous avez un large éventail de connaissances pour couvrir le pari.

Par exemple, regardez toutes les choses héritées que vous avez apprises et comment vous les avez appliquées au réseau moderne de Software-Defined Networking (SDN). Oui, vous pouvez vous enliser avec ce qui ressemble à un albatros d'un processus pour convertir l'ensemble de votre environnement en paradis de la sécurité micro-segmenté sur liste blanche - ou vous pouvez regarder la fondation et faire le voyage simplement. La plupart des environnements qui ont déployé le SDN ont commencé dans une émulation de topologies de réseau héritées. Cette conversion héritée vous permet de modéliser de nouveaux modèles SDN autour des limites VLAN héritées pour plus de familiarité. Vous pouvez convertir votre environnement existant en une structure SDN et conserver toute la nomenclature et les fonctionnalités héritées tout en travaillant à l'innovation future. L'avantage de ce concept est qu'une fois que votre environnement est implémenté avec une superposition SDN, il est beaucoup plus facile de "déplacer" les charges de travail que par le passé, car vous pouvez changer de vNIC avec l'intégration de l'hyperviseur et modifier la posture de sécurité de l'adressage IP, et accéder dynamiquement aux contrôles. Ai-je mentionné que le routage et la commutation entrent toujours en jeu ? Au fur et à mesure que vous vous intégrez à vos fournisseurs de services ou à votre WAN, vous aurez toujours besoin de connaître OSPF, BGP, STP, etc., pour vous assurer que votre réseau interagit de manière appropriée.

Je souhaite sincèrement à tous ceux qui liront ceci de déployer une solution SDN et de ne jamais avoir de problème. Mais si vous rencontrez un problème, comment comptez-vous le résoudre en plus de rappeler l'OEM et d'ouvrir un dossier d'assistance ?

Services Connexes