Hei Habr!
În acest articol am dori să vorbim despre automatizarea infrastructurii de rețea. Va fi prezentată o diagramă de lucru a rețelei care funcționează într-o companie mică, dar foarte mândră. Toate potrivirile cu echipamente reale de rețea sunt aleatorii. Ne vom uita la un caz care a avut loc în această rețea, care ar fi putut duce la o închidere a afacerii pentru o perioadă lungă de timp și la pierderi financiare grave. Soluția pentru acest caz se încadrează foarte bine în conceptul de „Automatizarea infrastructurii de rețea”. Folosind instrumente de automatizare, vom arăta cum puteți rezolva eficient probleme complexe într-un timp scurt și vom reflecta de ce aceste probleme ar trebui rezolvate astfel și nu altfel (prin consolă).
Declinare a responsabilităţii
Principalele noastre instrumente de automatizare sunt Ansible (ca instrument de automatizare) și Git (ca depozit pentru manualele Ansible). Aș dori să fac imediat o rezervă că acesta nu este un articol introductiv, în care vorbim despre logica lui Ansible sau Git și explicăm lucruri de bază (de exemplu, ce sunt roletaskimodules, fișierele de inventar, variabilele în Ansible sau ce se întâmplă atunci când introduceți comenzile git push sau git commit). Această poveste nu este despre cum puteți exersa Ansible și configura NTP sau SMTP pe echipamentul dvs. Aceasta este o poveste despre cum puteți rezolva rapid și de preferință o problemă de rețea fără erori. De asemenea, este recomandabil să aveți o bună înțelegere a modului în care funcționează rețeaua, în special care este stiva de protocoale TCP/IP, OSPF, BGP. Vom scoate, de asemenea, alegerea dintre Ansible și Git din paranteze. Dacă totuși trebuie să alegeți o soluție specifică, vă recomandăm să citiți cartea „Programabilitate și automatizare în rețea. Skills for the Next-Generation Network Engineer” de Jason Edelman, Scott S. Lowe și Matt Oswalt.
Acum la afaceri.
Declarație de problemă
Să ne imaginăm o situație: ora 3 dimineața, adormi adânc și visezi. Apel telefonic. Directorul tehnic sună:
- Da?
— ###, ####, #####, clusterul de firewall a căzut și nu crește!!!
Te freci la ochi, încercând să înțelegi ce se întâmplă și să-ți imaginezi cum se poate întâmpla asta. La telefon se aude părul de pe capul directorului rupându-se, iar acesta cere să-l sune pentru că generalul îl sună pe linia a doua.
O jumătate de oră mai târziu, ai adunat primele note introductive din tura de serviciu, i-ai trezit pe toți cei care puteau fi treziți. Drept urmare, directorul tehnic nu a mințit, totul este așa cum este, principalul grup de firewall-uri a căzut și nicio mișcare de bază a corpului nu-l aduce în fire. Toate serviciile pe care compania le oferă nu funcționează.
Alege o problemă pe gustul tău, toată lumea își va aminti ceva diferit. De exemplu, după o actualizare peste noapte în absența unei sarcini grele, totul a funcționat bine și toată lumea s-a culcat fericiți. Traficul a început să curgă, iar tampoanele de interfață au început să se depășească din cauza unei erori în driverul plăcii de rețea.
Jackie Chan poate descrie bine situația.
Mulțumesc, Jackie.
Nu este o situație foarte plăcută, nu-i așa?
Să lăsăm rețeaua noastră frate cu gândurile sale triste pentru o vreme.
Să discutăm despre cum se vor dezvolta evenimentele în continuare.
Vă sugerăm următoarea ordine de prezentare a materialului
- Să ne uităm la diagrama rețelei și să vedem cum funcționează;
- Vom descrie modul în care transferăm setările de la un router la altul folosind Ansible;
- Să vorbim despre automatizarea infrastructurii IT în ansamblu.
Diagrama și descrierea rețelei
Schema
Să luăm în considerare diagrama logică a organizației noastre. Nu vom numi anumiți producători de echipamente; în sensul acestui articol, nu contează (Cititorul atent va ghici ce fel de echipament este folosit). Acesta este doar unul dintre avantajele bune ale lucrului cu Ansible; la configurare, în general, nu ne interesează ce fel de echipament este. Doar ca să înțelegem, acesta este echipament de la furnizori cunoscuți, precum Cisco, Juniper, Check Point, Fortinet, Palo Alto... puteți înlocui propria opțiune.
Avem două sarcini principale pentru deplasarea traficului:
- Asigurarea publicării serviciilor noastre, care sunt afacerea companiei;
- Asigurați comunicarea cu sucursalele, un centru de date la distanță și organizațiile terțe (parteneri și clienți), precum și accesul sucursalelor la Internet prin intermediul biroului central.
Să începem cu elementele de bază:
- Două routere de frontieră (BRD-01, BRD-02);
- Firewall Cluster (FW-CLUSTER);
- Comutator de bază (L3-CORE);
- Un router care va deveni un colac de salvare (pe măsură ce rezolvăm problema, vom transfera setările de rețea din FW-CLUSTER în EMERGENCY) (URGENȚĂ);
- Switch-uri pentru managementul infrastructurii de rețea (L2-MGMT);
- Mașină virtuală cu Git și Ansible (VM-AUTOMATION);
- Un laptop pe care se efectuează testarea și dezvoltarea de playbook-uri pentru Ansible (Laptop-Automation).
Rețeaua este configurată cu un protocol de rutare dinamic OSPF cu următoarele zone:
- Zona 0 – zonă care include routerele responsabile cu deplasarea traficului în zona SCHIMB;
- Zona 1 – zona care include routerele responsabile cu operarea serviciilor companiei;
- Zona 2 – zonă care include routerele responsabile cu gestionarea rutei traficului;
- Zona N – zone ale rețelelor de sucursale.
Pe routerele de frontieră, este creat un router virtual (VRF-INTERNET), pe care este instalată eBGP full view cu AS-ul corespunzător alocat. iBGP este configurat între VRF-uri. Compania are un grup de adrese albe care sunt publicate pe aceste VRF-INTERNET. Unele dintre adresele albe sunt direcționate direct către FW-CLUSTER (adrese pe care funcționează serviciile companiei), unele sunt direcționate prin zona EXCHANGE (servicii interne ale companiei care necesită adrese IP externe și adrese NAT externe pentru birouri). În continuare, traficul merge către routerele virtuale create pe L3-CORE cu adrese albe și gri (zone de securitate).
Rețeaua de management folosește comutatoare dedicate și reprezintă o rețea dedicată fizic. Rețeaua de management este, de asemenea, împărțită în zone de securitate.
Routerul EMERGENCY duplică fizic și logic FW-CLUSTER. Toate interfețele de pe acesta sunt dezactivate, cu excepția celor care se uită în rețeaua de management.
Automatizarea și descrierea acesteia
Ne-am dat seama cum funcționează rețeaua. Acum să aruncăm o privire pas cu pas la ce vom face pentru a transfera traficul de la FW-CLUSTER la EMERGENCY:
- Dezactivăm interfețele de pe comutatorul de bază (L3-CORE) care îl conectează la FW-CLUSTER;
- Dezactivăm interfețele de pe comutatorul kernel L2-MGMT care îl conectează la FW-CLUSTER;
- Configuram routerul de URGENȚĂ (în mod implicit, toate interfețele sunt dezactivate pe acesta, cu excepția celor asociate cu L2-MGMT):
- Activam interfete pe URGENTA;
- Configuram adresa IP externa (pentru NAT) care era pe FW-Cluster;
- Generăm solicitări gARP, astfel încât adresele de mac din tabelele arp L3-CORE să fie schimbate din FW-Cluster în EMERGENCY;
- Înregistrăm ruta implicită ca static pentru BRD-01, BRD-02;
- Creați reguli NAT;
- Ridicați la URGENȚĂ OSPF Zona 1;
- Ridicați la URGENȚĂ OSPF Zona 2;
- Schimbăm costul rutelor din Zona 1 la 10;
- Schimbăm costul rutei implicite din Zona 1 la 10;
- Schimbăm adresele IP asociate cu L2-MGMT (la cele care erau pe FW-CLUSTER);
- Generăm solicitări gARP, astfel încât adresele mac din tabelele arp L2-MGMT să fie schimbate din FW-CLUSTER în EMERGENCY.
Din nou, revenim la formularea originală a problemei. Ora trei dimineața, stres enorm, o greșeală în orice etapă poate duce la noi probleme. Ești gata să tastați comenzi prin CLI? Da? Ok, măcar du-te și clătește-ți fața, bea niște cafea și adună-ți voința.
Bruce, te rog ajută-i pe băieți.
Ei bine, continuăm să ne îmbunătățim automatizarea.
Mai jos este o diagramă a modului în care funcționează manualul în termeni Ansible. Această schemă reflectă ceea ce am descris mai sus, este doar o implementare specifică în Ansible.
În această etapă, ne-am dat seama ce trebuie făcut, am dezvoltat un manual, am testat, iar acum suntem gata să-l lansăm.
O altă mică digresiune lirică. Ușurința poveștii nu ar trebui să vă inducă în eroare. Procesul de scriere a cărților de joc nu a fost atât de simplu și rapid pe cât ar părea. Testarea a durat destul de mult, a fost creat un stand virtual, soluția a fost testată de multe ori, s-au efectuat aproximativ 100 de teste.
Hai să lansăm... Există senzația că totul se întâmplă foarte încet, este o eroare undeva, ceva nu va funcționa până la urmă. Senzația de a sări cu parașuta, dar parașuta nu vrea să se deschidă imediat... este normal.
În continuare, citim rezultatul operațiunilor efectuate din manualul Ansible (adresele IP au fost înlocuite în scopuri 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 ************************************************************************Gata!
De fapt, nu este gata, nu uitați de convergența protocoalelor de rutare dinamică și de încărcarea unui număr mare de rute în FIB. Nu putem influența în niciun fel acest lucru. Așteptăm. A mers. Acum este gata.
Și în satul Vilabajo (care nu vrea să automatizeze configurarea rețelei) continuă să spele vasele. Bruce (desigur, deja diferit, dar nu mai puțin cool) încearcă să înțeleagă cât de mult va avea loc mai multă reconfigurare manuală a echipamentului.
De asemenea, aș dori să mă opresc asupra unui punct important. Cum putem recupera totul? După ceva timp, ne vom readuce la viață FW-CLUSTER. Acesta este echipamentul principal, nu backup, rețeaua trebuie să ruleze pe el.
Simți cum încep să se epuizeze rețelei? Directorul tehnic va auzi o mie de argumente de ce nu ar trebui făcut asta, de ce se poate face asta mai târziu. Din păcate, așa funcționează rețeaua dintr-o grămadă de patch-uri, bucăți, rămășițe din fostul său lux. Se dovedește a fi o pilota mozaic. Sarcina noastră în general, nu în această situație specifică, ci în general în principiu, ca specialiști IT, este să aducem munca rețelei la frumosul cuvânt englezesc „consistență”, este foarte multifațetat, poate fi tradus ca: coerență , consistență, logică, coerență, sistematicitate, comparabilitate, coerență. Totul este despre el. Numai în această stare rețeaua este gestionabilă, înțelegem clar ce funcționează și cum, înțelegem clar ce trebuie schimbat, dacă este necesar, știm clar unde să ne uităm dacă apar probleme. Și numai într-o astfel de rețea puteți efectua trucuri precum cele pe care tocmai le-am descris.
De fapt, a fost pregătit un alt manual, care a readus setările la starea inițială. Logica de funcționare a acestuia este aceeași (este important să ne amintim că ordinea sarcinilor este foarte importantă), pentru a nu prelungi un articol deja destul de lung, am decis să nu postăm o listă a execuției playbook-ului. După efectuarea unor astfel de exerciții, te vei simți mult mai calm și mai încrezător în viitor, în plus, orice cârje pe care le-ai îngrămădit acolo se vor dezvălui imediat.
Oricine ne poate scrie și primi sursele întregului cod scris, împreună cu toate cărțile de plată. Contacte din profil.
Constatări
În opinia noastră, procesele care pot fi automatizate nu s-au cristalizat încă. Pe baza a ceea ce am întâlnit și a ceea ce discută colegii noștri occidentali, următoarele teme sunt vizibile până acum:
- Aprovizionarea dispozitivelor;
- Colectare de date;
- Raportare;
- Depanare;
- Conformitatea.
Dacă există interes, putem continua discuția pe unul dintre subiectele date.
Aș vrea să vorbesc puțin și despre automatizare. Ce ar trebui să fie după înțelegerea noastră:
- Sistemul trebuie să trăiască fără o persoană, în timp ce este îmbunătățit de o persoană. Sistemul nu ar trebui să depindă de oameni;
- Operațiunea trebuie să fie expertă. Nu există o clasă de specialiști care să îndeplinească sarcini de rutină. Există experți care au automatizat întreaga rutină și rezolvă doar probleme complexe;
- Sarcinile standard de rutină sunt efectuate automat „la atingerea unui buton”, nu se irosesc resurse. Rezultatul unor astfel de sarcini este întotdeauna previzibil și de înțeles.
Și la ce ar trebui să conducă aceste puncte:
- Transparența infrastructurii IT (mai puține riscuri de funcționare, modernizare, implementare. Mai puține perioade de nefuncționare pe an);
- Capacitatea de planificare a resurselor IT (Sistemul de planificare a capacității - puteți vedea cât se consumă, puteți vedea câte resurse sunt necesare într-un singur sistem, și nu prin scrisori și vizite la departamentele de top);
- Posibilitatea de reducere a numărului de personal IT.
Autorii articolului: Alexander Chelovekov (CCIE RS, CCIE SP) și Pavel Kirillov. Suntem interesați să discutăm și să propunem soluții pe tema automatizării infrastructurii IT.
Sursa: www.habr.com