De la modélisation au day 2 | Arnaud Le Gall, HPE Aruba Networking

[musique] [musique]

Bien, bonjour à tous. Euh donc Carno Legal, je suis alors ingénieur consultant système. En gros, je suis avant vente euh pour HPE alors qu'on dit on dit HP networking maintenant depuis depuis quelques mois. Euh et donc dans cette partie donc je pour information je suis accompagné également d'Olivier Fort qui est mon pendant sur la sur la région. Euh donc moi je suis effectivement plus global hein. Je toute la partie switching, la partie automatisation mais je suis pas affecté à des comptes une région. Euh donc je suis voilà j'aide de tous mes petits collègues de l'équipe avant envente France sur ces sujets-là.

Euh donc dans cette partie de la session en fait c'était c'est toujours un peu compliqué quand on est constructeur de devoir faire quelque chose sur la partie source de vérité. Alors, source de vérité, source de confiance, enfin tout dépend comment vous voulez l'appeler. Euh puisque'effectivement, je pense que par rapport à aux intégrateurs, aux éditeurs, aux clients, on est peut-être les moins impactés par notion de source de vérité parce qu'on a logiquement une source de vérité sans être agnostique euh et donc pas euh enfin affilié entre guillemets à une euh un constructeur particulier. Donc chaque constructeur va avoir aussi ses solutions, hein.

Si je parle pour nous par exemple depuis quelqu on a on a abstrat euh dans le portfolio qui est une solution d'intent pour le data center. Et donc du coup ben devant tout ça en fait, j'ai préféré faire une sorte de retour d'expérience euh autour des projets qu'on a pu voir nous en tant que constructeur d'un point de vue constructeur.

de la partie modélisation jusqu'à la partie day to et comment effectivement les clients qu'on a pu voir qui sont accompagnés par les différents partenaires qui ont travaille ont pu justement adapter ces ces notions de source de vérité dans leur dans le dans leur workflow par OK alors donc déjà à quoi va nous servir la source de confiance bon ça je pense que vous l'avez pas près compris tout ce qui a été vu déjà sur les trois premières sessions. L'idée effectivement c'est effectivement de partir un data modeling.

Donc data modeling, vous avez bien compris, c'est effectivement comment je vais modéliser mes données, mes informations que je vais utiliser dans mes différentes configurations, dans mes snipet au fur et à mesure comment je vais modéliser ça dans la source de variété. Le deuxième étape qu'on va avoir, c'est la notion d'insertion de la donnée. Donc l'insertion de la donnée, en fait, on va avoir deux étapes, enfin deux façons de faire. En tout cas, nous ce qu'on a pu observer, c'est effectivement partir sur une sorte de green field. Donc ça effectivement chaque client ou intégrateur enfin partenaire va trouver des workflow plus ou moins avancés pour pouvoir aller récupérer l'information.

Généralement il va faire une instionation manuelle dans ses workflow pour aller derrière populer la base OD la la partie source de vérité. L'autre élément qu'on a vu, c'est une notion un peu de bronfield. Donc ça c'est un use case que je verrai un tout petit peu plus tard. c'est effectivement en fait de s'appuyer directement sur les équipements en production pour récupérer la donnée dont ils ont besoin, la mettre au bon format et ad après derrière insérer dans la B dans la dans la source de vérité. Donc en fait, on va avoir deux optiques effectivement.

Soit effectivement on part sur une notion un peu Greenfield, c'est j'insère tout dans un Giston, un Yamel, un fichier XLS, peu importe, un CSV, j'intègre, j'ai un workflow qui va me piocher des informations dans ces fichiers là pour aller derrière populer la source de vérité ou alors je vais chercher directement l'information sur les équipements. Éventuellement, je fais un raccord parce qu'il y a peut-être des fonctionnalités qu'on avait pas sur l'infraexistante et que je veux rajouter dans mon nouveau déploiement. Donc du coup derrière voilà, je vais faire un peu un mix2. Ensuite, on va retrouver des notions de D0 D1.

Alors D0, D1, même D2, c'est un concept où en fait on va retrouver des définitions qui sont un peu différentes en fonction des personnes avec qui on parle. Je parle du principe que D0 ça va être tout simplement de mettre les informations basiques de manière à pouvoir configurer point distance. Donc ça va être quoi ? Ça va être du crédent SH, ça va être de l'activation SSH, éventuellement des clés SSH, euh ça va être éventuellement du SNP, des choses comme ça. Vraiment les informations basiques qui permettent à une personne ou un workflow X ou Y de pouvoir attaquer l'équipement de manière à derrière pousser la configuration.

Et donc cette génération de la configuration finale et le fait de pousser cette configuration finale sur l'équipement, c'est ce qu'on va retrouver sur le D1. On va pas se mentir, généralement 90 % des projets, le D0 et le D1, ce sont les mêmes étapes. Il rester peu de clients qui vont vraiment respecter cette notion de D0 séparé du D1. Donc on va vraiment généralement les voir de manière mutualisée. Ensuite, on va repartir sur le day two. Donc le day to, ça va être toute la partie euh gestion du changement. J'ai un nouveau service à déployer, j'ai un nouveau velan, j'ai un nouveau VNI, enfin Virtual Network, j'ai un nouveau ping BGP, j'ai ce que vous voulez.

Comment est-ce que derrière je vais pouvoir automatiser ça selon les informations que je vais avoir dans ma source de vérité ? Et enfin, c'est un sujet qui vient d'être évoqué il y a de 2 minutes, la notion du drift. Donc le drift management effectivement comment je vais pouvoir donc c'est effectivement ce qui a été fait par Airbus. On parlera aussi dans un news case un peu plus tard. Notion du drift management, c'est comment je vais pouvoir de manière planifier vérifier la configuration, l'état de mon réseau par rapport à une intention et qu'est-ce que je vais pouvoir en faire derrière, comment je vais gérer cette notion de changement nonattendu, potentiellement nonattendu.

Et c'est là où en fait la notion du drift va être importante aussi dans la source de vérité parce qu'on va pouvoir effectivement taguer les changements qui potentiellement ont été faits parce que bah potentiellement peut-être que c'est une ligne de commande, peut-être que c'est un service qui a été activé de manière temporaire pour un besoin spécifique et que bah pendant que la gestion du drift tourne récupère l'information comme quoi il y eu un changement nonattendu, bah potentiellement je ne veux pas l'enlever parce que je vais avoir besoin de ce service pendant x jours, x semaines. Donc comment est-ce que je vais pouvoir gérer ça ?

Alors euh le principal challenge qu'on peut avoir dans l'implémentation qu'on a vu en tout cas avec les différents clients et effectivement là je me place plus en tant que que constructeur, c'est avec la partie modélisation de la donnée. Euh clairement [raclement de gorge] c'est le point qui prend le plus de temps. Euh ah d'accord, pas de souci. Donc ça va être le point qui va être potentiellement prendre le plus de réflexion.

Alors pas forcement plus de temps parce que tout ce qui va être population à donné dans les équipements, alors effectivement quand on parle de quatre équipements c'est pas un problème mais quand on compare 5000 10000 15000 20000 équipement là ça peut prendre énormément de temps à populer mais en tout cas en terme de réflexion c'est cette partie vraiment modélisation de la donnée qui va être qui va être la plus importante. Donc en fait il y a quatre points cinq quatre points oui pardon qui ont été qui sont importants. C'est le premier ça va être la partie scope technologique. Donc déjà ça va être quel scope-on intégrer dans la source de confiance ?

Est-ce que c'est une source de confiance qui va être juste réseau les switching, le wireless ou est-ce que c'est une source de variité sur lequelle on va rajouter toute une notion de virtualisation potentiellement mes hostes SX ou mes hostes Nutan X ou autres ? Est-ce que je vais vouloir les représenter pour voir où est-ce qu'ils sont attachés, où est-ce que potentiellement où sont les VM ? Alors, je prends pas en compte toute la partie Votion et ainsi de suite, mais euh mobilité de la des workload, mais en tous les cas effectivement où est-ce qui est potentiellement LVM et ainsi de suite.

Donc, est-ce que on va étendre le scope technologique de notre source de vérité jusqu'à intégrer toute la partie virtualisation ? Est-ce qu'on prend en compte la partie sécurité également ? La partie sécurité, les fireall, les gateway, VPN, les IDS, IPS, est-ce qu'on les représente également dans notre source de variété ? Et on peut étendre ça la partie one avec les routeurs et ainsi de suite. Et une fois qu'on a ça, c'est également est-ce que tous les scopes qui seront implémentés, donc network, virtualisation, sécurité, one est-ce que c'est juste à des fins de visualisation ?

D'accord, donc c'est juste pour savoir effectivement quel host il est connecté, à quel endroit, où est-ce que derrière on va également vouloir s'appuyer là-dessus pour aller potentiellement automatiser tous les aspects qu'on va retrouver sur la sécurité sur le web. Donc effectivement, il y a ce point-là aussi qui va être à prendre en compte parce que le champ d'information qu'on va fournir à ce moment-là en étendant les scopes technologiques ne seront pas du tout les mêmes. Ensuite, on va voir le scope fonctionnel. Donc euh le principe que les sources de vérité possèdent un grand une grande partie des champs euh génériques.

[raclement de gorge] Donc ça c'était quelque chose qui a été évoqué par Christophe tout à l'heure. Euh donc on vair des champs génériques qui vont être dans les sources de vérité généralement. Donc la partie velan, euh les ports et la MTU des choses comme ça. Donc ça pas de souci. Ça c'est commun à tous les constructeurs. Mais derrière chaque constructeur va potentiellement avoir des fonctions un peu spécifiques. Donc on va retrouver cette notion de spécificité sur deux choses. Des fonctions qui vont être des fonctions avancées et en plus des fonctions qui vont être entre guillemets propriétaires en tout cas supporté par très peu de constructeurs.

Donc ils seront pas forcément modélisés de base dans les équipements. D'accord. Donc dans le choix de la source de vérité, c'est jusqu'à où on va pouvoir rajouter des champs custom ou alors jusqu'à quelle profondeur on va pouvoir euh ajouter des informations qui ne sont pas nativement de la source de vérité. Donc il y a ce point là aussi qui est énormément à prendre en compte. Typiquement, je donne un exemple, c'est aussi dans ce choix-là, c'est est-ce que je vais avoir des champs spécifiques ou est-ce que je vais vouloir intégrer directement un Gon avec toutes les informations complémentaire. La façon de gérer ça derrière dans l'automatisation ne va pas forcément être la même.

Donc du coup voilà, il y a ce choix également à faire jusqu'à pour savoir la profondeur sur laquelle on va pouvoir s'appuyer quand on va faire le choix de la source de vérité. Le troisème point, c'est la partie formalisation. Si on souhaite modéliser l'intégralité des données de la configuration, ça va être la plus agnostique possible. Ce serait super si tous les clients étaient en HPE. Je dis bonjour cher concurrent. Euh mais voilà, donc il y a des environnements qui sont hétérogènes, qui sont euh multiconstructeurs ou des clients qui ont eu un vendor A sur data center, un vendor B sur le campus et ainsi de suite.

Cependant, les workflow, l'idée c'est pas d'avoir des workflow automatisations qui vont être différents en fonction du constructeur. Donc il faut avoir quelque chose qui soit le plus homogène possible. Donc il faut avoir cette capacité à modéliser la donnée de la manière la plus simple et la plus agnostique possible. Euh, typiquement, on parle de stacking. Un stacking va sera différent. Enfin, les terminologies vont être différentes en fonction de si c'est de l'HPE ou si c'est un constructeur. On aura des mécanismes qui auront des notions de priorité et pas d'autres. Enfin, voilà, il y a plein de d'éléments qui sont à prendre en compte.

Donc, comment derrière je vais rendre ça de la manière la plus agnostique possible, de manière à simplifier mes workflow et à ne pas complexifier tout ce que j'utilise à l'arrière, ce soit en Python, en antible, en terraform ou peu importe. Et le dernier point, c'est également il faut que la modélisation soit faite de manière à permettre une potentielle évolutivité des données sans rajouter de complexité. Un réseau est fait pour vivre d'un point de vue fonctionnel, d'un point de vue des features qu'on va mettre en place.

Si la modélisation qu'on a mis en place au tout début ne permet pas de faire évoluer et de pouvoir rajouter facilement nouveaux champs, ça peut devenir très compliqué à maintenir et du coup au bout d'un moment la source de variété, on va la mettre de côté. Donc si on veut continuer à s'appuyer là-dessus, il faut que la modélisation qu'on va faire au tout début soit faite de manière à garantir et à permettre une évolutivité de la donnée par rapport à des nouvelles fonctionnalités qui vont être mises en place ou par rapport à une fonction mise en place au départ mais qui elle évolue également en terme de profondeur.

Donc ça c'est les points qu'on a les quatre points principaux qu'on met en avant quand on discute et d'un point de vue constructeur quand on discute avec les clients quand il commencent à nous parler effectivement de mise en place d'une source de de confiance et les points qu'on va leur mettre en avant pour la partie euh pour faire attention. Alors les deux prochaines slides euh ça va être pour une partie enfin pour des use cas. Donc le premier use case c'est la partie migration. Je vous ai évoqué tout à l'heure le fait d'avoir une notion un peu de greenfield et de bronfield. D'accord ?

Donc le Greenfield, je vous rappelle, c'est j'ai un fichier X ou Y où je fais ça de manière manuelle directement dans l'interface web de la de la source de confiance ou alors partir sur du Bronfield. Et c'est effectivement un use case qui a été qui a été utilisé notamment en France où le client a voulu passer d'un constructeur A vers HPE à en l'occurrence. Et donc du coup le principe a été de se pour se simplifier les choses [grognement] d'utiliser une solution qui a été mentionnée tout à l'heure par Aurélien qui était IP FABC. IP Fabrique a cette capacité effectivement à créer des snapshots à l'instanté d'un réseau. D'accord ? de voir de pouvoir récupérer un maximum d'information.

Donc le principe ça été qu'effectivement IP Fabrique allait capter une très grande majorité d'informations du réseau existant et derrière il y avait toute une notion de workflow automatisation qui allait récupérer les informations dans IP fabrique, les montre les mettre au bon format pour pouvoir les insérer dans la source de vérité. Comme ça, automatiquement le client a pu populer sans efforts, sans gros efforts en tout cas. euh sa source de vérité sans avoir à gérer de manière manuelle des JSON, enfin des fichiers XWI. D'accord ? Donc on s'est vraiment basé sur des solutions existantes de manière à les populer. Donc c'est vraiment une notion un peu de Bronfield.

Je me base sur un existant pour aller populer une nouvelle source de vérité. Et donc derrière bah dans le workflow, l'idée était toute bête hein, c'est j'ai un workflow qui du coup va me récupérer euh toute la partie nouvelle donnée qui a été faite. Euh pardon, il y avait une préétape par rapport à ça. Il a converti les données également dans la source de vérité puisque les données qui étaient insérées dans cette source de variété étaient pour le vendor A. Il y avait des éléments, je l'ai évoqué tout à l'heure, comment je passe un vendor A un vendor B sur certaines fonctionnalités.

Donc ce workflow a permis de pouvoir convertir les données vers les informations qui étaient nécessaires pour et derrière d'aller générer les configurations. D'accord ? Donc ça c'est un use case qui peut être super intéressant dans l'utilisation et donc cette notion de modisation de données devient vraiment importante dans ce cas-là. Le deuxième use case que je voulais évoquer, c'est cette notion de configuration check et de drift. Euh c'est un peu ce qui a été évoqué également par Aurélien.

Euh le principe effectivement de base, donc je vais pas y revenir parce que c'est tu l'as déjà expliqué, euh c'est effectivement d'avoir toute une un workflow qui va permettre toutes les semaines, mois, enfin comme vous voulez euh de pouvoir effectivement comparer l'intent, donc ce qu'on a dans la source de config dans la source de vérité avec la configuration qui est actuellement en place et derrière de faire de l'alerting, voir de la remédiation, des choses comme ça. OK ? Donc ça c'est effectivement un point qui est de plus en plus utilisé et de plus en plus demandé. La notion de ZTP c'est quelque chose qu'on voit depuis pas mal de temps maintenant dans toute la partie automatisation.

La population de la la population pardon de la de la source de variité également. Maintenant effectivement les clients commencent à regarder un peu plus loin sur le notion de de run et derrière comment je vais gérer euh toute la partie gestion de la configuration donc check de la configuration et donc du coup derrière gestion du drift qui peuvent être soit en alerting soit en remédation automatique. Après si on pousse un peu plus loin euh on a également aussi des possibilités selon les équipements de pouvoir avoir des agents qui tournent directement sur les équipements et en fait ça nous permet de pouvoir décentraliser cette notion du check directement sur les agents.

En fait, on évite de faire un overload sur les serveurs qui doivent poer potentiellement des milliers d'équipements et du coup en fait avec une load qui va être du coup hyper importante et donc du coup en fait on va décentraliser cette notion là. Donc chaque équipement va être capable de pouvoir gérer son propre configuration check de manière soit soit séquentielle enfin soit planifié soit basé sur un changement de configuration. Donc qui est capable de voir qu'il y a un changement de configuration qui a été effectué et derrière d'aller vérifier dans la source de vérité si le change qui a été observé est-ce que c'est conforme ? Oui. Non.

Et à ce moment-là de pouvoir faire soit de l'arting pareil sur du sislog, du SNMP ou sur un ouverture de ticket voir faire de la remédiation et de l'autoromédiation. Donc ça c'est également des choses qu'on commence à à voir et qu'on sur lesquelles on commence à parler assez assez assez fréquemment avec les clients. Voilà [rires] 15 R5 [applaudissements] tu parlais en fait d'argent directement sur les équipements faire justement offloader complé chèque comme çaou oui et du coup c'est ça genre c'est quoi ça ça se traduit par quoi c'est un conteneur qui tourne sur le l'équipement c'est concrètement le retil il est où alors cet agent du Du coup, je vais c'est c'est en cur sur nos équipements.

D'accord. Après, peut-être que d'autres constructeurs peuvent gérer ce genre de de cas de figure, mais en tout cas, je parle pour pour les nôtres. En fait, c'est les agents. Donc, c'est du code Python qui tourne en 24, enfin 24735, donc tout le temps. Et derrière, dès qu'il y a une action à jouer, il va lancer un container interne, va lancer son action qui va être effectivement de faire son check de manière régulière, va pouvoir récupérer la conf, de pouvoir faire la le dif éventuellement et du coup de pouvoir comme c'est du pyon, il peut interagir des systèmes. En fait, c'est comment tu gères ?

Je sais pas, j'imagine j'ai j'ai 5000 à 7 là, j'ai tous ces agents qui tournent sur les équipements. Comment je récupère une visibilité globale ? Je sais pas si j'ai un agent qui ne fonctionne plus sur un équipement et du coup j'ai la compéance check qui tourne pas. Comment c'est géré ? Ben che parle de la solution à Ra mais chez vous du coup comment c'est géré ça ?

Il y a il y a il y a on a une sorte d'inside qui peut devoir un peu il y a pas alors il y a pas après ça peut se faire par la solution management mais je suis pas enfin voilà l'idée c'est pas forcément de pousser la solution management en tout cas les équipements sur sur lesquels ça tourne c'est du 100 % STPI notamment pour ces agents-là c'est qu'on peut avoir le statut en temps réel des alertes de du statut de l'équipement de l'agent et ainsi de suite. Donc ça ça peut se faire par du polling du polling restpi sur les équipements où on va récupérer les statuts, les dernières alertes, qu'est-ce qui a été fait, les actions qui ont été menées et ainsi de suite. Personne d'autre ?

Très bien, merci pour revoir Merci.

[musique]