Как Yandex.Cloud работи с Virtual Private Cloud и как нашите потребители ни помагат да внедрим полезни функции

Здравейте, казвам се Костя Крамлих, аз съм водещият разработчик на отдела за виртуален частен облак в Yandex.Cloud. Аз съм виртуална мрежа и както може би се досещате, в тази статия ще говоря за устройството за виртуален частен облак (VPC) като цяло и за виртуалната мрежа в частност. Освен това ще разберете защо ние, разработчиците на услугата, ценим обратната връзка от нашите потребители. Но на първо място.

Какво е VPC?

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

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

Как изглежда една виртуална мрежа отвън?

Под VPC имаме предвид основно мрежа с наслагване и мрежови услуги, като VPNaaS, NATaas, LBaas и т.н. И всичко това работи върху мрежова инфраструктура, устойчива на грешки, която вече е страхотна статия тук, на Хабре.

Нека разгледаме по-отблизо виртуалната мрежа и нейното устройство.

Помислете за две зони на достъпност. Ние предоставяме виртуална мрежа - това, което нарекохме VPC. Всъщност той определя пространството на уникалност на вашите "сиви" адреси. В рамките на всяка виртуална мрежа имате пълен контрол върху пространството от адреси, които можете да присвоите на изчислителни ресурси.

Мрежата е глобална. В същото време той се проектира върху всяка от зоните на достъпност под формата на обект, наречен Subnet. За всяка подмрежа присвоявате CIDR с размер 16 или по-малък. Може да има повече от един такъв обект във всяка зона на достъпност и винаги има прозрачно маршрутизиране между тях. Това означава, че всички ваши ресурси в рамките на един и същ VPC могат да „разговарят“ помежду си, дори ако са в различни зони на достъпност. „Общуват“ без достъп до интернет, през нашите вътрешни канали, „мислейки си“, че са в една и съща частна мрежа.

Диаграмата по-горе показва типична ситуация: два VPC, които се пресичат някъде в адреси. И двете могат да бъдат ваши. Например единият за разработка, другият за тестване. Може просто да има различни потребители - в този случай няма значение. И една виртуална машина е включена във всеки VPC.

Нека влошим схемата. Можете да направите така, че една виртуална машина да бъде залепена в няколко подмрежи наведнъж. И не просто така, а в различни виртуални мрежи.

В същото време, ако трябва да изложите машини на интернет, това може да стане чрез API или UI. За да направите това, трябва да конфигурирате NAT превод на вашия „сив“ вътрешен адрес в „бял“ - публичен. Не можете да изберете "бял" адрес, той се присвоява на случаен принцип от нашия набор от адреси. Веднага след като спрете да използвате външния IP, той се връща в пула. Плащате само за времето на използване на "белия" адрес.

Възможно е също така да се даде на машината достъп до интернет чрез NAT инстанция. Можете да насочвате трафик към екземпляр чрез статична таблица за маршрутизиране. Предоставили сме такъв калъф, защото потребителите понякога имат нужда от него и ние знаем за него. Съответно нашият каталог с изображения съдържа специално конфигуриран NAT образ.

Но дори когато има готов NAT образ, настройката може да бъде трудна. Разбрахме, че за някои потребители това не е най-удобната опция, така че в крайна сметка направихме възможно активирането на NAT за желаната подмрежа с едно кликване. Тази функция все още е в затворен достъп за визуализация, където се тества с помощта на членове на общността.

Как е подредена виртуалната мрежа отвътре

Как потребителят взаимодейства с виртуалната мрежа? Мрежата гледа навън със своя API. Потребителят идва в API и работи с целевото състояние. Чрез API потребителят вижда как всичко трябва да бъде подредено и конфигурирано, докато вижда състоянието, колко реалното състояние се различава от желаното. Това е снимка на потребителя. Какво става вътре?

Записваме желаното състояние в базата данни на Yandex и отиваме да конфигурираме различни части на нашия VPC. Мрежата за наслагване в Yandex.Cloud се основава на избрани компоненти на OpenContrail, който наскоро беше наречен Tungsten Fabric. Мрежовите услуги се изпълняват на една платформа CloudGate. В CloudGate използвахме и редица компоненти с отворен код: GoBGP - за достъп до контролна информация, както и VPP - за внедряване на софтуерен рутер, който работи върху DPDK за пътя на данните.

Tungsten Fabric комуникира с CloudGate чрез GoBGP. Казва какво се случва в насложената мрежа. CloudGate от своя страна свързва наслагваните мрежи една с друга и с интернет.

Сега нека видим как една виртуална мрежа решава проблемите с мащабирането и достъпността. Нека разгледаме един прост случай. Има една зона за достъпност и в нея се създават две VPC. Внедрихме един екземпляр на Tungsten Fabric и той изтегля няколко десетки хиляди мрежи. Мрежите комуникират с CloudGate. CloudGate, както вече казахме, осигурява тяхната свързаност помежду си и с интернет.

Да кажем, че е добавена втора зона за достъпност. Той трябва да се провали напълно независимо от първия. Следователно във втората зона на достъпност трябва да инсталираме отделен екземпляр на Tungsten Fabric. Това ще бъде отделна система, която се занимава с наслагването и знае малко за първата система. И видимостта, че нашата виртуална мрежа е глобална, всъщност създава нашия VPC API. Това е неговата задача.

VPC1 се съпоставя към зона на наличност B, ако има ресурси в зона на наличност B, които се изпращат към VPC1. Ако няма ресурси от VPC2 в зона на наличност B, ние няма да материализираме VPC2 в тази зона. От своя страна, тъй като ресурси от VPC3 съществуват само в зона B, VPC3 не съществува в зона A. Всичко е просто и логично.

Нека отидем малко по-дълбоко и да видим как работи конкретен хост в Y.Cloud. Основното нещо, което искам да отбележа е, че всички хостове са подредени по един и същи начин. Ние правим така, че само необходимия минимум от услуги да работи на хардуер, всички останали да работят на виртуални машини. Ние изграждаме услуги от по-висок порядък, базирани на основни инфраструктурни услуги, и също така използваме облака за решаване на някои инженерни проблеми, например в рамките на непрекъснатата интеграция.

Ако погледнем конкретен хост, можем да видим, че има три компонента, работещи на хост ОС:

• Compute - частта, отговорна за разпределението на изчислителните ресурси на хоста.
• VRouter е част от Tungsten Fabric, която организира наслагване, т.е. тунелира пакети през подложка.
• VDisks са части от виртуализация на съхранение.

Освен това се стартират услуги във виртуални машини: облачни инфраструктурни услуги, платформени услуги и клиентски капацитет. Капацитетът на клиента и услугите на платформата винаги отиват към наслагването през VRouter.

Инфраструктурните услуги могат да се придържат към наслагването, но основно те искат да работят в основата. Те се забиват в подложката с помощта на SR-IOV. Всъщност ние нарязваме картата на виртуални мрежови карти (виртуални функции) и ги вкарваме във виртуални машини на инфраструктурата, за да не губим производителност. Например, същият CloudGate се стартира като една от тези инфраструктурни виртуални машини.

Сега, след като описахме глобалните задачи на виртуалната мрежа и структурата на основните компоненти на облака, нека да видим как точно различните части на виртуалната мрежа взаимодействат помежду си.

Различаваме три слоя в нашата система:

• Config Plane - задава целевото състояние на системата. Това е, което потребителят конфигурира чрез API.
• Контролна равнина - осигурява дефинирана от потребителя семантика, тоест привежда състоянието на равнината на данни до това, което е описано от потребителя в равнината на конфигурацията.
• Data Plane - директно обработва пакетите на потребителя.

Както казах по-горе, всичко започва с факта, че потребителската или вътрешната услуга на платформата идва до API и описва определено целево състояние.

Това състояние незабавно се записва в базата данни на Yandex, връща идентификационния номер на асинхронна операция чрез API и стартира нашата вътрешна машина, за да върне желаното от потребителя състояние. Задачите за конфигуриране отиват към SDN контролера и казват на Tungsten Fabric какво да прави в наслагването. Например запазват портове, виртуални мрежи и други подобни.

Config Plane в Tungsten Fabric изпраща необходимото състояние към Control Plane. Чрез него Config Plane комуникира с хостовете, казвайки какво точно ще им се върти скоро.

Сега нека да видим как изглежда системата на хостовете. Виртуалната машина има мрежов адаптер, включен във VRouter. VRouter е основен модул Tungsten Fabric, който разглежда пакети. Ако вече има поток за някакъв пакет, модулът го обработва. Ако няма поток, модулът прави така нареченото punting, т.е. изпраща пакет към процеса usermod. Процесът анализира пакета и или сам отговаря на него, като DHCP и DNS, или казва на VRouter какво да прави с него. След това VRouter може да обработи пакета.

Освен това трафикът между виртуални машини в една и съща виртуална мрежа протича прозрачно, не е насочен към CloudGate. Хостовете, на които са разположени виртуалните машини, комуникират директно един с друг. Те тунелират трафика и го препращат един към друг през подложката.

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

И Control Plane комуникира с CloudGate. По същия начин той отчита къде и кои виртуални машини са повдигнати, какви адреси имат. Това ви позволява да насочвате външен трафик и трафик от балансьори към тях.

Трафикът, който напуска VPC, идва към CloudGate, към пътя на данните, където VPP с нашите плъгини бързо се сдъвква. След това трафикът се изстрелва или към други VPC, или навън, към гранични рутери, които са конфигурирани чрез контролната равнина на самия CloudGate.

Планове за близкото бъдеще

Ако обобщим всичко казано по-горе в няколко изречения, можем да кажем, че VPC в Yandex.Cloud решава две важни задачи:

• Осигурява изолация между различни клиенти.
• Комбинира ресурси, инфраструктура, платформени услуги, други облаци и локални в една мрежа.

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

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

В момента имаме следния списък с планове за близко бъдеще:

• VPN като услуга
• Частните DNS екземпляри са изображения за бързо настройване на виртуални машини с предварително конфигуриран DNS сървър.
• DNS като услуга.
• Вътрешен балансьор на натоварването.
• Добавяне на "бял" IP адрес без повторно създаване на виртуалната машина.

Балансьорът и възможността за превключване на IP адреса за вече създадена виртуална машина бяха в този списък по искане на потребителите. Честно казано, без изрична обратна връзка щяхме да поемем тези функции малко по-късно. И така вече работим по проблема с адресите.

Първоначално „бял“ IP адрес можеше да се добави само при създаване на машина. Ако потребителят забрави да направи това, виртуалната машина трябваше да бъде създадена отново. Същото и, ако е необходимо, премахнете външния IP. Скоро ще бъде възможно публичният IP да се включва и изключва, без да се налага да създавате отново машината.

Чувствайте се свободни да изразите своето идеи и предложения за подкрепа други потребители. Вие ни помагате да направим облака по-добър и да получим важни и полезни функции по-бързо!

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