Arista Networks CloudVision Demo

Euh, donc je suis Andre Pesh. Je suis directeur au sein de l'équipe d'ingénierie logicielle ici. En fait, j'étais intervenant lors du Tech Field Day 3 dont nous parlions plus tôt. C'est donc un plaisir de vous revoir parmi nous. Euh, et oui, je pense que ce que nous voulons faire ici, c'est rendre les choses un peu plus concrètes. Parlons d'un aspect euh, du portail Cloud Vision. Euh, en nous concentrant vraiment sur la partie provisionnement réseau et sur la façon dont nous pouvons automatiser les choses pour ce vaste ensemble de clients dont Jeff parlait. Surtout, n'hésitez pas à intervenir, à poser des questions, rendez cela aussi interactif que vous le souhaitez.

Donc, pour planter le décor, euh, comme le disait Jeff, nous essayons vraiment d'offrir cette automatisation réseau et cloud pour la grande majorité des clients qui n'ont peut-être pas encore beaucoup avancé sur cette voie. Et il y a vraiment trois points principaux sur lesquels je souhaite insister pendant cette démonstration. Le premier est la notion de base de données réseau, n'est-ce pas ? Nous devons arriver à un point où il existe une source unique qui définit l'état souhaité de votre réseau, n'est-ce pas ? Il ne peut pas y avoir, enfin, cela doit être une vision à l'échelle du réseau.

Il ne s'agit pas d'avoir un fichier de configuration pour un appareil, que j'ai ensuite copié et modifié pour un autre, et ainsi de suite un millier de fois. Maintenant, vous vous retrouvez avec tous ces fichiers à gérer. Il vous faut ce point central qui définit vos attentes, car c'est aussi ce point de référence pour vérifier l'état actuel de votre système et voir s'il est conforme à ce que vous souhaitez. Euh, la deuxième partie consiste à permettre aux clients d'effectuer des modifications sur leur réseau sans jamais avoir à toucher physiquement à leurs équipements.

Je pense qu'il est important de conserver la capacité d'accéder à vos appareils pour effectuer des changements et, vous savez, déboguer les problèmes lorsqu'ils surviennent. Mais pour les changements d'automatisation routiniers , vous avez besoin d'un cadre pour définir votre modification, la faire approuver et la déployer sur votre réseau de manière automatisée, avec des contrôles, des équilibres et une visibilité tout au long du processus, pour vous assurer que le changement souhaité a bien été effectué. Pas vrai ? Il ne s'agit donc pas seulement que cela se produise automatiquement. Vous avez besoin de visibilité pour confirmer que tout est bien en place.

Cela dépend en grande partie des API que nous exposons au niveau de l'EOS, qui rendent cela possible. Il s'agit des API que nous développons depuis des années avec nos plus grands clients cloud, qui les utilisent pour gérer leur environnement. Nous cherchons désormais à proposer cela sous forme de solution clé en main pour le reste de nos clients. La troisième partie consiste à reconnaître que nos clients ont déjà investi dans divers produits, qu'il s'agisse de leur base de données de gestion de configuration ou de systèmes d'orchestration de tâches. Et nous ne sommes qu'une partie de ce vaste problème d'orchestration de centre de données, n'est-ce pas ?

Lorsque les équipes déploient de nouvelles infrastructures ou services, de nombreux changements surviennent à divers niveaux, dont nous ne contrôlons pas tout. Nous devons donc être capables d'intégrer ces éléments, de récupérer les informations via des appels API ou des saisies utilisateur, et d'offrir une solution complète au client, en nous concentrant sur notre cœur de métier : la gestion réseau. Sur ce, je vais faire une démonstration, en m'arrêtant de temps en temps pour vos questions, pour vous donner un aperçu de ce que nous avons ici. Nous voici donc sur la page d'accueil. Vous avez accès à différentes applications.

Je souhaite principalement vous parler de ce tableau de bord de service. C'est ici que nous récupérons des informations depuis marissa.com pour vous alerter, par exemple, d'une nouvelle version logicielle, d'un nouveau correctif ou d'un avis technique sur le site du client. Si nous accédons à la page de provisionnement réseau, nous voyons tous les appareils gérés par le portail Cloud Vision. Dans ce cas, nous avons tous ces appareils que nous pouvons ensuite organiser dans ce que nous appelons des conteneurs. Ces conteneurs nous offrent un moyen de regrouper les appareils de manière logiquement cohérente pour vous.

Vous verrez ici que nous avons un conteneur pour les différents centres de données. Au sein de chaque centre de données, nous avons un conteneur pour chaque pod. Ici, j'ai même créé un conteneur pour chaque zone de disponibilité au sein de chaque pod. Si j'ai des zones de disponibilité entre les racks pour des déploiements OpenStack, je peux créer un conteneur différent pour cela. Et cette hiérarchie nous donne alors la possibilité de placer des définitions de configuration ou des propriétés au-delà du simple niveau de l'appareil , n'est-ce pas ?

Car si vous réfléchissez à ce qui se passe quand vous gérez vos appareils, si vous regardez la configuration d'un appareil , 90%est identique pour chaque appareil . Probablement 99%est identique si vous avez un algorithme de modélisation simple, n'est-ce pas ? L'idée que votre réseau, que chaque appareil est unique comme un flocon de neige, est espérons-le révolue, n'est-ce pas ? Vous essayez de construire des réseaux à grande échelle qui sont hautement reproductibles, où vous avez un modèle que vous dupliquez.

Et donc, quand vous êtes dans cet environnement , vous devez être capable de prendre la configuration que vous appliquez, non pas à l'appareil, mais à une propriété associée à cet appareil selon son emplacement, puis de l'appliquer. Ainsi, en créant cette hiérarchie, nous pouvons appliquer la configuration à différents niveaux et réduire la duplication qui se produit autrement. Je pense qu'un autre point important à aborder ici est ce conteneur indéfini. Ce sont donc tous les appareils qui ont démarré en mode de provisionnement zéro touche. La manière standard de démarrer ressemble un peu au démarrage PXE d'un serveur, n'est-ce pas ?

Vous démarrez, vous utilisez DHCP pour une adresse, vous obtenez un script de démarrage et , via ce script du portail Cloud Vision , vous vous enregistrez auprès du portail et attendez la configuration. Ainsi, que vous effectuiez une gestion de configuration continue ou un provisionnement initial, ou le déploiement de nouveaux racks, vous pouvez tout faire depuis un seul endroit. Ce n'est pas un processus séparé. Et donc, ces appareils peuvent maintenant être placés dans les conteneurs appropriés, recevoir leur configuration et être initialisés, sans jamais toucher l'appareil dès son branchement initial .

Pour terminer sur les attributs de base du portail Cloud Vision, l'autre chose, si l'on regarde le conteneur locataire ici, vous pouvez voir certaines des configurations que nous avons définies. Nous les appelons des « configlets ». Ce sont vraiment des sous-sections de configuration et nous en parlerons un peu plus en détail plus tard. Mais vous pouvez voir ici, au niveau du locataire, que nous avons défini la configuration AAA, la configuration EAPI et quelques paramètres de base pour le réseau et le fuseau horaire. Ce sont les mêmes pour tout ce que je vais placer au sein de ce conteneur locataire.

De même, je peux ajouter une configuration à différents niveaux, ce qui me permettra d'imposer, à un haut niveau, une cohérence uniforme au sein de ce centre de données. Vous voyez, ces propriétés sont identiques dans cette zone de disponibilité ; elles sont les mêmes, et c'est un excellent moyen de réduire les doublons. L'autre élément ici est que nous pouvons étiqueter chaque appareil ; certaines étiquettes sont automatiques, d'autres sont définies par l'utilisateur. Ici, j'ai donc tous les commutateurs « top of rack » du centre de données un, pod un. C'était la vue en liste ; voici maintenant une vue hiérarchique logique où vous pouvez également filtrer selon ces étiquettes.

Ainsi, à mesure que le nombre d'appareils gérés augmente, disons que vous en gérez des centaines, vous pouvez rapidement filtrer pour trouver ce que vous cherchez, effectuer des modifications, voir l'état, et continuer. Voilà qui couvre les éléments de base. Je veux maintenant tout rassembler et passer par un exemple, mais avant cela, y a-t-il des questions qui vous viennent à l'esprit en cours de route ? Très bien, je continue. Disiez-vous qu'il y avait une relation parent-enfant entre les « spine » et les « leaf » ? Si vous modifiez une configuration, tout ce qui se trouve dans ce conteneur, ou qui en dépend, recevra également cette modification. Oui, c'est une bonne remarque. Exact.

Les conteneurs suivent donc une hiérarchie stricte. Les étiquettes, elles, ne suivent pas de hiérarchie stricte. Les étiquettes peuvent être appliquées librement. Vous pouvez avoir plusieurs étiquettes sur un appareil, et il n'y a pas d'imposition du type « si vous avez cette étiquette, vous ne pouvez pas avoir cette autre étiquette ». C'est l'utilisateur qui l'applique. Les conteneurs forment une hiérarchie stricte qui, à mon avis, est plus simple à concevoir en fonction de l'emplacement. Le modèle centre de données, pod et zone de disponibilité fonctionne très bien car c'est ainsi que la configuration est appliquée.

Et oui, vous héritez du haut vers le bas ; les éléments plus proches de l'appareil, ou l'appareil lui-même, peuvent remplacer ce qui a été défini au-dessus. En résumé, la configuration d'un appareil, comme nous le verrons dans un instant, est la somme de la configuration du locataire, du conteneur de haut niveau, de tous les conteneurs enfants et enfin de ce qui est appliqué directement à l'appareil. Et donc, en général, ce qui est appliqué à l'appareil, c'est vraiment juste ce qui est spécifique à l'appareil, n'est-ce pas ? C'est l'adresse IP que vous allez obtenir, n'est-ce pas ? C'est, vous savez, c'est peut-être, selon votre environnement, la majeure partie de ce que vous avez.

Peut-être quelques configurations de vitesse spécifiques aux ports, mais en général, une grande partie devrait être au niveau du conteneur. Euh, et avec le templating, vous pouvez en fait en mettre encore plus au niveau du conteneur et simplement appliquer un modèle avec des variables spécifiques à chaque appareil remplies. Merci. Donc pour cet exemple, ce que je veux faire, c'est passer en revue une chose courante que nous devons faire au niveau de l'équipe réseau : appliquer un nouvel underlay sur votre environnement.

Et vous savez, c'est l'une de ces choses dont nous parlons moins parce qu'en ce moment, nous parlons beaucoup de l'intégration avec les contrôleurs SDN et les systèmes d'orchestration et ce que vous faites lorsque les services virtuels se déplacent dans votre infrastructure, et c'est vraiment important. Et c'est aussi ce que fait Cloud Vision grâce à notre intégration avec OpenStack et VMware NSX en utilisant OVSDB et des technologies similaires. Mais il est tout aussi important pour l'équipe réseau d'être en mesure d'effectuer ces changements d'underlay de manière automatisée.

Euh, afin que, lorsque des vulnérabilités apparaissent, que des changements doivent être effectués ou que vous déployiez plus de racks, vous puissiez tout aussi facilement provisionner et surveiller ce qui se passe sur votre infrastructure. Donc, dans ce cas, nous allons regarder la page des configlets. J'ai déjà créé ce configlet. Il s'appelle "server port ale". C'est là que tous mes ports orientés serveur ont cet "ale" appliqué. Euh, vous verrez que ce n'est que de la CLI, n'est-ce pas ? Il ne s'agit pas d'essayer de vous apprendre un énième modèle de données. C'est fait pour que les ingénieurs réseau sachent l'utiliser immédiatement.

Et nous pouvons aller valider cela sur tous les appareils en utilisant l'EAPI. Donc, vous savez, c'est syntaxiquement correct et une chose que vous remarquerez est que cette config n'est associée à aucun appareil. C'est juste là, en tant que sous-section de la configuration. Ensuite, nous pouvons aller appliquer cela, par exemple, au niveau du "datacenter one pod one". Et ce que nous disons ici, c'est que nous voulons que tous les appareils de ce pod aient cette configuration. Et donc, lorsque nous enregistrons, une chose importante à noter est que nous n'avons pas encore touché aux appareils. Cela configure notre intention : nous voulons cette configuration sur tous ces appareils.

Et vous remarquerez qu'il y a cette tâche en attente pour les exécuter réellement. Il existe donc un système complet de gestion des tâches pour approuver le moment où les tâches peuvent être exécutées, car définir ce que vous voulez faire et décider du moment où vous voulez le faire sont deux choses distinctes. Et si nous allons ici pour regarder la configuration d'un appareil donné, nous pouvons voir que sur la gauche se trouvent les « configlets ». Sur la droite, ou au centre, se trouve la configuration théorique, c'est-à-dire ce à quoi ressemblera la configuration quand je l'aurai appliquée, et sur la droite, c'est la configuration réelle en cours d'exécution sur l'équipement .

Je vais mettre cela en pause ici, car je pense qu'il est très important de comprendre ce qui se passe en coulisses . Vous savez, si vous regardez beaucoup de systèmes de gestion de configuration, vous devez effectuer tout ce travail fastidieux consistant à dire : « Voici mon ancien fichier de configuration, voici ce que je veux qu'il devienne, laissez-moi comparer les deux pour trouver quelles commandes je dois envoyer » , et « Oh, mais je suis sur ce type d'appareil, donc je dois envoyer celles-ci avant celles-là ». C'est un vrai bazar, n'est-ce pas ? C'est là que nous sommes en mesure de tirer parti des API que nous fournissons.

Grâce à l'API eAPI ou à l'API basée sur JSON et aux sessions de configuration, qui sont des modèles , ou plutôt des transactions au niveau de l'interface en ligne de commande, nous pouvons dire : « Regardez, voici ma configuration complète, je veux que la configuration de l'équipement ressemble à ceci ». Il n'y a pas de comparaison de différences du côté du Cloud Vision Portal ; il dit simplement : « Vous m'avez dit que c'est ce que vous voulez pour la configuration, alors voici.

» L'astuce consiste à exploiter notre base de données système : nous prenons un instantané de la configuration existante, nous revenons à un état propre, nous réappliquons toute cette configuration, puis nous recopions la base de données par-dessus. En faisant cela, nous ne modifions que ce qui est réellement différent selon la nouvelle configuration que vous poussez . Ainsi, du point de vue du système, si vous avez tous ces agents en cours d'exécution, ils ne voient que la différence. Dans ce cas, vous ne verriez que ce nouvel élément. Rien d'autre ne change. Mais du point de vue de la complexité, je sais que la configuration est exactement celle que je souhaite.

Si cela échoue, rien ne change. N'est-ce pas ? C'est l'autre aspect terrible de l'automatisation : elle est formidable jusqu'au moment où elle ne fonctionne qu'à moitié et ne s'applique pas correctement. Et ensuite , comment s'en sortir, n'est-ce pas ? C'est donc une opération tout ou rien, et avec cette vue, vous pouvez voir qu'il n'y a rien non plus que vous allez supprimer et qui aurait pu être ajouté manuellement. Nous avons tout un processus de réconciliation pour pouvoir dire : "Hé, il y a une commande que quelqu'un a placée ici ; êtes-vous sûr de vouloir tout effacer ?" Pas vrai ? Je ne pense pas qu'elle devrait être là, mais peut-être que vous, si.

Je pense que c'est une partie très importante de la puissance des API que nous avons fournies, et de la façon dont nous les exploitons pour automatiser les choses de manière plus simple et plus propre. Si nous allons ici maintenant, nous irons sur la page de gestion des tâches. En supposant que j'aie relancé la lecture. Oui, c'est le cas. La page de gestion des tâches, et vous verrez la tâche en attente. Il y en a une par appareil. Et maintenant, vous pouvez décider comment vous voulez appliquer la configuration que vous avez créée. Que vous le fassiez tout d'un coup, ou une par une en effectuant des vérifications entre chaque, n'est-ce pas ?

Mais vous avez maintenant ce contrôle sur la manière dont ces tâches sont approuvées. Comment je les exécute ? Et comment je fais ces changements ? Vous avez peut-être encore une fenêtre d'interruption ou de contrôle des changements pour le faire pendant une période creuse ; mais vous pouvez désormais tout faire de manière automatisée avec la certitude qu'une fois terminé, c'est réellement complet. Et une partie de ce que nous fournissons ici, c'est, encore une fois, le défi de l'automatisation, c'est tout l'aspect vérification de la conformité, n'est-ce pas ?

Parce que vous voulez savoir que ce qui devrait être là est bien là, et que quelqu'un n'est pas allé sur le commutateur pour le changer sans que vous le sachiez, risquant ainsi de perdre cette configuration. Donc, cette vérification de la conformité est vraiment importante. Je pense que la dernière chose dont je veux parler est que tout ce que nous avons fait ici avec l'interface utilisateur est construit sur les API JSON fournies par le portail Cloud Vision. Il n'y a donc rien que vous puissiez faire manuellement que vous ne puissiez automatiser. C'est très important car, encore une fois, nos clients ont investi dans des bases de données de gestion de configuration personnalisées.

Ils peuvent vouloir les exploiter. C'est parfait. Ils peuvent prendre la configuration, l'envoyer dans le portail Cloud Vision pour définir ce qu'ils souhaitent, puis exploiter nos API et l'automatisation pour appliquer ce changement sur le réseau sans interruption, vous voyez ? Ou, si vous utilisez ServiceNow ou un autre système de tickets, vous prenez les tâches en attente, vous les envoyez dans ce système, vous les faites approuver, et seulement une fois approuvées et planifiées, vous les exécutez, n'est-ce pas ? Et encore une fois, c'est ainsi que le portail Cloud Vision s'intègre au problème plus vaste de l'automatisation du centre de données. Voilà pour ma petite démonstration.

Euh, je ne sais pas s'il y a d'autres questions. Vous devriez parler davantage des transactions. Parler davantage des transactions. Je ne dis pas de le faire maintenant. Je dis juste qu'en tant qu'entreprise, vous devriez insister là-dessus. Ah oui. Je veux dire, la capacité d'effectuer des changements de manière cohérente, sans avoir à se soucier des spécificités d'EOS d'un côté. Vous dites quel état vous voulez obtenir et cela se produit tout simplement. C'est vraiment la force du modèle de base de données, c'est certain. Oui. Ouais. J'imagine que ce que nous entendons à propos des contrôleurs en général, ce sont des questions similaires à vous poser.

Euh, donc ceci s'exécute sur des machines virtuelles. Vous avez de la redondance. Oui. Ouais. Donc, sous le capot, le Cloud Vision, euh, oui. C'est un modèle en cluster haute disponibilité . Il y a donc trois nœuds. Euh, et c'est basé sur l'élection d'un leader . Euh, vous bénéficiez d'une redondance N + 1, ou euh, oui, un nœud peut tomber en panne, et une fois rétabli, un autre peut tomber en panne . C'est le modèle de redondance similaire à celui de beaucoup de contrôleurs existants. Oui. Euh, et si tout est hors service, tout va bien, aucun changement ne peut simplement être effectué sur le réseau. Ouais.

C'est un point vraiment important car, quand on pense au modèle OpenFlow, on a un nœud contrôleur central qui devient essentiel à toute décision au niveau du plan de données. Et ce n'est vraiment pas ce que nous faisons ici. Nous essayons d'automatiser le plan de gestion, pas le plan de données du contrôleur, n'est-ce pas ? Exactement. Il s'agit donc d'intégrer des systèmes d'orchestration pour provisionner de nouveaux services ou, vous savez, des outils de gestion pour appliquer des changements. C'est exact, si tout est arrêté, vous décidez de tout couper parce que vous devez simplement effectuer une mise à jour, tout fonctionne normalement.

Oui, vous ne pouvez pas provisionner de nouveaux services, mais comme vous avez tout arrêté, c'est tout à fait attendu. Donc oui bonnes questions. Eh bien, ne pouvez-vous pas simplement vous connecter à une box spécifique et afficher les configurations à partir de là ? Oh, absolument. Exact. Et c'est là un autre point très important. Rien de ce que nous faisons ne change la manière fondamentale dont vous interagissez avec votre box, n'est-ce pas ? D'un point de vue mise à l'échelle et exploitation, vous devez être capable d'agir sur tout le réseau sans gérer chaque box individuellement et automatiser les tâches. Mais en fin de compte, vous devez pouvoir accéder à votre box, non ?

L'interface en ligne de commande ne disparaît pas pour le débogage, surtout quand il est 2 heures du matin et que vous essayez de résoudre des problèmes. Vous ne voulez pas qu'on vous dise que les outils que vous maîtrisez ne sont plus utilisables, n'est-ce pas ? Donc tout cela fonctionne toujours. C'est ça, l'orchestration. Et bien sûr, depuis cette box, vous devez savoir ce que votre outil d'orchestration a fait, n'est-ce pas ? Vous ne pouvez pas le cacher comme si cela n'avait aucune importance. Donc oui, je décrivais le cas d'une panne, disons que le contrôleur est hors service et que je dois appliquer une modification urgente sur la box, juste pour changer quelque chose, n'est-ce pas ?

Et du côté de Cloud Vision Portal, ce que vous verrez lors de votre prochaine modification, c'est : " D'accord, voici votre configuration actuelle." Et hé, il y a des commandes ici que je n'ai pas envoyées, n'est-ce pas ? Voulez-vous les conserver ou voulez-vous les supprimer ? Vous avez l'option d'utiliser un bouton de réconciliation qui crée une nouvelle configuration appliquée au périphérique pour dire : "Voici la configuration présente sur l'appareil que nous allons effacer, sauf si vous changez d'avis." Vous pouvez alors apporter les modifications souhaitées ou décider de ne rien changer pour l'instant. Quelqu'un, vous savez, ma box n'est plus conforme.

Je ne pensais pas que ça devrait être le cas. Euh, en général, ce que nous attendons, c'est que vous commenciez toute fenêtre de changement en vérifiant si votre équipement est conforme. Si oui, commencez à faire les changements, puis appliquez-les, n'est-ce pas ? Si non, cherchez pourquoi, mettez-le en conformité, puis procédez aux changements. Super. Oui. Qu'en est-il des changements non autorisés ? Donc, vous avez votre contrôleur qui fonctionne. Vous avez dix personnes dans votre équipe. Vous avez une réunion avec neuf d'entre elles et vous dites : "Très bien, nous utilisons ce contrôleur maintenant." Oui.

La dixième ne se présente pas et décide le lendemain de faire un changement sur un commutateur. Comment cela est-il remédié ? Eh bien, euh, désolé, je pensais que vous alliez parler de l'option de la personne, mais vous parlez du contrôleur. Donc, oui, vous avez l'opération du contrôleur. Quelqu'un décide de faire un changement local sur le commutateur. Oh, oui. Je veux dire, encore une fois, je pense qu'aucun de ces outils ne remplace le processus standard que les gens doivent suivre, n'est-ce pas ? Donc, euh, vous devez aller vérifier avant d'appliquer le changement que rien n'a changé sur l'appareil de manière inattendue.

Ensuite, vous appliquez le changement et vous vérifiez qu'il est conforme. Donc on peut toujours faire des changements locaux même si vous pouvez absolument toujours faire des changements locaux. Rien ne vous empêche d'utiliser l'interface en ligne de commande et, du point de vue de l'intégration système d'orchestration, c'est assez intéressant. Il y a, euh, un point important : nous séparons la notion de configuration sous-jacente (underlay) et de configuration superposée ( overlay), n'est-ce pas ? Donc, quand l'intégration OpenStack décide : " Vous savez quoi ?

J'ai besoin de ce mappage VLAN vers VXLAN sur ce port parce que cette machine virtuelle y a été placée", ce n'est pas une configuration statique, n'est-ce pas ? Vous faites un "write mem" ; cette configuration ne va pas dans le commutateur car elle n'est pas statique , n'est-ce pas ? Elle n'a pas été saisie par l'utilisateur et elle dépend totalement de ce qu'OpenStack nous indique, n'est-ce pas ? Et grâce à cette séparation, vous pouvez voir ces éléments séparément et vous pouvez toujours effectuer des changements sur la partie statique qui s'intègrent à cela.

Vous pouvez donc toujours faire vos propres changements si vous le souhaitez pour mettre les choses en route ou pour empêcher quelque chose qui ne devrait pas arriver. D'accord. Oui. Que se passe-t-il dans le programme d'orchestration quand, euh, deux personnes essaient de faire un changement similaire mais pas tout à fait identique ? Donc avec votre exemple d'ACL, Oui. Deux personnes configurent le système, mais elles paramètrent l'ACL différemment. Fusion du contexte. Vous aviez une file d'attente d'une douzaine d'éléments qui semblaient concerner des appareils différents, mais peut-on voir plusieurs entrées pour le même appareil ? C'est une bonne question.

Pour l'instant, nous imposons une tâche par modèle d'appareil, n'est-ce pas ? C'est très délicat si plusieurs personnes font des changements différents et les exécutent dans des ordres variés. En général, vous effectuez ces changements, puis vous les appliquez lors d'une fenêtre de maintenance. Si vous faites plusieurs modifications sur un appareil, c'est parce que vous vouliez changer la précédente. Nous pourrions approfondir ce point, mais c'est le modèle actuel. Vous avez un seul changement par appareil. Ainsi, si quelqu'un d'autre apporte une modification, elle s'ajoute à la configuration existante. Exact. C'est ça. Et donc, que se passe-t-il dans la tâche ?

Avant de l'exécuter, vous vérifiez : "Est-ce bien ce à quoi je m'attendais avant de lancer l'exécution ?" Et là, vous vous dites : "Oh, c'est étrange.""Cet autre élément a été ajouté." Bien sûr, l'authentification basée sur les rôles pour restreindre qui peut effectuer des changements est également très importante. N'est-ce pas ? Je suppose que oui, car le problème est qu'avec un seul changement par appareil, vous risquez de regrouper quatre configurations pour quatre modifications distinctes en une seule opération. Oui. Si l'une d'elles échoue, c'est tout ou rien. Les quatre sont annulées, ce qui est un choix qui revient à l'utilisateur, n'est-ce pas ?

Car je pense que, durant votre fenêtre de maintenance, vous décidez : "Vais-je essayer de tout pousser en même temps ?" Ou bien : "Je commence par la première, puis la deuxième, puis la troisième", et là, "Zut, tout a planté, nous sommes dimanche soir et le marché ouvre demain, je vais donc restaurer l'état de vendredi." C'est là que réside toute la puissance de la restauration réseau. Mais si vous ne pouvez en préparer qu'une à la fois, alors le plaisir de voir quatre personnes préparer des changements, puis quelqu'un les exécuter ou les planifier un par un pendant la nuit. Je pense que dans ce cas, nous cherchons à simplifier les choses pour éviter tout problème d'ordre étrange.

Je comprends. On ne peut pas utiliser un logiciel pour résoudre un problème organisationnel. C'est tout à fait vrai. Eh bien, et et plus de processus. Eh bien, et beaucoup d'entreprises que nous visons ont déjà beaucoup de processus. Donc, le but est de s'intégrer à ces processus, pas d'en créer de nouveaux. Exact. Juste pour revenir à ce que Matt a mentionné concernant les modifications individuelles sur des objets individuels. Euh, la prochaine fois que vous pousserez une modification de configuration depuis un objet parent, est-ce que ces objets enfants seraient écrasés par la configuration standard , ou bien ces caractéristiques individuelles sont-elles conservées ?

En fait, le Cloud Vision Portal définit ce que devrait être la configuration. Vous l'utilisez donc comme base de données pour définir l'état souhaité. Si le switch contient des paramètres que vous voulez garder, vous pouvez les importer pour définir la configuration de cet appareil. Mais sinon, l'idée est que vous utilisez cet outil pour automatiser et affirmer : « Non, voici ce que cela doit être, et je veux savoir quand ce n'est pas le cas. » Donc, euh, effectivement, nous ne laissons pas les changements tels quels , n'est-ce pas ? À moins que vous ne nous demandiez explicitement de les intégrer.