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

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

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

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

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

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

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

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

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

Съдържание

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

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

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

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

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

Локации

LAN_DC ще има 6 дата центъра:

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

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

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

Вътре в дата центъра (Intra-DC)

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

Във всеки дата център има по 10 рафта с машини, те ще бъдат номерирани като A, Б, C И така нататък.

На всеки рафт по 30 машини. Те няма да ни интересуват.

Също така на всеки рафт има комутатор, към който са свързани всички машини — това е Top of the Rack switch — ToR или иначе в термините на фабриката Clos ще го наречем 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 наистина съм разположил на едно ниво. Класическите тристепенни мрежи създадоха у нас навика да разглеждаме uplink (всъщност оттук идва терминът) като линкове нагоре. А тук излиза, че "uplink" 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-ите underlay се поставя в VPN и се предава през MPLS магистралата (онзи директен линк).

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

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

За маршрутизация вътре в ДЦ ще използваме BGP.
На MPLS магистралата OSPF+LDP.
За DCI, т.е. организиране на свързаност в underlay — BGP L3VPN през 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 ще импортируем Loopback адресите в 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) вече е в списъка.

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

Въпреки това, агрегираните маршрути от други DC ще достигат безпрепятствено до ТоР-ите — в техния AS-Path ще има само ASN 65535 — номерът на AS Edge-Leaf, защото именно на тях те са създадени.

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

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

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

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

Leaf ASN

Ще имаме индивидуален ASN на всеки Leaf комутатор в цялата мрежа.
Правим го така поради горепосочените причини: AS-Path без цикли, конфигурация BGP без вложки.

За да могат маршрутите между Leaf-овете да минават безпрепятствено, AS-Path трябва да изглежда така:
[leafX_ASN, spine_ASN, leafY_ASN]
където leafX_ASN и leafY_ASN е добре да се различават.

Това е необходимо и за ситуацията с анонса на лупбека VNF между 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. Адресите на мрежата Underlay между ToR и машината. Те трябва да бъдат уникални в цялата мрежа, за да може всяка машина да се свърже с всяка друга. Перфектно подхоаят 10/8. На всеки шкаф по /26 в излишък. Ще отделим по /19 за DC и /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
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
sha

172.16.0.72/29
sia

172.16.2.0/23
spine
 
 

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
sha

172.16.2.144/28
sia

172.16.8.0/21
leaf
 
 

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
sha

172.16.12.128/25
sia

Underlay:

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

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
sha

10.1.32.0/19
sia

Лаборатория

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

Благодаря

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

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