Hé Habr !
Dans cet article, nous aimerions parler de l'automatisation de l'infrastructure réseau. Un schéma fonctionnel du réseau qui fonctionne dans une petite mais très fière entreprise sera présenté. Toutes les correspondances avec un équipement réseau réel sont aléatoires. Nous examinerons un cas survenu dans ce réseau, qui aurait pu entraîner un arrêt prolongé de l'entreprise et de graves pertes financières. La solution à ce cas s’inscrit très bien dans le concept « d’automatisation de l’infrastructure réseau ». À l'aide d'outils d'automatisation, nous montrerons comment vous pouvez résoudre efficacement des problèmes complexes en peu de temps, et nous réfléchirons aux raisons pour lesquelles ces problèmes doivent être résolus de cette manière et pas autrement (via la console).
Clause de non-responsabilité
Nos principaux outils d'automatisation sont Ansible (en tant qu'outil d'automatisation) et Git (en tant que référentiel pour les playbooks Ansible). Je voudrais immédiatement faire une réserve sur le fait qu'il ne s'agit pas d'un article d'introduction, dans lequel nous parlons de la logique d'Ansible ou de Git, et expliquons des choses de base (par exemple, que sont les modules de rôle, les fichiers d'inventaire, les variables dans Ansible, ou que se passe-t-il quand vous entrez les commandes git push ou git commit). Cette histoire ne porte pas sur la façon dont vous pouvez pratiquer Ansible et configurer NTP ou SMTP sur votre équipement. C'est une histoire sur la façon dont vous pouvez résoudre rapidement et de préférence un problème de réseau sans erreurs. Il est également conseillé d'avoir une bonne compréhension du fonctionnement du réseau, notamment ce qu'est la pile protocolaire TCP/IP, OSPF, BGP. Nous retirerons également de l’équation le choix d’Ansible et de Git. Si vous devez encore choisir une solution spécifique, nous vous recommandons fortement de lire le livre « Network Programmability and Automation. Compétences pour l'ingénieur réseau de nouvelle génération" par Jason Edelman, Scott S. Lowe et Matt Oswalt.
Maintenant au point.
Formulation du problème
Imaginons une situation : 3 heures du matin, vous dormez profondément et vous rêvez. Appel téléphonique. Le directeur technique appelle :
- oui
— ###, ####, #####, le cluster de pare-feu est tombé et ne se lève pas !!!
Vous vous frottez les yeux, essayant de comprendre ce qui se passe et d’imaginer comment cela pourrait arriver. Au téléphone, on entend les cheveux du directeur s'arracher et il demande à rappeler car le général l'appelle sur la deuxième ligne.
Une demi-heure plus tard, vous avez récupéré les premières notes d'introduction du quart de travail et avez réveillé tous ceux qui pouvaient être réveillés. Du coup, le directeur technique n'a pas menti, tout est comme ça, le principal groupe de pare-feu est tombé, et aucun mouvement corporel basique ne le ramène à la raison. Tous les services proposés par l'entreprise ne fonctionnent pas.
Choisissez un problème à votre goût, chacun se souviendra de quelque chose de différent. Par exemple, après une mise à jour nocturne en l’absence de lourde charge, tout a bien fonctionné et tout le monde s’est couché heureux. Le trafic a commencé à circuler et les tampons de l'interface ont commencé à déborder en raison d'un bug dans le pilote de la carte réseau.
Jackie Chan peut bien décrire la situation.
Merci, Jackie.
Ce n’est pas une situation très agréable, n’est-ce pas ?
Laissons notre frère du réseau avec ses tristes pensées pour un moment.
Discutons de la manière dont les événements vont évoluer.
Nous suggérons l'ordre suivant de présentation du matériel
- Regardons le schéma du réseau et voyons comment il fonctionne ;
- Nous décrirons comment nous transférons les paramètres d'un routeur à un autre à l'aide d'Ansible ;
- Parlons de l'automatisation de l'infrastructure informatique dans son ensemble.
Schéma et description du réseau
Conduire
Considérons le schéma logique de notre organisation. Nous ne nommerons pas de fabricants d'équipements spécifiques ; pour les besoins de cet article, cela n'a pas d'importance (Le lecteur attentif devinera quel type d'équipement est utilisé). Ce n’est qu’un des bons avantages de travailler avec Ansible : lors de la configuration, nous ne nous soucions généralement pas de quel type d’équipement il s’agit. Juste pour comprendre, il s'agit d'équipements provenant de fournisseurs bien connus, tels que Cisco, Juniper, Check Point, Fortinet, Palo Alto... vous pouvez remplacer votre propre option.
Nous avons deux tâches principales pour déplacer le trafic :
- Assurer la publication de nos services, qui sont l'activité de l'entreprise ;
- Assurer la communication avec les succursales, un centre de données distant et les organisations tierces (partenaires et clients), ainsi que l'accès des succursales à Internet via le bureau central.
Commençons par les éléments de base :
- Deux routeurs frontaliers (BRD-01, BRD-02) ;
- Cluster de pare-feu (FW-CLUSTER) ;
- Commutateur principal (L3-CORE) ;
- Un routeur qui deviendra une bouée de sauvetage (au fur et à mesure que nous résolvons le problème, nous transférerons les paramètres réseau de FW-CLUSTER vers EMERGENCY) (EMERGENCY) ;
- Commutateurs pour la gestion de l'infrastructure réseau (L2-MGMT) ;
- Machine virtuelle avec Git et Ansible (VM-AUTOMATION);
- Un ordinateur portable sur lequel sont effectués les tests et le développement de playbooks pour Ansible (Laptop-Automation).
Le réseau est configuré avec un protocole de routage dynamique OSPF avec les zones suivantes :
- Zone 0 – zone qui comprend les routeurs responsables du déplacement du trafic dans la zone EXCHANGE ;
- Zone 1 – zone qui comprend les routeurs responsables du fonctionnement des services de l'entreprise ;
- Zone 2 – zone qui comprend les routeurs responsables de la gestion du routage du trafic ;
- Zone N – zones des réseaux de succursales.
Sur les routeurs frontaliers, un routeur virtuel (VRF-INTERNET) est créé, sur lequel la vue complète eBGP est installée avec l'AS attribué correspondant. iBGP est configuré entre les VRF. La société dispose d'un pool d'adresses blanches qui sont publiées sur ces VRF-INTERNET. Certaines des adresses blanches sont acheminées directement vers FW-CLUSTER (adresses sur lesquelles fonctionnent les services de l'entreprise), d'autres sont acheminées via la zone EXCHANGE (services internes à l'entreprise qui nécessitent des adresses IP externes et adresses NAT externes pour les bureaux). Ensuite, le trafic est dirigé vers des routeurs virtuels créés sur L3-CORE avec des adresses blanches et grises (zones de sécurité).
Le réseau de gestion utilise des commutateurs dédiés et représente un réseau physiquement dédié. Le réseau de gestion est également divisé en zones de sécurité.
Le routeur EMERGENCY duplique physiquement et logiquement le FW-CLUSTER. Toutes les interfaces sont désactivées, à l'exception de celles qui consultent le réseau de gestion.
L'automatisation et sa description
Nous avons compris comment fonctionne le réseau. Voyons maintenant étape par étape ce que nous allons faire pour transférer le trafic de FW-CLUSTER vers EMERGENCY :
- Nous désactivons les interfaces sur le commutateur principal (L3-CORE) qui le connectent au FW-CLUSTER ;
- Nous désactivons les interfaces sur le commutateur du noyau L2-MGMT qui le connectent au FW-CLUSTER ;
- Nous configurons le routeur d'URGENCE (par défaut, toutes les interfaces y sont désactivées, sauf celles associées à L2-MGMT) :
- Nous activons les interfaces en cas d'URGENCE ;
- Nous configurons l'adresse IP externe (pour NAT) qui se trouvait sur le FW-Cluster ;
- Nous générons des requêtes gARP afin que les adresses poppy dans les tables arp L3-CORE passent de FW-Cluster à EMERGENCY ;
- Nous enregistrons la route par défaut comme statique vers BRD-01, BRD-02 ;
- Créer des règles NAT ;
- Monter vers la zone OSPF d'URGENCE 1 ;
- Monter vers la zone OSPF d'URGENCE 2 ;
- Nous modifions le coût des itinéraires dans la zone 1 en 10 ;
- Nous modifions le coût de l'itinéraire par défaut dans la zone 1 en 10 ;
- Nous modifions les adresses IP associées à L2-MGMT (par celles qui étaient sur FW-CLUSTER) ;
- Nous générons des requêtes gARP afin que les adresses poppy dans les tables arp L2-MGMT passent de FW-CLUSTER à EMERGENCY.
Encore une fois, nous revenons à la formulation originale du problème. Trois heures du matin, un stress énorme, une erreur à n'importe quel moment peut entraîner de nouveaux problèmes. Prêt à saisir des commandes via la CLI ? Oui? Ok, va au moins te rincer le visage, boire du café et rassembler ta volonté.
Bruce, s'il te plaît, aide les gars.
Eh bien, nous continuons à améliorer notre automatisation.
Vous trouverez ci-dessous un schéma du fonctionnement du playbook en termes Ansible. Ce schéma reflète ce que nous avons décrit juste au-dessus, il s’agit simplement d’une implémentation spécifique dans Ansible.
À ce stade, nous avons réalisé ce qui devait être fait, développé un playbook, effectué des tests et nous sommes maintenant prêts à le lancer.
Encore une petite digression lyrique. La simplicité de l'histoire ne doit pas vous induire en erreur. Le processus d’écriture des playbooks n’a pas été aussi simple et rapide qu’il y paraît. Les tests ont pris beaucoup de temps, un stand virtuel a été créé, la solution a été testée à plusieurs reprises, environ 100 tests ont été réalisés.
Lançons-nous... On a le sentiment que tout se passe très lentement, il y a une erreur quelque part, quelque chose ne fonctionnera pas au final. La sensation de sauter avec un parachute, mais le parachute ne veut pas s'ouvrir tout de suite... c'est normal.
Ensuite, nous lisons le résultat des opérations effectuées du playbook Ansible (les adresses IP ont été remplacées pour des raisons de secret) :
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Emergency on VCF] ********************************************************
TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]
PLAY [------->Emergency on MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]
PLAY [------->Emergency on] ****************************************************
TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Fait!
En fait, ce n'est pas tout à fait prêt, n'oubliez pas la convergence des protocoles de routage dynamique et le chargement d'un grand nombre de routes dans la FIB. Nous ne pouvons en aucun cas influencer cela. Nous attendons. Ça a marché. Maintenant c'est prêt.
Et dans le village de Vilabajo (qui ne veut pas automatiser la configuration du réseau) on continue à faire la vaisselle. Bruce (certes, déjà différent, mais non moins cool) essaie de comprendre à quel point la reconfiguration manuelle de l'équipement aura lieu.
Je voudrais également m'attarder sur un point important. Comment pouvons-nous tout récupérer ? Après un certain temps, nous redonnerons vie à notre FW-CLUSTER. Il s'agit de l'équipement principal, pas de secours, le réseau doit fonctionner dessus.
Sentez-vous à quel point les réseauteurs commencent à s'épuiser ? Le directeur technique entendra mille arguments pour que cela ne soit pas fait, pour que cela puisse être fait plus tard. Malheureusement, c'est ainsi que fonctionne le réseau à partir d'un tas de correctifs, de pièces et de vestiges de son luxe d'antan. Il s’avère qu’il s’agit d’une courtepointe en patchwork. Notre tâche en général, pas dans cette situation spécifique, mais en général en principe, en tant que spécialistes informatiques, est d'amener le travail du réseau au beau mot anglais « cohérence », il est très multiforme, il peut être traduit par : cohérence , cohérence, logique, cohérence, systématicité, comparabilité, cohérence. Tout tourne autour de lui. Ce n'est que dans cet état que le réseau est gérable, nous comprenons clairement ce qui fonctionne et comment, nous comprenons clairement ce qui doit être modifié, si nécessaire, nous savons clairement où chercher si des problèmes surviennent. Et ce n'est que dans un tel réseau que l'on peut réaliser des tours comme ceux que nous venons de décrire.
En fait, un autre playbook a été préparé, qui a ramené les paramètres à leur état d'origine. La logique de son fonctionnement est la même (il est important de rappeler que l'ordre des tâches est très important), afin de ne pas allonger un article déjà assez long, nous avons décidé de ne pas publier de listing de l'exécution du playbook. Après avoir effectué de tels exercices, vous vous sentirez beaucoup plus calme et plus confiant dans l'avenir. De plus, toutes les béquilles que vous y avez entassées se révéleront immédiatement.
N'importe qui peut nous écrire et recevoir les sources de tout le code écrit, ainsi que tous les palybooks. Contacts dans le profil.
résultats
Selon nous, les processus automatisables ne sont pas encore cristallisés. Sur la base de ce que nous avons rencontré et de ce dont nos collègues occidentaux discutent, les thèmes suivants sont visibles jusqu’à présent :
- Approvisionnement en appareils ;
- Collecte de données;
- Rapports ;
- Dépannage;
- Conformité.
S'il y a de l'intérêt, nous pouvons poursuivre la discussion sur l'un des sujets proposés.
J'aimerais également parler un peu de l'automatisation. Ce que cela devrait être selon nous :
- Le système doit vivre sans personne, tout en étant amélioré par une personne. Le système ne devrait pas dépendre des humains ;
- L'opération doit être experte. Il n’existe pas de classe de spécialistes effectuant des tâches de routine. Il existe des experts qui ont automatisé toute la routine et ne résolvent que des problèmes complexes ;
- Les tâches standard de routine sont effectuées automatiquement « sur simple pression d'un bouton », aucune ressource n'est gaspillée. Le résultat de telles tâches est toujours prévisible et compréhensible.
Et à quoi doivent conduire ces points :
- Transparence de l'infrastructure informatique (Moins de risques d'exploitation, de modernisation, de mise en œuvre. Moins de temps d'arrêt par an) ;
- La capacité de planifier les ressources informatiques (Système de planification de capacité - vous pouvez voir combien est consommée, vous pouvez voir combien de ressources sont nécessaires dans un seul système, et non par des lettres et des visites aux départements supérieurs) ;
- Possibilité de réduire le nombre de personnel informatique.
Auteurs de l'article : Alexander Chelovekov (CCIE RS, CCIE SP) et Pavel Kirillov. Nous souhaitons discuter et proposer des solutions sur le thème de l’automatisation de l’infrastructure informatique.
Source: habr.com