Sa unang dalawang artikulo, itinaas ko ang isyu ng automation at inilarawan ang balangkas nito, sa pangalawa ay gumawa ako ng retreat sa virtualization ng network, bilang unang diskarte sa pag-automate ng pagsasaayos ng mga serbisyo.
Ngayon ay oras na upang gumuhit ng isang diagram ng pisikal na network.

Kung hindi ka pamilyar sa pag-set up ng mga network ng data center, lubos kong inirerekomenda na magsimula sa mga artikulo tungkol sa kanila.

Lahat ng isyu:

• 0. ADSM. Bahagi Zero. Pagpaplano
• 1. ADSM. Unang bahagi (na pagkatapos ng zero). Virtualization ng network
• 2. ADSM. Ikalawang bahagi. Disenyo ng network

Ang mga kasanayang inilalarawan sa seryeng ito ay dapat na naaangkop sa anumang uri ng network, anumang laki, sa anumang iba't ibang vendor (hindi). Gayunpaman, imposibleng ilarawan ang isang pangkalahatang halimbawa ng aplikasyon ng mga pamamaraang ito. Samakatuwid, ako ay tumutuon sa modernong arkitektura ng DC network: Pabrika ng Kloz.
Gagawin namin ang DCI sa MPLS L3VPN.

Ang isang Overlay network ay tumatakbo sa ibabaw ng pisikal na network mula sa host (ito ay maaaring ang OpenStack's VXLAN o Tungsten Fabric o anumang bagay na nangangailangan lamang ng basic IP connectivity mula sa network).

Sa kasong ito, nakakakuha kami ng medyo simpleng senaryo para sa automation, dahil marami kaming kagamitan na naka-configure sa parehong paraan.

Pipili kami ng isang spherical DC sa isang vacuum:

• Isang bersyon ng disenyo sa lahat ng dako.
• Dalawang vendor na bumubuo ng dalawang network plane.
• Ang isang DC ay parang isa pang parang dalawang gisantes sa isang pod.

nilalaman

• Pisikal na topolohiya
• Pagruruta
• IP plan
• Laba
• Konklusyon
• Kapaki-pakinabang na mga link

Hayaan ang aming Service Provider na LAN_DC, halimbawa, na mag-host ng mga video ng pagsasanay tungkol sa pag-survive sa mga naka-stuck na elevator.

Sa megacities ito ay napakapopular, kaya kailangan mo ng maraming pisikal na makina.

Una, ilalarawan ko ang network nang humigit-kumulang sa gusto ko. At pagkatapos ay pasimplehin ko ito para sa lab.

Pisikal na topolohiya

Mga lokasyon

Ang LAN_DC ay magkakaroon ng 6 na DC:

• Russia (RU):
  • Moscow (msk)
  • Kazan (kzn)

• Espanya (SP):
  • Barcelona (bcn)
  • Malaga (MLG)

• Tsina (CN):
  • Shanghai (Sha)
  • Xi'an (kapwa)

Sa loob ng DC (Intra-DC)

Ang lahat ng DC ay may magkaparehong panloob na mga network ng koneksyon batay sa Clos topology.
Anong uri ng mga Clos network sila at bakit sila nasa hiwalay Artikulo.

Ang bawat DC ay may 10 rack na may mga makina, sila ay mabibilang bilang A, B, C At iba pa.

Ang bawat rack ay may 30 makina. Hindi nila tayo magiging interesante.

Gayundin sa bawat rack mayroong isang switch kung saan ang lahat ng mga makina ay konektado - ito ay Itaas ng switch ng Rack - ToR o kung hindi, sa mga tuntunin ng pabrika ng Clos, tatawagin namin ito Dahon.

Pangkalahatang diagram ng pabrika.

Tatawagan natin sila XXX-tinapayYSaan XXX - tatlong-titik na pagdadaglat DC, at Y - serial number. Halimbawa, kzn-leaf11.

Sa aking mga artikulo ay hahayaan ko ang aking sarili na gamitin ang mga terminong Leaf at ToR sa halip na walang kabuluhan bilang mga kasingkahulugan. Gayunpaman, dapat nating tandaan na hindi ito ang kaso.
Ang ToR ay isang switch na naka-install sa isang rack kung saan nakakonekta ang mga makina.
Ang dahon ay ang papel ng isang device sa isang pisikal na network o isang switch sa unang antas sa mga tuntunin ng topology ng Cloes.
Iyon ay, Dahon != ToR.
Kaya ang Leaf ay maaaring maging isang EndofRaw switch, halimbawa.
Gayunpaman, sa loob ng balangkas ng artikulong ito ay ituturing pa rin namin ang mga ito bilang mga kasingkahulugan.

Ang bawat ToR switch ay konektado naman sa apat na mas mataas na antas ng aggregation switch - gulugod. Isang rack sa DC ang inilalaan para sa Spines. Papangalanan natin ito nang magkatulad: XXX-gulugodY.

Ang parehong rack ay maglalaman ng kagamitan sa network para sa pagkakakonekta sa pagitan ng DC - 2 na mga router na may nakasakay na MPLS. Ngunit sa pangkalahatan, ang mga ito ay parehong mga ToR. Iyon ay, mula sa punto ng view ng mga switch ng Spine, ang karaniwang ToR na may mga konektadong makina o isang router para sa DCI ay hindi mahalaga sa lahat - pagpapasa lamang.

Ang ganitong mga espesyal na ToR ay tinatawag gilid-dahon. Tatawagan natin sila XXX-pagtaposY.

Magiging ganito.

Sa diagram sa itaas, talagang inilagay ko ang gilid at dahon sa parehong antas. Mga klasikong tatlong-layer na network Itinuro nila sa amin na isaalang-alang ang uplinking (kaya ang termino) bilang mga uplink. At dito lumalabas na ang "uplink" ng DCI ay bumabalik, na para sa ilan ay bahagyang sumisira sa karaniwang lohika. Sa kaso ng malalaking network, kapag ang mga data center ay nahahati sa mas maliliit na unit - Supot ng buto's (Point Of Delivery), i-highlight ang indibidwal Edge-PODPara sa DCI at access sa mga panlabas na network.

Para sa kadalian ng pang-unawa sa hinaharap, iguguhit ko pa rin ang Edge sa ibabaw ng Spine, habang isaisip natin na walang katalinuhan sa Spine at walang mga pagkakaiba kapag nagtatrabaho sa regular na Leaf at Edge-leaf (bagaman maaaring may mga nuances dito , ngunit sa pangkalahatan Ito ay totoo).

Scheme ng isang pabrika na may Edge-leafs.

Ang trinity ng Leaf, Spine at Edge ay bumubuo ng isang Underlay network o factory.

Ang gawain ng isang network factory (basahin ang Underlay), gaya ng natukoy na namin sa huling isyu, napaka, napakasimple - upang magbigay ng koneksyon sa IP sa pagitan ng mga makina sa parehong DC at sa pagitan ng mga ito.
Iyon ang dahilan kung bakit ang network ay tinatawag na isang pabrika, tulad ng, halimbawa, isang lumilipat na pabrika sa loob ng mga kahon ng modular network, na maaari mong basahin nang higit pa tungkol sa SDSM14.

Sa pangkalahatan, ang naturang topology ay tinatawag na isang pabrika, dahil ang tela sa pagsasalin ay nangangahulugang tela. At mahirap hindi sumang-ayon:

Ang pabrika ay ganap na L3. Walang VLAN, walang Broadcast - mayroon kaming napakagandang programmer sa LAN_DC, alam nila kung paano magsulat ng mga application na nakatira sa L3 paradigm, at ang mga virtual machine ay hindi nangangailangan ng Live Migration na may pangangalaga sa IP address.

At muli: ang sagot sa tanong kung bakit ang pabrika at kung bakit nasa hiwalay ang L3 Artikulo.

DCI - Data Center Interconnect (Inter-DC)

Aayusin ang DCI gamit ang Edge-Leaf, ibig sabihin, sila ang ating exit point sa highway.
Para sa pagiging simple, ipinapalagay namin na ang mga DC ay konektado sa isa't isa sa pamamagitan ng mga direktang link.
Huwag nating isama ang panlabas na koneksyon sa pagsasaalang-alang.

Alam kong sa tuwing mag-aalis ako ng isang bahagi, lubos kong pinapasimple ang network. At kapag na-automate namin ang aming abstract network, magiging maayos ang lahat, ngunit sa totoong isa ay magkakaroon ng mga saklay.
Ito ay totoo. Gayunpaman, ang punto ng seryeng ito ay mag-isip at gumawa ng mga diskarte, hindi upang malutas ang mga haka-haka na problema.

Sa Edge-Leafs, ang underlay ay inilalagay sa VPN at ipinadala sa pamamagitan ng MPLS backbone (ang parehong direktang link).

Ito ang top-level na diagram na nakukuha namin.

Pagruruta

Para sa pagruruta sa loob ng DC gagamitin namin ang BGP.
Sa MPLS trunk OSPF+LDP.
Para sa DCI, iyon ay, pag-aayos ng koneksyon sa ilalim ng lupa - BGP L3VPN sa MPLS.

Pangkalahatang routing scheme

Walang OSPF o ISIS (routing protocol na ipinagbabawal sa Russian Federation) sa pabrika.

Nangangahulugan ito na hindi magkakaroon ng Auto-discovery o pagkalkula ng pinakamaikling landas - manual lang (talagang awtomatiko - pinag-uusapan natin ang tungkol sa automation dito) sa pagse-set up ng protocol, kapitbahayan at mga patakaran.

BGP routing scheme sa loob ng DC

Bakit BGP?

Sa paksang ito mayroong buong RFC ipinangalan sa Facebook at Arista, na nagsasabi kung paano bumuo Napakalaki mga network ng data center gamit ang BGP. Ito ay nagbabasa halos tulad ng fiction, lubos kong inirerekomenda ito para sa isang malamlam na gabi.

At mayroon ding isang buong seksyon sa aking artikulo na nakatuon dito. Saan kita dadalhin at nagpapadala ako.

Ngunit gayon pa man, sa madaling salita, walang IGP ang angkop para sa mga network ng malalaking data center, kung saan ang bilang ng mga network device ay umaabot sa libo-libo.

Bilang karagdagan, ang paggamit ng BGP sa lahat ng dako ay magbibigay-daan sa iyo na huwag mag-aksaya ng oras sa pagsuporta sa ilang iba't ibang mga protocol at pag-synchronize sa pagitan ng mga ito.

Kamay sa puso, sa aming pabrika, na may mataas na antas ng posibilidad na hindi mabilis na lalago, ang OSPF ay magiging sapat para sa mga mata. Ito talaga ang mga problema ng mga megascaler at cloud titans. Ngunit isipin natin para lamang sa ilang release na kailangan natin ito, at gagamitin natin ang BGP, gaya ng ipinamana ni Pyotr Lapukhov.

Mga Patakaran sa Pagruruta

Sa mga switch ng Leaf, nag-i-import kami ng mga prefix mula sa mga interface ng Underlay na network sa BGP.
Magkakaroon tayo ng BGP session sa pagitan bawat isa isang pares ng Leaf-Spine, kung saan ang mga underlay na prefix na ito ay iaanunsyo sa network dito at doon.

Sa loob ng isang data center, ibabahagi namin ang mga detalye na na-import namin sa ToRe. Sa Edge-Leafs, pagsasama-samahin namin ang mga ito at iaanunsyo ang mga ito sa mga malalayong DC at ipapadala ang mga ito sa mga TOR. Ibig sabihin, eksaktong malalaman ng bawat ToR kung paano makarating sa isa pang ToR sa parehong DC at kung saan ang entry point para makarating sa ToR sa ibang DC.

Sa DCI, ang mga ruta ay ipapadala bilang VPNv4. Upang gawin ito, sa Edge-Leaf, ang interface patungo sa factory ay ilalagay sa isang VRF, tawagin natin itong UNDERLAY, at ang neighborhood na may Spine on Edge-Leaf ay tataas sa loob ng VRF, at sa pagitan ng Edge-Leafs sa VPNv4- pamilya.

Ipagbabawal din namin ang muling pag-anunsyo ng mga rutang natanggap mula sa mga spine pabalik sa kanila.

Sa Leaf and Spine hindi kami mag-i-import ng Loopbacks. Kailangan lang namin silang matukoy ang Router ID.

Ngunit sa Edge-Leafs ini-import namin ito sa Global BGP. Sa pagitan ng mga Loopback address, ang Edge-Leafs ay magtatatag ng isang BGP session sa IPv4 VPN-pamilya sa isa't isa.

Magkakaroon tayo ng OSPF+LDP backbone sa pagitan ng mga EDGE device. Ang lahat ay nasa isang zone. Napakasimpleng pagsasaayos.

Ito ang larawan na may routing.

BGP ASN

Edge-Leaf ASN

Sa Edge-Leafs magkakaroon ng isang ASN sa lahat ng DC. Mahalaga na mayroong iBGP sa pagitan ng Edge-Leafs, at hindi tayo nahuhuli sa mga nuances ng eBGP. Hayaan itong maging 65535. Sa katotohanan, maaaring ito ang bilang ng isang pampublikong AS.

gulugod ASN

Sa Spine magkakaroon tayo ng isang ASN bawat DC. Magsimula tayo dito sa pinakaunang numero mula sa hanay ng pribadong AS - 64512, 64513 At iba pa.

Bakit ASN sa DC?

Hatiin natin ang tanong na ito sa dalawa:

• Bakit pareho ang mga ASN sa lahat ng mga spine ng isang DC?
• Bakit sila naiiba sa iba't ibang mga DC?

Bakit pareho ang mga ASN sa lahat ng mga spine ng isang DC?

Ito ang magiging hitsura ng AS-Path ng Underlay na ruta sa Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Kapag sinubukan mong i-advertise ito pabalik sa Spine, itatapon nito dahil ang AS (Spine_AS) nito ay nasa listahan na.

Gayunpaman, sa loob ng DC lubos kaming nasiyahan na ang mga rutang Underlay na umakyat sa Edge ay hindi makakababa. Ang lahat ng komunikasyon sa pagitan ng mga host sa loob ng DC ay dapat mangyari sa loob ng antas ng gulugod.

Sa kasong ito, ang mga pinagsama-samang ruta ng iba pang mga DC ay madaling maabot ang mga ToR - ang kanilang AS-Path ay magkakaroon lamang ng ASN 65535 - ang bilang ng mga AS Edge-Leaf, dahil doon sila nilikha.

Bakit sila naiiba sa iba't ibang mga DC?

Sa teoryang, maaaring kailanganin nating i-drag ang Loopback at ilang mga virtual machine ng serbisyo sa pagitan ng mga DC.

Halimbawa, sa host tatakbo kami ng Route Reflector o ang parehong VNGW (Virtual Network Gateway), na magla-lock sa TopR sa pamamagitan ng BGP at iaanunsyo ang loopback nito, na dapat ma-access mula sa lahat ng DC.

Kaya ito ang magiging hitsura ng AS-Path nito:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

At dapat walang duplicate na ASN kahit saan.

Iyon ay, ang Spine_DC1 at Spine_DC2 ay dapat na magkaiba, tulad ng leafX_DC1 at leafY_DC2, na eksakto kung ano ang aming papalapit.

Tulad ng malamang na alam mo, may mga hack na nagpapahintulot sa iyo na tumanggap ng mga ruta na may mga duplicate na ASN sa kabila ng mekanismo ng pag-iwas sa loop (allowas-in sa Cisco). At mayroon pa itong mga lehitimong gamit. Ngunit ito ay isang potensyal na puwang sa katatagan ng network. At personal akong nahulog dito ng ilang beses.

At kung may pagkakataon tayong hindi gumamit ng mga mapanganib na bagay, sasamantalahin natin ito.

Dahon ASN

Magkakaroon tayo ng indibidwal na ASN sa bawat Leaf switch sa buong network.
Ginagawa namin ito para sa mga kadahilanang ibinigay sa itaas: AS-Path na walang mga loop, configuration ng BGP na walang mga bookmark.

Para sa mga ruta sa pagitan ng Leafs na dumaan nang maayos, ang AS-Path ay dapat magmukhang ganito:
[leafX_ASN, spine_ASN, leafY_ASN]
kung saan ang leafX_ASN at leafY_ASN ay magiging maganda na maging iba.

Ito ay kinakailangan din para sa sitwasyon na may anunsyo ng isang VNF loopback sa pagitan ng mga DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Gagamit kami ng 4-byte na ASN at bubuo ito batay sa ASN ng Spine at sa Leaf switch number, katulad nito: Spine_ASN.0000X.

Ito ang larawan kasama si ASN.

IP plan

Sa pangunahin, kailangan nating maglaan ng mga address para sa mga sumusunod na koneksyon:

1. I-underlay ang mga address ng network sa pagitan ng ToR at machine. Dapat na natatangi ang mga ito sa loob ng buong network upang ang anumang makina ay maaaring makipag-ugnayan sa iba. Mahusay na akma 10/8. Para sa bawat rack mayroong /26 na may reserba. Maglalaan kami ng /19 bawat DC at /17 bawat rehiyon.
2. I-link ang mga address sa pagitan ng Leaf/Tor at Spine.

   Gusto kong italaga ang mga ito ayon sa algorithm, iyon ay, kalkulahin ang mga ito mula sa mga pangalan ng mga device na kailangang konektado.

   Hayaan mo na... 169.254.0.0/16.
   Namos 169.254.00X.Y/31Saan X - Numero ng gulugod, Y — P2P network /31.
   Papayagan ka nitong maglunsad ng hanggang 128 rack, at hanggang 10 Spine sa DC. Ang mga link address ay maaaring (at ay) ulitin mula DC hanggang DC.

3. Inayos namin ang Spine-Edge-Leaf junction sa mga subnet 169.254.10X.Y/31, kung saan eksaktong pareho X - Numero ng gulugod, Y — P2P network /31.
4. I-link ang mga address mula sa Edge-Leaf patungo sa backbone ng MPLS. Narito ang sitwasyon ay medyo naiiba - ang lugar kung saan ang lahat ng mga piraso ay konektado sa isang pie, kaya ang muling paggamit ng parehong mga address ay hindi gagana - kailangan mong piliin ang susunod na libreng subnet. Samakatuwid, kunin natin bilang batayan 192.168.0.0/16 at aalisin namin ang mga libre mula dito.
5. Mga Address ng Loopback. Ibibigay namin ang buong hanay para sa kanila 172.16.0.0/12.
   • Dahon - /25 bawat DC - ang parehong 128 rack. Maglalaan kami ng /23 bawat rehiyon.
   • Spine - /28 bawat DC - hanggang 16 Spine. Ilaan natin ang /26 bawat rehiyon.
   • Edge-Leaf - /29 bawat DC - hanggang 8 kahon. Ilaan natin ang /27 bawat rehiyon.

Kung wala kaming sapat na mga nakalaan na hanay sa DC (at hindi magkakaroon - inaangkin naming mga hyperscaler), pipiliin lang namin ang susunod na bloke.

Ito ang larawang may IP addressing.

Mga loopback:

Awitan
Tungkulin ng device
Rehiyon
ДЦ

172.16.0.0/23
gilid
 
 

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
kapwa

172.16.2.0/23
tinik
 
 

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
kapwa

172.16.8.0/21
dahon
 
 

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
kapwa

Underlay:

Awitan
Rehiyon
ДЦ

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
kapwa

Laba

Dalawang vendor. Isang network. ADSM.

Juniper + Arista. Ubuntu. Magandang matandang Eve.

Ang halaga ng mga mapagkukunan sa aming virtual server sa Mirana ay limitado pa rin, kaya para sa pagsasanay ay gagamit kami ng isang network na pinasimple hanggang sa limitasyon.

Dalawang data center: Kazan at Barcelona.

• Dalawang spines bawat isa: Juniper at Arista.
• Isang torus (Leaf) sa bawat isa - Juniper at Arista, na may isang konektadong host (kumuha tayo ng isang magaan na Cisco IOL para dito).
• Isang Edge-Leaf node bawat isa (sa ngayon ay Juniper lang).
• Isang Cisco switch para pamunuan silang lahat.
• Bilang karagdagan sa mga kahon ng network, tumatakbo ang isang virtual control machine. Nagpapatakbo ng Ubuntu.
  Mayroon itong access sa lahat ng device, tatakbo ito ng mga IPAM/DCIM system, isang grupo ng mga script ng Python, Ansible at anumang bagay na maaaring kailanganin natin.

Buong configuration ng lahat ng device sa network, na susubukan naming kopyahin gamit ang automation.

Konklusyon

Tanggap din ba yun? Dapat ba akong magsulat ng maikling konklusyon sa ilalim ng bawat artikulo?

Kaya pinili namin tatlong antas Kloz network sa loob ng DC, dahil inaasahan namin ang maraming trapiko sa East-West at gusto namin ang ECMP.

Ang network ay nahahati sa pisikal (underlay) at virtual (overlay). Kasabay nito, ang overlay ay nagsisimula mula sa host - sa gayon ay pinapasimple ang mga kinakailangan para sa underlay.

Pinili namin ang BGP bilang routing protocol para sa mga network network para sa scalability at flexibility ng patakaran nito.

Magkakaroon kami ng hiwalay na mga node para sa pag-aayos ng DCI - Edge-leaf.
Ang backbone ay magkakaroon ng OSPF+LDP.
Ipapatupad ang DCI batay sa MPLS L3VPN.
Para sa mga link ng P2P, kakalkulahin namin ang mga IP address ayon sa algorithm batay sa mga pangalan ng device.
Magtatalaga kami ng mga loopback ayon sa tungkulin ng mga device at lokasyon ng mga ito nang sunud-sunod.
Mga underlay na prefix - lamang sa mga switch ng Leaf nang sunud-sunod batay sa kanilang lokasyon.

Ipagpalagay natin na sa ngayon ay wala pa tayong naka-install na kagamitan.
Samakatuwid, ang aming mga susunod na hakbang ay ang idagdag ang mga ito sa mga system (IPAM, imbentaryo), ayusin ang pag-access, bumuo ng configuration at i-deploy ito.

Sa susunod na artikulo ay haharapin natin ang Netbox - isang imbentaryo at sistema ng pamamahala para sa espasyo ng IP sa isang DC.

Salamat

• Andrey Glazkov aka @glazgoo para sa pag-proofread at pagwawasto
• Alexander Klimenko aka @v00lk para sa pag-proofread at pag-edit
• Artyom Chernobay para sa KDPV

Pinagmulan: www.habr.com