Здравейте, казвам се Костя Крамлих и съм водещ разработчик на подразделението за Виртуални Частни Облаци в Яндекс.Облака. Работя с виртуалната мрежа и, както можете да предположите, в тази статия ще разкажа за структурата на Виртуалните Частни Облаци (VPC) като цяло и за виртуалната мрежа в частност. Освен това ще научите защо ние, разработчиците на услугата, ценим обратната връзка от нашите потребители. Но всичко по реда си.
Какво е VPC?
В наши дни има най-различни възможности за разгръщане на услуги. Сигурен съм, че все още някой държи сървър под бюрото на администратора, въпреки че се надявам, че такива истории стават все по-малко.
В момента услугите се опитват да се преместят в публични облаци и точно тук те се сблъскват с VPC. VPC е част от публичния облак, която объединява потребителски, инфраструктурни и платформени ресурси, където и да се намират те, в нашето Облако или извън него. Освен това, VPC позволява да не излагате тези ресурси в интернет без необходимост, те остават в рамките на вашата изолирана мрежа.
Как изглежда виртуалната мрежа отвън
Под VPC ние разбираме преди всичко overlay мрежа и мрежови услуги, като VPNaaS, NATaas, LBaas и т.н. И всичко това работи над отказоустойчива мрежова инфраструктура, за която вече беше отлична статия споменато тук, на Хабра.
Нека да разгледаме по-подробно виртуалната мрежа и нейната структура.
Нека разгледаме две зони на наличност. Ние предоставяме виртуална мрежа – това, което наричаме VPC. Всъщност тя определя пространството на уникалност на вашите "сиви" адреси. В рамките на всяка виртуална мрежа вие изцяло управлявате пространството от адреси, които можете да назначите на изчислителни ресурси.
Мрежата е глобална. В същото време тя се проектира върху всяка от зоните на наличност под формата на единица, наречена Subnet. За всяка Subnet задавате определен CIDR с размер 16 или по-малко. Във всяка зона на наличност може да има повече от една такава единица, като между тях винаги има прозрачен рутинг. Това означава, че всички ваши ресурси в рамките на една VPC могат да "комуникират" помежду си, дори ако се намират в различни зони на наличност. "Комуникация" без излизане в интернет, по нашите вътрешни канали, "мислейки", че се намират в рамките на една частна мрежа.
На схемата по-горе е показана типична ситуация: две VPC, които се припокриват по адресите. И двете могат да принадлежат на вас. Например, едната за разработка, другата – за тестване. Могат да бъдат просто различни потребители – в този случай това не е важно. И всяка VPC е свързана с по една виртуална машина.
Усложняваме схемата. Може да се направи така, че една виртуална машина да се свързва едновременно с няколко Subnet. И не просто така, а в различни виртуални мрежи.
В същото време, ако ви е необходимо да излагате машините в интернет, можете да го направите чрез API или UI. За целта е необходимо да настроите NAT транслацията на вашия "сив", вътрешен адрес, в "бял" – публичен. Не можете да изберете "бял" адрес, той се назначава случайно от нашия пул адреси. Както скоро преставате да използвате външен IP, той се връща в пула. Плащате само за времето на използване на "бял" адрес.
Също така има възможност да дадете на машината достъп до интернет с помощта на NAT инстанс. Трафикът може да се маршрутизира през статична таблица за маршрутизиране. Предвидихме такъв случай, защото понякога е необходим на потребителите, и ние знаем за това. Следователно, в нашия каталог на образи има специално конфигуриран NAT образ.
Но дори когато има готов NAT образ, настройката може да бъде сложна. Разбирахме, че за някои потребители това не е най-удобният вариант, затова в крайна сметка направихме възможност за активиране на NAT за нужната Subnet с едно кликване. Тази функция все още е в затворен preview достъп, където се тества с помощта на участници от общността.
Как е устроена виртуалната мрежа отвътре
Как потребителят взаимодейства с виртуалната мрежа? Мрежата гледа навън чрез своето API. Потребителят идва в API и работи с целевото състояние. Чрез API потребителят вижда как всичко трябва да бъде устроено и настроено, като в същото време вижда статуса, доколко действителното състояние се различава от желаното. Това е изображението на потребителя. А какво се случва вътре?
Записваме желаното състояние в Yandex Database и преминаваме към конфигуриране на различните части на нашата VPC. Оверлейната мрежа в Яндекс.Облака е изградена на основата на избрани компоненти на OpenContrail, които от скоро носят името Tungsten Fabric. Мрежовите услуги се реализират на единна платформа CloudGate. В CloudGate също използвахме известен брой open source компоненти: GoBGP – за обработка на контролна информация, както и VPP – за реализиране на софтуерен рутер, работещ на DPDK за data path.
Tungsten Fabric комуникира с CloudGate чрез GoBGP. Информира за случващото се в оверлейната мрежа. CloudGate от своя страна свързва оверлейните мрежи помежду им и с интернет.
Нека разгледаме как виртуалната мрежа решава задачи, свързани с мащабируемост и достъпност. Нека разгледаме прост случай. Има една зона на достъпност, в която са създадени две VPC. Разгръщаме един инстанс на Tungsten Fabric, който поддържа няколко десетки хиляди мрежи. Мрежите са свързани с CloudGate. CloudGate, както вече споменахме, осигурява свързаност помежду им и с интернет.
Предположим, добавя се втора зона на достъпност. Тя трябва да функционира напълно независимо от първата. Затова във втората зона на достъпност трябва да поставим отделен инстанс на Tungsten Fabric. Това ще бъде отделна система, която управлява оверлея и има малко знание за първата система. Възможността, че нашата виртуална мрежа е глобална, всъщност се създава от нашия VPC API. Това е неговата задача.
VPC1 се проектира в зона на достъпност B, ако в зона на достъпност B има ресурси, свързани с VPC1. Ако в зона на достъпност B няма ресурси от VPC2, VPC2 в тази зона не се материализира. От своя страна, тъй като ресурсите от VPC3 съществуват само в зона B, VPC3 не е в зона A. Всичко е просто и логично.
Нека да се задълбочим и да разгледаме как е построен конкретен хост в Я.Облака. Най-важното, което искам да подчертая, е, че всички хостове са устроени еднакво. Правим така, че само необходимият минимум от услуги да работи на 'железото', а всички останали работят на виртуални машини. Изграждаме услуги от по-високо ниво на базата на основни инфраструктурни услуги и също така използваме Облака за решаване на някои инженерни задачи, например, в рамките на Continuous Integration.
Ако погледнем конкретен хост, ще видим, че в ОС на хоста работят три компонента:
- Compute – частта, отговаряща за разпределението на изчислителните ресурси на хоста.
- VRouter – част от Tungsten Fabric, която организира overlay, т.е. тунелира пакетите през underlay.
- VDisk – това са парчетата на виртуализацията на хранилището.
Освен това в виртуални машини са стартирани услуги: инфраструктурни услуги на облака, платформени услуги и ресурси на клиентите. Ресурсите на клиентите и платформените услуги винаги минават през overlay чрез VRouter.
Инфраструктурните услуги могат да се свързват с overlay, но основно искат да работят именно в underlay. В underlay те се свързват чрез SR-IOV. Всъщност, ние разрязваме картата на виртуални мрежови интерфейси (виртуални функции) и ги вмъкваме в инфраструктурни виртуални машини, за да не губим производителност. Например, същият CloudGate е стартиран като една от тези инфраструктурни виртуални машини.
Сега, когато описахме глобалните задачи на виртуалната мрежа и структурата на основните компоненти на облака, нека видим как точно различните части на виртуалната мрежа взаимодействат помежду си.
Ние изолираме в нашата система три слоя:
- Config Plane – задава целевото състояние на системата. Това е онова, което потребителят конфигурира чрез API.
- Control Plane – осигурява зададената от потребителя семантика, т.е. довежда състоянието на Data Plane до описаното от потребителя в Config Plane.
- Data Plane – директно обработва пакетите на потребителя.
Както вече споменах, всичко започва с това, че потребителят или вътрешната платформена услуга идва в API и описва определено целево състояние.
Това състояние веднага се записва в Yandex Database, връща чрез API ID на асинхронната операция и стартира нашата вътрешна машина, за да издаде състоянието, което потребителят е искал. Конфигурационните задачи отиват в SDN контролера и информират Tungsten Fabric какво трябва да се направи в overlay. Например, те резервират портове, виртуални мрежи и подобни неща.
Config Plane в Tungsten Fabric изпраща в Control Plane нуждното състояние. Чрез него Config Plane комуникира с хостовете, информира ги какво точно ще работи на тях в близко време.
Сега да видим как изглежда системата на хостовете. В виртуална машина Има един мрежов адаптер, включен в VRouter. VRouter е ядрото на Tungsten Fabric, което обработва пакетите. Ако за определен пакет вече съществува flow, модулът го обработва. Ако flow няма, модулът прави така нареченото punting, т.е. изпраща пакета в потребителския процес. Процесът анализира пакета и или отговаря на него сам, както например при DHCP и DNS, или казва на VRouter какво да направи с него. След това VRouter може да обработва пакета.
След това трафикът между виртуалните машини в рамките на една виртуална мрежа протича прозрачно, не се насочва към CloudGate. Хостовете, на които са разположени виртуалните машини, комуникират помежду си директно. Те тунелират трафика и го прехвърлят един на друг през underlay.
Control Plane комуникират помежду си между зоните на достъп чрез BGP, както с друг рутер. Те информират кои машини къде са разположени, за да може виртуалните машини в една зона директно да взаимодействат с другите виртуални машини.
Освен това, Control Plane комуникира с CloudGate. По подобен начин информира къде и какви виртуални машини са разположени, какви са техните адреси. Това позволява да се насочва външен трафик и трафик от балансировачи.
Трафикът, който излиза от VPC, пристига на CloudGate, в data path, където бързо се обработва от VPP с нашите плъгини. След това трафикът се насочва или към други VPC, или навън, към граничните маршрутизатори, които се конфигурират чрез Control Plane на самия CloudGate.
Планове за близкото бъдеще
Ако обобщим всичко казано по-горе в няколко изречения, можем да кажем, че VPC в Yandex.Cloud решава две важни задачи:
- Осигурява изолация между различни клиенти.
- Обединява ресурси, инфраструктура, платформени услуги, други облаци и on-premise в една единна мрежа.
И за да се решават тези задачи добре, е необходимо да се осигури мащабируемост и устойчивост на ниво вътрешна архитектура, което VPC прави.
Постепенно VPC се обогатява с функции, реализираме нови възможности, стремим се да подобряваме неща с оглед на удобството за потребителите. Някои идеи се изказват и попадат в списъка с приоритети благодарение на участниците в нашата общност.
Сега имаме приблизително такъв списък с планове за близкото бъдеще:
- VPN като услуга.
- Частни DNS инстанции – образи за бърза настройка на виртуални машини с предварително конфигуриран DNS сървър.
- DNS като услуга.
- Вътрешен балансировчик на натоварването.
- Добавяне на „бял“ IP адрес без преосноваване на виртуалната машина.
Балансировчикът и възможността за смяна на IP адрес за вече създадена виртуалка бяха включени в този списък по искане на потребители. Честно казано, без явна обратна връзка, ние щяхме да се заемем с тези функции малко по-късно. В момента работим по задачата за адресите.
Първоначално „бял“ IP адрес можеше да бъде добавен само при създаването на машината. Ако потребителят забравеше да го направи, виртуалната машина трябваше да бъде преосновавана. Същото важи и за необходимостта от премахване на външния IP. Скоро ще можем да включваме и изключваме публичен IP, без да преосноваваме машината.
Не се колебайте да изразите своите идеи и да подкрепяте предложенията на другите потребители. Помагате ни да направим Облака по-добър и получавате важни и полезни функции по-бързо!
Източник: habr.com
