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

Здраво, моето име е Костја Крамлих, јас сум главен развивач на поделбата за виртуелен приватен облак во Yandex.Cloud. Јас сум виртуелен вмрежувач, и како што може да претпоставите, во оваа статија ќе зборувам за уредот за виртуелен приватен облак (VPC) воопшто и за виртуелната мрежа особено. И, исто така, ќе дознаете зошто ние, развивачите на услугата, ги цениме повратните информации од нашите корисници. Но, прво прво.

Што е VPC?

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

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

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

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

Ајде внимателно да ја разгледаме виртуелната мрежа и нејзиниот уред.

Размислете за две зони на достапност. Обезбедуваме виртуелна мрежа - она ​​што го нарековме VPC. Всушност, тој го дефинира просторот на уникатноста на вашите „сиви“ адреси. Во секоја виртуелна мрежа, имате целосна контрола врз просторот на адреси што можете да ги доделите за пресметување на ресурсите.

Мрежата е глобална. Во исто време, тој се проектира на секоја од зоните на достапност во форма на ентитет наречен Подмрежа. За секоја подмрежа, доделувате CIDR со големина 16 или помалку. Може да има повеќе од еден таков ентитет во секоја зона на достапност и секогаш постои транспарентно рутирање меѓу нив. Ова значи дека сите ваши ресурси во рамките на истиот VPC можат да „разговараат“ едни со други, дури и ако се во различни зони на достапност. „Комуницирајте“ без пристап до Интернет, преку нашите внатрешни канали, „мислејќи“ дека се во иста приватна мрежа.

Дијаграмот погоре покажува типична ситуација: два VPC кои се вкрстуваат некаде во адресите. И двете можат да бидат ваши. На пример, еден за развој, другиот за тестирање. Едноставно може да има различни корисници - во овој случај тоа не е важно. И една виртуелна машина е вклучена во секој VPC.

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

Во исто време, ако треба да ги изложите машините на Интернет, тоа може да се направи преку API или UI. За да го направите ова, треба да го конфигурирате NAT преводот на вашата „сива“, внатрешна адреса, во „бела“ - јавна. Не можете да изберете „бела“ адреса, таа се доделува по случаен избор од нашиот базен на адреси. Штом престанете да ја користите надворешната IP адреса, таа се враќа во базенот. Плаќате само за времето на користење на „белата“ адреса.

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

Но, дури и кога има подготвена NAT слика, поставувањето може да биде незгодно. Разбравме дека за некои корисници ова не е најзгодната опција, па на крајот овозможивме да се овозможи NAT за саканата подмрежа со еден клик. Оваа функција сè уште е во затворен пристап за преглед, каде што се тестира со помош на членовите на заедницата.

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

Како корисникот комуницира со виртуелната мрежа? Вебот изгледа нанадвор со својот API. Корисникот доаѓа до API и работи со целната состојба. Преку API, корисникот гледа како сè треба да биде средено и конфигурирано, додека го гледа статусот, колку фактичката состојба се разликува од посакуваната. Ова е слика на корисникот. Што се случува внатре?

Ја пишуваме саканата состојба во Yandex Database и одиме да конфигурираме различни делови од нашиот VPC. Преклопената мрежа во Yandex.Cloud се заснова на избрани компоненти на OpenContrail, која неодамна беше наречена Волфрамска ткаенина. Мрежните услуги се имплементирани на една платформа CloudGate. Во CloudGate, користевме и голем број компоненти со отворен код: GoBGP - за пристап до информации за контрола, како и VPP - за имплементација на софтверски рутер што работи на врвот на DPDK за патеката за податоци.

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

Сега да видиме како виртуелната мрежа ги решава проблемите со скалирање и достапност. Да разгледаме едноставен случај. Има една зона на достапност и во неа се создаваат два VPC. Употребивме еден примерок од волфрамска ткаенина и тој повлекува неколку десетици илјади мрежи. Мрежите комуницираат со CloudGate. CloudGate, како што веќе рековме, ја обезбедува нивната поврзаност едни со други и со Интернет.

Да речеме дека е додадена втора зона на достапност. Треба да пропадне целосно независно од првиот. Затоа, во втората зона на достапност, мора да инсталираме посебен примерок од волфрамска ткаенина. Ова ќе биде посебен систем кој се занимава со преклопување и знае малку за првиот систем. И видливоста дека нашата виртуелна мрежа е глобална, всушност, го создава нашето VPC API. Ова е негова задача.

VPC1 е мапиран во зона на достапност Б ако има ресурси во зоната на достапност Б што се туркаат до VPC1. Ако нема ресурси од VPC2 во зоната на достапност Б, нема да го материјализираме VPC2 во оваа зона. За возврат, бидејќи ресурсите од VPC3 постојат само во зоната Б, VPC3 не постои во зоната А. Сè е едноставно и логично.

Ајде да одиме малку подлабоко и да видиме како работи одреден домаќин во Y.Cloud. Главната работа што сакам да ја забележам е дека сите домаќини се наредени на ист начин. Ние го правиме тоа така што само потребниот минимум услуги работи на хардвер, сите останати работат на виртуелни машини. Ние градиме услуги од повисок ред врз основа на основните инфраструктурни услуги, а исто така го користиме Облакот за да решиме некои инженерски проблеми, на пример, во рамките на Континуирана интеграција.

Ако погледнеме конкретен домаќин, можеме да видиме дека постојат три компоненти кои работат на оперативниот систем на домаќинот:

• Пресметајте - делот одговорен за дистрибуција на компјутерските ресурси на домаќинот.
• VRouter е дел од Tungsten Fabric што организира преклопување, односно тунелира пакети преку подлога.
• VDisks се делови од виртуелизација на складирање.

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

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

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

Разликуваме три слоја во нашиот систем:

• Config Plane - ја поставува целната состојба на системот. Ова е она што корисникот го конфигурира преку API.
• Контролна рамнина - обезбедува семантика дефинирана од корисникот, односно ја доведува состојбата на рамнина на податоци до она што го опишал корисникот во Config Plane.
• Data Plane - директно ги обработува пакетите на корисникот.

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

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

Конфигурациската рамнина во волфрамска ткаенина ја испраќа потребната состојба до контролната рамнина. Преку него, Config Plane комуницира со домаќините, кажувајќи што точно ќе им се врти наскоро.

Сега да видиме како изгледа системот на домаќините. Виртуелната машина има мрежен адаптер вклучен во VRouter. VRouter е основен модул за ткаенина од волфрам што ги разгледува пакетите. Ако веќе има проток за некој пакет, модулот го обработува. Ако нема проток, модулот го прави таканареченото punting, односно испраќа пакет до процесот usermod. Процесот го анализира пакетот и или самиот одговара на него, како DHCP и DNS, или му кажува на VRouter што да прави со него. После тоа, VRouter може да го обработи пакетот.

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

Контролните рамнини комуницираат меѓу себе помеѓу зоните на достапност преку BGP, како и со друг рутер. Тие кажуваат кои машини се горе, така што VM-ите во една зона можат директно да комуницираат со другите VM-и.

И 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