У першых двух артыкулах я падняў пытанне аўтаматызацыі і накідаў яе фрэймворк, у другой зрабіў адступленне ў віртуалізацыю сеткі, як першы падыход да аўтаматызацыі наладкі сэрвісаў.
А зараз прыйшоў час намаляваць схему фізічнай сеткі.

Калі вы не на кароткай назе з прыладай сетак датацэнтраў, то я настойліва рэкамендую пачаць са артыкулы пра іх.

Усе выпускі:

• 0. АДСМ. Частка Нулявая. Планаванне
• 1. АДСМ. Частка першая (якая пасля нулявой). Віртуалізацыя сеткі
• 2. АДСМ. Частка другая. Дызайн сеткі

Апісаныя ў гэтай серыі практыкі павінны быць дастасавальныя да сеткі любога тыпу, любога маштабу з любой разнастайнасцю вендараў (не). Аднак нельга апісаць універсальны прыклад ужывання гэтых падыходаў. Таму я спынюся на сучаснай архітэктуры сеткі ДЦ: Фабрыцы Клоза.
DCI зробім на MPLS L3VPN.

Па-над фізічнай сеткай працуе Overlay-сетка з хаста (гэта можа быць VXLAN OpenStack'а ці Tungsten Fabric ці што заўгодна іншае, што патрабуе ад сеткі толькі базавай IP-складнасці).

У гэтым выпадку атрымаецца параўнальна просты сцэнар для аўтаматызацыі, таму што маем шмат абсталявання, які наладжваецца аднолькавай выявай.

Мы выберам сферычны ДЦ у вакууме:

• Адна версія дызайну ўсюды.
• Два вендара, якія ўтвараюць дзве плоскасці сеткі.
• Адзін ДЦ падобны на іншы як дзве кроплі вады.

Змест

• Фізічная тапалогія
• Маршрутызацыя
• IP-план
• Лаба
• Заключэнне
• Карысныя спасылкі

Няхай наш Сэрвіс-Правайдэр LAN_DC будзе, напрыклад, хосціць навучальныя відэа аб выжыванні ў захраснулі ліфтах.

У мегаполісах гэта карыстаецца шалёнай папулярнасцю, таму фізічных машын трэба шмат.

Спачатку я апішу сетку прыблізна такі, які б яе хацелася бачыць. А потым спрашчу для лабы.

Фізічная тапалогія

лакацыі

У LAN_DC будзе 6 ДЦ:

• Расія (RU):
  • Масква (msk)
  • Казань (kzn)

• Іспанія (SP):
  • Барселона (bcn)
  • Малага (млг)

• Кітай (CN):
  • Шанхай (ша)
  • Сіань (абодва)

Унутры ДЦ (Intra-DC)

Ва ўсіх ДЦ ідэнтычныя сеткі ўнутранай складнасці, заснаваныя на тапалогіі Клоза.
Што за сеткі Клоза і чаму менавіта яны - у асобнай артыкуле.

У кожным ДЦ па 10 стоек з машынамі, яны будуць нумаравацца як A, B, C І гэтак далей.

У кожнай стойцы па 30 машын. Яны нас цікавіць не будуць.

Таксама ў кожнай стойцы варта камутатар, да якога падлучаныя ўсе машыны - гэта Top of the Rack switch - ToR ці інакш у тэрмінах фабрыкі Клоза будзем зваць яго Ліст.

Агульная схема фабрыкі.

Зваць іх будзем XXX-leafY, Дзе XXX - трохлітарнае скарачэнне ДЦ, а Y - парадкавы нумар. Напрыклад, kzn-leaf11.

Я ў артыкулах дазволю сабе дастаткова фрывольна звяртацца тэрмінамі Leaf і ToR, як сінонімамі. Аднак трэба памятаць, што гэта ня так.
ToR - гэта камутатар, усталяваны ў стойцы, да якога падлучаюцца машыны.
Leaf - гэта роля прылады ў фізічнай сетцы або світч першага ўзроўню ў тэрмінах тапалогіі Клоза.
Гэта значыць Leaf! = ToR.
Так Leaf'ом можа быць EndofRaw-камутатар, напрыклад.
Аднак у рамках гэтага артыкула будзем усё ж звяртацца імі як сінонімамі.

Кожны ToR-камутатар у сваю чаргу злучаны з чатырма вышэйстаячымі якія агрэгуюць камутатарамі. карэньчык. Пад Spine'ы выдзелена па адной стойцы ў ДЦ. Назваць будзем аналагічна: XXX-spineY.

У гэтай жа стойцы будзе стаяць сеткавае абсталяванне для складнасці паміж ДЦ – 2 маршрутызатара з MPLS на борце. Але па вялікім рахунку - гэта тыя ж самыя ToR'ы. Гэта значыць з пункту гледжання Spine-камутатараў не мае ніякага значэння звычайны там ToR з падлучанымі машынамі або маршрутызатар для DCI – адзін чорт форвардить.

Такія спецыяльныя ToR'ы называюцца Edge-leaf. Мы іх будзем называць XXX-крайY.

Выглядаць гэта будзе так.

На схеме вышэй edge і leaf я сапраўды размясціў на адным узроўні. Класічныя трохузроўневыя сеткі прызвычаілі нас разглядаць, аплінк (уласна адгэтуль і тэрмін), як лінкі ўверх. А тут атрымліваецца аплінк DCI ідзе зваротна ўніз, што некаторым трохі ламае звыклую логіку. У выпадку буйных сетак, калі датацэнтры дзеляцца яшчэ на больш дробныя адзінкі. POD'ы (Point Of Delivery), вылучаюць асобныя Edge-POD'ы для DCI і выхаду ў знешнія сеткі.

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

Схема фабрыкі з Edge-leaf'амі.

Сёмуха Leaf, Spine і Edge утвораць Underlay-сетку або фабрыку.

Задача сеткавай фабрыкі (чытай Underlay), як мы ўжо вызначыліся ў мінулым выпуску, вельмі і вельмі простая - забяспечыць IP-складнасць паміж машынамі як у межах аднаго ДЦ, так і паміж.
Таму сетка і завецца фабрыкай, гэтак жа, напрыклад, як фабрыка камутацыі ўсярэдзіне модульных сеткавых скрынак, пра што падрабязней можна пачытаць у СДСМ14.

А ўвогуле такая тапалогія называецца фабрыкай, таму што fabric у перакладзе — гэта тканіна. І складана не пагадзіцца:

Фабрыка поўнасцю L3. Ніякіх VLAN, ніякіх Broadcast – вось такія ў нас у LAN_DC выдатныя праграмісты, умеюць пісаць прыкладанні, якія жывуць у парадыгме L3, а віртуальныя машыны не патрабуюць Live Migration c захаваннем IP-адрасы.

І яшчэ раз: адказ на пытанне чаму фабрыка і чаму L3 – у асобнай артыкуле.

DCI – Data Center Interconnect (Inter-DC)

DCI будзе арганізаваны з дапамогай Edge-Leaf, гэта значыць яны – наш пункт выхаду ў магістраль.
Для прастаты выкажам здагадку, што ДЦ злучаны паміж сабой прамымі лінкамі.
Выключым з разгляду знешнюю складнасць.

Я разумею тое, што кожны раз, як я прыбіраю які-небудзь кампанент, я значна спрашчаю сетку. І пры аўтаматызацыі нашай абстрактнай сеткі ўсё будзе добра, а на рэальнай узнікнуць мыліцы.
Гэта так. І ўсё ж задача гэтай серыі - падумаць і папрацаваць над падыходамі, а не гераічна вырашаць выдуманыя праблемы.

На Edge-Leaf'ах underlay змяшчаецца ў VPN і перадаецца праз MPLS-магістраль (той самы прамы лінк).

Вось такая верхнеўзроўневая схема атрымліваецца.

Маршрутызацыя

Для маршрутызацыі ўнутры ДЦ будзем выкарыстоўваць BGP.
На MPLS-магістралі OSPF+LDP.
Для DCI, гэта значыць арганізацыі складнасці ў андэрлеі – BGP L3VPN over MPLS.

Агульная схема маршрутызацыі

На фабрыцы ніякіх OSPF і ISIS (забаронены ў Расіі пратакол маршрутызацыі).

А гэта значыць, што не будзе Auto-discovery і вылічэнні найкароткіх шляхоў - толькі ручная (на самай справе аўтаматычная - мы ж тут пра аўтаматызацыю) налада пратакола, суседства і палітык.

Схема маршрутызацыі BGP усярэдзіне ДЦ

Чаму BGP?

На гэтую тэму ёсць цэлы RFC імя Facebook'a і Arista, дзе расказваецца, як будаваць вельмі буйныя сеткі датацэнтраў, выкарыстоўваючы BGP. Чытаецца амаль як мастацкі, вельмі рэкамендую для цяжкага вечара.

А яшчэ цэлы раздзел у маім артыкуле прысвечаны гэтаму. Куды я вас і адсылаю.

Але ўсё ж калі сцісла, то ніякія IGP не падыходзяць для сетак буйных датацэнтраў, дзе рахунак сеткавым прыладамі ідзе на тысячы.

Акрамя таго выкарыстанне BGP усюды дазволіць не распыляцца на падтрымку некалькіх розных пратаколаў і сінхранізацыю паміж імі.

Паклаўшы руку на сэрца, на нашай фабрыцы, якая з вялікай дзеллю верагоднасці не будзе імкліва расці, за вочы хапіла б і OSPF. Гэта насамрэч праблемы мегаскейлераў і клаўд-тытанаў. Але пафантазуем усяго толькі на некалькі выпускаў, што нам гэта трэба, і будзем выкарыстоўваць BGP, як завяшчаў Пётр Лапухоў.

Палітыкі маршрутызацыі

На Leaf-камутатарах мы імпартуем у BGP прэфіксы з Underlay'ных інтэрфейсаў з сеткамі.
У нас будзе BGP-сесія паміж кожнай парай Leaf-Spine, у якой гэтыя Underlay'ныя прэфіксы будуць анансавацца па сетцы тудыць-сюдыць.

Унутры аднаго датацэнтра мы будзем распаўсюджваць спецыфікі, якія імпартавалі на ТоРы. На Edge-Leaf'ах будзем іх агрэгаваць і анансаваць у выдаленыя ДЦ і спускаць да Тораў. Гэта значыць кожны Тор будзе ведаць дакладна, як дабрацца да іншага Тор у гэтым жа ДЦ і дзе кропка ўваходу, каб дабрацца да Тор ў іншым ДЦ.

У DCI маршруты будуць перадавацца, як VPNv4. Для гэтага на Edge-Leaf інтэрфейс у бок фабрыкі будзе змяшчацца ў VRF, назавем яго UNDERLAY, і суседства са Spine на Edge-Leaf будзе паднімацца ўсярэдзіне VRF, а паміж Edge-Leaf'амі ў VPNv4-family.

А яшчэ мы забаронім рэанансаваць маршруты атрыманыя ад спайнаў, зваротна на іх жа.

На Leaf і Spine мы не будзем імпартаваць Loopback'і. Яны нам спатрэбяцца толькі дзеля таго, каб вызначыць Router ID.

А вось на Edge-Leaf'ах імпартуем яго ў Global BGP. Паміж Loopback-адрасамі Edge-Leaf'ы будуць усталёўваць BGP-сесію ў IPv4 VPN-family сябар з сябрам.

Паміж EDGE-прыладамі ў нас будзе расцягнута магістраль на OSPF+LDP. Усё ў адной зоне. Лімітава простая канфігурацыя.

Вось такая карціна з маршрутызацыяй.

BGP ASN

Edge-Leaf ASN

На Edge-Leaf'ах будзе адзін ASN ва ўсіх ДЦ. Гэта важна, каб паміж Edge-Leaf'амі быў iBGP, і мы не накалоліся на нюансы eBGP. Няхай гэта будзе 65535. У рэальнасці гэта мог бы быць нумар публічнай AS.

Spine ASN

На Spine у ​​нас будзе адзін ASN на ДЦ. Пачнём тут з самага першага нумара з дыяпазону прыватных AS – 64512, 64513 І гэтак далей.

Чаму ASN на ДЦ?

Дэкампазіруем гэтае пытанне на два:

• Чаму аднолькавыя ASN на ўсіх спайнах аднаго ДЦ?
• Чаму розныя ў розных ДЦ?

Чаму аднолькавыя ASN на ўсіх спайнах аднаго ДЦ

Вось як будзе выглядаць AS-Path Андэрлейнага маршруту на Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Пры спробе заанансаваць яго зваротна на Спайн, той яго адкіне таму што яго AS (Spine_AS) ужо ёсць у спісе.

Аднак у межах ДЦ нас зусім задавальняе, што маршруты Underlay, якія падняліся да Edge не змогуць спусціцца ўніз. Уся камунікацыя паміж хастамі ўнутры ДЦ павінна адбывацца ў межах узроўня спайнаў.

Пры гэтым агрэгаваныя маршруты іншых ДЦ у любым выпадку бесперашкодна будуць даходзіць да Тораў – у іх AS-Path будзе толькі ASN 65535 – нумар AS Edge-Leaf'ов, таму што менавіта на іх яны былі створаны.

Чаму розныя ў розных ДЦ

Тэарэтычна нам можа запатрабавацца працягнуць Loopback'і якіх-небудзь сэрвісных віртуальных машын паміж ДЦ.

Напрыклад, на хасце ў нас запусціцца Route Reflector або той самы VNGW (Virtual Network Gateway), які па BGP зачыніцца з Торам і праанансуе свой лупбэк, які павінен быць даступны з усіх ДЦ.

Дык вось як будзе выглядаць яго 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). І ў гэтага ёсць нават суцэль законныя ўжыванні. Але гэта патэнцыйны пралом ва ўстойлівасці сеткі. І я асабіста ў яе пару разоў правальваўся.

І калі ў нас ёсць магчымасць не выкарыстоўваць небяспечныя рэчы, мы ей скарыстаемся.

Leaf ASN

У нас будзе індывідуальны ASN на кожным Leaf-камутатары ў межах усёй сеткі.
Які робіцца мы так з меркаванняў, прыведзеных вышэй: AS-Path без завес, канфігурацыя BGP без закладак.

Каб маршруты паміж Leaf'амі бесперашкодна праходзілі, AS-Path павінен выглядаць так:
[leafX_ASN, spine_ASN, leafY_ASN]
дзе leafX_ASN і leafY_ASN добра было б, каб адрозніваліся.

Патрабуецца гэта і для сітуацыі з анонсам лупбэка VNF паміж ДЦ:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Будзем выкарыстоўваць 4-байтавы ASN і генераваць яго на аснове ASN Spine'а і нумары Leaf-камутатара, а менавіта, вось так: Spine_ASN.0000X.

Вось такая карціна з ASN.

IP-план

Прынцыпова, нам трэба вылучыць адрасы для наступных падлучэнняў:

1. Адрасы сеткі Underlay паміж ToR і машынай. Яны павінны быць унікальныя ў межах усёй сеткі, каб любая машына магла звязацца з любой іншай. Выдатна падыходзіць 10/8. На кожную стойку па /26 з запасам. Будзем вылучаць па /19 на ДЦ і /17 на рэгіён.
2. Лінкавыя адрасы паміж Leaf/Tor і Spine.

   Іх хацелася б прызначаць алгарытмічна, гэта значыць вылічаць з імёнаў прылад, якія трэба падлучыць.

   Няхай гэта будзе… 169.254.0.0/16.
   А менавіта 169.254.00X.Y/31, Дзе X - нумар Spine, Y - P2P-сетка /31.
   Гэта дазволіць запускаць да 128 стоек, і да 10 Spine у ​​ДЦ. Лінкавыя адрасы могуць (і будуць) паўтарацца з ДЦ у ДЦ.

3. Cтык Spine - Edge-Leaf арганізуем на падсетках 169.254.10X.Y/31, дзе сапраўды гэтак жа X - нумар Spine, Y - P2P-сетка /31.
4. Лінкавыя адрасы з Edge-Leaf у MPLS-магістраль. Тут сітуацыя некалькі іншая - месца злучэння ўсіх кавалкаў у адзін пірог, таму перавыкарыстоўваць тыя ж самыя адрасы не атрымаецца - трэба выбіраць наступную свабодную падсетку. Таму за аснову возьмем 192.168.0.0/16 і будзем зь яе выграбаць вольныя.
5. Адрасы Loopback. Аддамо пад іх увесь дыяпазон 172.16.0.0/12.
   • Leaf - па / 25 на ДЦ - тыя ж 128 стоек. Вылучым па /23 на рэгіён.
   • Spine - па /28 на ДЦ - да 16 Spine. Вылучым па /26 на рэгіён.
   • Edge-Leaf - па / 29 на ДЦ - да 8 каробак. Вылучым па /27 на рэгіён.

Калі ў ДЦ нам не будзе хапаць выдзеленых дыяпазонаў (а іх не будуць - мы ж прэтэндуем на гіперскейлераства), проста вылучаем наступны блок.

Вось такая карціна з IP-адрасацыяй.

Loopback'і:

прэфікс
Роля прылады
Рэгіён
ДЦ

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
ша

172.16.0.72/29
абодва

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
ша

172.16.2.144/28
абодва

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
ша

172.16.12.128/25
абодва

Падкладка:

прэфікс
Рэгіён
ДЦ

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
ша

10.1.32.0/19
абодва

Лаба

Два вендары. Адна сетка. АДСМ.

Juniper + Arista. Ubuntu. Старая добрая Ева.

Колькасць рэсурсаў на нашай віртуалачцы ў Міране ўсё ж абмежавана, таму для практыкі мы будзем выкарыстоўваць вось такую ​​спрошчаную да мяжы сетку.

Два датацэнтры: Казань і Барселона.

• Па два спайны ў кожным: Juniper і Arista.
• Па адным тору (Leaf'у) у кожным – Juniper і Arista, з адным падлучаным хастом (возьмем легкаважны Cisco IOL для гэтага).
• Па адной нодзе Edge-Leaf (пакуль толькі Juniper).
• Адзін Cisco вывучыць усе гэтыя.
• Акрамя сеткавых каробак запушчана віртуальная машына-кіраўніка. Пад кіраваннем Ubuntu.
  Яна мае доступ да ўсіх прылад, на ёй будуць круціцца IPAM / DCIM-сістэмы, букет пітонаўскіх скрыптоў, анзібль і што заўгодна яшчэ, што нам можа спатрэбіцца.

Поўная канфігурацыя усіх сеткавых прылад, якую мы будзем спрабаваць прайграць з дапамогай аўтаматыкі.

Заключэнне

Гэтак жа прынята? Пад кожным артыкулам рабіць кароткую выснову?

Дык вось, мы выбралі трохузроўневую сетку Клоза ўнутры ДЦ, паколькі чакаем шмат East-West трафіку і хочам ECMP.

Падзялілі сетку на фізічную (андэрляў) і віртуальную (оверлей). Пры гэтым оверлей пачынаецца з хаста - тым самым спрасцілі патрабаванні да андэрлея.

Выбралі BGP у якасці пратакола маршрутызацыі анерэлейных сетак за яго маштабаванасць і гнуткасць палітык.

У нас будуць асобныя вузлы для арганізацыі DCI - Edge-leaf.
На магістралі будзе OSPF+LDP.
DCI будзе рэалізаваны на аснове MPLS L3VPN.
Для P2P-лінкаў IP-адрасы мы будзем вылічаць алгарытмічна на аснове імёнаў прылад.
Лупбэкі будзем прызначаць па ролі прылад і іх размяшчэнню паслядоўна.
Андэрлейныя прэфіксы - толькі на Leaf-камутатары паслядоўна на аснове іх размяшчэння.

Выкажам здагадку, што прама зараз у нас яшчэ не ўсталявана абсталяванне.
Таму нашы наступныя крокі будуць - завесці іх у сістэмах (IPAM, інвентарная), арганізаваць доступ, згенераваць канфігурацыю і задэплоіць яе.

У наступным артыкуле разбярэмся з Netbox - сістэмай інвентарызацыі і кіравання IP-прасторай у ДЦ.

Дзякуй

• Андрэю Глазкову aka @glazgoo за вычытку і праўкі
• Аляксандру Кліменку aka @v00lk за вычытку і праўкі
• Арцёму Чарнабаю за КДПВ

Крыніца: habr.com