ProHoster > Blog > Administrácia > Automatizácia sietí. Prípadová štúdia

Automatizácia sietí. Prípadová štúdia

Ahoj, Habr!

V tomto článku sa chceme porozprávať o automatizácii sieťovej infraštruktúry. Predstavíme vám pracovnú schému siete, ktorá funguje v jednej malej, ale veľmi hrdé spoločnosti. Všetky zhody s reálnym sieťovým vybavením sú náhodné. Preskúmame prípad, ktorý sa stal v tejto sieti a mohol viesť k dlhodobému zastaveniu biznisu a vážnym finančným stratám. Riešenie tohto prípadu veľmi dobre zapadá do konceptu „Automatizácia sieťovej infraštruktúry“. S pomocou automatizačných nástrojov ukážeme, ako efektívne riešiť zložité úlohy v krátkom čase a zamyslíme sa nad tým, prečo je perspektívne riešiť tieto úlohy práve takto, a nie inak (cez konzolu).

Upozornenie

Hlavnými nástrojmi na automatizáciu sú pre nás Ansible (ako prostriedok automatizácie) a Git (ako úložisko playbookov Ansible). Hneď by som chcel povedať, že nejde o úvodný článok, kde hovoríme o logike fungovania Ansible alebo Gitu a vysvetľujeme základné veci (napríklad, čo sú rolí, moduly, inventárne súbory, premenné v Ansible, alebo čo sa deje pri zadávaní príkazov git push alebo git commit). Toto nie je príbeh o tom, ako sa môžete cvičiť v Ansible, nastaviť NTP alebo SMTP na zariadení. Toto je príbeh o tom, ako rýchlo a ideálne bez chýb vyriešiť sieťový problém. Tiež je dobré mať dobré predstavy o tom, ako sieť funguje, najmä čo je to zásobník protokolov TCP/IP, OSPF, BGP. Výber Ansible a Gitu tiež presunieme stranou. Ak máte stále na výber konkrétne riešenie, veľmi odporúčame prečítať knihu „Network Programmability and Automation. Skills for the Next-Generation Network Engineer“ od Jasona Edelmana, Scotta S. Lowea a Matta Oswalta.

Tak teraz k veci.

Stanovenie úlohy

Predstavte si situáciu: 3 hodiny ráno, pevne spíte a vidíte sny. Zvoní telefón. Volá technický riaditeľ:

— Áno?
— ###, ####, #####, cluster firewalla zlyhal a nezapína sa!!!
Vy si trieť oči, snažíte sa pochopiť, čo sa deje a predstaviť si, ako sa to vôbec mohlo stať. V telefóne je počuť, ako sa riaditeľovi trhajú vlasy z hlavy, a on žiada, aby sa mu zavolalo späť, pretože na druhej linke mu volá generálny riaditeľ.

Po pol hodine ste zhromaždili prvé údaje od služby, prebudili ste všetkých, ktorých ste mohli prebudil. Nakoniec technický riaditeľ nepovedal klamstvo, všetko je pravda, hlavný klaster firewallov padol a žiadne základné kroky ho neprebudia. Všetky služby, ktoré spoločnosť ponúka, nefungujú.

Vyberte si problém podľa vlastného vkusu, každý si na niečo spomenie. Napríklad po nočnej aktualizácii bez veľkej záťaže všetko fungovalo dobre, a všetci spokojní šli spať. Prišiel prenos a začali sa preplňovať buffery rozhraní kvôli chybe v ovládači sieťovej karty.

Situáciu dobre môže opísať Jackie Chan.

Automatizácia sietí. Prípadová štúdia

Ďakujem, Jackie.

Situácia nie je veľmi príjemná, však?

Necháme na chvíľu nášho sieťového kamoša s jeho smutnými myšlienkami.

Prediskutujeme, ako sa situácia bude vyvíjať ďalej.

Navrhujeme nasledujúci postup podania materiálu

  1. Preskúmame schému siete a vysvetlíme, ako funguje;
  2. Opíšeme, ako prenášame nastavenia z jedného routera na druhý pomocou Ansible;
  3. Povedzme si niečo o automatizácii IT infraštruktúry ako celku.

Schéma siete a jej popis

Schéma

Automatizácia sietí. Prípadová štúdia

Preskúmame logickú schému našej organizácie. Nebudeme spomínať konkrétnych výrobcov hardvéru, v rámci článku to nemá význam (Pozorný čitateľ si sám domyslí, aký hardvér sa používa). To je práve jeden z dobrých prínosov práce s Ansible; pri nastavení je nám v podstate jedno, aký to je hardvér. Iba pre lepšie pochopenie, tento hardvér je od známych výrobcov, ako Cisco, Juniper, Check Point, Fortinet, Palo Alto… môžete si dosadiť svoju možnosť.

Máme dve hlavné úlohy pri presúvaní prevádzky:

  1. Zabezpečiť publikovanie našich služieb, ktoré sú obchodom spoločnosti;
  2. Zabezpečiť komunikáciu s pobočkami, vzdialeným dátovým centrom a tretími organizáciami (partnermi a klientmi), ako aj výstup pobočiek na internet prostredníctvom centrálnej kancelárie.

Začneme s hlavnými prvkami:

  1. Dva okrajové smerovače (BRD-01, BRD-02);
  2. Klaster firewallov (FW-CLUSTER);
  3. Jadrový prepínač (L3-CORE);
  4. Smerovač, ktorý sa stane záchranným kruhom (počas riešenia problému prenesieme sieťové nastavenia z FW-CLUSTER na EMERGENCY) (EMERGENCY);
  5. Prepínače pre správu sieťovej infraštruktúry (L2-MGMT);
  6. Virtuálny stroj s Git a Ansible (VM-AUTOMATION);
  7. Notebook, na ktorom prebieha testovanie a vývoj playbook-ov pre Ansible (Laptop-Automation).

V sieti je nastavený dynamický protokol smerovania OSPF s nasledujúcimi oblasťami:

  • Oblasť 0 – oblasť, do ktorej sú zapojené smerovače zodpovedajúce za pohyb prevádzky v zóne EXCHANGE;
  • Oblasť 1 – oblasť, do ktorej sú zapojené smerovače zodpovedajúce za fungovanie služieb spoločnosti;
  • Oblasť 2 – oblasť, do ktorej sú zapojené smerovače zodpovedajúce za smerovanie management-prenášania;
  • Oblasť N – oblasti pobočkových sietí.

Na hraničných smerovačoch bolo vytvorené po jednom virtuálnom smerovači (VRF-INTERNET), na ktorých je spustené eBGP full view s príslušným prideleným AS. Medzi VRF-ami je nastavený iBGP. Spoločnosť má pool bielych adries, ktoré sú publikované na týchto VRF-INTERNET. Časť bielych adries je smerovaná priamo na FW-CLUSTER (adresy, na ktorých fungujú služby spoločnosti), časť je smerovaná cez zónu EXCHANGE (interné služby spoločnosti vyžadujúce externé IP adresy a externé adresy NAT pre kancelárie). Následne prevádzka dopadá na virtuálne smerovače, vytvorené na L3-CORE s bielymi a šedými adresami (bezpečnostné zóny).

V Management sieti sa používajú vyhradené prepínače a predstavujú fyzicky vyčlenenú sieť. Management sieť je tiež rozdelená na bezpečnostné zóny.
Smerovač EMERGENCY fyzicky a logicky duplikuje FW-CLUSTER. Na ňom sú vypnuté všetky rozhrania okrem tých, ktoré smerujú do management siete.

Automatizácia a jej opis

Prešli sme k tomu, ako funguje sieť. Teraz si rozoberieme krok za krokom, čo budeme robiť, aby sme preniesli prevádzku z FW-CLUSTER na EMERGENCY:

  1. Vypneme rozhrania na prepínači jadra (L3-CORE), ktoré ho spájajú s FW-CLUSTER;
  2. Vypneme rozhrania na prepínači jadra L2-MGMT, ktoré ho spájajú s FW-CLUSTER;
  3. Nastavíme smerovač EMERGENCY (prednastavene sú na ňom vypnuté všetky rozhrania okrem tých, ktoré sú spojené s L2-MGMT):

  • Zapneme rozhrania na EMERGENCY;
  • Nastavíme externú IP adresu (pre NAT), ktorá bola na FW-Cluster;
  • Generujeme gARP dopyty, aby sa v arp-tabulkách L3-CORE zmenili MAC adresy z FW-Cluster na EMERGENCY;
  • Zapíšeme predvolenú trasu staticky do BRD-01, BRD-02;
  • Vytvoríme pravidlá NAT;
  • Spustíme na EMERGENCY OSPF Oblasť 1;
  • Spustíme na EMERGENCY OSPF Oblasť 2;
  • Zmeníme náklady trás v Oblasti 1 na 10;
  • Zmeníme náklady predvolenej trasy v Oblasti 1 na 10;
  • Zmeníme IP adresy, súvisiace s L2-MGMT (na tie, ktoré boli na FW-CLUSTER);
  • Generujeme gARP dopyty, aby sa v arp-tablách L2-MGMT zmenili mac-adresy z FW-CLUSTER na EMERGENCY.

Opäť sa vraciame k pôvodnému zhodnoteniu úlohy. Tri hodiny ráno, obrovský stres, chyba v ktoromkoľvek z krokov môže viesť k novým problémom. Ste pripravení zadávať príkazy cez CLI? Áno? Dobre, choďte sa aspoň opláchnuť, vypite si kávu a zhromaždite odvahu.
Bruce, prosím, pomôž chlapcom.

Automatizácia sietí. Prípadová štúdia

Pokračujeme v rozvíjaní našej automatizácie.
Nižšie je uvedená schéma práce playbook-u v termínoch Ansible. Táto schéma odráža to, čo sme opísali o niečo vyššie, teraz už konkrétna realizácia v Ansible.
Automatizácia sietí. Prípadová štúdia

V tejto fáze sme si uvedomili, čo je potrebné urobiť, vyvinuli sme playbook, vykonali testovanie, teraz sme pripravení ho spustiť.

Ešte jedno malé lyrické odbočenie. Ľahkosť rozprávania by vás nemala zavádzať. Proces písania playbook-ov nebol jednoduchý a rýchly, ako sa môže zdať. Testovanie zaberalo pomerne veľa času, bol vytvorený virtuálny stánok, riešenie bolo viackrát testované, vykonalo sa okolo 100 testov.

Spúšťame… Mám pocit, že všetko prebieha veľmi pomaly, niekde je chyba, niečo nakoniec nebudú fungovať. Pocit skoku s padákom, a padák sa hneď nechce otvoriť… to je normálne.

Ďalej čítame výsledok vykonaných operácií playbook-u Ansible (ip-adresy boli pre konšpiráciu nahradené):

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

Hotovo!

V skutočnosti nie je úplne hotovo, nezabúdajme na konvergenciu dynamických smerovacích protokolov a načítanie veľkého množstva trás do FIB. Na to nemáme žiadny vplyv. Čakáme. Zladilo sa to. Teraz je to pripravené.

A v dedinke Vilabadžo (ktorá nechce automatizovať nastavenie siete) stále umývajú riad. Bruce (pravda, už iný, ale rovnako úžasný) sa snaží pochopiť, koľko zariadení ešte musí manuálne prekonfigurovať.

Automatizácia sietí. Prípadová štúdia

Chcel by som sa ešte zastaviť pri jednom dôležitom bode. Ako to všetko vrátiť späť? Po nejakej dobe, vzkřísíme náš FW-CLUSTER. To je hlavné zariadenie, nie záložné, na ňom by mala fungovať sieť.

Cítite, ako začína hrýzť sieťarov? Technický riaditeľ počuje tisíc argumentov, prečo to robiť netreba, prečo to môžeme urobiť neskôr. Bohužiaľ, takto vzniká sieť z množstva záplat, kusov, zvyškov minulých vymožeností. Vzniká patchwork. Našou úlohou celkovo, nie v tejto konkrétnej situácii, ale vôbec ako IT odborníkov — priviesť fungovanie siete k peknému anglickému slovu „consistency“, je veľmi mnohovrstevné, možno ho preložiť ako: súlad, logickosť, koherencia, systematičnosť, porovnateľnosť, spojitosť. To všetko o ňom. Iba v takom stave je sieť spravovateľná, jasne rozumieme, čo a ako funguje, jasne si uvedomujeme, čo treba zmeniť, ak je to potrebné, a jasne vieme, kam sa pozrieť, ak nastanú problémy. A iba v takej sieti je možné robiť kúzla, podobné tým, ktoré sme práve opísali.

Vlastne bol pripravený ďalší playbook, ktorý vracal nastavenia do pôvodného stavu. Logika jeho fungovania je rovnaká (je dôležité pamätať, poradie úloh je veľmi dôležité), aby sme nezdlžovali a tak dosť dlhý článok, rozhodli sme sa nezverejňovať zoznam vykonania playbooku. Po takýchto cvičeniach sa budete cítiť oveľa pokojnejší a sebavedomejší v budúcnosti, navyše akékoľvek samovoľné úpravy, ktoré ste tam urobili, sa ihneď odhalia.

Všetci záujemcovia nám môžu napísať a získať zdrojový kód všetkého napísaného kódu, spolu so všetkými playbookmi. Kontakty v profile.

Zhrnutie

Podľa nášho názoru procesy, ktoré je možné automatizovať, sa ešte nevytvorili. Z toho, s čím sme sa stretli a o čom diskutujú naši západní kolegovia, sú zatiaľ viditeľné nasledujúce témy:

  • Zabezpečenie zariadení;
  • Zber údajov;
  • Správa;
  • Riešenie problémov;
  • Zhodnotenie.

Ak budete mať záujem, môžeme pokračovať v diskusii na jednu z daných tém.

Chceme sa ešte zamyslieť nad témou automatizácie. Aká by mala byť podľa nášho chápania:

  • Systém by mal fungovať bez človeka, pričom sa zlepšuje človekom. Systém by nemal závisieť od človeka;
  • Prevádzka by mala byť odborná. Chýba trieda špecialistov, ktorí vykonávajú rutinné úlohy. Sú tu experti, ktorí celú rutinu automatizovali a zaoberajú sa iba zložitými úlohami;
  • Rutinné štandardné úlohy sa vykonávajú automaticky „stlačením tlačidla“, nechcú sa míňať zdroje. Výsledok takýchto úloh je vždy predvídateľný a jasný.

A kam by tieto body mali viesť:

  • Priehľadnosť IT infraštruktúry (Menej rizík prevádzky, modernizácie, implementácie. Menej downtime za rok);
  • Možnosť plánovať IT zdroje (Systém plánovania kapacity — vidno, koľko sa spotrebuje, vidno, koľko je potrebných zdrojov v jedinom systéme, a nie podľa e-mailov a chodenia k vedúcim oddelení);
  • Možnosť znížiť počet obsluhujúcich IT personál.

Autori článku: Alexander Človekov (CCIE RS, CCIE SP) a Pavel Kirillov. Zaujímavé je diskutovať a navrhovať riešenia na tému automatizácia IT infraštruktúry.


Zdroj: habr.com

Kúpte si spoľahlivý hosting pre webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Kúpte si spoľahlivý hosting pre webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster