Привіт, мене звуть Костя Крамліх, я провідний розробник підрозділу 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 існують тільки в зоні В, VPC3 немає в зоні А. Все просто і логічно.
Давайте підемо трохи глибше і подивимося, як влаштований конкретний хост у Я.Хмарі. Головне, що хочеться відзначити – всі хости влаштовані однаково. Ми робимо так, що лише необхідний мінімум сервісів крутиться на «залізі», всі інші працюють на віртуальних машинах. Ми будуємо сервіси вищого порядку на основі базових інфраструктурних сервісів, а також використовуємо Хмару для вирішення деяких інженерних завдань, наприклад, 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