Í fyrstu tveimur greinunum vakti ég spurningu um sjálfvirkni og skissaði um ramma hennar, í þeirri seinni dró ég mig inn í netvæðingu, sem fyrsta aðferð til að gera sjálfvirkan uppsetningu þjónustu.
Nú er kominn tími til að teikna skýringarmynd af líkamlegu neti.

Ef þú ert ekki kunnugur því að setja upp netkerfi gagnavera, þá mæli ég eindregið með því að byrja með greinar um þá.

Öll mál:

• 0. ADSM. Núll hluti. Skipulag
• 1. ADSM. Fyrsti hluti (sem er á eftir núlli). Virtualization netkerfis
• 2. ADSM. Partur tvö. Nethönnun

Aðferðirnar sem lýst er í þessari röð ættu að eiga við um hvaða netkerfi sem er, hvaða stærð sem er, með hvaða söluaðilum sem er (ekki). Hins vegar er ómögulegt að lýsa alhliða dæmi um beitingu þessara aðferða. Þess vegna mun ég einbeita mér að nútíma arkitektúr DC netsins: Kloz verksmiðjan.
Við munum gera DCI á MPLS L3VPN.

Yfirborðsnet keyrir ofan á líkamlega netið frá gestgjafanum (þetta gæti verið OpenStack's VXLAN eða Tungsten Fabric eða eitthvað annað sem krefst aðeins grunn IP tengingar frá netinu).

Í þessu tilviki fáum við tiltölulega einfalda atburðarás fyrir sjálfvirkni, vegna þess að við höfum mikið af búnaði sem er stilltur á sama hátt.

Við munum velja kúlulaga DC í lofttæmi:

• Ein hönnunarútgáfa alls staðar.
• Tveir seljendur mynda tvær netvélar.
• Einn DC er eins og annar eins og tvær baunir í belg.

efni

• Líkamleg staðfræði
• Leiðsögn
• IP áætlun
• Laba
• Ályktun
• gagnlegir krækjur

Láttu þjónustuveituna okkar LAN_DC, til dæmis, hýsa þjálfunarmyndbönd um að lifa af í fastum lyftum.

Í megaborgum er þetta gríðarlega vinsælt, svo þú þarft mikið af líkamlegum vélum.

Í fyrsta lagi mun ég lýsa netkerfinu eins og ég vil að það sé. Og þá mun ég einfalda það fyrir rannsóknarstofuna.

Líkamleg staðfræði

Staðsetningar

LAN_DC mun hafa 6 DC:

• Rússland (RU):
  • Moskvu (msk)
  • Kazan (kzn)

• Spánn (SP):
  • Barcelona (BCN)
  • Malaga (MLG)

• Kína (CN):
  • Shanghai (SHA)
  • Xi'an (SIA)

Inside DC (Intra-DC)

Öll DC eru með eins innri tengslanet byggð á Clos staðfræði.
Hvers konar Clos net eru það og hvers vegna eru þau aðskilin grein.

Hver DC hefur 10 rekka með vélum, þeir verða númeraðir sem A, B, C Og svo framvegis.

Hver rekki hefur 30 vélar. Þeir munu ekki vekja áhuga okkar.

Einnig er í hverri rekki rofi sem allar vélar eru tengdar við - þetta er Efst á rekki rofi - ToR eða á annan hátt, hvað varðar Clos verksmiðjuna, munum við kalla það Leaf.

Almenn skýringarmynd af verksmiðjunni.

Við munum hringja í þá XXX-blaðaYhvar XXX - þriggja stafa skammstöfun DC, og Y - Raðnúmer. Til dæmis, kzn-blað11.

Í greinum mínum mun ég leyfa mér að nota hugtökin Leaf og ToR frekar léttvæg sem samheiti. Hins vegar verðum við að muna að svo er ekki.
ToR er rofi settur upp í rekki sem vélar eru tengdar við.
Leaf er hlutverk tækis í líkamlegu neti eða fyrsta stigs rofi hvað varðar Cloes svæðisfræði.
Það er, Leaf != ToR.
Þannig að Leaf getur verið EndofRaw rofi, til dæmis.
Hins vegar, innan ramma þessarar greinar, munum við samt meðhöndla þau sem samheiti.

Hver ToR rofi er aftur tengdur við fjóra samsöfnunarrofa á hærra stigi - Hryggur. Einn rekki í DC er úthlutað fyrir Spines. Við nefnum það svipað: XXX-hryggY.

Sama rekki mun innihalda netbúnað fyrir tengingu milli DC - 2 beinanna með MPLS innanborðs. En í stórum dráttum eru þetta sömu ToRs. Það er, frá sjónarhóli Spine rofa, þá skiptir venjulega ToR með tengdum vélum eða beini fyrir DCI engu máli - bara áframsending.

Slík sérstök ToRs eru kölluð Kantblað. Við munum hringja í þá XXX-brúnY.

Þetta mun líta svona út.

Í skýringarmyndinni hér að ofan setti ég í raun brún og lauf á sama plani. Klassísk þriggja laga net Þeir kenndu okkur að líta á upptengingu (þar af leiðandi hugtakið) sem upptengingar. Og hér kemur í ljós að DCI „uplink“ fer aftur niður, sem fyrir suma brýtur aðeins venjulega rökfræði. Þegar um er að ræða stór net, þegar gagnaver er skipt í enn smærri einingar - POD's (Point Of Delivery), auðkenndu einstakling Edge-POD's fyrir DCI og aðgang að ytri netum.

Til að auðvelda skynjun í framtíðinni mun ég samt teikna Edge over Spine, á meðan við munum hafa í huga að það er engin greind á Spine og það er enginn munur þegar unnið er með venjulegt Leaf og Edge-leaf (þó að það geti verið blæbrigði hér , en almennt er þetta satt).

Skipulag verksmiðju með brúnblöðum.

Þrenningin Leaf, Spine og Edge mynda undirlagsnet eða verksmiðju.

Verkefni netverksmiðju (lesið undirlag), eins og við höfum þegar skilgreint í síðasta tölublað, mjög, mjög einfalt - að veita IP-tengingu milli véla bæði innan sama DC og á milli þeirra.
Þess vegna er netið kallað verksmiðja, rétt eins og td skiptiverksmiðja inni í einingakerfisboxum sem þú getur lesið meira um í SDSM14.

Almennt er slík staðfræði kölluð verksmiðja, því efni í þýðingu þýðir efni. Og það er erfitt að vera ósammála:

Verksmiðjan er algjörlega L3. Ekkert VLAN, engin útsending - við erum með svo frábæra forritara hjá LAN_DC, þeir vita hvernig á að skrifa forrit sem lifa í L3 hugmyndafræðinni og sýndarvélar þurfa ekki Live Migration með varðveislu IP tölunnar.

Og enn og aftur: svarið við spurningunni hvers vegna verksmiðjan og hvers vegna L3 er í sér grein.

DCI - Data Center Interconnect (Inter-DC)

DCI verður skipulagt með því að nota Edge-Leaf, það er að segja þeir eru útgöngustaður okkar út á þjóðveginn.
Til einföldunar gerum við ráð fyrir að DCs séu tengdir hver öðrum með beinum hlekkjum.
Við skulum útiloka ytri tengingu frá athugun.

Ég er meðvituð um að í hvert skipti sem ég fjarlægi íhlut einfalda ég netið verulega. Og þegar við gerum óhlutbundið netkerfi okkar sjálfvirkt verður allt í lagi, en á hinu raunverulega verða hækjur.
Þetta er satt. Samt sem áður er tilgangurinn með þessari röð að hugsa og vinna að nálgunum, ekki að leysa ímynduð vandamál á hetjulegan hátt.

Á Edge-Leafs er undirlagið komið fyrir í VPN og sent í gegnum MPLS burðarásina (sama beina hlekkurinn).

Þetta er skýringarmyndin á efsta stigi sem við fáum.

Leiðsögn

Fyrir leiðsögn innan DC munum við nota BGP.
Á MPLS skottinu OSPF+LDP.
Fyrir DCI, það er að skipuleggja tengingar í neðanjarðar - BGP L3VPN yfir MPLS.

Almennt leiðarkerfi

Það er engin OSPF eða ISIS (leiðarreglur bönnuð í Rússlandi) í verksmiðjunni.

Þetta þýðir að það verður engin sjálfvirk uppgötvun eða útreikningur á stystu leiðum - aðeins handvirk (reyndar sjálfvirk - við erum að tala um sjálfvirkni hér) uppsetningu samskiptareglur, hverfis og stefnu.

BGP leiðarkerfi innan DC

Af hverju BGP?

Um þetta efni er allt RFC kennd við Facebook og Arista, sem segir til um hvernig eigi að byggja mjög stórt gagnaverakerfi sem nota BGP. Hún les nánast eins og skáldskapur, ég mæli eindregið með henni fyrir slakt kvöld.

Og það er líka heill kafli í greininni minni sem er helgaður þessu. Hvert fer ég með þig og Ég er að senda.

En samt, í stuttu máli, þá hentar enginn IGP fyrir net stórra gagnavera, þar sem fjöldi nettækja hleypur á þúsundum.

Að auki mun notkun BGP alls staðar leyfa þér að eyða tíma í að styðja nokkrar mismunandi samskiptareglur og samstillingu á milli þeirra.

Hönd á hjarta, í verksmiðjunni okkar, sem með miklum líkum mun ekki vaxa hratt, væri OSPF nóg fyrir augun. Þetta eru í raun vandamál megaskala og skýjatítans. En við skulum ímynda okkur aðeins fyrir nokkrar útgáfur að við þurfum það, og við munum nota BGP, eins og Pyotr Lapukhov arfleiddi.

Leiðarstefnur

Á Leaf rofa flytjum við inn forskeyti frá Underlay netviðmótum í BGP.
Við verðum með BGP fund milli kl hver Leaf-Spine par, þar sem þessi Underlay forskeyti verða tilkynnt um netið fram og til baka.

Innan einnar gagnaver munum við dreifa forskriftunum sem við fluttum inn í ToRe. Á Edge-Leafs munum við safna þeim saman og tilkynna þá til fjarlægra DCs og senda þá niður til TORs. Það er, hver ToR mun vita nákvæmlega hvernig á að komast að öðrum ToR í sama DC og hvar inngangsstaðurinn er að komast að ToR í öðru DC.

Í DCI verða leiðir sendar sem VPNv4. Til að gera þetta, á Edge-Leaf, verður viðmótið að verksmiðjunni komið fyrir í VRF, við skulum kalla það UNDERLAY, og hverfið með Spine on Edge-Leaf mun rísa innan VRF, og á milli Edge-Leafs í VPNv4- fjölskyldu.

Við munum einnig banna endurtilkynningu á leiðum sem berast frá hryggnum til baka til þeirra.

Á Leaf and Spine munum við ekki flytja inn Loopbacks. Við þurfum aðeins þá til að ákvarða auðkenni leiðar.

En á Edge-Leafs flytjum við það inn í Global BGP. Á milli Loopback netföng mun Edge-Leafs stofna BGP lotu í IPv4 VPN-fjölskyldunni við hvert annað.

Við munum hafa OSPF+LDP burðarás á milli EDGE tækja. Allt er á einu svæði. Einstaklega einföld uppsetning.

Þetta er myndin með routing.

BGP ASN

Edge-Leaf ASN

Edge-Leafs mun hafa eitt ASN í öllum DCs. Það er mikilvægt að það sé iBGP á milli Edge-Leafs og við festumst ekki í blæbrigðum eBGP. Látum það vera 65535. Í raun gæti þetta verið númer opinbers AS.

Hrygg ASN

Á Spine munum við hafa eitt ASN á DC. Við skulum byrja hér með fyrstu töluna af bilinu einka AS - 64512, 64513 Og svo framvegis.

Af hverju ASN á DC?

Við skulum skipta þessari spurningu niður í tvennt:

• Af hverju eru ASN eins á öllum hryggjum eins DC?
• Af hverju eru þeir mismunandi í mismunandi DCs?

Af hverju eru sömu ASN á öllum hryggjum eins DC?

Svona mun AS-leið undirlagsleiðarinnar á Edge-Leaf líta út:
[leafX_ASN, spine_ASN, edge_ASN]
Þegar þú reynir að auglýsa það aftur til Spine mun það henda því vegna þess að AS (Spine_AS) þess er þegar á listanum.

Hins vegar, innan DC erum við fullkomlega ánægð með að undirlagsleiðirnar sem fara upp á brúnina munu ekki geta farið niður. Öll samskipti milli gestgjafa innan DC verða að eiga sér stað innan hryggjarins.

Á sama tíma munu samanlagðar leiðir annarra DCs í öllum tilvikum auðveldlega ná til ToRs - AS-Path þeirra mun aðeins hafa ASN 65535 - fjölda AS Edge-Leafs, því það er þar sem þeir voru búnir til.

Af hverju eru þeir mismunandi í mismunandi DCs?

Fræðilega séð gætum við þurft að draga Loopback og sumar þjónustu sýndarvélar á milli DCs.

Til dæmis, á gestgjafanum munum við keyra Route Reflector eða sama VNGW (Virtual Network Gateway), sem mun læsast við TopR í gegnum BGP og tilkynna afturhvarf þess, sem ætti að vera aðgengilegt frá öllum DCs.

Svo þetta er hvernig AS-leiðin mun líta út:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Og það ætti ekki að vera afrit af ASN hvar sem er.

Það er, Spine_DC1 og Spine_DC2 verða að vera ólíkir, alveg eins og leafX_DC1 og leafY_DC2, sem er einmitt það sem við erum að nálgast.

Eins og þú veist sennilega, þá eru til reiðhestur sem gera þér kleift að samþykkja leiðir með afrit af ASN þrátt fyrir lykkjuvarnarbúnaðinn (leyfa inn á Cisco). Og það hefur jafnvel lögmæta notkun. En þetta er hugsanlegt bil í stöðugleika netsins. Og ég persónulega lenti í því nokkrum sinnum.

Og ef við höfum tækifæri til að nota ekki hættulega hluti munum við nýta það.

Lauf ASN

Við munum hafa einstakt ASN á hverjum Leaf rofa um allt netið.
Við gerum þetta af ástæðum sem gefnar eru upp hér að ofan: AS-Path án lykkjur, BGP stillingar án bókamerkja.

Til þess að leiðir milli Leafs fari vel, ætti AS-stígurinn að líta svona út:
[leafX_ASN, spine_ASN, leafY_ASN]
þar sem leafX_ASN og leafY_ASN væri gaman að vera öðruvísi.

Þetta er einnig nauðsynlegt fyrir ástandið með tilkynningu um VNF loopback milli DCs:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Við munum nota 4-bæta ASN og búa það til byggt á ASN hryggsins og blaðrofanúmerinu, nefnilega svona: Hrygg_ASN.0000X.

Þetta er myndin með ASN.

IP áætlun

Í grundvallaratriðum þurfum við að úthluta heimilisföngum fyrir eftirfarandi tengingar:

1. Leggðu undir netföng milli ToR og vél. Þau verða að vera einstök innan alls netkerfisins svo að hvaða vél sem er geti átt samskipti við aðra. Frábær passa 10/8. Fyrir hverja rekki eru /26 með varasjóði. Við munum úthluta /19 á DC og /17 á svæði.
2. Tengja heimilisföng milli Leaf/Tor og Spine.

   Mig langar að úthluta þeim reiknirit, það er að reikna þau út frá nöfnum tækjanna sem þarf að tengja.

   Látum það vera... 169.254.0.0/16.
   Nefnilega 169.254.00X.Y/31hvar X - Hryggnúmer, Y — P2P net /31.
   Þetta gerir þér kleift að ræsa allt að 128 rekka og allt að 10 spines í DC. Tengilsföng geta (og verða) verið endurtekin frá DC til DC.

3. Við skipuleggjum Spine-Edge-Leaf mótum á undirnetum 169.254.10X.Y/31, þar sem nákvæmlega það sama X - Hryggnúmer, Y — P2P net /31.
4. Tengdu vistföng frá Edge-Leaf við MPLS burðarás. Hér er staðan nokkuð önnur - staðurinn þar sem öll stykkin eru tengd í eina köku, þannig að endurnotkun sömu vistföngin virkar ekki - þú þarft að velja næsta ókeypis undirnet. Þess vegna skulum við taka til grundvallar 192.168.0.0/16 og við munum raka út hina lausu úr því.
5. Loopback Heimilisföng. Við munum gefa allt úrvalið fyrir þá 172.16.0.0/12.
   • Lauf - /25 á DC - sömu 128 rekki. Við munum úthluta /23 á svæði.
   • Hryggur - /28 á DC - allt að 16 hryggur. Úthlutum /26 á svæði.
   • Edge-Leaf - /29 á DC - allt að 8 kassar. Úthlutum /27 á svæði.

Ef við höfum ekki nógu mikið úthlutað svið í DC (og það verður engin - við segjumst vera hyperscalers), veljum við einfaldlega næsta reit.

Þetta er myndin með IP tölu.

Loopbacks:

Forskeyti
Hlutverk tækis
Region
DC

172.16.0.0/23
brún
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
BCN

172.16.0.40/29
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
SHA

172.16.0.72/29
SIA

172.16.2.0/23
hrygg
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
BCN

172.16.2.80/28
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
SHA

172.16.2.144/28
SIA

172.16.8.0/21
blaða
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
BCN

172.16.10.128/25
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
SHA

172.16.12.128/25
SIA

Undirlag:

Forskeyti
Region
DC

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
BCN

10.0.160.0/19
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
SHA

10.1.32.0/19
SIA

Laba

Tveir söluaðilar. Eitt net. ADSM.

Juniper + Arista. Ubuntu. Gamla góða Eva.

Magn auðlinda á sýndarþjóninum okkar í Mirana er enn takmarkað, þannig að til æfinga munum við nota net sem er einfaldað til hins ýtrasta.

Tvö gagnaver: Kazan og Barcelona.

• Tvær hryggjar hvor: Juniper og Arista.
• Einn torus (Leaf) í hverjum - Juniper og Arista, með einum tengdum gestgjafa (tökum léttan Cisco IOL fyrir þetta).
• Einn Edge-Leaf hnút hver (í augnablikinu aðeins Juniper).
• Einn Cisco rofi til að stjórna þeim öllum.
• Auk netboxanna er sýndarstýringarvél í gangi. Keyrir Ubuntu.
  Það hefur aðgang að öllum tækjum, það mun keyra IPAM/DCIM kerfi, fullt af Python forskriftum, Ansible og öllu öðru sem við gætum þurft.

Full stilling af öllum nettækjum, sem við munum reyna að endurskapa með sjálfvirkni.

Ályktun

Er það líka samþykkt? Ætti ég að skrifa stutta niðurstöðu undir hverja grein?

Svo við völdum þriggja stiga Kloz net innan DC, þar sem við búumst við mikilli austur-vestur umferð og viljum ECMP.

Netinu var skipt í líkamlegt (undirlag) og raunverulegt (yfirlag). Á sama tíma byrjar yfirlagið frá hýsilnum - þar með einfaldar kröfurnar fyrir undirlagið.

Við völdum BGP sem leiðarsamskiptareglur fyrir netkerfi vegna sveigjanleika þess og sveigjanleika í stefnu.

Við munum hafa aðskilda hnúta til að skipuleggja DCI - Edge-leaf.
Bakbeinið mun hafa OSPF+LDP.
DCI verður innleitt á grundvelli MPLS L3VPN.
Fyrir P2P tengla munum við reikna IP tölur út frá nöfnum tækja.
Við munum úthluta lykkjum í samræmi við hlutverk tækjanna og staðsetningu þeirra í röð.
Undirlagsforskeyti - aðeins á blaðrofum í röð eftir staðsetningu þeirra.

Gerum ráð fyrir að núna höfum við ekki búnaðinn uppsettan ennþá.
Þess vegna verða næstu skref okkar að bæta þeim við kerfin (IPAM, birgðahald), skipuleggja aðgang, búa til stillingar og dreifa henni.

Í næstu grein munum við fjalla um Netbox - birgða- og stjórnunarkerfi fyrir IP pláss í DC.

Þakka þér fyrir

• Andrey Glazkov aka @glazgoo fyrir prófarkalestur og leiðréttingar
• Alexander Klimenko aka @v00lk fyrir prófarkalestur og breytingar
• Artyom Chernobay fyrir KDPV

Heimild: www.habr.com