Automatizarea rețelei. O întâmplare din viață

Salut, Habr!

În acest articol, dorim să discutăm despre automatizarea infrastructurii de rețea. Vom prezenta un diagramă de rețea care funcționează într-o companie mică, dar foarte mândră. Orice asemănare cu echipamentele reale de rețea este întâmplătoare. Vom analiza un caz care s-a petrecut în această rețea, care ar fi putut duce la oprirea afacerii pentru o perioadă îndelungată și la pierderi financiare semnificative. Soluția acestui caz se încadrează perfect în conceptul de „Automatizarea infrastructurii de rețea”. Cu ajutorul uneltelor de automatizare, vom arăta cum se pot rezolva eficient sarcini complexe într-un timp scurt și vom reflecta asupra motivului pentru care aceste sarcini ar trebui abordate în acest mod, și nu altfel (prin consolă).

Declinarea

Principalele unelte pentru automatizare pe care le folosim sunt Ansible (ca unealtă de automatizare) și Git (ca stocare pentru playbook-urile Ansible). Imediat trebuie să subliniez faptul că acesta nu este un articol introductiv în care discutăm despre logica de funcționare a Ansible sau Git și explicăm concepte de bază (de exemplu, ce sunt modulele, fișierele de inventar sau variabilele în Ansible, sau ce se întâmplă când introducem comenzile git push sau git commit). Aceasta nu este o poveste despre cum să ne exersăm abilitățile în Ansible, să configurăm NTP sau SMTP pe echipamente. Aceasta este o poveste despre cum putem rezolva rapid și ideal fără erori o problemă de rețea. De asemenea, este util să aveți o bună înțelegere a modului în care funcționează rețeaua, în special, ce este stiva de protocoale TCP/IP, OSPF, BGP. Alegerea Ansible și Git este o discuție pe care o lăsăm deoparte. Dacă aveți încă de ales o soluție specifică, vă recomandăm cu căldură să citiți cartea „Network Programmability and Automation. Skills for the Next-Generation Network Engineer” de Jason Edelman, Scott S. Lowe și Matt Oswalt.

Acum să trecem la subiect.

Formularea problemei

Să ne imaginăm situația: 3 dimineața, dormiți adânc și visați. Sună telefonul. Te sună directorul tehnic:

— Da?
— ###, ####, #####, clusterul de firewall-uri a căzut și nu se ridică!!!
Îți freci ochii, încerci să înțelegi ce se întâmplă și să îți imaginezi cum a putut să se întâmple așa ceva. În telefon se aude cum se smulg firele de păr de pe capul directorului, și el cere să suni înapoi, pentru că a doua linie îl sună pe directorul general.

După treizeci de minute, ați adunat primele informații de la tura de garda, ați trezit pe toți cei care puteau fi treziți. În cele din urmă, directorul tehnic nu a mințit, totul este adevărat, clusterul principal de firewall-uri a căzut și niciunul dintre pașii de bază nu-l readuce la viață. Toate serviciile oferite de companie nu funcționează.

Alegeți o problemă pe gustul vostru, fiecare își va aminti ceva deosebit. De exemplu, după actualizarea de noapte, în absența unei mari încărcături, totul a funcționat bine și toată lumea mulțumită s-a dus la somn. A început traficul și bufferele interfețelor s-au umplut din cauza unei erori în driver-ul plăcii de rețea.

Situația poate fi bine descrisă de Jackie Chan.

Automatizarea rețelei. O întâmplare din viață

Mulțumesc, Jackie.

Situația nu este foarte plăcută, nu-i așa?

Să-l lăsăm pe prietenul nostru de rețea cu gândurile sale triste pentru o vreme.

Să discutăm despre cum se vor desfășura evenimentele în continuare.

Propunem următoarea ordine de prezentare a materialului

  1. Vom examina schema rețelei și vom analiza cum funcționează;
  2. Vom descrie cum transferăm setările de pe un router pe altul cu ajutorul Ansible;
  3. Vom discuta despre automatizarea infrastructurii IT în general.

Schema rețelei și descrierea acesteia

Schema

Automatizarea rețelei. O întâmplare din viață

Vom examina schema logică a organizației noastre. Nu vom menționa producători specifici de echipamente, în cadrul articolului acest lucru nu are relevanță. (Cititorul atent va deduce singur ce echipamente sunt utilizate). Acesta este unul dintre avantajele lucrului cu Ansible; în timpul configurării, în general nu ne interesează ce echipament este. Doar pentru a înțelege, acest echipament provine de la furnizori cunoscuți, precum Cisco, Juniper, Check Point, Fortinet, Palo Alto… puteți folosi opțiunea preferată.

Avem două sarcini principale pentru mutarea traficului:

  1. Asigurarea publicării serviciilor noastre, care reprezintă afacerea companiei;
  2. Asigurarea comunicării cu filialele, centrala de date la distanță și alte organizații (parteneri și clienți), precum și ieșirea filialelor pe internet prin intermediul biroului central.

Să începem cu elementele de bază:

  1. Două routere de frontieră (BRD-01, BRD-02);
  2. Clusterul de firewall-uri (FW-CLUSTER);
  3. Switch-ul de nucleu (L3-CORE);
  4. Routerul care va deveni plasa de siguranță (pe măsură ce rezolvăm problema, vom transfera setările rețelei de la FW-CLUSTER la EMERGENCY) (EMERGENCY);
  5. Switch-uri pentru gestionarea infrastructurii de rețea (L2-MGMT);
  6. Mașină virtuală cu Git și Ansible (VM-AUTOMATION);
  7. Laptopul pe care se realizează testarea și dezvoltarea playbook-urilor pentru Ansible (Laptop-Automation).

În rețea este configurat protocolul dinamic de rutare OSPF cu următoarele zone:

  • Zona 0 – domeniul în care sunt incluse routerele care se ocupă de deplasarea traficului în zona EXCHANGE;
  • Zona 1 – domeniul în care sunt incluse routerele care se ocupă de funcționarea serviciilor companiei;
  • Zona 2 – domeniul în care sunt incluse routerele care se ocupă de rutarea traficului de management;
  • Zona N – zonele rețelelor sucursale.

Pe routerele de margine a fost creat câte un router virtual (VRF-INTERNET), pe care a fost activat eBGP full view cu AS-ul corespunzător. Între VRF-uri este configurat iBGP. Compania dispune de un pool de adrese IP publice, care sunt publicate pe aceste VRF-INTERNET. O parte din adresele publice sunt rute directe către FW-CLUSTER (adresele pe care funcționează serviciile companiei), iar o parte sunt rutate prin zona EXCHANGE (servicii interne ale companiei care necesită adrese IP externe și adrese externe NAT pentru birouri). Mai departe, traficul ajunge pe routerele virtuale create pe L3-CORE cu adrese publice și private (zone de securitate).

În rețeaua de management se utilizează switch-uri dedicate și reprezintă o rețea fizic dedicată. Rețeaua de management este împărțită și în zone de securitate.
Routerul EMERGENCY replicatează fizic și logic FW-CLUSTER. Pe acesta sunt dezactivate toate interfețele, cu excepția celor care se conectează la rețeaua de management.

Automatizare și descrierea acesteia

Am înțeles cum funcționează rețeaua. Acum să detaliem pașii pe care îi vom urma pentru a redirecționa traficul de la FW-CLUSTER către EMERGENCY:

  1. Dezactivăm interfețele de pe switch-ul de bază (L3-CORE) care îl leagă de FW-CLUSTER;
  2. Dezactivăm interfețele de pe switch-ul de bază L2-MGMT care îl leagă de FW-CLUSTER;
  3. Configurăm routerul EMERGENCY (în mod implicit, toate interfețele sunt dezactivate, cu excepția celor care sunt legate de L2-MGMT):

  • Activăm interfețele pe EMERGENCY;
  • Configurăm adresa IP externă (pentru NAT) care era pe FW-Cluster;
  • Generăm cereri gARP pentru ca în tabelele ARP L3-CORE să se schimbe adresele MAC de la FW-Cluster la EMERGENCY;
  • Definim ruta implicită statică către BRD-01, BRD-02;
  • Creăm reguli NAT;
  • Activăm OSPF Area 1 pe EMERGENCY;
  • Activăm OSPF Area 2 pe EMERGENCY;
  • Modificăm costurile rutelor în Area 1 la 10;
  • Modificăm costul rutei implicite în Area 1 la 10;
  • Schimbăm adresa IP, legate de L2-MGMT (la cele care erau pe FW-CLUSTER);
  • Generăm cereri gARP pentru a schimba adresele MAC din tabelele arp L2-MGMT de la FW-CLUSTER la EMERGENCY.

Revenim la sarcina inițială. Este ora trei dimineața, un stres imens, iar o eroare în oricare dintre etape poate duce la probleme noi. Ești gata să introduci comenzi prin CLI? Da? Bine, hai să te speli pe față, să bei o cafea și să îți strângi voința.
Bruce, te rog ajută-i pe băieți.

Automatizarea rețelei. O întâmplare din viață

Și noi continuăm să lucrăm la automatizarea noastră.
Mai jos este un diagramă a funcționării playbook-ului în termenii Ansible. Această diagramă reflectă ceea ce am descris mai sus, doar că acum este o implementare concretă în Ansible.
Automatizarea rețelei. O întâmplare din viață

În acest stadiu ne-am dat seama ce trebuie să facem, am dezvoltat playbook-ul, am efectuat testele, acum suntem pregătiți să îl lansăm.

O mică digresiune. Ușurința narațiunii nu ar trebui să te înșele. Procesul de scriere a playbook-urilor nu a fost simplu și rapid, așa cum ar putea părea. Testarea a durat destul de mult, a fost creat un mediu virtual, soluția a fost rulate de mai multe ori, au fost efectuate aproximativ 100 de teste.

Lansăm… Există o senzație că totul se desfășoară foarte lent, undeva este o eroare, ceva nu va funcționa în cele din urmă. Este ca săritul cu parașuta, iar parașuta nu se deschide imediat… este normal.

Apoi citim rezultatul operațiunilor efectuate de playbook-ul Ansible (adresele IP au fost înlocuite pentru a asigura confidențialitatea):

[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 ************************************************************************

Gata!

De fapt, nu este complet pregătit, nu uitați de convergența protocoalelor de rutare dinamice și de încărcarea unui număr mare de rute în FIB. Nu putem influența acest lucru. Așteptăm. S-au aliniat. Acum este pregătit.

Și în satul Vilabadjo (care nu dorește să automatizeze configurarea rețelei) continuă să spele vasele. Bruce (deși este altcineva, nu mai puțin impresionant) încearcă să înțeleagă cât de mult trebuie să reconfigureze manual echipamentul.

Automatizarea rețelei. O întâmplare din viață

Aș dori să mă opresc și pe un alt moment important. Cum ne putem întoarce totul înapoi? După un timp, vom readuce la viață FW-CLUSTER-ul nostru. Acesta este echipamentul principal, nu de rezervă, pe el trebuie să funcționeze rețeaua.

Simțiți cum începe să devină tensionat pentru rețeliști? Directorul tehnic va auzi o mie de argumente despre de ce nu ar trebui să facă acest lucru, de ce este mai bine să facă asta mai târziu. Din păcate, așa se construiește munca rețelei dintr-o mulțime de soluții temporare, piese, rămășițe ale unui trecut luxos. Rezultatul este o pătură din ciucuri. Sarcina noastră în general, nu doar în această situație particulară, ci în principiu ca specialiști IT — este să readucem funcționarea rețelei la un cuvânt englezesc frumos „consistență”, care este foarte complex, poate fi tradus ca: coerență, non-contradicție, logică, armonie, sistematizare, comparabilitate, conexiune. Toate acestea se referă la el. Numai în această stare rețeaua este gestionabilă, știm clar ce și cum funcționează, suntem conștienți de ce trebuie schimbat, dacă este necesar, știm clar unde să ne uităm în caz de probleme. Și numai într-o astfel de rețea putem face trucuri de genul celor pe care le-am descris acum.

De fapt, a fost pregătit un alt playbook, care readucea setările la starea inițială. Logica sa de funcționare este aceeași (este important de reținut, ordinea sarcinilor este foarte importantă), pentru a nu lungi și așa articolul destul de lung, am decis să nu publicăm lista de execuție a playbook-ului. După ce ați desfășurat aceste exerciții, vă veți simți mult mai liniștit și mai încrezător în viitor, în plus, orice soluții temporare pe care le-ați creat acolo vor fi imediat evidente.

Toți cei interesați pot să ne scrie și să primească sursele întregului cod scris, împreună cu toate playbook-urile. Contactele sunt în profil.

Conclusions

În opinia noastră, procesele care pot fi automatizate nu s-au cristalizat încă. Pe baza a ceea ce am întâmpinat și a ceea ce discută colegii noștri din străinătate, se disting următoarele subiecte:

  • Provisionarea dispozitivelor;
  • Colectarea datelor;
  • Raportare;
  • Soluționarea problemelor;
  • Conformitate.

Dacă există interes, putem continua discuția pe unul dintre subiectele date.

De asemenea, dorim să reflectăm puțin asupra temei automatizării. Cum ar trebui să arate aceasta din punctul nostru de vedere:

  • Sistemul trebuie să funcționeze fără intervenția umană, îmbunătățindu-se totuși cu ajutorul oamenilor. Sistemul nu trebuie să depindă de oameni;
  • Exploatarea trebuie să fie expertă. Lipsește clasa de specialiști care execută sarcini de rutină. Există experți care au automatizat întreaga rutină și se ocupă doar de sarcini complexe;
  • Sarcinile standard de rutină sunt realizate automat cu un «click», fără a consuma resurse. Rezultatele acestor sarcini sunt întotdeauna previzibile și clare.

Și la ce ar trebui să conducă aceste puncte:

  • Transparența infrastructurii IT (riscuri mai mici în exploatare, modernizare, implementare. Timp de nefuncționare mai mic pe an);
  • Posibilitatea de a planifica resursele IT (sistem de planificare a capacității — se vede cât este consumat, se vede câte resurse sunt necesare într-un singur sistem, nu prin e-mailuri și vizite la șefii departamentelor);
  • Posibilitatea de a reduce numărul personalului IT de întreținere.

Autorii articolului: Alexandr Čelîakov (CCIE RS, CCIE SP) și Pavel Kirilov. Ne interesează să discutăm și să propunem soluții pe tema automatizării infrastructurii IT.


Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster