Масштаб мережі Amazon Web Services – це 69 зон по всьому світу у 22 регіонах: США, Європа, Азія, Африка та Австралія. У кожній зоні знаходиться до 8 ЦОД – Центрів Обробки Даних. У кожному ЦОД тисячі чи сотні тисяч серверів. Мережа побудована так, що всі малоймовірні сценарії перебоїв у роботі беруться до уваги. Наприклад, всі регіони ізольовані один від одного, а зони доступності рознесені на відстані кілька кілометрів. Навіть якщо перерубати кабель, система перейде на резервні канали, а втрати інформації становитимуть одиниці пакетів даних. Про те, на яких ще принципах побудовано мережу та як вона влаштована, розповість Василь Пантюхін.
Василь Пантюхін починав Unix-адміном у .ru-компаніях, 6 років займався великими залозками Sun Microsystem, 11 років проповідував дата-центричність світу в EMC. Природним шляхом еволюціонував у приватні хмари, потім подався до публічних. Зараз, як архітектор Amazon Web Services, технічними порадами допомагає жити та розвиватися у хмарі AWS.
У попередній частині трилогії про пристрій AWS Василь заглибився у пристрій фізичних серверів та масштабування бази даних. Nitro-карти, кастомний гіпервізор на базі KVM, база даних Amazon Aurora – про це в матеріалі «». Прочитайте, щоб поринути у контекст, або подивіться виступи.
У цій частині йтиметься про масштабування мережі — однієї з найскладніших систем AWS. Еволюція від плоскої мережі до Virtual Private Cloud та її пристрій, внутрішні сервіси Blackfoot та HyperPlane, проблема галасливого сусіда, а наприкінці – масштаби мережі, backbone та фізичні кабелі. Про все це під катом.
Дисклеймер: все, що нижче – особиста думка Василя, і вона може не співпадати з позицією Amazon Web Services.
Масштабування мережі
Хмару AWS запустили у 2006 році. Його мережа була досить примітивною — із плоскою структурою. Діапазон приватних адрес був спільним для всіх тенантів хмари. При запуску нової віртуальної машини ви випадково отримували доступну IP-адресу з цього діапазону.
Такий підхід був простим у реалізації, але принципово обмежував використання хмари. Зокрема, було досить складно розробляти гібридні рішення, в яких поєднувалися приватні мережі на землі та в AWS. Найпоширеніша проблема була у перетині діапазонів IP-адрес.
Віртуальна приватна хмара
Хмара виявилася затребуваною. Настав час задуматися про масштабованість та можливість його використання десятками мільйонів тенантів. Плоска мережа стала головною перешкодою. Тому ми замислилися, як ізолювати користувачів один від одного на мережевому рівні так, щоб вони могли самостійно вибирати діапазони IP.
Що першим спадає на думку, коли ви замислюєтеся про мережеву ізоляцію? звичайно VLAN и VRF - Virtual Routing and Forwarding.
На жаль, це не спрацювало. VLAN ID – це всього 12 біт, що дає нам лише 4096 ізольованих сегментів. Навіть у найбільших комутаторах можна використовувати максимум 1-2 тис. VRF. Спільне використання VRF та VLAN дає нам лише кілька мільйонів підмереж. Цього точно недостатньо для десятків мільйонів тенантів, кожен з яких повинен мати можливість використовувати кілька підмереж.
Ще ми просто не можемо собі дозволити купити необхідну кількість великих коробок, наприклад, Cisco або Juniper. Є дві причини: це дуже дорого, і ми не хочемо потрапляти в залежність від їхньої політики розробки та патчингу.
Висновок один – варити своє рішення.
2009 року ми анонсували VPC - Віртуальна приватна хмара. Назва прижилася і тепер багато хмарних провайдерів теж її використовують.
VPC – це віртуальна мережа SDN (Software Defined Network). Ми вирішили не винаходити спеціальних протоколів на рівнях L2 та L3. Мережа працює на стандартному Ethernet та IP. Для передачі через мережу трафік віртуальних машин інкапсулюється в обгортку нашого власного протоколу. У ньому вказується ID, що належить VPC тенанта.
Звучить просто. Проте потрібно вирішити кілька серйозних технічних завдань. Наприклад, де і як зберігати дані про мапування віртуальних MAC/IP-адрес, VPC ID та відповідних фізичних MAC/IP. У масштабах AWS це величезна таблиця, яка має працювати з мінімальними затримками при зверненні. За це відповідає сервіс мапування, що розмазаний тонким шаром по всій мережі.
У машинах нових поколінь інкапсуляція провадиться картами Nitro на залізному рівні. У старих інстансах інкапсуляція та декапсуляція програмні.
Розберемося як це працює загалом. Почнемо з рівня L2. Припустимо, що ми маємо віртуалку з IP 10.0.0.2 на фізичному сервері 192.168.0.3. Вона надсилає дані віртуальній машині 10.0.0.3, яка живе на 192.168.1.4. Формується ARP-запит, який потрапляє на мережну картку Nitro. Для простоти вважаємо, що обидві віртуалки живуть в одному «синьому» VPC.
Карта замінює адресу джерела на власну і пересилає ARP-фрейм сервісу мапування.
Сервіс мапування повертає інформацію, яка необхідна передачі по фізичної мережі L2.
Nitro-карта в ARP-відповіді замінює MAC у фізичній мережі на адресу VPC.
При передачі даних ми загортаємо логічні MAC та IP в VPC-обертку. Все це передаємо фізичною мережею за допомогою відповідних IP Nitro-карт джерела та призначення.
Фізична машина, якій призначений пакет, здійснює перевірку. Це потрібно, щоб запобігти можливості заміни адрес. Машина надсилає спеціальний запит сервісу мапування та запитує: «З фізичної машини 192.168.0.3 я отримала пакет, який призначений для 10.0.0.3 у «блакитному» VPC. Він легітимний?
Сервіс мапування звіряється зі своєю таблицею розміщення ресурсів і дозволяє, або забороняє проходження пакета. У всіх нових інстансах додаткова валідація прошита у Nitro-картах. Її неможливо оминути навіть теоретично. Тому spoofing на ресурси у іншому VPC не спрацює.
Далі дані відправляються віртуальній машині для якої вони призначені.
Сервіс мапування працює ще й як логічний маршрутизатор передачі даних між віртуалками в різних підмережах. Там концептуально все просто, не детально розбиратиму.
Виходить, що з передачі кожного пакета сервери звертаються до сервісу мапирования. Як боротися із неминучими затримками? Кешуванням, звичайно ж.
Вся краса в тому, що не потрібно кешувати всю величезну таблицю. На фізичному сервері живуть віртуалки із відносно невеликої кількості VPC. Кешувати інформацію потрібно лише про ці VPC. Передача даних до інших VPC у «дефолтній» конфігурації все одно не легітимна. Якщо використовується така функціональність, як VPC-peering, то кеш додатково підвантажується інформація про відповідні VPC.
З передачею даних VPC розібралися.
Чорна нога
Як бути у випадках, коли трафік треба передавати назовні, наприклад Internet або через VPN на землю? Тут нас рятує Чорна нога - Внутрішній сервіс AWS. Він розроблений нашою Південно-Африканською командою. Тому сервіс називається на честь пінгвіна, що живе у Південній Африці.
Blackfoot декапсулює трафік і робить з ним те, що потрібно. Дані до Інтернету відправляються як є.
Дані декапсулюються та знову завертаються в обгортку IPsec при використанні VPN.
При використанні Direct Connect трафік теґується та передається у відповідний VLAN.
HyperPlane
Це внутрішній сервіс контролю потоку. Багато мережевих сервісів вимагають контролю стану потоку даних. Наприклад, при використанні NAT, контроль потоку повинен гарантувати, що кожній парі IP: порт призначення відповідає унікальний вихідний порт. У разі балансувальника NLB - Балансувальник мережевого навантаження, Потік даних завжди повинен прямувати на одну і ту ж цільову віртуалку. Security Groups - це файрвол із збереженням стану. Він стежить за трафіком і неявно відкриває порти для вихідного потоку пакетів.
У хмарі AWS вимоги до затримок передачі дуже високі. Тому HyperPlane критичний для працездатності всієї мережі.
Hyperplane побудований на віртуальних машинах EC2. Тут немає ніякої магії, лише хитрість. Хитрість у тому, що це віртуалки із великим RAM. Операції транзакційні та виробляються виключно у пам'яті. Це дозволяє досягти затримок всього в десятки мікросекунд. Робота з диском вбила б усю продуктивність.
Hyperplane це розподілена система з великої кількості таких EC2-машин. Кожна віртуалка має пропускну спроможність 5 ГБ/сек. У масштабах усієї регіональної мережі це дає скажені терабіти пропускної спроможності та дозволяє обробляти мільйони з'єднань за секунду.
HyperPlane працює лише з потоками. VPC інкапсуляція пакетів для нього є абсолютно прозорою. Потенційна вразливість у цьому внутрішньому сервісі все одно не дозволить пробити ізоляцію VPC. За безпеку відповідають рівні нижче.
Noisy neighbor
Є ще проблема галасливого сусіда - галасливий сусід. Припустимо, що у нас 8 нід. Ці ноди обробляють потоки всіх користувачів хмари. Начебто все добре і навантаження має рівномірно розподілятися по всіх нодах. Ноди дуже потужні та перевантажити їх складно.
Але ми будуємо свою архітектуру, виходячи навіть із малоймовірних сценаріїв.
Низька ймовірність не означає неможливість.
Ми можемо уявити ситуацію, в якій один або кілька користувачів будуть генерувати занадто велике навантаження. У обробку цього навантаження залучені всі ноди HyperPlane та інші користувачі можуть потенційно відчути якесь зниження продуктивності. Це руйнує концепцію хмари, в якій тенанти не мають можливості впливати один на одного.
Як вирішити проблему галасливого сусіда? Перше що спадає на думку – шардування. Наші 8 нід логічно діляться на 4 шарди по 2 ноди в кожному. Тепер галасливий сусід завадить лише чверті всіх користувачів, зате сильно.
Давайте вчинимо по-іншому. Кожному користувачеві виділимо лише по 3 ноди.
Хитрість у тому, щоб призначати ноди різним користувачам випадково. На малюнку нижче синій користувач перетинається по нодах з одним із двох інших користувачів – зеленим та помаранчевим.
При 8 нодах та 3 користувачах ймовірність перетину галасливого сусіда з одним із користувачів становить 54%. Саме з такою ймовірністю синій користувач вплине на інших тенантів. При цьому лише частиною свого навантаження. У нашому прикладі цей вплив буде хоч якось помітно не всім, а лише третині всіх користувачів. Це вже непоганий результат.
Число користувачів, які перетнуться
Ймовірність у відсотках
0
18%
1
54%
2
26%
3
2%
Наблизимо ситуацію до реальної — візьмемо 100 нод та 5 користувачів на 5 нодах. У цьому випадку жодна з нід не перетнеться з ймовірністю 77%.
Число користувачів, які перетнуться
Ймовірність у відсотках
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
У реальній ситуації при величезній кількості HyperPlane нод та користувачів потенційний вплив галасливого сусіда на інших користувачів мінімальний. Цей метод називається перемішуючим шардуванням - shuffle sharding. Він мінімізує негативний ефект від виходу з ладу.
На базі HyperPlane збудовано безліч сервісів: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Масштаби мережі
Тепер поговоримо про масштаби самої мережі. На жовтень 2019 AWS пропонує свої сервіси 22 регіонах, а заплановано ще дев'ять.
- Кожен регіон містить кілька зон доступності – Availability Zone. Усього їх у світі 69.
- Кожна AZ складається з центрів обробки даних. Усього їх не більше 8.
- У ЦОД розташовується безліч серверів, у деяких до 300 000.
Тепер усе це середнім, перемножимо і отримаємо значну цифру, яка відображає масштаб хмари Amazon.
Між зонами доступності та ЦОД прокладено багато оптичних каналів. В одному найбільшому нашому регіоні лише для зв'язку AZ між собою та центрами зв'язку з іншими регіонами (Transit Centers) прокладено 388 каналів. У сумі це дає шалені 5000 Тбіт.
Backbone AWS побудований спеціально для хмари та оптимізований для роботи з ним. Ми будуємо його на каналах 100 ГБ/сек. Ми їх повністю контролюємо, крім регіонів у Китаї. Трафік не поділяється із навантаженнями інших компаній.
Звичайно, ми не єдиний хмарний провайдер із приватною backbone-мережею. Все більше і більше великих компаній йдуть цим шляхом. Це підтверджується незалежними дослідниками, наприклад, від .
На графіку видно, що частка провайдерів контенту та cloud-провайдерів зростає. Через це частка Internet-трафіку backbone-провайдерів постійно знижується.
Поясню чому так відбувається. Раніше більшість web-сервісів були доступними і споживалися безпосередньо з Internet. Зараз все більше серверів розташовані у хмарі та доступні через CDN - Мережа розповсюдження вмісту. Для доступу до ресурсу користувач іде через Internet лише до найближчої CDN PoP. Точка присутності. Найчастіше це десь поряд. Далі він залишає загальнодоступний Internet і приватним backbone летить через Атлантику, наприклад, і потрапляє безпосередньо на ресурс.
Цікаво, як зміниться Internet через 10 років, якщо ця тенденція збережеться?
Фізичні канали
Вчені поки не придумали, як збільшити швидкість світла у Всесвіті, але сильно просунулися в методах його передачі оптоволокном. Зараз ми використовуємо кабелі з 6912 волокнами. Це допомагає значно оптимізувати вартість їхньої прокладки.
У деяких регіонах нам потрібно використовувати спеціальні кабелі. Наприклад, у регіоні Сідней ми застосовуємо кабелі зі спеціальним покриттям проти термітів.
Від проблем ніхто не застрахований і іноді наші канали пошкоджуються. На фото праворуч оптичні кабелі в одному з Американських регіонів, які були порвані будівельниками. Внаслідок аварії загубилося всього 13 пакетів даних, що дивно. Ще раз – лише 13! Система буквально миттєво переключилася на резервні канали – масштаб працює.
Ми галопом пробіглися деякими сервісами та технологіями хмари Amazon. Сподіваюся, що у вас з'явилося хоча б деяке уявлення про масштаб завдань, які вирішують наші інженери. Особисто це мене дуже захоплює.
Це фінальна частина трилогії від Василя Пантюхіна про пристрій AWS. У частини описані оптимізація серверів і масштабування бази даних, а - серверлес-функції та Firecracker.
На у листопаді Василь Пантюхін поділиться новими подробицями пристрою Amazon. Він про причини відмов і проектування розподілених систем в Amazon. 24 жовтня ще можна квиток за гарною ціною, а сплатити потім. Чекаємо на вас на HighLoad++, приходьте — поспілкуємося!
Джерело: habr.com