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

Ако не сте запознаени со поставувањето мрежи на центри за податоци, тогаш силно препорачувам да започнете со статии за нив.

Сите прашања:

• 0. АДСМ. Нулта дел. Планирање
• 1. АДСМ. Прв дел (кој е после нула). Мрежна виртуелизација
• 2. АДСМ. Втор дел. Мрежен дизајн

Практиките опишани во оваа серија треба да бидат применливи за секаков тип на мрежа, која било големина, со различни продавачи (не). Сепак, невозможно е да се опише универзален пример за примена на овие пристапи. Затоа, ќе се фокусирам на модерната архитектура на DC мрежата: Фабрика Клоз.
Ќе направиме DCI на MPLS L3VPN.

Преклопена мрежа работи на врвот на физичката мрежа од домаќинот (ова може да биде OpenStack's VXLAN или Tungsten Fabric или што било друго што бара само основно IP-поврзување од мрежата).

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

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

• Една дизајнерска верзија насекаде.
• Двајца продавачи формираат два мрежни рамнини.
• Еден DC е како друг како два грашок во мешунка.

содржина

• Физичка топологија
• Рутирање
• ИП план
• Лаба
• Заклучок
• Корисни линкови

Дозволете нашиот давател на услуги LAN_DC, на пример, да организира видеа за обука за преживување во заглавени лифтови.

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

Прво, ќе ја опишам мрежата приближно каква што би сакал да биде. И тогаш ќе го поедноставам за лабораторијата.

Физичка топологија

Локација

LAN_DC ќе има 6 DC:

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

• Шпанија (SP):
  • Барселона (bcn)
  • Малага (млг)

• Кина (CN):
  • Шангај (sha)
  • Ксиан (и двете)

Внатре DC (Intra-DC)

Сите DC имаат идентични внатрешни мрежи за поврзување базирани на Clos топологијата.
Какви се тие Клос мрежи и зошто се во посебна Член.

Секој DC има 10 решетки со машини, тие ќе бидат нумерирани како A, B, C И така натаму.

Секоја решетка има 30 машини. Нема да не интересираат.

Исто така, во секоја решетка има прекинувач на кој се поврзани сите машини - ова е Врвот на прекинувачот Rack - ToR или инаку во однос на фабриката Клос ќе ја наречеме Лист.

Општ дијаграм на фабриката.

Ќе ги повикаме ХХХ- листYкаде ХХХ - кратенка со три букви DC, и Y - сериски број. На пример, kzn-лист11.

Во моите написи ќе си дозволам прилично несериозно да ги користам поимите Leaf и ToR како синоними. Сепак, мораме да запомниме дека тоа не е така.
ToR е прекинувач инсталиран во решетката на која се поврзани машините.
Leaf е улогата на уред во физичка мрежа или прекинувач од прво ниво во однос на Cloes топологијата.
Тоа е, Лист != ToR.
Така, Leaf може да биде прекинувач EndofRaw, на пример.
Сепак, во рамките на оваа статија ние сепак ќе ги третираме како синоними.

Секој ToR прекинувач е за возврат поврзан со четири агрегациски прекинувачи на повисоко ниво - Рбетот. Една решетка во DC е наменета за боцки. Слично ќе го именуваме: ХХХ- 'рбетотY.

Истиот багажник ќе содржи мрежна опрема за поврзување помеѓу DC - 2 рутери со MPLS на одборот. Но, во голема мера, ова се истите ToR. Тоа е, од гледна точка на прекинувачите на 'рбетот, вообичаениот ToR со поврзани машини или рутер за DCI воопшто не е важен - само препраќање.

Таквите специјални ToR се нарекуваат Работ-лист. Ќе ги повикаме ХХХ-идY.

Ќе изгледа вака.

На дијаграмот погоре, всушност ги поставив работ и листот на исто ниво. Класични трислојни мрежи Тие нè научија да го сметаме uplinking (оттука и терминот) како uplinks. И тука излегува дека DCI „uplink“ се враќа надолу, што за некои малку ја нарушува вообичаената логика. Во случај на големи мрежи, кога центрите за податоци се поделени на уште помали единици - POD‘s (точка на испорака), означете одделно Edge-POD's за DCI и пристап до надворешни мрежи.

За полесно согледување во иднина, сепак ќе цртам Edge over Spine, додека ќе имаме на ум дека на Spine нема интелигенција и нема разлики при работа со обичен Leaf и Edge-leaf (иако тука може да има нијанси , но генерално Ова е вистина).

Шема на фабрика со раб-листови.

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

Задачата на фабрика за мрежа (читај Underlay), како што веќе ја дефиниравме во последно издание, многу, многу едноставно - да се обезбеди IP конекција помеѓу машините и во ист DC и меѓу нив.
Затоа мрежата се нарекува фабрика, исто како, на пример, фабрика за префрлување во модуларни мрежни кутии, за кои можете да прочитате повеќе во СДСМ14.

Во принцип, таквата топологија се нарекува фабрика, бидејќи ткаенина во превод значи ткаенина. И тешко е да не се согласувате:

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

И уште еднаш: одговорот на прашањето зошто фабриката и зошто L3 е во посебна Член.

DCI - Интерконекција на центарот за податоци (Inter-DC)

DCI ќе се организира со користење на Edge-Leaf, односно тие се нашата излезна точка на автопатот.
За едноставност, претпоставуваме дека DC се поврзани едни со други со директни врски.
Дозволете ни да го исклучиме надворешното поврзување од разгледување.

Свесен сум дека секогаш кога отстранувам компонента, значително ја поедноставувам мрежата. И кога ќе ја автоматизираме нашата апстрактна мрежа, се ќе биде во ред, но на вистинската ќе има патерици.
Ова е вистина. Сепак, поентата на оваа серија е да се размислува и да се работи на пристапи, а не херојски да се решаваат имагинарни проблеми.

На Edge-Leafs, подлогата се става во VPN и се пренесува преку MPLS столбот (истата директна врска).

Ова е дијаграмот на највисоко ниво што го добиваме.

Рутирање

За рутирање во DC ќе користиме BGP.
На багажникот MPLS OSPF+LDP.
За DCI, односно организирање на поврзување во подземјето - BGP L3VPN преку MPLS.

Општа шема за рутирање

Во фабриката нема OSPF или ISIS (протокол за рутирање забранет во Руската Федерација).

Ова значи дека нема да има автоматско откривање или пресметување на најкратките патеки - само рачно (всушност автоматско - овде зборуваме за автоматизација) поставување на протоколот, соседството и политиките.

BGP рутирачка шема во рамките на DC

Зошто BGP?

На оваа тема постои цела RFC именуван по Facebook и Arista, кој кажува како да се изгради многу голем мрежи на центри за податоци кои користат BGP. Се чита речиси како фикција, топло го препорачувам за мачна вечер.

И, исто така, има цел дел во мојата статија посветена на ова. Каде да те одведам и Јас испраќам.

Но, сепак, накратко, ниту еден IGP не е погоден за мрежи на големи центри за податоци, каде што бројот на мрежни уреди изнесува илјадници.

Дополнително, користењето на BGP насекаде ќе ви овозможи да не губите време за поддршка на неколку различни протоколи и синхронизација помеѓу нив.

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

Политики за рутирање

На прекинувачите Leaf, внесуваме префикси од мрежните интерфејси Underlay во BGP.
Ќе имаме BGP сесија помеѓу секој пар Leaf-Spine, во кој овие префикси на Underlay ќе се објавуваат преку мрежата напред и назад.

Во рамките на еден центар за податоци, ќе ги дистрибуираме спецификациите што ги увезовме во ToRe. На Edge-Leafs ќе ги собереме и ќе ги објавиме на далечински DC и ќе ги испратиме до TOR. Односно, секој ToR точно ќе знае како да стигне до друг ToR во истиот DC и каде е влезната точка да се дојде до ToR во друг DC.

Во DCI, маршрутите ќе се пренесуваат како VPNv4. За да го направите ова, на Edge-Leaf, интерфејсот кон фабриката ќе биде поставен во VRF, да го наречеме UNDERLAY, а соседството со Spine на Edge-Leaf ќе се издигне во рамките на VRF, и помеѓу Edge-Leafs во VPNv4- семејството.

Ќе забраниме и повторно објавување на правци добиени од боцки назад до нив.

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

Но, на Edge-Leafs го увезуваме во Global BGP. Помеѓу Loopback адресите, Edge-Leafs ќе воспостави BGP сесија во IPv4 VPN-семејството едни со други.

Ќе имаме OSPF+LDP столб помеѓу EDGE уредите. Сè е во една зона. Исклучително едноставна конфигурација.

Ова е сликата со рутирање.

БГП АСН

Edge-Leaf ASN

Edge-Leafs ќе има еден ASN во сите DC. Важно е да постои iBGP помеѓу Edge-Leafs и да не се заглавуваме во нијансите на eBGP. Нека биде 65535. Во реалноста, ова може да биде бројот на јавен AS.

'Рбет ASN

На 'рбетот ќе имаме еден ASN по DC. Да почнеме овде со првиот број од опсегот на приватни AS - 64512, 64513 И така натаму.

Зошто ASN на DC?

Ајде да го поделиме ова прашање на две:

• Зошто ASN се исти на сите боцки на еден DC?
• Зошто тие се различни во различни DC?

Зошто се исти ASN на сите боцки на едно DC?

Вака ќе изгледа AS-Path на патеката Underlay на 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), кој ќе се заклучи со TopR преку 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 и покрај механизмот за спречување на јамка (дозволува влез на Cisco). И дури има легитимна употреба. Но, ова е потенцијален јаз во стабилноста на мрежата. И јас лично паднав во тоа неколку пати.

И ако имаме можност да не користиме опасни работи, ќе ја искористиме.

Лист ASN

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

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

Ова е потребно и за ситуацијата со објавување на VNF loopback помеѓу DCs:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Ќе користиме ASN од 4 бајти и ќе го генерираме врз основа на ASN на 'рбетот и бројот на прекинувачот Leaf, имено, вака: Spine_ASN.0000X.

Ова е сликата со АСН.

ИП план

Во основа, треба да доделиме адреси за следните врски:

1. Поставете ги мрежните адреси помеѓу ToR и машината. Тие мора да бидат единствени во целата мрежа, така што секоја машина може да комуницира со која било друга. Одлично се вклопуваат 10/8. За секоја решетка има /26 со резерва. Ќе доделиме /19 по DC и /17 по регион.
2. Поврзете ги адресите помеѓу Leaf/Tor и Spine.

   Би сакал да ги доделам алгоритамски, односно да ги пресметам од имињата на уредите што треба да се поврзат.

   Нека биде... 169.254.0.0/16.
   Имено 169.254.00X.Г/31каде X - Број на 'рбетот, Y — P2P мрежа /31.
   Ова ќе ви овозможи да лансирате до 128 решетки и до 10 боцки во DC. Адресите за врски може (и ќе) се повторуваат од DC до DC.

3. Ние го организираме спојот Spine-Edge-Leaf на подмрежи 169.254.10X.Г/31, каде токму истото X - Број на 'рбетот, Y — P2P мрежа /31.
4. Поврзете адреси од Edge-Leaf до MPLS столбот. Овде ситуацијата е нешто поинаква - местото каде што сите парчиња се поврзани во една пита, така што повторното користење на истите адреси нема да работи - треба да ја изберете следната бесплатна подмрежа. Затоа, да го земеме како основа 192.168.0.0/16 и ние ќе ги извадиме слободните од него.
5. Loopback адреси. За нив ќе го дадеме целиот асортиман 172.16.0.0/12.
   • Лист - /25 по DC - истите 128 лавици. Ќе доделиме /23 по регион.
   • 'Рбет - /28 по DC - до 16'Рбет. Ајде да одвоиме /26 по регион.
   • Edge-Leaf - /29 по DC - до 8 кутии. Ајде да одвоиме /27 по регион.

Ако немаме доволно доделени опсези во DC (а нема да има - тврдиме дека сме хиперскалери), едноставно го избираме следниот блок.

Ова е сликата со IP адресирање.

Повратни информации:

Префикс
Улогата на уредот
Регионот
ДЦ

172.16.0.0/23
работ
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
мкс

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
и двете

172.16.2.0/23
'рбетот
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
мкс

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
и двете

172.16.8.0/21
лист
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
мкс

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
и двете

Подлога:

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

10.0.0.0/17
ru
 

10.0.0.0/19
мкс

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
и двете

Лаба

Двајца продавачи. Една мрежа. АДСМ.

Џунипер + Ариста. Ubuntu. Добра стара Ева.

Количината на ресурси на нашиот виртуелен сервер во Мирана е сè уште ограничена, така што за пракса ќе користиме мрежа која е поедноставена до крај.

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

• По две боцки: Џунипер и Ариста.
• По еден торус (лист) во секој - Џунипер и Ариста, со еден поврзан домаќин (ајде да земеме лесен Cisco IOL за ова).
• Секој Edge-Leaf јазол (засега само Juniper).
• Еден Cisco прекинувач за да владее со сите нив.
• Покрај мрежните кутии, работи и виртуелна контролна машина. Вклучување на Ubuntu.
  Има пристап до сите уреди, ќе работи IPAM/DCIM системи, еден куп Python скрипти, Ansible и се друго што можеби ни треба.

Целосна конфигурација од сите мрежни уреди, кои ќе се обидеме да ги репродуцираме користејќи автоматизација.

Заклучок

Дали е и тоа прифатено? Дали треба да напишам краток заклучок под секоја статија?

Така избравме три нивоа Клоз мрежа внатре во DC, бидејќи очекуваме многу сообраќај Исток-Запад и сакаме ECMP.

Мрежата беше поделена на физичка (подлога) и виртуелна (преклопување). Во исто време, преклопувањето започнува од домаќинот - со што се поедноставуваат барањата за подлогата.

Го избравме BGP како протокол за рутирање за мрежни мрежи поради неговата приспособливост и флексибилност на политиките.

Ќе имаме посебни јазли за организирање на DCI - Edge-leaf.
'Рбетот ќе има OSPF+LDP.
DCI ќе се имплементира врз основа на MPLS L3VPN.
За P2P врски, ќе ги пресметаме IP адресите алгоритамски врз основа на имињата на уредите.
Ќе доделиме повратни врати според улогата на уредите и нивната локација последователно.
Префикси на подлогата - само на прекинувачите со листови секвенцијално врз основа на нивната локација.

Да претпоставиме дека во моментов сè уште немаме инсталирана опрема.
Затоа, нашите следни чекори ќе бидат да ги додадеме во системите (IPAM, инвентар), да организираме пристап, да генерираме конфигурација и да ја распоредиме.

Во следната статија ќе се занимаваме со Netbox - систем за инвентар и управување за IP простор во DC.

Ви благодарам

• Андреј Глазков ака @glazgoo за лекторирање и корекции
• Александар Клименко aka @v00lk за лекторирање и уредување
• Артјом Чернобај за KDPV

Извор: www.habr.com