Tere, Habr!
Selles artiklis soovime rääkida võrguhalduse automatiseerimisest. Tutvustame töövõrguskeemi, mis toimib ühes väikeses, kuid väga uhkes ettevõttes. Kõik sarnased tegeliku võrguseadmega on juhuslikud. Vaatleme juhtumit, mis toimus selles võrgus ja mis oleks võinud põhjustada ettevõtte pikaajalise seisaku ning tõsiseid rahalisi kaotusi. Selle juhtumi lahendus sobib suurepäraselt võrguhalduse automatiseerimise kontseptsiooniga. Kasutades automatiseerimise vahendeid, näitame, kuidas saab tõhusalt lahendada keerulisi ülesandeid lühikese ajaga, ning arutleme, miks on tulevikus parem neid ülesandeid lahendada just nii, mitte teisiti (kaudu käsurea).
Märkus
Meie peamised automatiseerimistööriistad on Ansible (automatiseerimistööriist) ja Git (Ansible'i playbookide hoidla). Tähelepanu, et see ei ole tutvustav artikkel, kus räägitakse Ansible'i või Giti tööloogikast ja selgitatakse põhiasju (näiteks mis on Ansible'i rollid, moodulid, inventeerimisfailid ja muutujad või mis juhtub, kui sisestate käsud git push või git commit). See artikkel ei käsitle, kuidas Ansible'iga harjutada või seadistada NTP-d või SMTP-d. See räägib, kuidas kiiresti ja soovitavalt ilma vigadeta lahendada võrguprobleeme. Samuti on soovitatav omada head arusaama sellest, kuidas võrk töötab, sealhulgas, mis on TCP/IP protokollide, OSPF ja BGP kokkupuutevõime. Ansible'i ja Giti valimist käsitleme hiljem. Kui teil on veel valik konkreetse lahenduse osas, soovitame tungivalt 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 kolm öösel, magate sügavalt ja näete und. Telefon heliseb. Helistab tehniline direktor:
— Jah?
— ###, ####, #####, tulemüüride klaster on kokku kukkunud ja ei tõuse üles!!!
Te pühid silmi ja üritad teadvustada toimuvat ning ette kujutada, kuidas selline asi üldse juhtuda sai. Torus kuuleb, kuidas direktoril on juuksed peas katki ja ta palub tagasi helistada, kuna teisel joonel helistab talle peadirektor.
Pool tundi hiljem oled kogunud esimesed sissekanded öövahtkonnalt, oled äratanud kõik, keda oli võimalik ärgata. Lõppkokkuvõttes ei valetanud tehnilised direktor, kõik on tõsi: peamine tulemüüride klaster on kukkunud ja mingid põhitegevused ei too teda ellu. Kõik teenused, mida ettevõte pakub, ei tööta.
Vali probleem oma maitse järgi, igaüks mäletab midagi erilist. Näiteks, pärast öist värskendust ilma suure koormata töötas kõik hästi ja kõik rahulolevad läksid magama. Liiklus läks ja liideste puhverid hakkasid üle voolama, kuna võrguadapteri draiveris oli viga.
Seda situatsiooni suudab hästi kirjeldada Jackie Chan.
Aitäh, Jackie.
Situatsioon ei ole just meeldiv, ega ole?
Jätame meie mõttekaaslase hetkeks tema kurbade mõtetega.
Arutame, kuidas sündmused edaspidi arenevad.
Pakume välja järgmise materjali esitamise korra.
- Käsitleme võrgu skeemi ja selgitame, kuidas see toimib;
- Kirjeldame, kuidas kanname seadistused ühest ruuterist teise Ansible'i abil;
- Räägime IT-infrastruktuuri automatiseerimisest laiemalt.
Võrgu skeem ja selle kirjeldus
Skeem
Käsitleme meie organisatsiooni loogilist skeemi. Me ei nimeta konkreetselt seadmete tootjaid, kuna see ei ole artikli raames oluline. (Karm lugeja mõistab, milliseid seadmeid kasutatakse). See on just üks Ansible'i töö tõeliselt häid eeliseid — seadistamisel ei oma meile olulist vahet, mis seadmed need on. Lihtsalt arusaamiseks: need on tuntud tootjate seadmed, nagu Cisco, Juniper, Check Point, Fortinet, Palo Alto … võite sisse panna oma variandi.
Meil on kaks peamist ülesannet liikluse liigutamiseks:
- Tagada meie teenuste avaldamine, mis on ettevõtte äri;
- Tagada ühendus filiaalidega, kaugruumi ja kolmandate osapoolte organisatsioonidega (partnerite ja klientidega), samuti filiaalide internetiühendus keskuse kaudu.
Alustame põhielementidest:
- Kaks piiriruuterit (BRD-01, BRD-02);
- Tulekindlate tulemüüride klaster (FW-CLUSTER);
- Tuuma lüliti (L3-CORE);
- Ruuter, mis saab olema säästev ring (probleemi lahendamise käigus kolime võrgu seadistused FW-CLUSTERilt EMERGENCYle) (EMERGENCY);
- Lülitid võrgu infrastruktuuri haldamiseks (L2-MGMT);
- Virtuaalne masin Git'i ja Ansible'i jaoks (VM-AUTOMATION);
- Sülearvuti, millel testitakse ja arendatakse Ansible'i playbook'e (Laptop-Automation).
Võrgus on seadistatud dünaamiline marsruutimise protokoll OSPF järgmiste ala(de)ga:
- Area 0 – ala, kuhu kuuluvad ruuterid, mis vastutavad liikluse suunamise eest EXCHANGE piirkonnas;
- Area 1 – ala, kuhu kuuluvad ruuterid, mis vastutavad ettevõtte teenuste töö eest;
- Area 2 – ala, kuhu kuuluvad ruuterid, mis vastutavad haldustrafiku marsruutimise eest;
- Area N – filiaalide võrkude alad.
Piiri marsruuteritel on loodud virtuaalne marsruuter (VRF-INTERNET), millel on tõstetud eBGP täisvaade koos vastava AS-iga. VRF-ide vahel on seadistatud iBGP. Ettevõtte käsutuses on valgete IP-aadresside hulk, mis on avaldatud nendele VRF-INTERNET-idele. Osad valged aadressid marsruutitakse otse FW-CLUSTERisse (aadressid, kus töötavad ettevõtte teenused), osa marsruutitakse EXCHANGE tsooni kaudu (ettevõtte sise teenused, mis vajavad väliseid IP-aadresse, ja välised NAT-aadressid kontoritele). Edasi suundub liiklus virtuaalsetele marsruutijatele, mis on loodud L3-CORE'is valgete ja hallide aadressidega (turvatsoonid).
Haldusvõrgus kasutatakse eraldatud lülitusseadmeid ja see moodustab füüsiliselt eraldatud võrgu. Haldusvõrk on samuti jagatud turvatsoonideks.
Hädaolukorra marsruuter EMERGENCY füüsiliselt ja loogiliselt duplikeerib FW-CLUSTERi. Sellel on keelatud kõik liidesed, välja arvatud need, mis suunavad haldusvõrku.
Automatiseerimine ja selle kirjeldus
Oleme aru saanud, kuidas võrk töötab. Nüüd käsitleme samm-sammult, mida me teeme, et liiklust FW-CLUSTERist EMERGENCY-le suunata:
- Lülitame välja L3-CORE'i lüliti liidesed, mis ühendavad selle FW-CLUSTERiga;
- Keerame välja L2-MGMT lülituslülid, mis seovad selle FW-CLUSTERiga;
- Konfigureerime EMERGENCY marsruuteri (kõik liidendid on vaikimisi välja lülitatud, välja arvatud need, mis on ühendatud L2-MGMT-ga):
- Lülitame liidendid EMERGENCY-l sisse;
- Seame välist IP-aadressi (NAT jaoks), mis oli FW-Clusteril;
- Geneerime gARP päringud, et L3-CORE arvutustes vahetuksid MAC-aadressid FW-Clusterilt EMERGENCY-le;
- Kirjutame staatilise vaikemarsruudi BRD-01, BRD-02 suunas;
- Loome NAT reeglid;
- Käivitame EMERGENCY-l OSPF ala 1;
- Käivitame EMERGENCY-l OSPF ala 2;
- Muudame ala 1 marsruutide hinda 10-ks;
- Muudame ala 1 vaikemarsruudi hinda 10-ks;
- Muuda IP-aadressid., mis on seotud L2-MGMT-ga (nende suhtes, mis olid FW-CLUSTERil);
- Geneerime gARP päringud, et L2-MGMT arvutustes vahetuksid MAC-aadressid FW-CLUSTERilt EMERGENCY-le.
Tagasi algse ülesande juurde. Kell on kolm öösel, tohutu stress, viga igas etapis võib põhjustada uusi probleeme. Kas olete valmis CLI kaudu käske sisestama? Jah? Okei, minge vähemalt loputage nägu, jooge kohvi ja koguge julgus.
Bruce, palun aita meid, sõbrad.
Ja meie jätkame oma automatiseerimise arendamist.
Allpool on esitatud playbook'i töödiagramm Ansible'i mõistes. See skeem peegeldab seda, mida me varem kirjeldasime, lihtsalt juba konkreetne teostus Ansible'is.
Sellel etapil oleme mõistnud, mida teha, välja töötanud playbook'i, viinud läbi testimise ja nüüd oleme valmis selle käivitama.
Veel üks väike lühipause. Narri kergus ei tohi teid petta. Playbook'ide kirjutamise protsess ei olnud lihtne ja kiire, nagu võib tunduda. Testimine võttis üsna kaua aega, loodi virtuaalne seade, lahendust testiti korduvalt, kokku viidi läbi umbes 100 testi.
Käivitame... On tunne, et kõik toimub väga aeglaselt, kuskil on viga, midagi ei tööta. Tunne on nagu langevarjuhüppes, kus langevarjuga on kohe avamine raskusi... see on normaalne.
Edasi loeme Ansible'i playbook'i sooritatud toimingute tulemusi (IP-aadressid on eesmärgitult asendatud):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Häda VCF-is] ********************************************************
TASK [vcf_junos_emergency_on : Keela PROD liidesed FW-CLUSTER-ile] *********************
muudetud: [vcf]
PLAY [------->Häda MGMT-CORE-is] ************************************************
TASK [mgmt_junos_emergency_on : Keela MGMT liidesed FW-CLUSTER-ile] ******************
muudetud: [m9-03-sw-03-mgmt-core]
PLAY [------->Häda] ****************************************************
TASK [mk_routeros_emergency_on : Luba EXT-INTERNET liides] **************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Genera gARP EXT-INTERNET liidese jaoks] ****************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Luba staatiline vaike marsruut EXT-INTERNET-i] ****************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Muuda NAT reegel EXT-INTERNET liidese jaoks] ****************
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 : Luba OSPF Ala 1 PROD] ******************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Luba OSPF Ala 2 MGMT] *****************************
muudetud: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Muuda OSPF Ala 1 liidese kulusid 10-ks] *****************
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 : Muuda MGMT liidese IP aadresse] ********************
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 : Genera gARPs MGMT liidese jaoks] *********************
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 valmis, ärge unustage dünaamiliste marsruutimisprotokollide konvergentsi ja suurte marsruutide laadimist FIB-i. Sellele me ei saa mingil moel mõju avaldada. Ootame. Kokku tuli. Nüüd on see valmis.
Ja Vilabajõ külas (mis ei soovi võrgu seadistamist automatiseerida) pestakse jätkuvalt nõusid. Bruce (tõsi, juba teine, kuid mitte vähem äge) püüab mõista, kui palju veel tuleb seadmeid käsitsi ümber seadistada.
Sooviksin peatuda veel ühel olulisel hetkel. Kuidas me saame kõik tagasi tuua? Mõne aja pärast toome meie FW-CLUSTERi ellu tagasi. See on põhiseade, mitte varu, ja see peab toetama võrku.
Kas tunned, kuidas võrguinimesed hakkavad ärevaks minema? Tehniline direktor kuuleb tuhandet argumenti, miks seda mitte teha ja miks seda saab hiljem teha. Kahjuks koosneb võrgu töö paljuski patchwork'ist, killust ja kunagisest luksusest. Tulemuseks on lapitekk. Meie eesmärk, mitte ainult antud konkreetses olukorras, vaid üldiselt IT-spetsialistidena, on viia võrgu töö ilusasse ingliskeelsesse sõnasse "consistency", mis on väga mitmekesine ja võib tõlkida kui: järjepidevus, kooskõla, loogilisus, korralikkus, süsteemsus, võrreldavus, seotusus. See kõik on selle kohta. Ainult sellises seisundis on võrk hallatav; me mõistame selgelt, mis ja kuidas töötab, teame selgelt, mida on vajadusel vaja muuta, ja teame täpselt, kuhu vaatama minna, kui tekivad probleemid. Ainult sellises võrgus saab teha trikke, nagu me praegu kirjeldame.
Tegelikult on valmis veel üks playbook, mis taastab seaded algolekusse. Selle tööloogika on sama (on oluline meeles pidada, et ülesannete järjekord on väga oluline); et mitte pikendada niigi üsna pikka artiklit, otsustasime mitte avaldada playbooki täitmise loendit. Selliseid harjutusi läbides tunnete end tulevikus palju rahulikumalt ja kindlamalt, lisaks ilmnevad kohe kõik koodilõigud, mida olete sinna ehitanud.
Kõik huvilised võivad meile kirjutada ja saada kõigi kirjutatud koodide allikaid koos kõigi playbookidega. Kontaktandmed on profiilis.
Järeldused
Meie arvates ei ole veel automaatiseeritavad protsessid täielikult välja kujunenud. Arvestades, millega me oleme silmitsi seisnud, ja seda, millest arutavad meie läänesõbrad, paistavad hetkel silma järgmised teemad:
- Seadmete seadistamine;
- Andmete kogumine;
- Aruandlus;
- Probleemide lahendamine;
- Vastavus.
Kui on huvi, saame arutada mõnda neist teemadest edasi.
Soovime veel veidi arutleda automatiseerimise üle. Milline see meie arusaama järgi olema peaks:
- Süsteem peab elama ilma inimeseta, samas inimesega paranenud. Süsteem ei tohi sõltuda inimesest;
- Täitmine peab olema ekspertide käes. Puuduvad spetsialistide klass, kes teevad rutiinseid ülesandeid. On eksperdid, kes on kogu rutiini automatiseerinud ja tegelevad ainult keeruliste ülesannetega;
- Rutiinsed standardülesanded tehakse automaatselt „nupu vajutamisega”, ressursse ei kulutata. Selliste ülesannete tulemus on alati ettearvatav ja arusaadav.
Ja millele need punktid peaksid viima:
- IT-infrastruktuuri läbipaistvus (Vähem kasutamise, moderniseerimise, juurutamise riske. Vähem seisakuid aastas);
- Võimalus IT-ressursse planeerida (Kapatsiteedi planeerimise süsteem — on näha, kui palju tarbitakse, on näha, kui palju ressursse on ühes süsteemis vajalik, mitte e-kirjade ja osakondade juhtide juurde käimise kaudu);
- Võimalus vähendada teenindava IT-personali arvu.
Artikli autorid: Aleksandr Čeljakov (CCIE RS, CCIE SP) ja Pavel Kirillov. Meid huvitab arutada ja pakkuda lahendusi IT-infrastruktuuri automatiseerimise teemal.
Allikas: habr.com
