Сәлеметсіз бе, менің атым Костя Крамлич, мен Yandex.Cloud сайтындағы виртуалды жеке бұлт бөлімінің жетекші әзірлеушісімін. Мен виртуалды желіде жұмыс істеп жатырмын және сіз ойлағандай, бұл мақалада мен жалпы виртуалды жеке бұлт (VPC) құрылғысы және атап айтқанда виртуалды желі туралы айтатын боламын. Сондай-ақ, біз, сервис әзірлеушілері, пайдаланушылардың пікірлерін не үшін бағалайтынын білесіз. Бірақ бірінші нәрсе.
VPC дегеніміз не?
Қазіргі уақытта қызметтерді орналастырудың әртүрлі нұсқалары бар. Біреу әлі де әкімші үстелінің астында сервер ұстайтынына сенімдімін, дегенмен мұндай әңгімелер азайып бара жатыр деп үміттенемін.
Сейчас сервисы стараются уходить в публичные облака, и как раз тут они сталкиваются с VPC. VPC – это часть публичного облака, которая провязывает пользовательские, инфраструктурные, платформенные и прочие мощности воедино, где бы они ни находились, в нашем Облаке или за его пределами. При этом VPC позволяет не выставлять без необходимости эти мощности в интернет, они остаются в пределах вашей изолированной сети.
Как виртуальная сеть выглядит снаружи
VPC дегенде біз, ең алдымен, VPNaaS, NATaas, LBaas және т.б. сияқты қабаттастырылған желіні және желілік қызметтерді айтамыз. Мұның бәрі бұрын талқыланған ақауларға төзімді желілік инфрақұрылымның үстінде жұмыс істейді. мұнда Хабреде.
Виртуалды желіні және оның құрылымын толығырақ қарастырайық.
Рассмотрим две зоны доступности. Мы предоставляем виртуальную сеть – то, что мы назвали VPC. Фактически она определяет пространство уникальности ваших «серых» адресов. В рамках каждой виртуальной сети вы полностью управляете пространством адресов, которые можете назначать вычислительным ресурсам.
Сеть глобальна. При этом она проецируется на каждую из зон доступности в виде сущности под названием Subnet. Для каждой Subnet вы назначаете некий CIDR размером 16 или меньше. В каждой зоне доступности может быть больше одной такой сущности, при этом между ними всегда есть прозрачный routing. Это значит, что все ваши ресурсы в пределах одной VPC могут «общаться» друг с другом, даже если они находятся в разных зонах доступности. «Общаться» без выхода в интернет, по нашим внутренним каналам, «думая», что находятся в пределах одной частной сети.
Жоғарыдағы диаграмма әдеттегі жағдайды көрсетеді: мекенжайларының бір жерінде қиылысатын екі VPC. Екеуі де сенікі болуы мүмкін. Мысалы, бірі әзірлеу үшін, екіншісі тестілеу үшін. Әртүрлі пайдаланушылар болуы мүмкін - бұл жағдайда бұл маңызды емес. Әр VPC бір виртуалды машинаға ие.
Схеманы нашарлатайық. Бір виртуалды машинаны бірден бірнеше ішкі желіге қосуға болады. Бұл жай ғана емес, әртүрлі виртуалды желілерде.
Сонымен қатар, Интернетте машиналарды ашу қажет болса, мұны API немесе UI арқылы жасауға болады. Ол үшін «сұр» ішкі мекенжайыңыздың NAT аудармасын «ақ» – жалпыға ортақ мекенжайға теңшеу керек. Сіз «ақ» мекенжайды таңдай алмайсыз, ол біздің мекенжайлар пулымыздан кездейсоқ тағайындалады. Сыртқы IP пайдалануды тоқтатқаннан кейін ол пулға оралады. Сіз тек «ақ» мекенжайды пайдаланған уақыт үшін төлейсіз.
Также есть возможность выдать машине доступ в интернет с помощью NAT-инстанса. На инстанс можно зароутить трафик через статическую таблицу маршрутизации. Мы предусмотрели такой кейс, потому что он бывает нужен пользователям, и мы об этом знаем. Соответственно, в нашем каталоге образов лежит специально сконфигурированный NAT-образ.
Но даже когда есть готовый NAT-образ, настройка может быть сложной. Мы понимали, что для некоторых пользователей это не самый удобный вариант, поэтому в итоге сделали возможность включать NAT для нужной Subnet в один клик. Эта фича пока ещё в закрытом preview-доступе, где обкатывается с помощью участников сообщества.
Виртуалды желі ішінен қалай жұмыс істейді
Как взаимодействует с виртуальной сетью пользователь? Сеть смотрит наружу своим API. Пользователь приходит в API и работает с целевым состоянием. Через API пользователь видит, как всё должно быть устроено и настроено, при этом он видит статус, насколько действительное состояние отличается от желаемого. Это картина пользователя. А что происходит внутри?
Біз Яндекс дерекқорында қалаған күйді жазып, VPC-нің әртүрлі бөліктерін конфигурациялауға барамыз. Yandex.Cloud-тағы қабаттастыру желісі жақында вольфрамдық мата деп аталып кеткен OpenContrail-тың таңдалған құрамдастары негізінде құрастырылған. Желілік қызметтер бір CloudGate платформасында жүзеге асырылады. CloudGate-те біз сонымен қатар бірнеше ашық бастапқы құрамдастарды қолдандық: басқару ақпаратын өңдеуге арналған GoBGP, сондай-ақ деректер жолы үшін DPDK үстінде жұмыс істейтін бағдарламалық құрал маршрутизаторын іске асыру үшін VPP.
Tungsten Fabric CloudGate-пен GoBGP арқылы байланысады. Оверлейлік желіде не болып жатқанын айтады. CloudGate, өз кезегінде, қабаттасатын желілерді бір-бірімен және Интернетке қосады.
Енді виртуалды желі масштабтау және қолжетімділік мәселелерін қалай шешетінін қарастырайық. Қарапайым жағдайды қарастырайық. Бір қолжетімділік аймағы бар және онда екі VPC жасалған. Біз бір Tungsten Fabric данасын орналастырдық және ол бірнеше ондаған мың желілерді қамтиды. Желілер CloudGate-пен байланысады. CloudGate, жоғарыда айтқанымыздай, олардың бір-бірімен және Интернетпен байланысын қамтамасыз етеді.
Допустим, добавляется вторая зона доступности. Она должна выходить из строя совершенно независимо от первой. Поэтому во второй зоне доступности мы должны поставить отдельный инстанс Tungsten Fabric. Это будет отдельная система, которая занимается оверлеем и мало что знает о первой системе. А видимость, что наша виртуальная сеть глобальна, собственно, и создаёт наш VPC API. Это его задача.
Егер В қол жетімділік аймағында VPC1-ге жабысатын ресурстар болса, VPC1 қол жетімділік аймағымен салыстырылады. В қолжетімділік аймағында VPC2 ресурстары болмаса, біз бұл аймақта VPC2 іске асырмаймыз. Өз кезегінде, VPC3 ресурстары тек B аймағында болғандықтан, VPC3 A аймағында жоқ. Барлығы қарапайым және логикалық.
Давайте пойдём немного глубже и посмотрим, как устроен конкретный хост в Я.Облаке. Главное, что хочется отметить, – все хосты устроены одинаково. Мы делаем так, что только необходимый минимум сервисов крутится на «железе», все остальные работают на виртуальных машинах. Мы строим сервисы более высокого порядка на основе базовых инфраструктурных сервисов, а также используем Облако для решения некоторых инженерных задач, например, в рамках Continuous Integration.
Белгілі бір хостты қарастыратын болсақ, хост ОЖ-де жұмыс істейтін үш компонент бар екенін көреміз:
- Есептеу – хостта есептеу ресурстарын таратуға жауапты бөлік.
- VRouter — қабаттасуды ұйымдастыратын, яғни астыңғы қабат арқылы пакеттерді туннельдейтін вольфрам матаның бөлігі.
- VDisk - бұл сақтауды виртуалдандыру бөліктері.
Сонымен қатар, виртуалды машиналар қызметтерді іске қосады: бұлттық инфрақұрылым қызметтері, платформа қызметтері және тұтынушы сыйымдылығы. Тұтынушылардың мүмкіндіктері мен платформа қызметтері әрқашан VRouter арқылы қабаттасуға өтеді.
Инфрақұрылым қызметтері қабаттасуға қосыла алады, бірақ олар негізінен астарлы қабатта жұмыс істегісі келеді. Олар SR-IOV көмегімен астыңғы қабатқа жабыстырылады. Шын мәнінде, біз картаны виртуалды желі карталарына (виртуалды функциялар) кесеміз және өнімділігін жоғалтпау үшін оларды инфрақұрылымдық виртуалды машиналарға итереміз. Мысалы, сол CloudGate осы инфрақұрылымдық виртуалды машиналардың бірі ретінде іске қосылады.
Енді біз виртуалды желінің жаһандық міндеттерін және бұлттың негізгі құрамдас бөліктерінің дизайнын сипаттаған соң, виртуалды желінің әртүрлі бөліктерінің бір-бірімен дәл қалай әрекеттесетінін қарастырайық.
Мы выделяем в нашей системе три слоя:
- Config Plane – жүйенің мақсатты күйін орнатады. Бұл пайдаланушы API арқылы конфигурациялайды.
- Control Plane – обеспечивает заданную пользователем семантику, то есть доводит состояние Data Plane до того, что было описано пользователем в Config Plane.
- Деректер жазықтығы – пайдаланушы пакеттерін тікелей өңдейді.
Жоғарыда айтқанымдай, барлығы пайдаланушының немесе ішкі платформа қызметінің API-ге келуінен және белгілі бір мақсатты күйді сипаттаудан басталады.
Бұл күй бірден Яндекс дерекқорына жазылады, API арқылы асинхронды операцияның идентификаторын қайтарады және пайдаланушы қалаған күйді жасау үшін ішкі техникамызды іске қосады. Конфигурациялау тапсырмалары SDN контроллеріне өтіп, Вольфрам матасына қабаттастыруда не істеу керектігін айтады. Мысалы, олар порттарды, виртуалды желілерді және т.б. сақтайды.
Вольфрам матасындағы конфигурациялау жазықтығы қажетті күйді басқару жазықтығына жүктейді. Ол арқылы Config Plane хосттармен байланысып, оларға жақын болашақта нақты не жұмыс істейтінін айтады.
Енді жүйе хосттарда қалай көрінетінін көрейік. Виртуалды машинада VRouter желісіне қосылған белгілі бір желі адаптері бар. VRouter – пакеттерге қарайтын вольфрамдық матаның негізгі модулі. Кейбір пакеттер үшін ағын бар болса, модуль оны өңдейді. Егер ағын болмаса, модуль пунтинг деп аталатын әрекетті орындайды, яғни пакетті usermod процесіне жібереді. Процесс пакетті талдайды және DHCP және DNS сияқты оған өзі жауап береді немесе VRouter-ке онымен не істеу керектігін айтады. Содан кейін VRRouter пакетті өңдей алады.
Әрі қарай, бір виртуалды желідегі виртуалды машиналар арасындағы трафик мөлдір түрде жүреді, ол CloudGate-ке жіберілмейді. Виртуалды машиналар орналастырылған хосттар бір-бірімен тікелей байланысады. Олар трафикті туннель арқылы өткізіп, астыңғы қабат арқылы бір-біріне жібереді.
Басқару ұшақтары басқа маршрутизатор сияқты BGP арқылы қол жетімділік аймақтарында бір-бірімен байланысады. Олар бір аймақтағы виртуалды машиналар басқа виртуалды машиналармен тікелей байланыса алатындай етіп қай машиналар қайда орнатылғанын айтады.
А ещё Control Plane общается с CloudGate. Аналогично сообщает, где и какие виртуалки подняты, какие у них адреса. Это позволяет направлять на них внешний трафик и трафик от балансировщиков.
Трафик, который выходит из VPC, приходит на CloudGate, в data path, где быстро пережевывается VPP с нашими плагинами. Дальше трафик выстреливается либо в другие VPC, либо наружу, в пограничные маршрутизаторы, которые настраиваются через Control Plane самого CloudGate.
Жақын болашаққа арналған жоспарлар
Жоғарыда айтылғандардың барлығын бірнеше сөйлеммен қорытындылайтын болсақ, Yandex.Cloud-тағы VPC екі маңызды мәселені шешеді деп айта аламыз:
- Әртүрлі клиенттер арасында оқшаулауды қамтамасыз етеді.
- Ресурстарды, инфрақұрылымды, платформа қызметтерін, басқа бұлттарды және жергілікті бір желіге біріктіреді.
Бұл мәселелерді жақсы шешу үшін VPC жасайтын ішкі архитектура деңгейінде ауқымдылық пен ақауларға төзімділікті қамтамасыз ету керек.
Бірте-бірте VPC функцияларды алуда, біз жаңа мүмкіндіктерді енгізудеміз және пайдаланушылар үшін ыңғайлылық тұрғысынан бір нәрсені жақсартуға тырысамыз. Кейбір идеялар біздің қауымдастық мүшелерінің арқасында айтылып, басымдықтар тізіміне енгізілді.
Енді бізде жақын болашаққа арналған жоспарлардың шамамен келесі тізімі бар:
- VPN қызметі ретінде.
- Private DNS инстансы – образы для быстрой настройки виртуальных машин с заранее сконфигурированным DNS-сервером.
- DNS қызметі ретінде.
- Внутренний балансировщик нагрузки.
- Добавление «белого» IP-адреса без пересоздания виртуальной машины.
Балансировщик и возможность переключать IP-адрес для уже созданной виртуалки оказались в этом перечне по запросу пользователей. Скажу честно, без явной обратной связи мы взялись бы за эти функции несколько позже. А так мы уже работаем над задачей про адреса.
Бастапқыда «ақ» IP мекенжайын тек машина жасау кезінде қосуға болады. Егер пайдаланушы мұны ұмытып қалса, виртуалды машинаны қайта жасау керек болды. Қажет болса, сыртқы IP жоюға да қатысты. Жақында машинаны қайта жасамай-ақ жалпыға ортақ IP-ді қосу және өшіру мүмкін болады.
Не стесняйтесь высказывать свои других пользователей. Вы помогаете нам делать Облако лучше и быстрее получаете важные и полезные функции!
Ақпарат көзі: www.habr.com