Прывітанне, мяне клічуць Косця Крамліх, я вядучы распрацоўшчык падраздзялення Virtual Private Cloud у Яндэкс.Аблокі. Я займаюся віртуальнай сеткай, і, як можна здагадацца, у гэтым артыкуле раскажу пра прыладу Virtual Private Cloud (VPC) у цэлым і віртуальнай сетцы ў прыватнасці. А яшчэ вы даведаецеся, чаму мы, распрацоўшчыкі сэрвісу, цэнім зваротную сувязь ад нашых карыстальнікаў. Але пра ўсё па парадку.
Што такое VPC?
У наш час для разгортвання сэрвісаў ёсць самыя розныя магчымасці. Упэўнены, хтосьці да гэтага часу трымае сервер пад сталом адміністратара, хоць, спадзяюся, такіх гісторый становіцца ўсё менш.
Цяпер сэрвісы імкнуцца сыходзіць у грамадскія аблокі, і як раз тут яны сутыкаюцца з VPC. VPC - гэта частка публічнага аблокі, якая правязвае карыстацкія, інфраструктурныя, платформенныя і іншыя магутнасці разам, дзе б яны ні знаходзіліся, у нашым Аблокі або за яго межамі. Пры гэтым VPC дазваляе не выстаўляць без неабходнасці гэтыя магутнасці ў інтэрнэт, яны застаюцца ў межах вашай ізаляванай сеткі.
Як віртуальная сетка выглядае звонку
Пад VPC мы разумеем першым чынам оверлейную сетку і сеткавыя сэрвісы, такія як VPNaaS, NATaas, LBaas і т. д. І ўсё гэта працуе па-над адмоваўстойлівай сеткавай інфраструктуры, пра якую ўжо была тутака ж, на Хабры.
Давайце паглядзім на віртуальную сетку і яе прыладу больш уважліва.
Разгледзім дзве зоны даступнасці. Мы даем віртуальную сетку - тое, што мы назвалі VPC. Фактычна яна вызначае прастору ўнікальнасці вашых "шэрых" адрасоў. У рамках кожнай віртуальнай сеткі вы поўнасцю кіруеце прасторай адрасоў, якія можаце прызначаць вылічальным рэсурсам.
Сетка глабальная. Пры гэтым яна праецыюецца на кожную з зон даступнасці ў выглядзе сутнасці пад назовам Subnet. Для кожнай Subnet вы прызначаеце нейкі CIDR памерам 16 ці менш. У кожнай зоне даступнасці можа быць больш адной такой сутнасці, пры гэтым паміж імі заўсёды ёсць празрысты routing. Гэта значыць, што ўсе вашы рэсурсы ў межах адной 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. Калі рэсурсаў з VPC2 у зоне даступнасці B няма, VPC2 у гэтай зоне мы не матэрыялізуем. У сваю чаргу, паколькі рэсурсы з VPC3 існуюць толькі ў зоне B, VPC3 няма ў зоне A. Усё проста і лагічна.
Давайце пойдзем крыху глыбей і паглядзім, як уладкованы пэўны хост у Я.Облаке. Галоўнае, што жадаецца адзначыць, усё хасты ўладкованыя аднолькава. Мы робім так, што толькі неабходны мінімум сэрвісаў круціцца на жалезе, усе астатнія працуюць на віртуальных машынах. Мы будуем сэрвісы больш высокага парадку на аснове базавых інфраструктурных сэрвісаў, а таксама выкарыстоўваем Воблака для вырашэння некаторых інжынерных задач, напрыклад, у рамках Continuous Integration.
Калі мы паглядзім на пэўны хост, мы ўбачым, што ў АС хаста круцяцца тры кампаненты:
- Compute - частка, якая адказвае за размеркаванне вылічальных рэсурсаў на хасце.
- VRouter – частка Tungsten Fabric, якая арганізуе оверлей, гэта значыць тунэлюе пакеты праз андэрляў (underlay).
- VDisk - гэта кавалкі віртуалізацыі сховішча.
Акрамя гэтага ў віртуальных машынах запушчаны сэрвісы: інфраструктурныя сэрвісы Аблокі, платформенныя сэрвісы і магутнасці замоўцаў. Магутнасці заказчыкаў і платформенныя сэрвісы заўсёды ходзяць у аверлей праз VRouter.
Інфраструктурныя сэрвісы могуць утыкацца ў оверлей, але ў асноўным жадаюць працаваць менавіта ў андэрлеі. У андэрляў яны ўтыкаюцца з дапамогай SR-IOV. Фактычна мы рэжам карту на віртуальныя сеткавыя карткі (віртуальныя функцыі) і прасоўваем іх у інфраструктурныя віртуалкі, каб не губляць прадукцыйнасць. Напрыклад, гэты CloudGate запушчаны ў выглядзе адной з такіх інфраструктурных віртуальных машын.
Цяпер, калі мы апісалі глабальныя задачы віртуальнай сеткі і прылада базавых кампанентаў аблокі, давайце паглядзім, як менавіта розныя часткі віртуальнай сеткі ўзаемадзейнічаюць сябар з сябрам.
Мы вылучаем у нашай сістэме тры пласта:
- Config Plane - задае мэтавае стан сістэмы. Гэта тое, што канфігуруе карыстач праз API.
- Control Plane - забяспечвае зададзеную карыстачом семантыку, гэта значыць даводзіць стан Data Plane да таго, што было апісана карыстачом у Config Plane.
- Data Plane - непасрэдна апрацоўвае пакеты карыстальніка.
Як я ўжо казаў вышэй, усё пачынаецца з таго, што карыстач ці ўнутраны платформавы сэрвіс прыходзіць у API і апісвае вызначаны мэтавы стан.
Гэты стан адразу запісваецца ў Yandex Database, вяртае праз API ID асінхроннай аперацыі і запускае нашу ўнутраную машынерыю, каб выдаць стан, якое жадаў карыстач. Канфігурацыйныя цягі ідуць у SDN-кантролер і распавядаюць Tungsten Fabric, што трэба зрабіць у оверлее. Напрыклад, яны рэзервуюць парты, віртуальныя сеткі і да таго падобнае.
Config Plane у Tungsten Fabric адгружае ў Control Plane патрабаваны стан. Праз яго ж Config Plane мае зносіны з хастамі, распавядаючы, што менавіта на іх будзе круціцца ў хуткім часе.
Цяпер паглядзім, як выглядае сістэма на хастах. У віртуальнай машыне ёсць нейкі сеткавы адаптар, уваткнуты ў VRouter. VRouter - гэта ядзерны модуль Tungsten Fabric, які глядзіць на пакеты. Калі для некаторага пакета ўжо ёсць flow, модуль яго апрацоўвае. Калі flow няма, модуль робіць так званы punting, гэта значыць пасылае пакет у юзермод-працэс. Працэс разбірае пакет і альбо адказвае на яго сам, як, напрыклад, на DHCP і DNS, альбо кажа VRouter, што з ім рабіць. Пасля гэтага VRouter можа апрацоўваць пакет.
Далей трафік паміж віртуальнымі машынамі ў межах адной віртуальнай сетцы ходзіць празрыста, ён не накіроўваецца на CloudGate. Госты, на якіх разгорнутыя віртуальныя машыны, маюць зносіны сябар з сябрам напроста. Тунэлююць трафік і пракідваюць яго сябар для сябра праз андэрляў.
Control Plane маюць зносіны сябар з сябрам паміж зонамі даступнасці па BGP, як з іншым роўтарам. Яны расказваюць, якія машыны дзе падняты, каб віртуальныя машыны ў адной зоне маглі напрамую ўзаемадзейнічаць з іншымі віртуальнымі машынамі.
А яшчэ Control Plane мае зносіны з CloudGate. Аналагічна паведамляе, дзе і якія віртуалкі паднятыя, якія ў іх адрасы. Гэта дазваляе накіроўваць на іх вонкавы трафік і трафік ад балансавальнікаў.
Трафік, які выходзіць з VPC, прыходзіць на CloudGate, у data path, дзе хутка перажоўваецца VPP з нашымі плягінамі. Далей трафік выстрэльваецца альбо ў іншыя VPC, альбо вонкі, у памежныя маршрутызатары, якія наладжваюцца праз Control Plane самога CloudGate.
Планы на бліжэйшую будучыню
Калі абагульніць усё сказанае вышэй у некалькіх сказах, можна сказаць, што VPC у Яндекс.Облаке вырашае дзве важныя задачы:
- Забяспечвае ізаляцыю паміж рознымі кліентамі.
- Аб'ядноўвае рэсурсы, інфраструктуру, платформенныя сэрвісы, іншыя аблокі і on-premise у адзіную сетку.
А каб вырашаць гэтыя задачы добра, трэба забяспечваць маштабаванасць і адмоваўстойлівасць на ўзроўні ўнутранай архітэктуры, што VPC і робіць.
Паступова VPC абрастае функцыямі, мы рэалізуем новыя магчымасці, імкнемся паляпшаць штосьці ў плане выгоды для карыстачоў. Некаторыя ідэі агучваюцца і трапляюць у ліст прыярытэтаў дзякуючы ўдзельнікам нашай суполкі.
Цяпер у нас прыкладна такі спіс планаў на бліжэйшую будучыню:
- VPN як сэрвіс.
- Private DNS інстансы - выявы для хуткай налады віртуальных машын з загадзя сканфігураваным DNS-серверам.
- DNS як сэрвіс.
- Унутраны балансавальнік нагрузкі.
- Даданне "белага" IP-адрасы без перастварэння віртуальнай машыны.
Балансавальнік і магчымасць перамыкаць IP-адрас для ўжо створанай віртуалкі апынуліся ў гэтым пераліку па запыце карыстачоў. Скажу сапраўды, без відавочнай зваротнай сувязі мы ўзяліся б за гэтыя функцыі некалькі пазней. А так мы ўжо працуем над задачай пра адрасы.
Першапачаткова "белы" IP-адрас можна было дадаць толькі пры стварэнні машыны. Калі карыстач забываў гэта зрабіць, віртуальную машыну прыходзілася пераствараць. Тое ж самае і пры неабходнасці прыбраць вонкавы IP. Хутка можна будзе ўключыць і выключыць публічны IP, не пераствараючы машыну.
Не саромейцеся выказваць свае іншых карыстальнікаў. Вы дапамагаеце нам рабіць Воблака лепш і хутчэй атрымліваеце важныя і карысныя функцыі!
Крыніца: habr.com