Առաջին երկու հոդվածներում ես բարձրացրեցի ավտոմատացման խնդիրը և ուրվագծեցի դրա շրջանակը, երկրորդում ես նահանջ կատարեցի ցանցի վիրտուալացման մեջ, որպես ծառայությունների կազմաձևման ավտոմատացման առաջին մոտեցում:
Այժմ ժամանակն է նկարել ֆիզիկական ցանցի դիագրամը:

Եթե ​​դուք ծանոթ չեք տվյալների կենտրոնների ցանցերի ստեղծմանը, ապա ես խստորեն խորհուրդ եմ տալիս սկսել հոդվածներ նրանց մասին.

Բոլոր խնդիրները.

• 0. ADSM. Մաս Զրո. Պլանավորում
• 1. ADSM. Մաս առաջին (որը զրոյից հետո է): Ցանցի վիրտուալացում
• 2. ADSM. Մաս երկրորդ. Ցանցի դիզայն

Այս շարքում նկարագրված պրակտիկան պետք է կիրառելի լինի ցանկացած տեսակի ցանցի, ցանկացած չափի, ցանկացած տեսակի վաճառողների հետ (ոչ): Այնուամենայնիվ, անհնար է նկարագրել այս մոտեցումների կիրառման համընդհանուր օրինակ: Հետևաբար, ես կկենտրոնանամ DC ցանցի ժամանակակից ճարտարապետության վրա. Կլոզ գործարան.
Մենք կանենք DCI MPLS L3VPN-ով:

Overlay ցանցն աշխատում է հոսթից ֆիզիկական ցանցի վերևում (սա կարող է լինել OpenStack-ի VXLAN-ը կամ վոլֆրամի գործվածքը կամ որևէ այլ բան, որը պահանջում է միայն հիմնական IP կապ ցանցից):

Այս դեպքում մենք ստանում ենք ավտոմատացման համեմատաբար պարզ սցենար, քանի որ մենք ունենք բազմաթիվ սարքավորումներ, որոնք կարգավորվում են նույն ձևով:

Մենք կընտրենք գնդաձև DC վակուումում.

• Դիզայնի մեկ տարբերակ ամենուր:
• Երկու վաճառողներ, որոնք ձևավորում են ցանցի երկու հարթություն:
• Մեկ DC-ն նման է մյուսին, ինչպես երկու ոլոռը պատիճում:

Պարունակություն

• Ֆիզիկական տոպոլոգիա
• Երթուղիավորում
• IP պլան
• Լաբա
• Ամփոփում
• Օգտակար հղումներ

Թույլ տվեք, օրինակ, մեր Ծառայությունների Մատակարար LAN_DC-ին հյուրընկալել խրված վերելակներում գոյատևելու մասին ուսուցողական տեսանյութեր:

Մեգապոլիսներում սա շատ տարածված է, ուստի ձեզ հարկավոր են շատ ֆիզիկական մեքենաներ:

Նախ, ես կնկարագրեմ ցանցը մոտավորապես այնպես, ինչպես ես կցանկանայի, որ այն լիներ: Եվ հետո ես կպարզեցնեմ այն ​​լաբորատորիայի համար:

Ֆիզիկական տոպոլոգիա

Տեղանքներ

LAN_DC-ն կունենա 6 DC՝

• Ռուսաստան (RU):
  • Մոսկվա (msk)
  • Կազան (kzn)

• Իսպանիա (SP):
  • Բարսելոնա (bcn)
  • Մալագա (մկգ)

• Չինաստան (CN):
  • Շանհայ (sha)
  • Սիան (sia- ն)

Ներքին DC (Intra-DC)

Բոլոր DC-ները ունեն նույնական ներքին կապի ցանցեր՝ հիմնված Clos տոպոլոգիայի վրա:
Ինչպիսի՞ Clos ցանցեր են դրանք և ինչու են դրանք առանձին Հոդված.

Յուրաքանչյուր DC ունի 10 դարակ մեքենաներով, դրանք կհամարակալվեն որպես A, B, C Եվ այսպես շարունակ:

Յուրաքանչյուր դարակ ունի 30 մեքենա: Նրանք մեզ չեն հետաքրքրի։

Նաև յուրաքանչյուր դարակում կա անջատիչ, որին միացված են բոլոր մեքենաները Rack անջատիչի վերին մասը - ToR կամ հակառակ դեպքում, Կլոսի գործարանի մասով, կկոչենք Փեղկ.

Գործարանի ընդհանուր դիագրամ.

Մենք նրանց կկանչենք XXX- տերեւYՈրտեղ XXX - եռատառ հապավումը DC, և Y - սերիական համար. Օրինակ, կզն-տերեւ11.

Իմ հոդվածներում ես ինձ թույլ կտամ որպես հոմանիշներ օգտագործել Leaf և ToR տերմինները բավականին անլուրջ: Այնուամենայնիվ, պետք է հիշել, որ դա այդպես չէ։
ToR-ն անջատիչ է, որը տեղադրված է դարակում, որին միացված են մեքենաները:
Leaf-ը սարքի դերն է ֆիզիկական ցանցում կամ առաջին մակարդակի անջատիչի՝ Cloes տոպոլոգիայի առումով։
Այսինքն, Տերեւ != ToR.
Այսպիսով, Leaf-ը կարող է լինել EndofRaw անջատիչ, օրինակ:
Այնուամենայնիվ, այս հոդվածի շրջանակներում մենք դեռ կվերաբերվենք նրանց որպես հոմանիշների։

Յուրաքանչյուր ToR անջատիչ իր հերթին միացված է չորս ավելի բարձր մակարդակի ագրեգացիոն անջատիչների. Ողնաշարի. DC-ում մեկ դարակ հատկացված է Spines-ի համար: Նմանապես կանվանենք. XXX- ողնաշարY.

Նույն դարակը կպարունակի ցանցային սարքավորում DC - 2 երթուղիչի միջև MPLS-ով միանալու համար: Բայց, մեծ հաշվով, դրանք նույն ToR-ներն են: Այսինքն, Spine անջատիչների տեսանկյունից սովորական ToR-ը միացված մեքենաներով կամ DCI-ի համար երթուղիչով նշանակություն չունի.

Նման հատուկ ToR-ները կոչվում են Եզր-տերև. Մենք նրանց կկանչենք XXX- ծայրըY.

Այն այսպիսի տեսք կունենա.

Վերևի գծապատկերում ես իրականում դրեցի եզրն ու տերևը նույն մակարդակի վրա: Դասական եռաշերտ ցանցեր Նրանք մեզ սովորեցրել են վերբեռնումը (այստեղից էլ առաջացել է տերմինը) որպես վերին հղումներ: Եվ այստեղ պարզվում է, որ DCI «վերադարձը» հետ է իջնում, ինչը ոմանց համար փոքր-ինչ խախտում է սովորական տրամաբանությունը։ Մեծ ցանցերի դեպքում, երբ տվյալների կենտրոնները բաժանվում են նույնիսկ ավելի փոքր միավորների. POD's (Առաքման կետ), առանձնացրեք անհատականությունը Edge-PODDCI-ի և արտաքին ցանցեր մուտք գործելու համար:

Ապագայում ընկալման հեշտության համար ես դեռ կնկարեմ Edge-ը Spine-ի վրայով, մինչդեռ մենք նկատի կունենանք, որ ողնաշարի վրա ինտելեկտ չկա և չկան տարբերություններ սովորական Leaf-ի և Edge-leaf-ի հետ աշխատելիս (չնայած այստեղ կարող են լինել նրբերանգներ: , բայց ընդհանուր առմամբ Սա ճիշտ է):

Եզրային տերևներով գործարանի սխեման:

Տերեւների, ողնաշարի և եզրերի եռամիասնությունը կազմում է Underlay ցանց կամ գործարան:

Ցանցային գործարանի խնդիրը (կարդացեք Underlay), ինչպես մենք արդեն սահմանել ենք վերջին թողարկում, շատ, շատ պարզ՝ ապահովել IP կապ մեքենաների միջև ինչպես նույն DC-ում, այնպես էլ նրանց միջև:
Այդ իսկ պատճառով ցանցը կոչվում է գործարան, ինչպես, օրինակ, մոդուլային ցանցի տուփերի մեջ փոխարկվող գործարանը, որի մասին ավելին կարող եք կարդալ այստեղ ՍԴՍՄ14.

Ընդհանրապես նման տոպոլոգիան կոչվում է գործարան, քանի որ գործվածք թարգմանության մեջ նշանակում է գործվածք։ Եվ դժվար է չհամաձայնել.

Գործարանը ամբողջությամբ L3 է։ Ոչ VLAN, ոչ Broadcast. մենք ունենք այնպիսի հիանալի ծրագրավորողներ LAN_DC-ում, նրանք գիտեն, թե ինչպես գրել հավելվածներ, որոնք ապրում են L3 պարադիգմում, իսկ վիրտուալ մեքենաները չեն պահանջում Live Migration IP հասցեի պահպանմամբ:

Եվ ևս մեկ անգամ՝ հարցի պատասխանը, թե ինչու է գործարանը և ինչու L3-ը առանձին Հոդված.

DCI - տվյալների կենտրոնի փոխկապակցում (Inter-DC)

DCI-ն կկազմակերպվի Edge-Leaf-ի միջոցով, այսինքն՝ դրանք մեր ելքի կետն են դեպի մայրուղի։
Պարզության համար մենք ենթադրում ենք, որ DC-ները միմյանց հետ կապված են ուղիղ կապերով։
Դիտարկելուց բացառենք արտաքին կապը։

Ես տեղյակ եմ, որ ամեն անգամ, երբ ես հեռացնում եմ որևէ բաղադրիչ, ես զգալիորեն պարզեցնում եմ ցանցը: Իսկ երբ ավտոմատացնենք մեր աբստրակտ ցանցը, ամեն ինչ լավ կլինի, իսկ իրականի վրա հենակներ կլինեն։
Սա ճիշտ է։ Այդուհանդերձ, այս շարքի իմաստը մոտեցումների վրա մտածելն ու աշխատելն է, ոչ թե երևակայական խնդիրներ հերոսաբար լուծելը։

Edge-Leafs-ում տակդիրը տեղադրվում է VPN-ում և փոխանցվում MPLS ողնաշարի միջոցով (նույն ուղիղ հղումը):

Սա ամենաբարձր մակարդակի դիագրամն է, որը մենք ստանում ենք:

Երթուղիավորում

DC-ի ներսում երթուղիների համար մենք կօգտագործենք BGP:
MPLS միջքաղաքային OSPF+LDP-ի վրա:
DCI-ի համար, այսինքն՝ ստորգետնյա կապի կազմակերպում - BGP L3VPN MPLS-ի միջոցով:

Ընդհանուր երթուղիների սխեման

Գործարանում չկա OSPF կամ ISIS (Ռուսաստանի Դաշնությունում արգելված երթուղային արձանագրություն):

Սա նշանակում է, որ չի լինի ավտոմատ հայտնաբերում կամ ամենակարճ ուղիների հաշվարկ, միայն ձեռքով (իրականում ավտոմատ, այստեղ խոսում ենք ավտոմատացման մասին) արձանագրության, հարևանության և քաղաքականության կարգավորումը:

BGP երթուղիների սխեման DC-ում

Ինչու՞ BGP:

Այս թեմայով կա ամբողջ RFC Facebook-ի և Arista-ի անունով, որը պատմում է, թե ինչպես կարելի է կառուցել շատ մեծ տվյալների կենտրոնների ցանցեր՝ օգտագործելով BGP: Այն կարդում է գրեթե գեղարվեստական ​​գրականության պես, խորհուրդ եմ տալիս տխուր երեկոյի համար:

Եվ իմ հոդվածում կա նաև սրան նվիրված մի ամբողջ բաժին։ ուր տանեմ քեզ և ուղարկում եմ.

Սակայն, մի խոսքով, ոչ մի IGP հարմար չէ տվյալների խոշոր կենտրոնների ցանցերի համար, որտեղ ցանցային սարքերի թիվը հասնում է հազարների:

Բացի այդ, ամենուր BGP-ի օգտագործումը թույլ կտա ձեզ ժամանակ չկորցնել մի քանի տարբեր արձանագրությունների աջակցման և դրանց միջև համաժամացման վրա:

Ձեռք սրտի, մեր գործարանում, որը մեծ հավանականությամբ արագ չի աճի, OSPF-ը բավական կլիներ աչքերին։ Սրանք իրականում մեգասկանդերների և ամպի տիտանների խնդիրներն են: Բայց եկեք պատկերացնենք ընդամենը մի քանի թողարկման համար, որ դա մեզ պետք է, և մենք կօգտագործենք BGP-ն, ինչպես կտակել է Պյոտր Լապուխովը:

Ուղղորդման քաղաքականություն

Leaf անջատիչների վրա մենք ներմուծում ենք նախածանցներ Underlay ցանցային միջերեսներից BGP:
Մենք կունենանք BGP նիստի միջև յուրաքանչյուր Leaf-Spine զույգ, որում այս Underlay նախածանցները կհայտարարվեն ցանցի միջոցով այստեղ և այնտեղ:

Մեկ տվյալների կենտրոնի շրջանակներում մենք կտարածենք այն բնութագրերը, որոնք ներմուծել ենք ToRe: Edge-Leafs-ում մենք կհավաքենք դրանք և կհայտարարենք դրանք հեռավոր DC-ներին և կուղարկենք դրանք TOR-ներին: Այսինքն, յուրաքանչյուր ToR հստակ գիտի, թե ինչպես հասնել մեկ այլ ToR նույն DC-ում և որտեղ մուտքի կետն է ToR-ին հասնել մեկ այլ DC-ում:

DCI-ում երթուղիները կփոխանցվեն որպես VPNv4: Դա անելու համար, Edge-Leaf-ում, դեպի գործարան ինտերֆեյսը կտեղադրվի VRF-ում, եկեք այն անվանենք UNDERLAY, և Spine-ի Edge-Leaf-ի հետ հարևանությունը կբարձրանա VRF-ում, իսկ Edge-Leafs-ի միջև VPNv4-ում: ընտանիք.

Արգելելու ենք նաև ողնաշարից ստացված երթուղիների վերահայտարարումը դեպի իրենց։

Leaf and Spine-ի վրա մենք Loopbacks չենք ներմուծի: Նրանք մեզ պետք են միայն երթուղիչի ID-ն որոշելու համար:

Բայց Edge-Leafs-ում մենք այն ներմուծում ենք Global BGP: Loopback հասցեների միջև Edge-Leafs-ը միմյանց հետ կստեղծի BGP նիստ IPv4 VPN ընտանիքում:

Մենք կունենանք OSPF+LDP ողնաշար EDGE սարքերի միջև: Ամեն ինչ մեկ գոտում է։ Չափազանց պարզ կոնֆիգուրացիա:

Սա երթուղային պատկերն է։

BGP ASN

Edge-Leaf ASN

Edge-Leafs-ում բոլոր DC-ներում կլինի մեկ ASN: Կարևոր է, որ Edge-Leafs-ի միջև կա iBGP, և մենք չենք բռնվում eBGP-ի նրբություններին: Թող լինի 65535: Իրականում սա կարող է լինել հանրային AS-ի թիվը:

Ողնաշարի ASN

Ողնաշարի վրա մենք կունենանք մեկ ASN մեկ DC-ի համար: Սկսենք այստեղ մասնավոր ՀԾ-ների շարքից հենց առաջին համարից՝ 64512, 64513 և այլն:

Ինչու՞ ASN-ը DC-ում:

Եկեք այս հարցը բաժանենք երկու մասի.

• Ինչո՞ւ են ASN-ները նույնը մեկ DC-ի բոլոր ողնաշարի վրա:
• Ինչու են դրանք տարբեր տարբեր DC-ներում:

Ինչու են նույն ASN-ները մեկ DC-ի բոլոր ողնաշարի վրա:

Ահա, թե ինչ տեսք կունենա «Edge-Leaf»-ի Underlay երթուղու AS-ուղին.
[leafX_ASN, spine_ASN, edge_ASN]
Երբ դուք փորձում եք այն նորից գովազդել Spine-ում, այն կհրաժարվի այն, քանի որ նրա AS (Spine_AS) արդեն ցանկում է:

Այնուամենայնիվ, DC-ում մենք լիովին գոհ ենք, որ Underlay երթուղիները, որոնք բարձրանում են դեպի Edge, չեն կարողանա իջնել: DC-ի ներսում հյուրընկալողների միջև բոլոր հաղորդակցությունները պետք է տեղի ունենան ողնաշարի մակարդակում:

Այս դեպքում, այլ DC-ների ագրեգացված երթուղիները ամեն դեպքում հեշտությամբ կհասնեն ToR-ներին. նրանց AS-ուղին կունենա միայն ASN 65535՝ AS Edge-Leafs-ի թիվը, քանի որ հենց այնտեղ են ստեղծվել:

Ինչու են դրանք տարբեր տարբեր DC-ներում:

Տեսականորեն, մեզ կարող է անհրաժեշտ լինել Loopback-ը և սպասարկման որոշ վիրտուալ մեքենաներ DC-ների միջև քաշել:

Օրինակ, հոսթի վրա մենք գործարկելու ենք Route Reflector կամ նույն VNGW (Վիրտուալ ցանցի դարպաս), որը կողպվելու է TopR-ով BGP-ի միջոցով և կհայտարարի իր loopback-ը, որը պետք է հասանելի լինի բոլոր DC-ներից:

Այսպիսով, նրա AS-Path-ը նման կլինի.
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Եվ ոչ մի տեղ չպետք է լինի կրկնօրինակ ASN:

Այսինքն, Spine_DC1-ը և Spine_DC2-ը պետք է տարբեր լինեն, ճիշտ ինչպես leafX_DC1-ը և leafY_DC2-ը, ինչին մենք մոտենում ենք:

Ինչպես հավանաբար գիտեք, կան հաքեր, որոնք թույլ են տալիս ընդունել երթուղիներ կրկնակի ASN-ներով՝ չնայած հանգույցների կանխարգելման մեխանիզմին (Allowas-in Cisco-ում): Եվ դա նույնիսկ օրինական օգտագործում է: Բայց սա ցանցի կայունության պոտենցիալ բաց է: Եվ ես անձամբ մի երկու անգամ ընկել եմ դրա մեջ։

Եվ եթե մենք հնարավորություն ունենանք չօգտագործել վտանգավոր բաներ, մենք կօգտվենք դրանից։

Տերեւ ASN

Մենք կունենանք անհատական ​​ASN ցանցի յուրաքանչյուր Leaf անջատիչի վրա:
Մենք դա անում ենք վերը նշված պատճառներով՝ AS-Path առանց հանգույցների, BGP կոնֆիգուրացիա առանց էջանիշների:

Որպեսզի Leafs-ի միջև երթուղիները սահուն անցնեն, AS-Path-ը պետք է այսպիսի տեսք ունենա.
[leafX_ASN, spine_ASN, leafY_ASN]
որտեղ leafX_ASN-ը և leafY_ASN-ը հաճելի կլիներ տարբերվել:

Սա նաև պահանջվում է DC-ների միջև VNF հանգույցի հայտարարման հետ կապված իրավիճակի համար.
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Մենք կօգտագործենք 4 բայթանոց ASN և կստեղծենք այն ողնաշարի ASN-ի և Leaf switch-ի համարի հիման վրա, մասնավորապես, այսպես. Ողնաշար_ASN.0000X.

Սա ASN-ի պատկերն է։

IP պլան

Սկզբունքորեն, մենք պետք է հասցեներ հատկացնենք հետևյալ միացումների համար.

1. Ներդրեք ցանցի հասցեները ToR-ի և մեքենայի միջև: Նրանք պետք է եզակի լինեն ամբողջ ցանցում, որպեսզի ցանկացած մեքենա կարողանա շփվել ցանկացած այլ մեքենայի հետ: Հիանալի տեղավորում 10/8. Յուրաքանչյուր դարակի համար կա /26 ռեզերվով։ Մենք կհատկացնենք /19 մեկ DC-ի և /17 յուրաքանչյուր տարածաշրջանի համար:
2. Կապեք հասցեները Leaf/Tor-ի և Spine-ի միջև:

   Կցանկանայի դրանք վերագրել ալգորիթմորեն, այսինքն՝ հաշվարկել այն սարքերի անուններից, որոնք պետք է միացվեն։

   Թող լինի... 169.254.0.0/16.
   Այսինքն 169.254.00X.Y/31Որտեղ X - ողնաշարի համարը, Y — P2P ցանց /31.
   Սա թույլ կտա գործարկել մինչև 128 դարակ և մինչև 10 ողնաշար DC-ում: Հղման հասցեները կարող են (և կկրկնվեն) DC-ից մինչև DC:

3. Մենք կազմակերպում ենք Spine-Edge-Leaf հանգույցը ենթացանցերում 169.254.10X.Y/31, որտեղ ճիշտ նույնը X - ողնաշարի համարը, Y — P2P ցանց /31.
4. Կապեք հասցեները Edge-Leaf-ից ​​MPLS մայրուղային: Այստեղ իրավիճակը փոքր-ինչ այլ է. այն վայրը, որտեղ բոլոր կտորները միացված են մեկ կարկանդակի մեջ, այնպես որ նույն հասցեները նորից օգտագործելը չի ​​աշխատի, դուք պետք է ընտրեք հաջորդ անվճար ենթացանցը: Հետևաբար, հիմք ընդունենք 192.168.0.0/16 և մենք դրանից կհանենք անվճարներին:
5. Loopback հասցեներ. Մենք կտանք ամբողջ տեսականին նրանց համար 172.16.0.0/12.
   • Տերեւ - /25 մեկ DC - նույնը 128 դարակաշարեր: Տարածաշրջանին կտրամադրենք /23.
   • Ողնաշար - /28 մեկ DC - մինչև 16 Ողնաշար: Հատկացնենք /26 մեկ մարզին։
   • Edge-Leaf - /29 մեկ DC - մինչև 8 տուփ: Տարածաշրջանին հատկացնենք /27.

Եթե ​​մենք չունենք բավարար հատկացված միջակայքեր DC-ում (և չեն լինի, մենք պնդում ենք, որ մենք հիպերսանդղակավորողներ ենք), մենք պարզապես ընտրում ենք հաջորդ բլոկը:

Սա IP հասցեով նկարն է։

Loopbacks:

Նախածանց
Սարքի դերը
Մարզ
DC

172.16.0.0/23
գագաթ
 
 

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
մկգ

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
sia- ն

172.16.2.0/23
կռնակ
 
 

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
մկգ

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
sia- ն

172.16.8.0/21
տերեվ
 
 

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
մկգ

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
sia- ն

Ներքնաշերտ:

Նախածանց
Մարզ
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
մկգ

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
sia- ն

Լաբա

Երկու վաճառող. Մեկ ցանց. ADSM.

Juniper + Arista. Ubuntu. Բարի հին Եվա:

Միրանայում մեր վիրտուալ սերվերի ռեսուրսների քանակը դեռևս սահմանափակ է, ուստի պրակտիկայի համար մենք կօգտագործենք մինչև սահմանը պարզեցված ցանց:

Երկու տվյալների կենտրոն՝ Կազան և Բարսելոնա:

• Երկու ողնաշար՝ գիհի և Արիստա:
• Մեկական տորուս (Տերև) յուրաքանչյուրում՝ Juniper և Arista, մեկ կապակցված հյուրընկալողով (եկեք վերցնենք թեթև Cisco IOL դրա համար):
• Յուրաքանչյուր Edge-Leaf հանգույց (առայժմ միայն Juniper):
• Մեկ Cisco անջատիչ՝ բոլորին կառավարելու համար:
• Ցանցային տուփերից բացի, աշխատում է վիրտուալ կառավարման մեքենա: Աշխատում է Ubuntu-ն:
  Այն հասանելի է բոլոր սարքերին, այն կաշխատի IPAM/DCIM համակարգեր, Python-ի մի շարք սկրիպտներ, Ansible և ցանկացած այլ բան, որը մեզ կարող է անհրաժեշտ լինել:

Ամբողջական կոնֆիգուրացիա բոլոր ցանցային սարքերից, որոնք մենք կփորձենք վերարտադրել ավտոմատացման միջոցով:

Ամփոփում

Դա էլ է ընդունվու՞մ։ Կարճ եզրակացություն գրե՞մ յուրաքանչյուր հոդվածի տակ:

Այսպիսով, մենք ընտրեցինք եռաստիճան Kloz ցանցը DC-ի ներսում, քանի որ մենք ակնկալում ենք շատ Արևելք-Արևմուտք տրաֆիկ և ցանկանում ենք ECMP:

Ցանցը բաժանված էր ֆիզիկական (ներքև) և վիրտուալ (վերածման): Միևնույն ժամանակ, ծածկույթը սկսվում է հյուրընկալողից՝ դրանով իսկ պարզեցնելով ներքևի մասի պահանջները:

Մենք ընտրեցինք BGP-ն որպես ցանցային ցանցերի երթուղային արձանագրություն՝ իր մասշտաբայնության և քաղաքականության ճկունության համար:

Մենք կունենանք DCI կազմակերպման առանձին հանգույցներ՝ Edge-leaf։
ողնաշարը կունենա OSPF+LDP:
DCI-ն կիրականացվի MPLS L3VPN-ի հիման վրա:
P2P հղումների համար մենք կհաշվարկենք IP հասցեները ալգորիթմորեն՝ հիմնվելով սարքերի անունների վրա:
Մենք հաջորդաբար կնշանակենք loopbacks՝ ըստ սարքերի դերի և գտնվելու վայրի:
Ներքևի նախածանցներ - միայն Leaf անջատիչների վրա, որոնք հաջորդաբար հիմնված են իրենց գտնվելու վայրի վրա:

Ենթադրենք, որ այս պահին մենք դեռ սարքավորումներ չունենք տեղադրված։
Հետևաբար, մեր հաջորդ քայլերը կլինեն դրանք համակարգերին ավելացնելը (IPAM, գույքագրում), մուտքի կազմակերպումը, կոնֆիգուրացիա ստեղծելը և այն տեղակայելը:

Հաջորդ հոդվածում մենք կզբաղվենք Netbox-ի հետ՝ գույքագրման և կառավարման համակարգ DC-ում IP տարածքի համար:

Շնորհակալություն

• Անդրեյ Գլազկով՝ @glazgoo՝ սրբագրման և ուղղումների համար
• Ալեքսանդր Կլիմենկոն՝ @v00lk՝ սրբագրման և խմբագրման համար
• Արտյոմ Չեռնոբայը KDPV-ի համար

Source: www.habr.com