Алғашқы екі мақалада мен автоматтандыру мәселесін қозғадым және оның құрылымын сыздым, екіншісінде қызметтерді конфигурациялауды автоматтандырудың бірінші тәсілі ретінде желілік виртуализацияға шегініс жасадым.
Енді физикалық желінің диаграммасын салу уақыты келді.

Егер сіз деректер орталығының желілерін орнатумен таныс болмасаңыз, мен осыдан бастауды ұсынамын олар туралы мақалалар.

Барлық мәселелер:

• 0. ADSM. Нөлдік бөлік. Жоспарлау
• 1. ADSM. Бірінші бөлім (ол нөлден кейін). Желіні виртуалдандыру
• 2. ADSM. Екінші бөлім. Желілік дизайн

Осы серияда сипатталған тәжірибелер кез келген жеткізушілермен (жоқ) кез келген желі түріне, кез келген өлшемге қатысты болуы керек. Дегенмен, бұл тәсілдерді қолданудың әмбебап мысалын сипаттау мүмкін емес. Сондықтан мен тұрақты ток желісінің заманауи архитектурасына тоқталамын: Клоз фабрикасы.
Біз MPLS L3VPN жүйесінде DCI жасаймыз.

Overlay желісі хосттан физикалық желінің үстінде жұмыс істейді (бұл OpenStack VXLAN немесе вольфрамдық мата немесе желіден тек негізгі IP қосылымын қажет ететін кез келген басқа нәрсе болуы мүмкін).

Бұл жағдайда біз автоматтандырудың салыстырмалы түрде қарапайым сценарийін аламыз, өйткені бізде бірдей конфигурацияланған көптеген жабдықтар бар.

Біз вакуумда сфералық тұрақты токты таңдаймыз:

• Барлық жерде бір дизайн нұсқасы.
• Екі желілік ұшақты құрайтын екі жеткізуші.
• Бір DC екіншісіне ұқсайды, түйіршіктегі екі бұршақ сияқты.

Мазмұны

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

Мысалы, LAN_DC қызмет провайдеріне кептеліп қалған лифтілерде аман қалу туралы оқу бейнелерін орналастыруға рұқсат етіңіз.

Мегаполистерде бұл өте танымал, сондықтан сізге көптеген физикалық машиналар қажет.

Біріншіден, мен желіні шамамен мен қалағандай сипаттаймын. Содан кейін мен оны зертхана үшін жеңілдетемін.

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

Орындар

LAN_DC-де 6 DC болады:

• Ресей (RU):
  • Мәскеу (msk)
  • Қазан (kzn)

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

• Қытай (CN):
  • Шанхай (sha)
  • Сиань (sia)

Тұрақты ток ішінде (ішкі тұрақты ток)

Барлық тұрақты токтарда Clos топологиясына негізделген бірдей ішкі байланыс желілері бар.
Олар қандай Clos желілері және неге олар бөлек мақала.

Әрбір DC-де машиналары бар 10 тірек бар, олар нөмірленеді A, B, C Тағыда басқа.

Әр сөреде 30 машина бар. Олар бізді қызықтырмайды.

Сондай-ақ әрбір тіректе барлық машиналар қосылған қосқыш бар - бұл Сөренің үстіңгі қосқышы - ToR немесе басқаша айтқанда, Clos фабрикасы тұрғысынан біз оны атаймыз Жапырақ.

Зауыттың жалпы схемасы.

Біз оларды шақырамыз XXX-жапырақYқайда XXX - үш әріпті қысқарту DC, және Y - реттік нөмір. Мысалы, kzn-жапырақ11.

Мақалаларымда мен Leaf және ToR терминдерін синонимдер ретінде жеңіл қолдануға рұқсат етемін. Дегенмен, бұлай емес екенін есте ұстауымыз керек.
ToR – машиналар жалғанатын тірекке орнатылған қосқыш.
Жапырақ – физикалық желідегі құрылғының немесе Cloes топологиясы бойынша бірінші деңгейлі қосқыштың рөлі.
Яғни, Leaf != ToR.
Мысалы, Leaf EndofRaw қосқышы болуы мүмкін.
Дегенмен, осы мақаланың аясында біз оларды синонимдер ретінде қарастырамыз.

Әрбір ToR қосқышы өз кезегінде төрт жоғары деңгейлі біріктіру қосқыштарына қосылады - Омыртқа. Тұрақты токтағы бір тірек Spines үшін бөлінген. Біз оны осылай атаймыз: XXX- омыртқаY.

Сол сөреде бортында MPLS бар DC - 2 маршрутизаторы арасында қосылуға арналған желілік жабдық болады. Бірақ жалпы алғанда, бұл бірдей ТоРлар. Яғни, Spine қосқыштары тұрғысынан, қосылған машиналары бар әдеттегі ToR немесе DCI үшін маршрутизатор мүлдем маңызды емес - жай ғана бағыттау.

Мұндай арнайы ТР деп аталады Жиек-жапырақ. Біз оларды шақырамыз XXX-шекY.

Бұл келесідей болады.

Жоғарыдағы диаграммада мен жиек пен жапырақты бірдей деңгейде орналастырдым. Классикалық үш қабатты желілер Олар бізге uplinking (осыдан термин) uplinks ретінде қарастыруды үйретті. Міне, DCI «жоғары байланысы» қайтадан төмендейді, бұл кейбіреулер үшін әдеттегі логиканы аздап бұзады. Үлкен желілер жағдайында, деректер орталықтары одан да кішірек бірліктерге бөлінгенде - POD‘s (Жеткізу нүктесі), бөлек белгілеңіз Edge-POD‘s DCI және сыртқы желілерге кіруге арналған.

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

Жапырақтары бар фабриканың схемасы.

Жапырақ, омыртқа және шет үштігі астындағы желіні немесе зауытты құрайды.

Желілік зауыттың міндеті (Underlay оқыңыз), біз қазірдің өзінде анықтадық соңғы шығарылым, өте, өте қарапайым - бір тұрақты ток ішінде және олардың арасындағы машиналар арасында IP қосылымын қамтамасыз ету.
Сондықтан желіні зауыт деп атайды, мысалы, модульдік желі қораптарының ішіндегі коммутация зауыты сияқты, ол туралы толығырақ мына жерден оқи аласыз. SDSM14.

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

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

Және тағы бір рет: неліктен зауыт және неге L3 бөлек деген сұраққа жауап мақала.

DCI - деректер орталығының өзара байланысы (DC аралық)

DCI Edge-Leaf көмегімен ұйымдастырылады, яғни олар біздің тас жолға шығатын нүктеміз болып табылады.
Қарапайымдылық үшін тұрақты токтар бір-бірімен тікелей байланыстар арқылы қосылған деп есептейміз.
Сыртқы қосылымды қарастырудан шығарайық.

Мен компонентті өшірген сайын желіні айтарлықтай жеңілдететінімді білемін. Ал біз абстрактілі желіні автоматтандырған кезде бәрі жақсы болады, бірақ шынында балдақ болады.
Бұл осылай. Дегенмен, бұл топтаманың мәні ойдан шығарылған мәселелерді ерлікпен шешу емес, тәсілдермен ойлау және жұмыс істеу болып табылады.

Edge-Leafs-де астарлы қабат VPN-ге орналастырылады және MPLS магистральдық жүйесі (бірдей тікелей сілтеме) арқылы беріледі.

Бұл біз алатын жоғарғы деңгейлі диаграмма.

Маршруттау

DC ішінде маршруттау үшін біз BGP пайдаланамыз.
MPLS магистралінде OSPF+LDP.
DCI үшін, яғни жер астындағы байланысты ұйымдастыру - MPLS арқылы BGP L3VPN.

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

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

Бұл автоматты түрде табу немесе ең қысқа жолдарды есептеу болмайтынын білдіреді - тек қолмен (шын мәнінде автоматты - біз мұнда автоматтандыру туралы айтып отырмыз) протоколды, көршілестік пен саясатты орнату.

DC ішіндегі BGP маршруттау схемасы

Неліктен BGP?

Бұл тақырыпта бар тұтас RFC қалай салу керектігін айтатын Facebook пен Аристаның атымен аталған өте үлкен BGP көмегімен деректер орталығының желілері. Ол көркем әдебиет сияқты оқылады, мен оны түнгі кешке өте ұсынамын.

Менің мақаламда осыған арналған толық бөлім бар. Мен сені қайда апарамын және жіберіп жатырмын.

Дегенмен, қысқаша айтқанда, желілік құрылғылардың саны мыңға жететін үлкен деректер орталықтарының желілері үшін ешқандай IGP қолайлы емес.

Сонымен қатар, BGP-ті барлық жерде пайдалану бірнеше түрлі хаттамаларды қолдауға және олардың арасындағы синхрондауға уақытты жоғалтпауға мүмкіндік береді.

Жүректен қол ұстасып, жоғары ықтималдықпен тез өспейтін біздің зауытта OSPF көзге жеткілікті болар еді. Бұл шын мәнінде мегашкалерлер мен бұлтты титандардың проблемалары. Бірақ бізге қажет бірнеше шығарылымдар үшін елестетіп көрейік және Петр Лапухов өсиет еткендей, BGP қолданамыз.

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

Leaf қосқыштарында біз Underlay желі интерфейстерінен BGP-ге префикстерді импорттаймыз.
Бізде BGP сеансы болады әрқайсысы Leaf-Spine жұбы, онда бұл Underlay префикстері желі арқылы алға және артқа жарияланады.

Бір деректер орталығында біз ToRe ішіне импорттаған техникалық сипаттамаларды таратамыз. Edge-Leafs-де біз оларды біріктіреміз және қашықтағы DC-ге хабарлаймыз және оларды TOR-ге жібереміз. Яғни, әрбір ТҚ бір тұрақты токта басқа ТҚ-ға қалай жетуге болатынын және басқа DC-дегі ТҚ-ға кіру нүктесі қай жерде екенін нақты біледі.

DCI жүйесінде маршруттар VPNv4 ретінде жіберіледі. Бұл әрекетті орындау үшін, Edge-Leaf-те зауытқа бағытталған интерфейс VRF-ге орналастырылады, оны UNDERLAY деп атаймыз, ал Edge-Leaf-тегі омыртқалы аймақ VRF ішінде және VPNv4-тегі Edge-Leafs арасында көтеріледі. отбасы.

Біз сондай-ақ омыртқалардан алынған маршруттарды оларға кері қайтаруға тыйым саламыз.

Leaf and Spine-де біз Loopbacks импорттамаймыз. Олар бізге тек маршрутизатор идентификаторын анықтау үшін қажет.

Бірақ Edge-Leafs жүйесінде біз оны Global BGP-ге импорттаймыз. Loopback мекенжайлары арасында Edge-Leafs бір-бірімен IPv4 VPN отбасында BGP сеансын орнатады.

Бізде EDGE құрылғылары арасында OSPF+LDP магистральдық жүйесі болады. Барлығы бір аймақта. Өте қарапайым конфигурация.

Бұл маршрутизациясы бар сурет.

BGP ASN

Edge-Leaf ASN

Edge-Leafs барлық DC-де бір ASN болады. Edge-Leafs арасында iBGP болуы маңызды және біз eBGP нюанстарына түсіп қалмаймыз. Бұл 65535 болсын. Шындығында бұл қоғамдық АС саны болуы мүмкін.

Омыртқа ASN

Spine-де бізде бір DC үшін бір ASN болады. Мұнда жеке AS диапазонындағы ең бірінші саннан бастайық - 64512, 64513 және т.б.

Неліктен DC желісіндегі ASN?

Бұл сұрақты екіге бөліп көрейік:

• Неліктен ASN бір тұрақты токтың барлық тікенектерінде бірдей?
• Неліктен олар әртүрлі DC-де ерекшеленеді?

Неліктен бір тұрақты токтың барлық омыртқаларында бірдей ASN бар?

Edge-Leaf жолындағы Underlay маршрутының AS-Path жолы келесідей болады:
[leafX_ASN, spine_ASN, edge_ASN]
Оны қайтадан Spine-ге жарнамалауға тырысқанда, ол оны тастайды, себебі оның AS (Spine_AS) тізімде бұрыннан бар.

Дегенмен, DC ішінде біз Edge-ге көтерілетін Underlay маршруттары төмен түсе алмайтынына толықтай қанағаттанамыз. DC ішіндегі хосттар арасындағы барлық байланыс омыртқа деңгейінде болуы керек.

Сонымен қатар, басқа DC-лердің жинақталған маршруттары кез келген жағдайда ToR-ға оңай жетеді - олардың AS-жолында тек ASN 65535 болады - AS Edge-Leafs саны, өйткені олар сол жерде жасалған.

Неліктен олар әртүрлі DC-де ерекшеленеді?

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

Мысалы, хостта біз Route Reflector немесе іске қосамыз бірдей VNGW (Виртуалды желі шлюзі), ол BGP арқылы ToR арқылы құлыпталады және өзінің кері байланысын жариялайды, оған барлық ДК-дан қол жетімді болуы керек.

Осылайша, оның 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 бар маршруттарды қабылдауға мүмкіндік беретін бұзулар бар. Оның тіпті заңды қолданылуы да бар. Бірақ бұл желінің тұрақтылығындағы ықтимал алшақтық. Ал өз басым оған бір-екі рет түстім.

Ал қауіпті заттарды қолданбауға мүмкіндігіміз болса, біз оны пайдаланамыз.

Жапырақ 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 бар. Біз DC үшін /19 және аймаққа /17 бөлеміз.
2. Жапырақ/Тор және Омыртқа арасындағы мекенжайларды байланыстыру.

   Мен оларды алгоритмдік түрде тағайындағым келеді, яғни оларды қосу керек құрылғылардың атауларынан есептеңіз.

   Болсын... 169.254.0.0/16.
   Атап айтқанда 169.254.00X.Y/31қайда X - омыртқа саны, Y — P2P желісі /31.
   Бұл тұрақты токта 128 сөреге дейін және 10 шпинге дейін іске қосуға мүмкіндік береді. Сілтеме мекенжайлары тұрақты токтан тұрақты токқа дейін қайталануы мүмкін (және солай болады).

3. Біз ішкі желілерде Spine-Edge-Leaf түйісуін ұйымдастырамыз 169.254.10X.Y/31, қайда дәл солай X - омыртқа саны, Y — P2P желісі /31.
4. Edge-Leaf жүйесінен MPLS магистральдық жүйесіне мекенжайларды байланыстыру. Мұнда жағдай біршама басқаша - барлық бөліктер бір пирогқа қосылған орын, сондықтан бірдей мекенжайларды қайта пайдалану жұмыс істемейді - келесі бос ішкі желіні таңдау керек. Сондықтан негізге алайық 192.168.0.0/16 Ал біз одан бос адамдарды шығарамыз.
5. Кері байланыс мекенжайлары. Біз оларға барлық ассортиментті береміз 172.16.0.0/12.
   • Жапырақ - /25 тұрақты ток - бірдей 128 тірек. Облысқа /23 бөлеміз.
   • Омыртқа - /28 бір DC - 16 Омыртқаға дейін. Облысқа /26 бөлейік.
   • Edge-Leaf - /29/ DC - 8 қорапқа дейін. Облысқа /27 бөлейік.

Егер бізде тұрақты токта бөлінген диапазондар жеткіліксіз болса (және олар болмайды - біз гипермасштабшылармыз деп мәлімдейміз), біз жай ғана келесі блокты таңдаймыз.

Бұл IP мекенжайы бар сурет.

Кері байланыстар:

Префикс
Құрылғы рөлі
Аймақ
ДЦ

172.16.0.0/23
Edge
 
 

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

Астыңғы қабат:

Префикс
Аймақ
ДЦ

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.

Арша + Ариста. Ubuntu. Қайырлы қарт Хауа.

Миранадағы виртуалды сервердегі ресурстардың көлемі әлі де шектеулі, сондықтан тәжірибе үшін біз шектеуге дейін жеңілдетілген желіні қолданамыз.

Екі дата орталығы: Қазан және Барселона.

• Әрқайсысы екі омыртқа: Арша және Ариста.
• Әрқайсысында бір торус (Жапырақ) - Juniper және Arista, бір қосылған хосты бар (бұл үшін жеңіл Cisco IOL алайық).
• Әрбір Edge-Leaf түйіні (әзірше тек арша).
• Олардың барлығын басқару үшін бір Cisco қосқышы.
• Желілік қораптарға қосымша виртуалды басқару машинасы жұмыс істейді. Ubuntu іске қосылған.
  Ол барлық құрылғыларға қол жеткізе алады, ол IPAM/DCIM жүйелерін, Python сценарийлерінің топтамасын, Ansible және бізге қажет болуы мүмкін басқа нәрселерді іске қосады.

Толық конфигурация барлық желілік құрылғылардың, біз автоматтандыруды пайдалана отырып, шығаруға тырысамыз.

қорытынды

Бұл да қабылданды ма? Әр мақаланың астына қысқаша қорытынды жазуым керек пе?

Сонымен біз таңдадық үш деңгейлі DC ішіндегі Kloz желісі, өйткені біз шығыс-батыс трафикті көп күтеміз және ECMP-ті қалаймыз.

Желі физикалық (астарлы) және виртуалды (қабат) болып бөлінді. Сонымен қатар, қабаттастыру хосттан басталады - осылайша астарға қойылатын талаптарды жеңілдетеді.

Біз BGP-ті желілік желілер үшін маршруттау хаттамасы ретінде оның масштабталуы мен саясаттың икемділігі үшін таңдадық.

Бізде DCI - Edge-leaf ұйымдастыру үшін бөлек түйіндер болады.
Магистральда OSPF+LDP болады.
DCI MPLS L3VPN негізінде жүзеге асырылады.
P2P сілтемелері үшін IP мекенжайларын құрылғы атаулары негізінде алгоритмдік түрде есептейміз.
Біз құрылғылардың рөліне және олардың орналасуына сәйкес циклді тағайындаймыз.
Астыңғы қабат префикстері - тек олардың орналасуына қарай дәйектілікпен Leaf қосқыштарында.

Дәл қазір бізде жабдық әлі орнатылмаған делік.
Сондықтан, біздің келесі қадамдарымыз оларды жүйелерге (IPAM, инвентарь) қосу, қол жеткізуді ұйымдастыру, конфигурацияны жасау және оны орналастыру болады.

Келесі мақалада біз Netbox - тұрақты токтағы IP кеңістігін түгендеу және басқару жүйесімен айналысамыз.

Рақмет сізге

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

Ақпарат көзі: www.habr.com