В я описав фреймворк мережевої автоматизації. За відгуками деяких людей навіть цей перший підхід до проблеми вже розклав деякі питання по поличках. І це дуже мене тішить, бо наша мета у циклі — не обмазати пітонівськими скриптами анзибль, а побудувати систему.
Цей же фреймворк ставить порядок, у якому ми розбиратимемося з питанням.
І віртуалізація мережі, якій присвячено цей випуск, не особливо вкладається в тематику АДСМ, де ми розуміємо автоматику.
Але погляньмо на неї під іншим кутом.
Вже давно однією мережею користуються багато послуг. У випадку оператора зв'язку це 2G, 3G, LTE, ШПД та B2B, наприклад. У випадку ДЦ: зв'язковість для різних клієнтів, Інтернет, блочне сховище, об'єктне сховище.
І всі послуги вимагають ізоляції один від одного. Так з'явилися оверлейні мережі.
І всі послуги не хочуть чекати, коли людина налаштує їх вручну. Так з'явилися оркестратори та SDN.
Перший підхід до систематичної автоматизації мережі, точніше її частини, давно вжито і багато де впроваджено в життя: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Ось із ним сьогодні й порозбираємося.
Зміст
- Причини
- Термінологія
- Underlay - фізична мережа
- Overlay - віртуальна мережа
- Overlay з ToR'a
- Overlay з хоста
- На прикладі Tungsten Fabric
- Комунікація всередині однієї фізичної машини
- Комунікація між ВМ, розташованими на різних фізичних машинах
- Вихід у зовнішній світ
- FAQ
- Висновок
- Корисні посилання
Причини
І якщо ми вже про це заговорили, то варто згадати передумови до віртуалізації мережі. Насправді цей процес розпочався не вчора.
Напевно, ви не раз чули, що мережа завжди була найінертнішою частиною будь-якої системи. І це правда у всіх сенсах. Мережа - це базис, на який спирається все, і робити зміни на ній досить складно - послуги не терплять, коли мережа лежить. Найчастіше виведення з експлуатації одного вузла може скласти більшу частину програм та вплинути на багато клієнтів. Почасти тому мережева команда може чинити опір будь-яким змінам — тому що зараз воно якось працює (ми, можливо, навіть не знаємо як), а тут треба щось нове налаштувати, і невідомо як воно вплине на мережу.
Щоб не чекати, коли мережевики прокинуть 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 та більш простої горизонтальної масштабованості.
VNF - 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-мережі:
- Overlay з ToR'a
- Overlay з хоста
Overlay з ToR'a
Overlay може починатися на комутаторі доступу (ToR), що стоїть у стійці, як це відбувається, наприклад, у випадку VXLAN-фабрики.
Це перевірений часом на мережах ISP механізм і всі вендори мережного обладнання його підтримують.
Однак у цьому випадку ToR-коммутатор повинен вміти розділяти різні сервіси, відповідно, а мережевий адміністратор має певною мірою співпрацювати з адміністраторами віртуальних машин і вносити зміни (нехай і автоматично) у конфігурацію пристроїв.
Тут я відішлю читача до статті про нашого старого друга .
В цій детально описані підходи до будівництва мережі ДЦ з EVPN VXLAN-фабрикою.
А для повнішого занурення в реалії, можна почитати цискіну книгу .
Зауважу, що VXLAN — це лише метод інкапсуляції та термінація тунелів може відбуватися не на ToR'і, а на хості, як це відбувається у випадку OpenStack'а, наприклад.
Однак, VXLAN-фабрика, де overlay починається на ToR'і є одним із усталених дизайнів оверлейної мережі.
Overlay з хоста
Інший підхід – починати та термінувати тунелі на кінцевих хостах.
У цьому випадку мережа (Underlay) залишається максимально простою та статичною.
А хост сам робить усі необхідні інкапсуляції.
Для цього потрібно, безумовно, запускати спеціальний додаток на хостах, але він того вартий.
По-перше, запустити клієнт на linux-машині простіше або, скажімо так, взагалі можливо — тоді як на комутаторі, швидше за все, доведеться поки звертатися до пропрієтарних SDN-рішень, що вбиває ідею мультивендорності.
По-друге, ToR-коммутатор у разі можна залишити максимально простим, як із погляду Control Plane'а, і Data Plane'а. Справді - з SDN-контролером йому тоді спілкуватися не потрібно, і зберігати мережі/ARP'и всіх підключених клієнтів - теж - достатньо знати IP-адресу фізичної машини, що кратно полегшує таблиці комутації/маршрутизації.
У серії АДСМ я вибираю підхід оверлея з хоста - далі ми говоримо тільки про нього і повертатися до VXLAN-фабрики ми вже не будемо.
Найпростіше розглянути на прикладах. І як піддослідний ми візьмемо OpenSource'ну SDN платформу OpenContrail, нині відому як .
Наприкінці статті я наведу деякі міркування на тему аналогії з OpenFlow та OpenvSwitch.
На прикладі Tungsten Fabric
На кожній фізичній машині є vRouter - Віртуальний маршрутизатор, який знає про підключені до нього мережі і яким клієнтам вони належать - по суті - PE-маршрутизатор. До кожного клієнта він підтримує ізольовану таблицю маршрутизації (читай VRF). І власне vRouter робить Overlay'не тунелювання.
Трохи докладніше про vRouter – наприкінці статті.
Кожна ВМ, розташована на гіпервізорі, з'єднується з vRouter'ом цієї машини через .
TAP — Terminal Access Point — віртуальний інтерфейс у ядрі linux, що дозволяє здійснювати мережеву взаємодію.
Якщо за vRouter'ом знаходиться кілька мереж, то для кожної з них створюється віртуальний інтерфейс, на який призначається IP-адреса - він буде адресою стандартного шлюзу.
Усі мережі одного клієнта розміщуються в один Розширення VRF (одну таблицю), різних – у різні.
Зроблю тут застереження, що не все так просто, і відправлю допитливого читача до кінця статті.
Щоб vRouter'и могли спілкуватися один з одним, а відповідно і ВМ, які перебувають за ними, вони обмінюються маршрутною інформацією через SDN-контролер.
Щоб вибратися у світ, існує точка виходу з матриці — шлюз віртуальної мережі VNGW - Virtual Network GateWay (термін мій).
Тепер розглянемо приклади комунікацій і буде ясність.
Комунікація всередині однієї фізичної машини
VM0 хоче надіслати пакет на VM2. Припустимо поки що це ВМ одного клієнта.
Площина даних
- VM-0 має маршрут за замовчуванням у його інтерфейс eth0. Пакет вирушає туди.
Цей інтерфейс eth0 насправді віртуально з'єднаний із віртуальним маршрутизатором vRouter через TAP-інтерфейс tap0. - vRouter аналізує який інтерфейс прийшов пакет, тобто якого клієнту (VRF) він належить, звіряє адресу одержувача з таблицею маршрутизації цього клієнта.
- Виявивши, що одержувач на цій же машині за іншим портом, 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-сервер, щоб отримати публічну адресу — це схоже на вихід до зовнішніх мереж, про які нижче.
Комунікація між ВМ, розташованими на різних фізичних машинах
Площина даних
- Початок такий самий: VM-0 посилає пакет з адресатом VM-7 (172.17.3.2) за своїм дефолтом.
- vRouter його отримує і цього разу бачить, що адресат знаходиться на іншій машині та доступний через тунель Tunnel0.
- Спочатку він вішає мітку MPLS, що ідентифікує віддалений інтерфейс, щоб на звороті vRouter міг визначити куди цей пакет помістити без додаткових лукапів.
- Tunnel0 має джерело 10.0.0.2, одержувач: 10.0.1.2.
vRouter додає заголовки GRE (або UDP) та новий IP до вихідного пакета. - У таблиці маршрутизації vRouter є стандартний маршрут за адресою ToR1 10.0.0.1. Туди й відправляє.
- ToR1 як учасник Underlay мережі знає (наприклад, OSPF), як дістатися до 10.0.1.2, і відправляє пакет за маршрутом. Зверніть увагу, що тут вмикається ECMP. На ілюстрації два некстхопи, і різні потоки розкладатимуться в них по хешу. У разі справжньої фабрики тут буде скоріше 4 некстхопи.
При цьому знати, що знаходиться під зовнішнім заголовком IP, йому не потрібно. Тобто фактично під IP може бути бутерброд з IPv6 over MPLS over Ethernet over MPLS over GRE over over Грека.
- Відповідно на стороні, що приймає, 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 для передачі методу інкапсуляції або .
При цьому не змінюється жодним чином конфігурація Underlay-мережі, яку до речі, автоматизувати набагато складніше, а зламати незручним рухом простіше.
Вихід у зовнішній світ
Десь симуляція має закінчитися і з віртуального світу потрібно вийти в реальний. І потрібен телефон шлюз.
Практикують два підходи:
- Ставиться апаратний маршрутизатор.
- Запускається будь-який appliance, що реалізує функції маршрутизатора (так-так, за SDN ми і з VNF зіткнулися). Назвемо його віртуальний шлюз.
Перевага другого підходу в дешевій горизонтальній масштабованості - не вистачає потужності - запустили ще одну віртуалку зі шлюзом. На будь-якій фізичній машині, без необхідності шукати вільні стійки, юніти, виведення харчування, купувати саму залізницю, везти її, встановлювати, комутувати, налаштовувати, а потім ще й міняти в ній збійні компоненти.
Мінуси ж у віртуального шлюзу в тому, що одиниця фізичного маршрутизатора все ж таки на порядки потужніша за багатоядерну віртуалку, а його софт, підігнаний під його ж апаратну основу, працює значно стабільніше (немає). Складно заперечувати і той факт, що програмно-апаратний комплекс просто працює, вимагаючи лише налаштування, тоді як запуск та обслуговування віртуального шлюзу – це заняття для сильних інженерів.
Однією своєю ногою шлюз дивиться у віртуальну мережу Overlay як звичайна Віртуальна Машина і може взаємодіяти з усіма іншими ВМ. У цьому вона може термінувати у собі мережі всіх клієнтів і, відповідно, здійснювати і маршрутизацію з-поміж них.
Інший ногою шлюз дивиться вже у магістральну мережу та знає про те, як вибратися до Інтернету.
Площина даних
Тобто процес виглядає так:
- VM-0, маючи дефолт все той же vRouter, відправляє пакет з адресатом у зовнішньому світі (185.147.83.177) в інтерфейс eth0.
- vRouter отримує цей пакет і робить лукап адреси призначення в таблиці маршрутизації - знаходить маршрут за замовчуванням через VNGW1 шлюз через Tunnel 1.
Також він бачить, що це тунель GRE з SIP 10.0.0.2 і DIP 10.0.255.2, а ще потрібно спочатку повісити MPLS-мітку даного клієнта, на яку очікує VNGW1. - vRouter упаковує початковий пакет у заголовки MPLS, GRE та новий IP та відправляє на адресу ToR1 10.0.0.1 по дефолту.
- Андерлейна мережа доставляє пакет до VNGW1 шлюзу.
- Шлюз VNGW1 знімає заголовки GRE і MPLS, що тунелюють, бачить адресу призначення, консультується зі своєю таблицею маршрутизації і розуміє, що він спрямований в Інтернет — значить через Full View або Default. При необхідності здійснює NAT-трансляцію.
- Від VNGW до бордера може бути звичайна IP-мережа, що навряд.
Може бути класична мережа MPLS (IGP+LDP/RSVP TE), може бути назад фабрика з BGP LU або GRE-тунель від VNGW до бордера через IP-мережу.
Як би там не було, VNGW1 здійснює необхідні інкапсуляції і відправляє початковий пакет у бік бордера.
Трафік у зворотний бік проходить ті самі кроки у протилежному порядку.
- Бордер додає пакет до VNGW1
- Той роздягає, дивиться на адресу одержувача і бачить, що той доступний через тунель Tunnel1 (MPLSoGRE або MPLSoUDP).
- Відповідно, вішає мітку MPLS, заголовок GRE/UDP та новий IP та відправляє на свій ToR3 10.0.255.1.
Адреса призначення тунелю - IP-адреса vRouter'а, за якою стоїть цільова ВМ - 10.0.0.2. - Андерлейна мережа доставляє пакет до потрібного vRouter'а.
- Цільовий 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), змушуючи окремі потоки трафіку ходити не так, як їм велить маршрут.
FAQ
Навіщо ти постійно робиш ремарку 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-мережі.
- Вміти до якогось протоколу маршрутизації, у нашій ситуації — BGP.
- Мати широку смугу, бажано без перепідписки, щоб не губилися пакети через перевантаження.
- Підтримувати ECMP – невід'ємна частина заводу.
- Вміти забезпечити QoS, у тому числі хитрі штуки на кшталт ECN.
- Підтримувати NETCONF - зачеплення на майбутнє.
Роботі самої Underlay-мережі я присвятив тут мало часу. Це тому, що далі в серії я саме на ній і зосереджуся, а Overlay ми зачіпатимемо тільки побіжно.
Очевидно, я сильно обмежую нас усіх, використовуючи як приклад мережу ДЦ, побудовану на фабриці Клоза з чистою IP-маршрутизацією та оверлеєм з хоста.
Однак я впевнений, що будь-яку мережу, яка має дизайн, можна описати у формальних термінах та автоматизувати. Просто я ставлю за мету розібратися в підходах до автоматизації, а не заплутати всіх взагалі, вирішуючи завдання в загальному вигляді.
В рамках АДСМ ми з Романом Горге плануємо опублікувати окремий випуск про віртуалізацію обчислювальних потужностей та її взаємодію з віртуалізацією мережі. Залишайтеся на зв'язку.
Корисні посилання
- .
- . 6 годин про Яндекс.Хмара, де в тому числі торкається віртуальна мережа на TF.
- .
- . Тут розповідається про всю мережу ДЦ, включаючи Underlay, Overlay, підходи до мульти-хоумінгу та управління.
Дякую
- - колишньому ведучому подкасту linkmeup, а нині експерту в галузі хмарних платформ. За коментарі та редагування. Ну і чекаємо в найближчому майбутньому його глибшої статті про віртуалізацію.
- — мого колега та експерта в галузі розробки віртуальних мереж. За коментарі та редагування.
- — моєму колезі та експерту в галузі Tungsten Fabric. За коментарі та редагування.
- - Ілюстратор linkmeup. За КДПВ.
- Олександру Лимонову. За мем "automato".
Джерело: habr.com