Биринчи эки макалада мен автоматташтыруу маселесин козгоп, анын негизин тактадым, экинчисинде кызматтардын конфигурациясын автоматташтыруунун биринчи ыкмасы катары тармакты виртуалдаштырууга чегиндим.
Эми физикалык тармактын диаграммасын тартууга убакыт келди.

Эгер сиз маалымат борборунун тармактарын орнотуу менен тааныш эмес болсоңуз, анда мен баштоону сунуштайм алар жөнүндө макалалар.

Бардык маселелер:

• 0. ADSM. Part Zero. Пландоо
• 1. ADSM. Биринчи бөлүк (нөлдөн кийин). Тармакты виртуалдаштыруу
• 2. ADSM. Экинчи бөлүм. Тармак дизайны

Бул катарда сүрөттөлгөн практикалар тармактын каалаган түрүнө, каалаган өлчөмдө жана сатуучулардын ар кандай түрлөрүнө карата колдонулушу керек (жок). Бирок, бул ыкмаларды колдонуунун универсалдуу мисалын сүрөттөп берүү мүмкүн эмес. Ошондуктан, мен DC тармагынын заманбап архитектурасына басым жасайм: Клоз фабрикасы.
Биз MPLS L3VPN боюнча DCI жасайбыз.

Overlay тармагы хосттон физикалык тармактын үстүндө иштейт (бул OpenStackтин VXLAN же Tungsten Fabric же тармактан негизги IP байланышын гана талап кылган башка нерсе болушу мүмкүн).

Бул учурда биз автоматташтыруу үчүн салыштырмалуу жөнөкөй сценарийди алабыз, анткени бизде ушундай эле конфигурацияланган көптөгөн жабдуулар бар.

Биз вакуумда сфералык DC тандайбыз:

• Бардык жерде бир дизайн версиясы.
• Эки сатуучу эки тармак учакты түзөт.
• Бир ДК экинчисине окшоп, эки буурчак кабыкчасына окшош.

ыраазы

• Физикалык топология
• Маршруттоо
• IP планы
• Laba
• жыйынтыктоо
• Пайдалуу шилтемелер

Мисалы, LAN_DC Кызмат Провайдерибиз тыгылып калган лифттерде аман калуу боюнча тренинг видеолорун өткөрсүн.

Мегаполистерде бул абдан популярдуу, ошондуктан сизге көптөгөн физикалык машиналар керек.

Биринчиден, мен тармакты болжол менен мен каалагандай сүрөттөп берем. Анан мен аны лаборатория үчүн жөнөкөйлөтөм.

Физикалык топология

жер

LAN_DCде 6 DC болот:

• Орусия (RU):
  • Москва (msk)
  • Казан (kzn)

• Испания (SP):
  • Барселона (bcn)
  • Малага (MLG)

• Кытай (CN):
  • Шанхай (Бааша)
  • Сиань (SIA)

DC ичинде (Intra-DC)

Бардык DCs Clos топологиясына негизделген бирдей ички туташуу тармактарына ээ.
Алар кандай Clos тармактары жана эмне үчүн алар өзүнчө макала.

Ар бир DC машиналары менен 10 стеллаждар бар, алар катары номерленет A, B, C Ал эми чындыгында андай эмес.

Ар бир стеллажда 30дан машина бар. Алар бизди кызыктырбайт.

Ошондой эле ар бир стойкада бардык машиналар туташкан өчүргүч бар - бул Рактын үстү алмаштыргыч - ToR же болбосо, Clos заводунун шартында, биз аны чакырабыз жалбырак.

Заводдун жалпы схемасы.

Биз аларды чакырабыз XXX- жалбыракYкайда XXX - үч тамгадан турган аббревиатура DC, жана Y - сериялык саны. Мисалы, kzn-leaf11.

Мен өзүмдүн макалаларымда Leaf жана ToR терминдерин синонимдер катары колдонууга уруксат берем. Бирок, бул андай эмес экенин эстен чыгарбашыбыз керек.
ToR – бул машиналар туташтырылган стеллажга орнотулган өчүргүч.
Жалбырак – бул физикалык тармактагы түзүлүштүн ролу же Cloes топологиясы боюнча биринчи деңгээлдеги коммутатор.
Башкача айтканда, Leaf != ToR.
Ошентип, Leaf, мисалы, EndofRaw алмаштыргыч болушу мүмкүн.
Бирок, бул макаланын алкагында биз дагы эле аларды синонимдер катары карайбыз.

Ар бир ToR өчүргүч өз кезегинде төрт жогорку деңгээлдеги агрегаттык өчүргүчтөр менен туташкан - арка. DC бир стойка Spines үчүн бөлүнгөн. Биз аны ушундай эле атайбыз: XXX- омурткаY.

Ошол эле стеллажда DC - 2 роутерлердин бортунда MPLS менен туташуу үчүн тармактык жабдуулар болот. Бирок жалпысынан алганда, булар бир эле ТоР. Башкача айтканда, Spine өчүргүчтөрүнүн көз карашынан алганда, туташкан машиналары бар кадимки ToR же DCI үчүн роутер эч кандай мааниге ээ эмес - жөн гана жөнөтүү.

Мындай атайын ТоР деп аталат Edge-жалбырак. Биз аларды чакырабыз XXX-кырY.

Бул ушундай болот.

Жогорудагы диаграммада мен чындыгында четин жана жалбыракты бирдей деңгээлде койдум. Классикалык үч катмарлуу тармактар Алар бизге uplinking (демек, бул термин) uplinks катары кароого үйрөтүштү. Бул жерде DCI "жогорулатуу" кайра түшүп кетет, бул кээ бирлери үчүн кадимки логиканы бир аз бузат. Чоң тармактарда, маалымат борборлору дагы кичине бирдиктерге бөлүнгөндө - Гадылбек's (Point Of Delivery), индивидуалды белгилеңиз Edge-PODDCI жана тышкы тармактарга кирүү үчүн.

Для удобства восприятия в дальнейшем я буду всё же рисовать Edge над Spine, при этом мы будем держать в уме, что никакого интеллекта на Spine и отличий при работе с обычными Leaf и с Edge-leaf нет (хотя тут могут быть нюансы, но в целом бул ушундай).

Заводдун жээк-тери бар схемасы.

Жалбырак, омуртка жана кыр үчилтиги Underlay тармагын же фабриканы түзөт.

Тармактык фабриканын милдети (Underlay окуу), биз буга чейин аныктаганбыз акыркы маселе, абдан, абдан жөнөкөй - бир DC ичинде жана алардын ортосундагы машиналар ортосунда IP байланышты камсыз кылуу.
Мына ошондуктан тармак фабрика деп аталат, мисалы, модулдук тармак кутучаларынын ичиндеги коммутациялык завод сыяктуу, сиз бул тууралуу көбүрөөк окуй аласыз. SDSM14.

Жалпысынан алганда, мындай топология фабрика деп аталат, анткени которууда кездеме кездеме дегенди билдирет. Жана буга макул болбоо кыйын:

Завод толугу менен L3. VLAN жок, уктуруу жок - бизде LAN_DCде ушундай сонун программисттер бар, алар L3 парадигмасында жашаган тиркемелерди кантип жазууну билишет жана виртуалдык машиналар IP дарегин сактоо менен Live Migration талап кылбайт.

Жана дагы бир жолу: эмне үчүн завод жана эмне үчүн L3 өзүнчө деген суроого жооп макала.

DCI - Data Center Interconnect (DC Interconnect)

DCI Edge-Leaf аркылуу уюштурулат, башкача айтканда, алар биздин трассага чыгуу чекитибиз.
Жөнөкөйлүк үчүн, биз ДКлар бири-бири менен түз байланыштар аркылуу байланышат деп ойлойбуз.
Келгиле, тышкы байланышты кароодон чыгаралы.

Мен бир компонентти алып салган сайын тармакты бир топ жөнөкөйлөштүргөнүмдү билем. Ал эми абстракттуу тармагыбызды автоматташтырганда, баары жакшы болот, бирок чыныгыда балдак болот.
Бул ушундай. Ошентсе да, бул сериянын мааниси ойдон чыгарылган маселелерди баатырдык менен чечүү эмес, ыкмалар боюнча ойлонуу жана иштөө.

Edge-Leafs боюнча, астыңкы катмар VPNге жайгаштырылат жана MPLS магистралы (ошол эле түз шилтеме) аркылуу берилет.

Бул биз алган эң жогорку деңгээлдеги диаграмма.

Маршруттоо

DC ичинде маршруттоо үчүн биз BGP колдонобуз.
MPLS магистралында OSPF+LDP.
DCI үчүн, башкача айтканда, жер астындагы байланышты уюштуруу - MPLS аркылуу BGP L3VPN.

Маршрутизациянын жалпы схемасы

Заводдо OSPF же ISIS (Россия Федерациясында тыюу салынган маршруттук протокол) жок.

Бул авто-ачуу же эң кыска жолдорду эсептөө болбойт дегенди билдирет - протоколду, кошуналыкты жана саясатты орнотуу кол менен гана (чындыгында автоматтык - бул жерде автоматташтыруу жөнүндө сөз болуп жатат).

DC ичинде BGP маршруттук схемасы

Эмне үчүн BGP?

Бул темада бар бүт RFC кантип куруу керектигин айткан Facebook жана Arista атындагы өтө чоң BGP аркылуу маалымат борборунун тармактары. Ал дээрлик фантастикадай окулат, мен аны кечке сунуштайм.

Ошондой эле менин макаламда ушуга арналган бүтүндөй бир бөлүм бар. Мен сени кайда алып барам жана Мен жөнөтүп жатам.

Бирок, кыскасы, эч кандай IGP чоң маалымат борборлорунун тармактары үчүн ылайыктуу эмес, ал жерде тармактык түзүлүштөрдүн саны миңге жетет.

Мындан тышкары, бардык жерде BGP колдонуу бир нече ар кандай протоколдорду колдоо жана алардын ортосундагы синхрондоштуруу үчүн убакытты текке кетирбөөгө мүмкүндүк берет.

Ыктымалдуулуктун жогорку даражасы менен тездик менен өспөй турган биздин фабрикабызда көзгө OSPF жетиштүү болмок. Бул чындыгында мегашкалерлердин жана булут титандарынын көйгөйлөрү. Бирок, келгиле, бир нече релиздерди элестетип көрөлү, бул бизге керек жана биз Петр Лапухов керээз кылгандай, BGP колдонобуз.

Маршруттук саясаттар

Leaf которгучтарында биз Underlay тармак интерфейстеринен префикстерди BGPге импорттойбуз.
Биз ортосунда BGP сессиясы болот ар бир Leaf-Spine жуп, анда бул Underlay префикстери тармак аркылуу алдыга жана артка жарыяланат.

Бир маалымат борборунун ичинде биз ToReге импорттогон спецификацияларды таратабыз. Edge-Leafs боюнча биз аларды бириктирип, алыскы ДКларга жарыялайбыз жана TORлерге жөнөтөбүз. Башкача айтканда, ар бир ТР ошол эле DCдагы башка ТоРго кантип жетүү керектигин жана башка DCдагы ТоРго кирүү чекити кайда барарын так билет.

DCIде маршруттар VPNv4 катары өткөрүлөт. Бул үчүн, Edge-Leafде фабрикага карай интерфейс VRFге жайгаштырылат, келгиле, аны UNDERLAY деп атайлы, ал эми Spine on Edge-Leaf менен кошуналык VRF ичинде жана Edge-Leafs ортосунда VPNv4-те көтөрүлөт. үй-бүлө.

Биз ошондой эле омурткалардан алынган каттамдарды кайра аларга кайра жарыялоого тыюу салабыз.

Leaf жана Spine боюнча биз Loopbacks импорттолбойбуз. Бизге Router ID аныктоо үчүн гана керек.

Бирок Edge-Leafs боюнча биз аны Global BGPге импорттойбуз. Loopback даректеринин ортосунда, Edge-Leafs бири-бири менен IPv4 VPN үй-бүлөсүндө BGP сеансын орнотот.

Биз EDGE түзмөктөрүнүн ортосунда OSPF + LDP магистралына ээ болобуз. Баары бир зонада. Өтө жөнөкөй конфигурация.

Бул маршруттук сүрөт.

BGP ASN

Edge-Leaf ASN

Edge-Leafs бардык ДКларда бир ASN болот. Edge-Leafs ортосунда iBGP болушу маанилүү жана биз eBGP нюанстарына аралашпайбыз. Ал 65535 болсун. Чындыгында бул коомдук АСтын саны болушу мүмкүн.

Spine ASN

Spineде бизде DC үчүн бир ASN болот. Бул жерде жеке AS диапазонундагы эң биринчи сандан баштайлы - 64512, 64513 жана башкалар.

Эмне үчүн DC боюнча ASN?

Келгиле, бул суроону экиге бөлүп көрөлү:

• Эмне үчүн ASN бир DCнин бардык омурткаларында бирдей?
• Эмне үчүн алар ар кандай ДКда айырмаланат?

Эмне үчүн бир DCнин бардык омурткаларында бирдей ASN бар?

Edge-Leaf боюнча Underlay маршрутунун AS-Path ушундай болот:
[leafX_ASN, spine_ASN, edge_ASN]
Сиз аны кайра Spineге жарнамалоого аракет кылганыңызда, ал аны жокко чыгарат, анткени анын AS (Spine_AS) тизмеде мурунтан эле бар.

Бирок, DC ичинде биз Edgeге көтөрүлгөн Underlay маршруттары ылдый түшө албай турганына толугу менен канааттанабыз. DC ичиндеги кошуундардын ортосундагы бардык байланыш омуртка деңгээлинде болушу керек.

Ошол эле учурда, башка ДКлардын топтолгон маршруттары кандай болгон күндө да ToRларга оңой жетет - алардын AS-Path ASN 65535 гана болот - AS Edge-Leafs саны, анткени алар ошол жерде түзүлгөн.

Эмне үчүн алар ар кандай ДКда айырмаланат?

Теориялык жактан алганда, биз DC ортосунда Loopback жана кээ бир кызмат виртуалдык машиналарды сүйрөп керек болушу мүмкүн.

Мисалы, хостто биз Route Reflector же иштетебиз ошол эле VNGW (Virtual Network Gateway), ал TopR менен BGP аркылуу кулпулайт жана өзүнүн циклин жарыялайт, ал бардык ДКдан жеткиликтүү болушу керек.

Ошентип, анын AS-Жолу ушундай болот:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Жана эч бир жерде кайталанма ASN болбошу керек.

Башкача айтканда, Spine_DC1 жана Spine_DC2, жапайы X_DC1 жана leafY_DC2 сыяктуу, башкача болушу керек, бул биз жакындап жаткан нерсе.

Белгилүү болгондой, циклдин алдын алуу механизмине карабастан (Ciscoдо кирүү мүмкүнчүлүгү бар) кайталанма ASN менен маршруттарды кабыл алууга мүмкүндүк берген хакерлер бар. Ал тургай, мыйзамдуу пайдалануу бар. Бирок бул тармактын туруктуулугундагы потенциалдуу боштук. Ал эми жеке мен бир-эки жолу ага түшүп калдым.

Ал эми кооптуу нерселерди колдонбогонго мүмкүнчүлүгүбүз болсо, аны пайдаланабыз.

Leaf ASN

Тармак боюнча ар бир Leaf которуштурууда жеке ASN болот.
Биз муну жогоруда келтирилген себептерден улам жасайбыз: AS-Path илмексиз, BGP конфигурациясы кыстармаларсыз.

Жалбырактардын ортосундагы маршруттар бир калыпта өтүшү үчүн 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 колдонобуз жана аны Spine's ASN жана Leaf которуштуруу номеринин негизинде түзөбүз, тактап айтканда, төмөнкүдөй: Spine_ASN.0000X.

Бул ASN менен сүрөт.

IP планы

Негизинен, биз төмөнкү байланыштар үчүн даректерди бөлүштүрүү керек:

1. ToR менен машинанын ортосундагы тармак даректери. Алар бардык тармактын ичинде уникалдуу болушу керек, ошондуктан каалаган машина башкасы менен байланыша алат. Абдан туура 10/8. Ар бир стойка үчүн резерви бар /26 бар. ДКга /19 жана аймакка /17 бөлүп беребиз.
2. Leaf/Tor жана Spine ортосундагы шилтеме даректери.

   Мен аларды алгоритмдик түрдө дайындагым келет, башкача айтканда, аларды туташтыруу керек болгон түзүлүштөрдүн аттарынан эсептеп алгым келет.

   Болсун... 169.254.0.0/16.
   атап айтканда, 169.254.00X.Y/31кайда X - Омуртканын саны, Y — P2P тармагы /31.
   Бул сизге DCде 128 стойкага жана 10го чейин Spineди ишке киргизүүгө мүмкүндүк берет. Шилтеме даректери 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.
   • Leaf - / DC күнүнө 25 - ошол эле 128 стеллаждар. Район боюнча /23 белуп беребиз.
   • Spine - / 28 DC күнүнө - 16 Spine чейин. Район боюнча /26дан белуп берели.
   • Edge-Leaf - / DC үчүн 29 - 8 кутучага чейин. Район боюнча /27 белуп берели.

Эгерде бизде DC'де бөлүнгөн диапазондор жетишсиз болсо (жана эч ким болбойт - биз гиперкалидербиз деп ырастайбыз), биз жөн гана кийинки блокту тандайбыз.

Бул IP дареги бар сүрөт.

Артка кайтуулар:

приставка
Аппараттын ролу
регион
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
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
Бааша

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
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
Бааша

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
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
Бааша

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
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
Бааша

10.1.32.0/19
SIA

Laba

Эки сатуучу. Бир тармак. ADSM.

Арча + Ариста. Ubuntu. Жакшы эски Обо.

Миранадагы виртуалдык сервердеги ресурстардын көлөмү дагы эле чектелүү, ошондуктан практика үчүн биз чекке чейин жөнөкөйлөштүрүлгөн тармакты колдонобуз.

Эки маалымат борборлору: Казан жана Барселона.

• Ар бир эки омуртка: Арча жана Ариста.
• Ар биринде бир торус (Жалбырак) - Арча жана Ариста, бир туташкан хост менен (бул үчүн жеңил Cisco IOL алалы).
• Ар бири бирден Edge-Leaf түйүнү (азыр бир гана Арча).
• Алардын баарын башкаруу үчүн бир Cisco которуштуруу.
• Тармак кутучаларынан тышкары виртуалдык башкаруу машинасы иштеп жатат. Ubuntu иштеп жатат.
  Анын бардык түзмөктөргө мүмкүнчүлүгү бар, ал IPAM/DCIM системаларын, Python скрипттеринин бир тобун, Ansible жана бизге керек болгон башка нерселерди иштетет.

Толук конфигурация бардык тармактык түзүлүштөрдүн, биз автоматташтыруу аркылуу кайра чыгарууга аракет кылабыз.

жыйынтыктоо

Бул да кабыл алынганбы? Ар бир макаланын астына кыскача корутунду жазыш керекпи?

Ошентип биз тандадык үч даражалуу DC ичиндеги Kloz тармагы, анткени биз Чыгыш-Батыш трафиктин көп болушун күтөбүз жана ECMPти каалайбыз.

Тармак физикалык (подряддык) жана виртуалдык (кабаттуу) болуп бөлүнгөн. Ошол эле учурда, катмар хосттон башталат - ошону менен астыңкы катмарга коюлган талаптарды жөнөкөйлөтүү.

Биз анын масштабдуулугу жана саясаттын ийкемдүүлүгү үчүн тармактык тармактар ​​үчүн маршруттоо протоколу катары BGPди тандап алдык.

Бизде DCI уюштуруу үчүн өзүнчө түйүндөр болот - Edge-leaf.
Негизги OSPF+LDP болот.
DCI MPLS L3VPN негизинде ишке ашырылат.
P2P шилтемелери үчүн биз IP даректерди алгоритмдик түрдө түзмөк атына жараша эсептейбиз.
Түзмөктөрдүн ролуна жана алардын жайгашкан жерине ырааттуу түрдө кайра циклдерди дайындайбыз.
Астындагы префикстер - жалбырак которгучтарында гана алардын жайгашкан жерине жараша ырааттуу түрдө.

Азырынча бизде жабдуулар орнотулган эмес деп эсептейли.
Ошондуктан, биздин кийинки кадамдарыбыз аларды системаларга кошуу (IPAM, инвентаризация), кирүүнү уюштуруу, конфигурацияны түзүү жана аны жайылтуу.

Кийинки макалада биз Netbox менен алектенебиз - DC деги IP мейкиндигин инвентаризациялоо жана башкаруу системасы.

Рахмат

• Корректорлор жана оңдоолор үчүн Андрей Глазков ака @glazgoo
• Александр Клименко ака @v00lk түзөтүү жана оңдоо үчүн
• Артём Чернобай KDPV үчүн

Source: www.habr.com