En la unuaj du artikoloj, mi levis la temon de aŭtomatigo kaj skizis ĝian kadron, en la dua mi faris retiriĝon en retan virtualigon, kiel la unua alproksimiĝo al aŭtomatigo de la agordo de servoj.
Nun estas tempo desegni diagramon de la fizika reto.

Se vi ne konas agordon de datumcentraj retoj, tiam mi forte rekomendas komenci per artikoloj pri ili.

Ĉiuj aferoj:

• 0. ADSM. Parto Nulo. Planado
• 1. ADSM. Unua parto (kiu estas post nulo). Reta virtualigo
• 2. ADSM. Dua parto. Reto-dezajno

La praktikoj priskribitaj en ĉi tiu serio devus esti aplikeblaj al ajna tipo de reto, ajna grandeco, kun ajna vario de vendistoj (ne). Tamen, estas neeble priskribi universalan ekzemplon de la apliko de ĉi tiuj aliroj. Tial mi koncentriĝos pri la moderna arkitekturo de la DC-reto: Fabriko Kloz.
Ni faros DCI sur MPLS L3VPN.

Overlay-reto funkcias super la fizika reto de la gastiganto (ĉi tio povus esti la VXLAN aŭ Tungsten Fabric de OpenStack aŭ io ajn alia, kiu postulas nur bazan IP-konektecon de la reto).

En ĉi tiu kazo, ni ricevas relative simplan scenaron por aŭtomatigo, ĉar ni havas multajn ekipaĵojn, kiuj estas agordita en la sama maniero.

Ni elektos sferan DC en vakuo:

• Unu desegna versio ĉie.
• Du vendistoj formante du retajn aviadilojn.
• Unu DC estas kiel alia kiel du pizoj en balgo.

Enhavo

• Fizika topologio
• Envojigo
• IP-plano
• Laba
• konkludo
• utilaj ligoj

Lasu nian Servoprovizanton LAN_DC, ekzemple, gastigi trejnajn filmetojn pri pluvivo en blokitaj liftoj.

En megaurboj ĉi tio estas tre populara, do vi bezonas multajn fizikajn maŝinojn.

Unue, mi priskribos la reton proksimume kiel mi ŝatus, ke ĝi estu. Kaj tiam mi simpligos ĝin por la laboratorio.

Fizika topologio

Lokoj

LAN_DC havos 6 DC-ojn:

• Rusio (RU):
  • Moskvo (msk)
  • Kazan (kzn)

• Hispanio (SP):
  • Barcelono (bcn)
  • Malago (MLG)

• Ĉinio (CN):
  • Ŝanhajo (sha)
  • Ŝjiano (ambaŭ)

Ene de DC (Intra-DC)

Ĉiuj Dc havas identajn internajn konekteblecretojn bazitajn sur Clos-topologio.
Kiaj Clos-retoj ili estas kaj kial ili estas en aparta artikolo.

Ĉiu PK havas 10 rakojn kun maŝinoj, ili estos numeritaj kiel A, B, C Kaj tiel plu.

Ĉiu rako havas 30 maŝinojn. Ili ne interesos nin.

Ankaŭ en ĉiu rako estas ŝaltilo, al kiu ĉiuj maŝinoj estas konektitaj - jen Supro de la Rack-ŝaltilo - ToR aŭ alie, laŭ la fabriko Clos, ni nomos ĝin folio.

Ĝenerala diagramo de la fabriko.

Ni vokos ilin XXX-folioYkie XXX - trilitera mallongigo DC, kaj Y - seria numero. Ekzemple, kzn-folio11.

En miaj artikoloj mi permesos al mi uzi la terminojn Folio kaj ToR sufiĉe frivole kiel sinonimojn. Tamen ni devas memori, ke ĉi tio ne estas la kazo.
ToR estas ŝaltilo instalita en rako al kiu maŝinoj estas konektitaj.
Folio estas la rolo de aparato en fizika reto aŭ unuanivela ŝaltilo laŭ Cloes-topologio.
Tio estas Folio != ToR.
Do Folio povas esti EndofRaw-ŝaltilo, ekzemple.
Tamen, kadre de ĉi tiu artikolo ni ankoraŭ traktos ilin kiel sinonimojn.

Ĉiu ToR-ŝaltilo estas siavice konektita al kvar altnivelaj agregŝaltiloj - spino. Unu rako en la Dc estas asignita por Spinoj. Ni nomos ĝin simile: XXX- spinoY.

La sama rako enhavos retan ekipaĵon por konektebleco inter la DC - 2-enkursigiloj kun MPLS surŝipe. Sed ĝenerale, ĉi tiuj estas la samaj ToR-oj. Tio estas, el la vidpunkto de Spine-ŝaltiloj, la kutima ToR kun konektitaj maŝinoj aŭ enkursigilo por DCI ne gravas - unu diable antaŭen.

Tiaj specialaj ToR-oj estas nomitaj Rando-folio. Ni vokos ilin XXX-randoY.

Ĝi aspektos tiel.

En la supra diagramo, mi efektive metis randon kaj folion sur la sama nivelo. Klasikaj tri-tavolaj retoj Ili instruis nin konsideri uplinking (do la termino) kiel uplinks. Kaj ĉi tie rezultas, ke la DCI "suprenligo" reen malsupreniras, kio por iuj iomete rompas la kutiman logikon. En la kazo de grandaj retoj, kiam datumcentroj estas dividitaj en eĉ pli malgrandajn unuojn - POD's (Point Of Delivery), reliefigi individuon Edge-POD's por DCI kaj aliro al eksteraj retoj.

Por facileco de percepto en la estonteco, mi ankoraŭ desegnos Edge over Spine, dum ni memoros, ke ne ekzistas inteligenteco pri Spine kaj ne estas diferencoj kiam vi laboras kun regulaj Folio kaj Rando-folio (kvankam povas esti nuancoj ĉi tie. , sed ĝenerale Ĉi tio estas vera).

Skemo de fabriko kun Rando-folioj.

La triunuo de Folio, Spino kaj Rando formas Underlay-reton aŭ fabrikon.

La tasko de reta fabriko (legu Underlay), kiel ni jam difinis en lasta numero, tre, tre simpla - provizi IP-konektecon inter maŝinoj kaj ene de la sama DC kaj inter ili.
Tial la reto nomiĝas fabriko, same kiel ekzemple ŝaltila fabriko ene de modulaj retaj skatoloj, pri kiuj vi povas legi pli en SDSM14.

Ĝenerale, tia topologio estas nomita fabriko, ĉar ŝtofo en traduko signifas ŝtofo. Kaj estas malfacile malkonsenti:

La fabriko estas tute L3. Neniu VLAN, neniu Elsendo - ni havas tiajn mirindajn programistojn ĉe LAN_DC, ili scias kiel skribi aplikojn kiuj vivas en la paradigmo L3, kaj virtualaj maŝinoj ne postulas Vivan Migradon kun konservado de la IP-adreso.

Kaj denove: la respondo al la demando kial la fabriko kaj kial L3 estas en aparta artikolo.

DCI - Datumcentro-Interkonekto (Inter-DC)

DCI estos organizita uzante Edge-Leaf, tio estas, ili estas nia elirpunkto al la ŝoseo.
Por simpleco, ni supozas ke la PK estas ligitaj unu al la alia per rektaj ligiloj.
Ni ekskludu eksteran konekteblecon de konsidero.

Mi konscias, ke ĉiufoje kiam mi forigas komponanton, mi signife simpligas la reton. Kaj kiam ni aŭtomatigos nian abstraktan reton, ĉio estos en ordo, sed sur la reala estos lambastonoj.
Ĉi tio estas vera. Tamen, la celo de ĉi tiu serio estas pensi kaj labori pri aliroj, ne heroe solvi imagajn problemojn.

Sur Edge-Leafs, la subtavolo estas metita en la VPN kaj transdonita tra la MPLS-spino (la sama rekta ligo).

Ĉi tiu estas la supranivela diagramo, kiun ni ricevas.

Envojigo

Por vojigo ene de la DC ni uzos BGP.
Sur la MPLS-trunko OSPF+LDP.
Por DCI, tio estas, organizi konekteblecon en la subtera - BGP L3VPN super MPLS.

Ĝenerala envojiga skemo

Ne estas OSPF aŭ ISIS (vojprotokolo malpermesita en la Rusa Federacio) ĉe la fabriko.

Ĉi tio signifas, ke ne estos Aŭtomata malkovro aŭ kalkulo de plej mallongaj vojoj - nur mana (fakte aŭtomata - ni parolas pri aŭtomatigo ĉi tie) agordante la protokolon, najbarecon kaj politikojn.

BGP-vojigskemo ene de la Dc

Kial BGP?

Pri ĉi tiu temo ekzistas tuta RFC nomita laŭ Facebook kaj Arista, kiu rakontas kiel konstrui grandega datumcentraj retoj uzante BGP. Ĝi legas preskaŭ kiel fikcio, mi tre rekomendas ĝin por languida vespero.

Kaj ankaŭ estas tuta sekcio en mia artikolo dediĉita al tio. Kien mi konduku vin kaj Mi sendas.

Sed tamen, mallonge, neniu IGP taŭgas por retoj de grandaj datumcentroj, kie la nombro da retaj aparatoj atingas milojn.

Krome, uzi BGP ĉie permesos al vi ne malŝpari tempon por subteni plurajn malsamajn protokolojn kaj sinkronigadon inter ili.

Mano sur koro, en nia fabriko, kiu kun alta grado de probableco ne rapide kreskos, OSPF sufiĉus por la okuloj. Ĉi tiuj fakte estas la problemoj de megascalers kaj nubaj titanoj. Sed ni imagu nur por kelkaj eldonoj, ke ni bezonas ĝin, kaj ni uzos BGP, kiel testamentis Pjotr ​​Lapuĥov.

Vojaj Politikoj

Sur Leaf-ŝaltiloj, ni importas prefiksojn de Underlay-retaj interfacoj en BGP.
Ni havos BGP-sesion inter ĉiu paro Folio-Spino, en kiu ĉi tiuj Submetataj prefiksoj estos anoncitaj tra la reto tie kaj tie.

Ene de unu datumcentro, ni distribuos la specifojn, kiujn ni importis en ToRe. Sur Edge-Leafs ni kunigos ilin kaj anoncos ilin al malproksimaj DC-oj kaj sendos ilin al TOR-oj. Tio estas, ĉiu ToR scios precize kiel atingi alian ToR en la sama DC kaj kie la enirpunkto estas atingi la ToR en alia DC.

En DCI, itineroj estos elsenditaj kiel VPNv4. Por fari tion, sur Edge-Leaf, la interfaco al la fabriko estos metita en VRF, ni nomu ĝin SUBLAY, kaj la kvartalo kun Spine sur Edge-Leaf leviĝos ene de la VRF, kaj inter Edge-Leafs en la VPNv4- familio.

Ni ankaŭ malpermesos la reanoncon de itineroj ricevitaj de spinoj reen al ili.

Sur Folio kaj Spino ni ne importos Loopbacks. Ni nur bezonas ilin por determini la Router-ID.

Sed ĉe Edge-Leafs ni importas ĝin en Global BGP. Inter Loopback-adresoj, Edge-Leafs establos BGP-sesion en la IPv4 VPN-familio unu kun la alia.

Ni havos OSPF+LDP spinon inter EDGE-aparatoj. Ĉio estas en unu zono. Ege simpla agordo.

Jen la bildo kun vojigo.

BGP ASN

Rando-Folia ASN

Sur Edge-Leafs estos unu ASN en ĉiuj DC-oj. Gravas, ke ekzistas iBGP inter Edge-Leafs, kaj ni ne kaptiĝas en la nuancoj de eBGP. Estu 65535. En realeco, ĉi tio povus esti la nombro de publika AS.

Spino ASN

Sur Spine ni havos unu ASN per DC. Ni komencu ĉi tie per la plej unua nombro el la gamo de privata AS - 64512, 64513 Kaj tiel plu.

Kial ASN sur DC?

Ni dividu ĉi tiun demandon en du:

• Kial la ASN-oj estas samaj sur ĉiuj spinoj de unu DC?
• Kial ili estas malsamaj en malsamaj DC-oj?

Kial estas la samaj ASN-oj sur ĉiuj spinoj de unu DC?

Jen kiel aspektos la AS-Path of the Underlay-itinero sur Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Kiam vi provas reklami ĝin reen al Spine, ĝi forĵetos ĝin ĉar ĝia AS (Spine_AS) jam estas en la listo.

Tamen, ene de la DC ni estas tute kontentaj, ke la Underlay-vojoj kiuj supreniras al la Rando ne povos malsupreniri. Ĉiu komunikado inter gastigantoj ene de la DC devas okazi ene de la spina nivelo.

En ĉi tiu kazo, la kunigitaj itineroj de aliaj DC-oj ĉiukaze facile atingos la ToR-ojn - ilia AS-Path havos nur ASN 65535 - la nombron da AS Edge-Leafs, ĉar tie ili estis kreitaj.

Kial ili estas malsamaj en malsamaj DC-oj?

Teorie, ni eble bezonos treni Loopback kaj iujn servajn virtualajn maŝinojn inter DC-oj.

Ekzemple, sur la gastiganto ni rulos Route Reflector aŭ la sama VNGW (Virtuala Network Gateway), kiu ŝlosiĝos kun TopR per BGP kaj anoncos ĝian loopback, kiu devus esti alirebla de ĉiuj DC-oj.

Do jen kiel aspektos ĝia AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Kaj ne estu duplikataj ASN-oj ie ajn.

Tio estas, Spine_DC1 kaj Spine_DC2 devas esti malsamaj, same kiel leafX_DC1 kaj leafY_DC2, kio estas ĝuste al kio ni alproksimiĝas.

Kiel vi verŝajne scias, ekzistas hakoj, kiuj ebligas al vi akcepti itinerojn kun duobligitaj ASN-oj malgraŭ la bukla preventa mekanismo (permesata en Cisco). Kaj ĝi eĉ havas legitimajn uzojn. Sed ĉi tio estas ebla breĉo en la stabileco de la reto. Kaj mi persone falis en ĝin kelkajn fojojn.

Kaj se ni havas la ŝancon ne uzi danĝerajn aferojn, ni profitos ĝin.

Folio ASN

Ni havos individuan ASN sur ĉiu Leaf-ŝaltilo tra la reto.
Ni faras tion pro la supraj kialoj: AS-Path sen bukloj, BGP-agordo sen legosignoj.

Por ke itineroj inter Folioj pasu glate, la AS-Path devus aspekti jene:
[leafX_ASN, spine_ASN, leafY_ASN]
kie leafX_ASN kaj leafY_ASN estus bone esti malsamaj.

Ĉi tio ankaŭ estas postulata por la situacio kun la proklamo de VNF-loopback inter DCoj:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Ni uzos 4-bajtan ASN kaj generos ĝin surbaze de la ASN de la Spino kaj la Folio-ŝalta numero, nome jene: Spine_ASN.0000X.

Ĉi tiu estas la bildo kun ASN.

IP-plano

Esence, ni devas asigni adresojn por la sekvaj ligoj:

1. Submeta retadresoj inter ToR kaj maŝino. Ili devas esti unikaj ene de la tuta reto, por ke iu ajn maŝino povas komuniki kun iu ajn alia. Bonege taŭga 10/8. Por ĉiu rako estas /26 kun rezervo. Ni asignos /19 po DC kaj /17 po regiono.
2. Ligo-adresoj inter Folio/Tor kaj Spine.

   Mi ŝatus atribui ilin algoritme, tio estas, kalkuli ilin el la nomoj de la aparatoj, kiuj devas esti konektitaj.

   Estu... 169.254.0.0/16.
   Nome 169.254.00X.Y/31kie X - Spinonumero, Y — P2P reto /31.
   Ĉi tio permesos al vi lanĉi ĝis 128 rakojn, kaj ĝis 10 Spinojn en la DC. Ligiladresoj povas (kaj estos) ripetitaj de DC ĝis DC.

3. Ni organizas la krucvojon Spine-Edge-Leaf sur subretoj 169.254.10X.Y/31, kie ĝuste la sama X - Spinonumero, Y — P2P reto /31.
4. Ligi adresojn de Edge-Leaf al MPLS spino. Ĉi tie la situacio estas iom malsama - la loko, kie ĉiuj pecoj estas konektitaj en unu kukaĵon, do reuzo de la samaj adresoj ne funkcios - vi devas elekti la sekvan senpagan subreton. Tial, ni prenu kiel bazon 192.168.0.0/16 kaj ni eltiros la liberajn el ĝi.
5. Loopback Adresoj. Ni donos la tutan gamon por ili 172.16.0.0/12.
   • Folio - /25 po DC - la samaj 128 rakoj. Ni asignos /23 por regiono.
   • Spino - /28 per PK - ĝis 16 Spino. Ni asignu /26 po regiono.
   • Rando-Folio - /29 per PK - ĝis 8 skatoloj. Ni asignu /27 po regiono.

Se ni ne havas sufiĉe da asignitaj intervaloj en la DC (kaj ne estos iuj - ni asertas esti hiperscalers), ni simple elektas la sekvan blokon.

Jen la bildo kun IP-adresado.

Loopbacks:

Prefikso
Rolo de la aparato
Regiono
ДЦ

172.16.0.0/23
rando
 
 

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
ambaŭ

172.16.2.0/23
spino
 
 

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
ambaŭ

172.16.8.0/21
Folio
 
 

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
ambaŭ

Submetaĵo:

Prefikso
Regiono
ДЦ

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
ambaŭ

Laba

Du vendistoj. Unu reto. ADSM.

Junipero + Arista. Ubuntu. Bona maljuna Eva.

La kvanto de rimedoj en nia virtuala servilo en Mirana estas ankoraŭ limigita, do por praktiko ni uzos reton, kiu estas simpligita ĝis la limo.

Du datumcentroj: Kazan kaj Barcelono.

• Po du pikiloj: Junipero kaj Arista.
• Unu toro (Folio) en ĉiu - Junipero kaj Arista, kun unu konektita gastiganto (ni prenu malpezan Cisco IOL por ĉi tio).
• Po unu Rando-Folia nodo (nuntempe nur Junipero).
• Unu Cisco-ŝaltilo por regi ilin ĉiujn.
• Aldone al la retaj skatoloj, funkcias virtuala kontrolmaŝino. Kurante Ubuntu.
  Ĝi havas aliron al ĉiuj aparatoj, ĝi funkcios IPAM/DCIM-sistemojn, amason da Python-skriptoj, Ansible kaj ion alian, kion ni eble bezonos.

Plena agordo de ĉiuj retaj aparatoj, kiujn ni provos reprodukti uzante aŭtomatigon.

konkludo

Ĉu ankaŭ tio estas akceptata? Ĉu mi skribu mallongan konkludon sub ĉiu artikolo?

Do ni elektis trinivela Kloz-reto ene de la DC, ĉar ni atendas multan Orient-Okcidentan trafikon kaj volas ECMP.

La reto estis dividita en fizikan (submetaĵo) kaj virtualan (supermetaĵon). Samtempe, la tegaĵo komenciĝas de la gastiganto - tiel simpligante la postulojn por la submetaĵo.

Ni elektis BGP kiel la vojprotokolon por retaj retoj pro ĝia skaleblo kaj politika fleksebleco.

Ni havos apartajn nodojn por organizi DCI - Edge-leaf.
La spino havos OSPF+LDP.
DCI estos efektivigita surbaze de MPLS L3VPN.
Por P2P-ligoj, ni kalkulos IP-adresojn algoritme surbaze de aparataj nomoj.
Ni asignos loopbacks laŭ la rolo de la aparatoj kaj ilia loko sinsekve.
Subtagprefiksoj - nur ĉe Folioŝaltiloj sinsekve surbaze de ilia loko.

Ni supozu, ke nun ni ankoraŭ ne havas la ekipaĵon instalitan.
Sekve, niaj sekvaj paŝoj estos aldoni ilin al la sistemoj (IPAM, inventaro), organizi aliron, generi agordon kaj disfaldi ĝin.

En la sekva artikolo ni traktos Netbox - inventaron kaj administradsistemon por IP-spaco en DC.

Dankon

• Andrey Glazkov alinome @glazgoo pro provlegado kaj korektoj
• Alexander Klimenko alinome @v00lk por provlegado kaj redaktoj
• Artyom Chernobay por KDPV

fonto: www.habr.com