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

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

Всички издания:

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

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

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

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

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

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

Съдържание

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

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

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

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

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

Локации

LAN_DC ще има 6 DCI:

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

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

• Китай (CN):
  • Шанхай (sha)
  • Сиан (sia)

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

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

Във всеки DCI има по 10 стойки с машини, те ще се номерират като A, B, C И така нататък.

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

Също така в всяка стойка има комутатор, към който са свързани всички машини – това е Top of the Rack switch – ToR или иначе в термините на фабриката Клоза, ще го наречем Leaf.

Общата схема на фабриката.

Ще ги именуваме XXX-leafY, където XXX — тробуквено съкращение ДЦ, а Y — пореден номер. Например, kzn-leaf11.

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

Всеки ToR-комутатор от своя страна е свързан с четири по-високи агрегиращи комутатори — Spine. За Spine-ите е отделена по една стойка в ДЦ. Ще ги именуваме аналогично: XXX-spineY.

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

Такива специални ToR-и се наричат Edge-leaf. Ще ги наричаме XXX-edgeY.

Това ще изглежда така.

На схемата по-горе 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 с запазване на IP адреса.

И отново: отговорът на въпроса защо фабрика и защо L3 — е в отделен статията.

DCI — Data Center Interconnect (Inter-DC)

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

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

На Edge-Leaf-ите подслоето се поставя в VPN и се предава чрез MPLS магистралата (тези директни връзки).

Ето такава изгледна схема се получава.

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

За маршрутизация в ДЦ ще използваме BGP.
На MPLS магистралата OSPF+LDP.
За DCI, тоест организацията на свързаност в подслоето — BGP L3VPN over MPLS.

Общата схема за маршрутизация

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

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

Схемата за маршрутизация на BGP в ДЦ

Защо BGP?

Тази тема има цял RFC на име Facebook и 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 в всички дата центрове. Това е важно, за да имаме iBGP между Edge-Leaf-ите и да избегнем нюансите на eBGP. Нека това бъде 65535. В действителност, това би могло да бъде номер на публичен AS.

Spine ASN

На Spine ще имаме един ASN на дата център. Ще започнем тук с най-ниския номер от диапазона на частни AS — 64512, 64513 и така нататък.

Защо ASN на дата център?

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

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

Защо идентични ASN на всички спайнове в един дата център

Ето как ще изглежда AS-Path на маршрута на Underlay на Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
При опит да обявим обратно на Spine, той ще го отхвърли, тъй като неговият 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 между ТоР и машината. Те трябва да бъдат уникални в рамките на цялата мрежа, за да може всяка машина да се свърже с всяка друга. Отлично подхождат 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. Свързването на 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
edge
 
 

172.16.0.0/27
ру
 

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
sha

172.16.0.72/29
sia

172.16.2.0/23
spine
 
 

172.16.2.0/26
ру
 

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
sha

172.16.2.144/28
sia

172.16.8.0/21
leaf
 
 

172.16.8.0/23
ру
 

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
sha

172.16.12.128/25
sia

Underlay:

Префикс
Регион
ДЦ

10.0.0.0/17
ру
 

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
sha

10.1.32.0/19
sia

Лаборатория

Два вендора. Една мрежа. АДСМ.

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

Броят на ресурсите на нашата виртуалка в Мирана все пак е ограничен, затова за практиката ще използваме такава опростена до край мрежа.

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

• По два спайна в всеки: Juniper и Arista.
• По един тор (Leaf) в всеки — Juniper и Arista, с един свързан хост (ще вземем лековесен Cisco IOL за това).
• По една нода Edge-Leaf (засега само Juniper).
• Един комутатор Cisco, който да управлява всички.
• Освен мрежовите кутии, пусната е виртуална управленска машина. Под управлението на Ubuntu.
  Тя има достъп до всички устройства, на нея ще се въртят IPAM/DCIM системи, пакет от питоновски скриптове, Ansible и каквото и да е друго, от което можем да се нуждаем.

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

Заключение

Как стои въпросът? Под всяка статия има ли кратко резюме?

И така, избрахме три нива мрежа Клоза в ДЦ, тъй като очакваме много East-West трафик и искаме ECMP.

Разделихме мрежата на физическа (андерлей) и виртуална (оверлей). При това оверлеят започва от хоста — като по този начин опростихме изискванията към андерлея.

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

Ще имаме отделни възли за организиране на DCI — Edge-leaf.
На магистралата ще бъде OSPF+LDP.
DCI ще бъде реализиран на база MPLS L3VPN.
За P2P връзките IP адресите ще изчисляваме алгоритмично на базата на имената на устройствата.
Loopback адресите ще определяме според ролята на устройствата и тяхното местоположение последователно.
Андерлейните префикси — само на Leaf комутатори, последователно на база на тяхното местоположение.

Да предположим, че в момента нямаме изградено оборудване.
Следователно следващите ни стъпки ще бъдат — да ги добавим в системите (IPAM, инвентарна), да организираме достъпа, да генерираме конфигурация и да я внедрим.

В следващата статия ще разгледаме Netbox — система за инвентаризация и управление на IP пространството в ДЦ.

Благодаря

• На Андрей Глазков aka @glazgoo за ревизията и корекциите.
• На Александър Клименко aka @v00lk за ревизията и корекциите.
• На Артьом Чернобай за КДПВ.

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