Lehenengo bi artikuluetan, automatizazioaren gaia planteatu eta bere esparrua zirriborratu nuen, bigarrenean sare birtualizazioan erretiro bat egin nuen, zerbitzuen konfigurazioa automatizatzeko lehen hurbilketa gisa.
Orain sare fisikoaren diagrama bat marrazteko garaia da.
Ez baduzu ezagutzen datu-zentroen sareak konfiguratzen, orduan hastea gomendatzen dizut .
Gai guztiak:
Serie honetan deskribatutako praktikak edozein sare motari, edozein tamainari, edozein saltzaileri (ez) aplikatu behar zaizkio. Hala ere, ezinezkoa da planteamendu horien aplikazioaren adibide unibertsal bat deskribatzea. Horregatik, DC sarearen arkitektura modernoan zentratuko naiz: .
DCI MPLS L3VPNn egingo dugu.
Overlay sare bat ostalariaren sare fisikoaren gainean exekutatzen da (hau OpenStack-en VXLAN edo Tungsten Fabrica edo saretik oinarrizko IP konexioa behar duen beste edozer izan daiteke).
Kasu honetan, automatizaziorako agertoki sinple samarra lortzen dugu, era berean konfiguratuta dauden ekipamendu asko ditugulako.
DC esferiko bat aukeratuko dugu hutsean:
- Diseinu bertsio bat nonahi.
- Bi saltzaile sareko bi plano osatzen.
- DC bat leka batean bi ilar bezalako beste bat da.
Edukia
- Topologia fisikoa
- Bideratzea
- IP plana
- Laba
- Ondorioa
- Esteka interesgarriak
Utzi gure LAN_DC zerbitzu-hornitzaileari, adibidez, trabatuta igogailuetan bizirik irauteko prestakuntza-bideoak antolatzea.
Megahirietan hau oso ezaguna da, beraz, makina fisiko asko behar dituzu.
Lehenik eta behin, sarea nahiko nukeen moduan deskribatuko dut gutxi gorabehera. Eta gero sinplifikatu egingo dut laborategirako.
Topologia fisikoa
Kokapenak
LAN_DCk 6 DC izango ditu:
- Errusia (RU):
- Mosku (MSK)
- Kazan (kzn)
- Espainia (SP):
- Bartzelona (bcn)
- Malaga (mlg)
- Txina (CN):
- Shanghai (sha)
- Xi'an (bai)
Inside DC (Intra-DC)
DC guztiek barne-konektibitate sare berdinak dituzte Clos topologian oinarrituta.
Nolako Clos sareak dira eta zergatik daude bereizi batean .
DC bakoitzak 10 rack ditu makinekin, honela zenbatuko dira A, B, C Eta abar.
Rack bakoitzak 30 makina ditu. Ez gaituzte interesatuko.
Era berean, rack bakoitzean makina guztiak konektatuta dauden etengailu bat dago - hau da Rack-eko etengailuaren goialdea - ToR edo bestela, Clos fabrikari dagokionez, deituko diogu Leaf.
Fabrikaren eskema orokorra.
Guk deituko diegu XXX-hostoaYNon XXX - hiru letrako DC laburdura, eta Y - serie zenbakia. Adibidez, kzn-hosto11.
Nire artikuluetan Leaf eta ToR terminoak arinki sinonimo gisa erabiltzeko baimena emango diot. Hala ere, gogoratu behar dugu ez dela horrela.
ToR makinak konektatuta dauden rack batean instalatutako etengailua da.
Leaf sare fisiko batean edo lehen mailako etengailu baten eginkizuna da Cloes topologiari dagokionez.
Hau da, Hostoa != ToR.
Beraz, Leaf EndofRaw etengailu bat izan daiteke, adibidez.
Hala ere, artikulu honen esparruan oraindik sinonimo gisa tratatuko ditugu.
ToR etengailu bakoitza aldi berean lau agregazio etengailu altuagoetara konektatuta dago - bizkarrezurra. DCko rack bat esleitzen da Spinesentzat. Antzera emango diogu izena: XXX-bizkarrezurraY.
Rack berak sare-ekipoak edukiko ditu MPLS barnean duten DC - 2 bideratzaileen arteko konexiorako. Baina, oro har, Termino berberak dira. Hau da, Spine etengailuen ikuspuntutik, konektatutako makinekin edo DCIrako bideratzaile batekin ohiko ToRak ez du batere axola - birbidaltzea besterik ez.
ToR berezi horiei deitzen zaie Ertz-hostoa. Guk deituko diegu XXX-estekaY.
Honela izango da.
Goiko diagraman, ertza eta hostoa maila berean jarri ditut. Uplinking-a (hortik terminoa) goranzko lotura gisa hartzen irakatsi ziguten. Eta hemen gertatzen da DCI "gora esteka" behera egiten duela, eta horrek apur bat hausten du ohiko logika. Sare handien kasuan, datu-zentroak are unitate txikiagoetan banatzen direnean - POD's (Point Of Delivery), nabarmendu banakakoa Edge-PODDCIrako eta kanpoko sareetarako sarbidea.
Etorkizunean hautemateko erraztasuna lortzeko, oraindik ere Ertza bizkarrezurra marraztuko dut, baina kontuan izango dugu ez dagoela adimenik Bizkarrezurran eta ez dagoela desberdintasunik hosto arruntekin eta ertz-hostoarekin lan egitean (nahiz eta Γ±abardurak egon daitezkeen hemen. , baina orokorrean Hau egia da).
Ertz-hostoak dituen fabrika baten eskema.
Hosto, Bizkarrezurra eta Ertzaren hirutasunak Underlay sare edo fabrika osatzen dute.
Sareko fabrika baten zeregina (irakur ezazu Underlay), jadanik definitu dugun bezala , oso-oso sinplea - makinen artean IP konexioa eskaintzea bai DC berean bai haien artean.
Horregatik, sareari fabrika deitzen zaio, adibidez, sare modularreko kutxaren barruko konmutazio-fabrika bezala, eta horri buruz gehiago irakur dezakezun. .
Oro har, halako topologiari fabrika deitzen zaio, ehuna itzulpenean ehuna esan nahi duelako. Eta zaila da ados ez egotea:
Lantegia guztiz L3 da. Ez VLAN, ez Broadcast - LAN_DCn hain programatzaile zoragarriak ditugu, badakite L3 paradigman bizi diren aplikazioak idazten eta makina birtualek ez dute zuzeneko migrazioa behar IP helbidea gordeta.
Eta beste behin ere: zergatik fabrika eta zergatik dagoen L3 aparteko galderari erantzuna .
DCI - Data Center Interconnect (Inter-DC)
DCI Edge-Leaf erabiliz antolatuko da, hau da, gure autobiderako irteera puntua dira.
Sinpletasunerako, DCak lotura zuzenen bidez elkarren artean konektatuta daudela suposatuko dugu.
Bazter dezagun kanpoko konexioa kontuan.
Badakit osagai bat kentzen dudan bakoitzean sarea nabarmen sinplifikatzen dudala. Eta gure sare abstraktua automatizatzen dugunean, dena ondo egongo da, baina benetakoan makuluak egongo dira.
Hau egia da. Hala ere, serie honen helburua planteamenduak pentsatzea eta lantzea da, ez irudimenezko arazoak heroikoki konpontzea.
Edge-Leafs-en, azpikoa VPNan jartzen da eta MPLS bizkarrezurra bidez transmititzen da (zuzeneko esteka bera).
Hau da lortzen dugun goi-mailako diagrama.
Bideratzea
DC barruan bideratzeko BGP erabiliko dugu.
MPLS enborrean OSPF+LDP.
DCIrentzat, hau da, lurpeko konektibitatea antolatzea - ββBGP L3VPN MPLSren gainean.
Bideratze-eskema orokorra
Ez dago OSPF edo ISIS (Errusiar Federazioan debekatuta dagoen bideratze-protokolorik) fabrikan.
Horrek esan nahi du ez dela auto-aurkikuntzarik edo biderik laburrenen kalkulurik egingo - eskuzko (benetan automatikoa - automatizazioaz ari gara hemen) soilik protokoloa, auzoa eta politikak konfiguratzeko.
BGP bideratze-eskema DC barruan
Zergatik BGP?
Gai honen inguruan dago Facebook eta Arista izena du, nola eraikitzen den esaten duena oso handiak datu zentroen sareak BGP erabiliz. Ia fikzioa bezala irakurtzen da, oso gomendatzen dut arratsalde lapurreta baterako.
Eta atal oso bat ere badago horri eskainitako nire artikuluan. Nora eramaten zaitut eta .
Hala ere, laburbilduz, IGP ez da egokia datu-zentro handietako sareetarako, non sareko gailuen kopurua milaka izaten baita.
Gainera, BGP nonahi erabiltzeak hainbat protokolo ezberdin onartzen eta haien arteko sinkronizazioan denborarik ez galtzeko aukera emango du.
Eskuz bihotzean, gure lantegian, probabilitate handiarekin azkar haziko ez dena, OSPF nahikoa izango litzateke begietarako. Hauek dira benetan megascalers eta hodeiko titanen arazoak. Baina imajina dezagun argitalpen gutxi batzuetarako behar dugula, eta BGP erabiliko dugula, Pyotr Lapukhov-ek utzi zuen bezala.
Bideratze-politikak
Leaf etengailuetan, Underlay sareko interfazeetatik aurrizkiak inportatzen ditugu BGPra.
Tartean BGP saioa izango dugu bakoitzeko hosto-bizkarrezurra bikotea, zeinetan azpiko aurrizki hauek sarean han eta hemen iragarriko diren.
Datu-zentro baten barruan ToRe-ra inportatu ditugun zehaztapenak banatuko ditugu. Edge-Leafs-en bilduko ditugu eta urruneko DCei jakinaraziko dizkiegu eta TORetara bidaliko ditugu. Hau da, ToR bakoitzak zehatz-mehatz jakingo du nola iritsi DC bereko beste ToR batera eta non dagoen sarrera puntua beste DC batean ToRra iristeko.
DCIn, ibilbideak VPNv4 gisa transmitituko dira. Horretarako, Edge-Leaf-en, fabrikarako interfazea VRF batean kokatuko da, deitu dezagun UNDERLAY, eta Spine on Edge-Leaf duen auzoa igoko da VRF barruan, eta Edge-Leafs artean VPNv4-n. familia.
Era berean, debekatu egingo dugu bizkarrezurra itzultzeko jasotako ibilbideak berriro iragartzea.
Leaf eta Spine-n ez ditugu Loopback-ak inportatuko. Router IDa zehazteko bakarrik behar ditugu.
Baina Edge-Leafs-en Global BGPra inportatzen dugu. Loopback helbideen artean, Edge-Leafsek BGP saio bat ezarriko du IPv4 VPN-familian elkarrekin.
OSPF+LDP bizkarrezurra izango dugu EDGE gailuen artean. Dena zonalde batean dago. Konfigurazio oso sinplea.
Hau da bideratzearen argazkia.
BGP ASN
Ertz-Hosto ASN
Edge-Leafs-en ASN bat egongo da DC guztietan. Garrantzitsua da Edge-Leafs-en artean iBGP egotea, eta ez gara eBGPren Γ±abardurak harrapatzen. Izan bedi 65535. Egia esan, hau izan daiteke AS publiko baten zenbakia.
Bizkarrezurra ASN
Spine-n ASN bat izango dugu DC bakoitzeko. Has gaitezen hemen AS pribatuen barrutiko lehen zenbakiarekin - 64512, 64513 Eta abar.
Zergatik ASN DCn?
Bana dezagun galdera hau bitan:
- Zergatik dira berdinak ASNak DC baten bizkarrezurra guztietan?
- Zergatik dira desberdinak DC desberdinetan?
Zergatik daude ASN berdinak DC baten bizkarrezurra guztietan?
Hauxe izango da Edge-Leaf-en azpiko azpiko ibilbidearen AS-Ibilbidea:
[leafX_ASN, spine_ASN, edge_ASN]
Spine-ra iragartzen saiatzen zarenean, baztertu egingo du bere AS (Spine_AS) zerrendan dagoelako.
Hala ere, DCren barruan guztiz pozik gaude Ertzera igotzen diren Underlay bideak ezin izango direlako jaitsi. DC barruan ostalarien arteko komunikazio guztiak bizkarrezurreko mailan gertatu behar dira.
Kasu honetan, beste DC batzuen ibilbide batuek, nolanahi ere, erraz iritsiko dira ToRetara - haien AS-Path-ek ASN 65535 bakarrik izango du - AS Edge-Leafs kopurua, hor sortu baitziren.
Zergatik dira desberdinak DC desberdinetan?
Teorian, baliteke Loopback eta zenbait zerbitzu-makina birtual arrastatu behar izatea DCen artean.
Adibidez, ostalarian Route Reflector edo exekutatu egingo dugu (Virtual Network Gateway), BGP bidez TopR-rekin blokeatuko dena eta bere loopback-a iragarriko duena, DC guztietatik eskuragarri egon beharko lukeena.
Beraz, hauxe izango da bere AS-Path-a:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Eta ez luke inon ASN bikoizturik egon behar.
Hau da, Spine_DC1 eta Spine_DC2 desberdinak izan behar dute, leafX_DC1 eta leafY_DC2 bezala, horixe baita hurbiltzen ari garenera.
Seguruenik dakizuenez, ASN bikoiztuak dituzten ibilbideak onartzeko aukera ematen duten hack-ak daude begizta prebenitzeko mekanismoa izan arren (Ciscon-en baimenduta). Eta erabilera zilegiak ere baditu. Baina hau sarearen egonkortasunean izan daitekeen hutsune bat da. Eta pertsonalki pare bat aldiz erori nintzen.
Eta gauza arriskutsuak ez erabiltzeko aukera badugu, aprobetxatuko dugu.
Hosto ASN
Leaf switch bakoitzean ASN indibidual bat izango dugu sarean zehar.
Goian emandako arrazoiengatik egiten dugu: AS-Path begiztarik gabe, BGP konfigurazioa laster-markarik gabe.
Leafs-en arteko ibilbideak ondo pasa daitezen, AS-Path-ak honela izan behar du:
[leafX_ASN, spine_ASN, leafY_ASN]
non leafX_ASN eta leafY_ASN ondo egongo lirateke desberdinak izatea.
DCren arteko VNF loopback baten iragarpenaren egoerarako ere beharrezkoa da:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
4 byteko ASN bat erabiliko dugu eta Bizkarrezurreko ASNren eta Leaf switch zenbakiaren arabera sortuko dugu, hau da, honela: Bizkarrezurra_ASN.0000X.
Hau da ASNrekin egindako argazkia.
IP plana
Funtsean, honako konexio hauetarako helbideak esleitu behar ditugu:
- Azpiko sareko helbideak ToR eta makinaren artean. Sare osoan bakarrak izan behar dute, edozein makina beste edozeinekin komunikatu ahal izateko. Egokitze bikaina 10/8. Rack bakoitzeko /26 daude erreserba batekin. /19 DC eta /17 eskualde bakoitzeko esleituko ditugu.
- Lotu helbideak Leaf/Tor eta Spine artean.
Algoritmikoki esleitu nahiko nituzke, hau da, konektatu behar diren gailuen izenetatik kalkulatu.
Utzi... 169.254.0.0/16.
hots, 169.254.00X.Y/31Non X - Bizkarrezurra zenbakia, Y β P2P sarea /31.
Honek 128 bastidore eta 10 Spines gehienez abiarazteko aukera emango dizu DC-n. Estekaren helbideak DCtik DCra errepika daitezke (eta izango dira). - Bizkarrezurra-Ertza-Hostoa elkargunea azpisareetan antolatzen dugu 169.254.10X.Y/31, non zehazki berdina X - Bizkarrezurra zenbakia, Y β P2P sarea /31.
- Lotu helbideak Edge-Leaf-etik MPLS bizkarrezurrara. Hemen egoera zertxobait ezberdina da - pieza guztiak tarta batean konektatzen diren lekua, beraz, helbide berdinak berrerabiltzeak ez du funtzionatuko - hurrengo doako azpisarea hautatu behar duzu. Beraz, har dezagun oinarritzat 192.168.0.0/16 eta bertatik aterako ditugu libreak.
- Loopback helbideak. Sorta osoa emango diegu 172.16.0.0/12.
- Hostoa - /25 DC bakoitzeko - 128 rack berdinak. Eskualde bakoitzeko /23 esleituko ditugu.
- Bizkarrezurra - /28 DC bakoitzeko - 16 bizkarrezurra arte. Esleitu ditzagun /26 eskualde bakoitzeko.
- Edge-Leaf - /29 DC bakoitzeko - 8 kutxa arte. Esleitu ditzagun /27 eskualde bakoitzeko.
DCn esleitutako barruti nahikorik ez badugu (eta ez da egongo - hipereskalatzaileak garela esaten dugu), hurrengo blokea hautatu besterik ez dugu.
Hau da IP helbidea duen argazkia.
Loopback-ak:
aurrizki
Gailuaren eginkizuna
eskualde
DC
172.16.0.0/23
ertzean
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
bai
172.16.2.0/23
bizkarrezurra
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
bai
172.16.8.0/21
hosto
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
bai
Azpikoa:
aurrizki
eskualde
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
bai
Laba
Bi saltzaile. Sare bat. ADSM.
Juniper + Arista. Ubuntu. Eba zahar ona.
Miranan dagoen gure zerbitzari birtualeko baliabideen kopurua mugatua da oraindik, beraz praktikarako mugaraino sinplifikatuta dagoen sare bat erabiliko dugu.
Bi datu-zentro: Kazan eta Bartzelona.
- Bi bizkarrezurra bakoitza: Ipurua eta Arista.
- Toro bat (Hosto) bakoitzean - Juniper eta Arista, konektatutako ostalari batekin (har dezagun Cisco IOL arin bat horretarako).
- Ertz-Hosto nodo bana (oraingoz Juniper bakarrik).
- Cisco etengailu bat horiek guztiak gobernatzeko.
- Sare-koadroez gain, kontrol-makina birtual bat martxan dago. Ubuntu exekutatzen.
Gailu guztietarako sarbidea du, IPAM/DCIM sistemak, Python script mordoa, Ansible eta behar dugun beste edozer gauzatuko ditu.
sareko gailu guztiena, automatizazioa erabiliz erreproduzitzen saiatuko gara.
Ondorioa
Hori ere onartzen al da? Artikulu bakoitzaren azpian ondorio labur bat idatzi behar al dut?
Beraz, aukeratu genuen Kloz sarea DC barruan, Ekialde-Mendebalde trafiko asko espero dugulako eta ECMP nahi dugulako.
Sarea fisikoa (azpikoa) eta birtuala (gainjartzea) banatu zen. Aldi berean, gainjartzea ostalaritik abiatzen da, eta, horrela, azpiko eskakizunak sinplifikatzen ditu.
BGP aukeratu dugu sare-sareen bideratze-protokolo gisa bere eskalagarritasun eta politika malgutasunagatik.
DCI - Edge-leaf antolatzeko nodo bereiziak izango ditugu.
Bizkarrezurra OSPF+LDP izango du.
DCI MPLS L3VPNn oinarrituta ezarriko da.
P2P esteketarako, IP helbideak algoritmikoki kalkulatuko ditugu gailuen izenetan oinarrituta.
Loopback-ak esleituko ditugu gailuen eginkizunaren eta haien kokapenaren arabera sekuentzialki.
Azpiko aurrizkiak - Leaf etengailuetan bakarrik sekuentzialki haien kokapenaren arabera.
Demagun oraingoz ez dugula ekipamendurik instalatuta.
Hori dela eta, gure hurrengo pausoak sistemei gehitzea (IPAM, inbentarioa), sarbidea antolatzea, konfigurazio bat sortzea eta zabaltzea izango dira.
Hurrengo artikuluan Netbox-i buruz arituko gara - DC batean IP espazioaren inbentario eta kudeaketa sistema bat.
Eskerrik asko
- Andrey Glazkov aka @glazgoo zuzenketa eta zuzenketengatik
- Alexander Klimenko aka @v00lk zuzenketa eta edizioetarako
- Artyom Chernobay KDPVrako
Iturria: www.habr.com