SDSM on ohi, mutta hallitsematon halu kirjoittaa säilyy.

Veljemme kärsi useiden vuosien ajan rutiinityöstä, sormien ristissä ennen sitoutumista ja unen puutteesta öisten peruutusten vuoksi.
Mutta synkät ajat ovat loppumassa.

Tällä artikkelilla aloitan sarjan siitä, miten minua automaatio näkyy.
Matkan varrella ymmärrämme automaation vaiheet, muuttujien tallennuksen, suunnittelun formalisoinnin, RestAPI, NETCONF, YANG, YDK ja teemme paljon ohjelmointia.
Minua tarkoittaa, että a) se ei ole objektiivinen totuus, b) se ei ole ehdottoman paras lähestymistapa, c) mielipiteeni voi muuttua jopa siirtyessäni ensimmäisestä viimeiseen artikkeliin - ollakseni rehellinen, luonnosvaiheesta julkaisussa, kirjoitin kaiken kokonaan uudelleen kahdesti.

Pitoisuus

1. tavoitteet
   1. Verkosto on kuin yksittäinen organismi
   2. Kokoonpanon testaus
   3. Versiointi
   4. Palveluiden seuranta ja itsehoito

2. Varat
   1. Varastojärjestelmä
   2. IP-tilanhallintajärjestelmä
   3. Verkkopalvelun kuvausjärjestelmä
   4. Laitteen alustusmekanismi
   5. Toimittaja-agnostinen kokoonpanomalli
   6. Toimittajakohtainen ohjainliittymä
   7. Mekanismi konfiguroinnin toimittamiseksi laitteeseen
   8. CI / CD
   9. Mekanismi varmuuskopiointiin ja poikkeamien etsimiseen
   10. Valvontajärjestelmä

3. Johtopäätös

Yritän suorittaa ADSM:n muodossa, joka on hieman erilainen kuin SDSM. Isoja, yksityiskohtaisia, numeroituja artikkeleita ilmestyy jatkossakin, ja niiden väliin julkaisen pieniä muistiinpanoja arjen kokemuksista. Yritän taistella perfektionismia vastaan, enkä nuole niitä kaikkia.

Kuinka hauskaa onkaan, että toisen kerran joudut kulkemaan samaa polkua.

Aluksi minun piti kirjoittaa artikkeleita verkoista itse, koska ne eivät olleet RuNetissä.

Nyt en löytänyt kattavaa asiakirjaa, joka systematisoi lähestymistapoja automaatioon ja analysoi yllä olevia teknologioita yksinkertaisten käytännön esimerkkien avulla.

Saatan olla väärässä, joten anna linkkejä hyödyllisiin resursseihin. Tämä ei kuitenkaan muuta päättäväisyyttäni kirjoittaa, sillä päätavoitteena on oppia itse jotain ja muiden elämän helpottaminen on mukava bonus, joka hyväilee kokemuksen jakamisen geeniä.

Yritämme ottaa keskikokoisen LAN DC -palvelinkeskuksen ja suunnitella koko automaatiosuunnitelman.
Teen joitain asioita melkein ensimmäistä kertaa kanssasi.

En ole omaperäinen tässä kuvatuissa ideoissa ja työkaluissa. Dmitri Figolilla on erinomainen kanava, jolla on striimejä tästä aiheesta.
Artikkelit menevät päällekkäin niiden kanssa monilta osin.

LAN DC:ssä on 4 DC:tä, noin 250 kytkintä, puoli tusinaa reititintä ja pari palomuuria.
Ei Facebook, mutta tarpeeksi saa sinut ajattelemaan syvällisesti automaatiota.
On kuitenkin olemassa mielipide, että jos sinulla on enemmän kuin 1 laitetta, automaatiota tarvitaan jo.
Itse asiassa on vaikea kuvitella, että kukaan voi nyt elää ilman ainakin pakettia polvikäsikirjoituksia.
Vaikka kuulin, että on toimistoja, joissa IP-osoitteet säilytetään Excelissä, ja jokainen tuhansista verkkolaitteista on määritetty manuaalisesti ja niillä on oma ainutlaatuinen kokoonpanonsa. Tätä voidaan tietysti pitää modernina taiteena, mutta insinöörin tunteet loukkaantuvat varmasti.

tavoitteet

Nyt asetamme abstraktiimmat tavoitteet:

• Verkosto on kuin yksittäinen organismi
• Kokoonpanon testaus
• Verkon tilan versiointi
• Palveluiden seuranta ja itsehoito

Myöhemmin tässä artikkelissa tarkastelemme, mitä keinoja käytämme, ja seuraavassa tarkastelemme tavoitteita ja keinoja yksityiskohtaisesti.

Verkosto on kuin yksittäinen organismi

Sarjan määrittävä lause, vaikka se ei ensi silmäyksellä ehkä vaikutakaan niin merkittävältä: määritämme verkon, emme yksittäisiä laitteita.
Viime vuosina olemme nähneet painopisteen siirtymisen kohti verkon käsittelemistä yhtenä kokonaisuutena, joten Ohjelmiston määrittämä verkko, Tarkoitusvetoiset verkot и Autonomiset verkot.
Loppujen lopuksi mitä sovellukset tarvitsevat globaalisti verkosta: liitettävyyttä pisteiden A ja B välillä (no, joskus +B-Z) ja eristäytymistä muista sovelluksista ja käyttäjistä.

Ja niin meidän tehtävämme tässä sarjassa on rakentaa järjestelmän, säilyttäen nykyisen kokoonpanon koko verkko, joka on jo jaettu kunkin laitteen todelliseksi kokoonpanoksi sen roolin ja sijainnin mukaisesti.
Järjestelmä verkonhallinta tarkoittaa, että otamme siihen yhteyttä tehdäksemme muutoksia, ja se puolestaan ​​laskee kullekin laitteelle halutun tilan ja konfiguroi sen.
Tällä tavalla minimoimme manuaalisen pääsyn CLI:hen lähes nollaan - kaikki laitteen asetusten tai verkon suunnittelun muutokset on virallistettava ja dokumentoitava - ja vasta sitten levitetään tarvittaviin verkkoelementteihin.

Eli jos esimerkiksi päätimme, että tästä lähtien Kazanin telinekytkimien pitäisi ilmoittaa kahdesta verkosta yhden sijaan,

1. Ensin dokumentoidaan järjestelmien muutokset
2. Luodaan kaikkien verkkolaitteiden kohdekokoonpano
3. Käynnistämme verkkoasetusten päivitysohjelman, joka laskee, mitä kussakin solmussa pitää poistaa, mitä pitää lisätä ja saattaa solmut haluttuun tilaan.

Samanaikaisesti teemme muutoksia manuaalisesti vain ensimmäisessä vaiheessa.

Kokoonpanon testaus

Se on tiedossaettä 80% ongelmista tapahtuu kokoonpanomuutosten aikana - epäsuora todiste tästä on, että uudenvuoden lomien aikana kaikki on yleensä rauhallista.
Olen henkilökohtaisesti nähnyt kymmeniä globaaleja seisokkeja inhimillisen virheen vuoksi: väärä komento, konfigurointi suoritettiin väärässä haarassa, yhteisö unohti, MPLS purettiin maailmanlaajuisesti reitittimessä, viisi laitteistoa konfiguroitiin, mutta virhe ei ollut huomattiin kuudentena, toisen henkilön tekemiä vanhoja muutoksia tehtiin . Skenaarioita on paljon.

Automatisoinnin ansiosta voimme tehdä vähemmän virheitä, mutta suuremmassa mittakaavassa. Tällä tavalla voit estää vain yhden laitteen, vaan koko verkon kerralla.

Muinaisista ajoista lähtien isoisämme tarkastivat terävällä silmällä tehtyjen muutosten oikeellisuuden, teräspallot ja verkon toimivuuden niiden käyttöönoton jälkeen.
Ne isoisät, joiden työ johti seisokkeihin ja katastrofaalisiin menetyksiin, jättivät vähemmän jälkeläisiä ja niiden pitäisi kuolla sukupuuttoon ajan myötä, mutta evoluutio on hidas prosessi, eivätkä kaikki siksi vielä testaa muutoksia laboratoriossa ensin.
Edistyksen eturintamassa ovat kuitenkin ne, jotka ovat automatisoineet kokoonpanon testauksen ja sen edelleen soveltamisen verkkoon. Toisin sanoen lainasin CI/CD-menettelyn (Jatkuva integrointi, jatkuva käyttöönotto) kehittäjiltä.
Yhdessä osassa tarkastelemme, kuinka tämä toteutetaan versionhallintajärjestelmällä, luultavasti Githubilla.

Kun olet tottunut verkko-CI/CD-ajatukseen, menetelmä konfiguraation tarkistamiseksi soveltamalla sitä tuotantoverkkoon näyttää yhdessä yössä varhaiskeskiaikaiselta tietämättömyydestä. Vähän kuin iskeisi vasaralla taistelukärkeen.

Orgaaninen jatko ajatuksille aiheesta järjestelmä verkonhallinnasta ja CI/CD:stä tulee kokoonpanon täysi versio.

Versiointi

Oletetaan, että kaikilla, jopa pienimmillä muutoksilla, jopa yhdellä huomaamattomalla laitteella, koko verkko siirtyy tilasta toiseen.
Ja emme aina suorita komentoa laitteessa, vaan muutamme verkon tilaa.
Kutsutaanko näitä osavaltioita siis versioiksi?

Oletetaan, että nykyinen versio on 1.0.0.
Onko yhden ToR:n Loopback-liitännän IP-osoite muuttunut? Tämä on pieni versio ja sen numero on 1.0.1.
Tarkistimme reittien tuontia koskevat käytännöt BGP:hen - hieman vakavammin - jo 1.1.0
Päätimme luopua IGP:stä ja vaihtaa vain BGP:hen - tämä on jo radikaali suunnittelumuutos - 2.0.0.

Samaan aikaan eri DC:illä voi olla erilaisia ​​versioita - verkko kehittyy, uusia laitteita asennetaan, uusia tasoja lisätään jonnekin, ei muihin jne.

Про semanttinen versiointi puhumme erillisessä artikkelissa.

Toistan - mikä tahansa muutos (paitsi virheenkorjauskomentoja) on versiopäivitys. Ylläpitäjille on ilmoitettava kaikista poikkeamista nykyisestä versiosta.

Sama koskee muutosten palauttamista - tämä ei ole viimeisten komentojen peruuttamista, tämä ei ole palautus laitteen käyttöjärjestelmän avulla - tämä tuo koko verkon uuteen (vanhaan) versioon.

Palveluiden seuranta ja itsehoito

Tämä itsestään selvä tehtävä on saavuttanut uuden tason nykyaikaisissa verkoissa.
Usein suuret palveluntarjoajat omaksuvat sen lähestymistavan, että epäonnistunut palvelu on korjattava nopeasti ja nostettava uusi sen sijaan, että selvittäisivät mitä tapahtui.
"Erittäin" tarkoittaa, että sinun on oltava kaikilta puolilta runsaasti pinnoitettu valvonnalla, joka havaitsee sekunneissa pienimmätkin poikkeamat normista.
Ja tässä tavalliset mittarit, kuten käyttöliittymän lataus tai solmun saatavuus, eivät enää riitä. Niiden manuaalinen valvonta päivystäjän toimesta ei myöskään riitä.
Monelle asialle pitäisi olla Itsehoito — Valvontavalot syttyivät punaisiksi ja menimme itse levittämään jauhobanaania sinne, missä se sattui.

Ja täällä valvomme myös yksittäisten laitteiden lisäksi koko verkon kuntoa, sekä whiteboxin, mikä on suhteellisen ymmärrettävää, että blackboxin, joka on monimutkaisempi.

Mitä tarvitsemme tällaisten kunnianhimoisten suunnitelmien toteuttamiseksi?

• Pidä luettelo kaikista verkossa olevista laitteista, niiden sijainnista, rooleista, malleista ja ohjelmistoversioista.
  kazan-leaf-1.lmu.net, Kazan, lehti, Juniper QFX 5120, R18.3.
• Sinulla on järjestelmä verkkopalvelujen kuvaamiseksi.
  IGP, BGP, L2/3VPN, käytäntö, ACL, NTP, SSH.
• Pystyy alustamaan laite.
  Isäntänimi, Mgmt IP, Mgmt Route, Käyttäjät, RSA-avaimet, LLDP, NETCONF
• Konfiguroi laite ja tuo konfiguraatio haluttuun (mukaan lukien vanhaan) versioon.
• Testaa kokoonpano
• Tarkista säännöllisesti kaikkien laitteiden tila poikkeamien varalta nykyisistä ja ilmoita kenelle sen pitäisi olla.
  Yön aikana joku lisäsi hiljaa säännön ACL:ään.
• Seuraa suorituskykyä.

Varat

Se kuulostaa tarpeeksi monimutkaiselta aloittaaksesi projektin jakamisen osiin.

Ja niitä tulee olemaan kymmenen:

1. Varastojärjestelmä
2. IP-tilanhallintajärjestelmä
3. Verkkopalvelun kuvausjärjestelmä
4. Laitteen alustusmekanismi
5. Toimittaja-agnostinen kokoonpanomalli
6. Toimittajakohtainen ohjainliittymä
7. Mekanismi konfiguroinnin toimittamiseksi laitteeseen
8. CI / CD
9. Mekanismi varmuuskopiointiin ja poikkeamien etsimiseen
10. Valvontajärjestelmä

Tämä on muuten esimerkki siitä, kuinka näkemys syklin tavoitteista muuttui - luonnoksessa oli 4 komponenttia.

Kuvassa kuvasin kaikki komponentit ja itse laitteen.
Leikkaavat komponentit ovat vuorovaikutuksessa toistensa kanssa.
Mitä suurempi lohko, sitä enemmän huomiota on kiinnitettävä tähän komponenttiin.

Komponentti 1: Varastojärjestelmä

Ilmeisesti haluamme tietää, mitkä laitteet missä sijaitsevat, mihin on kytketty.
Varastojärjestelmä on olennainen osa mitä tahansa yritystä.
Useimmiten yrityksellä on erillinen verkkolaitteiden inventointijärjestelmä, joka ratkaisee tarkemmat ongelmat.
Osana tätä artikkelisarjaa kutsumme sitä nimellä DCIM - Data Center Infrastructure Management. Vaikka itse termi DCIM sisältää varsinaisesti paljon muutakin.

Tallennamme tarkoituksiinmme seuraavat tiedot laitteesta siihen:

• Varastonumero
• Otsikon kuvaus
• Malli (Huawei CE12800, Juniper QFX5120 jne.)
• Ominaiset parametrit (levyt, liitännät jne.)
• Rooli (Leaf, Spine, Border Router jne.)
• Sijainti (alue, kaupunki, datakeskus, teline, yksikkö)
• Laitteiden väliset liitännät
• Verkkotopologia

On täysin selvää, että me itse haluamme tietää kaiken tämän.
Mutta auttaako tämä automaatiotarkoituksiin?
Varmasti.
Tiedämme esimerkiksi, että tietyssä Leaf-kytkimien palvelinkeskuksessa, jos kyseessä on Huawei, ACL:itä tietyn liikenteen suodattamiseksi tulisi käyttää VLANissa, ja jos se on Juniper, niin fyysisen rajapinnan yksikössä 0.
Tai sinun on otettava uusi Syslog-palvelin käyttöön alueen kaikille rajoilla.

Siihen tallennamme virtuaalisia verkkolaitteita, esimerkiksi virtuaalisia reitittimiä tai juuriheijastimia. Voimme lisätä DNS-palvelimia, NTP:tä, Syslogia ja yleensä kaikkea, mikä tavalla tai toisella liittyy verkkoon.

Komponentti 2: IP-tilanhallintajärjestelmä

Kyllä, ja nykyään on joukko ihmisiä, jotka pitävät kirjaa etuliitteistä ja IP-osoitteista Excel-tiedostossa. Mutta nykyaikainen lähestymistapa on edelleen tietokanta, jossa on nginx/apache-etuosa, API ja laajat toiminnot IP-osoitteiden ja VRF:ihin jaettujen verkkojen tallentamiseen.
IPAM - IP-osoitteiden hallinta.

Tallennamme siihen tarkoituksiinsa seuraavat tiedot:

• VLAN
• VRF laajennus
• Verkot/aliverkot
• IP-osoitteet
• Sido osoitteita laitteisiin, verkkoja sijainteihin ja VLAN-numeroihin

Jälleen on selvää, että haluamme varmistaa, että kun varaamme uuden IP-osoitteen ToR-silmukalle, emme kompastu siihen, että se on jo osoitettu jollekin. Tai että käytimme samaa etuliitettä kahdesti verkon eri päissä.
Mutta miten tämä auttaa automaatiossa?
Se on helppoa.
Pyydämme järjestelmään etuliitettä Loopbacks-roolilla, joka sisältää allokoitavissa olevat IP-osoitteet - jos se löytyy, annamme osoitteen, jos ei, pyydämme uuden etuliitettä.
Tai laitekonfiguraatiota luotaessa voimme saada samasta järjestelmästä selville, missä VRF:ssä rajapinnan tulisi sijaita.
Ja uutta palvelinta käynnistettäessä skripti kirjautuu järjestelmään, selvittää missä kytkimessä palvelin on, mikä portti ja mikä aliverkko on liitetty rajapinnalle - ja jakaa siitä palvelimen osoitteen.

Tämä viittaa haluun yhdistää DCIM ja IPAM yhdeksi järjestelmäksi, jotta toiminnot eivät päällekkäisy eikä palvelisi kahta samanlaista kokonaisuutta.
Niin me teemme.

Komponentti 3. Järjestelmä verkkopalvelujen kuvausta varten

Jos kaksi ensimmäistä järjestelmää tallentavat muuttujia, joita on vielä jotenkin käytettävä, niin kolmas kuvaa kullekin laiteroolille, kuinka se tulisi määrittää.
On syytä erottaa kaksi eri verkkopalvelutyyppiä:

• Infrastruktuuri
• Asiakas.

Ensimmäiset on suunniteltu tarjoamaan perusyhteydet ja laiteohjauksen. Näitä ovat VTY, SNMP, NTP, Syslog, AAA, reititysprotokollat, CoPP jne.
Jälkimmäiset järjestävät palvelun asiakkaalle: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP jne.
Tietysti on myös rajatapauksia - mihin sisällyttää MPLS LDP, BGP? Kyllä, ja reititysprotokollia voidaan käyttää asiakkaille. Mutta tämä ei ole tärkeää.

Molemmat palvelutyypit on jaettu konfiguraatioprimitiiviksi:

• fyysiset ja loogiset rajapinnat (tag/anteg, mtu)
• IP-osoitteet ja VRF:t (IP, IPv6, VRF)
• ACL-luettelot ja liikenteen käsittelykäytännöt
• Protokollat ​​(IGP, BGP, MPLS)
• Reitityskäytännöt (etuliiteluettelot, yhteisöt, ASN-suodattimet).
• Apuohjelmat (SSH, NTP, LLDP, Syslog...)
• Jne.

Kuinka tarkalleen teemme tämän, minulla ei ole vielä aavistustakaan. Tarkastelemme sitä erillisessä artikkelissa.

Jos vähän lähempänä elämää, niin voisimme kuvailla sitä
Leaf-kytkimessä on oltava BGP-istunnot kaikkien kytkettyjen Spine-kytkimien kanssa, sen on tuotava yhdistetyt verkot prosessiin ja hyväksyttävä vain verkot tietyltä etuliitteeltä Spine-kytkimistä. Rajoita CoPP IPv6 ND 10 pps:iin jne.
Selkät puolestaan ​​pitävät istuntoja kaikkien kytkettyjen johtimien kanssa, jotka toimivat juuriheijastimina, ja ottavat niistä vastaan ​​vain tietyn pituisia ja tietyn yhteisön kanssa kulkevia reittejä.

Komponentti 4: Laitteen alustusmekanismi

Tämän otsikon alle yhdistän monia toimintoja, joiden on tapahduttava, jotta laite ilmestyy tutkalle ja sitä voidaan käyttää etänä.

1. Syötä laite varastojärjestelmään.
2. Valitse hallinnan IP-osoite.
3. Määritä sen peruskäyttö:
   Isäntänimi, hallinnan IP-osoite, reitti hallintaverkkoon, käyttäjät, SSH-avaimet, protokollat ​​- telnet/SSH/NETCONF

On kolme lähestymistapaa:

• Kaikki on täysin manuaalista. Laite tuodaan osastolle, jossa tavallinen luomuihminen syöttää sen järjestelmiin, kytkeytyy konsoliin ja konfiguroi sen. Voi toimia pienissä staattisissa verkoissa.
• ZTP - Zero Touch Provisioning. Laitteisto saapui, nousi seisomaan, vastaanotti osoitteen DHCP:n kautta, meni erityiselle palvelimelle ja konfiguroi itsensä.
• Konsolipalvelinten infrastruktuuri, jossa alkuperäinen konfigurointi tapahtuu konsoliportin kautta automaattitilassa.

Puhumme kaikista kolmesta erillisessä artikkelissa.

Komponentti 5: Toimittajan agnostinen kokoonpanomalli

Tähän asti kaikki järjestelmät ovat olleet erilaisia ​​korjaustiedostoja, jotka tarjoavat muuttujia ja deklaratiivisen kuvauksen siitä, mitä haluaisimme nähdä verkossa. Mutta ennemmin tai myöhemmin joudut käsittelemään yksityiskohtia.
Tässä vaiheessa jokaiselle tietylle laitteelle primitiivit, palvelut ja muuttujat yhdistetään konfiguraatiomalliksi, joka itse asiassa kuvaa tietyn laitteen täydellistä konfiguraatiota, vain toimittajaneutraalilla tavalla.
Mitä tämä vaihe tekee? Mikset luo heti laitekokoonpanoa, jonka voit yksinkertaisesti ladata?
Itse asiassa tämä ratkaisee kolme ongelmaa:

1. Älä mukaudu tiettyyn käyttöliittymään laitteen kanssa vuorovaikutuksessa. Olipa kyseessä CLI, NETCONF, RESTCONF, SNMP - malli on sama.
2. Älä säilytä mallien/komentosarjojen määrää verkon toimittajien määrän mukaan, ja jos rakenne muuttuu, muuta sama asia useassa paikassa.
3. Lataa konfiguraatio laitteesta (varmuuskopio), laita se täsmälleen samaan malliin ja vertaa kohdekonfiguraatiota suoraan nykyiseen laskeaksesi delta ja valmistellaksesi konfiguraatiokorjauksen, joka muuttaa vain tarpeellisia osia tai tunnistaa poikkeamia.

Tämän vaiheen tuloksena saamme toimittajasta riippumattoman kokoonpanon.

Komponentti 6. Toimittajakohtainen ohjainliitäntä

Ei kannata imartella itseäsi toiveilla, että jonain päivänä ciska voidaan konfiguroida täsmälleen samalla tavalla kuin Juniper, yksinkertaisesti lähettämällä heille täsmälleen samat kutsut. Huolimatta valkoisten laatikoiden kasvavasta suosiosta ja NETCONF-, RESTCONF- ja OpenConfig-tuen ilmaantumisesta, näiden protokollien tarjoama sisältö vaihtelee toimittajasta toiseen, ja tämä on yksi niiden kilpailueroista, josta ne eivät luovuta niin helposti.
Tämä on suunnilleen sama kuin OpenContrail ja OpenStack, joiden NorthBound-liittymänä on RestAPI, odottavat täysin erilaisia ​​kutsuja.

Joten viidennessä vaiheessa toimittajasta riippumattoman mallin on otettava muoto, jossa se siirtyy laitteistoon.
Ja tässä kaikki keinot ovat hyviä (ei): CLI, NETCONF, RESTCONF, SNMP yksinkertaisesti.

Siksi tarvitsemme ohjaimen, joka siirtää edellisen vaiheen tuloksen tietyn toimittajan vaadittuun muotoon: joukko CLI-komentoja, XML-rakenne.

Komponentti 7. Mekanismi konfiguroinnin toimittamiseksi laitteeseen

Olemme luoneet konfiguraation, mutta se on vielä toimitettava laitteisiin - eikä tietenkään käsin.
Ensiksi, joudumme kysymään, mitä liikennettä käytämme? Ja tänään valinta ei ole enää pieni:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (vaikka se on poikkeava, koska se on tapa toimittaa FIB, ei asetuksia)

Laitetaan t-kirjain tähän. CLI on perintöä. SNMP... yskä yskä.
RESTCONF on edelleen tuntematon eläin; REST API:ta ei tue melkein kukaan. Siksi keskitymme sarjassa NETCONF:iin.

Itse asiassa, kuten lukija on jo ymmärtänyt, tässä vaiheessa olemme jo päättäneet käyttöliittymästä - edellisen vaiheen tulos on jo esitetty valitun käyttöliittymän muodossa.

Toiseksi, ja millä työkaluilla teemme tämän?
Täällä on myös laaja valikoima:

• Itse kirjoitettu käsikirjoitus tai alusta. Varustaudutaan ncclientillä ja asyncIO:lla ja tehdään kaikki itse. Mitä meille maksaa käyttöönottojärjestelmän rakentaminen tyhjästä?
• Ansible runsaan verkkomoduulikirjastonsa ansiosta.
• Suola sen niukalla työllä verkon kanssa ja yhteydellä Napalmiin.
• Itse asiassa Napalm, joka tuntee pari myyjää ja siinä kaikki, hyvästi.
• Nornir on toinen eläin, jota tulemme käsittelemään tulevaisuudessa.

Täällä suosikkia ei ole vielä valittu - etsitään.

Mitä muuta tässä on tärkeää? Kokoonpanon soveltamisen seuraukset.
Onnistuuko tai ei. Onko laitteistoon vielä pääsyä vai ei?
Vaikuttaa siltä, ​​että commit auttaa tässä vahvistamaan ja vahvistamaan, mitä laitteelle on ladattu.
Tämä yhdistettynä NETCONF:n oikeaan toteutukseen kaventaa merkittävästi sopivien laitteiden valikoimaa - monet valmistajat eivät tue normaaleja sitoumuksia. Mutta tämä on vain yksi ennakkoedellytyksistä RFP. Loppujen lopuksi kukaan ei ole huolissaan siitä, ettei yksikään venäläinen toimittaja täytä 32*100GE-liitäntäehtoa. Vai onko hän huolissaan?

Komponentti 8. CI/CD

Tässä vaiheessa meillä on jo kokoonpano valmiina kaikille verkkolaitteille.
Kirjoitan "kaikkeen", koska puhumme verkon tilan versioinnista. Ja vaikka sinun pitäisi muuttaa vain yhden kytkimen asetuksia, muutokset lasketaan koko verkolle. Ilmeisesti ne voivat olla nolla useimmille solmuille.

Mutta kuten edellä jo todettiin, emme ole sellaisia ​​barbaareja, jotka haluavat viedä kaiken suoraan tuotantoon.
Luodun kokoonpanon on ensin läpäistävä Pipeline CI/CD.

CI/CD tulee sanoista Continuous Integration, Continuous Deployment. Tämä on lähestymistapa, jossa tiimi julkaisee kuuden kuukauden välein uuden suuren julkaisun, joka korvaa vanhan kokonaan, vaan myös ottaa säännöllisesti käyttöön (Deployment) uusia toimintoja pienissä osissa, joista jokaisen yhteensopivuus, turvallisuus ja turvallisuus on testattu kattavasti. suorituskyky (integrointi).

Tätä varten meillä on versionhallintajärjestelmä, joka valvoo konfiguraatiomuutoksia, laboratorio, joka tarkistaa, onko asiakaspalvelu rikki, valvontajärjestelmä, joka tarkistaa tämän tosiasian ja viimeisenä vaiheena on muutosten käyttöönotto tuotantoverkostoon.

Virheenkorjauskomentoja lukuun ottamatta ehdottomasti kaikkien verkon muutosten on tapahduttava CI/CD-putkilinjan kautta - tämä on takuumme hiljaisesta elämästä ja pitkästä, onnellisesta urasta.

Komponentti 9. Vara- ja poikkeamien havaitsemisjärjestelmä

No, varmuuskopioista ei tarvitse enää puhua.
Laitamme ne yksinkertaisesti gitiin kruunun mukaan tai konfiguraatiomuutoksen perusteella.

Mutta toinen osa on mielenkiintoisempi - jonkun pitäisi seurata näitä varmuuskopioita. Ja joissakin tapauksissa tämän henkilön täytyy mennä ja kääntää kaikki niin kuin se oli, ja toisissa tapauksissa miau jollekin, että jokin on vialla.
Jos esimerkiksi on ilmestynyt uusi käyttäjä, joka ei ole rekisteröitynyt muuttujiin, sinun on poistettava hänet hakkeroinnin ulkopuolelle. Ja jos on parempi olla koskematta uuteen palomuurisääntöön, ehkä joku on juuri laittanut virheenkorjauksen päälle, tai ehkä uutta palvelua, bungleria, ei rekisteröity määräysten mukaisesti, mutta ihmiset ovat jo liittyneet siihen.

Emme silti välttele pientä deltaa koko verkon mittakaavassa huolimatta automaatiojärjestelmistä ja hallinnan teräksestä kädestä. Virheenkorjausongelmien ratkaisemiseksi kukaan ei kuitenkaan lisää järjestelmien määrityksiä. Lisäksi niitä ei välttämättä edes sisälly kokoonpanomalliin.

Esimerkiksi palomuurisääntö, joka laskee pakettien määrän tiettyä IP-osoitetta kohden ongelman paikallistamiseksi, on täysin tavallinen väliaikainen kokoonpano.

Komponentti 10. Valvontajärjestelmä

Aluksi en aikonut käsitellä seuranta-aihetta - se on edelleen laaja, kiistanalainen ja monimutkainen aihe. Mutta asioiden edetessä kävi ilmi, että tämä oli olennainen osa automaatiota. Ja sitä on mahdotonta ohittaa, jopa ilman harjoittelua.

Evolving Thought on orgaaninen osa CI/CD-prosessia. Kun asetukset on otettu käyttöön verkkoon, meidän on voitava määrittää, onko kaikki nyt kunnossa.
Ja emme puhu vain eikä niinkään rajapintojen käyttöaikatauluista tai solmujen saatavuudesta, vaan hienovaraisemmista asioista - tarvittavien reittien läsnäolosta, niiden attribuuteista, BGP-istuntojen määrästä, OSPF-naapureista, päästä päähän -suorituskyvystä. päällekkäisistä palveluista.
Lakkasiko ulkoisen palvelimen syslogien lisääntyminen vai hajosiko SFlow-agentti, vai alkoivatko jonojen putoamiset kasvaa, vai katkesiko yhteys jonkin etuliiteparin välillä?

Pohdimme tätä erillisessä artikkelissa.

Johtopäätös

Pohjaksi valitsin yhden nykyaikaisista konesalin verkkomalleista - L3 Clos Fabricin, jossa on BGP reititysprotokollaksi.
Tällä kertaa rakennamme verkon Juniperille, koska nyt JunOs-rajapinta on vanlove.

Tehdään elämästämme vaikeampaa käyttämällä vain avoimen lähdekoodin työkaluja ja usean toimittajan verkostoa - joten valitsen matkan varrelta Juniperin lisäksi yhden onnekkaan.

Suunnitelma tulevista julkaisuista on suunnilleen tällainen:
Ensin puhun virtuaalisista verkoista. Ensinnäkin siksi, että haluan, ja toiseksi, koska ilman tätä infrastruktuuriverkon suunnittelu ei ole kovin selkeää.
Sitten itse verkon suunnittelusta: topologia, reititys, käytännöt.
Kootaan laboratorioteline.
Mietitään sitä ja ehkä harjoitellaan laitteen alustamista verkossa.
Ja sitten jokaisesta komponentista intiimeissä yksityiskohdissa.

Ja kyllä, en lupaa lopettaa tätä sykliä sulavasti valmiilla ratkaisulla. 🙂

Hyödyllisiä linkkejä

• Ennen sarjaan syventymistä kannattaa lukea Natasha Samoilenkon kirja Python verkkosuunnittelijoille. Ja ehkä läpi kurssi.
• Siitä on myös hyötyä lukea RFC Peter Lapukhovin palvelinkeskustehtaiden suunnittelusta Facebookista.
• Arkkitehtuuridokumentaatio antaa sinulle käsityksen siitä, miten Overlay SDN toimii. Volframi kangas (aiemmin Open Contrail).

Kiitos

Rooman rotko. Kommentteja ja muokkauksia varten.
Artjom Tšernobay. KDPV:lle.

Lähde: will.com