В първите две статии повдигнах въпроса за автоматизацията и очертах нейната рамка, във втората направих отклонение във виртуализацията на мрежата като първи подход за автоматизиране на конфигурацията на услугата.
И сега е време да начертаете диаграма на физическата мрежа.

Ако не сте на крачка с организирането на мрежи от центрове за данни, тогава силно препоръчвам да започнете с статии за тях.

Всички версии:

• 0. ADSM. Част нула. Планиране
• 1. ADSM. Първа част (която е след нулата). Мрежова виртуализация
• 2. ADSM. Част две. Мрежов дизайн

Практиките, описани в тази серия, трябва да са приложими за всеки тип мрежа, всякакъв мащаб и всякакво разнообразие от доставчици (не). Невъзможно е обаче да се опише универсален пример за прилагането на тези подходи. Затова ще се съсредоточа върху съвременната архитектура на DC мрежата: Фабрика Клоз.
Ще направим DCI на MPLS L3VPN.

Върху физическата мрежа има Overlay мрежа от хоста (това може да бъде VXLAN на OpenStack или Tungsten Fabric или нещо друго, което изисква само основна IP свързаност от мрежата).

В този случай получаваме сравнително прост сценарий за автоматизация, тъй като имаме много оборудване, конфигурирано по същия начин.

Ще изберем сферичен DC във вакуум:

• Една версия на дизайна навсякъде.
• Двама доставчици, образуващи две мрежови равнини.
• Един DC е като друг като две капки вода.

Съдържание

• Физическа топология
• Маршрутизиране
• IP план
• Лаба
• Заключение
• Полезни връзки

Нека нашият доставчик на услуги LAN_DC, например, да хоства обучителни видеоклипове за оцеляване на блокирани асансьори.

В мегаполисите това е изключително популярно, така че имате нужда от много физически машини.

Първо ще опиша мрежата приблизително така, както бих искал да я видя. И тогава ще опростя за лабораторията.

Физическа топология

Местоположения

LAN_DC ще има 6 DC:

• Русия (RU):
  • Москва (MSK)
  • Казан (кзн)

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

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

Вътре в DC (Intra-DC)

Всички DC имат идентични вътрешни мрежи за свързване, базирани на топологията на Klose.
Какво представляват мрежите Kloz и защо точно са – в отделна Статия.

Всеки DC има 10 стелажа с коли, те ще бъдат номерирани като A, B, C И така нататък.

Във всяка стойка има 30 машини. Те няма да ни интересуват.

Освен това във всяка стойка има превключвател, към който са свързани всички машини - това е Горен превключвател Rack - ToR или по друг начин, от гледна точка на фабриката на Клозе, ще го наречем Листо.

Обща схема на завода.

Ще ги назовем XXX-листYКъдето XXX - трибуквено съкращение DC, и Y - сериен номер. Например, kzn-лист11.

В моите статии ще си позволя да използвам термините Leaf и ToR доста несериозно като синоними. Трябва обаче да се помни, че това не е така.
ToR е монтиран в шкаф суич, към който се свързват машините.
Leaf е ролята на устройство във физическа мрежа или комутатор от първо ниво по отношение на топологията на Klose.
Тоест Leaf != ToR.
Така че Leaf може да бъде превключвател EndofRaw например.
Но в рамките на тази статия ще ги третираме като синоними.

Всеки ToR превключвател на свой ред е свързан с четири по-високи превключватели за агрегиране - гръбначен стълб. Под Spine's, един стелаж е разпределен в DC. Ще го кръстим така: XXX-гръбначен стълбY.

В същия шкаф ще има мрежово оборудване за връзка между DC-та - 2 рутера с MPLS на борда. Но като цяло това са същите Tors. Тоест, от гледна точка на превключвателите Spine, няма значение какво е обичайното ToR със свързани машини или рутер за DCI - едно проклето нещо.

Такива специални ТЗ се наричат Edge-лист. Ще ги назовем XXX-ръб, крайY.

Ще изглежда така.

В диаграмата по-горе наистина поставих ръба и листа на едно ниво. Класически трислойни мрежи ни научи да разглеждаме връзката нагоре (всъщност, оттук и терминът) като връзки нагоре. И тук се оказва, че DCI „uplink“ се връща обратно, което малко нарушава обичайната логика за някои. В случай на големи мрежи, когато центровете за данни са разделени на още по-малки единици - POD's (точка на доставка), разпределете индивидуално Edge-PODе за DCI и достъп до външни мрежи.

За по-лесно възприемане в бъдеще все пак ще нарисувам Edge над Spine, като същевременно ще имаме предвид, че няма интелигентност на Spine и няма разлики при работа с обикновен лист и с Edge-leaf (въпреки че може да има нюанси , но като цяло Това е вярно).

Фабрична схема с Edge-leafs.

Триединството Leaf, Spine и Edge образуват Underlay мрежа или фабрика.

Задачата на мрежовата фабрика (прочетете Underlay), както вече дефинирахме в последен брой, много, много просто - да се осигури IP свързаност между машини както в рамките на един и същ DC, така и между тях.
Ето защо мрежата се нарича фабрика, точно както, например, фабрика за превключване в модулни мрежови кутии, за които можете да прочетете повече в SDSM14.

Най-общо подобна топология се нарича фабрика, защото fabric в превод е тъкан. И е трудно да не се съглася:

Фабрично е изцяло L3. Без VLAN, без Broadcast - това са прекрасните програмисти, които имаме в LAN_DC, те могат да пишат приложения, които живеят в парадигмата L3, а виртуалните машини не изискват Live Migration със запазване на IP адреса.

И още веднъж: отговорът на въпроса защо заводът и защо L3 е в отделен Статия.

DCI - Взаимосвързаност на центъра за данни (Inter-DC)

DCI ще се организира с помощта на Edge-Leaf, тоест те са нашата изходна точка към магистралата.
За простота приемаме, че DC са свързани помежду си чрез директни връзки.
Нека изключим от разглеждане външната връзка.

Наясно съм, че всеки път, когато премахна компонент, значително опростявам мрежата. И когато автоматизираме нашата абстрактна мрежа, всичко ще бъде наред, но на истинската ще се появят патерици.
Това е вярно. И все пак целта на тази поредица е да се мисли и работи върху подходи, а не героично да се решават измислени проблеми.

На Edge-Leafs подложката се поставя във VPN и се предава през MPLS гръбнака (същата директна връзка).

Ето такава схема от най-високо ниво се получава.

Маршрутизиране

За маршрутизиране в рамките на DC ще използваме BGP.
На OSPF+LDP MPLS гръбнака.
За DCI, тоест организацията на свързаността в подложката - BGP L3VPN през MPLS.

Обща маршрутна схема

Фабрично няма OSPF и ISIS (протоколът за маршрутизиране е забранен в Руската федерация).

А това означава, че няма да има автоматично откриване и изчисляване на най-кратките пътища - само ръчни (всъщност автоматични - тук говорим за автоматизация) настройки на протокол, съседство и правила.

Схема за маршрутизиране на BGP вътре в DC

Защо BGP?

Има цял RFC кръстен на Facebook и Arista, който казва как да се изгражда много голям мрежи от центрове за данни, използващи BGP. Чете се почти като художествена измислица, горещо го препоръчвам за бавна вечер.

Има и цял раздел в моята статия, посветен на това. Къде мога да те заведа и изпрати.

Но все пак, накратко, никой IGP не е подходящ за мрежи от големи центрове за данни, където броят на мрежовите устройства отива в хиляди.

Освен това използването на BGP навсякъде ще ви позволи да не пръскате поддръжка на няколко различни протокола и синхронизация между тях.

Ръка на сърцето, в нашата фабрика, която най-вероятно няма да се развива бързо, OSPF би ни бил достатъчен за очите. Това всъщност е проблемът на мега скалърите и облачните титани. Но нека да си представим само за няколко издания, че ни трябва, и ще използваме BGP, както завеща Петър Лапухов.

Политики за маршрутизиране

На Leaf превключватели импортираме префикси от мрежови интерфейси Underlay в BGP.
Ще имаме BGP сесия между всеки двойка Leaf-Spine, в която тези префикси Underlay ще бъдат обявени по мрежата тук и там.

В рамките на един център за данни ще разпределим спецификите, които импортирахме в Tor. На Edge-Leafs ще ги обобщим и ще ги обявим на отдалечени DC и ще ги изпратим надолу към Tors. Тоест всеки Tor ще знае точно как да стигне до друг Tor в същия DC и къде е входната точка за достигане до Tor в друг DC.

В DCI маршрутите ще се предават като VPNv4. За да направите това, на Edge-Leaf интерфейсът към фабриката ще бъде поставен във VRF, нека го наречем UNDERLAY, а кварталът с гръбнака на Edge-Leaf ще се издигне вътре в VRF и между Edge-Leafs в семейството VPNv4.

Също така ще забраним повторното обявяване на маршрути, получени от spines обратно към тях.

На Leaf и Spine няма да импортираме Loopbacks. Ще ни трябват само за определяне на ID на рутера.

Но на Edge-Leafs го импортираме в Global BGP. Между Loopback адресите, Edge-Leafs ще установят BGP сесия в IPv4 VPN-семейство един с друг.

Между EDGE устройствата ще имаме магистрала, разтегната до OSPF + LDP. Всичко в една зона. Изключително проста конфигурация.

Ето снимка с рутинг.

BGP ASN

Edge Leaf ASN

На Edge-Leafs ще има един ASN във всички DC. Важно е да има iBGP между Edge-Leafs и ние не се сблъскваме с нюансите на eBGP. Нека да е 65535. В действителност може да е публичен AS номер.

Гръбначен стълб ASN

На Spine ще имаме един ASN на DC. Да започнем тук от първото число от обхвата на частните АС - 64512, 64513 и т.н.

Защо ASN на DC?

Нека разделим този въпрос на две:

• Защо един и същ ASN на всички спинове на един DC?
• Защо са различни в различните DC?

Защо един и същ ASN на всички спинове на един DC

Ето как ще изглежда AS-пътят на основния маршрут на Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Когато се опитвате да го съобщите обратно на Spine, той ще бъде отхвърлен, защото неговият AS (Spine_AS) вече е в списъка.

Въпреки това, в рамките на DC, ние сме напълно доволни, че маршрутите Underlay, които са се издигнали до Edge, няма да могат да слязат надолу. Цялата комуникация между хостовете в рамките на DC трябва да се извършва в рамките на нивото на шипове.

В същото време агрегираните маршрути на други DC във всеки случай ще достигнат свободно до Tors - техният AS-Path ще съдържа само ASN 65535 - броят на AS Edge-Leafs, защото именно върху тях са създадени.

Защо са различни в различните DC

Теоретично може да се наложи да плъзгаме Loopback и някои сервизни виртуални машини между DC.

Например на хоста ще стартираме Route Reflector или същият VNGW (Virtual Network Gateway), който ще се заключи с Tor чрез 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 би било хубаво да са различни.

Това също се изисква за ситуацията с обявяването на VNF loopback между DC:
[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. Подложете мрежови адреси между 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 Spine в DC. Адресите на връзките могат (и ще) се повтарят от DC към DC.

3. Joint Spine - Edge-Leaf организира в подмрежи 169.254.10X.Y/31, където точно същото X - Номер на гръбнака, Y — P2P мрежа /31.
4. Свързване на адреси от Edge-Leaf към MPLS backbone. Тук ситуацията е малко по-различна - свързването на всички парчета в един пай, така че няма да можете да използвате повторно едни и същи адреси - трябва да изберете следващата свободна подмрежа. Следователно, ние приемаме като основа 192.168.0.0/16 и ние ще се освободим от него.
5. Обратни адреси. Нека им дадем цялата гама 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
кзн

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
кзн

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
кзн

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
кзн

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

Лаба

Двама продавачи. Една мрежа. ADSM.

Хвойна + Ариста. Ubuntu. Добрата стара Ив.

Количеството ресурси на нашата виртуална машина в Miran все още е ограничено, така че за практика ще използваме такава опростена мрежа до краен предел.

Два центъра за данни: Казан и Барселона.

• По две завъртания: Juniper и Arista.
• По един тор (Leaf) във всеки - 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, система за инвентаризация и управление на IP пространство в DC.

Благодаря

• Андрей Глазков aka @glazgoo за корекция и редакция
• Alexandru Klimenko aka @v00lk за корекция и редакция
• Артьом Чернобай за KDPV

Източник: www.habr.com