SDSM er lokið en óviðráðanleg löngun til að skrifa er eftir.

Í mörg ár þjáðist bróðir okkar af venjubundinni vinnu, krosslagði fingur áður en hann skuldbindur sig og skorti svefn vegna nætursvefna.
En myrku tímarnir eru að líða undir lok.

Með þessari grein mun ég hefja röð um hvernig mig sjálfvirkni sést.
Í leiðinni munum við skilja stig sjálfvirkni, geyma breytur, formgera hönnun, RestAPI, NETCONF, YANG, YDK og við munum gera mikið af forritun.
Til mín þýðir að a) það er ekki hlutlægur sannleikur, b) það er ekki skilyrðislaust besta nálgunin, c) skoðun mín, jafnvel meðan á hreyfingu frá fyrstu til síðustu greinar stendur, getur breyst - satt best að segja, frá drögum til útgáfu, ég endurskrifaði allt alveg tvisvar.

efni

1. Markmið
   1. Netið er eins og ein lífvera
   2. Stillingarprófun
   3. Útgáfa
   4. Eftirlit og sjálfsmeðferð þjónustu

2. Þýðir
   1. Birgðakerfi
   2. IP rýmisstjórnunarkerfi
   3. Lýsingarkerfi fyrir netþjónustu
   4. Uppsetningarkerfi tækis
   5. Seljandi-agnostic stillingarlíkan
   6. Seldarsérstakt ökumannsviðmót
   7. Vélbúnaður til að skila stillingum í tækið
   8. CI / CD
   9. Vélbúnaður fyrir öryggisafrit og leit að frávikum
   10. Eftirlitskerfi

3. Ályktun

Ég mun reyna að framkvæma ADSM á sniði sem er aðeins öðruvísi en SDSM. Stórar, ítarlegar, tölusettar greinar munu halda áfram að birtast og á milli þeirra mun ég birta litlar glósur úr hversdagslegri reynslu. Ég mun reyna að berjast gegn fullkomnunaráráttu hér og ekki sleikja hvern og einn.

Hversu fyndið er það að í annað skiptið þarf maður að fara sömu leið.

Í fyrstu þurfti ég sjálfur að skrifa greinar um net vegna þess að þau voru ekki á RuNetinu.

Nú gat ég ekki fundið yfirgripsmikið skjal sem myndi kerfisbinda nálganir við sjálfvirkni og greina ofangreinda tækni með einföldum hagnýtum dæmum.

Ég gæti haft rangt fyrir mér, svo vinsamlegast gefðu upp tengla á gagnlegar heimildir. Þetta mun þó ekki breyta ákvörðun minni um að skrifa, því aðalmarkmiðið er að læra eitthvað sjálfur og að gera öðrum lífið léttara er skemmtilegur bónus sem strjúkir við genið til að deila reynslu.

Við munum reyna að taka meðalstórt LAN DC gagnaver og vinna allt sjálfvirknikerfið.
Ég mun gera suma hluti næstum í fyrsta skipti með þér.

Ég mun ekki vera frumlegur í þeim hugmyndum og verkfærum sem lýst er hér. Dmitry Figol hefur framúrskarandi rás með straumum um þetta efni.
Greinarnar munu skarast við þær á mörgum sviðum.

LAN DC er með 4 DC, um 250 rofa, hálfan tug beina og nokkra eldveggi.
Ekki Facebook, en nóg til að fá þig til að hugsa djúpt um sjálfvirkni.
Það er hins vegar skoðun að ef þú ert með fleiri en 1 tæki sé sjálfvirkni þegar þörf.
Reyndar er erfitt að ímynda sér að einhver geti nú lifað án að minnsta kosti pakka af hnéhandritum.
Þó að ég hafi heyrt að það eru skrifstofur þar sem IP tölur eru geymdar í Excel og hvert af þúsundum nettækja er stillt handvirkt og hefur sína einstöku uppsetningu. Þetta er auðvitað hægt að afgreiða sem nútímalist, en tilfinningar verkfræðingsins munu örugglega móðgast.

Markmið

Nú munum við setja abstrakt markmiðin:

• Netið er eins og ein lífvera
• Stillingarprófun
• Útgáfa netkerfis
• Eftirlit og sjálfsmeðferð þjónustu

Síðar í þessari grein munum við skoða hvaða leiðir við munum nota og hér á eftir munum við skoða markmiðin og leiðirnar í smáatriðum.

Netið er eins og ein lífvera

Skilgreiningarsetning seríunnar, þó við fyrstu sýn virðist hún kannski ekki svo mikilvæg: við munum stilla netið, ekki einstök tæki.
Á undanförnum árum höfum við séð áherslubreytingu í átt að því að meðhöndla netið sem eina heild, þess vegna Skilgreindur nethugbúnaður, Ásetningsdrifin net и Sjálfstæð net.
Eftir allt saman, hvað þurfa forrit á heimsvísu frá netinu: tengingu milli punkta A og B (ja, stundum +B-Z) og einangrun frá öðrum forritum og notendum.

Og svo er verkefni okkar í þessari röð byggja upp kerfi, viðhalda núverandi uppsetningu allt netið, sem er þegar brotið niður í raunverulega uppsetningu á hverju tæki í samræmi við hlutverk þess og staðsetningu.
System netstjórnun felur í sér að til að gera breytingar höfum við samband við það og það reiknar síðan út æskilegt ástand fyrir hvert tæki og stillir það.
Þannig lágmarkum við handvirkan aðgang að CLI í næstum núll - allar breytingar á tækjastillingum eða nethönnun verða að vera formlegar og skjalfestar - og aðeins þá rúllað út í nauðsynlega netþætti.

Það er, til dæmis, ef við ákváðum að héðan í frá rekki rofar í Kazan ættu að tilkynna tvö net í stað eins, við

1. Fyrst skjalfestum við breytingar á kerfum
2. Búa til markstillingar allra nettækja
3. Við ræsum uppfærsluforritið fyrir netstillingar, sem reiknar út hvað þarf að fjarlægja á hverjum hnút, hverju á að bæta við og færir hnútana í æskilegt ástand.

Á sama tíma gerum við breytingar handvirkt aðeins í fyrsta skrefi.

Stillingarprófun

Þekktað 80% vandamála eiga sér stað við stillingarbreytingar - óbein sönnun þess er að yfir áramótafríið er yfirleitt allt rólegt.
Ég hef persónulega orðið vitni að tugum alþjóðlegra stöðvunartíma vegna mannlegra mistaka: röng skipun, uppsetningin var framkvæmd í röngum útibúi, samfélagið gleymdi, MPLS var rifið á heimsvísu á beininum, fimm vélbúnaðarhlutar voru stilltir, en villa var ekki sá sjötta að gamlar breytingar sem annar maður gerði voru framdar. Það eru fullt af atburðarásum.

Sjálfvirkni gerir okkur kleift að gera færri mistök, en á stærri skala. Þannig geturðu múrað ekki bara eitt tæki heldur allt netið í einu.

Frá örófi alda athugaðu afar okkar réttmæti breytinganna sem gerðar voru með næmum augum, stálkúlur og virkni netsins eftir að þeim var rúllað út.
Þeir afar sem leiddu til stöðvunar í vinnunni og hörmulegu tapi skildu eftir sig færri afkvæmi og ættu að deyja út með tímanum, en þróunin er hægt ferli og þess vegna eru ekki allir enn að prófa breytingar á rannsóknarstofunni fyrst.
Hins vegar eru í fararbroddi framfara þeir sem hafa sjálfvirkt ferlið við að prófa uppsetninguna og frekari beitingu hennar á netið. Með öðrum orðum, ég fékk lánaða CI/CD málsmeðferðina (Stöðug samþætting, stöðug uppsetning) frá þróunaraðilum.
Í einum hlutanum munum við skoða hvernig á að útfæra þetta með útgáfustýringarkerfi, líklega Github.

Þegar þú hefur vanist hugmyndinni um net CI/CD, mun aðferðin við að athuga stillingar með því að nota hana á framleiðslukerfi á einni nóttu virðast eins og fáfræði snemma á miðöldum. Svolítið eins og að slá hamar í sprengjuhaus.

Lífrænt framhald af hugmyndum um kerfi netstjórnun og CI/CD verður að fullri útgáfu af uppsetningunni.

Útgáfa

Við gerum ráð fyrir að með öllum breytingum, jafnvel minniháttar, jafnvel á einu ómerkjanlegu tæki, færist allt netið frá einu ástandi í annað.
Og við framkvæmum alltaf ekki skipun á tækinu, við breytum stöðu netsins.
Svo skulum við kalla þessi ríki útgáfur?

Segjum að núverandi útgáfa sé 1.0.0.
Hefur IP-tala Loopback viðmótsins á einum af ToRs breyst? Þetta er minni útgáfa og verður númeruð 1.0.1.
Við endurskoðuðum reglurnar um innflutning á leiðum í BGP - aðeins alvarlegri - þegar 1.1.0
Við ákváðum að losa okkur við IGP og skipta aðeins yfir í BGP - þetta er nú þegar róttæk hönnunarbreyting - 2.0.0.

Á sama tíma geta mismunandi DCs verið með mismunandi útgáfur - netið er að þróast, nýr búnaður er settur upp, ný stigi hryggja er bætt við einhvers staðar, ekki í öðrum o.s.frv.

á merkingarfræðileg útgáfa við munum tala í sérstakri grein.

Ég endurtek - allar breytingar (nema fyrir villuleitarskipanir) eru útgáfuuppfærsla. Tilkynna skal stjórnendum um frávik frá núverandi útgáfu.

Sama á við um að afturkalla breytingar - þetta er ekki að hætta við síðustu skipanir, þetta er ekki afturköllun með því að nota stýrikerfi tækisins - þetta er að færa allt netkerfið í nýja (gamla) útgáfu.

Eftirlit og sjálfsmeðferð þjónustu

Þetta sjálfsagða verkefni hefur náð nýju stigi í nútíma netkerfum.
Oft taka stórir þjónustuaðilar þá aðferð að laga þurfi bilaða þjónustu mjög fljótt og hækka nýja í stað þess að finna út hvað gerðist.
„Mjög“ þýðir að þú þarft að vera rausnarlega húðaður á allar hliðar með eftirliti, sem innan nokkurra sekúndna mun greina minnstu frávik frá norminu.
Og hér duga venjulegar mælikvarðar, svo sem hleðsla viðmóts eða framboð á hnútum, ekki lengur. Handvirkt eftirlit með þeim hjá vaktstjóra dugar ekki heldur.
Fyrir margt ætti að vera til Sjálfsheilun — eftirlitsljósin urðu rautt og við fórum og settum á hnettinn sjálfir þar sem það var sárt.

Og hér fylgjumst við líka ekki aðeins með einstökum tækjum, heldur einnig heilsu alls netkerfisins, bæði whitebox, sem er tiltölulega skiljanlegt, og blackbox, sem er flóknara.

Hvað þurfum við til að hrinda svona metnaðarfullum áætlunum í framkvæmd?

• Hafa lista yfir öll tæki á netinu, staðsetningu þeirra, hlutverk, gerðir, hugbúnaðarútgáfur.
  kazan-leaf-1.lmu.net, Kazan, lauf, Juniper QFX 5120, R18.3.
• Hafa kerfi til að lýsa sérþjónustu.
  IGP, BGP, L2/3VPN, Stefna, ACL, NTP, SSH.
• Geta frumstillt tækið.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-keys, LLDP, NETCONF
• Stilltu tækið og færðu stillinguna í þá útgáfu sem þú vilt (þar á meðal gamla).
• Próf stillingar
• Athugaðu reglulega stöðu allra tækja fyrir frávik frá núverandi og tilkynntu hverjum það ætti að vera.
  Á einni nóttu bætti einhver hljóðlega reglu við ACL.
• Fylgstu með frammistöðu.

Þýðir

Það hljómar nógu flókið til að byrja að sundra verkefninu í íhluti.

Og þeir verða tíu:

1. Birgðakerfi
2. IP rýmisstjórnunarkerfi
3. Lýsingarkerfi fyrir netþjónustu
4. Uppsetningarkerfi tækis
5. Seljandi-agnostic stillingarlíkan
6. Seldarsérstakt ökumannsviðmót
7. Vélbúnaður til að skila stillingum í tækið
8. CI / CD
9. Vélbúnaður fyrir öryggisafrit og leit að frávikum
10. Eftirlitskerfi

Þetta er að vísu dæmi um hvernig viðhorfið til markmiða hringrásarinnar breyttist - það voru 4 þættir í drögunum.

Á myndinni sýndi ég alla íhlutina og tækið sjálft.
Íhlutir sem skerast hafa samskipti sín á milli.
Því stærri sem blokkin er, því meiri athygli þarf að gefa þessum þætti.

Hluti 1: Birgðakerfi

Vitanlega viljum við vita hvaða búnaður er staðsettur hvar, hvað er tengdur.
Birgðakerfið er óaðskiljanlegur hluti hvers fyrirtækis.
Oftast hefur fyrirtæki sérstakt birgðakerfi fyrir nettæki, sem leysir sértækari vandamál.
Sem hluti af þessari greinaröð munum við kalla það DCIM - Data Center Infrastructure Management. Þótt hugtakið DCIM sjálft, strangt til tekið, innihaldi miklu meira.

Í okkar tilgangi munum við geyma eftirfarandi upplýsingar um tækið í því:

• Birgðanúmer
• Titill/lýsing
• Fyrirmynd (Huawei CE12800, Juniper QFX5120 osfrv.)
• Einkennandi færibreytur (töflur, viðmót o.fl.)
• Hlutverk (Leaf, hrygg, Border Router, osfrv.)
• Staðsetning (svæði, borg, gagnaver, rekki, eining)
• Samtengingar milli tækja
• Staðfræði netkerfis

Það er alveg ljóst að við viljum sjálf vita allt þetta.
En mun þetta hjálpa í sjálfvirkni tilgangi?
Vissulega.
Til dæmis vitum við að í tilteknu gagnaveri á Leaf rofum, ef það er Huawei, ætti ACL að sía ákveðna umferð að beita á VLAN, og ef það er Juniper, þá á einingu 0 á líkamlega viðmótinu.
Eða þú þarft að setja út nýjan Syslog netþjón til allra landamæra á svæðinu.

Í því munum við geyma sýndarnetstæki, til dæmis sýndarbeina eða rótarendurkastara. Við getum bætt við DNS netþjónum, NTP, Syslog og almennt öllu sem á einn eða annan hátt tengist netinu.

Hluti 2: IP rýmisstjórnunarkerfi

Já, og nú á dögum eru hópar fólks sem halda utan um forskeyti og IP tölur í Excel skrá. En nútíma nálgunin er enn gagnagrunnur, með framhlið á nginx/apache, API og víðtækum aðgerðum til að taka upp IP tölur og netkerfi skipt í VRF.
IPAM - Stjórnun IP-tölu.

Í okkar tilgangi munum við geyma eftirfarandi upplýsingar í því:

• VLAN
• VRF
• Net/undirnet
• IP tölur
• Bindir heimilisföng við tæki, net við staðsetningar og VLAN númer

Aftur, það er ljóst að við viljum ganga úr skugga um að þegar við úthlutum nýrri IP tölu fyrir ToR loopback, munum við ekki hrasa yfir þeirri staðreynd að það var þegar úthlutað einhverjum. Eða að við notuðum sama forskeytið tvisvar á mismunandi endum netsins.
En hvernig hjálpar þetta við sjálfvirkni?
Það er auðvelt.
Við óskum eftir forskeyti í kerfinu með Loopbacks hlutverkinu, sem inniheldur IP tölur sem eru tiltækar til úthlutunar - ef það finnst, úthlutum við heimilisfanginu, ef ekki, óskum við eftir að búið verði til nýtt forskeyti.
Eða þegar við búum til tækjastillingu getum við fundið út frá sama kerfi í hvaða VRF viðmótið ætti að vera staðsett.
Og þegar nýr netþjónn er ræstur, skráir handritið sig inn í kerfið, kemst að því í hvaða rofi þjónninn er, hvaða tengi og hvaða undirnet er úthlutað við viðmótinu - og mun úthluta netfanginu frá því.

Þetta bendir til þess að vilja sameina DCIM og IPAM í eitt kerfi til að afrita ekki aðgerðir og þjóna ekki tveimur svipuðum aðilum.
Það er það sem við munum gera.

Hluti 3. Kerfi til að lýsa sérþjónustu

Ef fyrstu tvö kerfin geyma breytur sem enn þarf að nota einhvern veginn, þá lýsir það þriðja fyrir hvert tækishlutverk hvernig það ætti að vera stillt.
Það er þess virði að greina á milli tveggja mismunandi tegunda netþjónustu:

• Innviðir
• Viðskiptavinur.

Fyrrverandi eru hönnuð til að veita grunntengingar og tækjastýringu. Þar á meðal eru VTY, SNMP, NTP, Syslog, AAA, leiðarsamskiptareglur, CoPP osfrv.
Hið síðarnefnda skipuleggur þjónustuna fyrir viðskiptavininn: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, osfrv.
Auðvitað eru líka til landamæratilvik - hvar á að fela MPLS LDP, BGP? Já, og hægt er að nota leiðarsamskiptareglur fyrir viðskiptavini. En þetta er ekki mikilvægt.

Báðar tegundir þjónustu eru sundurliðaðar í frumstillingar:

• líkamlegt og rökrétt viðmót (tag/anteg, mtu)
• IP tölur og VRF (IP, IPv6, VRF)
• ACL og umferðarvinnslustefnur
• Samskiptareglur (IGP, BGP, MPLS)
• Leiðarstefnur (forskeytislistar, samfélög, ASN síur).
• Gagnaþjónusta (SSH, NTP, LLDP, Syslog...)
• O.s.frv.

Hvernig nákvæmlega við munum gera þetta hef ég ekki hugmynd um ennþá. Við munum skoða það í sérstakri grein.

Ef það er aðeins nær lífinu, þá gætum við lýst því
Leaf rofinn verður að hafa BGP lotur með öllum tengdum Spine rofum, flytja inn tengd netkerfi inn í ferlið og samþykkja aðeins net frá ákveðnu forskeyti frá Spine rofum. Takmarkaðu CoPP IPv6 ND við 10 pps osfrv.
Aftur á móti halda hryggir fundir með öllum tengdum leiðum, virka sem rótarendurskinsmerki, og samþykkja frá þeim aðeins leiðir af ákveðinni lengd og með ákveðnu samfélagi.

Hluti 4: Frumstillingarkerfi tækis

Undir þessum fyrirsögn sameina ég margar af þeim aðgerðum sem verða að eiga sér stað til þess að tæki birtist á ratsjá og sé hægt að nálgast það með fjartengingu.

1. Sláðu tækið inn í birgðakerfið.
2. Veldu IP-tölu stjórnenda.
3. Settu upp grunnaðgang að því:
   Hýsilnafn, IP-tala stjórnenda, leið að stjórnunarnetinu, notendur, SSH lyklar, samskiptareglur - telnet/SSH/NETCONF

Það eru þrjár aðferðir:

• Allt er algjörlega handvirkt. Tækið er komið í standinn þar sem venjulegur lífrænn einstaklingur fer inn í kerfin, tengir við stjórnborðið og stillir það. Getur unnið á litlum kyrrstæðum netum.
• ZTP - Zero Touch úthlutun. Vélbúnaðurinn kom, stóð upp, fékk heimilisfang í gegnum DHCP, fór á sérstakan netþjón og stillti sjálfan sig.
• Innviðir stjórnborðsþjóna, þar sem upphafleg stilling fer fram í gegnum stjórnborðshöfnina í sjálfvirkri stillingu.

Við munum tala um öll þrjú í sérstakri grein.

Hluti 5: Seljandi-agnostic stillingarlíkan

Hingað til hafa öll kerfi verið ólíkir plástrar sem veita breytur og lýsandi lýsingu á því sem við viljum sjá á netinu. En fyrr eða síðar verður þú að takast á við einstök atriði.
Á þessu stigi, fyrir hvert tiltekið tæki, eru frumstæður, þjónustur og breytur sameinaðar í uppsetningarlíkan sem lýsir í raun heildaruppsetningu tiltekins tækis, aðeins á hlutlausan hátt frá seljanda.
Hvað gerir þetta skref? Af hverju ekki strax að búa til tækjastillingu sem þú getur einfaldlega hlaðið upp?
Í raun leysir þetta þrjú vandamál:

1. Ekki laga sig að ákveðnu viðmóti til að hafa samskipti við tækið. Hvort sem það er CLI, NETCONF, RESTCONF, SNMP - líkanið verður það sama.
2. Ekki halda fjölda sniðmáta/forskrifta í samræmi við fjölda framleiðenda á netinu og ef hönnunin breytist skaltu breyta því sama á nokkrum stöðum.
3. Hladdu stillingunum úr tækinu (afrit), settu það í nákvæmlega sama líkan og berðu markstillinguna beint saman við þá sem fyrir er til að reikna delta og útbúa stillingarplástur sem mun breyta aðeins þeim hlutum sem eru nauðsynlegir eða til að bera kennsl á frávik.

Sem afleiðing af þessu stigi fáum við uppsetningu sem er óháð seljanda.

Hluti 6. Seljenda-sérstakur bílstjóri tengi

Þú ættir ekki að stæla þig með von um að einn daginn verði hægt að stilla ciska á nákvæmlega sama hátt og Juniper, einfaldlega með því að senda nákvæmlega sömu símtölin til þeirra. Þrátt fyrir vaxandi vinsældir hvítra kassa og tilkomu stuðnings við NETCONF, RESTCONF, OpenConfig, er sértækt efni sem þessar samskiptareglur skila mismunandi eftir söluaðilum og þetta er einn af samkeppnismunum þeirra að þeir munu ekki gefast upp svo auðveldlega.
Þetta er nokkurn veginn það sama og OpenContrail og OpenStack, sem hafa RestAPI sem NorthBound viðmót, búast við allt öðrum símtölum.

Svo, í fimmta skrefinu, verður seljanda-óháða líkanið að vera í því formi sem það mun fara í vélbúnað.
Og hér eru allar leiðir góðar (ekki): CLI, NETCONF, RESTCONF, SNMP einfaldlega.

Þess vegna þurfum við bílstjóri sem mun flytja niðurstöðuna úr fyrra skrefi yfir í áskilið snið tiltekins söluaðila: safn af CLI skipunum, XML uppbyggingu.

Hluti 7. Vélbúnaður til að skila stillingum í tækið

Við höfum búið til stillingarnar, en samt þarf að afhenda hana í tækin - og augljóslega ekki í höndunum.
Í fyrsta lagi, við stöndum frammi fyrir þeirri spurningu hvaða flutninga við munum nota? Og í dag er valið ekki lengur lítið:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (þó það sé útúrsnúningur vegna þess að það er leið til að skila FIB, ekki stillingum)

Við skulum punkta t-ið hér. CLI er arfleifð. SNMP... hósti hósti.
RESTCONF er enn óþekkt dýr; REST API er stutt af nánast engum. Þess vegna munum við einbeita okkur að NETCONF í seríunni.

Reyndar, eins og lesandinn hefur þegar skilið, á þessum tímapunkti höfum við þegar ákveðið viðmótið - niðurstaðan úr fyrra skrefi er þegar kynnt í sniði viðmótsins sem var valið.

Í öðru lagi, og hvaða verkfæri munum við gera þetta með?
Það er líka mikið úrval hér:

• Sjálfskrifað handrit eða vettvangur. Vopnum okkur með ncclient og asyncIO og gerum allt sjálf. Hvað kostar okkur að byggja upp dreifingarkerfi frá grunni?
• Ansible með ríkulegu safni af neteiningum.
• Salt með litlu starfi sínu við netið og tengingu við Napalm.
• Reyndar Napalm, sem þekkir nokkra söluaðila og það er það, bless.
• Nornir er annað dýr sem við munum kryfja í framtíðinni.

Hér hefur uppáhaldið ekki enn verið valið - við munum leita.

Hvað er annars mikilvægt hér? Afleiðingar þess að beita stillingunni.
Vel heppnað eða ekki. Er ennþá aðgangur að vélbúnaðinum eða ekki?
Svo virðist sem commit muni hjálpa hér við staðfestingu og staðfestingu á því sem var hlaðið niður í tækið.
Þetta, ásamt réttri útfærslu NETCONF, þrengir verulega úrval viðeigandi tækja - ekki margir framleiðendur styðja venjulega skuldbindingar. En þetta er bara ein af forsendunum í Rfp. Að lokum hefur enginn áhyggjur af því að ekki einn rússneskur söluaðili uppfylli 32*100GE viðmótsskilyrðið. Eða hefur hann áhyggjur?

Hluti 8. CI/CD

Á þessum tímapunkti höfum við nú þegar uppsetninguna tilbúna fyrir öll nettæki.
Ég skrifa „fyrir allt“ vegna þess að við erum að tala um útgáfu netkerfisins. Og jafnvel þótt þú þurfir að breyta stillingum á einum rofa eru breytingar reiknaðar fyrir allt netið. Augljóslega geta þeir verið núll fyrir flesta hnúta.

En, eins og áður var sagt hér að ofan, erum við ekki einhvers konar villimenn sem viljum rúlla öllu beint í framleiðslu.
Mynda stillingin verður fyrst að fara í gegnum Pipeline CI/CD.

CI/CD stendur fyrir Continuous Integration, Continuous Deployment. Þetta er nálgun þar sem teymið setur ekki aðeins út nýja stóra útgáfu á sex mánaða fresti, sem kemur algjörlega í stað þeirrar gömlu, heldur innleiðir reglulega (dreifing) nýja virkni í smáum skömmtum, sem hver um sig er ítarlega prófuð með tilliti til eindrægni, öryggi og árangur (Integration).

Til að gera þetta erum við með útgáfustýringarkerfi sem fylgist með breytingum á stillingum, rannsóknarstofu sem athugar hvort þjónusta viðskiptavinarins sé biluð, eftirlitskerfi sem athugar þessa staðreynd og síðasta skrefið er að útfæra breytingar á framleiðslunetinu.

Að undanskildum villuleitarskipunum verða algerlega allar breytingar á netinu að fara í gegnum CI/CD leiðsluna - þetta er trygging okkar fyrir rólegu lífi og langan, farsælan feril.

Hluti 9. Öryggis- og fráviksgreiningarkerfi

Jæja, það er engin þörf á að tala um öryggisafrit aftur.
Við munum einfaldlega setja þau í git í samræmi við kórónu eða þegar stillingarbreytingar hafa verið gerðar.

En seinni hlutinn er áhugaverðari - einhver ætti að fylgjast með þessum öryggisafritum. Og í sumum tilfellum verður þessi einhver að fara og snúa öllu við eins og það var, og í öðrum, mjáðu við einhvern að eitthvað sé að.
Til dæmis, ef nýr notandi hefur birst sem ekki er skráður í breyturnar, þarftu að fjarlægja hann í burtu frá hakkinu. Og ef það er betra að snerta ekki nýja eldveggsreglu, kannski kveikti einhver bara á villuleit, eða kannski var nýja þjónustan, bungler, ekki skráð samkvæmt reglunum, en fólk hefur þegar gengið í hana.

Við munum samt ekki sleppa við einhverja litla delta á mælikvarða alls netkerfisins, þrátt fyrir öll sjálfvirknikerfi og stálhönd stjórnenda. Til að kemba vandamál mun enginn bæta stillingum við kerfin hvort sem er. Þar að auki geta þeir ekki einu sinni verið með í stillingarlíkaninu.

Til dæmis, eldveggsregla til að telja fjölda pakka á tiltekna IP til að staðsetja vandamál er algjörlega venjuleg tímabundin uppsetning.

Hluti 10. Vöktunarkerfi

Í fyrstu ætlaði ég ekki að fjalla um eftirlitsefnið - það er enn umfangsmikið, umdeilt og flókið efni. En þegar á leið kom í ljós að þetta var órjúfanlegur hluti af sjálfvirkni. Og það er ómögulegt að komast framhjá því, jafnvel án æfinga.

Þróandi hugsun er lífrænn hluti af CI/CD ferlinu. Eftir að stillingarnar hafa verið settar út á netið þurfum við að geta ákvarðað hvort allt sé í lagi með það núna.
Og við erum að tala ekki aðeins og ekki svo mikið um viðmótsnotkunaráætlanir eða hnútaframboð, heldur um lúmskari hluti - tilvist nauðsynlegra leiða, eiginleika á þeim, fjölda BGP funda, OSPF nágranna, end-to-end árangur af yfirliggjandi þjónustu.
Hættu syslogs við ytri netþjóninn að bætast við, eða bilaði SFlow umboðsmaðurinn, eða fóru droparnir í biðröðunum að stækka, eða rofnaði tengingin á milli einhverra forskeytapars?

Við munum íhuga þetta í sérstakri grein.

Ályktun

Sem grundvöll valdi ég eina af nútíma nethönnun gagnavera - L3 Clos Fabric með BGP sem leiðarsamskiptareglur.
Að þessu sinni munum við byggja upp netið á Juniper, því núna er JunOs viðmótið vanlove.

Gerum líf okkar erfiðara með því að nota aðeins Open Source verkfæri og netkerfi fyrir marga söluaðila - þannig að til viðbótar við Juniper, mun ég velja einn heppinn mann í leiðinni.

Áætlunin fyrir komandi útgáfur er eitthvað á þessa leið:
Fyrst mun ég tala um sýndarnet. Í fyrsta lagi vegna þess að ég vil það og í öðru lagi vegna þess að án þessa verður hönnun innviðakerfisins ekki mjög skýr.
Síðan um nethönnunina sjálfa: staðfræði, leið, stefnur.
Setjum saman rannsóknarstofustand.
Hugsum málið og æfum okkur kannski í að frumstilla tækið á netinu.
Og svo um hvern þátt í nánum smáatriðum.

Og já, ég lofa ekki að enda þessa lotu af þokkabót með tilbúinni lausn. 🙂

gagnlegir krækjur

• Áður en kafað er í seríuna er vert að lesa bók Natasha Samoilenko Python fyrir netverkfræðinga. Og kannski standast námskeiðið.
• Það verður líka gagnlegt að lesa RFC um hönnun gagnaveraverksmiðja frá Facebook eftir Peter Lapukhov.
• Arkitektúrskjölin gefa þér hugmynd um hvernig Overlay SDN virkar. Wolfram efni (áður Open Contrail).

Þakka þér fyrir

Rómverska gljúfrið. Fyrir athugasemdir og breytingar.
Artyom Chernobay. Fyrir KDPV.

Heimild: www.habr.com