Tere, Habr!
Selles artiklis soovime rääkida võrguinfrastruktuuri automatiseerimisest. Tutvustame töökindlat võrgu skeemi, mis töötab ühes väikeses, kuid väga uhkes ettevõttes. Kõik sarnasused reaalse võrguvarustusega on juhuslikud. Uurime juhtumit, mis juhtus selles võrgus, mis oleks võinud viia äritegevuse seisakuni pikka aega ja tõsiste rahaliste kaotusteni. Selle juhtumi lahendus sobib suurepäraselt süsteemi «Võrguinfrastruktuuri automatiseerimine» mõistetesse. Kasutades automatiseerimise vahendeid, näitame, kuidas saame tõhusalt lahendada keerulisi ülesandeid lühikese aja jooksul, ja arutame, miks on otstarbekam neid ülesandeid lahendada just nii, mitte teisiti (konsoli kaudu).
Märkus
Peamised tööriistad automatiseerimiseks on meil Ansible (automaatika tööriistana) ja Git (Ansible’i playbookide hoidjana). Tahan kohe öelda, et see ei ole ülevaatlik artikkel, kus räägime Ansible'i või Giti tööloogikast ning selgitame põhiasju (näiteks, mis on Ansible'i rollid, moodulid, inventeerimisfailid, muutujad, või mis juhtub, kui sisestate käsud git push või git commit). See ei ole lugu sellest, kuidas Ansible’iga harjutada, seadistada NTP või SMTP seadmetes. See lugu räägib sellest, kuidas kiiresti ja soovitavalt ilma vigadeta võrguprobleemi lahendada. Samuti on soovitatav omada head arusaama võrgu toimimisest, eelkõige sellest, mis on TCP/IP protokollide virn, OSPF, BGP. Ansible'i ja Giti valik jääb samuti kõrvale. Kui te otsustate konkreetse lahenduse üle, soovitame soojalt lugeda raamatut «Network Programmability and Automation. Skills for the Next-Generation Network Engineer» autoriteks Jason Edelman, Scott S. Lowe ja Matt Oswalt.
Nüüd asja juurde.
Ülesande seadmine
Kujutame ette olukorda: kell on 3 öösel, magate sügavalt ja näete unenägusid. Telefon heliseb. Helistab tehniline direktor:
— Jah?
— ###, ####, #####, tulemüüride klaster on kukkunud ja ei tõuse üles!!!
Käite silmi, püüate mõista, mis toimub, ja kujutada ette, kuidas selline asi üldse võis juhtuda. Torus on kuulda, kuidas direktori juustest tõmbab ja ta palub tagasi helistada, sest teisel joonel helistab talle peadirektor.
Pool tunni pärast olete kogunud öövahtkonnalt esimesed sisendid, äratanud kõik, keda oli võimalik. Tõepoolest, tehniline direktor ei valetanud – kõik on nii, nagu öeldud: peamine tulemüürikluster on kokku kukkunud ja mingid lihtsad toimingud ei suuda seda taastada. Kõik ettevõtte pakutavad teenused ei tööta.
Valige probleem oma maitsele, igaühel on midagi meeles. Näiteks, pärast öist uuendust, mil koormus oli väike, töötas kõik hästi ja kõik rahulolevad läksid magama. Tuli liiklus ja liidese puhverdamised hakkasid üle koormama, kuna võrguadapteri draiveris oli viga.
Seda olukorda suudab hästi kirjeldada Jackie Chan.
Aitäh, Jackie.
Situatsioon ei ole just meeldiv, kas pole?
Jätame meie võrguvenna tema kurbade mõtete juurde ajutiselt.
Arutame, kuidas sündmused edasi arenevad.
Pakume järgmise sisu esitamise korrakava.
- Vaadakem võrgu skeemi ja uurime, kuidas see töötab.
- Kirjeldame, kuidas me Ansible'i abil seadeid ühest ruuterist teise edastame.
- Räägime IT-infrastruktuuri automatiseerimisest laiemalt.
Võrgu skeem ja selle kirjeldus.
Schema
Vaadakem meie organisatsiooni loogilist skeemi. Me ei nimeta konkreetseid seadmete tootjaid, see pole artikli kontekstis oluline. (Tähelepanelik lugeja mõistab ise, milliseid seadmeid kasutatakse.). See on üks Ansible'i töö eeliseid – seadistamisel ei oma me enamasti tähtsust, millised seadmed need on. Lihtsalt arusaamiseks: need on tuntud kaubamärkide seadmed, nagu Cisco, Juniper, Check Point, Fortinet, Palo Alto ... võite sisestada oma variandi.
Meil on kaks põhiülesannet liikluse edastamiseks:
- Tagada meie teenuste avalikustamine, mis on ettevõtte äripool.
- Tagada ühendus haruettevõtetega, kaugtöökohaga ja kolmandate osapooltega (partnerite ja klientidega), samuti filiaalide internetiühendus keskse büroo kaudu.
Alustame põhi elementidest:
- Kaks piiri marsruuterit (BRD-01, BRD-02);
- Tulemüüride klaster (FW-CLUSTER);
- Tuuma lüliti (L3-CORE);
- Marsruuter, mis muutub päästerõngaks (probleemi lahendamise käigus edastame võrgu seadistused FW-CLUSTERist EMERGENCYle) (EMERGENCY);
- Lülitid võrgu infrastruktuuri haldamiseks (L2-MGMT);
- Virtuaalne masin Git'i ja Ansible'i jaoks (VM-AUTOMATION);
- Arvuti, millel testitakse ja arendatakse Ansible'i playbook’e (Laptop-Automation).
Võrgus on seadistatud dünaamiline marsruutimisprotokoll OSPF järgmiste aladega:
- Area 0 – ala, kuhu kuuluvad marsruutorid, mis vastutavad liikluse edasiviimise eest EXCHANGE tsoonis;
- Area 1 – ala, kuhu kuuluvad marsruutorid, mis vastutavad ettevõtte teenuste toimimise eest;
- Area 2 – ala, kuhu kuuluvad marsruutorid, mis vastutavad juhtimist liikluse marsruutimise eest;
- Area N – haru võrkude alad.
Piiriveerandi marsruutorites on loodud virtuaalne marsruutor (VRF-INTERNET), kus on seadistatud eBGP full view vastava määra AS-iga. VRF-ide vahel on seadistatud iBGP. Ettevõttel on valgete IP-aadresside hulk, mis on avaldatud nende VRF-INTERNET-is. Osa valgetest aadressidest marsruutimine toimub otse FW-CLUSTERi (aadressid, millel töötavad ettevõtte teenused), osa marsruutimine toimub EXCHANGE tsooni kaudu (ettevõtte siseteenused, mis vajavad väliseid IP-aadresse, ja välised aadressid NAT-iks kontoritele). Edasi jõuab liiklus virtuaalsetesse marsruutoritesse, mis on loodud L3-CORE-s valgete ja hallide aadressidega (turvapiirkonnad).
Halduse võrgus kasutatakse eraldatud lülitusi ja see on füüsiliselt eraldatud võrk. Halduse võrk on samuti jagatud turvapiirkondadeks.
Kriisi marsruutor EMERGENCY dubleerib füüsiliselt ja loogiliselt FW-CLUSTERi. Sellel on välja lülitatud kõik liidesed, välja arvatud need, mis suunavad halduse võrku.
Automatiseerimine ja selle kirjeldus
Me oleme aru saanud, kuidas võrk töötab. Nüüd vaatame samm-sammult, mida me teeme, et suunata liiklust FW-CLUSTER-ist EMERGENCY-le:
- Lülitame välja L3-CORE lülitil liidesed, mis ühendavad seda FW-CLUSTER-iga;
- Lülitame välja L2-MGMT lülitil liidesed, mis ühendavad seda FW-CLUSTER-iga;
- Seame üles marsruutori EMERGENCY (vaikimisi on sellel välja lülitatud kõik liidesed, välja arvatud need, mis on seotud L2-MGMT-iga):
- Lülitame EMERGENCY-l liidesed sisse;
- Seame üles välise IP-aadressi (NAT jaoks), mis oli FW-Clusteril;
- Genereerime gARP päringud, et L3-CORE-i ARP-tabelites asenduvad MAC-aadressid FW-Clusterilt EMERGENCY-le;
- Seame peamarsruudi staatiliselt BRD-01-le, BRD-02-le;
- Loome NAT reeglid;
- Seame EMERGENCY-l üles OSPF Area 1;
- Seame EMERGENCY-l üles OSPF Area 2;
- Muudame marsruutide hinda Area 1-s 10-ks;
- Muudame vaikimisi marsruudi hinda Area 1-s 10-ks;
- Muudame ip-aadresside, mis on seotud L2-MGMT-iga (need, mis olid FW-CLUSTER-il);
- Genereerime gARP-päringud, et L2-MGMT ARP-tabelites MAC-aadressid FW-CLUSTER-ist EMERGENCY-le muutuksid.
Tagasi algse ülesande juurde. Kell on kolm öösel, tohutu stress, viga mis tahes etapis võib põhjustada uusi probleeme. Kas olete valmis CLI kaudu käske sisestama? Jah? Okei, mine vähemalt peske oma nägu, jooge kohvi ja koguge end kokku.
Bruce, palun aita hädalisi.
Jätkame oma automatiseerimise kallal töötamist.
Allpool on esitatud playbooki töö skeem Ansible'i terminoloogias. See skeem peegeldab seda, mida me just ülal kirjeldasime, kuid konkreetse rakenduse Ansible'is.
Sellel etapil oleme mõistnud, mida teha, välja töötanud playbooki, testinud seda ning nüüd oleme valmis seda käivitama.
Veel üks väike lühiõpik. Jutu lihtsus ei tohi teid petta. Playbookide kirjutamise protsess ei olnud nii lihtne ja kiire, nagu võib tunduda. Testimine võttis üsna kaua aega, loodi virtuaalne keskkond, lahendust testiti korduvalt, tehti umbes 100 testi.
Käivitame... Tundub, et kõik toimub väga aeglaselt, kuskil on viga, midagi ei tööta lõpuks. Tunne nagu langevarjuhüppel, kus langevari ei taha kohe avaneda... see on normaalne.
Edasi loeme Ansible'i playbooki täitmise tulemusi (IP-aadressid asendati saladuse nimel):
[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] *********************
muudetud: [vcf]
PLAY [------->Emergency on MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
muudetud: [m9-03-sw-03-mgmt-core]
PLAY [------->Emergency on] ****************************************************
TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
muudetud: [m9-04-r-04] => (item=12)
muudetud: [m9-04-r-04] => (item=14)
muudetud: [m9-04-r-04] => (item=15)
muudetud: [m9-04-r-04] => (item=16)
muudetud: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
muudetud: [m9-04-r-04] => (item=VLAN-1001)
muudetud: [m9-04-r-04] => (item=VLAN-1002)
muudetud: [m9-04-r-04] => (item=VLAN-1003)
muudetud: [m9-04-r-04] => (item=VLAN-1004)
muudetud: [m9-04-r-04] => (item=VLAN-1005)
muudetud: [m9-04-r-04] => (item=VLAN-1006)
muudetud: [m9-04-r-04] => (item=VLAN-1007)
muudetud: [m9-04-r-04] => (item=VLAN-1008)
muudetud: [m9-04-r-04] => (item=VLAN-1009)
muudetud: [m9-04-r-04] => (item=VLAN-1010)
muudetud: [m9-04-r-04] => (item=VLAN-1011)
muudetud: [m9-04-r-04] => (item=VLAN-1012)
muudetud: [m9-04-r-04] => (item=VLAN-1013)
muudetud: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
muudetud: [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] *********************
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
muudetud: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Valmis!
Tegelikult ei ole see veel täiesti valmis, ärge unustage dünaamiliste marsruutimisprotokollide konvergentsust ja suurte marsruutide koormust FIB-is. Me ei saa sellele kuidagi mõjuda. Ootame. Läks kokku. Nüüd on valmis.
Ja Vilabadzho külas (mis ei soovi võrgu seadistamist automatiseerida) jätkatakse nõude pesemist. Bruce (tõsi, juba teine, kuid mitte vähem äge) püüab aru saada, kui palju veel käsitsi seadmeid seadistada.
Soovin veel peatuda ühel olulisel hetkel. Kuidas me saame kõik tagasi tuua? Pärast mõnda aega toome tagasi meie FW-CLUSTERi. See on põhiseade, mitte varu, võrgu peab toimima sellel.
Kas tunnete, kuidas võrguhariduses hakkab närv üles kerkima? Tehniline direktor kuuleb tuhandeid argumente, miks seda ei peaks tegema ja miks seda saaks hiljem teha. Kahjuks koosneb võrgu töö paljuski plaasterdamisest, tükkidest ja endise luksuse jäänustest. Tulemuseks on tilk-kate. Meie ülesanne tervikuna, mitte ainult antud konkreetses olukorras, vaid IT-spetsialistidena üldiselt — tuua võrgu töö tagasi ilusasse ingliskeelsesse sõnasse „consistency”, millel on palju nüansse ja mida saab tõlkida järgmiselt: järjepidevus, mittevastuolulisus, loogilisus, ühtsus, süsteemsus, võrreldavus, seostatavus. Kõik see on selle kohta. Ainult sellises seisundis on võrgu haldamine võimalik, me mõistame selgelt, mis ja kuidas töötab, me oleme selgelt teadlikud, mida on vajadusel muuta, ja me teame täpselt, kuhu vaadata, kui probleeme tekib. Ainult sellises võrgus saab teha trikke, nagu me praegu oleme kirjeldanud.
Oli valmistatud veel üks playbook, mis taastab seaded algseisundisse. Selle tööloogika on sama (on oluline meeles pidada, et ülesannete järjekord on väga oluline), et mitte pikendada juba niigi pika artikli kanda, otsustasime playbooki käivitamise loendit mitte avaldada. Selliste harjutuste läbiviimisel tunned end palju rahulikumana ja kindlamana tulevikus, pealegi avastavad kõik toe, mis oled seal kokku keevitanud, koheselt end.
Kõik soovijad saavad meiega ühendust võtta ja saada algkoodide allika koos kõikide playbookidega. Kontaktid on profiilis.
Järeldused
Meie arvates ei ole protsessid, mida saaks automatiseerida, veel täielikult välja selgitatud. Lähtudes sellest, millega oleme kokku puutunud, ja sellest, mida arutavad meie lääne kolleegid, on hetkel nähtavad järgmised teemad:
- Seadmestiku seadistamine;
- Andmete kogumine;
- Aruandlus;
- Tõrkeotsing;
- Vastavus.
Kui huvi on, saame arutelu jätkata ühe eelmainitud teemadega.
Tahan veel natuke mõelda automatiseerimise teemal. Milline see meie arusaama järgi olema peaks:
- Süsteem peaks toimima ilma inimeseta, samas inimesest paranenud. Süsteem ei tohiks sõltuda inimesest;
- Kasutamine peab olema ekspertide tasemel. Puuduvad spetsialistide klass, kes teeksid rutiinseid ülesandeid. On eksperdid, kes on kogu rutiini automatiseerinud ja lahendavad ainult keerulisi ülesandeid;
- Rutiinsed ja standardiseeritud ülesanded tehakse automaatselt ühe nupuvajutusega, ressursse ei kulu. Selliste ülesannete tulemus on alati ennustatav ja arusaadav.
Ja kuhu need punktid peaksid viima:
- IT-infrastruktuuri läbipaistvus (Vähem risk eksploatatsioonis, moderniseerimises, rakendamises. Vähem seisakut aastas);
- Võimalus IT-ressursse planeerida (Capacity-planning system — selge, kui palju tarbitakse, selge, kui palju ressursse on üheainsa süsteemi jaoks vajalik, mitte kirjade ja osakondade tippude külastamise kaudu);
- Võimalus vähendada teenindava IT-personali arvu.
Artikli autorid: Aleksandr Čeljakov (CCIE RS, CCIE SP) ja Pavel Kirillov. Meil on huvitav arutada ja pakkuda välja lahendusi IT-infrastruktuuri automatiseerimise teemal.
Allikas: habr.com
