Comment nous automatisons un grand réseau existant

Salut Nous avons plus de 15 260 objets et 38 000 périphériques réseau qui doivent être configurés, mis à jour et vérifiés pour être opérationnels. Le maintien d'une telle flotte d'équipements est assez difficile et nécessite beaucoup de temps, d'efforts et de personnes. Par conséquent, nous devions automatiser le travail avec les équipements réseau et nous avons décidé d'adapter le concept de réseau en tant que code pour gérer le réseau dans notre entreprise. Sous la coupe, lisez notre historique d'automatisation, les erreurs commises et un autre plan pour les systèmes de construction.

Pour faire court, nous voulons automatiser le réseau

Salut Je m'appelle Alexander Prokhorov et, avec l'équipe d'ingénieurs réseau de notre département, nous travaillons sur un réseau en #IT X5 . Notre département développe l'infrastructure réseau, la surveillance, l'automatisation du réseau et la direction tendance de Network as a Code.

Au départ, je ne croyais pas vraiment à une quelconque automatisation de notre réseau en principe. Il y avait beaucoup d'erreurs héritées et de configuration - pas partout où il y avait une autorisation centrale, pas tout le matériel SSH pris en charge, pas partout SNMP était configuré. Tout cela a grandement ébranlé la croyance en l'automatisation. Par conséquent, tout d'abord, nous mettons en ordre ce qui est nécessaire pour démarrer l'automatisation, à savoir: la normalisation de la connexion SSH, l'autorisation unique ( AAA ) et les profils SNMP. Toute cette fondation vous permet d'écrire un outil pour la livraison en masse de configurations sur un appareil, mais la question se pose: puis-je en obtenir plus? Nous en sommes donc arrivés à la nécessité d'élaborer un plan de développement de l'automatisation et du concept de Réseau en tant que Code en particulier.

Le concept de réseau en tant que code, selon Cisco, signifie les principes suivants:

• Stocker les configurations cibles dans le référentiel, contrôle de source
• Les modifications de configuration passent par le référentiel, Single Source of Truth
• Incorporation de configurations via l' API

Les deux premiers points vous permettent d'appliquer l'approche DevOps ou NetDevOps à la gestion de votre infrastructure réseau. Avec le troisième paragraphe, il y a des difficultés, par exemple, que faire s'il n'y a pas d'API? Bien sûr, SSH et CLI, nous sommes des networkers!


En plus d'essayer d'appliquer de nouvelles approches à la gestion de réseau, nous voulions résoudre certains problèmes plus aigus dans l'infrastructure de réseau, tels que l'intégrité des données, la mise à jour et, bien sûr, l'automatisation. Par automatisation, nous entendons non seulement la livraison en masse de configurations aux équipements, mais également la configuration automatique, la collecte automatique des données d'inventaire des équipements de réseau, l'intégration avec les systèmes de surveillance. Mais tout d'abord.

La fonctionnalité que nous visions est:

• Base de données d'équipements réseau (+ découverte, + mise à jour automatique)
• Adresses réseau de base (IPAM + contrôles de validation)
• Intégration de systèmes de surveillance avec des données d'inventaire
• Stockage des normes de configuration dans le système de contrôle de version
• Formation automatique de configurations cibles pour un objet
• Livraison en vrac des configurations à l'équipement réseau
• Mettre en œuvre un processus CI / CD pour gérer les modifications de configuration réseau
• Test des configurations réseau avec CI / CD
• ZTP (Zero Touch Provisioning) - configuration automatique de l'équipement pour un objet

Les systèmes dont nous avons besoin et leurs connexions

Une brève conclusion du spoiler - il est préférable de systématiser et de contrôler le processus de livraison en masse des configurations afin de ne pas arriver à la livraison en masse des erreurs dans les configurations.

 - DevOps:    50ms     4    -     : ", !@#$%" 

Le schéma auquel nous sommes arrivés consiste en des blocs de données de base «métier», des blocs de données de base «réseau», des systèmes de surveillance d'infrastructure de réseau, des systèmes de livraison de configuration, des systèmes de contrôle de version avec une unité de test.

Tout ce dont nous avons besoin, c'est de données

Nous devons d'abord savoir quels sont les objets dans l'entreprise.

SAP - Système d'entreprise ERP . Il existe des données sur presque toutes les installations, et plus précisément sur tous les magasins et centres de distribution. De plus, il existe des données sur les équipements qui ont transité par un entrepôt informatique avec des numéros d'inventaire, qui nous seront également utiles à l'avenir. Seuls les bureaux manquent, ils ne sont pas démarrés dans le système. Nous essayons de résoudre ce problème dans un processus séparé, à partir du moment de l'ouverture, nous avons besoin d'une connexion sur chaque objet, et nous sélectionnons les paramètres de communication, donc quelque part à ce moment, nous devons créer des données de base. Mais l'insuffisance des données est un sujet distinct, il est préférable de mettre cette description dans un article séparé si cela vous intéresse.

HPSM - un système contenant une CMDB commune pour l'informatique, la gestion des incidents, la gestion du changement. Étant donné que le système est commun à tous les services informatiques, il doit disposer de tous les équipements informatiques, y compris les équipements réseau. C'est l'endroit où nous ajouterons toutes les données finales sur le réseau. Avec la gestion des incidents et des changements, nous prévoyons d'interagir à partir des systèmes de surveillance à l'avenir.

Nous savons quels objets nous avons, les enrichir avec des données sur le réseau. À cette fin, nous avons deux systèmes - IPAM de SolarWinds et notre propre système CMDB.noc.

IPAM est un référentiel de sous-réseaux IP, les données les plus correctes et correctes sur la propriété des adresses IP dans l'entreprise devraient être ici.

CMDB.noc est une base de données avec une interface WEB où sont stockées des données statiques sur l'équipement réseau - routeurs, commutateurs, points d'accès, ainsi que les fournisseurs et leurs caractéristiques. Dans le cadre de moyens statiques, leur changement ne s'effectue qu'avec la participation de l'homme. En d'autres termes, la découverte automatique ne modifie pas cette base de données, nous en avons besoin pour comprendre ce qui «devrait» être installé sur l'objet. Sa base est nécessaire comme tampon entre les systèmes productifs avec lesquels toute l'entreprise travaille et les outils réseau internes. Accélère le développement, en ajoutant les champs nécessaires, de nouvelles relations, en ajustant les paramètres, etc. De plus, cette solution est non seulement dans la vitesse de développement, mais aussi en présence de ces relations entre les données dont nous avons besoin, sans compromis. Comme mini-exemple, nous utilisons plusieurs exid dans la base de données pour la communication entre IPAM, SAP et HPSM.

En conséquence, nous avons reçu des données complètes sur tous les objets, avec l'équipement réseau connecté et les adresses IP. Nous avons maintenant besoin de modèles de configuration ou de services réseau que nous fournissons sur ces sites.

Source unique de vérité

Ici, nous venons d'atteindre l'application du premier principe NaaC - le stockage des configurations cibles dans le référentiel. Dans notre cas, c'est Gitlab. Le choix pour nous était simple:

• Premièrement, nous avons déjà cet outil dans notre entreprise, nous n'avons pas eu besoin de le déployer à partir de zéro
• Deuxièmement, il convient parfaitement à toutes nos tâches actuelles et futures sur l'infrastructure réseau

La principale partie intéressante de l'automatisation se produira dans Gitlab - le processus de modification de la norme de configuration ou, plus simplement, du modèle.

Exemple de processus de changement standard

L'un des types d'objets que nous avons est le magasin Pyaterochka. Là, une topologie typique se compose d'un routeur et d'un / deux commutateurs. Le fichier de configuration du modèle est stocké dans Gitlab, dans cette partie tout est simple. Mais ce n'est pas tout à fait NaaC.

Supposons maintenant qu'un nouveau projet nous arrive. Les tâches du nouveau projet informatique sont de réaliser un pilote dans un certain volume de magasins. Selon les résultats du pilote - en cas de succès, effectuez une réplication pour tous les objets de ce type; sinon réduisez le pilote sans effectuer de réplication.

Ce processus s'intègre très bien dans la logique Git:

1. Pour un nouveau projet, nous créons une branche, où nous apportons des modifications aux configurations.
2. Dans Branch, nous conservons également une liste des objets sur lesquels ce projet est piloté.
3. En cas de succès, nous faisons une demande de fusion dans la branche principale, qui devra être répliquée sur le prod-network
4. En cas d'échec, quittez Branch pour l'historique, ou supprimez simplement

En première approximation - même sans automatisation, c'est un outil très pratique pour travailler ensemble sur une configuration réseau. Surtout si vous imaginez que trois projets ou plus sont arrivés en même temps. Lorsque le moment sera venu de publier les projets dans prod, vous devrez résoudre tous les conflits de configuration dans les demandes de fusion et vérifier que les modifications apportées aux paramètres ne s'excluent pas mutuellement. Et c'est très pratique à faire dans git.

De plus, cette approche nous ajoute la flexibilité d'utiliser les outils Gitlab CI / CD pour tester virtuellement des configurations, pour automatiser la livraison de configurations à un banc de test ou à un groupe pilote d'objets. // Et même sur prod si vous voulez.

Déployer la configuration dans n'importe quel environnement

Initialement, l'objectif principal était précisément la livraison en masse de configurations, en tant qu'outil qui permet très clairement de gagner du temps aux ingénieurs et d'accélérer l'exécution des tâches de configuration. Pour ce faire, avant même le début de la grande activité «Network as a Code», nous avons écrit une solution python pour se connecter à des équipements soit pour collecter des configurations d'équipements, soit pour les configurer. C'est netmiko , c'est pysnmp , c'est jinja2 , etc.

Mais il est temps pour nous de diviser la configuration en bloc en plusieurs sous-espèces:

1. Livraison de configurations pour tester et zones pilotes

   Cet élément est basé sur Gitlab CI, qui vous permet d'activer la remise de la configuration aux zones pilote et de test dans le pipeline.
   
2. Duplication de configurations dans prod

   • Un élément distinct, le plus souvent la réplication vers des appareils 38k a lieu en plusieurs vagues - augmentant le volume - pour surveiller la situation en prod. De plus, un travail de cette ampleur nécessite une coordination du travail, il est donc préférable de démarrer ce processus à la main. Pour cela, il est pratique d'utiliser Ansible + -AWX et d'y fixer la compilation dynamique de l'inventaire de nos systèmes de données de base.
   • En outre, il s'agit d'une solution pratique lorsque vous devez donner à la deuxième ligne le lancement de playbooks préconfigurés qui effectuent des opérations complexes et importantes, telles que la commutation du trafic entre les sites.
3. Collecte de données

   • Découverte automatique des périphériques réseau
   • Configurations de sauvegarde
   • Vérifier la connectivité

   
   Nous avons attribué cette tâche dans un bloc séparé, car il y a des moments où quelqu'un a soudainement démonté un commutateur ou installé un nouvel appareil, mais nous ne le savions pas à l'avance. En conséquence, cet appareil ne sera pas dans nos données de base et tombera du processus de livraison de configuration, de surveillance et, en général, de travail opérationnel. Il arrive que l'équipement ait été installé légitimement, mais la configuration y a été "mal" versée et, pour une raison quelconque, ssh , snmp , aaa ou des mots de passe non standard pour l'accès n'y fonctionnent pas. Pour ce faire, nous avons python pour essayer toutes les méthodes de connexion héritées possibles que nous pourrions avoir dans l'entreprise, faire de la force brute pour tous les anciens mots de passe, et tout cela pour obtenir le morceau de fer et le préparer à travailler avec ansible et à surveiller .
   
   Il existe un moyen simple - de créer plusieurs fichiers d' inventaire pour ansible, où décrire toutes les données possibles pour les connexions (tous les types de fournisseurs avec toutes les paires nom d'utilisateur / mot de passe possibles) et exécuter un playbook pour chaque variante d' inventaire . Nous espérions une meilleure solution, mais lors de la conférence RedHat, l'architecte Ansible a conseillé la même chose. Il est généralement admis que vous savez à l'avance à quoi vous vous connectez.
   Nous voulions une solution universelle - lorsque vous supprimez une sauvegarde, recherchez un nouvel équipement et, s'il est trouvé, ajoutez-le à tous les systèmes nécessaires. Par conséquent, nous choisissons une solution en python - sachez ce qui pourrait être plus beau qu'un programme qui lui-même peut détecter un matériel réseau pour s'y connecter, indépendamment de ce qui y est configuré (dans des limites raisonnables, bien sûr), configurer selon les besoins, supprimer la configuration et, en même temps, Ajoutez des données API aux systèmes requis.
   

Vérification comme la surveillance

L'une des tâches de l'automatisation est, bien sûr, de découvrir ce qui est tombé de cette automatisation. Les 38k ne sont pas tous parfaitement configurés la première fois, il arrive même que quelqu'un installe l'équipement avec ses mains. Et il est nécessaire de suivre ces changements et de rendre justice à la configuration cible.

Il existe trois approches pour vérifier la conformité de la configuration avec la norme:

• Faites une vérification une fois par période - déchargez l'état actuel, comparez avec la cible et corrigez les lacunes identifiées.
• Sans rien vérifier, une fois par période - déployez les configurations cibles. Certes, il y a un risque de casser quelque chose - peut-être qu'il n'y avait pas tout dans la configuration cible.
• Une approche pratique consiste à considérer les différences par rapport à la configuration cible dans Single Source of Truth comme des alertes et à les surveiller par le système de surveillance. Cela comprend: une incompatibilité avec la norme de configuration actuelle, une différence entre le matériel et celui spécifié dans les données de base, une incompatibilité avec les données dans IPAM .

Dans le troisième cas, une option semble transférer ce travail à la gestion des incidents (OS), afin que les incohérences soient éliminées par petites portions tout au long du temps plus d'une fois par urgence.

Zabbix , dont j'ai parlé plus tôt dans l'article «Comment nous avons surveillé 14 000 objets», est notre système de surveillance des objets distribués où nous pouvons effectuer tous les déclencheurs et alertes auxquels nous pouvons penser. Depuis la rédaction du dernier article, nous avons mis à niveau vers Zabbix 4.0 LTS .

Sur la base de Web Zabbix, nous avons mis à jour notre portail de support réseau, où vous pouvez désormais trouver toutes les informations sur un objet de tous nos systèmes sur un seul écran, ainsi que exécuter des scripts pour vérifier les problèmes fréquents.



Nous avons également introduit une nouvelle fonctionnalité - pour nous, Zabbix est devenu, en quelque sorte, un CRON pour le lancement de scripts programmés, tels que les scripts d'intégration système, les scripts de découverte automatique . C'est très pratique lorsque vous devez regarder les scripts actuels et quand et où ils s'exécutent sans vérifier tous les serveurs. Certes, pour les scripts qui s'exécutent pendant plus de 30 secondes, vous aurez besoin d'un lanceur qui les lance sans attendre la fin. Heureusement, c'est simple:




Splunk est une solution qui vous permet de collecter des journaux d'événements à partir de l'équipement réseau, et cela peut également être utilisé pour surveiller l'automatisation. Par exemple, lors de la collecte d'une sauvegarde de configuration, un script python génère un message LOG CFG-5-BACKUP , un routeur ou un commutateur envoie un message à Splunk, dans lequel nous comptons le nombre de messages de ce type provenant de l'équipement réseau. Cela nous permet de suivre la quantité d'équipement que le script a détecté. Et nous voyons combien de morceaux de fer ont pu signaler cela à Splunk et vérifier que les messages de tous les morceaux de fer sont arrivés.
Spectrum est un système complet que nous utilisons pour surveiller les objets critiques, un outil plutôt puissant qui nous aide beaucoup à résoudre les incidents réseau critiques. Dans l'automatisation, nous l'utilisons uniquement en extrayant des données, ce n'est pas open-source , donc les possibilités sont quelque peu limitées.

La cerise sur le gâteau

En utilisant des systèmes avec des données de base sur l'équipement, nous pouvons penser à créer ZTP, ou Zero Touch Provisioning. Comme un bouton "auto-tuning", mais seulement sans bouton.

Nous avons toutes les données nécessaires des blocs précédents - nous connaissons l'objet, son type, quel équipement est là (fournisseur et modèle), quelles adresses sont là (IPAM), quelle est la norme de configuration actuelle (Git). En les rassemblant tous, nous pouvons au moins préparer un modèle de configuration pour le téléchargement sur l'appareil, ce sera plus comme One Touch Provisioning, mais parfois plus n'est pas nécessaire.

True Zero Touch a besoin d'un moyen de fournir automatiquement la configuration à du matériel non configuré. De plus, il est souhaitable quel que soit le fournisseur. Il existe plusieurs options de travail - un serveur de console, si tout l'équipement passe par l'entrepôt central, des solutions de console mobile, si l'équipement arrive immédiatement. Nous travaillons simplement sur ces solutions, mais dès qu'il y a une option de travail, nous pouvons la partager.

Conclusion

Au total, dans notre concept de réseau en tant que code , il y avait 5 étapes principales:

• Données de base (communication des systèmes et des données entre eux, API des systèmes, suffisance des données pour le support et le lancement)
• Surveillance des données et des configurations (découverte automatique des périphériques réseau, vérification de la pertinence de la configuration dans l'installation)
• Contrôle de version, tests et configurations de pilotage (Gitlab CI / CD appliqué au réseau, outils de test de configuration réseau)
• Livraison de la configuration (Ansible, AWX, scripts python pour se connecter)
• Zero Touch Provisioning (quelles données sont nécessaires, comment construire un processus pour qu'il soit, comment se connecter à un matériel non configuré)

Cela n'a pas fonctionné de tout intégrer dans un seul article, chaque élément mérite une discussion distincte, nous pouvons parler de quelque chose maintenant, de quelque chose lorsque nous vérifions les solutions dans la pratique. Si vous êtes intéressé par l'un des sujets - à la fin, il y aura un sondage où vous pourrez voter pour le prochain article. Si le sujet n'est pas inclus dans la liste, mais qu'il est intéressant de le lire, laissez un commentaire dès que possible, assurez-vous de partager notre expérience.

---

Un merci spécial à Virilin Alexander ( xscrew ) et Sibgatulin Marat ( eucariot ) pour la visite de référence à l'automne 2018 sur le cloud yandex et l'histoire de l'automatisation dans l'infrastructure de réseau cloud. Après lui, nous avons trouvé l'inspiration et beaucoup d'idées sur l'utilisation de l'automatisation et de NetDevOps dans l'infrastructure du X5 Retail Group.