Le SDSM est terminé, mais le désir incontrôlable d’écrire demeure.

Pendant de nombreuses années, notre frère a souffert du travail de routine, croisant les doigts avant de s'engager et manquant de sommeil à cause des reculs nocturnes.
Mais les temps sombres touchent à leur fin.

Avec cet article, je vais commencer une série sur la façon dont moi l'automatisation est visible.
En chemin, nous comprendrons les étapes d'automatisation, de stockage des variables, de formalisation de la conception, RestAPI, NETCONF, YANG, YDK et nous ferons beaucoup de programmation.
Moi signifie que a) ce n'est pas une vérité objective, b) ce n'est pas inconditionnellement la meilleure approche, c) mon opinion, même pendant le passage du premier au dernier article, peut changer - pour être honnête, du stade du projet au publication, j’ai tout réécrit complètement deux fois.

Teneur

1. Objectifs
   1. Le réseau est comme un organisme unique
   2. Tests de configuration
   3. Gestion des versions
   4. Surveillance et auto-réparation des services

2. Fonds
   1. systeme d'inventaire
   2. Système de gestion d'espace IP
   3. Système de description de service réseau
   4. Mécanisme d'initialisation de l'appareil
   5. Modèle de configuration indépendant du fournisseur
   6. Interface de pilote spécifique au fournisseur
   7. Mécanisme de livraison de la configuration à l'appareil
   8. CI / CD
   9. Mécanisme de sauvegarde et de recherche d'écarts
   10. Système de surveillance

3. Conclusion

Je vais essayer de réaliser l'ADSM dans un format légèrement différent du SDSM. Des articles volumineux, détaillés et numérotés continueront à paraître, et entre eux je publierai de petites notes tirées de mon expérience quotidienne. Je vais essayer de combattre le perfectionnisme ici et de ne pas les lécher chacun.

Comme c'est drôle que la deuxième fois il faille suivre le même chemin.

Au début, j'ai dû écrire moi-même des articles sur les réseaux car ils n'étaient pas sur RuNet.

Maintenant, je n'ai pas pu trouver de document complet qui systématiserait les approches d'automatisation et analyserait les technologies ci-dessus à l'aide d'exemples pratiques simples.

Je me trompe peut-être, alors veuillez fournir des liens vers des ressources utiles. Cependant, cela ne changera pas ma détermination à écrire, car l'objectif principal est d'apprendre quelque chose par moi-même, et rendre la vie plus facile aux autres est un bonus agréable qui caresse le gène du partage d'expériences.

Nous essaierons de prendre un centre de données LAN DC de taille moyenne et d'élaborer l'ensemble du schéma d'automatisation.
Je ferai certaines choses presque pour la première fois avec toi.

Je ne serai pas original dans les idées et les outils décrits ici. Dmitry Figol a un excellent chaîne avec des flux sur ce sujet.
Les articles les recouperont à bien des égards.

Le LAN DC comprend 4 DC, environ 250 commutateurs, une demi-douzaine de routeurs et quelques pare-feu.
Pas Facebook, mais suffisamment pour vous faire réfléchir profondément à l'automatisation.
Il existe cependant une opinion selon laquelle si vous possédez plus d'un appareil, l'automatisation est déjà nécessaire.
En fait, il est difficile d’imaginer que quiconque puisse désormais vivre sans au moins un pack de scripts knee.
Bien que j'aie entendu dire qu'il existe des bureaux où les adresses IP sont conservées dans Excel, et que chacun des milliers de périphériques réseau est configuré manuellement et possède sa propre configuration unique. Bien sûr, cela peut être présenté comme de l’art moderne, mais les sentiments de l’ingénieur seront certainement offensés.

Objectifs

Nous allons maintenant fixer les objectifs les plus abstraits :

• Le réseau est comme un organisme unique
• Tests de configuration
• Versionnement de l'état du réseau
• Surveillance et auto-réparation des services

Plus loin dans cet article, nous examinerons les moyens que nous utiliserons, et dans ce qui suit, nous examinerons les objectifs et les moyens en détail.

Le réseau est comme un organisme unique

La phrase déterminante du cycle, même si à première vue elle peut ne pas sembler si significative : nous configurerons le réseau, pas les appareils individuels.
Ces dernières années, nous avons assisté à un changement d’orientation vers le traitement du réseau comme une entité unique, d’où la Software Defined Networking, Réseaux axés sur l'intention и Réseaux autonomes.
Après tout, de quoi les applications ont-elles besoin globalement du réseau : une connectivité entre les points A et B (enfin, parfois +B-Z) et une isolation des autres applications et utilisateurs.

Et donc notre tâche dans cette série est construire un système, en conservant la configuration actuelle tout le réseau, qui est déjà décomposé en configuration réelle sur chaque appareil en fonction de son rôle et de son emplacement.
Système la gestion du réseau implique que pour apporter des modifications, nous le contactons et il calcule à son tour l'état souhaité pour chaque appareil et le configure.
De cette façon, nous minimisons l'accès manuel à la CLI à presque zéro - toute modification dans les paramètres de l'appareil ou la conception du réseau doit être formalisée et documentée - et ensuite seulement déployée sur les éléments réseau nécessaires.

Autrement dit, si nous décidions que désormais les commutateurs à rack à Kazan devraient annoncer deux réseaux au lieu d'un, nous

1. Nous documentons d’abord les changements dans les systèmes
2. Génération de la configuration cible de tous les périphériques réseau
3. Nous lançons le programme de mise à jour de la configuration réseau, qui calcule ce qui doit être supprimé sur chaque nœud, ce qu'il faut ajouter et amène les nœuds à l'état souhaité.

Dans le même temps, nous apportons des modifications manuellement uniquement lors de la première étape.

Tests de configuration

Est connuque 80 % des problèmes surviennent lors des changements de configuration - une preuve indirecte en est que pendant les vacances du Nouvel An, tout est généralement calme.
J'ai personnellement été témoin de dizaines de temps d'arrêt globaux dus à une erreur humaine : mauvaise commande, configuration exécutée dans la mauvaise branche, la communauté a oublié, MPLS a été démoli globalement sur le routeur, cinq éléments matériels ont été configurés, mais l'erreur n'a pas été détectée. remarqué le sixième, d'anciennes modifications apportées par une autre personne ont été commises. Il existe une tonne de scénarios.

L’automatisation nous permettra de faire moins d’erreurs, mais à plus grande échelle. De cette façon, vous pouvez connecter non pas un seul appareil, mais l’ensemble du réseau à la fois.

Depuis des temps immémoriaux, nos grands-pères vérifiaient avec un œil attentif l'exactitude des modifications apportées et la fonctionnalité du réseau après leur déploiement.
Les grands-pères dont le travail a entraîné des temps d'arrêt et des pertes catastrophiques ont laissé moins de descendants et devraient disparaître avec le temps, mais l'évolution est un processus lent et, par conséquent, tout le monde ne teste pas encore d'abord les changements en laboratoire.
Cependant, à l'avant-garde du progrès se trouvent ceux qui ont automatisé le processus de test de la configuration et son application ultérieure au réseau. Autrement dit, j'ai emprunté la procédure CI/CD (Intégration continue, déploiement continu) des développeurs.
Dans l'une des parties, nous verrons comment implémenter cela à l'aide d'un système de contrôle de version, probablement Github.

Une fois habitué à l'idée du CI/CD en réseau, du jour au lendemain, la méthode de vérification d'une configuration en l'appliquant à un réseau de production ressemblera à une ignorance du début du Moyen Âge. Un peu comme frapper une ogive avec un marteau.

Une continuation organique des idées sur système la gestion du réseau et CI/CD devient un versioning complet de la configuration.

Gestion des versions

Nous supposerons qu'avec tout changement, aussi petit soit-il, même sur un appareil imperceptible, l'ensemble du réseau passe d'un état à un autre.
Et nous n'exécutons toujours pas de commande sur l'appareil, nous modifions l'état du réseau.
Alors appelons ces états versions ?

Disons que la version actuelle est la 1.0.0.
L’adresse IP de l’interface Loopback sur l’un des ToR a-t-elle changé ? Il s'agit d'une version mineure et sera numérotée 1.0.1.
Nous avons révisé les politiques d'importation de routes dans BGP - un peu plus sérieusement - déjà 1.1.0
Nous avons décidé de nous débarrasser d'IGP et de passer uniquement à BGP - c'est déjà un changement radical de conception - 2.0.0.

Dans le même temps, différents DC peuvent avoir des versions différentes - le réseau se développe, de nouveaux équipements sont installés, de nouveaux niveaux de spines sont ajoutés quelque part, pas ailleurs, etc.

Sur versionnement sémantique nous en parlerons dans un article séparé.

Je le répète, tout changement (à l'exception des commandes de débogage) est une mise à jour de version. Les administrateurs doivent être informés de tout écart par rapport à la version actuelle.

Il en va de même pour l'annulation des modifications - il ne s'agit pas d'annuler les dernières commandes, il ne s'agit pas d'une annulation utilisant le système d'exploitation de l'appareil - cela amène l'ensemble du réseau vers une nouvelle (ancienne) version.

Surveillance et auto-réparation des services

Cette tâche évidente a atteint un nouveau niveau dans les réseaux modernes.
Souvent, les grands fournisseurs de services estiment qu’un service défaillant doit être réparé très rapidement et qu’un nouveau doit être créé, au lieu de comprendre ce qui s’est passé.
«Très» signifie que vous devez être généreusement couvert de tous côtés par une surveillance qui détectera en quelques secondes les moindres écarts par rapport à la norme.
Et ici, les métriques habituelles, comme le chargement de l’interface ou la disponibilité des nœuds, ne suffisent plus. Leur surveillance manuelle par l'agent de service ne suffit pas non plus.
Pour beaucoup de choses, il devrait y avoir Auto-guérison — les voyants de surveillance sont devenus rouges et nous sommes allés appliquer nous-mêmes le plantain là où ça faisait mal.

Et ici, nous surveillons également non seulement les appareils individuels, mais également la santé de l'ensemble du réseau, à la fois la boîte blanche, qui est relativement compréhensible, et la boîte noire, qui est plus compliquée.

De quoi aurons-nous besoin pour mettre en œuvre des plans aussi ambitieux ?

• Ayez une liste de tous les appareils sur le réseau, leur emplacement, leurs rôles, leurs modèles et leurs versions logicielles.
  kazan-leaf-1.lmu.net, Kazan, feuille, Genévrier QFX 5120, R18.3.
• Disposer d'un système de description des services réseau.
  IGP, BGP, L2/3VPN, politique, ACL, NTP, SSH.
• Être capable d'initialiser l'appareil.
  Nom d'hôte, IP de gestion, route de gestion, utilisateurs, clés RSA, LLDP, NETCONF
• Configurez l'appareil et amenez la configuration à la version souhaitée (y compris l'ancienne).
• Configuration des tests
• Vérifiez périodiquement l'état de tous les appareils pour déceler les écarts par rapport à ceux actuels et signalez à qui cela doit être.
  Du jour au lendemain, quelqu'un a discrètement ajouté une règle à l'ACL.
• Les performances du moniteur.

Fonds

Cela semble déjà assez compliqué pour commencer à décomposer le projet en composants.

Et il y en aura dix :

1. systeme d'inventaire
2. Système de gestion d'espace IP
3. Système de description de service réseau
4. Mécanisme d'initialisation de l'appareil
5. Modèle de configuration indépendant du fournisseur
6. Interface de pilote spécifique au fournisseur
7. Mécanisme de livraison de la configuration à l'appareil
8. CI / CD
9. Mécanisme de sauvegarde et de recherche d'écarts
10. Système de surveillance

Soit dit en passant, c'est un exemple de la façon dont la vision des objectifs du cycle a changé - il y avait 4 éléments dans le projet.

Dans l'illustration, j'ai représenté tous les composants et l'appareil lui-même.
Les composants qui se croisent interagissent les uns avec les autres.
Plus le bloc est grand, plus il faut prêter attention à ce composant.

Composante 1 : Système d'inventaire

Évidemment, nous voulons savoir quel équipement se trouve, où, à quoi il est connecté.
Le système d'inventaire fait partie intégrante de toute entreprise.
Le plus souvent, une entreprise dispose d'un système d'inventaire distinct pour les périphériques réseau, qui résout des problèmes plus spécifiques.
Dans le cadre de cette série d’articles, nous l’appellerons DCIM – Data Center Infrastructure Management. Bien que le terme DCIM lui-même, à proprement parler, englobe bien plus.

Pour nos besoins, nous y stockerons les informations suivantes sur l'appareil :

• Numéro d'inventaire
• Description du titre
• Modèle (Huawei CE12800, genévrier QFX5120, etc.)
• Paramètres caractéristiques (cartes, interfaces, etc.)
• Rôle (Feuille, colonne vertébrale, routeur de bordure, etc.)
• Emplacement (région, ville, centre de données, rack, unité)
• Interconnexions entre appareils
• Topologie du réseau

Il est parfaitement clair que nous voulons nous-mêmes savoir tout cela.
Mais cela sera-t-il utile à des fins d’automatisation ?
Certainement.
Par exemple, nous savons que dans un centre de données donné sur des commutateurs Leaf, s'il s'agit de Huawei, les ACL pour filtrer certains trafics doivent être appliquées sur le VLAN, et s'il s'agit de Juniper, alors sur l'unité 0 de l'interface physique.
Ou vous devez déployer un nouveau serveur Syslog sur toutes les frontières de la région.

Nous y stockerons des périphériques de réseau virtuel, par exemple des routeurs virtuels ou des réflecteurs racine. On peut ajouter des serveurs DNS, NTP, Syslog et en général tout ce qui concerne d'une manière ou d'une autre le réseau.

Composante 2 : Système de gestion de l'espace IP

Oui, et de nos jours, il existe des équipes de personnes qui assurent le suivi des préfixes et des adresses IP dans un fichier Excel. Mais l’approche moderne reste une base de données, avec un front-end sur nginx/apache, une API et des fonctions étendues d’enregistrement des adresses IP et des réseaux divisés en VRF.
IPAM - Gestion des adresses IP.

Pour nos besoins, nous y stockerons les informations suivantes :

• VLAN
• VRF
• Réseaux/sous-réseaux
• Adresses IP
• Liaison des adresses aux appareils, des réseaux aux emplacements et aux numéros de VLAN

Encore une fois, il est clair que nous voulons nous assurer que lorsque nous allouons une nouvelle adresse IP pour le bouclage ToR, nous ne trébucherons pas sur le fait qu'elle a déjà été attribuée à quelqu'un. Ou que nous avons utilisé deux fois le même préfixe à différentes extrémités du réseau.
Mais en quoi cela contribue-t-il à l’automatisation ?
C'est facile.
Nous demandons un préfixe dans le système avec le rôle Loopbacks, qui contient les adresses IP disponibles pour l'attribution - s'il est trouvé, nous attribuons l'adresse, sinon, nous demandons la création d'un nouveau préfixe.
Ou lors de la création d'une configuration de périphérique, nous pouvons savoir à partir du même système dans quel VRF l'interface doit être située.
Et lors du démarrage d'un nouveau serveur, le script se connecte au système, découvre dans quel commutateur se trouve le serveur, quel port et quel sous-réseau est attribué à l'interface - et attribuera l'adresse du serveur à partir de celui-ci.

Cela suggère une volonté de combiner DCIM et IPAM en un seul système afin de ne pas dupliquer les fonctions et de ne pas servir deux entités similaires.
C'est ce que nous ferons.

Composant 3. Système de description des services réseau

Si les deux premiers systèmes stockent des variables qui doivent encore être utilisées d'une manière ou d'une autre, le troisième décrit pour chaque rôle de périphérique comment il doit être configuré.
Il convient de distinguer deux types différents de services réseau :

• Infrastructure
• Client.

Les premiers sont conçus pour fournir une connectivité de base et un contrôle des appareils. Ceux-ci incluent VTY, SNMP, NTP, Syslog, AAA, les protocoles de routage, CoPP, etc.
Ces derniers organisent le service pour le client : MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Bien sûr, il existe également des cas limites : où inclure MPLS LDP, BGP ? Oui, et les protocoles de routage peuvent être utilisés pour les clients. Mais ce n'est pas important.

Les deux types de services sont décomposés en primitives de configuration :

• interfaces physiques et logiques (tag/anteg, mtu)
• Adresses IP et VRF (IP, IPv6, VRF)
• ACL et politiques de traitement du trafic
• Protocoles (IGP, BGP, MPLS)
• Politiques de routage (listes de préfixes, communautés, filtres ASN).
• Services utilitaires (SSH, NTP, LLDP, Syslog...)
• Etc.

Comment exactement nous allons procéder, je n’en ai pas encore la moindre idée. Nous y reviendrons dans un article séparé.

Si c'était un peu plus proche de la vie, alors nous pourrions décrire cela
Le commutateur Leaf doit avoir des sessions BGP avec tous les commutateurs Spine connectés, importer les réseaux connectés dans le processus et accepter uniquement les réseaux d'un certain préfixe des commutateurs Spine. Limitez CoPP IPv6 ND à 10 pps, etc.
À leur tour, les épines organisent des sessions avec tous les leads connectés, agissant comme des réflecteurs racines, et n'acceptent d'eux que des itinéraires d'une certaine longueur et avec une certaine communauté.

Composant 4 : mécanisme d'initialisation du périphérique

Sous cette rubrique, je regroupe de nombreuses actions qui doivent se produire pour qu'un appareil apparaisse sur le radar et soit accessible à distance.

1. Entrez l'appareil dans le système d'inventaire.
2. Sélectionnez une adresse IP de gestion.
3. Configurez un accès de base à celui-ci :
   Nom d'hôte, adresse IP de gestion, itinéraire vers le réseau de gestion, utilisateurs, clés SSH, protocoles - telnet/SSH/NETCONF

Il existe trois approches :

• Tout est entièrement manuel. L'appareil est amené au stand, où une personne organique ordinaire le saisira dans les systèmes, se connectera à la console et le configurera. Peut fonctionner sur de petits réseaux statiques.
• ZTP - Approvisionnement sans contact. Le matériel est arrivé, s'est levé, a reçu une adresse via DHCP, s'est rendu sur un serveur spécial et s'est configuré lui-même.
• L'infrastructure des serveurs de console, où la configuration initiale s'effectue via le port console en mode automatique.

Nous parlerons des trois dans un article séparé.

Composant 5 : modèle de configuration indépendant du fournisseur

Jusqu'à présent, tous les systèmes étaient constitués de correctifs disparates qui fournissaient des variables et une description déclarative de ce que nous aimerions voir sur le réseau. Mais tôt ou tard, vous devrez faire face à des détails.
À ce stade, pour chaque périphérique spécifique, les primitives, les services et les variables sont combinés dans un modèle de configuration qui décrit réellement la configuration complète d'un périphérique spécifique, uniquement d'une manière indépendante du fournisseur.
A quoi sert cette étape ? Pourquoi ne pas créer immédiatement une configuration d'appareil que vous pouvez simplement télécharger ?
En fait, cela résout trois problèmes :

1. Ne vous adaptez pas à une interface spécifique pour interagir avec l'appareil. Que ce soit CLI, NETCONF, RESTCONF, SNMP, le modèle sera le même.
2. Ne conservez pas le nombre de modèles/scripts en fonction du nombre de fournisseurs sur le réseau, et si le design change, changez la même chose à plusieurs endroits.
3. Chargez la configuration depuis l'appareil (sauvegarde), placez-la exactement dans le même modèle et comparez directement la configuration cible avec celle existante pour calculer le delta et préparer un correctif de configuration qui modifiera uniquement les parties nécessaires ou identifiera les écarts.

À la suite de cette étape, nous obtenons une configuration indépendante du fournisseur.

Composant 6. Interface de pilote spécifique au fournisseur

Il ne faut pas se flatter d'espérer qu'un jour il sera possible de configurer un ciska exactement de la même manière qu'un Juniper, simplement en leur envoyant exactement les mêmes appels. Malgré la popularité croissante des boîtes blanches et l'émergence de la prise en charge de NETCONF, RESTCONF, OpenConfig, le contenu spécifique fourni par ces protocoles diffère d'un fournisseur à l'autre, et c'est l'une de leurs différences concurrentielles qu'ils n'abandonneront pas si facilement.
C'est à peu près la même chose qu'OpenContrail et OpenStack, qui ont RestAPI comme interface NorthBound, s'attendent à des appels complètement différents.

Ainsi, dans la cinquième étape, le modèle indépendant du fournisseur doit prendre la forme dans laquelle il sera transmis au matériel.
Et là tous les moyens sont bons (pas) : CLI, NETCONF, RESTCONF, SNMP simplement.

Par conséquent, nous aurons besoin d'un pilote qui transférera le résultat de l'étape précédente dans le format requis d'un fournisseur spécifique : un ensemble de commandes CLI, une structure XML.

Composant 7. Mécanisme de livraison de la configuration à l'appareil

Nous avons généré la configuration, mais elle doit encore être livrée aux appareils - et bien sûr pas manuellement.
D'abord, nous sommes confrontés à la question de savoir quel moyen de transport allons-nous utiliser ? Et aujourd'hui, le choix n'est plus restreint :

• CLI (telnet, ssh)
• SNMP
• CONF NET
• RESTCONF
• API REST
• OpenFlow (bien que ce soit une valeur aberrante car c'est un moyen de fournir FIB, pas des paramètres)

Mettons les points sur les t ici. La CLI est héritée. SNMP... toux toux.
RESTCONF est encore un animal inconnu ; l'API REST n'est supportée par presque personne. Par conséquent, nous nous concentrerons sur NETCONF dans cette série.

En fait, comme le lecteur l'a déjà compris, à ce stade, nous avons déjà décidé de l'interface - le résultat de l'étape précédente est déjà présenté dans le format de l'interface choisie.

deuxièmement, et avec quels outils allons-nous faire cela ?
Il y a aussi un large choix ici :

• Script ou plateforme auto-écrit. Armons-nous de ncclient et asyncIO et faisons tout nous-mêmes. Combien cela nous coûte-t-il de créer un système de déploiement à partir de zéro ?
• Ansible avec sa riche bibliothèque de modules réseau.
• Salt avec son maigre travail avec le réseau et sa connexion avec Napalm.
• En fait Napalm, qui connaît quelques vendeurs et c'est tout, au revoir.
• Nornir est un autre animal que nous disséquerons dans le futur.

Ici, le favori n'a pas encore été choisi, nous allons chercher.

Qu’est-ce qui est important ici ? Conséquences de l'application de la configuration.
Réussi ou pas. Y a-t-il toujours accès au matériel ou non ?
Il semble que la validation aidera ici à confirmer et à valider ce qui a été téléchargé sur l'appareil.
Ceci, combiné à la mise en œuvre correcte de NETCONF, réduit considérablement la gamme de périphériques appropriés - peu de fabricants prennent en charge les validations normales. Mais ce n'est qu'une des conditions préalables à DP. En fin de compte, personne ne s'inquiète du fait qu'aucun fournisseur russe ne respectera la condition d'interface 32*100GE. Ou est-il inquiet ?

Composante 8. CI/CD

À ce stade, la configuration est déjà prête pour tous les périphériques réseau.
J'écris « pour tout » car nous parlons de versionner l'état du réseau. Et même si vous devez modifier les paramètres d'un seul commutateur, les modifications sont calculées pour l'ensemble du réseau. Évidemment, ils peuvent être nuls pour la plupart des nœuds.

Mais comme nous l’avons déjà dit plus haut, nous ne sommes pas des barbares qui veulent tout mettre directement en production.
La configuration générée doit d’abord passer par Pipeline CI/CD.

CI/CD signifie Intégration Continue, Déploiement Continu. Il s'agit d'une approche dans laquelle l'équipe publie non seulement une nouvelle version majeure tous les six mois, remplaçant complètement l'ancienne, mais implémente régulièrement (déploiement) de nouvelles fonctionnalités par petites portions, dont chacune est entièrement testée pour la compatibilité, la sécurité et performances (Intégration).

Pour ce faire, nous disposons d'un système de contrôle de version qui surveille les modifications de configuration, d'un laboratoire qui vérifie si le service client est en panne, d'un système de surveillance qui vérifie ce fait, et la dernière étape consiste à déployer les modifications sur le réseau de production.

À l'exception des commandes de débogage, absolument toutes les modifications sur le réseau doivent passer par le pipeline CI/CD - c'est notre garantie d'une vie tranquille et d'une carrière longue et heureuse.

Composante 9. Système de sauvegarde et de détection des anomalies

Eh bien, il n’est pas nécessaire de reparler de sauvegardes.
Nous les ajouterons simplement à la couronne ou lors d'un changement de configuration dans git.

Mais la deuxième partie est plus intéressante : quelqu'un devrait garder un œil sur ces sauvegardes. Et dans certains cas, ce quelqu'un doit tout retourner tel qu'il était, et dans d'autres, miauler à quelqu'un que quelque chose ne va pas.
Par exemple, si un nouvel utilisateur est apparu qui n'est pas enregistré dans les variables, vous devez le retirer du hack. Et s'il vaut mieux ne pas toucher à une nouvelle règle de pare-feu, peut-être que quelqu'un vient d'activer le débogage, ou peut-être que le nouveau service, un gâchis, n'a pas été enregistré conformément à la réglementation, mais que des personnes l'ont déjà rejoint.

Nous n’échapperons toujours pas à un petit delta à l’échelle de l’ensemble du réseau, malgré les systèmes d’automatisation et la main d’acier de la direction. Pour déboguer les problèmes, personne n’ajoutera de toute façon une configuration aux systèmes. De plus, ils peuvent même ne pas être inclus dans le modèle de configuration.

Par exemple, une règle de pare-feu permettant de compter le nombre de paquets par IP spécifique afin de localiser un problème est une configuration temporaire tout à fait ordinaire.

Composante 10. Système de surveillance

Au début, je n’allais pas aborder le sujet du contrôle – il s’agit encore d’un sujet volumineux, controversé et complexe. Mais au fur et à mesure que les choses avançaient, il s’est avéré que cela faisait partie intégrante de l’automatisation. Et il est impossible de le contourner, même sans pratique.

L'évolution de la pensée fait partie intégrante du processus CI/CD. Après avoir déployé la configuration sur le réseau, nous devons être en mesure de déterminer si tout va bien maintenant.
Et nous ne parlons pas seulement et pas tant de calendriers d'utilisation de l'interface ou de disponibilité des nœuds, mais de choses plus subtiles - la présence des routes nécessaires, leurs attributs, le nombre de sessions BGP, les voisins OSPF, les performances de bout en bout. des services sous-jacents.
Les journaux système envoyés au serveur externe ont-ils cessé de s'additionner, ou l'agent SFlow est-il tombé en panne, ou les pertes dans les files d'attente ont-elles commencé à augmenter, ou la connectivité entre une paire de préfixes s'est-elle interrompue ?

Nous y réfléchirons dans un article séparé.

Conclusion

Comme base, j'ai choisi l'une des conceptions de réseau de centre de données modernes - L3 Clos Fabric avec BGP comme protocole de routage.
Cette fois, nous allons construire le réseau sur Juniper, car désormais l'interface JunOs est un vanlove.

Rendons-nous la vie plus difficile en utilisant uniquement des outils Open Source et un réseau multifournisseur - donc en plus de Juniper, je choisirai une autre personne chanceuse en cours de route.

Le plan pour les prochaines publications ressemble à ceci :
Je vais d'abord parler des réseaux virtuels. D’abord parce que je le souhaite, et ensuite parce que sans cela, la conception du réseau d’infrastructures ne sera pas très claire.
Ensuite, sur la conception du réseau elle-même : topologie, routage, politiques.
Assemblons un stand de laboratoire.
Réfléchissons-y et entraînons-nous peut-être à initialiser l'appareil sur le réseau.
Et puis sur chaque composant en détail.

Et oui, je ne promets pas de terminer ce cycle en beauté avec une solution toute faite. 🙂

Liens utiles

• Avant de plonger dans la série, cela vaut la peine de lire le livre de Natasha Samoilenko Python pour les ingénieurs réseau. Et peut-être passer cours.
• Il sera également utile de lire RFC sur la conception des usines de centres de données de Facebook par Peter Lapukhov.
• La documentation sur l'architecture vous donnera une idée du fonctionnement d'Overlay SDN. Tissu de tungstène (anciennement Open Contrail).

Merci

Gorges romaines. Pour les commentaires et les modifications.
Artyom Tchernobaï. Pour KDPV.

Source: habr.com