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

Гэты ж фрэймворк задае парадак, у якім мы будзем разбірацца з пытаннем.
І віртуалізацыя сеткі, якой прысвечаны гэты выпуск, не асоба ўкладваецца ў тэматыку АДСМ, дзе мы разбіраем аўтаматыку.

Але давайце зірнем на яе пад іншым кутом.

Ужо даўно адной сеткай карыстаюцца шматлікія сервісы. У выпадку аператара сувязі гэта 2G, 3G, LTE, ШПД і B2B, напрыклад. У выпадку ДЦ: складнасць для розных кліентаў, Інтэрнэт, блокавае сховішча, аб'ектнае сховішча.

І ўсе сэрвісы патрабуюць ізаляцыі сябар ад сябра. Так з'явіліся аверлейныя сеткі.

І ўсе сэрвісы не жадаюць чакаць, калі чалавек наладзіць іх уручную. Так з'явіліся аркестратары і SDN.

Першы падыход да сістэматычнай аўтаматызацыі сеткі, дакладней яе часткі, даўно зроблены і шмат дзе ўкаранёны ў жыццё: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Вось з ім сёння і разбіраемся.

Змест

• прычыны
• тэрміналогія
• Underlay - фізічная сетка
• Overlay - віртуальная сетка
  • Overlay з ToR'a
  • Overlay з хаста
  • На прыкладзе Tungsten Fabric
    • Камунікацыя ўнутры адной фізічнай машыны
    • Камунікацыя паміж ВМ, размешчанымі на розных фізічных машынах
    • Выхад у знешні свет

• Часта задаваныя пытанні
• Заключэнне
• Карысныя спасылкі

прычыны

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

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

Каб не чакаць, калі сецявікі пракінуць VLAN і любыя сэрвісы не прапісваць на кожным вузле сеткі, людзі прыдумалі выкарыстоўваць оверлеи – накладзеныя сеткі – якіх вялікая разнастайнасць: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE

Іх прывабнасць заключаецца ў двух простых рэчах:

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

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

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

На гэтым абсталяванні запускаюцца віртуальныя машыны/кантэйнеры/серверлес, якія рэалізуюць сэрвісы.

тэрміналогія

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

Фізічныя машыны ў стойках зваць серверамі ня будзем.

Фізічная машына - x86-кампутар, усталяваны ў стойцы. Найбольш часта ўжытны тэрмін хост. Так і будзем называць яе «машына»або хост.

Гіпервізар - Прыкладанне, запушчанае на фізічнай машыне, якое эмулюе фізічныя рэсурсы, на якіх запускаюцца Віртуальныя Машыны. Часам у літаратуры і сетцы слова «гіпервізар» выкарыстоўваюць як сінонім «хост».

Віртуальная машына - аперацыйная сістэма, запушчаная на фізічнай машыне па-над гіпервізарам. Для нас у рамках дадзенага цыклу не так ужо важна, ці насамрэч гэта віртуальная машына ці проста кантэйнер. Будзем называць гэта «ВМ«

Тэнант - Шырокае паняцце, якое я ў гэтым артыкуле вызначу як асобны сэрвіс або асобны кліент.

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

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

Акрамя тапалогіі ToR, розныя правайдэры практыкуюць End of Row (EoR) або Middle of Row (хоць апошняе - грэблівая рэдкасць і абрэвіятуры MoR я не сустракаў).

Underlay network або падлягаючая сетка або андэрлей - фізічная сеткавая інфраструктура: камутатары, маршрутызатары, кабелі.

Overlay network або накладзеная сетка або оверлей - віртуальная сетка тунэляў, якая працуе па-над фізічнай.

L3-фабрыка ці IP-фабрыка - Неверагоднае вынаходства чалавецтва, якое дазваляе да сумоўяў не паўтараць STP і не вучыць TRILL. Канцэпцыя, у якой уся сетка аж да ўзроўня доступу вылучна L3, без VLAN і адпаведна велізарных расцягнутых шырокавяшчальных даменаў. Адкуль тут слова "фабрыка" разбярэмся ў наступнай частцы.

SDN - Software Defined Network. Ці ледзь мае патрэбу ва ўяўленні. Падыход да кіравання сеткай, калі змены на сетцы выконваюцца не чалавекам, а праграмай. Звычайна азначае вынясенне Control Plane за межы канчатковых сеткавых прылад на кантролер.

NFV – Network Function Virtualization – віртуалізацыя сеткавых прылад, якая прадугледжвае, што частка функцый сеткі можна запускаць у выглядзе віртуальных машын або кантэйнераў для паскарэння ўкаранення новых сэрвісаў, арганізацыі Service Chaining і прасцейшай гарызантальнай маштабаванасці.

ВНФ - Virtual Network Function. Канкрэтная віртуальная прылада: маршрутызатар, камутатар, файрвол, NAT, IPS/IDS і т.д.

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

Большасць сетак сёння можна відавочна разбіць на дзве часткі:

Падкладка - фізічная сетка са стабільнай канфігурацыяй.
Накладанне - абстракцыя над Underlay для ізаляцыі тэнантаў.

Гэта дакладна, як для выпадку ДЦ (які мы разбяром у гэтым артыкуле), так і для ISP (які мы разбіраць не будзем, таму што ўжо было ў СДСМ). З энтэрпрайзнымі сеткамі, вядома, сітуацыя некалькі іншая.

Малюнак з фокусам на сетку:

Падкладка

Underlay – гэта фізічная сетка: апаратныя камутатары і кабелі. Прылады ў андэрлеі ведаюць, як дабрацца да фізічных машын.

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

А вось хто-небудзь накшталт Гугла можа сабе дазволіць распрацоўку ўласных камутатараў і адмова ад агульнапрынятых пратаколаў. Але LAN_DC не Google.

Underlay параўнальна рэдка змяняецца, таму што яго задача – базавая IP-складнасць паміж фізічнымі машынамі. Underlay нічога не ведае аб запушчаных па-над ім сэрвісах, кліентах, тэнантах - яму трэба толькі даставіць пакет ад адной машыны да іншай.
Underlay можа быць напрыклад такім:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Наладжваецца Underlay'ная сетка класічнай выявай: CLI/GUI/NETCONF.

Уручную, скрыптамі, прапрыетарнымі ўтылітамі.

Больш падрабязна андэрлею будзе прысвечаны наступны артыкул цыкла.

Накладанне

Overlay – віртуальная сетка тунэляў, нацягнутая па-над Underlay, яна дазваляе ВМ аднаго кліента мець зносіны сябар з сябрам, пры гэтым забяспечваючы ізаляцыю ад іншых кліентаў.

Дадзеныя кліента інкапсулююцца ў якія-небудзь тунэлюючыя загалоўкі для перадачы праз агульную сетку.

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

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

• GRE-тунэль
• VXLAN
• EVPN
• L3VPN
• ЖЭНЭВА

Overlay'ная сетка звычайна наладжваецца і падтрымліваецца праз цэнтральны кантролер. З яго канфігурацыя, Control Plane і Data Plane дастаўляюцца на прылады, якія займаюцца маршрутызацыяй і інкапсуляцыяй кліенцкага трафіку. Ледзь ніжэй разбяром гэта на прыкладах.

Так, гэта SDN у чыстым выглядзе.

Існуе два прынцыпова адрозных падыходу да арганізацыі Overlay-сеткі:

1. Overlay з ToR'a
2. Overlay з хаста

Overlay з ToR'a

Overlay можа пачынацца на камутатары доступу (ToR), які стаіць у стойцы, як гэта адбываецца, напрыклад, у выпадку VXLAN-фабрыкі.

Гэта правераны часам на сетках ISP механізм і ўсе вендары сеткавага абсталявання яго падтрымліваюць.

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

Тут я пашлю чытача да артыкула аб VxLAN на хабры нашага старога сябра @bormoglotx.
У гэтай прэзентацыі з ENOG падрабязна апісаны падыходы да будаўніцтва сеткі ДЦ з EVPN VXLAN-фабрыкай.

А для больш поўнага апускання ў рэаліі, можна пачытаць цыскіну кнігу Modern, Open, Scalable Fabric: VXLAN EVPN.

Заўважу, што VXLAN – гэта толькі метад інкапсуляцыі і тэрмінацыя тунэляў можа адбывацца не на ToR'е, а на хасце, як гэта адбываецца ў выпадку OpenStack'а, напрыклад.

Аднак, VXLAN-фабрыка, дзе overlay пачынаецца на ToR'е з'яўляецца адным з устояных дызайнаў оверлейной сеткі.

Overlay з хаста

Іншы падыход - пачынаць і тэрмінаваць тунэлі на канчатковых хастах.
У гэтым выпадку сетка (Underlay) застаецца максімальна простай і статычнай.
А хост сам робіць усё неабходныя інкапсуляцыі.

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

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

Па-другое, ToR-камутатар у гэтым выпадку можна пакінуць максімальна простым, як з пункта гледжання Control Plane'а, так і Data Plane'а. Сапраўды – з SDN-кантролерам яму тады мець зносіны не трэба, і захоўваць сеткі/ARP'ы ўсіх падлучаных кліентаў – таксама – досыць ведаць IP-адрас фізічнай машыны, што кратна палягчае табліцы камутацыі/маршрутызацыі.

У серыі АДСМ я выбіраю падыход оверлея з хаста - далей мы гаворым толькі пра яго і вяртацца да VXLAN-фабрыцы мы ўжо не будзем.

Прасцей за ўсё разгледзець на прыкладах. І ў якасці паддоследнага мы возьмем OpenSource'ную SDN платформу OpenContrail, цяпер вядомую як Tungsten Fabric.

У канцы артыкула я прывяду некаторыя разважанні на тэму аналогіі з OpenFlow і OpenvSwitch.

На прыкладзе Tungsten Fabric

На кожнай фізічнай машыне ёсць vRouter - Віртуальны маршрутызатар, які ведае аб падлучаных да яго сетках і якім кліентам яны належаць - па сутнасці - PE-маршрутызатар. Для кожнага кліента ён падтрымлівае ізаляваную табліцу маршрутызацыі (чытай VRF). І ўласна vRouter робіць Overlay'нае тунэляванне.

Крыху падрабязней пра vRouter – у канцы артыкула.

Кожная ВМ, размешчаная на гіпервізоры, злучаецца з vRouter'ом гэтай машыны праз TAP-інтэрфейс.

TAP - Terminal Access Point - віртуальны інтэрфейс у ядры linux, якія дазваляе ажыццяўляць сеткавае ўзаемадзеянне.

Калі за vRouter'ам знаходзіцца некалькі сетак, то для кожнай з іх ствараецца віртуальны інтэрфейс, на які прызначаецца IP-адрас - ён будзе адрасам шлюза па змаўчанні.
Усе сеткі аднаго кліента змяшчаюцца ў адзін VRF (адну табліцу), розных - у розныя.
Зраблю тут агаворку, што не ўсё так проста, і адпраўлю дапытлівага чытача ў канец артыкула.

Каб vRouter'ы маглі мець зносіны сябар з сябрам, а адпаведна і ВМ, змешчаныя за імі, яны абменьваюцца маршрутнай інфармацыяй праз SDN-кантролер.

Каб выбрацца ў знешні свет, існуе кропка выхаду з матрыцы - шлюз віртуальнай сеткі VNGW - Virtual Network GateWay (тэрмін мой).

Цяпер разгледзім прыклады камунікацый - і будзе яснасць.

Камунікацыя ўнутры адной фізічнай машыны

VM0 жадае адправіць пакет на VM2. Дапусцім пакуль, што гэта ВМ аднаго кліента.

Плоскасць дадзеных

1. У VM-0 ёсць маршрут па змаўчанні ў яго інтэрфейс eth0. Пакет адпраўляецца туды.
   Гэты інтэрфейс eth0 насамрэч віртуальна злучаны з віртуальным маршрутызатарам vRouter праз TAP-інтэрфейс tap0.
2. vRouter аналізуе на які інтэрфейс прыйшоў пакет, гэта значыць да якога кліента (VRF) ён ставіцца, звярае адрас атрымальніка з табліцай маршрутызацыі гэтага кліента.
3. Выявіўшы, што атрымальнік на гэтай жа машыне за іншым портам, vRouter проста адпраўляе пакет у яго без якія-небудзь дадатковых загалоўкаў - на гэты выпадак на vRouter'е ўжо ёсць ARP-запіс.

Пакет у гэтым выпадку не пападае ў фізічную сетку - ён змаршрутызаваўся ўсярэдзіне vRouter'а.

Плоскасць кіравання

Гіпервізар пры запуску віртуальнай машыны паведамляе ёй:

• Яе ўласны IP-адрас.
• Маршрут па змаўчанні - праз IP-адрас vRouter'а ў гэтай сетцы.

vRouter'у праз спецыяльны API гіпервізор паведамляе:

• Што трэба стварыць віртуальны інтэрфейс.
• Які ёй (ВМ) трэба стварыць Virtual Network.
• Да якога VRF яго (VN) прывязаць.
• Статычны ARP-запіс для гэтай VM – за якім інтэрфейсам знаходзіцца яе IP-адрас і да якога MAC-адрасу ён прывязаны.

І зноў, рэальная працэдура ўзаемадзеяння спрошчана для разумення канцэпцыі.

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

А вось VM0 і VM1 прыналежаць розным кліентам, адпаведна, знаходзяцца ў розных табліцах vRouter'а.

Ці змогуць яны сябар з сябрам мець зносіны напроста, залежыць ад налад vRouter і дызайну сеткі.
Напрыклад, калі ВМ абодвух кліентаў выкарыстоўваюць публічныя адрасы, ці NAT адбываецца на самым vRouter'е, то можна зрабіць і прамую маршрутызацыю на vRouter.

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

Камунікацыя паміж ВМ, размешчанымі на розных фізічных машынах

Плоскасць дадзеных

1. Пачатак сапраўды такое ж: VM-0 пасылае пакет з адрасатам VM-7 (172.17.3.2) па сваім дэфолце.
2. vRouter яго атрымлівае і на гэты раз бачыць, што адрасат знаходзіцца на іншай машыне і даступны праз тунэль Tunnel0.
3. Спачатку ён вешае пазнаку MPLS, якая ідэнтыфікуе выдалены інтэрфейс, каб на зваротным боку vRouter мог вызначыць куды гэты пакет змясціць прычым без дадатковых лукапаў.

   

4. У Tunnel0 крыніца 10.0.0.2, атрымальнік: 10.0.1.2.
   vRouter дадае загалоўкі GRE (ці UDP) і новы IP да зыходнага пакета.
5. У табліцы маршрутызацыі vRouter ёсць маршрут па змаўчанні праз адрас ToR1 10.0.0.1. Туды і адпраўляе.

   
   

6. ToR1 як удзельнік Underlay сеткі ведае (напрыклад, па OSPF), як дабрацца да 10.0.1.2, і адпраўляе пакет па маршруце. Звярніце ўвагу, што тут уключаецца ECMP. На ілюстрацыі два некстхопы, і розныя патокі будуць раскладвацца ў іх па хэшу. У выпадку сапраўднай фабрыкі тут будзе хутчэй за 4 некстхопы.

   Пры гэтым ведаць, што знаходзіцца пад вонкавым загалоўкам IP яму не трэба. Гэта значыць фактычна пад IP можа быць бутэрброд з IPv6 па-за грэкам.

7. Адпаведна на які прымае боку vRouter здымае GRE і па MPLS-пазнаку разумее, у які інтэрфейс гэты пакет трэба перадаць, распранае яго і адпраўляе ў першапачатковым выглядзе атрымальніку.

Плоскасць кіравання

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

І плюс яшчэ наступнае:

• Для кожнага кліента vRouter выдзяляе MPLS-пазнаку. Гэта сэрвісная пазнака L3VPN, па якой кліенты будуць падзяляцца ў межах адной фізічнай машыны.
  

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

• vRouter усталёўвае злучэнне з SDN-кантролерам па пратаколе BGP (ці падобнаму на яго – у выпадку TF -гэта XMPP 0_o).
• Праз гэтую сесію vRouter паведамляе SDN-кантролеру маршруты да падлучаных сетак:
  • Адрас сеткі
  • Метад інкапсуляцыі (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-пазнаку кліента
  • Свой IP-адрас у якасці nexthop

• SDN-кантролер атрымлівае такія маршруты ад усіх падлучаных vRouter'ов, і адлюстроўвае іх іншым. Гэта значыць ён выступае Route Reflector'ам.

Тое ж самае адбываецца і ў адваротны бок.

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

Цэнтральны кантролер бярэ на сябе ўсе складанасці з падтрыманнем канфігурацыі і кантролем табліц камутацыі/маршрутызацыі на vRouter.

Калі казаць груба, то кантролер замыкаецца са ўсімі vRouter'амі па BGP (ці падобнаму на яго пратаколу) і проста перадае маршрутную інфармацыю. BGP, напрыклад, ужо мае Address-Family для перадачы метаду інкапсуляцыі MPLS-in-GRE або MPLS-in-UDP.

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

Выхад у знешні свет

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

Практыкуюць два падыходы:

1. Ставіцца апаратны маршрутызатар.
2. Запускаецца які-небудзь appliance, які рэалізуе функцыі маршрутызатара (так-так, услед за SDN мы і з VNF сутыкнуліся). Назавем яго віртуальны шлюз.

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

Мінусы ж у віртуальнага шлюза ў тым, што адзінка фізічнага маршрутызатара ўсё ж на парадкі больш магутны шмат'ядравай віртуалкі, а яго софт, падагнаны пад яго ж апаратную аснову, працуе значна стабільней.няма). Складана адмаўляць і той факт, што праграмна-апаратны комплекс проста працуе, патрабуючы толькі наладкі, у той час як запуск і абслугоўванне віртуальнага шлюза – занятак для моцных інжынераў.

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

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

Плоскасць дадзеных

Гэта значыць працэс выглядае так:

1. VM-0, маючы дэфолт усё ў той жа vRouter, адпраўляе пакет з адрасатам у вонкавым свеце (185.147.83.177) у інтэрфейс eth0.
2. vRouter атрымлівае гэты пакет і робіць лукап адрасы прызначэння ў табліцы маршрутызацыі - знаходзіць маршрут па змаўчанні праз шлюз VNGW1 праз Tunnel 1.
   Таксама ён бачыць, што гэта тунэль GRE з SIP 10.0.0.2 і DIP 10.0.255.2, а яшчэ трэба спачатку павесіць MPLS-пазнаку дадзенага кліента, якую чакае VNGW1.
3. vRouter пакуе першапачатковы пакет у загалоўкі MPLS, GRE і новы IP і адпраўляе на адрас ToR1 10.0.0.1 па дэфолце.
4. Андэрлейная сетка дастаўляе пакет да шлюза VNGW1.
5. Шлюз VNGW1 здымае тунэлюючыя загалоўкі GRE і MPLS, бачыць адрас прызначэння, кансультуецца са сваёй табліцай маршрутызацыі і разумее, што ён накіраваны ў Інтэрнэт - значыць праз Full View або Default. Пры неабходнасці вырабляе NAT-трансляцыю.
6. Ад VNGW да бордэра можа быць звычайная IP-сетка, што ці наўрад.
   Можа быць класічная MPLS сетка (IGP+LDP/RSVP TE), можа быць зваротна фабрыка з BGP LU ці GRE-тунэль ад VNGW да бордэра праз IP-сетку.
   Як бы там ні было VNGW1 здзяйсняе неабходныя інкапсуляцыі і адпраўляе першапачатковы пакет у бок бордэра.

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

1. Бордэр дабрасывае пакет да VNGW1
2. Той яго распранае, глядзіць на адрас атрымальніка і бачыць, што той даступны праз тунэль Tunnel1 (MPLSoGRE ці MPLSoUDP).
3. Адпаведна, вешае пазнаку MPLS, загаловак GRE/UDP і новы IP і адпраўляе на свой ToR3 10.0.255.1.
   Адрас прызначэння тунэля – IP-адрас vRouter'а, за якім стаіць мэтавая ВМ – 10.0.0.2.
4. Андэрлейная сетка дастаўляе пакет да патрэбнага vRouter'а.
5. Мэтавы vRouter здымае GRE/UDP, па MPLS-пазнацы вызначае інтэрфейс і шле голы IP-пакет у свой TAP-інтэрфейс, злучаны з eth0 ВМ.

Плоскасць кіравання

VNGW1 усталёўвае BGP-суседства з SDN-кантролерам, ад якога ён атрымлівае ўсю маршрутную інфармацыю аб кліентах: за якім IP-адрасам (vRouter'ом) знаходзіцца які кліент, і які MPLS-пазнакай ён ідэнтыфікуецца.

Аналагічна ён сам SDN-кантролеру паведамляе дэфолтны маршрут з пазнакай гэтага кліента, паказваючы сябе ў якасці nexthop'а. А далей гэты дэфолт прыязджае на vRouter'ы.

На VNGW звычайна адбываецца агрэгацыя маршрутаў ці NAT-трансляцыя.

І ў іншы бок у сесію з бордэрамі ці Route Reflector'амі ён аддае менавіта гэты агрэгаваны маршрут. А ад іх атрымлівае маршрут па змаўчанні ці Full-View, ці нешта яшчэ.

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

І з дапамогай паслядоўнага стварэння VRF і правільнага анонсу маршрутаў, можна прымушаць трафік пятляць так, як вам жадаецца, што і завецца Service Chaining'ом.

Гэта значыць і тут SDN-кантролер выступае ў ролі Route-Reflector'а паміж VNGW, vRouter'амі і іншымі сеткавымі прыладамі.

Але фактычна кантролер спускае яшчэ інфармацыю аб ACL і PBR (Policy Based Routing), прымушаючы асобныя патокі трафіку хадзіць не так, як ім загадвае маршрут.

Часта задаваныя пытанні

Навошта ты ўвесь час робіш рэмарку GRE/UDP?

Ну, наогул, гэта, можна сказаць, спецыфічна для Tungsten Fabric можна наогул не браць ва-ўвага.

Але калі браць, то сам TF, яшчэ быўшы OpenContrail'ом падтрымліваў абедзве інкапсуляцыі: MPLS in GRE і MPLS in UDP.

UDP добры тым, што ў Source Port у яго загалоўку вельмі лёгка закадаваць хэш-функцыю ад першапачатковых IP+Proto+Port, што дазволіць рабіць балансаванне.

У выпадку GRE, нажаль, ёсць толькі вонкавыя загалоўкі IP і GRE, якія аднолькавыя для ўсяго інкапсуляванага трафіку і гаворка пра балансаванне не ідзе – мала хто можа зазірнуць так глыбока ўнутр пакета.

Да некаторага часу маршрутызатары, калі і ўмелі ў дынамічныя тунэлі, то толькі ў MPLSoGRE, і толькі зусім нядаўна, навучыліся ў MPLSoUDP. Таму даводзіцца рабіць заўсёды рэмарку аб магчымасці двух розных інкапсуляцый.

Справядлівасці дзеля, варта адзначыць, што TF суцэль падтрымлівае і L2-складнасць з дапамогай VXLAN.

Ты абяцаў правесці паралелі з OpenFlow.
Яны і праўда напрошваюцца. vSwitch у тым жа OpenStack'е робіць вельмі падобныя рэчы, выкарыстоўваючы VXLAN, у якога, дарэчы, таксама UDP-загаловак.

У Data Plane яны працуюць прыкладна аднолькава, істотна адрозніваецца Control Plane. Tungsten Fabric выкарыстоўвае XMPP для дастаўкі інфармацыі аб маршрутах на vRouter, у той час, як у OpenStack'е працуе Openflow.

А можна крыху больш пра vRouter?
Ён дзеліцца на дзве часткі: vRouter Agent і vRouter Forwarder.

Першы запускаецца ў User Space хаставой АС і мае зносіны з SDN-кантролерам, абменьваючыся інфармацыяй аб маршрутах, VRF і ACL.

Другі рэалізуе Data Plane – звычайна ў Kernel Space, але можа запускацца і на SmartNIC'ах – сеткавых картах з CPU і асобным праграмуемым чыпам камутацыі, што дазваляе зняць нагрузку з CPU хаставой машыны, а сетка зрабіць хутчэй і больш прадказальнай.

Яшчэ магчымы сцэнар, калі vRouter - гэта DPDK-дадатак у User Space.

vRouter Agent спускае наладкі на vRouter Forwarder.

Што за Virtual Network?
Я абмовіўся ў пачатку артыкула аб VRF, што маўляў кожны тэнант прывязваецца да свайго VRF. І калі для павярхоўнага разумення працы оверлейнай сеткі гэтага было дастаткова, то ўжо на наступнай ітэрацыі трэба рабіць удакладненні.

Звычайна ў механізмах віртуалізацыі сутнасць Virtual Network (можна лічыць гэта імем уласным) уводзіцца асобна ад кліентаў/тэнантаў/віртуальных машын - цалкам сабе самастойная рэч. А гэты Virtual Network праз інтэрфейсы ўжо можна падлучыць у адзін тэнант, у іншы, у два, ды хоць куды. Так, напрыклад, рэалізуецца Service Chaining, калі трафік трэба прапусціць праз пэўныя ноды ў патрэбнай паслядоўнасці, проста ў правільнай паслядоўнасці ствараючы і прыцягваючы Virtual Network'і.

Таму як такой прамой адпаведнасці паміж Virtual Network і тэнантам няма.

Заключэнне

Гэта вельмі павярхоўнае апісанне працы віртуальнай сеткі з оверлеем з хаста і SDN-кантролерам. Але якую б платформу віртуалізацыі вы сёння ні ўзялі, працаваць яна будзе падобнай выявай, няхай гэта будзе VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric або Juniper Contrail. Яны будуць адрознівацца выглядамі інкапсуляцый і загалоўкаў, пратаколамі дастаўкі інфармацыі на канчатковыя сеткавыя прылады, але прынцып праграмна наладжвальнай оверлейной сеткі, якая працуе па-над параўнальна простай і статычнай андэрлейнай сеткі застанецца ранейшым.
Можна сказаць, што вобласці стварэння прыватнага аблокі на сённяшні дзень SDN на аснове аверлейнай сеткі перамог. Зрэшты гэта не значыць, што Openflow няма месца ў сучасным свеце - ён выкарыстоўваецца ў OpenStacke і ў той жа VMWare NSX, яго, наколькі мне вядома, выкарыстоўвае Google для налады андэрлейнай сеткі.

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

А што тамака наш Underlay?

А ўвогуле нічога. Ён усю дарогу не мяняўся. Усё, што яму трэба рабіць у выпадку оверлея з хаста - гэта абнаўляць маршруты і ARP'ы па меры з'яўлення і знікненні vRouter/VNGW і цягаць пакеты паміж імі.

Давайце сфармулюем спіс патрабаванняў да Underlay-сеткі.

1. Умець у нейкі пратакол маршрутызацыі, у нашай сітуацыі - BGP.
2. Мець шырокую паласу, пажадана без перападпіскі, каб не губляліся пакеты з-за перагрузак.
3. Падтрымліваць ECMP - неад'емная частка фабрыкі.
4. Умець забяспечыць QoS, у тым ліку хітрыя штукі, накшталт ECN.
5. Падтрымліваць NETCONF - задзел на будучыню.

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

Відавочна, я моцна абмяжоўваю нас усіх, выкарыстоўваючы ў якасці прыкладу сетку ДЦ, пабудаваную на фабрыцы Клоза з чыстай IP-маршрутызацыяй і оверлеем з хаста.

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

У рамках АДСМ мы з Раманам Горга плануем апублікаваць асобны выпуск пра віртуалізацыю вылічальных магутнасцей і яе ўзаемадзеянне з віртуалізацыяй сеткі. Заставайцеся на сувязі.

Карысныя спасылкі

• Tungsten Fabric Archvitecture.
• about:cloud. 6 гадзін пра Яндэкс.Хмара, дзе ў тым ліку закранаецца віртуальная сетка на TF.
• What Is Open vSwitch?
• Увядзенне ў VxLAN.
• RFC 7348. Virtual Extensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.
  
• Scaleway approach to VXLAN EVPN Fabric. Тут распавядаецца пра ўсю сетку ДЦ, у тым ліку Underlay, Overlay, падыходы да мульты-хоўмінгу і кіраванню.

Дзякуй

• Раману Горгу - былому вядучаму падкасьце linkmeup, а цяпер эксперту ў галіне хмарных платформаў. За каментары і праўкі. Ну і чакаем у хуткім будучыні яго глыбейшага артыкула аб віртуалізацыі.
• Аляксандру Шалімаву - Майму калегу і эксперту ў галіне распрацоўкі віртуальных сетак. За каментары і праўкі.
• Валянціну Сініцыну - Майму калегу і эксперту ў галіне Tungsten Fabric. За каментары і праўкі.
• Арцёму Чарнабаю - ілюстратару linkmeup. За КДПВ.
• Аляксандру Лімонаву. За мем "automato".

Крыніца: habr.com