2017-08-17 8:51 GMT+02:00 Xavier Beaudouin <[email protected]>: > Ceci dit, attention à l'eugénisme software si on veux pas avoir les mêmes > emmerdes futures comme le leap seconds qui ont foutu la grouille avec les > Java et Linux. > > Ha ben là c'est trop tard :-( Il suffit de regarder le choix des technos utilisés dans les contrôleurs SDN pour s'apercevoir que ces solutions ont été pensées par le stagiaire Web 2.0 qui n'avais pas grande notion des technos télécoms/réseau ni de la sécurité.
Exemple avec Juniper Contrail [1]: 1. Ils ne savaient pas ce qu'était BGP alors ils ont utilisé du XMPP à la place. 2. Ils ne connaissaient pas les fichiers textes pour stocker la configuration, alors ils ont déployé du Cassandra, oui le truc pour du big data pour stocker la configuration de leur solution. Et comme cette base était aussi utilisée pour collecter l'ensemble des netflows de la plateforme, ben il suffisait qu'un client sur la plateforme génère un gros nombre de flux (style un serveur DNS) pour remplir la base et bloquer l'ensemble. :-) 3. Ils s’obstinent a vouloir que les VMs partagent le même domaine de broadcast de niveau 2 entre-elles (on devrait leur expliquer que les applis sont essentiellement en IP), donc ils utilisent des technos d'overlay de VLAN (VXLAN ou autre). Va falloir leur expliquer que pour le cloisonnement large-scale, MPLS a fait ses preuves et que la mise au point d'un MPLS-over-Ethernet (et pas over-GRE ou over-UDP) aurait peut-être était plus judicieux et surtout plus simple? Le seul intérêt potentiel que je vois a garantir ce domaine de broadcast de niveau 2, est pour le VM-motion entre différents DC (garder la même MAC/IP de la VM). Mais le VM-motion n'est utile que dans un cas très particulier: Le déplacement d'applications interactives (style serveur TSE ou gateway VoIP) qui ne permettent pas de simplement démarrer une nouvelle instance et d'éteindre l'ancienne instance de façon transparente pour l'utilisateur. C'est quand même très limité comme cas pour toute cette complexité. 4. Pour la gestion des configurations, c'est du NETCONF qui est utilisé… le truc tellement simple qu'il faut plus de 35 RFC pour l'expliquer. Comment cela se fait qu'il existe depuis longtemps de nombreuses solutions de gestion de configuration des serveurs, qui pourtant sont beaucoup plus compliqués à gérer qu'un routeur/switch, et qu'aucune de ces solutions n'ait été réutilisée ici ? 5. À la place de netflow ils utilisent du Sandesh, ben oui c'est plus simple de tout mettre dans du XML; 6. Ils ont découvert l'existence d'IPv6 très très tard; 7. Le tout est validé pour fonctionner sur de l'Ubuntu, car le stagiaire n'avait que cela sur son poste ? 8. Et ne pas oublier que comme c'est du réseau, c'est à faire installer/administrer/débugger par vos équipes réseaux… sauf que bien sûr vous n'avez pas pensé à la leur reconversion professionnelle en devops (compter 6-mois minimum). ATT semble être l'unique exception sur ce sujet [2]. Ailleurs (dans les grosses boites de taille identique) je ne suis pas sur que ce soit le cas. Donc pourquoi les opérateurs font du SDN ? Car Gartner a dit que c'était l'avenir, donc il faut rapidement sortir une offre comme les concurrents, même si on a aucune idée de ce que cela va donner. Les solutions actuelles sont d'une complexité hallucinante et tombent miraculeusement en marche. Je ne souhaite pas être dans le coin le jour ou il faudra déboguer cette usine à gaz: L'empilement énorme des différentes technologies rend ingérables ces solutions. Il n'y a qu'a regarder la figure n°1 (page 9) de la doc Juniper qui se permet de résumer OpenStack à un seul bloc pour avoir un aperçu de l'ensemble. J'aurais bien aimé calculer le nombre de ligne de code de l'ensemble des éléments d'une solution complète pour rigoler ainsi que le nombre de technos/langages différents utilisés. Au final c'est quand même positif: enfin les équipes réseau vont, forcées, découvrir l'ensemble des technos matures (et en majorité open source) utilisées par les équipes devops et du coup cela permettra d'accélérer des sujets comme l'automatisation des configurations, tests de régression et intégration continue, d'envisager d'utiliser des solutions à base de x86 pour remplacer des routeurs Cisco/Juniper et de tester des switchs ONIE. Olivier [1] http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf [2] https://networkingexchangeblog.att.com/wp-content/uploads/2017/ 04/ATT-Tech-Dev-Transformation-Whitepaper-FINAL.pdf --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
