La Fibre
Datacenter et équipements réseaux => Datacenter => 
Datacenter => Discussion démarrée par: BadMax le 28 octobre 2015 à 11:46:44
-
-snip-, perso j'ai du mal avec le SDN, ça ne me plait pas du tout).
Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.
Si y'a de la demande, je peux en faire un topic dédié.
-
Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.
Si y'a de la demande, je peux en faire un topic dédié.
Oui ça m'intéresse, jusqu'ici je n'ai eu que des présentations d'équipementiers, forcèment orientées avantages et oubliant les risques et contraintes techniques.
-
Si y'a de la demande, je peux en faire un topic dédié.
Je serais intéressé, je n'ai toujours pas bien compris ce qu'était le SDN, par rapport aux commutateurs traditionnels (on pourrait penser que si c'est software, il n'y a plus de matériel, ce qui n'est pas le cas...).
-
Je serais intéressé, je n'ai toujours pas bien compris ce qu'était le SDN, par rapport aux commutateurs traditionnels (on pourrait penser que si c'est software, il n'y a plus de matériel, ce qui n'est pas le cas...).
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.
Leon.
-
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.
Leon.
Pour ceux qui font du système, c'est un peu adapter Puppet/Chef/Capistrano au monde réseau, on déploie les modifications de manière centralisée et le soft gère de pousser les confs de chacun des équipements (mais de manière plus intelligente que juste pousser des confs modifiées en centralisé).
C'est super pratique quand on a beaucoup d'équipements pour déployer très rapidement un service, dans un monde de plus en plus cloud ça devient même parfois indispensable.
Le principal défaut c'est qu'on peut tout aussi vite faire une connerie et qu'un potentiel bug pourrait impacter l'ensemble des équipements également. La solution étant donc d'avoir 2 univers SDN distincts sans interaction, avec les coûts qui peuvent aller avec.
De mon côté la quantité d'équipements ne justifie pas encore d'y passer même si le gain de temps serait non négligeable.
C'est toujours la question de la centralisation VS séparation qui revient sur le tapis au gré des modes. J'ai trop vu de stacks de switchs partir en vrille avec un élèment défaillant dans le pile, ça m'a un peu rendu fermé sur le fait de centraliser le contrôle en réseau. Comme dit au dessus, centraliser ok, mais toujours avec 2 ensembles séparés pour parer au pire des cas.
-
2 univers SDN ? un pour gérer la moitié des switch et le second pour l'autre moitié ?
Si tes serveurs sont connecté sur un seul switch, cela n'apporte rien ou je n'ai pas compris ?
-
Il faut partir du principe qu'on fait de la redondance pour que ça ait un sens c'est sûr. Avoir les serveurs sur 2 switchs ou 2 serveurs redondants sur 2 univers différents.
Chez nous tout est redondé de A à Z, c'est un principe de base.
-
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.
Leon.
Pas tout à fait ou plutot ça dépend des visions.
Chez Cisco, en mode ACI (gamme Nexus 9000 uniquement):
- Si la configuration est centralisée, l'intelligence reste sur tes équipements, voir meme descend jusqu'aux "extrémités", c'est-à-dire qu'il n'y a plus d'équipements avec un role central pour les fonctions de routage par exemple.
- La configuration est gérée par des contrôleurs (APIC en terminologie Cisco), au nombre de 3. Les contrôleurs ne sont pas nécessaire au fonctionnement de la Fabric, ils ne servent qu'à la piloter. 1 seul contrôleur suffit à configurer la Fabric mais le TAC exige 3 contrôleurs.
- S'il y a 3 contrôleurs, c'est qu'il est strictement impossible de configurer un équipement en local, les commandes config sont inaccessibles, il n'y a pas de running-config visible comme sous IOS/NX-OS. On peut néanmoins se connecter en SSH pour faire des "sh int" ou "sh vpc"
- On peut se connecter indépendemment sur l'un des 3, il n'y a aucune différence.
- Les APIC gèrent la configuration mais aussi l'état du réseau : chemins, adresses MAC,... Les APIC voient tout ce qui permet de n'avoir qu'un point d'observation
- Les APIC effectuent beaucoup de contrôles avant de pousser une configuration, ce n'est pas juste mettre un Vlan sur interface, il y a (des tonnes) d'autres choses à faire avant
- On se connecte aux APIC via une interface Web mais on peut les adresser via une API en Python et c'est là où ça déménage : on peut faire des controles en masse (sur la config notamment, vu la complexité des paramètres) et pousser des configurations sur des centaines/milliers d'interfaces. Du fait que les APIC font des controles de config, si un Vlan n'est pas prévu sur un profil d'interface, ça sera bloqué.
- ACI étant récent, il y a pas mal de contraintes et/ou de features non disponibles comme par exemple sur le transit BGP, l'impossibilité d'utiliser des tags de Vlans entre EndPointGroup, le dual-homing des FEX Cisco, etc.
Bon là, comme ça, c'est un très rapide résumé, je ferai un topic dédié pour mieux expliquer. Croyez-moi, en 15 ans de métier où j'ai automatisé beaucoup de taches sur du Cisco, et bien là, il y a vraiment de quoi faire. Le changement entre ACI et avant c'est le travail amont : la 1ère étape de mise en place de la Fabric avec tous les profils nécessaires prend de temps mais ce temps on le gagne après, sur le nombre de changements.
-
Merci pour le résumé :)
- On se connecte aux APIC via une interface Web mais on peut les adresser via une API en Python et c'est là où ça déménage : on peut faire des controles en masse (sur la config notamment, vu la complexité des paramètres) et pousser des configurations sur des centaines/milliers d'interfaces
Quand je lis interface Web et/ou API Python, je me dis nouveaux vecteurs d'attaque et donc mise à jour de sécurité plus nombreuses, donc plus de fenêtre de maintenance et de risques de planter une partie de l'infra... A voir
-
C'est pour cela que tu utilises un réseau "Out-Of-Band" dédié et physiquement séparé :)
Ca reste quand meme du HTTPS avec une auth, API Python ou pas.
Les Nexus "classiques" imposent déjà cela avec leur port Mgmt dédié qu'on utilise pour le keepalive du VPC mais c'est pareil pour les ASR et la plupart des matériels récents chez les autres constructeurs.
-
Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.
Si y'a de la demande, je peux en faire un topic dédié.
Ca serait pas mal de faire un topic sur le sujet, meme si peux de personnes sont concernées.
Pour ma part je n'ai pas conseiller/ implementé le SDN dans les DC, car si ca facilite beaucoup les configs, il y a pas mal de risques, un couillon qui fait une mauvaise config sur le controleur et tu mets a genoux des 100 ene de switch.
-
Ca serait pas mal de faire un topic sur le sujet, meme si peux de personnes sont concernées.
Pour ma part je n'ai pas conseiller/ implementé le SDN dans les DC, car si ca facilite beaucoup les configs, il y a pas mal de risques, un couillon qui fait une mauvaise config sur le controleur et tu mets a genoux des 100 ene de switch.
Par ce que si un couillon plante le contrôleur hard cisco, tu crois que ça va bien se passer ?
-
Par ce que si un couillon plante le contrôleur hard cisco, tu crois que ça va bien se passer ?
Pen si tu le plante il se passera rien, mais si tu propage une mauvaise config tu impacte tout le reseau, enfin je suis pas un expert SDN, mais c'est ce que j'ai cru compendre..
-
Pousser une mauvaise config sur des IOS ou des NX/OS ou des JunOS ou TrucDeLaMortOS ça sera toujours pire qu'avec le SDN.
Parce que le SDN te le dira 1- avant et 2- après aussi car tu as plus de moyen de vérifier ce que tu fais.
-
Ouais, mais dans les centre d'ebergement que je frequante, c'est plutot comme ca que ca se passe...
Une table dans le couloir volée a la caféteria, a coté du montecharge, et des couillons qui reconfigure les Cisco ;)
(http://s16.postimg.org/fqahsoiw5/firwall_config.jpg)
Bon la photo c'était pour le remplacement des firewall et leur reconfig, 3 jours de boulot avec les specialites des différent fournisseurs.
-
Alors qu'avec le SDN ils pourraient travailler dans de bien meilleurs conditions depuis leur bureau, c'est ça le point ?
-
En fait tu peux juste donner des conseils, ensuite c'est l' IT manager qui decide, et comme c'est des financier qui conaissent pas grand chose a la technique ;)
Faut juste prouver que tu génère une economie sur le budget du DC.
-
Dans mon cas, c'est justement l'IT manager qui a demandé du SDN. L'industrialisation est la demande forte du moment (en réseau, système, stockage), le SDN est l'une des "briques" nécessaire.
-
J'ai fais une présentation à des étudiants sur le concept SDN + NFV.
Voici quelques slides :
(https://lafibre.info/images/doc/201510_network_virtualization_sdn_nfv.png) (https://lafibre.info/images/doc/201510_network_virtualization_sdn_nfv.pdf)
Y a plusieurs éléments à comprendre :
SDN Controler
SDN Interface
SDN OS
Y a encore beaucoup de résistance chez les network guy car ils preferent le CLI à l'ancienne :) Mais ça devient de plus en plus une nécessité d'enlever le facteur humain.
-
Par ce que si un couillon plante le contrôleur hard cisco, tu crois que ça va bien se passer ?
Ca se passe déjà quand un tech (de chez ovh) fait une bourde sur un routeur core, ca tombe.. (il y a quelques semaines je crois) ! Le controleur il peut faire du rollback facilement, même si il plante, le trafic n'est pas impacté.
-
J'ai fais une présentation à des étudiants sur le concept SDN + NFV.
Voici quelques slides en PJ.
Y a plusieurs éléments à comprendre :
SDN Controler
SDN Interface
SDN OS
Merci pour cette présentation, c'est intéressant. Ca m'amène plusieurs question.
Dans ta présentation, je lis:
* Réseau classique : Machines aux décisions autonomes
* SDN : Décisions sont prises par un OS centralisé
Qu'est-ce qu'on entend pas OS centralisé?
* Est-ce un OS identique installé dans tous les routeurs / switches? Donc installé sur des centaines d'équipements différents? (Switches/routeurs)
* Est-ce au contraire un OS qui tourne sur 1 ou 2 serveurs centraux, qui ont la responsabilité de tout le "control plane" pour l'ensemble du réseau? Si c'est le cas, BadMax nous disait le contraire ci dessous, donc je ne comprends plus.
- Si la configuration est centralisée, l'intelligence reste sur tes équipements, voir meme descend jusqu'aux "extrémités", c'est-à-dire qu'il n'y a plus d'équipements avec un role central pour les fonctions de routage par exemple.
Peux-tu nous donner des explications sur les planches 6 et 7 de ta présentation? C'est assez abstrait. Pourquoi y a-t-il une différence entre les 2 planches? A quoi correspondent les boiboites?
Merci.
Leon.
-
Merci David pour l'explication !
C'est plus clair avec des slides.
-
Merci pour cette présentation, c'est intéressant. Ca m'amène plusieurs question.
Dans ta présentation, je lis:
* Réseau classique : Machines aux décisions autonomes
* SDN : Décisions sont prises par un OS centralisé
Qu'est-ce qu'on entend pas OS centralisé?
* Est-ce un OS identique installé dans tous les routeurs / switches? Donc installé sur des centaines d'équipements différents? (Switches/routeurs)
* Est-ce au contraire un OS qui tourne sur 1 ou 2 serveurs centraux, qui ont la responsabilité de tout le "control plane" pour l'ensemble du réseau? Si c'est le cas, BadMax nous disait le contraire ci dessous, donc je ne comprends plus.
Il faut bien comprendre que SDN c'est un work in progress. Sachant qu'il y a un réseau existant à manager, il faut être pragmatique sur l'approche.
Il y a plusieurs initiatives ONOS, Open Daylight, Open vSwitch ainsi que les solutions de Cisco, Juniper, ALU(nuage) et autres...
Pour répondre à ta question : OS centralisé, une partie sera installé sur la machine réseau (la partie forwarding) et l'autre (intelligente) sera sur des serveurs centralisés dans un DC ou dans un CORD (CO reconfiguré en Datacenter - Définition de ATT).
A court terme, ca va être difficile d'avoir un OS identique sur chaque machine. A long terme, OS identique (ou compatible) c'est le but.
Il faut avoir conscience que c'est pour les opérateurs une chance de baisser les coûts. (Équipements standards, moins de personnels, etc...)
Peux-tu nous donner des explications sur les planches 6 et 7 de ta présentation? C'est assez abstrait. Pourquoi y a-t-il une différence entre les 2 planches? A quoi correspondent les boiboites?
Merci.
Leon.
Slide 6 et 7
6 (il y a une animation sur le powerpoint)
Actuellement, switch/routeur (les boiboites) sont dotés d'un OS, et d'une couche de forwarding spécialisé (ethernet ou ip) ainsi que des applications qui tournent au dessus, (sécurité, QOS, routage, ...)
On va déporter l’intelligence (OS+APP) vers le nord, sur des serveurs. La partie qui va rester sur les Equipements réseaux est juste la couche forwarding (qui va être simplifié donc moins cher)
7 Entre l'OS et les éléments du réseau, on va avoir des interfaces standards (non propriétaires) comme open flow par exemple. Donc pas besoin d'avoir un routeur X avec un sdn X. tu pourra avoir Routeur Y et sdn Z
Pareil pour la couche nord, avec des API ouvertes. Aujourd’hui, c'est impossible de s'intégrer car les API sont fermées.
Avantage, toi léon, si tu as envie d'innover sur une APP réseau, tu pourra le faire plus facilement (à la manière App-Apple, Google etc..). (Slide 8 ). Pas besoin d'acheter toutes les fonctions du même fournisseur.
-
Merci, c'est clair. Et ça ressemble bien à ce que j'avais compris initialement. L'intelligence (élaboration des tables de routage par exemple) est centralisée, sur des serveurs.
Par contre, c'est vraiment en contradiction avec ce que nous disait BadMax, du coup, je suis perdu, je ne sais plus qui croire.
- Si la configuration est centralisée, l'intelligence reste sur tes équipements, voir meme descend jusqu'aux "extrémités", c'est-à-dire qu'il n'y a plus d'équipements avec un role central pour les fonctions de routage par exemple.
Les gros équipementiers ont énormèment à perdre avec ça. Surtout avec leur système de licence qui ressemble parfois à des arnaques. On voit bien qu'ils essayent de contre-attaquer, avec leurs propres solutions tagguées SDN pas si ouvertes que ça.
Leon.
-
Je ne suis pas sur d'avoir bien compris. On déportes certains fonctions du switch :
- sur les serveurs connectés en aval, sur chaque port du switch
- sur un/des serveur(s) dédiés au SDN, situés en amont du switch
Les buffers sont toujours sur le switch ?
Les règles de priorisation dans le sens montant et descendant sont toujours effectués par le switch ?
-
Merci, c'est clair. Et ça ressemble bien à ce que j'avais compris initialement. L'intelligence (élaboration des tables de routage par exemple) est centralisée, sur des serveurs.
Par contre, c'est vraiment en contradiction avec ce que nous disait BadMax, du coup, je suis perdu, je ne sais plus qui croire.
Leon.
Je ne suis pas en accord avec sa définition. Le SDN c'est pas juste la config centralisée. Ca c'est déjà en place si tu achètes tout d'un seul vendeur. (Alu et ISAM sont très bon pour ca, end-to end provisionning etc..)
Mais il faut que l'intelligence sorte pour que tu puisses utiliser le "scale" du datacenter et non pas de devoir acheter des routeurs de plus en plus gros.
Les gros équipementiers ont énormèment à perdre avec ça. Surtout avec leur système de licence qui ressemble parfois à des arnaques. On voit bien qu'ils essayent de contre-attaquer, avec leurs propres solutions tagguées SDN pas si ouvertes que ça.
Leon.
Tu as tout compris :)
Y a plusieurs visions dans l'industrie, je ne dis pas que la mienne est la bonne :)
-
Je ne suis pas sur d'avoir bien compris. On déportes certains fonctions du switch :
- sur les serveurs connectés en aval, sur chaque port du switch
- sur un/des serveur(s) dédiés au SDN, situés en amont du switch
Les buffers sont toujours sur le switch ?
Les règles de priorisation dans le sens montant et descendant sont toujours effectués par le switch ?
Oui, il y a quand même des choses qui vont rester sur l'équipement. Ca va dépendre des applications que tu veux faire. (Y a de la bonne documentation de Google sur le SDN chez eux)
Une bonne conférence pour comprendre : http://opennetsummit.org/ (US)
Je ne suis pas un spécialiste hardware alors difficile de te répondre en détail.
-
@Leon: Le cas que j'ai commencé à expliquer est l'approche de Cisco : les switches conservent l'intelligence de décision, les contrôleurs ne servent qu'à les configurer.
Attention, c'est une approche particulière car l'ACI de Cisco ne fonctionne qu'avec une gamme spécifique d'équipements (gamme Nexus 9000) et ne sera jamais transposée ailleurs (Nexus 5000/7000) en raison de pré-requis matériels spécifiques. Par contre, l'intégration d'équipements L4-L7 est bien prévue : firewalls (Palo Alto, Checkpoint), load-balancers (F5), hyperviseurs (Hyper-V, VMware) sont intégrables dans ce SDN. D'ailleurs ça se bascule au portillon pour être compliant.
Cisco est allé un peu plus loin que de simplement traiter les couches 1 à 3 du modèle OSI, ils ont souhaité aller plus haut et remonter jusqu'à niveau 7. C'est un SDN qui permet de définir un flux (un Contract) entre 2 machines (des EPG) : le contrôleur va se débrouiller pour configurer toutes les couches nécessaires.
Pour être un peu plus concret, prenons par exemple le routage : chez Cisco, il est traité en périphérie de la Fabric, sur les switches appelés Leafs (=feuilles). BGP, par exemple, y sera alors traité. On est très loin de l'ancien schéma où le routage était porté par les coeurs.
Cette approche est très orienté Datacenter "end-user" (genre une grosse boite) et n'est pas orienté "opérateur" et/ou "hébergeur" comme Online par exemple : ils utilisent des Nexus 9396PX parfaitement compatibles SDN -> l'utilisation qu'en fait Online est incompatible, ils fonctionnent en NX-OS "classique" ! (enfin, je ne vois pas ce que ça apporterait ou alors on change l'archi et encore...)
-
Y a plusieurs visions dans l'industrie, je ne dis pas que la mienne est la bonne :)
+1 le terme SDN est trop "marketing" pour regrouper toutes les propositions du marché sous une même appellation technique.
A cette heure, impossible de dire quelle est la meilleure approche et laquelle va l'emporter.
-
On est d'accord avec ça. Plusieurs visions s'affrontent. Open source vs propriétaire.
Si vous voulez une bonne vidéo neutre :
https://www.youtube.com/watch?v=WabdXYzCAOU
-
Hello,
J'aime pas trop le terme SDN , ce qui est important pour moi c'est OPENFLOW , car c'est la base du SDN , un protocole ouvert qui permet de déplacer l'intelligence du réseau sur des environnements virtuels et qui permet de centraliser les rêgles de routage , d'ACL , QOS etc.
Dans ma société on a le projet de monter un SDN pour la partie QOS notamment pour Skype for business pour être sur que les paquets tagués seront bien acheminés en priorité.
Etant équipés en switch HP , on est évidemment sur la solution SDN d'HP basé sur openflow.
J'aime bien le diagramme pour expliquer le concept dans cette présentation :
https://www.randco.fr/actualites/2014/sdn-et-openflow/
Après le problème c'est d'avoir les bons soft qui permettront d'étendre les capacités du SDN et ça c'est pas encore ça mais ça va arriver très vite !! DEVOPS oblige :)
-
Ben le soucis est que dans un grand DC d'une mutinationale, tu as du matos de différente génération et différente marque.
Juniper, Bluecat, Nexus, Cisco, HP, Checkpoint, Nortel et autres.
C'est impossible de tout remplacer en meme temps quand tu as 200 switchs Cisco, 50 HP, c'est des couts énorme difficilement justifiable,et comme rien on compatible, on garde les anciennes methodes....
Chaque consrtucteur a ses propres spécificiés, switchs, routers, firewall, etc, difficile de tout acheter chez le meme pour garder une compatibilité.
-
et comme rien on compatible, on garde les anciennes methodes....
C'est justement ce qui est en train de changer.
OpenFlow, pas mal de constructeurs commencent à l'implèmenter, et à terme certains standards s'imposeront.
Dans ma boite, les DC sont composés de différents univers; un univers récent a été construit immédiatement avec du SDN pour le cloud interne de la boite (il y a alors de très gros besoins d'industrialisation), les autres sont encore dans des technos classiques.
Mais je ne doute pas que lors du renouvellement d'un univers, en fonction du besoin, on changera suffisamment d'équipements d'un coup pour décider de migrer du même coup en SDN.
Raisonner comme ça, c'est le meilleur moyen de se faire couler à court terme par un concurrent qui va réduire drastiquement ses coûts IT et son time-to-market. A priori, un DSI pas trop à côté de la plaque n'a pas envie que cela puisse arriver, si sa boite est concernée par un tel enjeu.
-
Tu veux parler d'un DSI qui a des couilles ?
J'en connais, mais ce n'est pas les plus courants.
Je suis d'accord avec toi, ceux qui ne bougent pas vont devoir justifier pourquoi la concurrence va faire mieux à moins cher, pour certains ce sera trop tard.
-
Je suis d'accord avec vous , on ne peut pas changer tout d'un coup l'investissement est trop grand par contre lors du renouvellement d'infra il faut réfléchir sur les 5 ans à venir et la , le SDN s'impose sur la couche network , openstack et docker sur la partie virtualisation pour les gros fournisseurs cloud.
Quand je vois ce que fait facebook
https://code.facebook.com/posts/717010588413497/introducing-6-pack-the-first-open-hardware-modular-switch/
Et bien je me dis que les autres ont intérêt à réviser leur gamme de produit !
-
Pour l'instant y'a surtout un gros bullshit-loto-bingo avec tout le monde qui s'affiche avec un logo SDN alors que derrière c'est juste une API REST ou équivalent pour permettre une configuration sans passer par du CLI.
Après y'a la partie "essuyage de platre" qui fait qu'il y a peu de déploiement SDN à grande échelle sur des environnements critiques. 2016 pourrait être l'année du début de la maturité des produits et on pourra faire le tri entre les produits aboutis et les "bullshit-loto-bingo".
-
Je crois qu'il ne faut pas confondre le SDN pour les opérateurs de type WAN et le SDN dans un DC. Ce n'est pas du tout le même environnement. Dans le WAN, y a des Equipements qui ont 10 ans et plus. Il faudra les incorporer, donc une approche hybrid est certainement plus adéquate.
Pour moi open flow c'est aussi du bullshit-loto-bingo :) C'est juste un protocol comme netconf. Pas sur que OpenFlow sortira gagnant dans le WAN. Dans le DC, je ne suis pas assez connaisseur.
Je vous conseil la présentation de Javier sur l'architecture de Colt : http://fr.slideshare.net/ColtTechnologyServices/colts-sdnnfv-evolution
-
Pour moi open flow c'est aussi du bullshit-loto-bingo :) C'est juste un protocol comme netconf.
Ah bon? Je ne m'y connais pas forcèment bien dans le détail, mais j'avais compris qu'Openflow allait beaucoup plus loin que netconf, et offrait beaucoup plus de possibilité que juste la "configuration à distance". Je me trompe?
Les 2 ne seraient-ils pas complèmentaires?
http://blog.ipspace.net/2012/06/we-need-both-openflow-and-netconf.html
Leon.
-
Je suis d'accord avec toi léon, on a besoin de openflow, mais aussi d'utiliser les netconf, CLI et autres protocoles south band si l'on veut pas faire partir de 0. Je disais juste que je ne suis pas sur que Openflow soit le protocole qui sortira vainqueur en bout de ligne, du moins dans sa version actuelle comme l'unique protocole pour le SDN.
-
En même temps, ça pourrait "couter la tête" de ces offres techniques OpenFlow/NetConf s'il n'y a pas un standard qui èmerge rapidement avec une API commune : beaucoup d'entreprises avec des DC privés veulent évoluer vers du Cloud privé en s'appuyant sur ce type de brique. Mais le message a encore du mal à passer : quels matériels acheter ? comment je rétrofite l'existant ? sur quoi je forme les équipes ?
C'est compliqué, le message n'est pas clair, certains insistent sur la virtualisation, d'autres sur l'industrialisation alors qu'en fait, le vrai problème pour les entreprises, c'est juste de pouvoir accélérer la vitesse de leurs changements et/ou réduire les coûts d'exploitation. Même les intégrateurs ont du mal à suivre : leurs équipes ont toujours travaillé à "juste" mettre en place une infra alors que le SDN remet en question les process internes. Plus de cloisonnement par équipe, plus de configuration "à la mimine".
-
Un petit posdcast pour ceux qui sont intéressé par le sujet:
http://www.nolimitsecu.fr/sdn/ (http://www.nolimitsecu.fr/sdn/)
-
Bonjour à tous, je me permet de déterrer ce sujet.
Ma réflexion : un des aspect du SDN, c'est de déporter le maximum d'intelligence de routage dans la périphérie du réseau, et de réaliser ces opérations de routage complexes de périphérie en software, directement dans les serveurs, voire carrèment dans des serveurs virtualisés.
A priori, ça apporte plus de flexibilité, c'est très adapté aux architectures "virtualisées", et puis ça fait des architectures réseaux "scalables".
Mais qu'en est-il de la consommation électrique?
Les opérations de routage consomment sans doute beaucoup plus en software que dans des routeurs physiques. Dans les routeurs physiques "haut de gamme", il y a énormèment d'accélération hardware, et les paquets sont manipulés par des processeurs/ASIC dédiés, même pour les opérations complexes.
Quand on parle de gros réseaux dans des datacenters, on parle de débits énormes, car le débit échangé entre les serveurs eux mêmes est parfois monstrueux. Et puis en faisant ce type de SDN, le nombre de "routeurs" explose, avec tous ces routeurs virtualisés.
Du coup, est-ce qu'on connait l'impact du SDN sur la consommation électrique, dans de grosses architectures? Est-ce que cet aspect n'est pas un frein sur le déploiement du SDN (au moins l'aspect routage en bordure par soft) dans de grosses architectures?
Leon.
-
Ce qui est sur, c'est que les routeurs avec accélération hardware consomment eux aussi beaucoup d'énergie, plus de 6000 watts de consommation réel, pour un routeur qui prend 1/2 baie rempli de cartes avec les ports actifs.
-
Ce qui est sur, c'est que les routeurs avec accélération hardware consomment eux aussi beaucoup d'énergie, plus de 6000 watts de consommation réel, pour un routeur qui prend 1/2 baie rempli de cartes avec les ports actifs.
Ok Vivien,
Mais on parle de très très gros routeur, je pense qu'il est impossible de faire l'équivalent en software pur!
Et je pense aussi que faire l'équivalent en software consommerai encore plus d'électricité!
De toutes façon, l'objectif du SDN n'est pas de supprimer ces gros routeurs, c'est juste de les rendre moins intelligents (ne plus leur faire faire les taches complexes) et beaucoup moins chers.
Leon.
-
Pas certain que les opérations de routage augmentent la consommation cpu d'un serveur à ce point: seule la prise de décision du routage du premier paquet entre A et B est consommatrice, le reste c'est du switching.
Je dirais que c'est donc plus le côté bande passante qui rentre en ligne de compte : avec du 40Gb on a tôt fait de remplir quelques lignes PCI-Ex.
Enfin Intel a pondu DPDK qui permet de décharger outrageusement pas mal d'opérations du CPU vers les chipsets network.
Avantage du SDN: c'est plus facile à scaler quand le nombre de routes (des /32 ou /128 par exemple) commence à exploser là où les ASIC coincent rapidement.
Je dirai donc que le SDN permet de décharger des opérations ´Core ´ vers la périphérie ´Leaf ´ (pour faire un Loto). Au global, on s'y retrouve sur le plan fonctionnel (plus souple et facile à gérer) et on peut limiter la consommation en équilibrant intelligemment la charge.
-
OK, merci BadMax
Pas certain que les opérations de routage augmentent la consommation cpu d'un serveur à ce point: seule la prise de décision du routage du premier paquet entre A et B est consommatrice, le reste c'est du switching.
OK, mais par exemple encapsuler des trames dans un tunnel, ça prend de la ressource CPU, alors que les routeurs haut de gamme le font en hardware.
Leon.
-
À quel genre de tunnel tu penses ? Je ne vois pas trop de besoin en tunnel à gérer ailleurs qu'en périphérie, là où IPsec règne en maître. Avec les extensions AES-NI, y'a de quoi soutenir de sacrés débits sur un serveur.
-
drap
-
Tin' on peut plus être tranquille :D
XaT
-
Vous connaissez des sociétés qui ont mis en place ONOS par exemple ?
Merci :)