Intégrer le « composant logiciel » à la mise en réseau réalisée par logiciel
4 min read
L’une des principales préoccupations que je constate en ce qui a trait à l’intérêt actuel de l’industrie pour la technologie SDN est l’élargissement des horizons de ce que signifie le terme « réalisée par logiciel », et la confusion qu’il cause auprès de mes clients. Comme je l’ai mentionné dans mon billet de blogue précédent, c’est une bonne chose que des clients puissent appliquer la technologie SDN de différentes façons. Toutefois, en raison de cela, certains clients ont de la difficulté à voir les avantages qu’ils pourraient en tirer.
Dans ce billet, je vais traiter de quelques possibilités de la technologie SDN et de la façon dont celle-ci peut être avantageuse pour vos activités quotidiennes. Je vais aussi parler de là où le battage au sujet de cette technologie risque d’excéder vos exigences actuelles.
Dans mon dernier billet, j’ai dit que trois formes principales de la technologie SDN font l’objet de discussions aujourd’hui : la « vraie » technologie SDN fondée sur des normes, les interfaces API exclusives et les réseaux dédiés. Aujourd’hui, je veux examiner les avantages de chacune de ces formes pour votre entreprise.
Un point important à garder en tête est que la technologie SDN a été prévue à titre de « cycle de vie » et non uniquement en tant qu’outil de configuration. L’objectif est que les applications acheminent de l’intention en plus de recevoir de l’information, comme on peut le voir dans ce diagramme de cycle de vie.
Toutefois, la majorité des déploiements de la technologie SDN actuels sont centrés sur la partie inférieure gauche du cycle de vie, utilisant la fonction d’orchestration de services pour programmer le réseau ou pour surmonter les limites que le réseau peut mettre en place. Mais ce n’est qu’une facette de la puissance de la technologie SDN. En permettant à l’application d’établir l’intention et donc d’effectuer l’orchestration, d’utiliser la rétroaction de rendement en temps réel, d’analyser cette rétroaction et de fournir des données utiles aux applications, nous pouvons changer la façon dont les applications et le réseau interagissent.
SDN fondée sur des normes
La technologie SDN d’OpenFlow a amorcé la conversation et constitue encore la forme de SDN la plus anticipée et la plus largement utilisée. La technologie SDN a été conçue pour fournir une nouvelle façon de gérer le trafic acheminé à l’échelle du réseau, ce qui permet aux logiciels de changer les « règles » de transmission des données qui auparavant étaient un ensemble relativement statique de configurations et de politiques figées dans le code intégrées au commutateur lui-même.
Les utilisations de cette technologie sont aussi vastes que votre imagination. Toutefois, les exemples évidents comprennent l’automatisation, la mise en service du nuage, la sélection de voies de transmission, le contrôle des politiques, etc. Seulement, voilà… Une personne doit se charger d’élaborer les règles, politiques et applications avant qu’elles puissent être implémentées. C’est dans ce domaine que les progrès les plus intéressants en matière de technologie SDN surviennent actuellement.
Des outils comme Cisco eXtensible Network Controller ou XNC offrent le cadre de travail SDN pour gérer le réseau et ajoutent des applications clés dont les clients peuvent profiter immédiatement, comme la division d’un réseau en de multiples sous-réseaux ou la fourniture de voies de transmission adaptées sur mesure à l’échelle du réseau et réservées à différentes utilisations.
En outre, nous voyons une intégration directe de la sensibilité au réseau développée pour les applications de l’avenir. Une application pourra éventuellement exiger une bande passante spécifique par transaction, stipuler des exigences précises en matière de latence ou demander un rapport sur l’acheminement de données critiques.
SDN exclusive
Comme je l’ai mentionné dans mon billet précédent, les fournisseurs développent des méthodes exclusives pour configurer le réseau, et ce depuis de nombreuses années (vous vous souviendrez sûrement de notre solution Application-Oriented Network ou AON). Ces capacités fourniront un moyen de profiter de fonctions particulières au fournisseur dans votre réseau, qui ne sont pas prises en charge autrement dans ces normes.
La solution Cisco XNC tire profit de certaines de nos fonctions pour fournir un commutateur matriciel virtuel qui peut recevoir des données de divers ports ou prises de réseau et envoyer des données aux outils d’analyse nécessaires, sans qu’un opérateur ait besoin de configurer chaque commutateur ou appareil sur la voie.
Réseaux dédiés
Enfin, les réseaux dédiés fournissent un moyen d’acheminer une charge de travail n’importe où, n’importe quand. La solution Nexus 1000v InterCloud de Cisco confère la liberté d’acheminer une charge de travail d’un réseau d’entreprise à une infrastructure de nuage public, tout en conservant la politique de réseau du réseau d’origine.
Cela mènera ensuite à des applications dotées de la capacité de demander davantage de ressources et de relocaliser leur charge de travail sans l’intervention d’un opérateur. Bien sûr, les télémesures et les indicateurs de rendement devront être surveillés attentivement et atteints systématiquement avant que cela ne devienne une technique courante.
Simplification nécessaire
Ces outils sont actuellement développés à vitesse grand V et c’est maintenant aux fournisseurs de rendre la technologie SDN accessible. Les solutions actuelles sont complexes et comportent de nombreuses pièces mobiles et c’est ce qui met un frein au déploiement mondial réel de la technologie SDN.
Dans mon prochain billet, je traiterai de la façon dont l’infrastructure centrée sur les applications (Application Centric Infrastructure ou ACI) simplifie considérablement les composants d’intégration réseau et l’application de la technologie SDN.
Participez à la conversation @CiscoCanada ou laissez un commentaire ci-dessous.
Authors
