Yn 'e earste twa artikels brocht ik it probleem fan automatisearring op en sketste har ramt, yn' e twadde makke ik in retreat yn netwurkvirtualisaasje, as de earste oanpak foar it automatisearjen fan de konfiguraasje fan tsjinsten.
No is it tiid om in diagram fan it fysike netwurk te tekenjen.

As jo ​​​​net bekend binne mei it ynstellen fan datacenternetwurken, dan advisearje ik sterk te begjinnen mei artikels oer harren.

Alle saken:

• 0. ADSM. Part Zero. Planning
• 1. ADSM. Diel ien (dat is nei nul). Netwurk virtualisaasje
• 2. ADSM. Diel twa. Netwurk ûntwerp

De praktiken beskreaun yn dizze searje moatte fan tapassing wêze op elk type netwurk, elke grutte, mei elke ferskaat oan leveransiers (net). It is lykwols ûnmooglik om in universele foarbyld fan 'e tapassing fan dizze oanpak te beskriuwen. Dêrom sil ik rjochtsje op 'e moderne arsjitektuer fan it DC-netwurk: Kloz Fabryk.
Wy sille DCI dwaan op MPLS L3VPN.

In Overlay-netwurk rint boppe op it fysike netwurk fan 'e host (dit kin OpenStack's VXLAN of Tungsten Fabric wêze of wat oars dat allinich basis IP-ferbining fan it netwurk fereasket).

Yn dit gefal krije wy in relatyf ienfâldige senario foar automatisearring, om't wy in protte apparatuer hawwe dy't op deselde manier is konfigureare.

Wy sille in sfearyske DC kieze yn in fakuüm:

• Ien ûntwerpferzje oeral.
• Twa leveransiers dy't twa netwurkfleantugen foarmje.
• Ien DC is as in oar as twa earte yn in pod.

Ynhâld

• Fysike topology
• Routing
• IP plan
• Laba
• konklúzje
• Nuttige keppelings

Lit ús tsjinstferliener LAN_DC bygelyks trainingsfideo's hostje oer oerlibjen yn fêste liften.

Yn megasteden is dit heul populêr, dus jo hawwe in protte fysike masines nedich.

Earst sil ik it netwurk sawat beskriuwe lykas ik it graach wolle. En dan sil ik it ferienfâldigje foar it laboratoarium.

Fysike topology

Lokaasjes

LAN_DC sil 6 DC's hawwe:

• Ruslân (RU):
  • Moskou (msk)
  • Kazan (kzn)

• Spanje (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

• Sina (CN):
  • Shanghai (sha)
  • Xi'an (sia)

Inside DC (Intra-DC)

Alle DC's hawwe identike ynterne ferbiningsnetwurken basearre op Clos topology.
Wat soarte Clos netwurken binne se en wêrom binne se yn in apart artikel.

Elts DC hat 10 racks mei masines, se sille wurde nûmere as A, B, C En sa op.

Elts rack hat 30 masines. Se sille ús net ynteressearje.

Ek yn elke rack is d'r in skeakel wêrmei alle masines binne ferbûn - dit is Top of the Rack switch - ToR of oars, yn termen fan de Clos fabryk, wy sille neame it Blêd.

Algemiene diagram fan it fabryk.

Wy sille se neame XXX-blêdYwêr XXX - trije-letter ôfkoarting DC, en Y - searynûmer. Bygelyks, kzn-leaf11.

Yn myn artikels sil ik my talitte de termen Leaf en ToR frij frivolously as synonimen te brûken. Wy moatte lykwols betinke dat dit net it gefal is.
ToR is in switch ynstallearre yn in rek dêr't masines binne ferbûn.
Leaf is de rol fan in apparaat yn in fysyk netwurk of in earste-nivo switch yn termen fan Cloes topology.
Dat is, Leaf != ToR.
Sa Leaf kin bygelyks in EndofRaw-skeakel wêze.
Yn it ramt fan dit artikel sille wy se lykwols noch as synonimen behannelje.

Elke ToR-skeakel is op syn beurt ferbûn mei fjouwer aggregaasje-switches op heger nivo - Rêch. Ien rek yn 'e DC wurdt tawiisd foar Spines. Wy sille it op deselde namme neame: XXX-rêchY.

Itselde rack sil befetsje netwurk apparatuer foar ferbining tusken de DC - 2 routers mei MPLS oan board. Mar yn 't algemien binne dit deselde ToR's. Dat is, út it eachpunt fan Spine-skeakels, de gewoane ToR mei ferbûne masines of in router foar DCI makket neat út - gewoan trochstjoere.

Sokke spesjale ToR's wurde neamd Râneblêd. Wy sille se belje XXX-râneY.

It sil der sa útsjen.

Yn it boppesteande diagram haw ik eins râne en blêd op itselde nivo pleatst. Klassike trije-laach netwurken Se learden ús om uplinking (dus de term) as uplinks te beskôgjen. En hjir docht bliken dat de DCI "uplink" werom giet, wat foar guon wat de gewoane logika brekt. Yn it gefal fan grutte netwurken, as datasintra wurde ferdield yn noch lytsere ienheden - POD's (Point Of Delivery), markearje yndividu Edge-POD's foar DCI en tagong ta eksterne netwurken.

Foar gemak fan waarnimming yn 'e takomst sil ik noch Râne oer Spine tekenje, wylst wy yn gedachten hâlde dat d'r gjin yntelliginsje is op Spine en d'r binne gjin ferskillen by it wurkjen mei gewoane Leaf en Edge-leaf (hoewol't d'r hjir nuânses kinne wêze , mar yn it algemien Dit is wier).

Skema fan in fabryk mei Edge-leaves.

De trije-ienheid fan Leaf, Spine en Edge foarmje in Underlay-netwurk as fabryk.

De taak fan in netwurk fabryk (lês Underlay), sa't wy hawwe al definiearre yn lêste nûmer, heul, heul ienfâldich - om IP-ferbining te leverjen tusken masines sawol binnen deselde DC as tusken har.
Dêrom wurdt it netwurk in fabryk neamd, krekt as bygelyks in skeakelfabryk yn modulêre netwurkdoazen, dêr't jo mear oer lêze kinne yn SDSM14.

Yn 't algemien wurdt sa'n topology in fabryk neamd, om't stof yn oersetting stof betsjut. En it is dreech om it net iens te wêzen:

It fabryk is folslein L3. Gjin VLAN, gjin Broadcast - wy hawwe sokke prachtige programmeurs by LAN_DC, se witte hoe te skriuwen applikaasjes dy't libje yn it L3 paradigma, en firtuele masines net nedich Live Migration mei behâld fan it IP-adres.

En nochris: it antwurd op de fraach wêrom't it fabryk en wêrom L3 is yn in apart artikel.

DCI - Data Center Interconnect (Inter-DC)

DCI sil wurde organisearre mei Edge-Leaf, dat is, se binne ús útgongspunt nei de snelwei.
Foar ienfâld geane wy ​​derfan út dat de DC's mei inoar ferbûn binne troch direkte keppelings.
Lit ús eksterne ferbining útslute fan beskôging.

Ik bin bewust dat elke kear as ik in komponint fuortsmite, ik it netwurk signifikant ferienfâldigje. En as wy ús abstrakte netwurk automatisearje, sil alles goed wêze, mar op 'e echte sille d'r krukken wêze.
Dit is wier. Noch altyd is it punt fan dizze searje om te tinken en te wurkjen oan oanpakken, net om tinkbyldige problemen heroysk op te lossen.

Op Edge-Leafs wurdt de underlay yn 'e VPN pleatst en oerbrocht fia de MPLS-rêchbonke (deselde direkte keppeling).

Dit is it diagram op boppeste nivo dat wy krije.

Routing

Foar routing binnen de DC sille wy BGP brûke.
Op de MPLS-romp OSPF+LDP.
Foar DCI, dat is, organisearjen fan ferbining yn 'e ûndergrûn - BGP L3VPN oer MPLS.

Algemiene routing skema

D'r is gjin OSPF of ISIS (routingprotokol ferbean yn 'e Russyske Federaasje) by it fabryk.

Dit betsjut dat d'r gjin Auto-ûntdekking of berekkening fan koartste paden sil wêze - allinich hânmjittich (eigentlik automatysk - wy prate hjir oer automatisearring) it ynstellen fan it protokol, buert en belied.

BGP routing skema binnen de DC

Wêrom BGP?

Op dit ûnderwerp is der hiele RFC neamd nei Facebook en Arista, dy't fertelt hoe te bouwen hiel grut datacenternetwurken mei BGP. It lêst hast as fiksje, ik rekommandearje it tige oan foar in lompe jûn.

En der is ek in hiele paragraaf yn myn artikel wijd oan dit. Wêr nim ik dy en ik stjoer.

Mar dochs, koartsein, gjin IGP is geskikt foar netwurken fan grutte datasintra, dêr't it oantal netwurk apparaten rint yn de tûzenen.

Derneist, mei BGP oeral kinne jo gjin tiid fergrieme op it stypjen fan ferskate ferskillende protokollen en syngronisaasje tusken har.

Hân op hert, yn ús fabryk, dat mei in hege graad fan kâns net fluch groeie sil, soe OSPF genôch wêze foar de eagen. Dit binne eins de problemen fan megascalers en wolkentitanen. Mar lit ús yntinke krekt foar in pear releases dat wy nedich hawwe, en wy sille brûke BGP, as Pyotr Lapukhov fermakke.

Routing Policies

Op Leaf-skeakels ymportearje wy foarheaksels fan Underlay-netwurkynterfaces yn BGP.
Wy sille hawwe in BGP sesje tusken elk in Leaf-Spine pear, wêryn dizze Underlay foarheaksels wurde oankundige oer it netwurk hjir en dêr.

Binnen ien datasintrum sille wy de spesifikaasjes fersprieden dy't wy ymporteare yn ToRe. Op Edge-Leafs sille wy se aggregearje en kundigje se oan op ôfstân DC's en stjoere se nei TOR's. Dat is, elke ToR sil krekt witte hoe't jo nei in oare ToR kinne komme yn deselde DC en wêr't it yngongspunt is om nei de ToR te kommen yn in oare DC.

Yn DCI sille rûtes wurde oerbrocht as VPNv4. Om dit te dwaan, op Edge-Leaf, sil de ynterface nei it fabryk yn in VRF pleatst wurde, litte wy it UNDERLAY neame, en de buert mei Spine on Edge-Leaf sil opstean binnen de VRF, en tusken Edge-Leafs yn 'e VPNv4- famylje.

Wy sille ek ferbiede de opnij oankundiging fan rûtes ûntfongen fan spines werom nei harren.

Op Leaf and Spine sille wy Loopbacks net ymportearje. Wy hawwe se allinich nedich om de router-ID te bepalen.

Mar op Edge-Leafs ymportearje wy it yn Global BGP. Tusken Loopback-adressen sil Edge-Leafs in BGP-sesje yn 'e IPv4 VPN-famylje mei elkoar fêstigje.

Wy sille in OSPF + LDP-rêgen hawwe tusken EDGE-apparaten. Alles is yn ien sône. Ekstreem ienfâldige konfiguraasje.

Dit is de foto mei routing.

BGP ASN

Edge-Leaf ASN

Op Edge-Leafs sil d'r ien ASN wêze yn alle DC's. It is wichtich dat der iBGP tusken Edge-Leafs, en wy net krije fongen yn 'e nuânses fan eBGP. Lit it wêze 65535. Yn werklikheid kin dit it nûmer wêze fan in iepenbiere AS.

Spine ASN

Op Spine sille wy ien ASN per DC hawwe. Litte wy hjir begjinne mei it alderearste nûmer út it berik fan privee AS - 64512, 64513 Ensafuorthinne.

Wêrom ASN op DC?

Litte wy dizze fraach yn twa brekke:

• Wêrom binne de ASNs itselde op alle spines fan ien DC?
• Wêrom binne se oars yn ferskate DC's?

Wêrom binne deselde ASNs op alle spines fan ien DC?

Dit is hoe't it AS-paad fan 'e Underlay-rûte op Edge-Leaf der útsjen sil:
[leafX_ASN, spine_ASN, edge_ASN]
As jo ​​​​besykje it werom te advertearjen nei Spine, sil it it ferwiderje om't syn AS (Spine_AS) al yn 'e list is.

Binnen de DC binne wy ​​​​lykwols folslein tefreden dat de Underlay-rûtes dy't opstekke nei de Râne net kinne omleech gean. Alle kommunikaasje tusken hosts binnen de DC moat plakfine binnen de spine nivo.

Yn dit gefal sille de aggregearre rûtes fan oare DC's yn alle gefallen maklik de ToR's berikke - har AS-Pad sil allinich ASN 65535 hawwe - it oantal AS Edge-Leafs, om't dat is wêr't se makke binne.

Wêrom binne se oars yn ferskate DC's?

Teoretysk moatte wy miskien Loopback en guon tsjinst firtuele masines tusken DC's slepe.

Bygelyks, op de host wy sille rinne Route Reflector of deselde VNGW (Virtual Network Gateway), dy't sil beskoattelje mei TopR fia BGP en syn loopback oankundigje, dy't tagonklik wêze moat fan alle DC's.

Dat dit is hoe't syn AS-Pad der útsjen sil:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

En d'r moatte oeral gjin dûbele ASN's wêze.

Dat is, Spine_DC1 en Spine_DC2 moatte oars wêze, krekt as leafX_DC1 en leafY_DC2, dat is krekt wat wy benaderje.

Sa't jo nei alle gedachten witte, der binne hacks dy't tastean jo te akseptearjen rûtes mei dûbele ASN nettsjinsteande de loop previnsje meganisme (allowas-in op Cisco). En it hat sels legitime gebrûk. Mar dit is in potinsjele gat yn 'e stabiliteit fan it netwurk. En ik foel der persoanlik in pear kear yn.

En as wy de kâns hawwe om gjin gefaarlike dingen te brûken, sille wy der profitearje fan.

Leaf ASN

Wy sille hawwe in yndividuele ASN op eltse Leaf switch hiele netwurk.
Wy dogge dit foar de redenen jûn hjirboppe: AS-Pad sûnder loops, BGP konfiguraasje sûnder blêdwizers.

Om rûtes tusken Leafs soepel troch te gean, soe it AS-paad der sa útsjen moatte:
[leafX_ASN, spine_ASN, leafY_ASN]
dêr't leafX_ASN en leafY_ASN moai wêze soe om oars te wêzen.

Dit is ek nedich foar de situaasje mei de oankundiging fan in VNF-loopback tusken DC's:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Wy sille in 4-byte ASN brûke en it generearje op basis fan 'e Spine's ASN en it Leaf-skeakelnûmer, nammentlik sa: Spine_ASN.0000X.

Dit is de foto mei ASN.

IP plan

Yn prinsipe moatte wy adressen tawize foar de folgjende ferbiningen:

1. Underlay netwurkadressen tusken ToR en masine. Se moatte unyk wêze binnen it heule netwurk, sadat elke masine mei elke oare kin kommunisearje. Geweldich fit 10/8. Foar elk rek binne der /26 mei in reserve. Wy sille /19 per DC en /17 per regio tawize.
2. Link adressen tusken Leaf / Tor en Spine.

   Ik wol se algoritmysk tawize, dat is, se berekkenje út 'e nammen fan' e apparaten dy't moatte wurde ferbûn.

   Lit it wêze ... 169.254.0.0/16.
   Nammentlik 169.254.00X.Y/31wêr X - Spine nûmer, Y - P2P netwurk /31.
   Dit sil tastean jo te starten oant 128 racks, en oant 10 Spines yn de DC. Linkadressen kinne (en sille) wurde werhelle fan DC nei DC.

3. Wy organisearje it knooppunt Spine-Edge-Leaf op subnets 169.254.10X.Y/31, dêr't krekt itselde X - Spine nûmer, Y - P2P netwurk /31.
4. Link adressen fan Edge-Leaf nei MPLS rêchbonke. Hjir is de situaasje wat oars - it plak wêr't alle stikken binne ferbûn yn ien pie, dus it werbrûken fan deselde adressen sil net wurkje - jo moatte it folgjende fergese subnet selektearje. Dêrom, lit ús nimme as basis 192.168.0.0/16 en wy sille der de frije út harkje.
5. Loopback-adressen. Wy sille jouwe it hiele berik foar harren 172.16.0.0/12.
   • Leaf - /25 per DC - deselde 128 racks. Wy sille /23 per regio tawize.
   • Spine - /28 per DC - oant 16 Spine. Lit ús /26 per regio tawize.
   • Edge-Leaf - /29 per DC - oant 8 doazen. Lit ús /27 per regio tawize.

As wy net genôch tawiisde berik hawwe yn 'e DC (en d'r sil gjin wêze - wy beweare dat wy hyperskalers binne), selektearje wy gewoan it folgjende blok.

Dit is de ôfbylding mei IP-adressen.

Loopbacks:

Foarheaksel
Rol fan it apparaat
Lokaasje
DC

172.16.0.0/23
râne
 
 

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
rêch
 
 

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
blêd
 
 

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

Underlay:

Foarheaksel
Lokaasje
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

Twa ferkeapers. Ien netwurk. ADSM.

Juniper + Arista. Ubuntu. Goeie âlde Eva.

De hoemannichte boarnen op ús firtuele server yn Mirana is noch beheind, dus foar praktyk sille wy in netwurk brûke dat oant de limyt ferienfâldige is.

Twa datasintra: Kazan en Barcelona.

• Twa stekels elk: Juniper en Arista.
• Ien torus (Leaf) yn elk - Juniper en Arista, mei ien ferbûn host (lite wy nimme in lichtgewicht Cisco IOL foar dit).
• Ien Edge-Leaf-knooppunt elk (foar no allinich Juniper).
• Ien Cisco switch te hearskje se allegearre.
• Neist de netwurkdoazen rint in firtuele kontrôlemasine. Running Ubuntu.
  It hat tagong ta alle apparaten, it sil IPAM / DCIM-systemen útfiere, in bosk Python-skripts, Ansible en alles wat wy miskien nedich hawwe.

Folsleine konfiguraasje fan alle netwurkapparaten, dy't wy sille besykje te reprodusearjen mei automatisearring.

konklúzje

Is dat ek akseptearre? Moat ik ûnder elk artikel in koarte konklúzje skriuwe?

Sa hawwe wy keazen trije-nivo Kloz netwurk binnen de DC, sûnt wy ferwachtsje in soad East-West ferkear en wolle ECMP.

It netwurk waard ferdield yn fysike (underlay) en firtuele (overlay). Tagelyk begjint de overlay fan 'e host - wêrtroch't de easken foar de underlay ferienfâldigje.

Wy hawwe BGP keazen as it routingprotokol foar netwurknetwurken foar syn skalberens en beliedsfleksibiliteit.

Wy sille hawwe aparte knopen foar it organisearjen fan DCI - Edge-leaf.
De rêchbonke sil OSPF + LDP hawwe.
DCI sil wurde ymplementearre basearre op MPLS L3VPN.
Foar P2P-keppelings sille wy IP-adressen algoritmysk berekkenje op basis fan apparaatnammen.
Wy sille loopbacks tawize neffens de rol fan 'e apparaten en har lokaasje sequentially.
Underlay-foarheaksels - allinich op Leaf-skeakels sequentieel basearre op har lokaasje.

Lit ús oannimme dat wy no de apparatuer noch net ynstalleare hawwe.
Dêrom sille ús folgjende stappen wêze om se ta te foegjen oan 'e systemen (IPAM, ynventaris), tagong te organisearjen, in konfiguraasje generearje en it ynsette.

Yn it folgjende artikel sille wy omgean mei Netbox - in ynventaris- en behearsysteem foar IP-romte yn in DC.

Dankewol

• Andrey Glazkov aka @glazgoo foar korrektyflêzen en korreksjes
• Alexander Klimenko aka @v00lk foar korrektyflêzen en bewurkingen
• Artyom Chernobay foar KDPV

Boarne: www.habr.com