Маштаб сеткі 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 дэкапсулюе трафік і робіць з ім тое, што трэба. Дадзеныя ў Internet адпраўляюцца як ёсць.
Дадзеныя дэкапсулююцца і зноў заварочваюцца ў абгортку IPsec пры выкарыстанні VPN.
Пры выкарыстанні Direct Connect трафік тэгуецца і перадаецца ў які адпавядае VLAN.
HyperPlane
Гэта ўнутраны сэрвіс кантролю патоку. Многія сеткавыя сэрвісы патрабуюць кантролю стану патоку дадзеных. Напрыклад, пры выкарыстанні NAT, кантроль струменя павінен гарантаваць, што кожнай пары "IP: порт прызначэння" адпавядае ўнікальны выходны порт. У выпадку балансавальніка НББ - Network Load Balancer, струмень дадзеных заўсёды павінен накіроўвацца на адну і тую ж мэтавую віртуалку. Security Groups - гэта файрвол з захаваннем стану. Ён сочыць за ўваходным трафікам і няяўна адчыняе парты для выходнага струменя пакетаў.
У воблаку AWS патрабаванні да затрымак перадачы лімітава высокія. Таму HyperPlane крытычны для працаздольнасці ўсёй сеткі.
Hyperplane пабудаваны на віртуальных машынах EC2. Тут няма ніякай магіі, толькі хітрасць. Хітрасць у тым, што гэта віртуалкі з вялікім RAM. Аперацыі транзакцыйныя і робяцца выключна ў памяці. Гэта дазваляе дамагчыся затрымак усяго ў дзясяткі мікрасекунд. Праца з дыскам забіла б усю прадукцыйнасць.
Hyperplane гэта размеркаваная сістэма з вялікай колькасці такіх EC2-машын. Кожная віртуалка мае прапускную здольнасць 5 ГБ/С. У маштабах усёй рэгіянальнай сеткі гэта дае шалёныя тэрабіты прапускной здольнасці і дазваляе апрацоўваць мільёны злучэнняў у секунду.
HyperPlane працуе толькі са струменямі. VPC інкапсуляцыя пакетаў для яго зусім празрыстая. Патэнцыйная ўразлівасць у гэтым унутраным сэрвісе ўсё роўна не дазволіць прабіць ізаляцыю VPC. За бяспеку адказваюць узроўні ніжэй.
Noisy neighbor
Ёсць яшчэ праблема шумнага суседа - 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 рэгіёнах, а запланавана яшчэ 9.
- Кожны рэгіён змяшчае некалькі зон даступнасці – 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